krb5kdc_err_s_principal_unknown on Windows Kerberos Domain - Kerberos

This is a discussion on krb5kdc_err_s_principal_unknown on Windows Kerberos Domain - Kerberos ; I may be having problems with Kerberos on a Windows 2000 domain controller, 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

  1. krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    I may be having problems with Kerberos on a Windows 2000 domain controller,
    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



  2. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    >>>>> "Will" == Will writes:

    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
    res@qoxp.net


  3. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain


    "Richard E. Silverman" wrote in message
    news:m2slldfia5.fsf@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




  4. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    >>>>> "Will" == Will writes:

    Will> "Richard E. Silverman" wrote in message
    Will> news:m2slldfia5.fsf@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.corp.com@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
    res@qoxp.net


  5. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    "Richard E. Silverman" wrote in message
    news:m27j2ofpkf.fsf@darwin.oankali.net...
    > >>>>> "Will" == Will writes:

    > Will> "Richard E. Silverman" wrote in message
    > Will> news:m2slldfia5.fsf@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.corp.com@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



  6. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    >
    > "Richard E. Silverman" wrote in message
    > news:m27j2ofpkf.fsf@darwin.oankali.net...
    > > >>>>> "Will" == Will writes:

    > > Will> "Richard E. Silverman" wrote in message
    > > Will> news:m2slldfia5.fsf@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.corp.com@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.


    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
    res@qoxp.net


  7. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    Richard Silverman said:
    >>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



  8. RE: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    Hi Will,

    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
    -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/pro...3/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


    -----Original Message-----
    From: kerberos-bounces@MIT.EDU [mailto:kerberos-bounces@MIT.EDU] On Behalf
    Of Will
    Sent: Friday, July 07, 2006 3:16 AM
    To: kerberos@mit.edu
    Subject: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    I may be having problems with Kerberos on a Windows 2000 domain controller,
    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


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  9. Re: krb5kdc_err_s_principal_unknown on Windows Kerberos Domain

    ""Paul B. Hill"" wrote in message
    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
    > -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




+ Reply to Thread