Vista / UAC

Tim Alsop Tim.Alsop at CyberSafe.Com
Thu Mar 1 09:52:10 EST 2007


We have found that when UAC is enabled, code cannot read the service
ticket's session key. In fact, it can, but the value is 00000000 so when
gssapi server application accepts the context the key used is not same
as key in keytab, and hence the authentication fails.


-----Original Message-----
From: Jeffrey Altman [mailto:jaltman at] 
Sent: 01 March 2007 14:47
To: Tim Alsop
Cc: krbdev at
Subject: Re: Vista / UAC


Accounts that are not Administrators can read the session key just fine.
UAC only affects accounts that are in the Administrators group.

Jeffrey Altman

Tim Alsop wrote:
> Jeffrey,
> We have a large number of customers using our product who will at some
> point in the future be wanting to upgrade to Vista. When they do this,
> and we change our code as you described these users which are
> non-administrators (hundreds of thousands of users in total across
> various companies in the world) will have to (a) give permission for
> code to access the session key every time they logon to windows, or
> turn of UAC. I suspect most will turn off UAC to avoid the pop-up
> request once we explain why this appears. This is against what MS
> intended since UAC is supposed to be good and useful, not be anoying
> useless :-) Also, we are not the only vendor using Kerberos for SSO so
> suspect there will be many vendors facing the same issue.
> Like yourself I disagree with the current approach to protect session
> keys when using UAC. It seems if we use SSPI instead of our own GSSAPI
> then this problem would not occur, but we should not be forced to
> our code and use SSPI just because of this UAC issue. In order for UAC
> to gain acceptance MS need to change it to work better than it does. I
> consider the current way it works to be wrong. I would rather have a
> registry value like AllowTGTSessionKey (AllowServiceTicketSessionKey
> which we can set to allow access to service ticket session keys.
> Thanks,
> Tim 
> -----Original Message-----
> From: Jeffrey Altman [mailto:jaltman at] 
> Sent: 01 March 2007 14:30
> To: Tim Alsop
> Cc: krbdev at
> Subject: Re: Vista / UAC
> Tim:
> I repeat:  You cannot bypass the UAC checks.   When your process is
> running under an account that is a member of the "Administrators"
> you will have to start a secondary process or COM object running as
> "Administrator" which will have the bits necessary to read the session
> key.  When that secondary process or COM object is started, the user
> *will* be asked for permission.  That is the purpose of UAC, to notify
> the user, each and every time, that a process is trying to perform an
> operation that is deemed sensitive.
> The best you can do is design your code such that the user only gets
> prompted once per logon session.
> If you want to see this changed, I recommend that you get your users
> file a complaint with Microsoft.
> Jeffrey Altman
> Tim Alsop wrote:
>> Jeffrey,
>> I have only just joined this list so didn't get the previous email
> send
>> on 21st Nov. Thanks for explaining the background anyway.
>> Can you confirm if I undertand correctly ? If we use administrative
>> objects as described a non-privilaged user can logon to Vista when
>> is enabled and then using credentials obtained during this logon they
>> can logon to other apps on the network using Kerberos auth, and will
> not
>> be asked for permission with a pop-up from UAC ?
>> We will read up on admin com objects as suggested so we can
>> how we can transparently bypass UAC checks to support the situation
>> described above.
>> Cheers,
>> Tim
>> -----Original Message-----
>> From: Jeffrey Altman [mailto:jaltman at] 
>> Sent: 01 March 2007 14:03
>> To: Tim Alsop
>> Cc: krbdev at
>> Subject: Re: Vista / UAC
>> Tim Alsop wrote:
>>> Jeffrey,
>>> When account is called adminstrator, e.g. local administrator or
>> domain
>>> administrator then the problems do not occur because Vista checks
>>> 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
>>> difference.
>>> Thanks,
>>> Tim 
>> Tim:
>> You cannot bypass UAC via a manifest file.   The purpose of UAC is
> warn
>> users when a process is going to be performing a task that requires
>> elevation.  Its not a question of code compilation but of run-time
> code
>> execution.
>> Quoting from e-mail that I sent to this list on 21 Nov 2006 regarding
>> KFW and Vista:
>> "Any operations that require administrative privileges to be
>> will need to be broken out into a separate process space which will
> have
>> to obtain administrative privileges via a secure desktop interaction
> (if
>> the user has the appropriate privileges.)
>> ...
>> The recommended method for adding administrative operations is via
>> use of administrative COM objects."
>> In the case of the session keys, Microsoft has decided that it is ok
> for
>> a generic user or the real Administrator to access the session keys. 
>> However, if the user is a member of the Administrators group and UAC
> is
>> active, the user must be notified and given permission to deny the
>> access. 
>> The Microsoft UAC page is located here:
>> It contains pointers on UAC administration and tips and best
>> for developers.
>> Personally, I disagree with this choice of behaviors. In my opinion
>> should be used to prevent modifications to the host configuration, it
>> should not be used in such a manner that would severely restrict the
>> ability of users to negotiate protocols with APIs other than SSPI.
>> Jeffrey Altman
>> Secure Endpoints Inc.

More information about the krbdev mailing list