Vista / UAC

[Tim Alsop]

Jeffrey,

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.

Thanks,
Tim 

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

Tim:

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
our
> code to access the session key every time they logon to windows, or
(b)
> 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
and
> useless :-) Also, we are not the only vendor using Kerberos for SSO so
I
> 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
change
> 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
new
> 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 secure-endpoints.com] 
> Sent: 01 March 2007 14:30
> To: Tim Alsop
> Cc: krbdev at mit.edu
> 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"
group,
> you will have to start a secondary process or COM object running as
the
> "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
to
> 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
> COM
>> objects as described a non-privilaged user can logon to Vista when
UAC
>> 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
understand
>> how we can transparently bypass UAC checks to support the situation
>> described above.
>>
>> Cheers,
>> Tim
>>
>> -----Original Message-----
>> From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
>> Sent: 01 March 2007 14:03
>> To: Tim Alsop
>> Cc: krbdev at mit.edu
>> 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
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 
>>>
>> 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
performed
>> 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
the
>> 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:
>>
>>   http://technet.microsoft.com/en-us/windowsvista/aa905108.aspx
>>
>> It contains pointers on UAC administration and tips and best
practices
>> for developers.
>>
>> Personally, I disagree with this choice of behaviors. In my opinion
> UAC
>> 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.
>>
>>
>>
>>