Need Help Understanding Kerberos SPN Problem
Will
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.
--
Will
Al Mulnick
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
"Will" <DELETE...@earthbroadcast.com> wrote in message
news:46SdnXOsoO6opiTZ...@giganews.com...
Joe Richards [MVP]
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.
============================================================================
Will
news:OcZBgtFq...@TK2MSFTNGP03.phx.gbl...
> 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?
>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 (j...@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
>servicePrincipalName: DNS/my-dc1.hq.corp.com
>servicePrincipalName:
NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/my-dc1.hq.corp.com
>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
>servicePrincipalName:
E3514235-4B06-11D1-AB04-00C04FC2DCD2/6c1d6a59-1c7c-43bf-be94-1b531062d7b5/hq
.corp.com
>servicePrincipalName:
LDAP/6c1d6a59-1c7c-43bf-be94-1b531062d7b5._msdcs.hq.corp.com
>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]
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.
============================================================================
Will
> 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?
--
Will
Joe Richards [MVP]
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.
============================================================================
Will
> 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?
--
Will
Joe Richards [MVP]
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.
============================================================================
Will
> 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
Al Mulnick
additional 3268 tcp.
Any luck with that dcdiag? Haven't seen any results posted.
"Will" <DELETE...@earthbroadcast.com> wrote in message
news:P5mdnVq6EuNrOifZ...@giganews.com...
Joe Richards [MVP]
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.
============================================================================
Will
news:OJHU81Sq...@TK2MSFTNGP04.phx.gbl...
> 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.
--
Will