Discussion:
Kerberos Error Getting Ticket From Domain: krb5kdc_err_s_principal_unknown
(too old to reply)
Will
2006-06-23 07:34:52 UTC
Permalink
Member server A is contacting domain controller my-dc1 in domain
hq.corp.com. What I am seeing in the sniffer trace is that the member
server asks the my-dc1 domain controller in its role as a Kerberos ticket
granter for a ticket to the domain (i.e., krbtgt/hq.corp.com). The domain
controller is returning krb5kdc_err_s_principal_unknown. That can't be
good? What is the expected result when a member server asks for a ticket
for the entire domain?

The following line in the trace shows the member server asking for the
Kerberos ticket for the domain controller krbtgt/my-dc1 and this it does
obtain.

What would cause the domain controller to not recognize its own domain in
the Kerberos ticket request?
--
Will
Roger Abell [MVP]
2006-06-24 09:25:01 UTC
Permalink
From what you have said it sounds like you are misinterpreting what is
happening. It is not that the DC is not recognizing the domain, but that
it is not recognizing the machine as a member of the domain, and hence
it is not granting a TGT to it. This might be because the join has problems
or perhaps the times are too far out of sync.
Post by Will
Member server A is contacting domain controller my-dc1 in domain
hq.corp.com. What I am seeing in the sniffer trace is that the member
server asks the my-dc1 domain controller in its role as a Kerberos ticket
granter for a ticket to the domain (i.e., krbtgt/hq.corp.com). The domain
controller is returning krb5kdc_err_s_principal_unknown. That can't be
good? What is the expected result when a member server asks for a ticket
for the entire domain?
The following line in the trace shows the member server asking for the
Kerberos ticket for the domain controller krbtgt/my-dc1 and this it does
obtain.
What would cause the domain controller to not recognize its own domain in
the Kerberos ticket request?
--
Will
Will
2006-06-26 23:07:26 UTC
Permalink
But then how do you explain that the same member server asks for a ticket
using the domain controller's name (krbtgt/my-dc1) and succeeds? Requests
using the domain fail. Requests by the same member server for the domain
controller succeed. And I'm probably wording this incorrectly. I guess
what the member server is asking for is a ticket that grants it a right to
converse and ask services from the domain controller?

In any case, if the machine is not recognized as a member of the domain,
then how is it that domain logins are working, and how is it that the member
server is able to use file shares on the domain controller?
--
Will
Post by Roger Abell [MVP]
From what you have said it sounds like you are misinterpreting what is
happening. It is not that the DC is not recognizing the domain, but that
it is not recognizing the machine as a member of the domain, and hence
it is not granting a TGT to it. This might be because the join has problems
or perhaps the times are too far out of sync.
Post by Will
Member server A is contacting domain controller my-dc1 in domain
hq.corp.com. What I am seeing in the sniffer trace is that the member
server asks the my-dc1 domain controller in its role as a Kerberos ticket
granter for a ticket to the domain (i.e., krbtgt/hq.corp.com). The domain
controller is returning krb5kdc_err_s_principal_unknown. That can't be
good? What is the expected result when a member server asks for a ticket
for the entire domain?
The following line in the trace shows the member server asking for the
Kerberos ticket for the domain controller krbtgt/my-dc1 and this it does
obtain.
What would cause the domain controller to not recognize its own domain in
the Kerberos ticket request?
--
Will
Roger Abell [MVP]
2006-06-27 13:36:48 UTC
Permalink
Post by Will
But then how do you explain that the same member server asks for a ticket
using the domain controller's name (krbtgt/my-dc1) and succeeds?
Requests
using the domain fail. Requests by the same member server for the domain
"from" the domain controller, not "for" - small point, but it would be
trying for a host/my-dc1 ticket if it were for my-dc1
Post by Will
controller succeed. And I'm probably wording this incorrectly. I guess
what the member server is asking for is a ticket that grants it a right to
converse and ask services from the domain controller?
Yes, the tgt could be so described.
Post by Will
In any case, if the machine is not recognized as a member of the domain,
then how is it that domain logins are working, and how is it that the member
server is able to use file shares on the domain controller?
I was previously responding with best guess given the provided info.
Is the domain name DNS resolvable (should point to the DCs), and
is there an spn registered for the the domain-name ?? If those are
not satisfied then attempt to use that service name to get tgt would not
be able to work.
Post by Will
Post by Roger Abell [MVP]
From what you have said it sounds like you are misinterpreting what is
happening. It is not that the DC is not recognizing the domain, but that
it is not recognizing the machine as a member of the domain, and hence
it is not granting a TGT to it. This might be because the join has
problems
Post by Roger Abell [MVP]
or perhaps the times are too far out of sync.
Post by Will
Member server A is contacting domain controller my-dc1 in domain
hq.corp.com. What I am seeing in the sniffer trace is that the member
server asks the my-dc1 domain controller in its role as a Kerberos
ticket
Post by Roger Abell [MVP]
Post by Will
granter for a ticket to the domain (i.e., krbtgt/hq.corp.com). The domain
controller is returning krb5kdc_err_s_principal_unknown. That can't be
good? What is the expected result when a member server asks for a
ticket
Post by Roger Abell [MVP]
Post by Will
for the entire domain?
The following line in the trace shows the member server asking for the
Kerberos ticket for the domain controller krbtgt/my-dc1 and this it does
obtain.
What would cause the domain controller to not recognize its own domain
in
Post by Roger Abell [MVP]
Post by Will
the Kerberos ticket request?
--
Will
Will
2006-06-30 06:18:21 UTC
Permalink
Post by Roger Abell [MVP]
Post by Will
In any case, if the machine is not recognized as a member of the domain,
then how is it that domain logins are working, and how is it that the member
server is able to use file shares on the domain controller?
I was previously responding with best guess given the provided info.
Is the domain name DNS resolvable (should point to the DCs), and
is there an spn registered for the the domain-name ?? If those are
not satisfied then attempt to use that service name to get tgt would not
be able to work.
How do I check for an SPN for the domain name?

