Question

I have an interesting issue I’ve been trying to resolve for a few days.

I’m currently working with an Windows Server 2003 machine that is running a standard instance of Active Directory.

The directory contains two domain components (DCs) that both house users that are going to be authorizing against the directory, via my application.

I’m using :

• The IP address of the server as the host name
• An SSL connection via port 3269
• The GSS Negotiate Auth Mechanism
• A BaseDN that is a parentDN of both DC’s
• The sAMAccountName as the login name

The problem is, I cannot successfully authorize any users from DC1, yet all of the ones who belong to DC2 are completely fine and work great. I get this error on DC1 :

8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece
System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.

However, using Softerra’s LDAP Broswer, I can connect in and authorize the same exact user without any issue, so I know the credentials are correct.

From what I can tell, both of these DC’s are configured the same… I’ve browsed both of them for something, anything that is different… but have found nothing that really stands out.

I posted something months ago about this particular setup, and the code I’m using is in that thread as well.

Set callback for System.DirectoryServices.DirectoryEntry to handle self-signed SSL certificate?

Any help here would be much appreciated.

Thanks!

Answer 1

I was able to get this working, but for the life of me I cannot figure out why this was the case. Basically, this error…

8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece    System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid.

…was dead on. The issue was that users logging in under what I called DC2 needed to issue the bind with the domain AND sAMAccountName (Ex. LIB\JSmith), as opposed to DC1, which allowed just the sAMAccountName to be entered.

I figured the best way to make this programmatic was to use the principal binding account to query for the DN of the user. From that DN, using some crafty RegEx, I’m able to capture the domain they inherit from, and issue two separate binds.

SearchResultEntry ResultEntry = userResponse.Entries[0];

//Let's get the root domain of the user now using our DN RegEx and that search result
Regex RegexForBaseDN = new Regex(config.LdapAuth.LdapDnRegex);
Match match = RegexForBaseDN.Match(ResultEntry.DistinguishedName);
string domain = match.Groups[1].Value;

//Try binding the user with their domain\username
try
{
    var thisUser = new NetworkCredential{
                                         Domain = domain, 
                                         UserName = username, 
                                         Password = Pin
                                        };

     //If this goes well, we'll continue forward
     ldapconn.Bind(thisUser);
}

//If that doesn't work, try biding them with the highest level domain
catch (LdapException ex)
{
     if (ex.ErrorCode.Equals(LdapErrorCodes.LDAP_INVALID_CREDENTIALS))
     {
          var thisUserOnce = new NetworkCredential{
                                                   Domain = config.LdapAuth.LdapDomain,
                                                   UserName = username,
                                                   Password = Pin
                                                  };

          //If this goes well, we'll continue forward
          ldapconn.Bind(thisUserOnce);
      }
 }

It’s not nearly as elegant as I would have wanted, but it does work for this particular scenario.

However, I’m still really interested in why the naming conventions are different depending on which DC the user inherit’s from.