krb5kdc_err_s_principal_unknown on Windows Kerberos Domain
Will
used with a Windows 2000 or Windows 2003 member server. I would appreciate
some help in understanding this situation from experienced Kerberos admins
who happen to also have deep Windows experience.
A sniffer trace of our Windows domain member servers shows the member
servers are succeeding in getting tickets from the domain controller for the
domain controller's host ticket, but failing to get tickets for the domain
itself.
By example, member server A is contacting domain controller my-dc1 in
Windows domain hq.corp.com. What I am seeing in the sniffer trace is that
the member server A 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. The following line in the trace shows the
same member server A asking my-dc1 for the Kerberos ticket for the domain
controller krbtgt/my-dc1 and this member server A does obtain.
First, I want to understand what does this failure mean? I saw many
sniffer traces posted on Google that show the same sequence for other
Windows domains, so apparently it's a common case.
Second, how do I correct this problem? Someone else told me to create an
SPN for the domain with SetSPN, but I would like to a) get help determining
if we already have such an SPN, b) I would like to understand better what it
is I am creating when I create an SPN, how an SPN is used by member servers,
and what are the effects we are suffering if we don't have an SPN.
Any other ideas on what is causing the krb5kdc_err_s_principal_unknown error
are appreciated.
--
Will
Richard E. Silverman
Will> I may be having problems with Kerberos on a Windows 2000 domain
Will> controller, used with a Windows 2000 or Windows 2003 member
Will> server. I would appreciate some help in understanding this
Will> situation from experienced Kerberos admins who happen to also
Will> have deep Windows experience.
Will> A sniffer trace of our Windows domain member servers shows the
Will> member servers are succeeding in getting tickets from the domain
Will> controller for the domain controller's host ticket, but failing
Will> to get tickets for the domain itself.
Will> By example, member server A is contacting domain controller
Will> my-dc1 in Windows domain hq.corp.com. What I am seeing in the
Will> sniffer trace is that the member server A asks the my-dc1 domain
Will> controller in its role as a Kerberos ticket granter for a ticket
Will> to the domain (i.e., krbtgt/hq.corp.com).
Is the realm in the request also correct?
Will> The domain controller is returning krb5kdc_err_s_principal_unknown.
That sounds as if someone deleted the "krbtgt" user from the domain.
--
Richard Silverman
r...@qoxp.net
Will
"Richard E. Silverman" <r...@qoxp.net> wrote in message
news:m2slldf...@darwin.oankali.net...
> Will> By example, member server A is contacting domain controller
> Will> my-dc1 in Windows domain hq.corp.com. What I am seeing in the
> Will> sniffer trace is that the member server A asks the my-dc1 domain
> Will> controller in its role as a Kerberos ticket granter for a ticket
> Will> to the domain (i.e., krbtgt/hq.corp.com).
>
> Is the realm in the request also correct?
I'm not a Kerberos person, so I don't understand the question. Are you
asking if the is the Windows domain name being spelled correctly? The
answer to that would be yes.
> Will> The domain controller is returning
krb5kdc_err_s_principal_unknown.
>
> That sounds as if someone deleted the "krbtgt" user from the domain.
I checked, and the krbtgt user is in the Users and Computer application for
the domain. It shows as disabled, but a check online confirmed that this
is its only state and cannot in fact be enabled because it is never used for
interactive logins.
Any other ideas?
--
Will
Richard E. Silverman
Will> "Richard E. Silverman" <r...@qoxp.net> wrote in message
Will> news:m2slldf...@darwin.oankali.net... By example, member
Will> server A is contacting domain controller my-dc1 in Windows
Will> domain hq.corp.com. What I am seeing in the sniffer trace is
Will> that the member server A asks the my-dc1 domain controller in
Will> its role as a Kerberos ticket granter for a ticket to the domain
Will> (i.e., krbtgt/hq.corp.com).
>> Is the realm in the request also correct?
Will> I'm not a Kerberos person, so I don't understand the question.
Will> Are you asking if the is the Windows domain name being spelled
Will> correctly? The answer to that would be yes.
No; the full principal name should be (I guess)
krbtgt/hq.co...@HQ.CORP.COM; the final part is the Kerberos "realm."
It may not be represented this way in the network trace, but there should
be a "realm" part of the data structure nearby.
Will> The domain controller is returning
Will> krb5kdc_err_s_principal_unknown.
>> That sounds as if someone deleted the "krbtgt" user from the
>> domain.
Will> I checked, and the krbtgt user is in the Users and Computer
Will> application for the domain. It shows as disabled, but a check
Will> online confirmed that this is its only state and cannot in fact
Will> be enabled because it is never used for interactive logins.
Will> Any other ideas?
Will> -- Will
--
Richard Silverman
r...@qoxp.net
Will
> >>>>> "Will" == Will <DELETE...@earthbroadcast.com> writes:
> Will> "Richard E. Silverman" <r...@qoxp.net> wrote in message
> Will> news:m2slldf...@darwin.oankali.net... By example, member
> Will> server A is contacting domain controller my-dc1 in Windows
> Will> domain hq.corp.com. What I am seeing in the sniffer trace is
> Will> that the member server A asks the my-dc1 domain controller in
> Will> its role as a Kerberos ticket granter for a ticket to the domain
> Will> (i.e., krbtgt/hq.corp.com).
> >> Is the realm in the request also correct?
>
> Will> I'm not a Kerberos person, so I don't understand the question.
> Will> Are you asking if the is the Windows domain name being spelled
> Will> correctly? The answer to that would be yes.
>
> No; the full principal name should be (I guess)
> krbtgt/hq.co...@HQ.CORP.COM; the final part is the Kerberos "realm."
> It may not be represented this way in the network trace, but there should
> be a "realm" part of the data structure nearby.
In a sniffer trace, the REALM: parameter is filled in as HQ.CORP.COM, so
apparently it is correct.
I looked more carefully, and it looks like your original guess is still on
the right track. The request for the following is succeeding:
krbtgt/hq.corp.com
The request for the following is failing:
HOST/hq.corp.com
And there is no userid named "Host" on the domain controller which is the
ticket granting server. Any idea on why kerberos client is asking for
this HOST record, and is it a normal thing for it to ask for such a record
for the realm itself and fail?
--
Will
Richard E. Silverman
There wouldn't be; there would be a user or computer account named
"hq.corp.com", corresponding to a host having that name.
--
Richard Silverman
r...@qoxp.net
Will
>>Will said:
> > I looked more carefully, and it looks like your original guess is still
on
> > the right track. The request for the following is succeeding:
> >
> > krbtgt/hq.corp.com
> >
> > The request for the following is failing:
> >
> > HOST/hq.corp.com
> >
> > And there is no userid named "Host" on the domain controller which is
the
> > ticket granting server.
>
> There wouldn't be; there would be a user or computer account named
> "hq.corp.com", corresponding to a host having that name.
Okay, so maybe now we are narrowing this down to a DNS problem. I can
resolve hq.corp.com to the two IP addresses of two domain controllers.
There is no host named hq.corp.com, but maybe there needs to be some kind of
host record for the domain and it is missing? What would I be checking for
in the raw zone files?
--
Will
Paul B. Hill
Instead of diving down into the network traces, can you describe the
problems that you are seeing from a user's perspective? This thread sounds
like you are getting lost in the details instead of solving the problem.
Install the Microsoft Resource Kit on the member server and/or workstation
that you are trying to troubleshoot. Run the Microsoft klist.exe from the
command line with the parameter "tickets". This will show the tickets that
you, the logged in user, has on the machine. If you want to see what tickets
the local machine account has use the "at" command to run "klist tickets"
(e.g. a minute from invoking the "at" command.)
To see the list of service principal names issued to a computer use "setspn
<computername> -l". The program communicates with the DCs so you can check
the SPNs for any computer from any workstation or server in the domain.
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.
Better yet, please read
<http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies
/security/tkerberr.mspx>. If that doesn't help, you should at least have
enough information to ask a very pointed question that subscribers to the
public list may be able to help you resolve.
Good luck.
Paul
--
Will
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Will
news:011a01c6a355$4650dcd0$0300a8c0@pbhtablet...
> Instead of diving down into the network traces, can you describe the
> problems that you are seeing from a user's perspective? This thread sounds
> like you are getting lost in the details instead of solving the problem.
>
> Install the Microsoft Resource Kit on the member server and/or workstation
> that you are trying to troubleshoot. Run the Microsoft klist.exe from the
> command line with the parameter "tickets". This will show the tickets that
> you, the logged in user, has on the machine. If you want to see what
tickets
> the local machine account has use the "at" command to run "klist tickets"
> (e.g. a minute from invoking the "at" command.)
>
> To see the list of service principal names issued to a computer use
"setspn
> <computername> -l". The program communicates with the DCs so you can check
> the SPNs for any computer from any workstation or server in the domain.
>
> 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.
Okay, let's try top down then. I have some computers on the network that
fail group policy replication for users. The detail in eventviewer
indicates a failure to find the GPT.INI file on the file server using a path
that looks like this:
\\hq.corp.com\sysvol\blahblahblah\gpt.ini
I went to the command line and tested this unusual syntax, and lo and
behold: on machines where group policy works, this syntax works fine and
finds the file. On machines where group policy fails, on the command line
this syntax gets an obtuse "0 files found". So the group policy message is
certainly not misleading and is documenting a case I can easily duplicate at
the command line.
In looking at the sniffer trace, I see that the systems where group policy
fails are looking for host records for hq.corp.com, and they are failing.
Using kerbtray, I don't see any evidence of a different set of tickets on
the machines where things work versus the ones where they don't. Then
again, the kerberos ticket structure is new to me and I don't trust myself
to be a judge of whether it is all in order.
I don't understand how to view the results of the AT command invocation of
klist tickets. It wasn't going to the eventviewer. Morever, the
command was being scheduled in my user context so it wouldn't have shown
system context anyway. Every time I tried to change the user in Schedule
Tasks to SYSTEM, the task would refuse to run at all.
SETSPN frankly just perplexes me. It appears to be a pretty simplistic
utility with a very rigid input syntax expected, and I guess I don't know
what it is. From the console of the domain controller my-dc1, I tried:
setspn -L my-dc1
This gets failure message:
"ldap_search_s failed: No Such Object"
Then I tried to search for the domain itself:
setspn -L hq.corp.com
This gets another failure:
"Domain not found for account"
I tried to fully qualify the server, and I got a repeat of the domain not
found error.
I tried your syntax with -L at the end, but that just gets the command line
help and rejects the syntax.
I'm not sure if I simply typed the syntax of setspn wrong, or if I have a
genuine problem with the kerberos system.
--
Will