NSLOOKUP on the domain name does produce the IPs of the domain controllers.
--
Will
Roger Abell [MVP]
2006-07-02 15:28:47 UTC
Permalink
netlogon or dnslint are the tools for checking whether DCs' DNS
records are correct - there is much more to it than just seeing if
the DCs' names can be resolved to IPs.
setspn can be used to see the existing SPNs and dcdiag is base
tool for checking health of DC availability
Post by Will
Post by Roger Abell [MVP]
Post by Will
In any case, if the machine is not recognized as a member of the domain,
then how is it that domain logins are working, and how is it that the member
server is able to use file shares on the domain controller?
I was previously responding with best guess given the provided info.
Is the domain name DNS resolvable (should point to the DCs), and
is there an spn registered for the the domain-name ?? If those are
not satisfied then attempt to use that service name to get tgt would not
be able to work.
How do I check for an SPN for the domain name?
NSLOOKUP on the domain name does produce the IPs of the domain
controllers.
--
Will
Will
2006-07-06 06:13:15 UTC
Permalink
I used all of the checks in DNSLINT on both domain controllers, and those
did not turn up any errors. Those did not name an "SPN" however.

I ran NetDiag /v and that turned up nothing.

Dcdiag /v didn't turn up errors either.

I looked at Setspn, but that seems fairly trivial and didn't really do much
diagnostics. When I ran the argument to verify the SPN it gave strange
messages that it didn't recognize the domain, so maybe there is a problem
there. The error messages were poor so I can't really tell if I got the
syntax wrong, or if there is a DNS record problem.

Can you describe what an SPN record for the domain should look like, and how
do I locate it in the DNS tree, or in ADSIEDIT, or whatever else I would
look in to check it manually?
--
Will
Post by Roger Abell [MVP]
netlogon or dnslint are the tools for checking whether DCs' DNS
records are correct - there is much more to it than just seeing if
the DCs' names can be resolved to IPs.
setspn can be used to see the existing SPNs and dcdiag is base
tool for checking health of DC availability
Post by Will
Post by Roger Abell [MVP]
Post by Will
In any case, if the machine is not recognized as a member of the domain,
then how is it that domain logins are working, and how is it that the member
server is able to use file shares on the domain controller?
I was previously responding with best guess given the provided info.
Is the domain name DNS resolvable (should point to the DCs), and
is there an spn registered for the the domain-name ?? If those are
not satisfied then attempt to use that service name to get tgt would not
be able to work.
How do I check for an SPN for the domain name?
NSLOOKUP on the domain name does produce the IPs of the domain controllers.
--
Will
Loading...