I tried this test scenario on XP.  When a user starts a process with 
elevated privilege, the process gets a different LSID from the spawning 
logon session.  The spawned, elevated process can't access the original 
process's ccache, because the name of the ccache is based on the LSID.

The fact that additional krbcc32s servers are created means 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.


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.


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?


[JAltman]:
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?

You can't use the LSID.  You need to use something based
on the user token.