Skip Menu |
 

Subject: KFW: CCAPI: Vista UAC incompatibility
The KFW CCAPI RPC implementation is incompatible with Vista User Account
Control. The initial ccache server is started using the credentials of
the logon account. An account that is a member of the Administrators
Group when UAC is active will start off with restricted access. Tickets
acquired by KFW in this state will be stored in a ccache server that is
running with restricted privileges.

When the user elevates a process it will no longer be able to
communicate with the ccache server. This results in the following
negative user experience. The user elevates a process that requires
Kerberos credentials. The krb5 library cannot find any valid credential
cache and prompts the user to obtain a TGT. The user obtains the TGT
and is then prompted again because the application seeking the
credentials still cannot read them. User looks a credential manager,
sees valid tickets, and gets frustrated.
Download (untitled) / with headers
text/plain 1.8KiB
In preparation for testing this on Vista, I wrote out a test scenario
and tried it on XP. Is this behavior acceptable???

Does the fact that additional krbcc32s servers are created mean that
the elevated process's logon session is different from the user's logon
session?

Elevated privilege test scenario
----------------------------------------------------------------
0) Setup:

Two accounts: password-protected Administrator 'admin' and restricted
user 'kpkoch.'

Ensure NIM, SecureCRT icons on desktop.

Configure SecureCRT:
Global settings: SSH2 / Use personal store certificate.
Athena session : user kpkoch, only GSSAPI and Kerberos.


----------------------------------------------------------------
1) Restricted user test:

(Re)boot. No logon sessions.

Logon as 'kpkoch.' MIT KfW 3.2.2 autoprompts for credentials. Enter
password, get creds.

Start Task Manager; verify one krbcc32s, user should be kpkoch.

Run SecureCRT, connect to Athena. Should work without any additional
prompting.
One krbcc32s.
Exit SecureCRT.


----------------------------------------------------------------
2) Elevated user test 1:

Right click SecureCRT icon, Run As ... 'admin,' connect to Athena.
2nd krbcc32s, owned by Admin.
Connection to session athena.dialup.mit.edu failed: Key exchange
failed. No compatible key exchange method.


----------------------------------------------------------------
3) Elevated user test 2:

Kill NIM.

Right click NIM icon, select Run As ..., enter username 'admin.'
Asked for password for kpkoch, 3rd krbcc32s, owned by Admin.
Enter kpkoch password, get creds.
<ESC> to iconize to tray.
NIM now owned by Admin.

Right click SecureCRT icon, Run As ... 'admin,' connect to Athena.
Obtain new credentials Password prompt for kpkoch.
Delay.
Connection to session athena.dialup.mit.edu failed: Key exchange
failed. No compatible key exchange method.
Date: Wed, 12 Mar 2008 21:49:25 -0400
From: Jeffrey Altman <jaltman@columbia.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5871] KFW: CCAPI: Vista UAC incompatibility
RT-Send-Cc:
Kevin Koch via RT wrote:
Show quoted text
> Does the fact that additional krbcc32s servers are created mean that
> the elevated process's logon session is different from the user's logon
> session?

Yes.
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

Show quoted text
> Kevin Koch via RT wrote:
> > Does the fact that additional krbcc32s servers are created mean that
> > the elevated process's logon session is different from the user's
> > logon session?

[jaltman@columbia.edu - Wed Mar 12 21:47:08 2008]:
Show quoted text
> Yes.

Then the shipping CCAPI V2 and V3 replacement both give the same poor
user experience. Both V2 & V3 use the logon session ID to select which
ccache to access.
Date: Thu, 13 Mar 2008 09:46:49 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5871] KFW: CCAPI: Vista UAC incompatibility
RT-Send-Cc:
Kevin Koch via RT wrote:
Show quoted text
>> Kevin Koch via RT wrote:
>>> Does the fact that additional krbcc32s servers are created mean that
>>> the elevated process's logon session is different from the user's
>>> logon session?
>
> [jaltman@columbia.edu - Wed Mar 12 21:47:08 2008]:
>> Yes.
>
> Then the shipping CCAPI V2 and V3 replacement both give the same poor
> user experience. Both V2 & V3 use the logon session ID to select which
> ccache to access.
Hence the reason why this bug was opened and the reason why the original
design for CCAPIv3
was to use a single system-wide service.
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

I've updated the subject since the design issue is not Vista-UAC-
specific.

A single system-wide ccache isn't going to solve the problem if it is
indexed by logon session id (LSID).

The real problem is the use of LSID, which is different between the
user's logon session and an elevated process spawned by the session.
What identifier can be used that will be the same for the logon session
and an elevated process it spawns?

Should this discussion continue on krbdev?
Date: Thu, 13 Mar 2008 10:24:25 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5871] KFW: CCAPI: Logon Session as cache index: poor elevated-user experience
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Kevin Koch via RT wrote:
Show quoted text
> I've updated the subject since the design issue is not Vista-UAC-
> specific.

I disagree. The XP case of run as user "Administrator"
vs "Kpkoch" is explicitly using a different user account and the
credentials should not be shared in that instance.

This is different from the UAC case in which case the same user account
"Kpkoch" is used in both cases. The only difference is that in one
instance the user token is a "Restricted" token and the other one is
not.

If you permit "Administrator" and "Kpkoch" to share the same
cache how are you going to protect user sessions from each other
with terminal server or fast-user switching?

Show quoted text
> A single system-wide ccache isn't going to solve the problem if it is
> indexed by logon session id (LSID).
>
> The real problem is the use of LSID, which is different between the
> user's logon session and an elevated process spawned by the session.
> What identifier can be used that will be the same for the logon session
> and an elevated process it spawns?

Right. You can't use the LSID. You need to use something based
on the user token.
Download smime.p7s
application/x-pkcs7-signature 3.2KiB

Message body not shown because it is not plain text.

Subject: KfW: CCAPI: Vista UAC incompatibility
I have separated the LSID-based ccache name issue into a new ticket.
This ticket goes back to being only about UAC on Vista.