Fundamentals of Windows Security Vol 9 rel 4

The Security Principal 

A Windows security principal is an authenticated entity that uses the resources (e.g., files, printers), applications, or services that a Windows computer hosts. A security principal can be a user, computer, or group of users or computers. Each security principal has a unique identifier that's known as a SID.

What Is a SID Number?

A Security Identifier (SID) is a unique, immutable identifier of a user, user group, or other security principal. A security principal has a single SID for life (in a given domain), and all properties of the principal, including its name, are associated with the SID.  SIDs are created when the account is first created in Windows and no two SIDs on a computer are ever the same.

Why Does Windows Use SIDs? 
People, or humans prefer to identify entities by names, like "Ralph" or "Sara", but computers only understand numbers; hence, Windows uses the SID when dealing with accounts internally. This design allows a principal to be renamed (for example, from "Jane Smith" to "Jane Jones") without affecting the security attributes of objects that refer to the principal. 

While a username can be changed as many times you like, you're unable to change the SID that's associated with an account without having to manually update all the security settings that were associated with that user to rebuild its identity. 

So even if you have users with the same name, they will be assigned a new SID.  That being said, if a person leaves the company, it is common practice to disable the user rather than delete, this way, if a replacement new employee comes along you can just rename the old user and enable the new one who now gets all the permissions and access privileges of their predecessor without much fuss. 

Finding the SID for a particular User 

There are many reasons why you might want to find the security identifier (SID) for a particular user's account in Windows, but in our corner of the world, the common reason for doing so is to determine which key under HKEY_USERS in the Windows Registry to look for user-specific registry data. 

Regardless of the reason for your need, matching SIDs to usernames is really easy thanks to the wmic command, a command available from the Command Prompt in most versions of Windows. 

How to Find a Your SID With WhoAmI

To Find a SID of Current User using "WhoAmI" command 

1. 1. Open a command prompt or PowerShell. 
2. 2. Enter the command below, and press Enter. 

 whoami /user 

How to Find a User's SID With WMIC 

It'll probably only take a minute, maybe less, to find a user's SID in Windows via WMIC: 

Open Command Prompt. 

In Windows 10 and Windows 8, if you're using a keyboard and mouse, the fastest way is through the Power User Menu, accessible with the WIN+X shortcut. 

If you don't see Command Prompt in the Power User Menu, type cmd into the search bar in the Start menu, and click Command Prompt when you see it. 

Note: You don't have to open an elevated Command Prompt for this to work. Some Windows commands require it, but in the WMIC command example below, you can open a regular, non-administrative Command Prompt. 

Type the following command into Command Prompt exactly as it's shown here, including spaces or lack thereof: 

 

...and then press Enter. 

To Find User Name for SID using "wmic useraccount" command  

1. Open a command prompt or PowerShell. 

2. Enter the command below, and press Enter. 

 wmic useraccount where sid='<sid>' get domain,name 

 Substitute <sid> in the command above with the actual SID (ex: "S-1-5-21-237214570-1361766723-3061440971-1001") of the account you want to see the name for. 

Decoding SID Numbers in Windows 

From the above illustration, it can be surmised that all SIDs start with S-1-5-21 but will otherwise be unique.


There are other standard designations, such as, the SID for the Administrator account in Windows always ends in 500. The SID for the Guest account always ends in 501 (like the Levi’s Jeans). 

You'll also find SIDs on every installation of Windows which correspond to certain built-in accounts. 

For example, the S-1-5-18 SID can be found in any copy of Windows you come across and corresponds to the Local System account, the system account that's loaded in Windows before a user logs on. 

Here's an example of a user SID: S-1-5-21-1180699209-877415012-3182924384-1004. Yours will be different, but the purpose of each part of the SID remains the same: 

   

Any group or user that was manually created (i.e., not included in Windows by default) will have a Relative ID of 1000 or greater. 

The following are a few examples of the string values for groups and special users that are universal across all Windows installs: 

S-1-0-0 (Null SID): Assigned when the SID value is unknown, or for a group without any members. 

S-1-1-0 (World): This is a group of every user. 

S-1-2-0 (Local): This SID is assigned to users who log on to a local terminal. 

How Is a SID Number Used? 

The SID of an AD domain account is created by a domain's security authority that runs on every Windows domain controller (DC). The SID of a local account is created by the Local Security Authority (LSA) service that runs on every Windows box. 

Access Control Entries 

Access control entries (ACE) are entries in an access control list containing information describing the access rights related to a particular security identifier or user. Each access control entry contains an ID, which identifies the subject group or individual. Each ACE controls or monitors access to an object by a specified trustee.  

There are six types of ACEs, three of which are supported by all securable objects. The other three types are Object-specific ACEs supported by directory service objects. 

All types of ACEs contain the following access control information: 

• A security identifier (SID) that identifies the trustee to which the ACE applies. 
• An access mask that specifies the access rights controlled by the ACE. 
• A flag that indicates the type of ACE. 
• A set of bit flags that determine whether child containers or objects can inherit the ACE from the primary object to which the ACL is attached. 

The following table lists the three ACE types supported by all securable objects. 
 

