How do I validate Active Directory creds over LDAP + SSL?

Question

I'm trying to use the .NET 3.5 System.DirectoryServices.AccountManagement namespace to validate user credentials against our Active Directory LDAP server over an SSL encrypted LDAP connection. Here's the sample code:

using (var pc = new PrincipalContext(ContextType.Domain, "sd.example.com:389", "DC=sd,DC=example,DC=com", ContextOptions.Negotiate))
{
    return pc.ValidateCredentials(_username, _password);
}

This code works fine over unsecured LDAP (port 389), however I'd rather not transmit a user/pass combination in clear text. But when I change to LDAP + SSL (port 636), I get the following exception:

System.DirectoryServices.Protocols.DirectoryOperationException: The server cannot handle directory requests.
  at System.DirectoryServices.Protocols.ErrorChecking.CheckAndSetLdapError(Int32 error)
  at System.DirectoryServices.Protocols.LdapSessionOptions.FastConcurrentBind()
  at System.DirectoryServices.AccountManagement.CredentialValidator.BindLdap(NetworkCredential creds, ContextOptions contextOptions)
  at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)
  at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)
  at (my code)

Port 636 works for other activities, such as looking up non-password information for that LDAP/AD entry...

UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, _username)

...so I know it's not my LDAP server's SSL setup, since it works over SSL for other lookups.

Has anyone gotten the ValidateCredentials(...) call to work over SSL? Can you explain how? Or is there another/better way to securely validate AD/LDAP credentials?

Here's an MSDN article for troubleshooting LDAP over SSL: http://support.microsoft.com/kb/938703 — CAbbott, Jun 01 '12 at 13:13
Thanks for the link. But again I can communicate over LDAPS (port 636) just fine for all the other LDAP queries I've performed. It seems like something unusual about `ValidateCredentials()`. I'll look through the article in more detail, though. — Nate Sauber, Jun 01 '12 at 13:25
Passwords should be transmitted in clear text - not hashed - over a secure connection to a server that supports password quality checks and password history enforcement unless the LDAP client provides password quality and history checks, otherwise, the server will not be able to enforce the quality and history. — Terry Gardner, Jun 01 '12 at 16:54

score 15 · Accepted Answer · answered Jun 01 '12 at 15:32

I was able to validate credentials using the System.DirectoryServices.Protocols namespace, thanks to a co-worker. Here's the code:

// See http://support.microsoft.com/kb/218185 for full list of LDAP error codes
const int ldapErrorInvalidCredentials = 0x31;

const string server = "sd.example.com:636";
const string domain = "sd.example.com";

try
{
    using (var ldapConnection = new LdapConnection(server))
    {
        var networkCredential = new NetworkCredential(_username, _password, domain);
        ldapConnection.SessionOptions.SecureSocketLayer = true;
        ldapConnection.AuthType = AuthType.Negotiate;
        ldapConnection.Bind(networkCredential);
    }

    // If the bind succeeds, the credentials are valid
    return true;
}
catch (LdapException ldapException)
{
    // Invalid credentials throw an exception with a specific error code
    if (ldapException.ErrorCode.Equals(ldapErrorInvalidCredentials))
    {
        return false;
    }

    throw;
}

I'm not thrilled with using a try/catch block to control decisioning logic, but it's what works. :/

It appears you were trying to talk to AD LDS (i.e. Lightweight Directory Services) and *not* AD DS (regular Active Directory). If that was the case then your original code didn't work because you specified the wrong ContextType. Per Microsoft docs if you want to query AD LDS then you need to specify **ContextType.ApplicationDirectory**. **ContextType.Domain** is for regular Active Directory only. https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices.accountmanagement.contexttype?view=netframework-4.8 — Mike Bouck, Apr 24 '19 at 21:49

score 3 · Answer 2 · answered Mar 12 '14 at 17:44

Maybe this is another way. There's nothing unusual in validate credentials. The ContextOptions must set properly.

Default value:

ContextOptions.Negotiate | ContextOptions.Signing | ContextOptions.Sealing

Add Ssl:

ContextOptions.Negotiate | ContextOptions.Signing | ContextOptions.Sealing | ContextOptions.SecureSocketLayer

ContextOptions.Negotiate or ContextOptions.SimpleBind is required. Or whatever your server need to perform authentication. ContextOptions only supports OR bit to bit.

You could try also set the ContextOptions directly this way in ValidateCredentials method.

using (var pc = new PrincipalContext(ContextType.Domain, "sd.example.com:636", "DC=sd,DC=example,DC=com", ContextOptions.Negotiate | ContextOptions.SecureSocketLayer))
{
    return pc.ValidateCredentials(_username, _password);
}

Or

using (var pc = new PrincipalContext(ContextType.Domain, "sd.example.com:636", "DC=sd,DC=example,DC=com", ContextOptions.Negotiate))
{
    return pc.ValidateCredentials(_username, _password, ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);
}

I see you say " Or whatever your server need to perform authentication.". How can I know what a server needs for authentication? I am working on a server which is previously set with some options, but I don't know what are they now. Can I check them somehow? — Tolga Evcimen, Nov 28 '14 at 12:33

Quark Soup · Answer 3 · 2017-02-02T21:30:55.210

For me, the ValidateCredentials method works just fine. The problem, I found, was on the server hosting the AD (I'm using AD LDS). You needed to associate the server certificate with the AD instance. So if your instance was called 'MyAD' (or ActiveDirectoryWebService), you needed to open up the MMC, snap in the 'Certificates' module, select 'Service Account' and then select 'MyAD' from the list. From there you can add the SSL certificate into the 'MyAD' Personal store. This finally kicked the SSL processing into gear.

I suspect, from what I know of the LdapConnection method and the fact that you omitted the callback function, that you are not validating your server certificate. It's a messy job and ValidateCredentials does it for free. Probably not a big deal, but a security hole none-the-less.

score 0 · Answer 4 · answered Mar 15 '18 at 22:24

I know this is old, but for anybody running into this again:

PrincipalContext.ValidateCredentials(...), by default, tries to open an SSL connection (ldap_init(NULL, 636)) followed by setting the option LDAP_OPT_FAST_CONCURRENT_BIND.

If a (trusted?) client certificate is present, however, the LDAP connection is implicitly bound and fast bind cannot be enabled anymore. PrincipalContext doesn't consider this case and fails with an unexpected DirectoryOperationException.

Workaround: To support SSL where possible, but have a fallback, call ValidateCredentials(...) with default options first (i.e. no options). If this fails with the DirectoryOperationException, try again by specifying the ContextOptions (Negotiate | Sealing | Signing), which is what ValidateCredentials internally does for the expected LdapException anyway.

Why do you think fast bind cannot be enabled, when we have SSL LDAP? — managerger, Aug 08 '22 at 14:05

How do I validate Active Directory creds over LDAP + SSL?

4 Answers4

Linked

Related