Windows Server - eDirectory Authentication in .net

Asked By nelsona on 05-Aug-08 01:48 PM
Hi, I'm having some issues using S.DS.P LdapConnection to try and
authenticate a login/password with a server hosting eDirectory.

I've tried this LdapConnection con = new LdapConnection(new
LdapDirectoryIdentifier(this.SearchRoot), new
System.Net.NetworkCredential(this.tbUserName.Text, this.tbPassword.Text),
AuthType.Basic);
where
SearchRoot = "10.16.173"
username="customer"
password="password"
I can successfully log into iManager on the server hosting eDirectory, but
trying in the windows app i get an exception of:
DirectoryOperationException - Confidentiality is required for this operation

So i tried setting:
con.SessionOptions.SecureSocketLayer = true;
con.SessionOptions.VerifyServerCertificate = new
VerifyServerCertificateCallback(ServerCallback);

Where ServerCallback just returns true, and now i get an LdapException
errorcode 81 The LDAP server is unavailable.

Thanks in advance for any advice you can offer, I've been searching for
quite a while now and keep coming up short.

Adam




Joe Kaplan replied on 05-Aug-08 04:19 PM
Do you need to use a different port when connecting to this server via SSL?
Perhaps you need to specify "10.16.173:636" in your identifier?

Normally, you should be accessing the server by hostname and should not have
to override SSL verification as the server's certificate should be fine and
should chain normally, but sometimes it is helpful to override the
verification.

Note also that if you need to get this authentication approach to scale
effectively, you will need to reuse your existing LdapConnection across
multiple requests as you will run out of TCP wildcard ports if you open and
close the connection over and over in rapid succession.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
nelsona replied on 05-Aug-08 07:16 PM
Thanks for the reply Joe,

I'm still not succeeding but I think I have environmental issues to figure
out, but you gave me some input to keep in mind for later.

I tried downloading a trial of /n software IP*Works SSL V8 and pointing the
sample site at my edirectory server, but it cant seem to talk to it either, I
dont think this is the time or place to go over server configuration but I'm
starting to think I screwed something up along those lines.

Thanks again.
Joe Kaplan replied on 05-Aug-08 09:33 PM
I use a low level SSL tool to check to see whether SSL itself can be
negotiated for this type of thing.  Sometimes there is something wrong on
the server with the private key on the cert and the server can't start the
handshake.

I don't know anything about eDirectory or I'd give you other pointers.  :)

Best luck getting it figured out.

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
Lance R replied on 09-Aug-08 10:37 AM
e
r, I
I am

Hey Adam - what happened when you tried with the LDAPS component in
IPWorks SSL?  I can definitely help you with that.

Lance
http://www.lancerobinson.net/
nelsona replied on 06-Aug-08 01:23 PM
Hey Lance,

I kinda changed the ldap page, instead of searching ldaps1.Search("(cn=" +
txtQuery.Text + ")"); i changed it to ldaps1.Search("(sn=*)"); so i get all
users back

I figured out that i was using the wrong value for ldap-server...i had been
trying servername-nds but it should just be servername, so then i ran the
query and got an exception of: server certificate verification failed.
Connection aborted.

again, the server was installed with all the default values, but when i
uncheck enable SSL on the page i get results back. This should help me get
further along.

If you have any input about why i get an exception when trying to use SSL
let me know....

Thanks to both for input and suggestions,

Adam
Lance R replied on 09-Aug-08 10:37 AM
On Aug 6, 1:23=A0pm, nelsonad <nelso...@>
en

Yep, I can help with this.

In order to be the most secure, the component can't just accept any
old SSL certificate unless one of the following is true:

1.  The server machine automatically trusts it (the cert issuers
public key is installed in the trusted root certificate store)

2.  You tell it to accept it by setting the SSLAcceptServerCert
property before attempting to connect.  If initially you don't have
such a setting, the component will provide the server certificate to
you for your inspection in the SSLServerCert property when you attempt
to bind.  If you trust this certificate, you can then set the
SSLAcceptServerCert to this same certificate before making future
requests.

3.  If you're using the SSLServerAuthentication event, you can inspect
the server certificate right there, and set the Accept parameter to
true to go ahead and accept the certificate and continue with the
connection.

Lance
http://www.lancerobinson.net/
nelsona replied on 06-Aug-08 04:31 PM
That makes sense, I just dont know how to work with certificates i guess. But
hopefully our customers trying to integrate LDAP authentication with our
application will....I guess I need to provide configuration options for using
SSL, the LDAP Search Root, and the Server Context

My authentication code is as follows: using S.DS.P objects

LdapConnection con = new LdapConnection(new
LdapDirectoryIdentifier(this.SearchRoot), new
System.Net.NetworkCredential(string.Empty, string.Empty), AuthType.Basic);
con.SessionOptions.SecureSocketLayer = this.UseSSL;
using (con)
{
con.Bind();
SearchRequest request = new SearchRequest("o=" + this.Context, "(uid="
+    this.tbUserName.Text + ")",
System.DirectoryServices.Protocols.SearchScope.Subtree);

SearchResponse response = (SearchResponse)con.SendRequest(request);
SearchResultEntry entry = response.Entries[0];
string dn = entry.DistinguishedName;
con.Credential = new NetworkCredential(dn, this.tbPassword.Text);
con.Bind();
}

in local testing i also have a line
con.SessionOptions.VerifyServerCertificate = new
VerifyServerCertificateCallback(ServerCallback);

which simply returns true because i cant seem to get my certificates
validated.
Joe Kaplan replied on 06-Aug-08 06:29 PM
If your callback function actually gets called, that means the server itself
can do an SSL handshake.  If you want to find out why the default
verification fails, I think it is easier to write a small piece of code
using .NET SslStream so you can get the full certificate chain provided by
the server and get the failure code.  The most likely problems are:

- name mismatch between the subject name in the cert and the DNS name used
to establish the connection
- server's full certificate chain is not trusted by the client
- server's certificate is expired

Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--