I am using the following C# code in the code behind of a webform deployed in an ASP.NET 4 (4.0.30319) application pool on Server1 and Server2.

PrincipalContext pc = new PrincipalContext(ContextType.Domain, "testnet.testad.org:636", "dc=testnet,dc=testad,dc=org");
bool validated = pc.ValidateCredentials(username, password, ContextOptions.Negotiate);

Server1 is running: windows server 2003 SP2
IIS 6.0
ASP.NET version 4.0.30319

Server1 takes between 30-60 seconds to authenticate depending on the options.
(Note: using regular ldap it authenticates immediately with no delay)

Server2 is running: windows server 2008 SP2
IIS 7.0
ASP.NET version 4.0.30319

Running the exact same code as Server1, Server2 authenticates almost instantaneously.
(I have also tried the code against another IIS 7.0 server with the same results)

So I believe the code is fine which is why I am asking this on serverfault.

Has anyone ran into this issue before?
Is there something I can patch or configure differently on Server1 to bring down the authentication time to be in line with Server2?

Thanks for any help on this.



I turned on wireshark while making an ldaps authentication request.
I have created a file containing all requests over 636.
It can be viewed here: Server1 636 traffic

The biggest gaps are found between:

No. 1949 at 1.115583 sec - No. 06788 at 14.501754 sec
No. 6803 at 14.64297 sec - No. 11742 at 27.921379 sec

All other traffic on that port occurs within the same second.

NOTE: There is roughly the same amount of traffic on Server2 but it all occurs between 2-3 seconds.
It can be viewed here: Server2 636 traffic

  • is server1 a production server? if not then I'd hit up MS for all the hotfixes if you haven't already. Also w2k8+ in general is a lot faster then w2k3. – tony roth Mar 25 '13 at 13:34
  • @tonyroth Server1 is a produciton server as is Server2. I agree that w2k8 performs much better than w2k3. I have also tried it on windows 7 machine and it performed as fast as w2k8. However, 30-60 seconds seems a bit excessive for a simple call to ldap over port 636? Additionally it authenticates immediately when not using the secure port 636 on the w2k3 machine. – Baxter Mar 25 '13 at 13:42
  • can you install netmon on server1, if so then I'd filter down to ldap and watch for gaps. – tony roth Mar 25 '13 at 15:50
  • @tonyroth I used wireshark and filtered down to just ldaps traffic on port 636. I have updated my question and provided a link to see the log file. Do you still need me to run netmon? – Baxter Mar 25 '13 at 17:15
  • 1
    It looks like some event i timing out. Potentially a CRL or root cert lookup? Since the delays seem to be in waiting for Server1, it may be trying to validate the server cert provided to it by the DC. Can you post a full capture from server1? +1 if you can post the .cap. I understand you may not want to post full packets so headers should be sufficient. – charleswj81 Mar 30 '13 at 18:43

Try running process monitor to see if you're getting access denied on:

C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

If so, give the service account read acces to it.

  • I ran process monitor and filtered results by path contains "Crypto\RSA\MachineKeys". When I ran the login page I found a lot of Access Denied entries to the path you specified. I have made the log entries available here: Process Monitor Logs What account do you mean by "service account" to give access to it? – Baxter Apr 3 '13 at 13:24
  • Additionally, in the logs the operation is "CreateFile" but the folders and machine keys the operation is being applied to already exist? The result for the folders is "Name Collision" and the result for the machine keys is "Access Denied". – Baxter Apr 3 '13 at 14:13
  • "NT AUTHORITY\NETWORK SERVICE" is getting the access denied, so give it READ / Execute permissions – Daro Apr 3 '13 at 16:16
  • I added read & execute / read permissions for "Network Service" to the key that was displaying all the access denied errors in procmon. This immediately resolved the problem. The ldaps login over 636 now works immediately and the key shows all success messages in procmon. Thank you very much for your assistance. – Baxter Apr 4 '13 at 0:26
  • You're welcome. – Daro Apr 4 '13 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.