Kerberos Error Getting Ticket From Domain: krb5kdc_err_s_principal_unknown

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

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.

"Will" <westes-usc@noemail.nospam> wrote in message
news:w4WdnfD8c87mBAbZnZ2dnUVZ_sWdnZ2d@giganews.com...
> 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
>
>

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


"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:emwhPA3lGHA.3732@TK2MSFTNGP05.phx.gbl...
> 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.
>
> "Will" <westes-usc@noemail.nospam> wrote in message
> news:w4WdnfD8c87mBAbZnZ2dnUVZ_sWdnZ2d@giganews.com...
> > 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" <westes-usc@noemail.nospam> wrote in message
news:Oeqdndm87pkR9T3ZnZ2dnUVZ_ridnZ2d@giganews.com...
> 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

> 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.

> 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.
>
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:emwhPA3lGHA.3732@TK2MSFTNGP05.phx.gbl...
>> 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.
>>
>> "Will" <westes-usc@noemail.nospam> wrote in message
>> news:w4WdnfD8c87mBAbZnZ2dnUVZ_sWdnZ2d@giganews.com...
>> > 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]" <mvpNoSpam@asu.edu> wrote in message
news:uOfm96emGHA.3880@TK2MSFTNGP02.phx.gbl...
> > 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

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

"Will" <westes-usc@noemail.nospam> wrote in message
news:KKGdnRk7DJmRXznZnZ2dnUVZ_s2dnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:uOfm96emGHA.3880@TK2MSFTNGP02.phx.gbl...
>> > 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
>
>
>

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


"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:ureE1wenGHA.1444@TK2MSFTNGP02.phx.gbl...
> 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
>
> "Will" <westes-usc@noemail.nospam> wrote in message
> news:KKGdnRk7DJmRXznZnZ2dnUVZ_s2dnZ2d@giganews.com...
> > "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> > news:uOfm96emGHA.3880@TK2MSFTNGP02.phx.gbl...
> >> > 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