Demystifying the NTDS #4 - Active Directory Accounts

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”.

Attributes

When opening an NTDS database, accounts are associated with numerous attributes. From a security perspective, the following are interesting for us:

Property	Column	Description
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: bastien.lastname@xmco.lan
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.

 S-1-5-21-2718885639-921538116-1870948965-96387

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

References

1. Managed Service Accounts : https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-standalone-managed

2. https://learn.microsoft.com/en-US/windows-server/identity/ad-ds/manage/understand-security-identifiers

3. https://github.com/xalicex/AD-description-password-finder

4. https://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx

5. https://specopssoft.com/support/en/password-reset/understanding-privileged-accounts-and-adminsdholder.htm

6. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc756101(v=ws.10)?redirectedfrom=MSDN