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
Altostratus
