- Overview
- Securing Built-in Administrator Accounts
- Creating Management Accounts for Protected Accounts and Groups
- Enabling Management Accounts to Modify the Membership of Protected Groups
- Testing the “Enabling” Accounts
- Testing the “Management” Accounts
- External References
Overview
Within Active Directory, there are three built-in groups that comprise the highest privilege groups in the directory, plus a fourth group, the Schema Admins (SA) group:
Securing Built-in Administrator Accounts
Securing Built-in Administrator Accounts on Domain Members
In Active Directory users and computers navigate to the Users container and locate the Administrator account and open Properties.
Go to the Account tab and later to Account Options. Enable the Account is sensitive and cannot be delegated flag on the account.
Note: Original best practices recommended disabling the account. This was removed as the forest recovery white paper makes use of the default administrator account. The reason is, this is the only account that allows logon without a Global Catalog Server.
Create and link a GPO to your domain members (servers, workstations) but make sure you don’t apply it to domain controllers. You can give it the name ‘Securing Built-in Administrator Accounts’.
In one or more GPOs that you create and link to workstation and member server OUs in each domain, add each domain’s Administrator account to the following user rights in
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments:
Deny access to this computer from the network
Deny log on as a batch job
Deny log on as a service
Basically we are saying here, on any domain member, do not allow the domain built in Administrators group (EXAMPLE\Administrators), domain built in Administrator (EXAMPLE\Administrator) or local member Administrators group member to be able to log in as a service or as a batch script and don’t allow the domain member to be accessed from the network.
Note: When you implement restrictions on the Administrators group in GPOs, Windows applies the settings to members of a computer’s local Administrators group in addition to the domain’s Administrators group.
Deny log on through Remote Desktop Services
Regarding RDP, we want to restrict only to the domain built in Administrator account, and local Administrator account. DO NOT include the Administrators group.
This is how the settings should look like:
Securing Built-in Administrator Accounts on Domain Controllers
In each domain in the forest, the Default Domain Controllers policy or a policy linked to the Domain Controllers OU should be modified to add each domain’s Administrator account to the following user rights in Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments:
- Deny access to this computer from the network
- Deny log on as a batch job
- Deny log on as a service
- Deny log on through Remote Desktop Services
Note: These settings will ensure that the local Administrator account cannot be used to connect to a domain controller, although the account, if enabled, can log on locally to domain controllers. Because this account should only be enabled and used in disaster-recovery scenarios, it is anticipated that physical access to at least one domain controller will be available, or that other accounts with permissions to access domain controllers remotely can be used.
Here are the GPO settings:
As is the case with the Enterprise Admins (EA) and Domain Admins (DA) groups, membership in the built-in Administrators (BA) group should be required only in build or disaster recovery scenarios. There should be no day-to-day user accounts in the Administrators group with the exception of the Built-in Administrator account for the domain.
Creating Management Accounts for Protected Accounts and Groups
Creating a Group to Enable and Disable Management Accounts
Creating accounts that can be used to manage the membership of privileged groups are described in the step-by-step instructions that follow:
- First, you should create a group that will be granted the necessary privileges in order to manage the accounts (management accounts), because these accounts should be managed by a limited set of trusted users. If you do not already have an OU structure that accommodates segregating privileged and protected accounts and systems from the general population in the domain, you should create one. Although specific instructions are not provided in this appendix, screenshots show an example of such an OU hierarchy.
- Create the management accounts. These accounts should be created as “regular” user accounts and granted no user rights beyond those that are already granted to users by default.
- Implement restrictions on the management accounts that make them usable only for the specialized purpose for which they were created, in addition to controlling who can enable and use the accounts (the group you created in the first step).
- Configure permissions on the AdminSDHolder object in each domain to allow the management accounts to change the membership of the privileged groups in the domain.
We can proceed as follows:
Create a new OU in your structure that would indicate that it is used for managing AD.
Inside this OU we can create a new Group which will contain the members that can activate the management accounts. If this group will manage the whole forest, make it an Universal group.
Right-click the group you just created, click Properties, and click the Object tab. In the group’s Object property dialog box, select Protect object from accidental deletion, which will not only prevent otherwise-authorized users from deleting the group, but also from moving it to another OU unless the attribute is first deselected.
Next we add the users that will be in charge of activating the management accounts.
Now under advanced security, disable inheritance and convert the existing permissions to explicit permissions.
Remove groups that should not be permitted to access this group. Leave a minimum set of object permissions in place. Leave the following ACEs intact:
- SELF
- SYSTEM
- Domain Admins
- Enterprise Admins
- Administrators
- Windows Authorization Access Group (if applicable)
- ENTERPRISE DOMAIN CONTROLLERS
Creating the Management Accounts
Create a new AD account and in the Account Options field, select the following and click OK:
- Account is disabled flag,
- User cannot change password flag,
- Account is sensitive and cannot be delegated flag,
- This account supports Kerberos AES 128 bit encryption flag
- This account supports Kerberos AES 256 encryption flag
Also select the checkbox to Protect object from accidental deletion.
Note: Because this account, like other accounts, will have a limited, but powerful function, the account should only be used on secure administrative hosts.
Clear the Enable remote control flag.
On the Network Access Permission field, select Deny access. This account should never need to connect over a remote connection.
Note: Should circumstance ever require the account to log on to an RODC, you should add this account to the Denied RODC Password Replication Group so that its password is not cached on the RODC.
Although the account’s password should be reset after each use and the account should be disabled, implementing this setting does not have a deleterious effect on the account, and it might help in situations in which an administrator forgets to reset the account’s password and disable it.
Under advanced security, disable inheritance and convert permissions to explicit.
Next, click Add. Select a principal and then search for the AD group that will enable the AD management accounts.
Next in the permissions, scroll to the bottom of the dialog box and click Clear all to remove all default permissions. Clear all.
Scroll to the top of the Permission Entry dialog box. Ensure that the Type drop-down list is set to Allow, and in the Applies to drop-down list, select This object only. In the Permissions field, select Read all properties, Read permissions, and Reset password.
In the Properties field, select Read userAccountControl and Write userAccountControl.
In the Group or user names field of the Security tab, remove any groups that should not be permitted to access or manage the account. Do not remove any groups that have been configured with Deny ACEs, such as the Everyone group and the SELF computed account (that ACE was set when the user cannot change password flag was enabled during creation of the account. Also do not remove the group you just added, the SYSTEM account, or groups such as EA, DA, BA, or the Windows Authorization Access Group.
Check the Advanced and ensure its similar to the following example.
This configuration part is complete.
Enabling Management Accounts to Modify the Membership of Protected Groups
Now we will configure permissions on the domain’s AdminSDHolder object to allow the newly created management accounts to modify the membership of protected groups in the domain. This procedure cannot be performed via a graphical user interface (GUI).
Log on to your the domain controller that is also the PDC Emulator role holder with Domain Admins credentials.
Open a command prompt as Administrator and run the following while replacing the distinguished name of your AdminSDHolder and the UPN of the security principal. In my case it’s like this:
Dsacls CN=AdminSDHolder,CN=System,DC=example,DC=com /G leo@example.com:RPWP;member
Run SDProp manually instead of waiting.
Open as Administrator the Ldp.exe tool.
In the Ldp dialog box, click Connection, and click Connect. In the Connect dialog box, type the name of the domain controller for the domain that holds the PDC Emulator (PDCE) role and click OK.
Next click Connection and click Bind. If your account has permission to modify the rootDSE object you can Bind as currently logged on user.
Once the bind operation completes, click Browse, and click Modify. In the Modify dialog box, leave the DN field blank. In the Edit Entry Attribute field, type RunProtectAdminGroupsTask, and in the Values field, type 1. Click Enter to populate the entry list.
To check, click Properties on the Domain Admins security group, go to Security, Advanced and select Edit.
Verify that the account has been granted only Read Members and Write Members permissions on the DA group, and click OK.
We repeat the previous steps for other protected groups in the domain; the permissions should be the same for all protected groups.
Note: Any account that has permission to write membership of a group in Active Directory can also add itself to the group. This behavior is by design and cannot be disabled. For this reason, you should always keep management accounts disabled when not in use, and should closely monitor the accounts when they’re disabled and when they’re in use.
Testing the “Enabling” Accounts
Logon to a host as a member of the enabling accounts group.
Open AD Users and Computers and validate that you can enable the new management account and set a new password.
Confirm that the “Enabler“ account cannot perform other activities on the “Management“ account. Try changing the name of the account, enabling remote control and changing group membership.
Testing the “Management” Accounts
Logon to a host as a management account.
Open AD users and computers and navigate to Domain Admins group. Try to add a new user account.
Confirm that the “Management“ account cannot perform other activities. Try changing the name of the group, description, etc.
Repeat these steps for additional protected groups as needed.
When finished, log on to a secure administrative host with an account that is a member of the “Enablers“ group. Then reset the password on the management account and disable the account.
You have completed setup of the management accounts and the group that will be responsible for enabling and disabling the accounts.
External References
Appendix I – Creating Management Accounts for Protected Accounts and Groups in Active Directory
Marius Ene 