Demystifying the NTDS #4

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:

sAMAccountNameATTm590045The account login used to identify the user or service that uses it. Example: bastien.lastname
objectSIDATTr589970Security Identifier(2). A unique identifier for each object. Example: S-1-5-21-7623811015-3361044348-030300820-1013
dBCSPwdATTk589879The LM password hash. This attribute is encrypted. See Part 3: Password Hashes.
unicodePwdATTk589914The NT password hash. This attribute is encrypted. See Part 3: Password Hashes.
pekListATTk590689Password Encryption Key. Encrypted similar to LM and NT hashes.
supplementalCredentialsATTk589949An encrypted attribute (using the same key as LM and NT hashes) that can contain the clear-text password.
servicePrincipalNameATTm590595The Service Principal Name (SPN) of a service account. Example: MSSQLSvc/COMPUTERNAME:1433
primarygroupATTj589922The primary group of the account. Example: RID 513 (domain user) or RID 515 (domain computer).
logoncountATTj589993The number of times a user has authenticated to the domain controller. This attribute is not replicated (in the case of multiple domain controllers).
badPwdCountATTj589836The 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.
descriptionATTm13The account description. This attribute is often used by administrators to store passwords. Automated verification tools(3) available on the Internet can be used.
whenCreatedATTl131074The date the account was created.
whenChangedATTl131075The last time the account was modified.
lastlogonATTq589876The last login date of the account on the domain controller. Note that this field is not replicated between different domain controllers.
lastLogonTimestampATTq591520The 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).
accountExpiresATTq589983The 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.
pwdLastSetATTq589920The date of the last password change.
userPrincipalNameATTm590480The full name of the account (login + domain). Example: bastien.lastname@xmco.lan
userAccountControlATTj589832Account properties such as enabled, disabled, locked, password does not expire, etc. All properties are available on the Microsoft website.
infoATTm131153An additional attribute to the “description” attribute that can contain additional information about the account.
operatingSystemATTm590187The system name. Example: Windows Server 2019 Standard
operatingSystemVersionATTm590188The system version. Example: 10.0 (17763)
operatingSystemServicePackATTm590189Service pack information. Example: Service Pack 1.
sIDHistoryATTr590433Contains previous SIDs used to reference the object if it has been moved from another domain.
adminCountATTj589974An 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:

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 CheckpointsAttribute 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 :






Bastien Cacace

Découvrir d'autres articles