Need Help Understanding Kerberos SPN Problem

[Will]

I either don't understand how to use SETSPN, or I have some serious problem
with Kerberos in our domain. For a domain hq.corp.com and a domain
controller my-dc1, the following SETSPN commands executed at the console of
the domain controller are returning errors indicating the account doesn't
exist:

SETSPN -L hq.corp.com
SETSPN -L my-dc1

I've read the Microsoft documents on troubleshooting Kerberos, and I don't
understand SPNs any better after reading those than I did before. They
talk about SPNs in some very vague way and they don't give examples to tie
SPNs together concretely with objects you see in the actual AD management
applications.

I see the special reserved user account krbtgt, and I gather this is an SPN?

I'm getting krb5kdc_err_s_principal_unknown errors on some member servers
when they request a Kerberos host/hq.corp.com ticket.

I don't understand if member servers should be getting the host/<domain>
ticket.
I don't understand why they need it or how they use it.
I don't understand what the implications are if they don't get this ticket.
I don't understand how this relates to SPNs.
I don't understand how to investigate the cause of this.
I don't understand how to fix it.

Mostly, I don't understand. :)

Any help in understanding if we have a problem here is appreciated.

[Al Mulnick]

First things first. I see this is not the first time you've posted this.

See:
http://groups.google.com/group/comp.protocols.kerberos/browse_thread/thread/b43445ec98f2eba1/7fc0cf8c08c03540?lnk=st&q=krb5kdc_err_s_principal_unknown+site%3Amicrosoft.com&rnum=2&hl=en#7fc0cf8c08c03540
And so I figure you're probably spending a while troubleshooting this. If I
understand this correctly, your troubleshooting started when you had some
machines that couldn't get GPO applied properly. Some suggestions were made
to try removing those machines from the domain and re-adding them in the
hopes that their computer account somehow got messed up. What were the
results of that?

Paul's advice is sound: "For standard Microsoft applications you should not
have to create any SPNs
manually, using Setspn. Once in a while you may find that the DC indicates
that an SPN exits for a member machine, but you really can't use Kerberos to
authenticate to the machine. This is usually fixed by removing the machine
from the domain, rebooting, and rejoining the machine to the domain."

In addition, this is almost always a problem with either the machine account
or name resolution vs. SPN's unless you've done something really odd. To
check, the best way is to use DCDIAG on the domain controller and check the
output.

As for SPN's, if you have not already read this, take a moment and look it
over.
http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAServicePrincipalNameSPN.html

Al

Post by Will
I either don't understand how to use SETSPN, or I have some serious problem
with Kerberos in our domain. For a domain hq.corp.com and a domain
controller my-dc1, the following SETSPN commands executed at the console of
the domain controller are returning errors indicating the account doesn't
SETSPN -L hq.corp.com
SETSPN -L my-dc1
I've read the Microsoft documents on troubleshooting Kerberos, and I don't
understand SPNs any better after reading those than I did before. They
talk about SPNs in some very vague way and they don't give examples to tie
SPNs together concretely with objects you see in the actual AD management
applications.
I see the special reserved user account krbtgt, and I gather this is an SPN?
I'm getting krb5kdc_err_s_principal_unknown errors on some member servers
when they request a Kerberos host/hq.corp.com ticket.
I don't understand if member servers should be getting the host/<domain>
ticket.
I don't understand why they need it or how they use it.
I don't understand what the implications are if they don't get this ticket.
I don't understand how this relates to SPNs.
I don't understand how to investigate the cause of this.
I don't understand how to fix it.
Mostly, I don't understand. :)
Any help in understanding if we have a problem here is appreciated.
--
Will

[Joe Richards [MVP]]

You really shouldn't have to mess with SPNs in a normal course of
events. Usually it is required if you add new services or someone has
been dorking around with AD objects and don't know what they are doing.

Your first command where you try to get the SPNs for the domain
shouldn't work. The second one should work and if doesn't it could
indicate some issues. Download adfind and then run the following command
and post the results

adfind -gc -b -f name=my-dc1 serviceprincipalname

As for the rest of your questions, I recommend picking up the O'Reilly
kerberos book. Without a background in kerberos it is tough to
understand what the point of SPNs are.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

============================================================================
Do not read this worthless blog entry on
Defending Security Infrastructures http://blog.joeware.net/2006/07/11/445/
I'm serious, you will learn absolutely nothing about
Defending Security Infrastructures.
============================================================================

Post by Will
I either don't understand how to use SETSPN, or I have some serious problem
with Kerberos in our domain. For a domain hq.corp.com and a domain
controller my-dc1, the following SETSPN commands executed at the console of
the domain controller are returning errors indicating the account doesn't
SETSPN -L hq.corp.com
SETSPN -L my-dc1
I've read the Microsoft documents on troubleshooting Kerberos, and I don't
understand SPNs any better after reading those than I did before. They
talk about SPNs in some very vague way and they don't give examples to tie
SPNs together concretely with objects you see in the actual AD management
applications.
I see the special reserved user account krbtgt, and I gather this is an SPN?
I'm getting krb5kdc_err_s_principal_unknown errors on some member servers
when they request a Kerberos host/hq.corp.com ticket.
I don't understand if member servers should be getting the host/<domain>
ticket.
I don't understand why they need it or how they use it.
I don't understand what the implications are if they don't get this ticket.
I don't understand how this relates to SPNs.
I don't understand how to investigate the cause of this.
I don't understand how to fix it.
Mostly, I don't understand. :)
Any help in understanding if we have a problem here is appreciated.

