Vista / UAC

[Tim Alsop]

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.
>
>
>
>