Part 4: Active Directory Accounts
This article is about the Active Directory accounts that can be found in the NTDS database. As mentioned in the second part of this article series (LINK), accounts are objects stored in the datatable.
Types of accounts
We can distinguish three types of accounts in an Active Directory:
- User accounts: They generally have recognizable names that correspond to the user’s name (for example: f.lastname). In an enterprise, administrative accounts can be marked as such to easily identify them (e.g., f.lastname-adm);
- Machine accounts: They are usually named after the machine they correspond to, and their names end with a dollar sign “$” (for example, “COMPUTERNAME$”). When a domain has a trust relationship with another domain, the name of the latter also appears in the form of a machine account;
- Service accounts: These accounts are often named after the service they operate. Depending on usage, they can be managed service accounts (MSA (1)) which end with a “$” sign, machine accounts, or user accounts used to operate the target service. For example, a service account for SQLServer could be called “SQLService”.
When opening an NTDS database, accounts are associated with numerous attributes. From a security perspective, the following are interesting for us:
|sAMAccountName||ATTm590045||The account login used to identify the user or service that uses it. Example: bastien.lastname|
|objectSID||ATTr589970||Security Identifier(2). A unique identifier for each object. Example: S-1-5-21-7623811015-3361044348-030300820-1013|
|dBCSPwd||ATTk589879||The LM password hash. This attribute is encrypted. See Part 3: Password Hashes.|
|unicodePwd||ATTk589914||The NT password hash. This attribute is encrypted. See Part 3: Password Hashes.|
|pekList||ATTk590689||Password Encryption Key. Encrypted similar to LM and NT hashes.|
|supplementalCredentials||ATTk589949||An encrypted attribute (using the same key as LM and NT hashes) that can contain the clear-text password.|
|servicePrincipalName||ATTm590595||The Service Principal Name (SPN) of a service account. Example: MSSQLSvc/COMPUTERNAME:1433|
|primarygroup||ATTj589922||The primary group of the account. Example: RID 513 (domain user) or RID 515 (domain computer).|
|logoncount||ATTj589993||The number of times a user has authenticated to the domain controller. This attribute is not replicated (in the case of multiple domain controllers).|
|badPwdCount||ATTj589836||The number of invalid password attempts. This attribute is reset when the user enters the correct password or after a certain time defined in the domain settings. This attribute is not replicated.|
|description||ATTm13||The account description. This attribute is often used by administrators to store passwords. Automated verification tools(3) available on the Internet can be used.|
|whenCreated||ATTl131074||The date the account was created.|
|whenChanged||ATTl131075||The last time the account was modified.|
|lastlogon||ATTq589876||The last login date of the account on the domain controller. Note that this field is not replicated between different domain controllers.|
|lastLogonTimestamp||ATTq591520||The last login date of the account on the domain controller. Unlike lastlogon, this attribute is replicated by default only if the previous value is greater than 14 days(4).|
|accountExpires||ATTq589983||The date when the account can no longer be used (may be empty). When the account expires, it is still considered active in the “status” property.|
|pwdLastSet||ATTq589920||The date of the last password change.|
|userPrincipalName||ATTm590480||The full name of the account (login + domain). Example: firstname.lastname@example.org|
|userAccountControl||ATTj589832||Account properties such as enabled, disabled, locked, password does not expire, etc. All properties are available on the Microsoft website.|
|info||ATTm131153||An additional attribute to the “description” attribute that can contain additional information about the account.|
|operatingSystem||ATTm590187||The system name. Example: Windows Server 2019 Standard|
|operatingSystemVersion||ATTm590188||The system version. Example: 10.0 (17763)|
|operatingSystemServicePack||ATTm590189||Service pack information. Example: Service Pack 1.|
|sIDHistory||ATTr590433||Contains previous SIDs used to reference the object if it has been moved from another domain.|
|adminCount||ATTj589974||An attribute with an empty, 0, or 1 value. When the value is 1, the user is or was in a protected administration group. More information is available in this article(5).|
Default “built-in” accounts
When creating a domain, three “built-in” accounts are created:
- Administrator (RID 500): the default domain administrator account;
- Guest (RID 501): an account that allows limited access to a domain machine. By default, it is disabled, and its password is empty;
- Krbtgt (RID 502): a service account whose password is used in the Kerberos authentication process. This account is also disabled by default, and its password is randomly generated.
It is recommended not to use the Administrator account to administer the domain. This non-nominative account does not allow actions to be attributed to a specific user. The Administrator account should only serve as a backup account, and its password should be securely stored and audited.
Tips : To determine the creation date of a domain, you can simply note the creation date of any of the three accounts mentioned above.
The DSRM Administration Account
A lesser-known account called DSRM (Directory Services Restore Mode) is a local account that exists on each domain controller, allowing for the restoration of the Active Directory. This “break-glass” account is not stored in the NTDS.dit database because it needs to be accessible even if the NTDS.dit database cannot be read, such as when a domain controller starts in DSRM mode. It is worth noting that since update KB961320, an option is available to synchronize the DSRM account password with the built-in Administrator account. A persistence technique for an attacker who has compromised this account is described in the following article: https://adsecurity.org/?p=1714
What is the maximum number of accounts in an AD?
During our audits using our IAMBuster solution, we have audited Active Directories with over 250,000 accounts and a total number of SIDs around 500,000. This may seem like a lot, but according to the official documentation(6), the Active Directory service since Windows Server 2012 can handle a little over two billion SIDs throughout the life of a domain. This limitation stems from the fact that the Relative Identifier (RID) assigned to each object (accounts, groups, etc.) is limited to 31 bits (thus a maximum unsigned integer of 2,147,483,647) and is not reused.
Example of an object’s SID with the RID highlighted in bold.
Analyzing “account” objects is therefore essential during audits of the IAM (Identity and Access Management) aspect of Active Directory. This analysis helps to identify security flaws, hygiene issues, and organizational problems within a domain.
The attributes of the above accounts allow for a set of security checks, such as:
|Security Checkpoints||Attribute to Check|
|Is an account still in use?||lastLogonTimestamp|
|Has an account changed its password since creation?||whenCreated, pwdLastSet|
|Does my domain have outdated systems?||operatingSystem, operatingSystemVersion, operatingSystemServicePack|
|Does my domain have user accounts exposing an SPN?||servicePrincipalName|
|Do any user accounts originate from another domain?||sIDHistory|
|Are there accounts that do not have password expiration?||userAccountControl|
|Do any user accounts still have passwords in LM format?||DBCSPwd|
|Is Kerberos pre-authentication enabled for all accounts?||userAccountControl|
|How many accounts are locked or disabled?||userAccountControl|
|Is an account approved for Kerberos delegation?||userAccountControl|
|Has the “master key” of my domain been recently modified?||pwdLastSet du compte Krbtgt|
Example of graphs extracted from IAMBuster based on the user password change dates and the last login dates
1. Managed Service Accounts : https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-standalone-managed