Vista / UAC

[Tim Alsop]

Jeffrey,

When account is called adminstrator, e.g. local administrator or domain
administrator then the problems do not occur because Vista checks for
this account name and disabled UAC. 
When account is a domain account with domain admin group membership then
the problem exists.

So, do we need to compile all our code which accesses credential cache
using elevated privileges ? This means that a normal user who uses our
product will be running code with elevated admin privs in order for our
code to access ms cache keys. Is this correct ? Do  you know how to
compile code to run elevated ? Is it via Visual Studio manifest file
change ?

On previous Windows version UAC was not available so this is expected
difference.

Thanks,
Tim 

-----Original Message-----
From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
Sent: 01 March 2007 13:34
To: Tim Alsop
Cc: krbdev at mit.edu
Subject: Re: Vista / UAC

Tim:

Do you have these problems with a non-Administrator account?

Do you have these problems with an Administrator account that is running
with elevated privileges?

Under Vista an Administrator account cannot read session keys if UAC is
active and the process is not running with elevated privileges.

This behavior is different from previous Windows releases but it is how
Microsoft designed it.

Jeffrey Altman


Tim Alsop wrote:
> Jeffrey,
>
> I also wanted to mention, that on Vista, when we set
AllowTGTSessionKey
> we don't get same results as on XP. On XP SP2 if this is not set or
set
> to 0 then the etype is shown as 0 in credentials cache, but on Vista
the
> etype is shown as 23 as it would be expected regardless of the
> AllowTGTSessionKey presence/value. It is possible that
> AllowTGTSessionKey is not working on Vista. Anyway, this is not the
> issue I am asking for help on - I am only concerned with the session
key
> in service tickets.
>
> I asked krbdev because I thought that kfw product was being enhanced
to
> support MS LSA cache and run on Vista. Our product has supported LSA
> cache on XP, and XP x64 for a long time, and when we recently tested
on
> Vista we found these differences. I just wondered if MIT dev team had
> also seen the same issues.
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
> Of Tim Alsop
> Sent: 01 March 2007 07:28
> To: jaltman at secure-endpoints.com
> Cc: krbdev at mit.edu
> Subject: RE: Vista / UAC
>
> Jeffrey,
>
> I am NOT referring to the TGT session key. I am using
AllowTGTSessionKey
> in registry and it is working as designed for the TGT session key.
> However, when I use LSP functions to get the session key from a
service
> ticket this is not possible with UAC enabled, and there is no known
> registry key to allow my code to read this key. I can read the key
when
> UAC is disabled, or when using an administrator account.
>
> Thanks, Tim 
>
> -----Original Message-----
> From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
> Sent: 01 March 2007 02:29
> To: Tim Alsop
> Cc: krbdev at mit.edu
> Subject: Re: Vista / UAC
>
> Tim Alsop wrote:
>> Hello,
>>  
>> I am intersted in how far you have got with developing support for MS
>> WIndows cache on Vista. We find our code works well, but only if UAC
> is
>> turned off. This is because when UAC is enabled the session key in a
>> service ticket is returned as all zero's instead of a valid session
> key.
>> The result is that a server application that is accepting a security
>> context fails to accept the context using the key from a key table
> file
>> on server. I plan to raise a support call with MS, but wanted to
check
>> first if you had already talked to MS and found a solution to this
>> problem ?
>>  
>> Regards,
>> Tim
>
> Tim:
>
> This is working as designed.
>
> When the user is a normal user and the AllowTGTSessionKey value is
> non-zero, the session key may be extracted.
>
> When the user is an administrator and UAC is active, the session key
can
> only be extracted if the AllowTGTSessionKey value is non-zero and the
> process is running with elevated privileges.
>
> Jeffrey Altman
> Secure Endpoints Inc.
>
>
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev