SID - Security Identifier

Everybody shall have some idea of what a SID (security identifier) is.
There are plenty of information about SIDs on the Internet.

I do not intend to bore anyone copying and pasting, but the fact is or seems to be that information is split and scattered making it difficult to be used. I do not intend to touch on the subject of its implementation details.

What it seems more reasonable in addition to a basic understanding of its purpose, which everybody already or should know well, is its very basic structure and well-known values (generics) as used by Windows systems to which interoperability is required at some point, typically on ACLs of SMB shares.

As most things in Windows world, SIDs are also confusing, both with respect to its own concepts and with respect to other affine concepts such as GUIDs and so on... The bad news is that of course this is probably not getting any better in the near future. So we have to live with it :-(

What I'll attempt is summarizing what's found (at least for now) (at the time of this writing) on two Microsoft sources (MSDN API and References section 2.4.2 and Support KB243330). I believe that the way I display the information is better than what's found on these official references. Anyway...

BASIC STRUCTURE

As you may already have noted, a SID has variable length but always start with the letter S in a prefix that is usually S-1. What this means is that we are dealing with a version 1 SID (I still haven't seen nor have had any interest in looking for other versions).

What follows (separated by another dash) is called the Authority. Please, don't ask me why (I didn't invent this) it's called like that nor if it makes any sense to have such ones numbered and named as follows:

• 0 - Null
• 1 - World
• 2 - Local
• 3 - Creator
• 4 - Non-unique
• 5 - NT
• other unknowns: 15, 16, 18

What shall more frequently appears hence is the prefix S-1-5.

The following remaining parts (delimited by dashes) of the SID are called SubAuthorities (so, at a minimum, one infers, presumes, each one is dependent on the other that follows).

If the first SubAuthority, in general (as there are exceptions as for the 84!), is the 21 (you know, don't ask me why this value!), then it will be necessarily followed by three more SubAuthorities which together will denote a certain domain (or a machine). It may happen that the domain be, in fact, the root domain (the first domain that is created in an Active Directory forest infrastructure).

So, it will be usual to come to a SID that starts with something such as:

S-1-5-21-1111111111-222222222-3333333333

where (the three fictitious SubAuthorities delimited by dashes):

1111111111-222222222-3333333333

denote (identify) a certain domain or machine.

Finally, the last SubAuthority (but again there are exceptions, such as on the SID 1-5-5-X-Y), that follows the domain / machine id (if Authority = 21) or the Authority id itself (in the remaining cases), is called RID (the relative identifier). The RID, is what ultimately distinguishes one SID from another, that is, ascertain the uniqueness of a SID. It seems that values under 1000 are reserved for the system.

For example, the complete SID denoting respectively a user and a group within the previous example could be:

S-1-5-21-1111111111-222222222-3333333333-1100
S-1-5-21-1111111111-222222222-3333333333-2147483658

WELL-KNOWNS (Yellow Pages)

These well-known SID values are constant across all operating systems.
They typically represent generic identities on Windows.
A few are also relevant in terms of interoperability.

Windows NT, 2000 and later
                                                                                                               

S-1-0                    Null Authority
S-1-0-0                  Nobody

S-1-1                    World Authority
S-1-1-0                  Everyone

S-1-2                    Local Authority
S-1-2-0                  Local
S-1-2-1                  Console Logon

S-1-3                    Creator Authority
S-1-3-0                  Creator Owner
S-1-3-1                  Creator Group
S-1-3-2                  Creator Owner Server
S-1-3-3                  Creator Group Server
S-1-3-4                  Owner Rights

S-1-4                    Non-unique Authority

S-1-5                    NT Authority
S-1-5-1                  Dialup
S-1-5-2                  Network
S-1-5-3                  Batch
S-1-5-4                  Interactive
S-1-5-5-X-Y              Logon Session
S-1-5-6                  Service
S-1-5-7                  Anonymous
S-1-5-8                  Proxy
S-1-5-9                  Enterprise Domain Controllers
S-1-5-10                 Principal Self
S-1-5-11                 Authenticated Users
S-1-5-12                 Restricted Code
S-1-5-13                 Terminal Server Users
S-1-5-14                 Remote Interactive Logon
S-1-5-15                 This Organization
S-1-5-17                 This Organization
S-1-5-18                 Local System
S-1-5-19                 NT Authority
S-1-5-20                 NT Authority

S-1-5-21-domain-500      Administrator
S-1-5-21-domain-501      Guest
S-1-5-21-domain-502      KRBTGT
S-1-5-21-domain-512      Domain Admins
S-1-5-21-domain-513      Domain Users
S-1-5-21-domain-514      Domain Guests
S-1-5-21-domain-515      Domain Computers
S-1-5-21-domain-516      Domain Controllers
S-1-5-21-domain-517      Cert Publishers
S-1-5-21-rootdomain-518  Schema Admins
S-1-5-21-rootdomain-519  Enterprise Admins
S-1-5-21-domain-520      Group Policy Creator Owners
S-1-5-21-domain-553      RAS and IAS Servers

S-1-5-32-544             Administrators
S-1-5-32-545             Users
S-1-5-32-546             Guests
S-1-5-32-547             Power Users
S-1-5-32-548             Account Operators
S-1-5-32-549             Server Operators
S-1-5-32-550             Print Operators
S-1-5-32-551             Backup Operators
S-1-5-32-552             Replicators

S-1-5-64-10              NTLM Authentication
S-1-5-64-14              SChannel Authentication
S-1-5-64-21              Digest Authentication

S-1-5-80                 NT Service
S-1-5-80-0               All Services
S-1-5-80-0               NT SERVICES \ ALL SERVICES

S-1-5-83-0               NT VIRTUAL MACHINE \ Virtual Machines

S-1-16-0                 Untrusted Mandatory Level
S-1-16-4096              Low Mandatory Level
S-1-16-8192              Medium Mandatory Level
S-1-16-8448              Medium Plus Mandatory Level
S-1-16-12288             High Mandatory Level
S-1-16-16384             System Mandatory Level
S-1-16-20480             Protected Process Mandatory Level
S-1-16-28672             Secure Process Mandatory Level

In the next three sections that follows:
 

• Rember that the "operations master" is also known as
  the flexible single master operations (FSMO).
   
• The groups that are listed appear as SIDs until the respective Windows Server domain controller is made the primary domain controller (PDC) operations master role holder.
   
• The additional built-in groups that are listed are created when the respective Windows Server domain controller is added to the domain.

Windows Server 2003
                                                                                                                                  

S-1-5-32-554             BUILTIN \ Pre-Windows 2000 Compatible Access
S-1-5-32-555             BUILTIN \ Remote Desktop Users
S-1-5-32-556             BUILTIN \ Network Configuration Operators
S-1-5-32-557             BUILTIN \ Incoming Forest Trust Builders
S-1-5-32-558             BUILTIN \ Performance Monitor Users
S-1-5-32-559             BUILTIN \ Performance Log Users
S-1-5-32-560             BUILTIN \ Windows Authorization Access Group
S-1-5-32-561             BUILTIN \ Terminal Server License Servers
S-1-5-32-562             BUILTIN \ Distributed COM Users  


Windows Server 2008 (or R2)
                                                                                                                                  

S-1-5-21-rootdomain-498  Enterprise Read-only Domain Controllers 
S-1-5-21-domain-521      Read-only Domain Controllers
S-1-5-21-domain-571      Allowed RODC Password Replication Group
S-1-5-21-domain-572      Denied RODC Password Replication Group

S-1-5-32-568             BUILTIN \ IIS_IUSRS
S-1-5-32-569             BUILTIN \ Cryptographic Operators
S-1-5-32-573             BUILTIN \ Event Log Readers
S-1-5-32-574             BUILTIN \ Certificate Service DCOM Access


Windows Server 2012
                                                                                                                                  

S-1-5-21-0-0-0-496       COMPOUNDED_AUTHENTICATION
S-1-5-21-0-0-0-497       CLAIMS_VALID
S-1-5-21-domain-522      Cloneable Domain Controllers
S-1-5-21-domain-525      PROTECTED_USERS

S-1-5-32-575             BUILTIN \ RDS Remote Access Servers
S-1-5-32-576             BUILTIN \ RDS Endpoint Servers
S-1-5-32-577             BUILTIN \ RDS Management Servers
S-1-5-32-578             BUILTIN \ Hyper-V Administrators
S-1-5-32-579             BUILTIN \ Access Control Assistance Operators
S-1-5-32-580             BUILTIN \ Remote Management Users

S-1-5-33                 WRITE_RESTRICTED_CODE
S-1-5-65-1               THIS_ORGANIZATION_CERTIFICATE
S-1-5-84-0-0-0-0-0       USER_MODE_DRIVERS
S-1-5-113                LOCAL_ACCOUNT
S-1-5-114                LOCAL_ACC_AND_MEMBER_OF_ADMIN_GRP
S-1-5-1000               OTHER_ORGANIZATION

S-1-15-2-1               ALL_APP_PACKAGES

S-1-18-1                 AUTH_AUTH_ASSERTED_IDENTITY
S-1-18-2                 SERVICE_ASSERTED_IDENTITY
   

W2K & NFSv4 ACL mapping

This post is a development of another post, SMB & NFSv4 ACL mapping. It's specific to the Windows 2000 (and later) family systems. If necessary, please, check back the aforementioned "parent" post.

My discussion will be based on the following minimal scenario:
(box-01 is a Solaris 11.3 acting as a Windows 2000 Server)
 

The graphical interface of the (directory and files) unified ACL editor (Properties | Security) seems good to manage basic settings such as: List Folder Contents, Read & Execute, Modify and Full Control. But it is impossible to get the big picture at once, it may be confusing for handling inheritance and it mixes in more complex permissions sets. The point is: it should allow us to see the permissions for all names at once, it shouldn't have the confusing Read and Write options and it should have a more objective approach (other than the confusing dimmed or grayed out checkboxes alongside the Allow inheritable... checkbox) on the inheritance status. And on top of all this, by clicking on the checkboxes on a certain order (check Modify then clear Write, you would expect to be left with Read & Execute but you don't!) it's possible to mistakenly generate unwanted special permissions.
 

Unfortunately, the design of the Advanced option, entitled Access Control Settings is also bad because it adopts horizontal scrolling (which is terrible; they don't even persist the tedious adjustments of the listview columns that someone does in order to better see all the information without scrolling) instead of more concise graphical elements and filtering, or even a resize-able dialog, in order to really help an administrator do its job. Bottom line is it's also cumbersome as the basic one. Again, unfortunately, especially because Windows is so centric on ergonomics and GUI design. It's like this area has been greatly overlooked or treated with laziness (many out there could do a lot better than that...).
 

Still similarly to what I have done for Windows NT 4.0 (and before) let's initially focus just on the permissions sets that are displayed on the basic (Properties | Security) dialog.

The first thing to note is that the legacy permission flags (R, W, X, D, P and O) have all gone. They were replaced by other 13 (frequently even more confusing) flags which have no compact names but just descriptions and are only accessible after yet another click and more scrolling and a bunch more clicks. As you can see, a nightmare (I'm still not sure if they really wanted to discourage people or hide their mess, perhaps both, but there would be better ways, but, that's Windows!). In order to help put things in order we have the following 1-1 mapping between the each NFSv4 and Windows permission flag:
 

To help even more here is a mapping for the Windows 2000 basic permission sets dialog together with each flag setting, bor for the unnamed Windows flags and the UNIX NFSv4 ACLs (for simplicity here I'm intentionally omitting the name of the associated user or group that should be prefixed to each UNIX ACL and I'm also representing the 13 Windows flags as an ordered row resulting from a counter-clockwise rotation of 90°): 

Full Control
+Modify   +Read & Execute   +List Folder Contents   +Read   +Write

                        rwxpdDaARWcCos:fd-----:allow

Modify
+Read & Execute   +List Folder Contents   +Read   +Write

                        rwxpd-aARWc--s:fd-----:allow

Read & Execute
+List Folder Contents   +Read

                        r-x---a-R-c--s:fd-----:allow

List Folder Contents

                        r-x---a-R-c--s:-d-----:allow

Read

                        r-----a-R-c--s:fd-----:allow

Write

                        -w-p---A-W---s:fd-----:allow

NOTE

The preceding series of ACLs is formatted in terms of directory permissions but the same translation applies to file permissions (except, of course, List Folder Contents) if you disregard the respective ACL inheritance flags (between both colons in my listing) which contains an f and/or d. For instance, the Full Control for a file is depicted by rwxpdDaARWcCos:-------:allow, but depending on the inheritance it may show a trailing I inheritance flag.

NOTE

If needed, the Add & Read permission set from Windows NT 4.0 (and before)  must be manually created from the scratch by adding the following two permission sets to the desired user and directory:

r-x---a-R-c--s:f-i----:allow
rwxp--aARWc--s:-d-----:allow

Which, in other words, basically means:

Read & Execute for files and
Read, Write & Execute for directories (not their contents).

NOTE

As a variation of the Add & Read permission set above it could be interesting to have the possibility to add a folder just to a certain subtree root (or share) while all other permissions are inherited (as for giving read access to a group and so on). In that case, it's assumed (of course) that amongst the inherited permissions is the Full Control for the CREATOR OWNER identity. The permission that has to be added to the desired subtree root is:

r-xp--a-R-c--s:-------:allow

Well, beyond all the above, who knows, maybe someone can devise some useful and unanticipated sort of special access, but in general what's been seen is pretty much all about that.

With the knowledge of this post, it's not necessary to resort to a Windows box in order to set meaningful permissions according to Windows by using its GUI editors. You can do it from a Solaris 11.3 shell by using chmod(1).
   

NT4 & NFSv4 ACL mapping

This post is a development of another post, SMB & NFSv4 ACL mapping. It's specific to the Windows NT 4.0 (and before) family systems. If necessary, please, check back the aforementioned "parent" post.

The graphical interface of the ACL editors (Directory Permissions and File Permissions) are powerful yet reasonably nice, simple, concise and straightforward. And I mostly like it.

Let's focus just on the permissions sets which are listed on the "second colon" of the listboxes labeled Name for each user or group to which the ACL is to be enforced.

The first thing to note is that Directories Permissions have two pairs of parenthesis while Files Permissions just have one. On the former, the first pair of parenthesis refers to the permissions that apply just to the directory (not the files in it), while the second pair of parenthesis refers to the permissions of the (current or new) files in the directory (depending on the setting of the checkbox which text is Replace Permissions on Existing Files).

The second thing to note is that most of the permissions sets that are list on the dropdown-listbox labeled Type of Access are the "standard" ones (according to Windows). Whatever deviates from these is considered a Special Access case and treated accordingly in the interface.

The third thing to note is that on this world, exactly 6 permission flags (independent among each other) are recognized and they are as follows (but there are a few caveats around their names and effective meanings as it shall become more clear on the permissions sets below):

       Permission Flag
    R  Read 
    W  Write 
    X  Execute 
    D  Delete 
    P  Change Permissions 
    O  Take Ownership

The fourth thing to note is that from the Windows GUI ACL editors there's no direct way of telling if an ACL is being inherited or not. The rule is that if you override any ACL for a file system object than then what's previously inherited is copied alongside what's been changed.

Still solely from the Windows perspective let's summarize the ("standard", except for the Special Access) permissions sets as they are recognized by the system:

For directories:
                        Permission Set 
   (None  )   (None  )  No Access
   (R_X___)   (None  )  List
   (R_X___)   (R_X___)  Read
   (_WX___)   (None  )  Add
   (RWX___)   (R_X___)  Add & Read 
   (RWXD__)   (RWXD__)  Change
   (All   )   (All   )  Full Control
   (Other )   (Other )  Special Access


For files:
                        Permission Set 
              (None  )  No Access
              (R_X___)  Read 
              (RWXD__)  Change 
              (All   )  Full Control
              (Other )  Special Access
 

Now from the UNIX NFSv4 ACLs perspective each of the above permission set (interestingly) translates into the following (for simplicity here I'm intentionally omitting the name of the associated user or group that should be prefixed to each ACL):

No Access

 (None)(None)           rwxpdDaARWcCos:f-i----:deny
                        rwxpdDaARWcCos:-d-----:deny 

List

 (RX)(Not Specified)    r-x---a-R-c--s:-d-----:allow

Read

 (RX)(RX)               r-x---a-R-c--s:f-i----:allow
                        r-x---a-R-c--s:-d-----:allow

Add

 (WX)(Not Specified)    -wxp--aA-Wc--s:-d-----:allow

Add & Read

 (RWX)(RX)              r-x---a-R-c--s:f-i----:allow
                        rwxp--aARWc--s:-d-----:allow

Change

 (RWXD)(RWXD)           rwxpd-aARWc--s:f-i----:allow
                        rwxpd-aARWc--s:-d-----:allow

Full Control

 (All)(All)             rwxpdDaARWcCos:f-i----:allow
                        rwxpdDaARWcCos:-d-----:allow

NOTE

The preceding series of ACLs is formatted in terms of directory permissions but the same translation applies to file permissions if you consider just the second pair of parenthesis and the respective ACL inheritance flags (between both colons in my listing) which contain an f but removing both the f and i. For instance, the Full Control for a file is depicted by the ACL rwxpdDaARWcCos:-------:allow

So, as one can see, for directories, except when (Not Specified) is involved, each pair of parenthesis actually translates into 2 NFSv4 ACLs, one for the directory (which contains the d flag) and another (which contains the f flag) for files (for being implictly inherited by new files or overriden in existing files within the directory, this last case depending on the checkbox which text is Replace Permissions on Existing Files).

For attempting the ultimate fine-grained ACL mapping between NT4 and UNIX I'll put the following (hopefully) final listing of this (long) post:
 

 (Special Access)(R)    r-----a-R-c--s:-------:allow

 (Special Access)(W)    -w-p---A-Wc--s:-------:allow

 (Special Access)(X)    --x---a---c--s:-------:allow

 (Special Access)(D)    ----d--------s:-------:allow

 (Special Access)(P)    -----------C-s:-------:allow

 (Special Access)(O)    ------------os:-------:allow

Well, beyond all the above, who knows, maybe someone can devise some useful and unanticipated sort of special access, but in general what's been seen is pretty much all about that.

With the knowledge of this post, it's not necessary to resort to a Windows box in order to set meaningful permissions according to Windows by using its GUI editors. You can do it from a Solaris 11.3 shell by using chmod(1).