Kerberos' role in a 'std. setup' without bells & whistles

Archived from groups: microsoft.public.win2000.security (More info?)

Hi there...

I haven't quite figured out just yet, what my DC uses Kerberos for, so can
anyone here clue me in, what it is used for[1]? I've figured out it's about
issueing tickets in some security context, and that my DC current acts as a
Kerberos Key Distribution Center- and it somehow relates to LDAP/AD. But a
look in my event log shows that it runs in a rather fault way -

Event ID 594 :

A Kerberos Error Message was received:
on logon session InitializeSecurityContext
Client Time:
Server Time:
Error Code: 4:30:5.0000 6/30/2005 (null) 0x20
Extended Error: KRB_AP_ERR_TKT_EXPIRED
Client Realm:
Client Name:
Server Realm: domain.tld
Server Name: krbtgt/domain.tld
Target Name: krbtgt/domain.tld@domain.tld
Error Text:
File:
Line:
Error Data is in record data.

And since I apparently don't know what the server is using Kerberos for it
makes it difficult to nick this error. Futhermore, a search on this error,
indicates to me that it's quite an extensive task to fix it - eek!

A "klist tickets" shows some tickets that have expired, but not reviewed -

Server: myDC@domain.tld
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT
End Time: 6/17/2005 7:16:25
Renew Time: 6/23/2005 21:16:25

- presumeably, this failure to renew the ticket, is what generets the error
in the event log?

[1] I primarily need some quick advice that enables to either investigate
further (read up on Kerberos etc.) if you think I need Kerberos, or some
advice on how to disable Kerberos, if you think I don't need Kerberos.

