Hi Jim, disclaimer: I'm not an NTLM expert... On Tue, Nov 3, 2015 at 3:04 PM, o haya <ohaya@xxxxxxxxx> wrote: > > I think that other info that binds to the authenticated user is at the SharePoint application level (maybe persisted in the app on the client side) because it doesn't look like any cookies or headers that are user-specific get sent to SharePoint after the user is authenticated. Not even the "Authentication: NTLM ..." header? > > So, in other words, once the user is authenticated via NTLM, it looks like it doesn't matter which connection any subsequent requests get sent over, since the session info is probably carried in the requests themselves somewhere (SharePoint 2010+ uses an internal STS, and the client-side app gets a token from the STS at some point and then persists it and sends that token along with requests to SharePoint). No idea where that authenticator/token may be... I suspect that once the user is authenticated on a connection, that connection is assumed to be owned by that same user and hence everything that comes in is the user session (there may be a check on the authenticator or token if available for each request, so that a renegotiation is asked on mismatch, but still multiple users can't share the same connection AFAICT). What happens if you use a threaded MPM (and start httpd with -X to leverage the multiplexing, as suggested in a previous message), or if you use another httpd (likewise threaded and started with -X) in front of your current proxy? The goal here is to have something in the chain that multiplexes requests on a the same connection before the Sharepoint, and hence see if the sharepoint behaves correctly in this case (I doubt so, otherwise you wouldn't need any particular httpd configuration or patch). Once the first user is NTLM-authenticated with a first connection to the frontend/multiplexer, open a second connection with no NTLM authentication (simple HTTP request), and then open a third one for another user (asking for his/her own NTLM authentication). Make sure the frontend reuse the same outgoing connection each time. Then you will see if the sharepoint: 1. is able to handle multiple users on the same connection, or 2. asks for renegotiation (in both cases), or 3. reuses the first session for successives requests (for one and/or the other case). Except 1., the users' sessions will break (and even be compromised in 3.), hence you'll need to make sure there is no multiplexer in the chain (SSL termination on the frontend/proxy, and direct connection to the backend -- no load-balancer or things like that). > > Anyway, that is what I think, as far as the importance of being on the same connection. Does that make sense? This requires a testing IMHO... Regards, Yann. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|