Access Control Lists 

An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: a DACL and a SACL. 

A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether to grant access to it. If the object does not have a DACL, the system grants full access to everyone. If the object's DACL has no ACEs, the system denies all attempts to access the object because the DACL does not allow any access rights. The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied. For more information, see How DACLs Control Access to an Object. For information about how to properly create a DACL, see Creating a DACL. 

A system access control list (SACL) enables administrators to log attempts to access a secured object. Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. For more information about SACLs, see Audit Generation and SACL Access Right. 

Do not try to work directly with the contents of an ACL. To ensure that ACLs are semantically correct, use the appropriate functions to create and manipulate ACLs. For more information, see Getting Information from an ACL and Creating or Modifying an ACL. 

ACLs also provide access control to Microsoft Active Directory service objects. Active Directory Service Interfaces (ADSI) include routines to create and modify the contents of these ACLs. For more information, see Controlling Access to Active Directory Objects. 

ACE/ACL - How Does All This Work? 

Assume there’s a user ‘Max Paine’ who wants to access a file on a file share on a server. For Max to access a Word document, an ACE containing Max’s SID should have been created when his user was created.   

Now, assuming Max was included in a group that has access to the specified file in the file share.  So, before Max can access any resource on the network, he has to be authenticated by the Domain Controller – once he logs in with his password, he is given a “token” which includes his SID, Group SIDs, List of privileges, access, etc. 

What is a Token? 

An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread. When a user logs on, the system verifies the user's password by comparing it with information stored in a security database. If the password is authenticated, the system produces an access token. Every process executed on behalf of this user has a copy of this access token. 

The system uses an access token to identify the user when a thread interacts with a securable object or tries to perform a system task that requires privileges. Access tokens contain the following information: 

• The security identifier (SID) for the user's account 
• SIDs for the groups of which the user is a member 
• A logon SID that identifies the current logon session 
• A list of the privileges held by either the user or the user's groups 
• An owner SID 
• The SID for the primary group 
• The default DACL that the system uses when the user creates a securable object without specifying a security descriptor 
• The source of the access token 
• Whether the token is a primary or impersonation token (impersonation token, an access token that has been created to capture the security information of a client process, allowing a server to "impersonate" the client process in security operations). 
• An optional list of restricting SIDs 
• Current impersonation levels 
• Other statistics 

Every process has a primary token that describes the security context of the user account associated with the process. By default, the system uses the primary token when a thread of the process interacts with a securable object. Moreover, a thread can impersonate a client account. Impersonation allows the thread to interact with securable objects using the client's security context. A thread that is impersonating a client has both a primary token and an impersonation token. 

Use the OpenProcessToken function to retrieve a handle to the primary token of a process. Use the OpenThreadToken function to retrieve a handle to the impersonation token of a thread.  

Back to Max 

Now that Max has this token, he can access resources on the network.  Suppose he is trying to access a file share on the network.  Now, the file share has an ACL that lists all authorized entities.  His token is transferred to the fileserver.  The fileserver compares the SIDs of the token with the SIDs of the file share.  If there is a match, access is granted. 

So, the question is, “Can a hacker pretend he is an authorized user by counterfeiting a token?”  Rest assured this would be nearly impossible, for the token are generated much like a certificate with a secret key; hence, this wouldn’t be the best approach for a breach. 

Key Takeaways  

• 
  
• Security Principal is an entity that can be authenticated (user, group, process) 
• When a user, group, or process is created, a unique SID is created with it. 
• A SID is transferrable – just change the name associated with it. 
• Delete the user, you delete the SID, so to be safe and save time disable vs. Delete. 
• Access Control Entities contain A security identifier (SID) that identifies the trustee, access rights, type of Entity, and inheritance flags. 
• Access Control Lists contain ACE identifies the trustees that are allowed or denied access to a securable object 
• Tokens are secret key protected entities that have a user's identity and privileges of the user account associated with the process or thread. 

___________________________________________

We would like to thank our sponsors, for without them - our fine content wouldn't be deliverable!

Rick's Cafe' American

____________________________________________

Source(s)

• https://www.lifewire.com/what-is-an-sid-number-2626005
• https://www.lifewire.com/how-to-find-a-users-security-identifier-sid-in-windows-2625149
• https://www.itprotoday.com/windows-78/understanding-well-known-security-principals-part-1
• https://en.wikipedia.org/wiki/Security_Identifier
• https://docs.microsoft.com/en-us/windows/win32/secauthz/access-control-lists
• https://docs.microsoft.com/en-us/windows/win32/secauthz/object-specific-aces
• https://www.tenforums.com/tutorials/84467-find-security-identifier-sid-user-windows.html
• https://docs.microsoft.com/en-us/windows/win32/secauthz/access-tokens
• https://docs.microsoft.com/en-us/windows/win32/secauthz/access-tokens

So “Once more unto the breach, dear friends, once more;”

____________________________________________________________

About Rick Ricker

An IT professional with over 23 years experience in Information Security, wireless broadband, network and Infrastructure design, development, and support.
For more information, contact Rick at rwricker@gmail.com