2

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.

4
  • Is LDAP_SSL_PORT properly defined in all your scenario?
    – Ram
    Jun 22, 2012 at 23:41
  • Yes, it shows up as 636.
    – Zac
    Jun 22, 2012 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, 2012 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, 2012 at 22:50

2 Answers 2

1

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.

3
  • 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, 2012 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, 2012 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, 2012 at 15:13
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .