My previous post detailed the steps of how to recover from a "lost" password for the default built-in Active Directory Administrator user account. The solution works great for standard Active Directory (AD) environments, but some AD environments follow recommended best practices to secure their AD infrastructure beyond the basics. Locking down the default built-in Active Directory Administrator user account is one of them.
Here are a few strategies used to secure the default built-in Active Directory Administrator user account:
Our solution will be able to work with each of these strategies on a Windows Server 2008 (or later) AD domain controller.
Prerequisite
I will assume you have read my previous post and are "stuck" at the point where you need to enter a specific AD Administrator user account username for the custom service.
Our first task is to obtain access to the AD database.
Mount the Active Directory (AD) database
So we are presently in Directory Services Repair Mode (DSRM) which means our Active Directory database (ntds.dit) is currently offline. Our objective is to mount the database, so we can query for information about AD Administrator user account objects.
Open two command prompt windows. The first window will be controlled by the dsamain.exe process. The second window will be used for our interactive commands.
Tip: If using Server Core, you can launch another command prompt window by running the command 'start cmd' from the first window.
Before we run the dsamain.exe tool, we need to verify another process is not currently using port 389. From the second command prompt window, run the following command:
We should expect no output from the result of running the command at this stage.
The AD/DS/LDS offline data browser (dsamain.exe) tool allows us to mount the AD database and run LDAP queries against it. We will run the tool with a few options:
Now from the first command prompt window, run the following command:
Let's verify the dsamain.exe process is ready and listening on port 389. Run the following command from the second command prompt window:
Verify Process ID 604 is our dsamain.exe process by running the following command from the second command prompt window:
Strategies
It looks like we are good to go at this point. Since we set the port number to the default LDAP port number with our AD database mount, we can leverage the ds* tools from the local server. Now let's see how we can tackle each of the following scenarios.
# Renamed default Administrator account
How do we determine if the default built-in Active Directory Administrator user account was renamed?
The default built-in Active Directory Administrator user account has a well-known security identifier (SID) with a syntax of S-1-5-21-[domain]-500, so we can perform a query for user objects and filter on the result set. The following chain of commands will satisfy our requirement. Run the following from the second command prompt window:
The output shows the default built-in Active Directory Administrator user account's Security Account Manager (SAM) name has been renamed to mr.bean.
We can now go ahead and use mr.bean as the username value for our custom service.
The AD database can now be dismounted. The dsamain.exe process can be stopped by using the Ctrl+C key combination with the first command prompt window in the foreground. Look for the Active Directory Domain Services was shut down successfully. message in the output for confirmation.
# Decoy Administrator account
How do we determine if a decoy for the default built-in Active Directory Administrator user account was created?
This should be simple enough. We know the distinguished name (DN) of the default built-in Active Directory Administrator user account, so we can just query the security group membership for the user account. Run the following command from the second command prompt window:
The output demonstrates even though this looks like the privileged default built-in Active Directory Administrator user account, the group membership proves it's just a normal domain user account with the inherent limits.
The following strategy will provide a solution to find a "real" Administrator user account.
# Disabled default built-in Active Directory Administrator user account with a secondary Administrator account
Another strategy is to create a secondary Administrator user account and disable the default built-in Active Directory Administrator user account. How do we determine if this strategy was implemented?
I recommend we first perform a recursive query for the membership of the built-in Administrators security group. I like this command because it not only returns members of the default built-in Active Directory Administrators group but also members of the groups within the group (Domain Admins and Enterprise Admins specifically). Run the following command from the second command prompt window:
We speculate the default built-in Active Directory Administrator user account is disabled. We can verify this by running the following command from the second command prompt window:
So we have verified the default built-in Active Directory Administrator user account is currently disabled, our next task is to determine what other user account has the same level of power as the default built-in Active Directory Administrator user account. The john.doe user looks interesting. Let's check it out. Run the following command from the second command prompt window:
Everything looks good so far. Let's compare this account's security group membership with the default built-in Active Directory Administrator user account. Run the following command from the second command prompt window:
And for the default built-in Active Directory Administrator user account, run the following command from the second command prompt window:
Looks like a match to me. We can now go ahead and use John Doe's samid property as the username value for our custom service.
The AD database can now be dismounted. The dsamain.exe process can be stopped by using the Ctrl+C key combination with the first command prompt window in the foreground. Look for the Active Directory Domain Services was shut down successfully. message in the output for confirmation.
Here are a few strategies used to secure the default built-in Active Directory Administrator user account:
- Rename the default built-in Active Directory Administrator user account
- Create a decoy Active Directory Administrator account
- Create a secondary Administrator user account and disable the built-in Administrator user account
Our solution will be able to work with each of these strategies on a Windows Server 2008 (or later) AD domain controller.
Prerequisite
I will assume you have read my previous post and are "stuck" at the point where you need to enter a specific AD Administrator user account username for the custom service.
C:\> sc create ResetPW binPath= "%ComSpec% /k net user administrator PA$$w0rd94" start= auto
Our first task is to obtain access to the AD database.
Mount the Active Directory (AD) database
So we are presently in Directory Services Repair Mode (DSRM) which means our Active Directory database (ntds.dit) is currently offline. Our objective is to mount the database, so we can query for information about AD Administrator user account objects.
Open two command prompt windows. The first window will be controlled by the dsamain.exe process. The second window will be used for our interactive commands.
Tip: If using Server Core, you can launch another command prompt window by running the command 'start cmd' from the first window.
Before we run the dsamain.exe tool, we need to verify another process is not currently using port 389. From the second command prompt window, run the following command:
C:\> netstat -ano | findstr :389
We should expect no output from the result of running the command at this stage.
The AD/DS/LDS offline data browser (dsamain.exe) tool allows us to mount the AD database and run LDAP queries against it. We will run the tool with a few options:
- The dbpath parameter value is the file system path to the ntds.dit file.
- The allowNonAdminAccess switch allows us to query the AD database with our local administrator user account. This switch is important because the default setting will only allow members of the Domain Admins and Enterprise Admins security groups to query the mounted database.
- The ldapPort option sets a custom LDAP port number for the dsamain.exe process. We will be using the default LDAP port number (389).
Now from the first command prompt window, run the following command:
C:\> dsamain -dbpath C:\Windows\NTDS\ntds.dit -allowNonAdminAccess -ldapPort 389
Let's verify the dsamain.exe process is ready and listening on port 389. Run the following command from the second command prompt window:
From the output, we can determine a process (with a Process ID of 604) is listening on TCP port 389.
C:\> netstat -ano | findstr :389
TCP 0.0.0.0:389 0.0.0.0:0 LISTENING 604
TCP [::]:389 [::]:0 LISTENING 604
TCP 0.0.0.0:389 *:* 604
TCP [::]:389 *:* 604
Verify Process ID 604 is our dsamain.exe process by running the following command from the second command prompt window:
C:\> tasklist /fi "pid eq 604" /fo list
Image Name: dsamain.exe
PID: 604
Session Name: Console
Session#: 2
Mem Usage: 13,116 K
Strategies
It looks like we are good to go at this point. Since we set the port number to the default LDAP port number with our AD database mount, we can leverage the ds* tools from the local server. Now let's see how we can tackle each of the following scenarios.
# Renamed default Administrator account
How do we determine if the default built-in Active Directory Administrator user account was renamed?
The default built-in Active Directory Administrator user account has a well-known security identifier (SID) with a syntax of S-1-5-21-[domain]-500, so we can perform a query for user objects and filter on the result set. The following chain of commands will satisfy our requirement. Run the following from the second command prompt window:
C:\> dsquery user -s localhost | dsget user -s localhost -samid -sid | findstr /c:"-500"
mr.bean S-1-5-21-2092397264-2003686862-3249677370-500
The output shows the default built-in Active Directory Administrator user account's Security Account Manager (SAM) name has been renamed to mr.bean.
We can now go ahead and use mr.bean as the username value for our custom service.
C:\> sc create ResetPW binPath= "%ComSpec% /k net user mr.bean PA$$w0rd94" start= auto
The AD database can now be dismounted. The dsamain.exe process can be stopped by using the Ctrl+C key combination with the first command prompt window in the foreground. Look for the Active Directory Domain Services was shut down successfully. message in the output for confirmation.
# Decoy Administrator account
How do we determine if a decoy for the default built-in Active Directory Administrator user account was created?
This should be simple enough. We know the distinguished name (DN) of the default built-in Active Directory Administrator user account, so we can just query the security group membership for the user account. Run the following command from the second command prompt window:
C:\> dsget user "CN=Administrator,CN=Users,DC=example,DC=internal" -s localhost -memberof -expand
"CN=Domain Users,CN=Users,DC=example,DC=internal"
"CN=Users,CN=Builtin,DC=example,DC=internal"
The output demonstrates even though this looks like the privileged default built-in Active Directory Administrator user account, the group membership proves it's just a normal domain user account with the inherent limits.
The following strategy will provide a solution to find a "real" Administrator user account.
# Disabled default built-in Active Directory Administrator user account with a secondary Administrator account
Another strategy is to create a secondary Administrator user account and disable the default built-in Active Directory Administrator user account. How do we determine if this strategy was implemented?
I recommend we first perform a recursive query for the membership of the built-in Administrators security group. I like this command because it not only returns members of the default built-in Active Directory Administrators group but also members of the groups within the group (Domain Admins and Enterprise Admins specifically). Run the following command from the second command prompt window:
The output has identified a couple of user accounts in addition to the Domain Admins and Enterprise Admins security groups.
C:\> dsquery group -s localhost -samid "administrators" | dsget group -s localhost -members -expand
"CN=Domain Admins,CN=Users,DC=example,DC=internal"
"CN=Enterprise Admins,CN=Users,DC=example,DC=internal"
"CN=Administrator,CN=Users,DC=example,DC=internal"
"CN=john.doe,CN=Users,DC=example,DC=internal"
We speculate the default built-in Active Directory Administrator user account is disabled. We can verify this by running the following command from the second command prompt window:
We notice two important pieces of information from the output. This is the default built-in Active Directory Administrator user account because of the well-known security identifier (SID), and the account is currently in the disabled state.
C:\> dsget user "CN=Administrator,CN=Users,DC=example,DC=internal" -s localhost -samid -sid -disabled
samid sid disabled
Administrator S-1-5-21-2092397264-2003686862-3249677370-500 yes
dsget succeeded
So we have verified the default built-in Active Directory Administrator user account is currently disabled, our next task is to determine what other user account has the same level of power as the default built-in Active Directory Administrator user account. The john.doe user looks interesting. Let's check it out. Run the following command from the second command prompt window:
C:\> dsget user "CN=john.doe,CN=Users,DC=example,DC=internal" -s localhost -samid -sid -disabled
samid sid disabled
john.doe S-1-5-21-2092397264-2003686862-3249677370-1107 no
dsget succeeded
Everything looks good so far. Let's compare this account's security group membership with the default built-in Active Directory Administrator user account. Run the following command from the second command prompt window:
C:\> dsget user "CN=john.doe,CN=Users,DC=example,DC=internal" -s localhost -memberof -expand
"CN=Group Policy Creator Owners,CN=Users,DC=example,DC=internal"
"CN=Domain Admins,CN=Users,DC=example,DC=internal"
"CN=Enterprise Admins,CN=Users,DC=example,DC=internal"
"CN=Schema Admins,CN=Users,DC=example,DC=internal"
"CN=Domain Users,CN=Users,DC=example,DC=internal"
"CN=Denied RODC Password Replication Group,CN=Users,DC=example,DC=internal"
"CN=Administrators,CN=Builtin,DC=example,DC=internal"
"CN=Users,CN=Builtin,DC=example,DC=internal"
And for the default built-in Active Directory Administrator user account, run the following command from the second command prompt window:
C:\> dsget user "CN=Administrator,CN=Users,DC=example,DC=internal" -s localhost -memberof -expand
"CN=Group Policy Creator Owners,CN=Users,DC=example,DC=internal"
"CN=Domain Admins,CN=Users,DC=example,DC=internal"
"CN=Enterprise Admins,CN=Users,DC=example,DC=internal"
"CN=Schema Admins,CN=Users,DC=example,DC=internal"
"CN=Domain Users,CN=Users,DC=example,DC=internal"
"CN=Denied RODC Password Replication Group,CN=Users,DC=example,DC=internal"
"CN=Administrators,CN=Builtin,DC=example,DC=internal"
"CN=Users,CN=Builtin,DC=example,DC=internal"
Looks like a match to me. We can now go ahead and use John Doe's samid property as the username value for our custom service.
C:\> sc create ResetPW binPath= "%ComSpec% /k net user john.doe PA$$w0rd94" start= auto
The AD database can now be dismounted. The dsamain.exe process can be stopped by using the Ctrl+C key combination with the first command prompt window in the foreground. Look for the Active Directory Domain Services was shut down successfully. message in the output for confirmation.