[Will]

Post by Joe Richards [MVP]
Your first command where you try to get the SPNs for the domain
shouldn't work.

Which leads to the question why are the member servers asking for
HOST/<domain> tickets that by design they should never be able to get?

Post by Joe Richards [MVP]
The second one should work and if doesn't it could
indicate some issues. Download adfind and then run the following command
and post the results
adfind -gc -b -f name=my-dc1 serviceprincipalname

I posted the output - with names changed to the original example and
preserving capitalization where it occurs - below my signature.
--
Will



[c:\util]adfind -gc -b -f name=my-dc1 serviceprincipalname

AdFind V01.27.00cpp Joe Richards (***@joeware.net) November 2005

Using server: my-dc1.hq.corp.com:3268
Directory: Windows 2000

dn:CN=my-dc1,CN=Servers,CN=CORP-Domain,CN=Sites,CN=Configuration,DC=hq,DC=co
rp,DC=com

dn:CN=my-dc1,OU=Domain Controllers,DC=hq,DC=corp,DC=com

Post by Joe Richards [MVP]
servicePrincipalName: DNS/my-dc1.hq.corp.com

NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/my-dc1.hq.corp.com

Post by Joe Richards [MVP]
servicePrincipalName: GC/my-dc1.hq.corp.com/hq.corp.com
servicePrincipalName: HOST/my-dc1.hq.corp.com/CORP
servicePrincipalName: HOST/MY-DC1
servicePrincipalName: HOST/my-dc1.hq.corp.com
servicePrincipalName: HOST/my-dc1.hq.corp.com/hq.corp.com

E3514235-4B06-11D1-AB04-00C04FC2DCD2/6c1d6a59-1c7c-43bf-be94-1b531062d7b5/hq
.corp.com
LDAP/6c1d6a59-1c7c-43bf-be94-1b531062d7b5._msdcs.hq.corp.com

Post by Joe Richards [MVP]
servicePrincipalName: LDAP/my-dc1.hq.corp.com/CORP
servicePrincipalName: LDAP/MY-DC1
servicePrincipalName: LDAP/my-dc1.hq.corp.com
servicePrincipalName: LDAP/my-dc1.hq.corp.com/hq.corp.com

dn:CN=my-dc1,CN=Domain System Volume (SYSVOL share),CN=File Replication
Service,CN=System,DC=hq,DC=corp,DC=com

dn:DC=my-dc1,DC=hq.corp.com,CN=MicrosoftDNS,CN=System,DC=hq,DC=corp,DC=com

dn:CN=my-dc1,CN=NTDS
Settings,CN=MY-DC2,CN=Servers,CN=CORP-Domain,CN=Sites,CN=Configuration,DC=hq
,DC=corp,DC=com


5 Objects returned

[Joe Richards [MVP]]

So the SPNs are there, I would run a network trace when running your
SETSPN command for the DC name and see where the failure is. Possibly it
is hitting another machine where the SPNs aren't indicating a
replication issue or possibly it isn't getting to the DC which could be
all sorts of issues. We could guess lots of things, best to get a trace
and actually see for sure what SETSPN is or isn't getting.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

============================================================================
Do not read this worthless blog entry on
Defending Security Infrastructures http://blog.joeware.net/2006/07/11/445/
I'm serious, you will learn absolutely nothing about
Defending Security Infrastructures.
============================================================================

Post by Will

Post by Joe Richards [MVP]
Your first command where you try to get the SPNs for the domain
shouldn't work.

Which leads to the question why are the member servers asking for
HOST/<domain> tickets that by design they should never be able to get?

Post by Joe Richards [MVP]
The second one should work and if doesn't it could
indicate some issues. Download adfind and then run the following command
and post the results
adfind -gc -b -f name=my-dc1 serviceprincipalname

I posted the output - with names changed to the original example and
preserving capitalization where it occurs - below my signature.

[Will]

Post by Joe Richards [MVP]
So the SPNs are there, I would run a network trace when running your
SETSPN command for the DC name and see where the failure is. Possibly it
is hitting another machine where the SPNs aren't indicating a
replication issue or possibly it isn't getting to the DC which could be
all sorts of issues. We could guess lots of things, best to get a trace
and actually see for sure what SETSPN is or isn't getting.

I tried your adfind on the other domain controller (using the -h argument to
target it) and it is failing right away claiming that the LDAP server is
down:

LDAP_BIND: ... Error 0x51 (81) - Server Down

Now that's an interesting result maybe. I ran over to that domain
controller, and dcdiag /v doesn't show anything failing of interest (dhcp
and distributed link tracking server services are stopped).

Where can I get a list of services that should be running on a DC, and I can
compare against that list on the machine that won't work with adfind.

