Vista / UAC
jaltman at secure-endpoints.com
Thu Mar 1 09:02:59 EST 2007
Tim Alsop wrote:
> 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
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
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:
It contains pointers on UAC administration and tips and best practices
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.
Secure Endpoints Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070301/24175247/attachment.bin
More information about the krbdev