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

  • Thread starter Thread starter Kim Noer
  • Start date Start date
K

Kim Noer

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/[email protected]
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: (e-mail address removed)
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.
 
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;en-us;291382

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 said:
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/[email protected]
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: (e-mail address removed)
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.
Click to expand...
 
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 said:
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/[email protected]
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: (e-mail address removed)
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.
Click to expand...
 
Roger Abell said:
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).
Click to expand...

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.
 
Kim Noer said:
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.
Click to expand...


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.
 
Anyway, let us know how things turn out for you.
Click to expand...

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/[email protected]
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/[email protected]
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.
 
Anyway, let us know how things turn out for you.
Click to expand...

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 :)
 
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...st=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/[email protected])
but then again, sometimes failures are misintpreted and fail
on over to trigger a misleading message.
 
Roger Abell said:
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...st=1&ast=2&ast=3&ast=8&ast=9&mode=a&x=13&y=15
Click to expand...

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 ?
Click to expand...

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/[email protected])
but then again, sometimes failures are misintpreted and fail
on over to trigger a misleading message.
Click to expand...

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?
 
Back
Top