Users reported that access to the internet via the ProxySG appliance was slow. A packet capture (pcap) revealed that the slow down occurred after the browser sent the NTLM login string to the ProxySG, with the ProxySG taking more than 5 seconds to respond. Additional packet captures at the BCAAA server showed many errors from the DC after the BCAAA server made the RPC query to the DC. For example:
DCERPC Bind_ack: call_id: 1 Unknown result (3), reason: Abstract syntax not supported
The pcap also showed a delayed DC response time of about 200 ms seconds.
In addition, the BCAAA debug log showed many delays in Windows RPC queries as shown in the following example:
2011/04/15 18:02:49.208  AcceptSecCtxt: pCtx=ead098 tLen=224 tId=b63ea sn=b63ea ct=700
2011/04/15 18:02:49.849  AcceptSecCtxt returns 0x0 LastError 0
This shows that there was over 600 ms of delay from the DC, between the AcceptSecCtxt and AcceptSecCtxt returns. These messages are written immediately before and after BCAAA calls the Windows AcceptSecurityContext API (netlogon). This is the API that BCAAA calls to validate Windows credentials.
When comparing the pcap with a different BCAAA server that did not have this symptom, the error did not appear and responses were within 10 ms., which indicates that the slowness was caused by the DC.
nltest /SC_RESET:<domain name>\unreachableep; This resets the secure channel to the specified domain controller (DC).
By using this command on the BCAAA server (it is a member of domain server) to point to a faster DC and restarting BCAAA, authentication times return to normal ranges within 20 ms.
Note: Please keep in mind that the affects of this command are temporary. Windows might decide to connect to another DC when it’s rebooted, or if the specified DC becomes unreachable for some reason.
You can refer to 000009829 for more information