CODEWITHSUNDEEP
c#authenticationiis-7ldapiis-6
Baxter
Baxter

Reputation: 5845

Secure LDAP Authentication Issue

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

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

Server 2 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)

Has anyone ran into this issue before?
Is there an alternative way to authenticate on an IIS 6.0 server vs IIS 7.0 server?
Is there something I need to configure, add, remove etc.,?

Thanks for any help on this.

..............................................................................................................................................

[Update]

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
and
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

I ran netstat -ano” command and found the following connections for ldaps when I login:

Proto Local Address Foreign Address State PID
TCP 10.1.72.74:1761 10.1.72.54:636 ESTABLISHED 3688
TCP 10.1.72.74:1800 10.1.72.54:636 ESTABLISHED 3688
TCP 10.1.72.74:1825 10.1.72.54:636 ESTABLISHED 3688

Upvotes: 3

Views: 2557

Answers (3)

Daro
Daro

Reputation: 2020

Have a look at my answer at ServerFault...

The service may not be able to access:

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

Your mention:

Date: 3/25/2013 Time: 10:11:06 AM Source: Schannel "A fatal error occurred when attempting to access the SSL client credential private key.

makes it probable.

Upvotes: 2

Sean Hall
Sean Hall

Reputation: 7878

PrincipalContext's ValidateCredentials method is basically a wrapper for the LDAP Bind operation. The two key articles to read for this are IADsOpenDSObject::OpenDSObject and LDAP ADsPath.

You're using SSL, so you need to specify that if you want it to be as efficient as possible. The documentation on the ContextOptions argument of the ValidateCredentials method actually sounds like it doesn't support this:

A combination of one or more ContextOptions enumeration values the options used to bind to the server. This parameter can only specify Simple bind with or without SSL, or Negotiate bind.

Assuming that I'm misinterpreting the documentation and the ValidateCredentials method really does support specifying Negotiate | SecureSocketLayer, you need to look at how you're sending the username. In the OpenDSObject article, it gives this advice on the username's format:

You may pass in lpszUserName as one of the following strings:

  1. The name of a user account, such as "jeffsmith". To use a user name by itself, you must set only the ADS_SECURE_AUTHENTICATION flag in the lnReserved parameter.

  2. The user path from a previous version of Windows NT, such as "Fabrikam\jeffsmith".

  3. Distinguished Name, such as "CN=Jeff Smith,OU=Sales,DC=Fabrikam,DC=Com". To use a DN, the lnReserved parameter must be zero or it must include the ADS_USE_SSL flag

  4. User Principal Name (UPN), such as "[email protected]". To use a UPN, you must assign the appropriate UPN value for the userPrincipalName attribute of the target user object.

You're setting the SSL flag, so you have to use 2, 3, or 4.

P.S. In your example code, you are specifying the domain's DNS name in the constructor. If you're specifying a server in your real code, you need to add the ServerBind flag.

Upvotes: 1

BLoB
BLoB

Reputation: 9725

Check the registry key entries to see what SSL / TLS version is supported; an issue which can result in handshake issues... (see Scenario 5 in the link given below)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

For some relevant scenarios and their resolutions have a read of troubleshooting ssl related issues server certificate

Upvotes: 1

Related Questions