Would this error be caused if we didn't have a copy of the global catalog on
the second DC? If yes, how do I make a copy on that DC?

[Joe Richards [MVP]]

Yes that adfind command requires a GC, to run it against a non-GC use

adfind -h servername -default -f name=my-dc1 serviceprincipalname

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

============================================================================
Do not read this worthless blog entry on
Defending Security Infrastructures http://blog.joeware.net/2006/07/11/445/
I'm serious, you will learn absolutely nothing about
Defending Security Infrastructures.
============================================================================

Post by Will

Post by Joe Richards [MVP]
So the SPNs are there, I would run a network trace when running your
SETSPN command for the DC name and see where the failure is. Possibly it
is hitting another machine where the SPNs aren't indicating a
replication issue or possibly it isn't getting to the DC which could be
all sorts of issues. We could guess lots of things, best to get a trace
and actually see for sure what SETSPN is or isn't getting.

I tried your adfind on the other domain controller (using the -h argument to
target it) and it is failing right away claiming that the LDAP server is
LDAP_BIND: ... Error 0x51 (81) - Server Down
Now that's an interesting result maybe. I ran over to that domain
controller, and dcdiag /v doesn't show anything failing of interest (dhcp
and distributed link tracking server services are stopped).
Where can I get a list of services that should be running on a DC, and I can
compare against that list on the machine that won't work with adfind.
Would this error be caused if we didn't have a copy of the global catalog on
the second DC? If yes, how do I make a copy on that DC?

[Will]

Post by Joe Richards [MVP]
Yes that adfind command requires a GC, to run it against a non-GC use
adfind -h servername -default -f name=my-dc1 serviceprincipalname

Is the error:

LDAP_BIND: ... Error 0x51 (81) - Server Down

the expected result when you point with the -gc argument at a server with no
global catalog?

[Joe Richards [MVP]]

Yes because the port isn't there. When you see a message of server down
with an application that uses a specific port, the port not responding
is a server down to the clients. Alternately consider that the LDAP
Server Service runs on a machine, so if the port doesn't respond, that
server on that machine is down.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

============================================================================
Do not read this worthless blog entry on
Defending Security Infrastructures http://blog.joeware.net/2006/07/11/445/
I'm serious, you will learn absolutely nothing about
Defending Security Infrastructures.
============================================================================

Post by Will

Post by Joe Richards [MVP]
Yes that adfind command requires a GC, to run it against a non-GC use
adfind -h servername -default -f name=my-dc1 serviceprincipalname

LDAP_BIND: ... Error 0x51 (81) - Server Down
the expected result when you point with the -gc argument at a server with no
global catalog?

[Will]

Post by Joe Richards [MVP]
Yes because the port isn't there. When you see a message of server down
with an application that uses a specific port, the port not responding
is a server down to the clients. Alternately consider that the LDAP
Server Service runs on a machine, so if the port doesn't respond, that
server on that machine is down.

I'm not getting the big picture at all, sorry. LDAP only runs on the
domain controllers that have the global catalog? I thought LDAP was the
standard protocol to access any directory information at all on any domain
controller?

[Al Mulnick]

No, LDAP runs on both (listener on 389 tcp). A GC also listens on the
additional 3268 tcp.

Any luck with that dcdiag? Haven't seen any results posted.

Post by Will

Post by Joe Richards [MVP]
Yes because the port isn't there. When you see a message of server down
with an application that uses a specific port, the port not responding
is a server down to the clients. Alternately consider that the LDAP
Server Service runs on a machine, so if the port doesn't respond, that
server on that machine is down.

I'm not getting the big picture at all, sorry. LDAP only runs on the
domain controllers that have the global catalog? I thought LDAP was the
standard protocol to access any directory information at all on any domain
controller?
--
Will

[Will]

Post by Al Mulnick
No, LDAP runs on both (listener on 389 tcp). A GC also listens on the
additional 3268 tcp.
Any luck with that dcdiag? Haven't seen any results posted.

DCDIAG doesn't show any errors except that the link tracking server and dhcp
service are stopped. Everything else passes.

[Joe Richards [MVP]]

No it runs on all domain controllers. However on GCs it listens for LDAP
requests on two additional ports, 3268 and 3269. This is to support GC
requests and GC SSL requests. Normal LDAP requests go to 389 or 636
which are LDAP and LDAPS (SSL).

The GC switch on adfind tells it to use the global catalog port so it
tries to connect to the servers port 3268. If the machine isn't a GC,
that port won't be listening.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

============================================================================
Do not read this worthless blog entry on
Defending Security Infrastructures http://blog.joeware.net/2006/07/11/445/
I'm serious, you will learn absolutely nothing about
Defending Security Infrastructures.
============================================================================

Post by Will

Post by Joe Richards [MVP]
Yes because the port isn't there. When you see a message of server down
with an application that uses a specific port, the port not responding
is a server down to the clients. Alternately consider that the LDAP
Server Service runs on a machine, so if the port doesn't respond, that
server on that machine is down.

I'm not getting the big picture at all, sorry. LDAP only runs on the
domain controllers that have the global catalog? I thought LDAP was the
standard protocol to access any directory information at all on any domain
controller?