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