Directory Programming .NET

Hello

I have a program that binds to ADAM (running on W2K3 SP2) and performs a simple query (looking for a particular node, where I know the full DN).  Connection to ADAM using Digest authentication.  This has been working correctly for some time (thanks to Joe and Ryan on this forum back in August 2007 for helping with this).

I now have a scenario where this code is failing.  I am catching a DirectoryOperationException which contains Response.ErrorMessage="000004DC: LdapErr: DSID-0C09062B, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece".

I don't understand the error, because I have performed a successful bind.

However, it's not as simple as that.  My code is being used inside a WCF middletier, which is impersonating the client (using Kerberos delegation).  Also I am connecting to the ADAM server using it's IP address instead of it's name (see footnote below).

If I connect to the ADAM server by name instead of IP the problem disappears and code works perfectly.  Or if I disable the client impersonation (and thus connect to ADAM using the middletier service's account) the problem also disappears.  Unfortunately neither of these are acceptable solutions for me so I'm searching for a reason.

The only reference to this error I've been able to find was at http://blog.joeware.net/2006/03/15/259/ but this doesn't match my scenario.

Any suggestions greatly appreciated.

PEvans

Footnote:  Actually the problem first surfaced because we are running ADAM on a 2-server NLB cluster (ADAM installed on both nodes, with replication between each other).  The problem occurs when we connect to ADAM on the cluster's name, but disappears when connecting to ADAM on either server1 or server2.  I don't think that NLB is relevant, because the problem also surfaces as described in the main text, when connecting to server1 (or server2) by IP instead of name.

1. I am connecting to the ADAM server using it's IP address instead of its name; and

2. I am connecting

This sounds like a classic Kerberos delegation problem, but you confuse me when you say you are using Digest auth.  Are you sure?

The reason I say that this sounds like a classic Kerberos delegation issue is that with Kerberos authentication, the SPN is normally tied to the NetBIOS and DNS name of the service, so if you use an IP address for the server name Kerberos breaks.  As such, your result to totally expected in a scenario where you depend on Kerberos authentication working which you would have if you were delegating.

So, the confusing piece is the Digest auth part, as you can't do Kerberos delegation when the service being delegated to is not accessed via Kerberos auth.

Hi Joe, thanks for replying.  You were right (as usual, sigh...).  I was connecting to ADAM using AuthType=Negotiate, which would have resulted in Kerberos.  So not being able to connect to an IP address (or a NLB logical computer name) makes perfect sense.

I don't understand why I didn't get an error when I did connection.Bind, but instead got the error when I tried to use the connection in a query.

Also leaves me a bit stranded trying to connect to ADAM on a cluster using a Windows account.  Looks like I might have to ignore the cluster name and just try each of the servers in the cluster myself, until I get one that replies.

Load balancing of Kerberos services is possible.  What you need to do is run the service as a fixed domain account instead of network service and then publish all SPNs for the service to that service account in AD instead of the computer account.  You also then need to use a DNS name to hit this cluster IP address so it will match with an SPN.

Definitely possible although a little painful.

If you need to delegate, you have to do this.

If you don't need to delegate, then you can use NTLM and it won't matter.

It is possible as Joe says.  We actually had to do this some time ago.  You have to register the VIP into AD and add an SPN for that account.  Once AD can see it as a resource, calls to the VIP will be able to be delegated as you will have the proper SPN for delegation.  The trick is that for load balancing, all the nodes need to run under the same SPN.  This is not possible of course when using delegation as you would have duplicate SPNs (which is verboten).  To get around this, you instead register the load balancer or cluster in AD and assign the SPN to this device or service.  How you do this depends on the device and/or service.  This way, the 'cluster' has the SPN and you don't have the duplicate SPN problem.

Thanks Guys.

And again you are correct.  I've switched my ADAM services to run as a domain account (same account used on both cluster nodes) and registered SPNs for the cluster name against that account.  This allows my client to connect to ADAM using the cluster name (with the expected failover support that the cluster provides), using Kerberos.  Exactly what I needed.

Cheers
PEvans

That's very cool.  Kerb auth can be very mysterious and hard to troubleshoot, so I'm glad you got it working quickly.

If these two servers replicate (not sure if that's how it works in a cluster scenario), make sure the auth changes you made didn't break replication.