This ticket raises a number of interesting concerns. The summary of
the initial complaint is that the user would like to be able to use
NetIdMgr from within a secondary logon session. For example, start
CMD.EXE with Run As ... "DOMAIN\Administrator" while logged into the
machine as "DOMAIN\User".
When "DOMAIN\user" logged in, NetIdMgr started and is being run within
the primary logon session. There it serves two purposes:
(1) it manages identities for DOMAIN\user, performs renewals, obtains
AFS tokens, etc.
(2) it acts as the Interactive Prompter when GSSAPI applications require
a Kerberos 5 TGT and there is valid one available for the "default"
identity.
When the "DOMAIN\Administrator" logon session is created it shares the
same Desktop as "DOMAIN\User". More importantly, in non-Terminal Server
environments, it shares the same name space for Mutex objects and Window
names. When the second instance of NetIdMgr 1.0 starts it discovers
that the Mutex names it uses for synchronization are already in use AND
those mutex objects cannot be shared using its process credentials.
(DOMAIN\Administrator cannot access a mutex owned by DOMAIN\user.)
NetIdMgr terminates immediately under this condition.
Assuming we wanted to allow two instances of NetIdMgr to execute on the
same Desktop we would have to be able to solve the shared name space
problem for "window names". We can easily work around the Mutex
problem by assigning mutex names that are uniqified by appending the
LUID to them. However, the "window names" will still collide. The
problem here is that a GSSAPI application running in the
DOMAIN\Administrator logon session will more than likely trigger a
prompt from the DOMAIN\User NetIDMgr. The side effect will be that
DOMAIN\User will now have credentials that were meant for
"DOMAIN\Administrator". That would be very bad.
NOTE: Leash32 has exactly this same problem. However, as Leash does not
use named mutexes, we did not discover it.
One possible solution would be to extend NetIdMgr to support multiple
logon sessions at once. This would require that the NetIdMgr running
in the DOMAIN\Administrator session act as a slave of the DOMAIN\User
NetIDMgr. The DOMAIN\User NetIdMgr would provide UI functionality but
the DOMAIN\Administrator NetIdMgr would interact with the actual
DOMAIN\Administrator credentials.
This would be a significant re-write and a funding source for this work
would have to be identified.
Jeffrey Altman
