1

I have a unique quandary.

I'm developing a class that will test the Users Account Permission, I've covered most basis. But the one I'm mostly concerned with is testing against Null or a SID.

The reason I'm concerned is:

if(user != null)
{
   role.IsInRole(WindowsBuiltInRole.Administrator);
}

Obviously a simple implementation to demonstrate, but will the WindowsBuiltInRole check strictly based on the individual machine or against the Domain? If the users Domain account is indeed Administrator, will it successfully test?

Or would the better way to test against the five or six Domain SID Tokens? Will other User Accounts such as the Network Service Account will it manipulate the same way? What would be the best way to ensure the authenticity of the token value.

Any input would be terrific.

Greg
  • 11,302
  • 2
  • 48
  • 79

2 Answers2

1

By definition of WindowsBuiltInRole Enumeration found at:

WindowsBuiltInRole Enumeration

The WindowsBuiltInRole.Administrator role indeed works for both computer and domain without restrictions.

The WindowsBuiltInRole.PowerUser will be able to run applications but cannot install or uninstall stuff.

The WindowsBuiltInRole.AccountAdministrator may manage accounts and even change rights, but not making domain-wide changes (as in distributed deployments).

The WindowsBuiltInRole.BackupOperator can override security restrictions for the sole purpose of backing up or restoring files.

The WindowsBuiltInRole.Replicator supports file replication in a domain.

These different roles may seem blurry, but it can be inferred that all but Administrator can do some Administrator tasks, but not all.

  • But what about the other `BuiltInRole` Accounts? Will they span across the `Domain` as well? – Greg Mar 29 '13 at 15:36
  • I expanded the answer hoping it's satisfactory. Other roles have some Administrator-like privileges, not all. –  Mar 30 '13 at 00:07
1

The WindowsBuiltInRole enumeration corresponds exactly to Windows SIDs, and precisely to well-kwown SIDS associated with a Windows built-in group: Well-known security identifiers in Windows operating systems, all the SIDs starting with 'S-1-5-32-'.

The integer value of the enum value corresponds to the last number in the sid, so, because WindowsBuiltInRole.Administrator is 544, it corresponds to S-1-5-32-544. So what you're checking using this code is really if the user belongs to the Administrators group:

SID: S-1-5-32-544

Name: Administrators

Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
  • That is a great post, so by default the `BuiltInRole` is comparing the *Local Machine, Workgroup, or Domain* to see which those default `Roles` belong to? But it is physically using the `SID Token`. – Greg Apr 01 '13 at 21:04
  • The check is done on the Administrators group, so it depends exactly on what's in that group for the machine you're running the code off. That's it. The underlying Windows API used is simply CheckTokenMembership http://msdn.microsoft.com/en-us/library/windows/desktop/aa376389.aspx with the corresponding SID. – Simon Mourier Apr 02 '13 at 06:03
  • Thanks, I don't know how I missed that when I was looking for answers about the ideal way to handle it. You earned it though. – Greg Apr 02 '13 at 15:13