Kerberos TGT Session Key restriction for Domain user in local Administrators group with UAC enabled?
I'm desperately looking for proof that there is a genuine Microsoft restriction on AD Domain users who are members of the local Administrators group with UAC enabled not having access to the Kerberos TGT Session Key. So far I have only found non-Microsoft references to this "restriction" but would like to have definitive proof that it's real. I've also got empirical evidence that it's true, but I can't say for certain that it's UAC causing it. Note that I'm experiencing this restriction with Windows Vista and Windows 7; I assume it also applies to Windows Server 2008. Can anyone link me to a Microsoft document or KB article or TechNet article that confirms (or denies) this restriction? Regards, ...alan
April 27th, 2010 6:01pm

Hi, It seems we need to clarify some questions before moving forward. What are you trying to do and what’s the detailed error message you got? If I run "klist purge" on a UAC enabled Windows 7 system, there is no error. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
April 29th, 2010 12:19pm

I simply wish to know if there is a restriction. I have seen many references to such a restriction, but nothing "official" from Microsoft to back it up.
May 7th, 2010 11:46pm

Hi Alan, were you able to get more info on this? We have a java client that is having this problem and would like to know if its a problem with Windows or our client. Thanks Hans
Free Windows Admin Tool Kit Click here and download it now
June 25th, 2010 1:33pm

I'd like to know what the restrictions are as well with Windows 7 and UAC on. Java application works fine without UAC but fails with UAC. Wireshark trace shows TCP being used for the first TGS request and that works, then for some odd reason it moves back to UDP but fails with BAD_INTEGRITY. So the question is why is Windows using TCP then UDP (most of the time I have seen UDP > TCP) and why is it failing with the BAD_INTEGRITY.
July 9th, 2010 10:09pm

here is an article for understanding UAC http://technet.microsoft.com/en-us/library/cc772207(WS.10).aspx
Free Windows Admin Tool Kit Click here and download it now
July 12th, 2010 11:55am

I'm in a similar predicament as 'crashrat' above. The referenced UAC article didn't provide any useful new insight to bring to bear on the problem. This seems to be a bug in Windows 7 and/or the UAC feature.
July 13th, 2010 10:56pm

Thanks but that really doesn't help much. Here is what the stdout results of the Java toolbox app shows with UAC on Client Principal = thnan@EGDK.IT-CORP.NET Server Principal = krbtgt/EGDK.IT-CORP.NET@EGDK.IT-CORP.NET Session Key = EncryptionKey: keyType=23 keyBytes (hex dump)= 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Forwardable Ticket true Forwarded Ticket false Proxiable Ticket false Proxy Ticket false Postdated Ticket false Renewable Ticket true Initial Ticket true Auth Time = Mon Jun 28 08:29:10 CEST 2010 Start Time = Mon Jun 28 08:29:10 CEST 2010 End Time = Mon Jun 28 18:29:10 CEST 2010 Renew Till = Mon Jul 05 08:29:10 CEST 2010 Client Addresses Null Found a principal Retrieved principal: thnan@EGDK.IT-CORP.NET Creating AS400 object with: DKEGH408 Using GSS name: thnan@EGDK.IT-CORP.NET Found ticket for thnan@EGDK.IT-CORP.NET to go to krbtgt/EGDK.IT-CORP.NET@EGDK.IT-CORP.NET expiring on Mon Jun 28 18:29:10 CEST 2010 Entered Krb5Context.initSecContext with state=STATE_NEW Found ticket for thnan@EGDK.IT-CORP.NET to go to krbtgt/EGDK.IT-CORP.NET@EGDK.IT-CORP.NET expiring on Mon Jun 28 18:29:10 CEST 2010 Service ticket not found in the subject >>> Credentials acquireServiceCreds: same realm Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 3 1 23 16 17. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType >>> KrbKdcReq send: kdc=HERSDC01 UDP:88, timeout=30000, number of retries =3, #bytes=1566 >>> KDCCommunication: kdc=HERSDC01 UDP:88, timeout=30000,Attempt =1, #bytes=1566 >>> KrbKdcReq send: #bytes read=116 >>> KrbKdcReq send: #bytes read=116 >>> KDCRep: init() encoding tag is 126 req type is 13 >>>KRBError: sTime is Mon Jun 28 10:27:11 CEST 2010 1277713631000 suSec is 160084 error code is 31 error Message is Integrity check on decrypted field failed realm is EGDK.IT-CORP.NET sname is krbsvr400/dkegh408.egdk.it-corp.net msgType is 30 KrbException: Integrity check on decrypted field failed (31) at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:61) at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:234) at sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:294) at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:106) at sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:561) at sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:585) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:213) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158) at com.ibm.as400.access.TokenManager.getGSSToken(TokenManager.java:49) at com.ibm.as400.access.AS400.signon(AS400.java:3662) at com.ibm.as400.access.AS400.connectService(AS400.java:1107) at KerberosLogon.run(KerberosLogon.java:119) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:337) at KerberosLogon.logon(KerberosLogon.java:108) at KerberosLogon.main(KerberosLogon.java:81) Caused by: KrbException: Identifier doesn't match expected value (906) at sun.security.krb5.internal.KDCRep.init(KDCRep.java:133) at sun.security.krb5.internal.TGSRep.init(TGSRep.java:58) at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:53) at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:46) ... 15 more com.ibm.as400.access.AS400SecurityException: Kerberos service ticket could not be retrieved. at com.ibm.as400.access.AS400.signon(AS400.java:3675) at com.ibm.as400.access.AS400.connectService(AS400.java:1107) at KerberosLogon.run(KerberosLogon.java:119) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:337) at KerberosLogon.logon(KerberosLogon.java:108) at KerberosLogon.main(KerberosLogon.java:81) Notice the 0's for the encryption key. So like the originator of this post points out, it seem the app does not have access to the TGT, but no documentation on this specifically within Microsoft.
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2010 11:11pm

