Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have created an ISAPI filter for IIS 6.0 that tries to authenticate against Active directory using LDAP. The filter works fine when authenticating regularly over port 389, but when I try to use SSL, I always get the 0x51 Server Down error at the ldap_connect() call. Even skipping the connect call and using ldap_simple_bind_s() results in the same error.

The weird thing is that if I change the app pool identity to the local admin account, then the filter works fine and LDAP over SSL is successful. I created an exe with the same code below and ran it on the server as admin and it works. Using the default NETWORK SERVICE identity for the site's app pool is what seems to be the problem. Any thoughts as to what is happening? I want to use the default identity since I don't want the website to have elevated admin privileges.

The server is in a DMZ outside the network and domain where our DCs are that run AD. We have a valid certificate on our DCs for AD as well.

Code:

// Initialize LDAP connection
LDAP * ldap = ldap_sslinit(servers, LDAP_SSL_PORT, 1);
ULONG version = LDAP_VERSION3;

if (ldap == NULL)
{
    strcpy(error_msg, ldap_err2string(LdapGetLastError()));
    valid_user = false;
}
else
{
    // Set LDAP options
    ldap_set_option(ldap, LDAP_OPT_PROTOCOL_VERSION, (void *) &version);
    ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_ON);

    // Make the connection
    ldap_response = ldap_connect(ldap, NULL); // <-- Error occurs here!

    // Bind and continue...
}

UPDATE: I created a new user without admin privileges and ran the test exe as the new user and I got the same Server Down error. I added the user to the Administrators group and got the same error as well. The only user that seems to work with LDAP over SSL authentication on this particular server is administrator.

The web server with the ISAPI filter (and where I've been running the test exe) is running Windows Server 2003. The DCs with AD on them are running 2008 R2.

Also worth mentioning, we have a WordPress site on the same server that authenticates against LDAP over SSL using PHP (OpenLDAP) and there's no problem there. I have an ldap.conf file that specifies TLS_REQCERT never and the user running the PHP code is IUSR.

share|improve this question
    
Is LDAP_SSL_PORT properly defined in all your scenario? –  Ram Jun 22 '12 at 23:41
    
Yes, it shows up as 636. –  Zac Jun 22 '12 at 23:51
    
If you create a separate account for the app pool identity, add it to the administrators group, does that work? If so, if the account is removed from the administrators group, does it continue to work? –  Greg Askew Jun 23 '12 at 1:01
    
Hi Greg, I tried that and the new account, whether it was part of the admin group or not, would not authenticate against LDAPS. The issue was because the web server didn't have the CA in its store. –  Zac Jun 23 '12 at 22:50
add comment

2 Answers

up vote 1 down vote accepted

Make sure the user that is failing trusts your ldap server's certificate authority.

To do that, log in as the user that is failing (you might have to grant temporary privileges for that, maybe put it in the "Remote Desktop" group). Start certmgr.msc and look for the certificate authority you are using under "Trusted Root Certification Authorities".

Compare what you see with what is in the Administrator account.

share|improve this answer
    
This suggestion led me to figure out the problem: the web server did not have a copy of the CA in its certificate store. As soon as I added the CA, all users were able to authenticate. I'm curious as to why administrator was able to authenticate though. Does the local admin account just bypass certificate checking? –  Zac Jun 23 '12 at 22:49
    
I imagine that the intermediate CA you had to add was already present in the other account as it had been seen before and was cached (as is typical in browsers). –  Ram Jun 25 '12 at 2:20
    
Didn't even think to check the current account's (admin) trusted CA list. That's exactly what it was. The CA was under the admin account and not the computer account. Thanks for the help guys! –  Zac Jun 25 '12 at 15:13
add comment

I believe you are having a trust store issue.

Please see http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx?mfr=true

A sample way of testing this might be to diff the text based output of your printing the certificate store contents.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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