Difference between revisions of "KfW UAC interactions"

Latest revision as of 16:05, 26 February 2016

This page attempts to characterize what we know about KfW interactions with UAC.

TGT-less API ccache

"Matching credential not found" from gss_init_sec_context

Conditions:

• WIN.MIT.EDU domain joined Windows workstation
• domain user with local Administrator rights logs in
• UAC is active
• ms2mit.exe runs from the login scripts
• user hasn't set a default ccache location for KfW in the registry HKCU\Software\MIT\Kerberos5\ccname? maybe also HKLM

The result is an API: ccache with no TGTs that contains only the service tickets that existed in the LSA ccache at the time ms2mit.exe ran. This leads to cryptic errors when running SAPgui, etc. and no prompting by Leash for a password to get fresh tickets. (If the API: ccache is empty, Leash should prompt.) We believe this is because the LSA doesn't allow direct access to TGTs when an admin user is logged in with UAC active.

The Windows LSA apparently creates two sets of access tokens (Kerberos credentials? how equivalent are they?) when a domain user with local Administrator rights logs in. One set has full Administrator rights on the local machine, and the other has those rights filtered (presumably by filtering the PAC? See https://support.microsoft.com/en-us/kb/937624 but it's not very clear due to vague terminology). Allowing access to the TGT session key in a non-elevated user session might allow a user to get a ticket with an unfiltered PAC and thereby gain access to unrestricted local Administrator rights while bypassing UAC.

Leash has some code to copy the LSA creds to the API: ccache during startup, but it seems to notice when the TGT session key is unavailable and refuses to copy anything. ms2mit.exe apparently uses different logic and copies all the existing service tickets but not the (inaccessible) TGT. In theory this means that not running ms2mit.exe will cause something mostly reasonable to happen: domain users without local Administrator rights get a usable API: ccache, and users with local Administrator rights get an empty API: ccache and a password prompt. Unfortunately, when Richard disabled running ms2mit.exe in the logon script, some users reported problems. Were these running an older KfW release that had different Leash startup logic for copying LSA creds?

TODO:

Investigate how the LSA cache behaves in a machine not joined to the WIN domain. Such a machine might not know how to contact ATHENA realm KDCs or how to do cross-realm to WIN correctly (this is highly speculative).

Popup kinit failure

• Popup from Leash displays, prompting for Kerberos password
• Type password
• Get "Couldn't inquire DEFAULT INITIATING credentials" from gss_inquire_cred

This seems to happen when

• the registry key HKCU\Software\MIT\Kerberos5\ccname isn't set (nor its HKLM version)
• the API: ccache is empty (or expired?)
• user is in the local admin group
• UAC is active

Troubleshooting

Check whether the user is in the local Administrators group:

   net localgroup Administrators

or

   whoami /groups

when logged in as the user.

Look for WIN\username or WIN\groupname (where username is the user's account name, and groupname is the name of a group the user belongs to).

Check the default ccache name:

   reg query HKCU\Software\MIT\Kerberos5 /v ccname
   reg query HKLM\Software\MIT\Kerberos5 /v ccname

Also running

   "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A

and looking at whether the MSLSA: ccache is lacking krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU is useful. On some machines, it's necessary to give the full path to the KfW klist because there's a Windows native klist program that behaves differently.