This page will document different measures that are implemented for hardening and maintenance of the Security Test Domain Controller.
Setting up Active Directory
For information on how to setup a Windows 2016 Server as a domain controller, see the excellent write-up on Microsoft’s technet blog.
Creating a Backup for Disaster Recovery and Auditing
A backup was created for Disaster Recovery and Auditing using ntdsutil.exe using an Administrator Command Prompt with the command: ntdsutil.exe “activate instance ntds” snapshot create quit quit. Then, mounting the snapshot and making it available through an LDAP query using “dsamain.exe -dbpath C:\$SNAP_20180825044_VOLUMEC$\Windows\NTDS|ntds.dit -ldapport 9999”.
Global Catalog Replication
Currently, our configuration only utilizes one domain controller, but if we implement another for this, or future projects, we would fully implement Global Catalog(GC) replication. Two GCs per site is the recommended configuration, as a GC comprises a bit more than half of the Active Directory database. This replication can take place over specific RPCs and SMTP transports that already exist. To confirm Global Catalog is enabled: open Active Directory Sites and Services > Sites > Servers, right clicking on NTDS Settings and ensuring “Global Catalog” is checked.
Using SYSKEY for Encryption
SYSKEY creates a 128-bit RC4 key called the System Key. This encrypts numerous things, including: users’ passwords in Active Directory or the local SAM database, user’s master keys that are used for protection of private keys and digital certificates, LSA secrets in the registry, protection key for the local admin account password that is used when booting into safe mode. This key is typically stored locally with a a complex obscuring function in the registry, but it is important to keep in mind that this can still be hacked.
For our initial project, we are utilizing a user that has a local group administrator account. However, we fully recognize the importance of using least privileges in an organization and will document implementation of best practice permissions configurations when we’ve wrapped up the initial project.
For testing purposes, we created a group, Receptionists, that have advanced permissions to edit contact information of users. In addition, the ability to add computers to the domain for all users but administrators has been changed from its default value of 7 to 0 to prevent non-administrative users from adding computers to the domain.
Delegation of Control
In our mock organization, a Help Desk group and OU were created and granted additional privileges above a standard user to: Reset user passwords and force password change at next logon. This can be done using by right clicking a user or group and selecting “Delegation Control Wizard”.
Creating the Help Desk OU, group, and user:
Using the Delegation of Control Wizard:
Using a GPO to restrict MMCs for Help Desk
For our Help Desk group, we do not want them to have the ability to revoke or modify existing privileges on machines that are out of the scope of their job functions. To curtail this, we have restricted what MMCs those belonging to the Help Desk group are able to utilize. This will not fully stop a user with malicious intent, but is one more road block and annoyance that they have to deal with. Similar protections will be configured for all standard users when the initial project is finished.