ADAM Kerberos Authentication issue and missing SPNs

Hi,

I'm hoping someone can help me with a difficult Kerberos authentication failure with Microsoft ADAM (and AD LDS). I think it's a bug to do with Kerberos SPNs and it's very easy to reproduce.

This problem only happens on a server whos computer fqdn ends in a dot. Unusual I know but we have customers set up like this so I need a workaround for it. ( I have to deal with Murphy's Law!).

My Server is Windows Server 2003 (called SERVER1) and it is joined to an AD domain (called DOMAIN1).

To reproduce this problem I do the following:

In "Control Panel > System > Computer Name > Change > More > Primary DNS suffix of this computer:" I set the suffix to "domain1.int." (note the dot at the end of this name).

Computername: SERVER1
Domain: DOMAIN1
Computer FQDN: server1.domain1.int. (note this ends in a dot).

I install an ADAM instance using all defaults then using LDP.EXE do:

"Connect > Connection" and specify "localhost". This works. It shows the dnsHostName attribute value as "server1.domain1.int.".
"Connection > Bind... > Bind as currently logged on user". This fails with:


0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 0)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
{NtAuthIdentity: User='NULL'; Pwd= <unavailable>; domain = 'NULL'.}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: 8009030C: LdapErr: DSID-0C090441, comment: AcceptSecurityContext error, data 52e, vece
Error 0x8009030C The logon attempt failed

Note that if I specify 127.0.0.1 instead of localhost in the LDP Connect, the bind works. Also if my server fqdn name does not end in a dot it also works.

localhost resolves to "server1.domain1.int." ending in a dot.

127.0.0.1 is the only thing that works. Specifying the NETBIOS name or the fgdn of the server also fails.

Note that if when installing the ADAM instance, you also specify that you want the LDIF files to be loaded then the installer fails to do this puttuing up a
prompt for credentials which you can't get past. This allows the problem to be reproduced even without using LDP.

I think the bug is to do with the ADAM installer not setting up the SPNs correctly in this situation. I'd like to implement a workaround when I detect that the fqdn ends in a dot by setting up the appropriate SPNs in my installer with setspn.exe before running the ADAM installer.

I have tried the following setspn commands to add the proper fqdn SPNs before installing the ADAM instance but so far I still haven't been able to get this to work. I will actually use DsWriteAccountSpn() from an installer
DLL to do this but I want to verify the workaround first with setspn.exe.

setspn -A host/server1.domain1.int SERVER1
setspn -A host/server1.domain1.int. SERVER1
setspn -A ldap/server1.domain1.int SERVER1
setspn -A ldap/server1.domain1.int. SERVER1
setspn -A ldap/server1. SERVER1
setspn -A ldap/server1.:389 SERVER1
setspn -A ldap/server1.domain1.int.:389 SERVER1

I know for replication I will also need E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM SPNs but I've left those out for now.

I have verified that these SPNs do get updated in the machine's Computer account in AD and that "setspn -L SERVER1" lists them.

I'm sure I'm on the right lines with this but probably because I'm doing something wrong here it still isn't working.

"ping localhost" shows that localhost resolves to "server1.domain1.int.".

We use ADAM as part of our product and have a great experience with it so I'm really hoping I can find the workaround to this problem.

If anyone has any ideas on how to trace this to perhaps see what the missing SPN entry is, that'd also be helpful. I've set all the registry "Diagnostics" values to 5 to get Event Log tracing, but that hasn't heped me.

Thanks!

Mark.

Any error in the record interesting events related to the lack of authentication? This seems more a problem of preventing a problem of ADAM, but it's hard to say. The other thing I probably would try to do is get network trace LDAP traffic for traffic generated in running order of the protocol, namely the service ticket request to the LDAP server associated with the operation link. This could help explain what is happening. It is also possible that the error is in the Windows LDAP client in terms of how it is conducting negotiations authorities during the binding operation, but who really knows.

Interestingly I got 8009030C on W2003 from accidentally trying to verify the same Kerberos ticket twice. Obviously this should not happen in the normal course of events, but it's one response to look out for if your writing Kerberized applications since it could mean someone else has stolen the Kerberos ticket and already verified it in place of the intended user...