Forum Discussion
Persist connection based on NTLM username
- Jan 29, 2023
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
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
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-ibnouJan 29, 2023Altostratus
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
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com