Open Enterprise Server 11SP1 (OES11SP1)
Domain Services for Windows
Some of the workstations try to send NTLMSSP authentication requests in the following sequence and fail to authenticate and the requests go in loop,
1. BIND (C->S)
2. BIND-ACK (S->C)
3. BIND (C->S)
4. BIND-ACK (S->C)
5. AUTH3 (C->S)
6. FAULT (S->C)
All the above 6 steps are looped over. The steps 1 and 2 are redundant and incomplete. This incomplete exchange is leaving the association group in the
stuck state and hence the resource exhaustion.
One of the stack show,
#0 0x00002aaaaabdf9f2 in rpc__cn_binding_inq_addr ()
#1 0x00002b95f3ead0d3 in rpc_binding_to_string_binding ()
#2 0x00002b95f258f622 in xad_sec_handle_is_local ()
#3 0x00002b95f533ffe9 in xad_lsa_policy_handle_new ()
#4 0x00002b95f53403bd in LsapOpenPolicy ()
#5 0x00002b95f5340966 in LsarOpenPolicy2 ()
#6 0x00002b95f5356140 in op44_ssr ()
#7 0x00002aaaaabe69d9 in rpc__cn_call_executor ()
The NTLM2 seal and sign verification in NTLMSSP is failing for NTLMv1 authentication protocol. As a result of this some 20 odd workstations repeatedly send the DCERPC BIND (using NTLMSSP) packets. This generated a lot of load on xadsd and have caused some crashes that are not consistently reproducible.
This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.