Working around UAC for AccessCheck API, how?

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

  • Re: Working around UAC for AccessCheck API, how?
    ... I have a client server solution that uses RPC in order to talk from the ... this is how restricted tokens and UAC ... Use the impersonated user's token and call AccessCheck. ...
    (microsoft.public.win32.programmer.kernel)
  • 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)
  • 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)