Windows Security and ID Management Notes

The main source of information can be found at the Microsoft Documentation: Identity and access management.

Contents

• Security Identifier

• User Accounts

• Service Accounts

• Authentication

  • NTLM

  • Kerberos

Terms

Simple objects	Explanation
Security Principle	Users or groups and are represented as a Security Identifier (SID)
Resource	Has an owner - default will be the user who created it
Rights	Assigned to user accounts and authorizes users to perform specific actions e.g. interactive sign-on, file backup
Permissions	Are associated with objects
Objects	Are files/folders/printers/registry keys, AD DS Objects etc.
Container	Can contain other objects and can also inherit permissions
Expressions	Enhancements to access controls; they can allow/deny access to resources only when certain conditions are met e.g. device type or location
Security Principal	Can be an entity e.g. user account, computer, thread/process that runs in the security context of a user/computer account
Security Context	A process/group/user running in the security context of the account and has a unique SID issued by an authority e.g. DC

Claim

Is a unique piece of information about a user, device or resource that has been published by a DC e.g. title, health state

• User claims: AD attributes associated with a specific user

• Device claims: AD attributes associated with a specific computer object

• Resource claims: Global resource properties that are marked for user in authorization decisions and published in AD

Dynamic Access Control

Domain based and enables admins to apply access control permissions and restrictions based on well-defined rules that include the sensitivity fo resources, the job/role of the user, and the configuration of the device that's used to access the resources.

Basically, a user's permission can change dynamically if the user's role/job changes.

Central Access Policies

Authorization policies that include conditional expressions. They are an additional to local policies or DACLs (Discretionary Access Control Lists).

Central Access Roles

Expression of authorization rules that can include one or more conditions involving user groups, user claims, device claim and resource properties. They can be combined into a Central Access Policy.

Access token

A security token that is created every time a user sign-ins. It contains:

• the user's SID

• the user's rights

• the SIDs of any group it belongs to

It is the security context for whatever actions the user performs on that computer.

User sign-in -> Authenticated -> SID - Other         -> LSA generates an Access token (primary)
                                     - User/groups
                                     - Old? SIDs

A copy of the primary token is coped and attached to any thread/process that executes on the user's behalf.

• Primary token: describes the security context of the user associated with the process

• Impersonation token: enables a thread to run in a security context differs from the security context of the process that owns the thread

Security Identifier

A SID is used to uniquely identify a security principle or group. There are two types:

• Local SID: created by the Local Security Authority (LSA) and is stored in secure registry

• Domain SID: generated by the domain security authority and is stored as an attribute of the user/group in AD

SID structure

+-----------------------------------+
|SubAuthorityCount|Reserved|Revision|
+-----------------------------------+
|Identifier Authority               |
+-----------------------------------+
|SubAuthority[0]                    | Domain Identifier
|SubAuthority[1]                    |
|...                                |
|SubAuthority[n]                    | Relative Identifier
+-----------------------------------+

Identifier Authority

Highest level of authority that can issue SIDs for that type of security principal. For example:

• For the Everyone group -> World Authority

• For the specific Windows Server account -> NT Authority

SubAuthorities

These are most important; they collectively identify a domain in enterprise. The RID identifies the account/user relative to the domain - if the domain changes, it will also change.

String representation

S - R - X - Y1 - Y2 ... Yn - 1 - Yn

S: Indicates the string is a SID
R: Revision
X: Identifier Authority value
Y: Represents a series of subauthority values where n is the number of values

Example for Builtin Administrators Group:
S - 1 - 5 - 32 - 544

5: NT Authority
32 : Domain identifier (Builtin)
544: Administrator

SID history

Stores a user's SID history/ For example, if a user changes domains, they are stored in the access token. Access controls can access the old SIDs and still allow/deny access.

Security Descriptor

It is a data structure that's associates with each securable object. It contains:

• who owns it

• who can access it and in what way

• what types of access are audited

Structure:

ACLS - DACL
     - SACL

DACL

Discretionary Access Control List that identifies users/groups who are allowed/denied

SACL

System Access Control List which controls how access is audited

User Accounts

Local Accounts

They are stored locally on the server.

Default local users

• Created on OS installation

• No access to network resources

• Examples: Administrator, Guest, HelpAssist

Default Administrator

• Full control of all files/folders on local system

• Can create local users and assign permissions and rights

• Part of the Administrators group - this is a local group that domain admins will automatically be part of

• Recommended to rename this account but its SID will remain the same

Local System

• Admin account and part of the Administrators group

• For OS sign-in, Windows Installers etc.

• Can use the Administrator user account to perform Administrator tasks

User Access Control (UAC)

• Mechanism for elevating a process with Administrator privileges

• You can also configure UAC to make a user account with Administrator privileges behave like a non-administrator until escalation is required

Domain Accounts

• Equivalent of local accounts but at the domain level and are completely separate from local accounts

• They are store locally on the Domain Controller

• Examples: Administrator, KRBTGT

They do the following:

• Let the domain represent, identify and authenticate the identity of the user that's assigned to the account using unique credentials (usn/pwd).

• Authorize access to resources. After a user's credentials have been authenticated, the user is authorized to access the network and domain resources based on their rights and permissions

• Audit the actions that are carried out on a user account

Service Accounts

They are user accounts create explicitly to provide a security context for services.

Standalone Managed Service Accounts

Designed to isolate domain accounts in crucial applications and eliminates the need for Administrators to manually administer the SPN and credentials for the accounts.

• This service account can only manage one server - but it can manage multiple services on that server.

• The network passwords are automatically reset

• Admin tasks for managed service accounts can be delegated to non-admins

Group Managed Service Accounts

The same as standalone managed service accounts except they extend over multiple servers.

A client no longer needs to remember what service it needs to connect to; it only needs to authenticate itself against a single identity i.e. a group managed service account.

Virtual Accounts

They are managed local accounts that are automatically managed, can access the network in a domain environment and no password management.

Services run as virtual accounts access network resources using the credentials of the computer account in the format:

<domain_name>\<computer_name>$

LAB\SOME_SERVER$

Service Isolation

Usually computed using the service name and hashing it.

• A SID that is linked to a service's name and not the account it is running as

• The service SID is used authorize its access to resources

• The service account is used for authenticating a service

Authentication

SSPI

Security Support Provider Interface allows an application to use various security models available on a computer/network without changing the interface to the security system.

A SSP is contained in a DLL that implements SSPI by making one or more security packages available to applications.

NTLM

Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows OS and stand-alone systems. NTLM uses an encrypted challenge/response protocol to authenticate a user.

NTLM credentials are based on data obtained during the interactive logon process and consist of:

1. domain name

2. user name

3. one-way hash of user's password

Interactive NTLM authentication

Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept.

Non-interactive NTLM authentication

Non-interactive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.

1. Interactive authentication only - A user accesses a client computer and provides a domain name, user name and password. The client computes a cryptographic hash of the password and discards the actual password.

2. The client sends the user name to the server (in plaintext).

3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.

4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller:

   • User name

   • Challenge sent to the client

   • Response received from the client

6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.

7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Kerberos

SPN

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate.