Vista / UAC

[Jeffrey Altman]

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.
>>
>>
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070301/5beb0165/attachment.bin