Directory Programming .NET

Hi,

I had to write LDAP Authentication for my application against three different servers - Sun, Active Directory, and Novell's Edirectory. I was using System.DirectoryServices.protocols namespace where I found that the Available list of authentication types to be: Anonymous, Basic, Negotiate, Ntlm, Digest, Sicily, Dpa, Msn, External, Kerberos.

Now my question is, how can i set these different authentication types in each of these servers so that I can test how the app responds to my code. In short, how do i change the authentication type in each of these servers, and what type of authentication each of them support?

Thanks in advance,

Ramu

AD only supports Basic, Negotiate and Digest.  Anonymous isn't really an auth method.  It may support NTLM and Kerberos specifically instead of just Negotiate, but I've only tried Negotiate and know that to work for sure.  I don't know what Dpa, Msn or Sicily are.

All you have to do is set the auth type and pass in the credentials.  For basic auth, you don't pass in a domain name in the NetworkCredential object but use a qualified name instead (or the full DN).

Note that Basic auth (simple bind) is the only auth method in the LDAP spec and guaranteed to be supported on all servers.

Thanks for he reply Joe.

As far as the code is concerned, I just need to set the property connection.AuthType to be one of those values. But how do I set the server to use one of the Auth types so that i can test the same from my code. Or, how do i know what thype of Auth has been set in the server and how do I change them in the server. I am sure there should be some place in the Console where I can do this...

The server will use whatever auth type was specified by the client if it supports that auth type.  Thus if you say DIGEST, the server will do DIGEST auth, etc.  If it can't support that auth type, it will give you an error.

You can find out what SASL authentication mechanisms AD and ADAM support by getting the supportedSASLMechanisms attribute from rootDSE.  Other directories may support this as well.  As you'll see, AD and ADAM support GSSAPI, GSS-SPNEGO (negotiate auth), EXTERNAL (for client cert auth which does not currently work in S.DS.P) and DIGEST-MD5.  All directories support "Basic" (or simple bind) and since that is not a SASL auth mechanism, it is not included in that list in RootDSE.

I hope that helps.

In context to the above message:

I have to connect to a unix LDAP Server that allows GSSAPI sasl mechanism.  Should I be using AuthType.Negotiate and SASLmechanism GSSAPI for the ldapconnection.bind?

Also I am unable to find the correct NetworkCredential for GSSAPI. I can use the basic Username and Password but not for GSSAPI.

I actually don't have any knowledge of how to do GSSAPI interop outside of Windows.  I'm not sure if the Windows client will be able to find a KDC to get a Kerb ticket for this service.

Do you have any information at all about how Kerberos interop is deployed in this UNIX system?  Does the UNIX system use AD for Kerberos and thus the SPN for the service would be published in AD for the .NET client to find it or does it work through some other mechanism.

Honestly, I'd be pretty surprised if you can get this to work but it might be possible.  It may just require having the right magical DNS SRV records published but I really don't have any idea.

Thanks for the reply.

The SSPI uses the Active Directory for the Kerberos but only for the SPN using the Windows realm domain. We trying to solve this issue using the cross realm mapping.

But can I say that LDAPConnection will use SSPI  and try to check the server name for Kerb if the ldapserver saslmechanism does not support GSS-SPNEGO but only supports GSSAPI.

The issue is even if thats the case , on checking ethereal the ldapconnection.bind is not checking the server name (wrong name) for kerberos ticket.

Just need to confirm that the issue is only with the cross-realm problem and not the SSPI usage in ldapconnection.

 

I'm guessing that I'm not going to be of much assistance with this particular issue. You might need to talk to someone at MS directly through a support ticket or something. Do you have a way to do something like that (support contract, etc.)? I could try sending some emails to people who might know but I'm unsure if that will work.

Will be really grateful if you could email to the people who might know regarding the internal SSPI usage in LDAPConnection for Kerberos.

Thanks

I'll see what I can do. Going to wait until Monday as I've found that asking for favors on Friday afternoon can tend to result in emails getting lost and forgotten. Feel free to remind me Monday morning if you like. :)

Any luck on this?

Thanks

Avinash

Nope, nothing. :) Let me try again.