locked
AccessCheck on an impersonated user inside a service RRS feed

  • Question

  • I've run across a problem using the AccessCheck function in Vista with impersonated users.

    The AccessCheck function is being called from inside a service that accepts connections via RPC or .NET remoting. The connections include authentication information, and the user is successfully being impersonated.

    Everything works fine when the services is running on Windows 2000, XP or 2003. The AccessCheck function checks against a custom ACL, and user actions are controlled via the ACL. However, the access check just doesn't work the same on Vista.

    The default ACL gives full access to the BUILTIN\Administrators group. I am experiencing the following behaviour:
    • If the user is logged on locally as a member of the group, and runs the service's admin tool non-elevated, the AccessCheck function denies access.
    • If the user is logged on locally as a member of the group, and runs the service's admin tool elevated, the AccessCheck function grants access.
    • If a user connects remotely using the credentials of a member of the group, the AccessCheck function denies access.
    As far as I have been able to figure out, the problem is related to integrity levels. I'm guessing that the remote and non-elevated users are being given a medium integrity level, and are therefore failing the integroty check. Running elevated seems to give the user the required integrity level to pass the access check.

    Is there any way that I can get the AccessCheck function to validate against a lower integrity level impersonation token? I'm not terribly worried about the integrity level of the user, just so long as users are granted access when the ACL says they should have it.

    Thanks in advance to anyone who can help.
    Wednesday, August 1, 2007 12:02 AM

Answers

  • I did some testing, and found that the following accounts are restricted under UAC:
    • BUILTIN\Administrators
    • DOMAIN\Domain Admins
    • DOMAIN\Domain Controllers
    • DOMAIN\Schema Admins
    • DOMAIN\Enterprise Admins
    • DOMAIN\Group Policy Creator Owners
    By "restricted", I mean that they're added to a user's token as SE_GROUP_USE_FOR_DENY_ONLY under normal circumstances. They only get SE_GROUP_ENABLED status when the user is running elevated.

    I also found that while the domain groups are "restricted", they are only restricted when used on their own. They can be used to add members to other groups without issue.

    In the end, I had to code quite a workaround:
    • When the service starts, it checks the OS. If the OS is not Vista (or later), no changes are made.
    • The ACL (in SDDL form) is checked to see which groups have been given allow ACEs.
    • If an ACE is present for any account other than the ones listed above (or SYSTEM / Local Service / Network Service), no changes are made.
    • A new local group is created. This members of this group are copied from BUILTIN\Administrators.
    • An allow ACE is added for this new group.
    This has worked around the issue for us.

    My main sticking point on this whole issue is that the documentation for all of this is terrible (both the April 2007 MSDN Library and the online docs). I found plenty of stuff talking about mandatory labels, but nothing that mentioned anything about group tokens being modified. There's also no documentation on which groups are affected this way, leaving me to try and figure this out the hard way.

    The lack of documentation on this area of Vista's security changes is terrible. When you consider that the product has been RTM for around 9 months now, and in beta for several months before that, you'd think that more of this would be documented.
    Monday, August 13, 2007 5:40 AM

All replies

  • I've just put in some extra code, and the services is running with System integrity level, while the users are running with Medium integrity level.

    I guess what I'm looking at finding now is either a way to (temporarily) lower the process integrity level for the duration of the check, or to elevate the impersonation token integrity level.

    Is there any way to do either of these?
    Wednesday, August 1, 2007 2:09 AM
  •  nzgeek wrote:


    Is there any way that I can get the AccessCheck function to validate against a lower integrity level impersonation token? I'm not terribly worried about the integrity level of the user, just so long as users are granted access when the ACL says they should have it.

     

    The problem is that when the user is not running elevated, the BUILTIN\Administrators token is not part of their security token and so the check is failing.

     

    I'd imagine that the best way to get around this would be to create a local group that specifies who is allowed to access the service and make checks based on membership of that group rather than Administrators. This has two benefits: firstly the group membership won't be filtered out of the token so your check won't be dependent on elevation status and secondly it allows delegated access to your service without requiring the user to be a full blown administrator on the computer.

    Wednesday, August 1, 2007 8:17 AM
  •  AndyCadley wrote:

    I'd imagine that the best way to get around this would be to create a local group that specifies who is allowed to access the service and make checks based on membership of that group rather than Administrators. This has two benefits: firstly the group membership won't be filtered out of the token so your check won't be dependent on elevation status and secondly it allows delegated access to your service without requiring the user to be a full blown administrator on the computer.


    Unfortunately, that doesn't help our situation much.

    The idea here is that the admin tool can be used by any local administrator as soon as the software has been installed. Adding another local group means that the group has to be populated first. To work around that, we'd have to automatically populate the group with members... such as the Administrators group. Which doesn't really change the situation at all.

    I'm not convinced that the BUILTIN\Administrators group is not part of a user's token unless they're elevated. I'll check this out and report back with the results.
    Sunday, August 5, 2007 8:59 PM
  • Andy is correct as far as you are concerned.

    But it's not absolutely correct: Non-elevated processes of admins still have the admins SID but it's marked such that it can only be used for DENY ACEs... It can't be used to grant access.

     

    What you're seeing remotely is also by design if you're using local accounts added to the admins group.

    Domain accounts would have their full administrative administrative privileges remotely.

     

    Monday, August 13, 2007 1:37 AM
  • I did some testing, and found that the following accounts are restricted under UAC:
    • BUILTIN\Administrators
    • DOMAIN\Domain Admins
    • DOMAIN\Domain Controllers
    • DOMAIN\Schema Admins
    • DOMAIN\Enterprise Admins
    • DOMAIN\Group Policy Creator Owners
    By "restricted", I mean that they're added to a user's token as SE_GROUP_USE_FOR_DENY_ONLY under normal circumstances. They only get SE_GROUP_ENABLED status when the user is running elevated.

    I also found that while the domain groups are "restricted", they are only restricted when used on their own. They can be used to add members to other groups without issue.

    In the end, I had to code quite a workaround:
    • When the service starts, it checks the OS. If the OS is not Vista (or later), no changes are made.
    • The ACL (in SDDL form) is checked to see which groups have been given allow ACEs.
    • If an ACE is present for any account other than the ones listed above (or SYSTEM / Local Service / Network Service), no changes are made.
    • A new local group is created. This members of this group are copied from BUILTIN\Administrators.
    • An allow ACE is added for this new group.
    This has worked around the issue for us.

    My main sticking point on this whole issue is that the documentation for all of this is terrible (both the April 2007 MSDN Library and the online docs). I found plenty of stuff talking about mandatory labels, but nothing that mentioned anything about group tokens being modified. There's also no documentation on which groups are affected this way, leaving me to try and figure this out the hard way.

    The lack of documentation on this area of Vista's security changes is terrible. When you consider that the product has been RTM for around 9 months now, and in beta for several months before that, you'd think that more of this would be documented.
    Monday, August 13, 2007 5:40 AM
  • More groups than this are filtered.

    Half way through this article (http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/default.aspx) you'll find

    this link: http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/default.aspx?loc=&fig=true#fig3

     

    Here's the content so you don't have to walk the link:

    Built-In Administrators
    Power Users
    Account Operators
    Server Operators
    Printer Operators
    Backup Operators
    RAS Servers Group
    Windows NT 4.0 App Compat Group
    Network Configuration Operators
    Domain Administrators
    Domain Controllers
    Certificate Publishers
    Schema Administrators
    Enterprise Administrators
    Group Policy Administrators

     

    Monday, August 27, 2007 2:21 AM