Issue with TGS requests following DC promotion to existing domain

  • 191 Views
  • Last Post 22 June 2015
n3ilb3 posted this 21 June 2015

Hi All,I’m seeing an issue with newly promoted domain controllers in my existing environment issuing Service Tickets.  Specifically I’m seeing the problem with TGS request for SPN’s registered to accounts that have “Use Kerberos DES encryption types for this account” set.Let me give you some background on the environment, the FFL/DFL are 2008r2, all DCs are 2008r2 SP1 and are fully patched.  Both the DCs and clients have both DES encryption types enabled under the allowed encryption types for Kerberos via a GPO.  The domain has been upgraded from 2000, to 2003 and finally up to 2008r2 over the last 12 years or so, its been running at a 2008r2 DFL/FFL for 6 months, and has been running only 2008r2 DCs for the last 18 months.  The service accounts affected are both old and new, so some have existed from 2003 days but others are less than 6 months old.The specific event logged on the newly promoted DCs is Event 16 in the System Event Log.“While processing a TGS request for the target server HTTP/intranet.company.com, the account user1@xxxxxxxxxxxxxxxx did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18  17  23  3  1  24  -135. The accounts available etypes were 23  -133  -128  3  1. Changing or resetting the password of SvcIntranet will generate a proper key.”The above example shows the service account SvcIntranet, but it happens for multiple accounts all of which have the “User Kerberos DES…” set.A network trace from a client machine shows the Kerberos request failing with an error: KRB5KDCERRETYPE_NOSUPP being generated.One strange thing I’ve noted is that on the existing DCs there are some Event 16’s logged, but only 5 – 10 in a 24 hour period per DC, whereas on the new DCs they appear every 2 – 3 minutes, so I see 100’s per hour.I’ve verified the registry key for the Kerberos DES encryption support that the GPO sets and I’ve rebooted the new DCs multiple times just in case the GPO didn’t process following promotion without luck.  I’m not clear from the error message exactly what is wrong, the requested and available etypes in the TGS request do have values in common so why can’t one of those be used?  Where does the key with an ID of 8 fit in? - I’ve had no joy googling info on an etype with a value of 8.Can anybody give an explanation to the issue and how I can resolve it?  Client are currently failing back to use NTLM which is ok expect some sites we host internally only permit Kerberos Auth.Thanks for the help!Neil

Order By: Standard | Newest | Votes
PARRIS posted this 22 June 2015

I have seen this issue in the past where the 2003 credentials are presented to the 2008 R2 DC’s and vice versa and they are in a different data format/structure , resetting the accounts password should fix the issue, I would imagine changing the password to the same password would work. The is an old KB that highlights the scenario, but looks to be a step away from your issue.https://support.microsoft.com/en-us/kb/978055   Regards, Mark ParrisActive Directory ConsultantMobile: +44 7801 690596E-mail:mark@xxxxxxxxxxxxxxxx   MVP Directory Services | MCM Directory Services

show

n3ilb3 posted this 22 June 2015

Hi Mark,
Thanks for the link, I'd reviewed that one myself and it does sound similar.  The thing that doesn't fit is that its also happening with SPNs registered against service accounts that have been created since we went purely 2008r2.  So I can't see why resetting the password would resolve those, given the account and password would both have been created on 2008r2 DCs.  It is probably a valid test though and something I'll look to do.
Thanks,
Neil


show

Close