--
I doubt, therefore I might be.
8 answers Last reply
More about kerberos role setup bells whistles
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    Kerberos is the default authentication method used in a Windows 2000/2003
    domain and Windows 2000/2003/XP Pro computers can use it and will use it by
    default. This is not something that can or should be disabled. Computers and
    users authenticate with the KDC and use the tickets to access domain
    resources. If kerberos fails the users/computers should be able to fall back
    to lm/ntlm/ntlmv2 though things like ipsec policy, if used, may fail
    without kerberos authentication.

    Active Directory and kerberos depends heavily on DNS and if DNS is not
    configured correctly [as in ISP dns servers being listed as a preferred dns
    server in tcp/ip properties of a domain computer] all kinds on problems can
    happen in the domain. Simple network connectivity problems can also cause
    similar problems. What I would suggest is that you first make sure your DNS
    is working correctly and use the support tools netdiag, dcdiag, and gpotool
    on your domain controllers and netdiag on domain computers to check for
    domain/AD/dns/network connectivity health. The link below has a lot of good
    information about Active Directory dns and the support tools are located in
    the support/tools folder of the installation disk of the appropriate
    operating system.

    http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382

    The link below is good information on troubleshooting kerberos if problems
    persist after you have verified that your domain is otherwise a well oiled
    machine. I also pasted the info on that error. Kerberos is time sensitive
    and all domain computers need to be in synch time wise [default skew
    tolerance is five minutes] and should be automatically but this is still
    something to check on the problem computer. When checking a computers time
    always check day/date/year/time zone/AM or PM in addition to the time. By
    default the maximum lifetime for a user ticket is ten hours. --- Steve

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

    0x20 - KRB_AP_ERR_TKT_EXPIRED: Ticket expired
    Associated internal Windows error codes
    . STATUS_TIME_DIFFERENCE_AT_DC


    Corresponding debug output messages
    . DebugLog("Trying to renew a ticket past its renew time\n")

    . DebugLog("Trying to renew an expired ticket\n")


    Possible Cause and Resolution
    . The smaller the value for the Maximum lifetime for user ticket
    Kerberos policy setting, the more likely it is that this error will occur.
    Because ticket renewal is automatic, you should not have to do anything if
    you get this message.

    Resolution

    To change the Maximum lifetime for user ticket setting:

    1.
    Click Start, click All Programs, click Administrative Tools, and
    then click Domain Security Policy.

    2.
    Click Accounts Policies, and then click Kerberos Policy.

    3.
    Increase the value for Maximum lifetime for user ticket.

    4.
    Run gpupdate /force on any client computer on which you want this
    policy change to take effect immediately.


    "Kim Noer" <kn@nospam.dk> wrote in message
    news:eOfBSlZfFHA.1444@TK2MSFTNGP10.phx.gbl...
    > Hi there...
    >
    > I haven't quite figured out just yet, what my DC uses Kerberos for, so can
    > anyone here clue me in, what it is used for[1]? I've figured out it's
    > about issueing tickets in some security context, and that my DC current
    > acts as a Kerberos Key Distribution Center- and it somehow relates to
    > LDAP/AD. But a look in my event log shows that it runs in a rather fault
    > way -
    >
    > Event ID 594 :
    >
    > A Kerberos Error Message was received:
    > on logon session InitializeSecurityContext
    > Client Time:
    > Server Time:
    > Error Code: 4:30:5.0000 6/30/2005 (null) 0x20
    > Extended Error: KRB_AP_ERR_TKT_EXPIRED
    > Client Realm:
    > Client Name:
    > Server Realm: domain.tld
    > Server Name: krbtgt/domain.tld
    > Target Name: krbtgt/domain.tld@domain.tld
    > Error Text:
    > File:
    > Line:
    > Error Data is in record data.
    >
    > And since I apparently don't know what the server is using Kerberos for it
    > makes it difficult to nick this error. Futhermore, a search on this error,
    > indicates to me that it's quite an extensive task to fix it - eek!
    >
    > A "klist tickets" shows some tickets that have expired, but not reviewed -
    >
    > Server: myDC@domain.tld
    > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT
    > End Time: 6/17/2005 7:16:25
    > Renew Time: 6/23/2005 21:16:25
    >
    > - presumeably, this failure to renew the ticket, is what generets the
    > error in the event log?
    >
    > [1] I primarily need some quick advice that enables to either investigate
    > further (read up on Kerberos etc.) if you think I need Kerberos, or some
    > advice on how to disable Kerberos, if you think I don't need Kerberos.
    >
    > --
    > I doubt, therefore I might be.
    >
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    As Steve suggests, before trying to fix Kerberos itself, check whether
    you need to fix its key dependencies of DNS and timesync (which can
    be off due to DNS).

    Kerb in a tiny nutshell is that at authentication a TGT, ticket granting
    ticket, is received. This TGT is the passport for getting service tickets
    for accessing services (resources). The TGT is obtained in a fancy
    dance of three parties, and afterwards act like a token of the holder's
    identity, such that when presented to the KDC it is key to getting
    tickets and hence access to services.

    The steps in the "fancy dance" underlying this must be completed
    withina set time from when they start, so it is critical that all parties
    to the dance believe it is the same time. The PDC emulator of each
    domain is responsible for this time sync service for its domain, and
    the PDC emulator of the forest root domain is responsible for telling
    all the other PDC emulators what time it really is.

    So, if for example, your domain does not have a PDC FSMO at the
    moment. eventual chaos follows. Or, if the DNS records are not
    up-to-date and correctly pointing to the PDC FSMO, machines do
    not find it in order to get in sync (which, if they are out of sync
    means they will likely stay out of sync since they will not be allowed
    to use the other lookup methods with LDAP inquey to AD to find
    their PDC FSMO. Again, choas follows.

    So, start by ruling out issues with the dependencies of Kerberos.
    Run netdiag and dcdiag on each of your domain controller for a
    first step to see if these utilities like things.

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "Kim Noer" <kn@nospam.dk> wrote in message
    news:eOfBSlZfFHA.1444@TK2MSFTNGP10.phx.gbl...
    > Hi there...
    >
    > I haven't quite figured out just yet, what my DC uses Kerberos for, so can
    > anyone here clue me in, what it is used for[1]? I've figured out it's
    about
    > issueing tickets in some security context, and that my DC current acts as
    a
    > Kerberos Key Distribution Center- and it somehow relates to LDAP/AD. But a
    > look in my event log shows that it runs in a rather fault way -
    >
    > Event ID 594 :
    >
    > A Kerberos Error Message was received:
    > on logon session InitializeSecurityContext
    > Client Time:
    > Server Time:
    > Error Code: 4:30:5.0000 6/30/2005 (null) 0x20
    > Extended Error: KRB_AP_ERR_TKT_EXPIRED
    > Client Realm:
    > Client Name:
    > Server Realm: domain.tld
    > Server Name: krbtgt/domain.tld
    > Target Name: krbtgt/domain.tld@domain.tld
    > Error Text:
    > File:
    > Line:
    > Error Data is in record data.
    >
    > And since I apparently don't know what the server is using Kerberos for it
    > makes it difficult to nick this error. Futhermore, a search on this error,
    > indicates to me that it's quite an extensive task to fix it - eek!
    >
    > A "klist tickets" shows some tickets that have expired, but not reviewed -
    >
    > Server: myDC@domain.tld
    > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT
    > End Time: 6/17/2005 7:16:25
    > Renew Time: 6/23/2005 21:16:25
    >
    > - presumeably, this failure to renew the ticket, is what generets the
    error
    > in the event log?
    >
    > [1] I primarily need some quick advice that enables to either investigate
    > further (read up on Kerberos etc.) if you think I need Kerberos, or some
    > advice on how to disable Kerberos, if you think I don't need Kerberos.
    >
    > --
    > I doubt, therefore I might be.
    >
    >
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:%23fUuS9efFHA.576@TK2MSFTNGP15.phx.gbl
    > As Steve suggests, before trying to fix Kerberos itself, check whether
    > you need to fix its key dependencies of DNS and timesync (which can
    > be off due to DNS).

    I'll dig into the time sync issues, since a client expirences clock drift
    currently, and apparently the client does not correct the time. I'll post again
    when I've been digging around enough :).

    Thank you very much for the information posted (both you and Steve), highly
    appriciated.

    --
    I doubt, therefore I might be.
  4. Archived from groups: microsoft.public.win2000.security (More info?)

    "Kim Noer" <kn@nospam.dk> wrote in message
    news:%23Nip2ZkfFHA.484@TK2MSFTNGP14.phx.gbl...
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:%23fUuS9efFHA.576@TK2MSFTNGP15.phx.gbl
    > > As Steve suggests, before trying to fix Kerberos itself, check whether
    > > you need to fix its key dependencies of DNS and timesync (which can
    > > be off due to DNS).
    >
    > I'll dig into the time sync issues, since a client expirences clock drift
    > currently, and apparently the client does not correct the time. I'll post
    again
    > when I've been digging around enough :).
    >
    > Thank you very much for the information posted (both you and Steve),
    highly
    > appriciated.
    >
    > --
    > I doubt, therefore I might be.
    >


    Too funny.
    That reminds me of a comment some decades back
    when discussing with an elder Buddhist priest from
    South Vietam, and he said
    'That early thinker in here in the West (Descartes)
    said "I think, therefore I am". The problem is,
    sometimes I do not think.'

    Anyway, let us know how things turn out for you.
    --
    Roger Abell
  5. Archived from groups: microsoft.public.win2000.security (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:%23bAmTokfFHA.3316@TK2MSFTNGP14.phx.gbl

    > Anyway, let us know how things turn out for you.

    After some sniffing around I came up with nothing. All the computers I checked,
    had the right time, and a minute within the 'DC time'.

    Checking the event log shows that two Kerberos 594 event ID errors. Both entries
    very poor on details (read:none) -

    Event Type: Error
    Event Source: Kerberos
    Event Category: None
    Event ID: 594
    Date: 03-07-2005
    Time: 13:14:51
    User: N/A
    Computer: ThePDC
    Description:
    A Kerberos Error Message was received:
    on logon session InitializeSecurityContext
    Client Time:
    Server Time:
    Error Code: 11:14:51.0000 7/3/2005 (null) 0x20
    Extended Error: KRB_AP_ERR_TKT_EXPIRED
    Client Realm:
    Client Name:
    Server Realm: domain.tld
    Server Name: krbtgt/domain.tld
    Target Name: krbtgt/domain.tld@domain.tld
    Error Text:
    File:
    Line:
    Error Data is in record data.

    Event Type: Error
    Event Source: Kerberos
    Event Category: None
    Event ID: 594
    Date: 03-07-2005
    Time: 13:15:14
    User: N/A
    Computer: ThePDC
    Description:
    A Kerberos Error Message was received:
    on logon session InitializeSecurityContext
    Client Time:
    Server Time:
    Error Code: 11:15:14.0000 7/3/2005 (null) 0x20
    Extended Error: KRB_AP_ERR_TKT_EXPIRED
    Client Realm:
    Client Name:
    Server Realm: domain.tld
    Server Name: krbtgt/domain.tld
    Target Name: krbtgt/domain.tld@domain.tld
    Error Text:
    File:
    Line:
    Error Data is in record data.

    From what I ca read, it's the actual PDC that have problems with expirering
    tickets..?
    The corresponding security entries are -Event Type: Failure Audit
    Event Source: Security
    Event Category: Account Logon
    Event ID: 677
    Date: 03-07-2005
    Time: 13:14:51
    User: NT AUTHORITY\SYSTEM
    Computer: ThePDC
    Description:
    Service Ticket Request Failed:
    User Name: User Domain:
    Service Name: krbtgt/domain.tld
    Ticket Options: 0x2
    Failure Code: 0x20
    Client Address: 127.0.0.1

    Event Type: Failure Audit
    Event Source: Security
    Event Category: Account Logon
    Event ID: 677
    Date: 03-07-2005
    Time: 13:15:14
    User: NT AUTHORITY\SYSTEM
    Computer: ThePDC
    Description:
    Service Ticket Request Failed:
    User Name: ThePDC$
    User Domain: domain.tld
    Service Name: krbtgt/domain.tld
    Ticket Options: 0x2
    Failure Code: 0x20
    Client Address: 127.0.0.1
    Now I can do what Steven suggested, that is changing the lifetime for the
    tickets, but isn't that just a symptom treatment more than an actual fix? I
    mean, shouldn't this expirering thingy just work "out of the box"-- I doubt,
    therefore I might be.
  6. Archived from groups: microsoft.public.win2000.security (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:%23bAmTokfFHA.3316@TK2MSFTNGP14.phx.gbl

    > Anyway, let us know how things turn out for you.

    Did you forget me? :) I still haven't figured out the problem :(.

    Searching the net doesn't help me at all, either there's generic error
    description, or nobody knows what to do about it. It does seem like Kerberos is
    like black magic to many :)

    --
    I doubt, therefore I might be.
  7. Archived from groups: microsoft.public.win2000.security (More info?)

    So are all of the event messages for expired ticket being seen
    on the DC(s) and being recorded without info in the client
    name and realm info ?

    Have you seen these
    http://support.microsoft.com/search/default.aspx?spid=global&query=KRB_AP_ERR_TKT_EXPIRED&catalog=LCID%3D1033&pwt=false&title=false&kt=ALL&mdt=0&comm=1&ast=1&ast=2&ast=3&ast=8&ast=9&mode=a&x=13&y=15


    If it was just a client machine where you used klist to see that the
    ticket for the server was expired, have you tried removing that
    ticket in order to try forcing getting a new one ?

    I am assume the service principal names (spn)s for your server
    host and for kerberos kdc are fine or else you would be getting
    different failure errors rather than an apparent return of the
    expired error from the KDC (krbtgt/domain.tld@domain.tld)
    but then again, sometimes failures are misintpreted and fail
    on over to trigger a misleading message.

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "Kim Noer" <kn@nospam.dk> wrote in message
    news:ePQIoK8gFHA.1044@tk2msftngp13.phx.gbl...
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:%23bAmTokfFHA.3316@TK2MSFTNGP14.phx.gbl
    >
    > > Anyway, let us know how things turn out for you.
    >
    > Did you forget me? :) I still haven't figured out the problem :(.
    >
    > Searching the net doesn't help me at all, either there's generic error
    > description, or nobody knows what to do about it. It does seem like
    Kerberos is
    > like black magic to many :)
    >
    > --
    > I doubt, therefore I might be.
    >
    >
  8. Archived from groups: microsoft.public.win2000.security (More info?)

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:%23f46Ap8gFHA.328@tk2msftngp13.phx.gbl
    > So are all of the event messages for expired ticket being seen
    > on the DC(s) and being recorded without info in the client
    > name and realm info ?
    >
    > Have you seen these
    > http://support.microsoft.com/search/default.aspx?spid=global&query=KRB_AP_ERR_TKT_EXPIRED&catalog=LCID%3D1033&pwt=false&title=false&kt=ALL&mdt=0&comm=1&ast=1&ast=2&ast=3&ast=8&ast=9&mode=a&x=13&y=15

    Yes, but they didn't clue me in how to nick this error unfortunately.

    > If it was just a client machine where you used klist to see that the
    > ticket for the server was expired, have you tried removing that
    > ticket in order to try forcing getting a new one ?

    But the problem is that I don't know which client that generates this error,
    since so far, every error have an emtpy "Client Name" and "Client Realm", this
    makes me think that the errors are generate on the ThePDC itself?

    > I am assume the service principal names (spn)s for your server
    > host and for kerberos kdc are fine or else you would be getting
    > different failure errors rather than an apparent return of the
    > expired error from the KDC (krbtgt/domain.tld@domain.tld)
    > but then again, sometimes failures are misintpreted and fail
    > on over to trigger a misleading message.

    Here is a dsstore -macobj domain\ThePDC$ output for ThePDC -


    Attribute : dNSHostName
    ThePDC.domain.tld

    Attribute : objectCategory
    CN=Computer,CN=Schema,CN=Configuration,DC=domain,DC=tld

    Attribute : sAMAccountName
    ThePDC$

    Attribute : servicePrincipalName
    MSSQLSvc/ThePDC.domain.tld:24408
    exchangeMDB/ThePDC.domain.tld
    exchangeMDB/ThePDC
    exchangeRFR/ThePDC.domain.tld
    exchangeRFR/ThePDC
    SMTPSVC/ThePDC
    SMTPSVC/ThePDC.domain.tld
    DNS/ThePDC.domain.tld
    NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/ThePDC.domain.tld
    GC/ThePDC.domain.tld/domain.tld
    HOST/ThePDC.domain.tld/domain
    HOST/ThePDC
    HOST/ThePDC.domain.tld
    HOST/ThePDC.domain.tld/domain.tld
    E3514235-4B06-11D1-AB04-00C04FC2DCD2/070cb0e4-5b87-4d49-af7c-36f34c079c75/domain.tld
    LDAP/070cb0e4-5b87-4d49-af7c-36f34c079c75._msdcs.domain.tld
    LDAP/ThePDC.domain.tld/DOMAIN
    LDAP/ThePDC
    LDAP/ThePDC.domain.tld
    LDAP/ThePDC.domain.tld/domain.tld

    Attribute : userAccountControl
    532480

    Group Memberships:
    Domain Servers
    Domain Controllers


    Note that I don't actually have exchange installed anymore. Can you spot any
    errors/possible faults in the above?

    --
    I doubt, therefore I might be.
Ask a new question

Read More

Windows