Forum Discussion
abdel-ibnou
Altostratus
AltostratusPersist connection based on NTLM username
Hello;
Have anyone an idea if the persistence based on NTLM username is possible or not without envolving APM module?
by analysing pcap traffic, i've found that the username is interchanged between Client & server starting from the 5th packet (after 3-way handshake) so the LB decision have already taken place and also this persistence criteria is encoded and crypted. but after the authentication, the client/server are not communicating anymore the username (seems that the session is authenticated just in its start).
My problematic is that i have a client (same @IP) that launch many scirpts using differente users and i want to load balance and persist based on the username (and i want to keep the persistence based on IP source as fallback mechanism for the other client)
is this kinf of persistence possible or not based on NTLM username?
Thank you
Wait a second... did you said the user is using scripts to authenticate with different users? The tell the dude to add a custom http header in his scripts containing the username. Problem solved... 😉
Cheers, Kai
mihaicMVP
- mihaic
abdel-ibnouthak you for your response,
first think that come to my bring is universal persistence but as i described there is many challenges:
-username (persistence criteria which is encrypted ) is communicated starting from the 5th packet (so the session is already load balanced and persisted by the fallback persistence by src IP address and all the scripts will pointed to the same Pool Membder.
-username is present just on the 5th and 6th packet of NTLM authentication and after that this criteria will desapear on traffic
-username is endoded and encrypted and this is challenging for irules
Regards
- Kai_Wilke
Hi Abdel-Ibnou,
although its basically a no brainer to extract the DOMAIN\User string out of the NTLM Handshake.
if { [HTTP::header value "Authorization"] starts_with "NTLM TlRMTVNTUAADAAAA" } then { set ntml_type3 [b64decode [findstr [HTTP::header value "Authorization"] " " 1]] binary scan $ntml_type3 @28sx2sx2sx2s dom_len dom_off usr_len usr_off binary scan $ntml_type3 @${dom_off}A${dom_len}@${usr_off}A${usr_len} domain user log "This is what you are looking for: [string map { \x00 "" } $domain]\\[string map { \x00 "" } $user]" }It would probably not work to shift the workload from NODE_A to NODE_B in the case the client is trying to establish a new NTLM session to the non-persisted node. It would most likely cause annoying authentication popups in user-agents, if you would call [LB::detach] and reselect the pool member by assigning a [persist uie label] at this point.
For transparent NTML authentication you may deploy source_ip or cookie bases persistence sessions to make sure the user-agent is persistet independently of the NTLM authentication. But this wont work, if many independent user-agents / client devices are used or if a single user-agent should become distributed based on the username currently used.
You may consider to switch from NTLM to SPNEGO/Kerberos authentication, in this case you could simply call [LB::detach] and reassign the node as you like as soon as you see a ticket flying in. Kerberos does not depend on challenges/responses that require multiple round trips...
Cheers, Kai
- Kai_Wilke
Wait a second... did you said the user is using scripts to authenticate with different users? The tell the dude to add a custom http header in his scripts containing the username. Problem solved... 😉
Cheers, Kai
- abdel-ibnou
thank you Kai_Wilke the irule script is interessant for retrieving info from Authorization header. sure i will test it but not in this case. I have suggested already that to customer he need to specify something on header for isolating each session. after thinking deeply about this problem, it seems it is not a persistence case (as you mentionned detaching a session and redirect it to another node will trigger a new authentication and it could impact the application behavior). the problem is mainly about taking a LB decision based on the new customized header and keep persisting using the same creteria.
Thank you again for you reply. i will mention your last post as a solution