Vista / UAC

[Tim Alsop]

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.