Difference between revisions of "KfW UAC interactions"
(New page: This page attempts to characterize what we know about KfW interactions with UAC. Conditions: * WIN.MIT.EDU domain joined Windows workstation * domain user with local Administrator rights...) |
|||
| Line 14: | Line 14: | ||
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? |
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). |
||
Revision as of 22:43, 16 February 2016
This page attempts to characterize what we know about KfW interactions with UAC.
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
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).
