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

Question

I have an application replicating data from a directory service using typical System.DirectoryServices.DirectoryEntry code. I now have a requirement to replicate from Novell eDirectory using SSL with a self-signed certificate. I suspect that the existing code would work with a valid certificate that could be verified, or perhaps if the self-signed cert is added to the local machine keystore. In order to make it work for sure with a self-signed cert however, the only solution I can find is to use the System.DirectoryServices.Protocols namespace and the LdapConnection class, whereby I can wire up a VerifyServerCertificate callback. I can't find any way of applying the same concept to a DirectoryEntry instance, or of connecting with an LdapConnection instance and somehow "converting" that to a DirectoryEntry instance. Maybe it isn't possible, I'd just like to confirm that really. Any other thoughts welcome.

The only pertinent link I've found is at: http://www.codeproject.com/Articles/19097/eDirectory-Authentication-using-LdapConnection-and

Answer 1

This is a phenomenal question.

I've been battling this same issue for a few days now, and I've finally got some definitive proof on why the DirectoryEntry object will not work in this scenario.

This particular Ldap server (running on LDAPS 636) also issues it's own self signed certificate. Using LdapConnection (and monitoring the traffic via Wireshark), I noticed a handshake taking place that does not occur when using DirectoryEntry :

The first sequence is the from the secured ldap server, the second sequence is from my machine. The code that prompts the second sequence is :

ldapConnection.SessionOptions.VerifyServerCertificate += delegate { return true; };

There are others way to "fake out" the callback, but this what I've been using.

Unfortunately, DirectoryEntry does not have an option or method to verify a self signed cert, thus the acceptance of the certificate never happens (second sequence), and the connection fails to initialize.

The only feasible way to accomplish this is by using LdapConnection, in conjunction with a SearchRequest and SearchResponse. This is what I've got so far :

LdapConnection ldapConnection = new LdapConnection("xxx.xxx.xxx:636");

var networkCredential = new NetworkCredential("Hey", "There", "Guy");
ldapConnection.SessionOptions.SecureSocketLayer = true;
ldapConnection.SessionOptions.VerifyServerCertificate += delegate { return true; };
ldapConnection.AuthType = AuthType.Negotiate;
ldapConnection.Bind(networkCredential);

SearchRequest request = new SearchRequest("DC=xxx,DC=xxx,DC=xxx", "(sAMAccountName=3074861)", SearchScope.Subtree);
SearchResponse response = (SearchResponse)ldapConnection.SendRequest(request);

if(response.Entries.Count == 1)
{SearchResultEntry entry = response.Entries[0];
 string DN = entry.DistinguishedName;}

From there you can gather AD Properties from the SearchResponse, and process accordingly. This is a total bummer though, because the SearchRequest seems to be much slower then using the DirectoryEntry.

Hope this helps!

Answer 2

I have used below code to connect with ldaps using DirectoryEntry.

What i understood in my scenerio is directoryEntry does not work when ldaps is specified in server path or authentication type is mentioned as "AuthenticationTypes.SecureSocketsLayer" but if only ldaps port is mentioned at the end of server name it work. After having a look at wireshark log i can see handshake taking place as mentioned in above post.

Handshake:

Code:

public static SearchResultCollection GetADUsers()
    {
        try
        {
            List<Users> lstADUsers = new List<Users>();
            DirectoryEntry searchRoot = new DirectoryEntry("LDAP://adserver.local:636", "username", "password");
            DirectorySearcher search = new DirectorySearcher(searchRoot);
            search.PropertiesToLoad.Add("samaccountname");
            SearchResult result;
            SearchResultCollection resultCol = search.FindAll();
            Console.WriteLine("Record count " + resultCol.Count);
            return resultCol;
        }
        catch (Exception ex)
        {
            Console.WriteLine("exception" + ex.Message);
            return null;
        }
    }

Answer 3

I promise, this will be my last post on this particular question. :)

After another week of research and development, I have a nice solution to this, and it has worked exceedingly well for me thus far.

The approach is somewhat different then my first answer, but in general, it's the same concept; using the LdapConnection to force validation of the certificate.

//I set my Domain, Filter, and Root-AutoDiscovery variables from the config file
string Domain = config.LdapAuth.LdapDomain;
string Filter = config.LdapAuth.LdapFilter;
bool AutoRootDiscovery = Convert.ToBoolean(config.LdapAuth.LdapAutoRootDiscovery);

//I start off by defining a string array for the attributes I want 
//to retrieve for the user, this is also defined in a config file.
string[] AttributeList = config.LdapAuth.LdapPropertyList.Split('|');

//Delcare your Network Credential with Username, Password, and the Domain
var credentials = new NetworkCredential(Username, Password, Domain);

//Here I create my directory identifier and connection, since I'm working 
//with a host address, I set the 3rd parameter (IsFQDNS) to false
var ldapidentifier = new LdapDirectoryIdentifier(ServerName, Port, false, false);
var ldapconn = new LdapConnection(ldapidentifier, credentials);

//This is still very important if the server has a self signed cert, a certificate 
//that has an invalid cert path, or hasn't been issued by a root certificate authority. 
ldapconn.SessionOptions.VerifyServerCertificate += delegate { return true; };

//I use a boolean to toggle weather or not I want to automatically find and query the absolute root. 
//If not, I'll just use the Domain value we already have from the config.
if (AutoRootDiscovery)
{
    var getRootRequest = new SearchRequest(string.Empty, "objectClass=*", SearchScope.Base, "rootDomainNamingContext");
    var rootResponse = (SearchResponse)ldapconn.SendRequest(getRootRequest);
    Domain = rootResponse.Entries[0].Attributes["rootDomainNamingContext"][0].ToString();
}

//This is the filter I've been using : (&(objectCategory=person)(objectClass=user)(&(sAMAccountName={{UserName}})))
string ldapFilter = Filter.Replace("{{UserName}}", UserName);

//Now we can start building our search request
var getUserRequest = new SearchRequest(Domain, ldapFilter, SearchScope.Subtree, AttributeList);

//I only want one entry, so I set the size limit to one
getUserRequest.SizeLimit = 1;

//This is absolutely crucial in getting the request speed we need (milliseconds), as
//setting the DomainScope will suppress any refferal creation from happening during the search
SearchOptionsControl SearchControl = new SearchOptionsControl(SearchOption.DomainScope);
getUserRequest.Controls.Add(SearchControl);

//This happens incredibly fast, even with massive Active Directory structures
var userResponse = (SearchResponse)ldapconn.SendRequest(getUserRequest);

//Now, I have an object that operates very similarly to DirectoryEntry, mission accomplished  
SearchResultEntry ResultEntry = userResponse.Entries[0];

The other thing I wanted to note here is that SearchResultEntry will return user "attributes" instead of "properties".

Attributes are returned as byte arrays, so you have to encode those in order to get the string representation. Thankfully, System.Text.Encoding contains a native ASCIIEncoding class that can handle this very easily.

string PropValue = ASCIIEncoding.ASCII.GetString(PropertyValueByteArray);

And that's about it! Very happy to finally have this figured out.

Cheers!