Re: Working around UAC for AccessCheck API, how?

Try using the linked token, TOKEN_LINKED_TOKEN
(http://msdn.microsoft.com/en-us/library/bb530719(VS.85).aspx).

You may also need this info as well:
http://blogs.msdn.com/vistacompatteam/archive/2007/04/18/c2065-token-linked-token-undeclared-identifier.aspx

--
Garfield A. Lewis

"Stefan Kuhr" <kustt110@xxxxxx> wrote in message
news:OB9S4vBwIHA.4848@xxxxxxxxxxxxxxxxxxxxxxx
Hello everyone,

I have a client server solution that uses RPC in order to talk from the
client to the server. The server protects resources via private object
security and impersonates client calls and invokes the AccessCheck API in
order to determine if the client s eligible to get access to the protected
resources. This works great for all platforms as long as clients and
servers are on different machines.

Now if both the client and the server run on the same machine and if that
machine is Vista with UAC enabled, UAC gets in my way if. e.g. access to a
protected resource of the server is granted to the local administrators
group. In this case the interactive user's token is used to determine
access and this token is restricted, so access is denied to a local
administrator. Nothing fancy so far, this is how restricted tokens and UAC
work - and clients have to be elevated in order to access the resources.

The thing is: I don't want these UAC implications for administrators in my
server, I simply want the behaviour as if an administrator was logged in
on XP. My client typically runs in the background on user's desktops,
started with an autorun registry key and it should definitely not require
elevation. Is there a way to achieve this on the server side?

If not, is the following workaround correct:

Since I cannot modify the impersonated user token in my server, I
temporarily modify the security descriptor of my private object security
and the "algorithm" would go as follows:

Step 1: Use the impersonated user's token and call AccessCheck. If
AccessCheck grants access then grant access, otherwise continue with Step
2.

Step 2: If the token is unrestricted, deny access, otherwise continue with
Step 3

Step 3. Loop over the groups in the token. For each ACE that is used for
denying access (attributes are SE_GROUP_USE_FOR_DENY_ONLY), see, if there
is an access-allow ACE in the security descriptor of the private object.
If so, replace the SID of this access-allow ACE with the "Everyone"
group's SID. Now continue with Step 4.

Step 4: Again do an access check with the AccessCheck API. This time use
the modified security descriptor from the previous step. If AccessCheck
now grants access, grant access, because obviously access was denied in
Step 1 only because of a restricted token. If AccessCheck denies access,
ultimately deny access.


Did I overlook something? Is this the correct approach to replace a single
AccessCheck call if I want to ignore the implications of restricted tokens
as they are issued on Vista with UAC enabled?



Any comments appreciated,

--
Stefan


.

Relevant Pages

  • Using SSPI (NTLM) Apis With Windows AccessCheck() On Vista With UAC Enabled
    ... Using SSPI Api's With Windows AccessCheck() On Vista With UAC ... Server / Running as LocalSystem Service ... Client - AcquireCredentialsHandle ...
    (microsoft.public.platformsdk.security)
  • Working around UAC for AccessCheck API, how?
    ... I have a client server solution that uses RPC in order to talk from the client to the server. ... The server protects resources via private object security and impersonates client calls and invokes the AccessCheck API in order to determine if the client s eligible to get access to the protected resources. ... Is this the correct approach to replace a single AccessCheck call if I want to ignore the implications of restricted tokens as they are issued on Vista with UAC enabled? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: DWORDs vs interface pointers as tokens: marshalling & other Qs
    ... client for later use through the server. ... my server object has one or more tokens, ... Only enough information is transferred to allow creating a proxy on the ...
    (microsoft.public.vc.atl)
  • Re: [9fans] QTCTL?
    ... tokens and then revoke them as appropriate. ... had granted a read token to a client the client could simply stop ... the cached behavior is identical to what ... suppose you adopted a model where each server ...
    (comp.os.plan9)
  • Re: Practical limit of access tokens or kernel objects in one process?
    ... connections might be something shorted than that, assuming that each RPC ... I am currently writing a service that will accept client connects via RPC ... the server until the client closes the context handle or dies for whatever ... Is my approach of keeping client access tokens around in the ...
    (microsoft.public.win32.programmer.kernel)