I've found the same issue in a simple Java kerberos app. The simplest workaround seems to be to have the user run kinit, which caches a new ticket in their user directory. Running the program as administrator works as well, but that probably should be your last resort.
August 13th, 2010 10:37pm

I think I have the exact same problem here! I am working as a domain account with administrator privileges on a Windows 7 machine and a server running Windows 2008. I am trying to authenticate windows users from our own Java client application to our Java server application without the need for retyping the password. I got the GSS-API example from Oracle and this example to work when I still manually type in the password. However I cannot get Single Sign On to work when I use the cached TGT (by setting useTicketCache=false in the JAAS config). The client seems to be able to use the cached TGT to login to the KDC, but when the client tries to initialize a GSS context (which works fine when manually typing the password) it receives the error "Integrity check on decrypted field failed (31)". I have already set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters to 1. When I type "klist tgt" in a command prompt I see ... Sessiesleutel : KeyType 0x17 - RSADSI RC4-HMAC(NT) : KeyLength 16 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... In fact this bug seems to be known (a won't fix) at Oracle in this bug report . EDIT: I created a normal user in Active Directory and it does have this key set and the example program works!
Free Windows Admin Tool Kit Click here and download it now
November 29th, 2010 10:00am

My understanding of this issue is that, because your Java app is using GSS-API to manage the credentials instead of using SSPI to manage them, Single Sign On (SSO) won't work. With SSPI, the application never needs to deal directly with the credentials and the correct things happen automatically. With GSS-API, the application tries to handle the users credentials within the application. Since the application is running as a limited user (not elevated to Administrator), Windows won’t give the application all of the credential information since that would allow the application to run as an elevated user. I think there are two workarounds that might be possible in this case. Run the Java application as an elevated user (e.g. right-click on the application and select "Run as Administrator"). Change the application to use SSPI (this may not be possible if this is a third party application). If you're going to run the application with Administrator priviledges, it's important that you trust the application.[MSFT]
December 13th, 2010 3:13pm

as of my understanding, whatever is not working in java is just a matter of java. I would rather post the question to some java support forum to have the guys repair their own problems. There is actually no restriction on "accessing TGT" from restricted token processes. The question is what level of access you are asking about. If you used just the Win32 SSPI API to exchange the tokens then you wouldn't have any problems. This certailny does not give you any access to the ticket itself, but would do all the encryptions for you itself. ondrej.
Free Windows Admin Tool Kit Click here and download it now
December 14th, 2010 2:20am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics