Performing Active Directory Security Review

/in /by

Download the ADMustcheckReports.ps1 script below.

Note: You will need to extract the .ps1 after downloading the zip file, please review the help file.

The ADMustcheckReports.ps1 is a PowerShell scripts gathers basic data from AD Domain/forest that we believe enterprises must review on a regular basis and take necessary actions to remediate any weakness. You can further use CionSystems’ Free AD reporter for detailed AD assessment.

The PowerShell script requires the following:

  • PowerShell 5.0 (minimum)
  • Windows 7+ or Windows Server 2008 (or newer)
  • Active Directory PowerShell Module
  • Group Policy PowerShell Module

The PowerShell script gathers domain data using the Active Directory PowerShell & Group Policy modules and displays some results on the screen. The data shown on the screen is also saved to a transcript log file and all captured data is also saved to csv/text files in c:\temp\ADMustcheckReports.

The ADMustcheckReports PowerShell script gathers data for key AD security items in a domain:

  • User Account Issues
  • Groups
  • Trusts
  • Duplicate SPNs
  • Group Policies
  • AD Administration & Privileged Accounts
  • KRBTGT Account
  • Kerberos Delegation
  • Group Policy Object Owners
  • Much more…
# What is it? Recommendations
1 User Account Issues
There are several potential issues that Active Directory domain user accounts may have because these accounts can be configured in many different ways. Further they can be in different states with different user access control settings. The script shows the state of all users along with User accounts flags.
  • Disable and eventually delete inactive accounts. You must look at all domain controllers to figure out the inactive users as last login attributes are not replicated between DC’s.
  • Remove the following from accounts:
    • Reversible Encryption
    • Password Not Required
    • Password Never Expires
    • DES Kerberos Encryption Enabled
    • Do not require Kerberos Pre-Authentication
      • Review accounts configured with SID History and clean up SIDs in SID History for accounts from domains that no longer have trusts configured with them.
2 Domain Password Policy
The Domain Password policy determines how passwords are created and how often they need to be changed, etc. The AD default password minimum is 7 characters. Most AD environments we see have this set to between 8 and 10. Some are set to 0 or 3 or 5.Password Spray attacks are effective against Active Directory due to bad passwords (often with short minimum requirements).Increasing password length can limit Password Spray effectiveness. Fine-Grained Password Policies (FGPP) provides additional flexibility, especially for admin and service accounts.		 You can use CionSystems ADGuardian password protection to audit all passwords, enhance default AD password policies, remove duplicate passwords, force all users to change passwords if they are using passwords that has been breached
3 Tombstone Lifetime
 The AD Tombstone Lifetime determines how long deleted items exist in AD before they are purged. The default value is 180 days starting with new AD forests created with Windows 2003 SP1. While the tombstone lifetime directly affects deleted items, it also has an impact on Domain Controllers. If a DC hasn’t replicated within the tombstone lifetime with another DC, it is effectively orphaned from the domain. Additionally, DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.		 Systems state DC backups are only useful for restoring AD data within this tombstone lifetime – a backup that is 181 days old is no longer useful when the tombstone lifetime is 180 days.
4 Active Directory Backups
Microsoft supported backups update a partition attribute to identify the last backup date for that partition.		 Unlike CionSystems ADGuardian plus, not all backup solutions of Active Directory set this attribute since they are likely not using a Microsoft supported method.
5 Trusts
An Active Directory trust extends the security boundary and include other the systems that may not be in the domain yet they can access resources within the domain, thereby extending the authentication boundary.
  • Review trust configuration & ensure that trusts are appropriate at least once every month.
  • Review bidirectional trusts.
  • Check if trusts is needed with DMZ environments otherwise remove.
  • See if Selective Authentication works for your need.
6 Active Directory Duplicate Service Principal Names (SPNs) Make sure there are no duplicates!
7 Group Policy Preference Passwords
Group Policy Preferences was released in the 2008 time-frame and included capability to provide and update credentials. These credentials were encrypted using AES256 which sounds good until you realize that a static key is used to encrypt them. The cpassword value in the GPP xml files is the encrypted password. Using a PowerShell function from PowerSploit, we can reverse this encryption and get the plain-text value. Since authenticated users have read access to Group Policies in the SYSVOL share on all DCs, anyone can view this information and get the passwords stored in GPP xml files, even across trusts.
  • Ensure there are no Group Policy Preference passwords in SYSVOL.
8 Active Directory Admin Account Checks
During standard Active Directory Security Assessment, the focus must be on identifying “AD Admins” which includes members of the domain Administrators group, Domain Admins, Enterprise Admins, and other builtin groups etc. These accounts have full AD rights and require careful protection. Note, there may be other accounts with privilege access that may not show up in this list, if the access was granted using ACL’s modification
  • Ensure passwords change regularly (every year)
  • Disable inactive account
  • Remove disabled accounts
  • Ensure no SPNs on accounts associated with people
  • Remove any computer accounts
  • Scrutinize Service Accounts
  • What do they do?
  • Where do they run?
  • What computers do they authenticate to?
  • What rights are actually required?
9 AD Admin Accounts Not Member of Protected Users
Protected Users is a new group created when the domain PDC Emulator is running Windows Server 2012 R2. Full Domain protection is only available when the domain functional level is 2012 R2.
Protected Users group provides additional protections:
  • Kerberos AES authentication only (No Kerberos DSE/RC4 or NTLM)
  • No Kerberos delegation (constrained or unconstrained)
  • Kerberos TGT set to 4 hours
  • Credential delegation (CredSSP) will not cache the user’s plain text credentials
  • NTLM will not cache the user’s plain text credentials or NT one-way function
  • Offline sign-in is not supported
10 AD Admins with Old Passwords
AD Admin accounts with old passwords, especially those older than 3 months, are vulnerable to password spraying (and password guessing).
  • Ensure privileged account passwords change regularly. Use CionSystems password protection enhancer!
  • Older passwords are typically poor and easier to guess.
  • Password Spraying & Kerberoasting are popular attack methods for compromising accounts lacking strong passwords.
11 AD Admins with Kerberos Service Principal Names (SPNs)
Kerberos Service Principal Name or SPN is effectively the signpost that points to the service account for a service on a server that supports Kerberos authentication. When the client needs to connect to a service, it must request a Kerberos service ticket from a DC and in order to do this it needs to provide a SPN for that service. The DC looks up the account in the AD forest that has that SPN, identifies the account, and uses the account’s password data to encrypt the ticket. Once the service ticket is delivered to the service, it attempts to open the service ticket and if it can, it can assume the DC provided it, so it validates access for the user.
  • Ensure that no AD Admin accounts associated with people have SPNs.
  • Limit service account membership in privileged Active Directory groups and ensure these service account passwords are longer than 25 characters
  • Enhance password policies using CionSystems Password protection solution
12 Check Default Domain Administrator Account for Issues
  • The account password should change at least every month (and when an AD Admin leaves the organization).
  • Ensure the account has no SPNs.
  • Account should be rarely used which is not the case in most enterprises
  • The account can be enabled or disabled.
13 Review AD Default/Built-In Group Membership
Reviewing the default privileged groups in Active Directory is important to identify accounts with high-level privileges.
  • Leave only accounts that must require full AD rights are members of these groups. Use CionSystems ADGuardian to reduce the privilege accounts.
14 Default AD Groups: Administrators Default Rights:

  • Active Directory admin rights (for the domain)
  • Domain Controller admin rights (for the domain)

Reference:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-admins
15 Default AD Groups: Domain Admins Default Rights:

  • Membership in the domain Administrators group which provides most rights.
  • Active Directory admin rights (for the domain)
  • Domain Controller admin rights (for the domain)
  • Default rights on all domain Group Policies
  • Default local Administrator on all domain-joined computers

Reference:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-domainadmins
16 Default AD Groups: Enterprise Admins Default Rights:

  • Membership in every domain Administrators group which provides most rights.
  • Active Directory admin rights (in every forest domain)
  • Domain Controller admin rights (in every forest domain)
  • Default rights on all domain Group Policies
  • This group should remain empty in a single domain forest and membership very limited in a multi-domain forest.

Reference:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-entadmins
17 Default AD Groups: Server Operators This group is effectively “Domain Controller Admins” and members of this group should be scrutinized at a similar level to Domain Admins. This group has no default members.
Default Rights:

  • Default rights on Domain Controllers:
  • Log on locally
  • create and delete shared resources
  • start and stop some services
  • backup and restore files
  • format the hard disk
  • shut down the computer

Reference:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-serveroperators
18 Default AD Groups: Account Operators This group has no default members. This group should remain empty.
Default Rights:

  • This group has rights to most objects in the domain (users, groups, computers, etc).

Microsoft recommends this group remain empty.
PowerShell Sample Code & Results:
Get-ADGroupMember ‘Account Operators’

Reference:
 https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-accountoperators
19 Privileged Group: VMWare Admins Many enterprises have “VMWare Admins” or other such groups.

  • Ensure that “admin” groups only contain admin accounts.
  • Ensure that VMWare Admins follow privileged account best practices:
    • Use separate admin accounts
    • Use admin workstations
    • Passwords change about once a year
20 Krbtgt Password Not Changed Recently
The krbtgt account is the domain service account. This account is disabled but used for Kerberos Tickets. The password set when created & practically never changes. DC/AD backups contains the KRBTGT account password. If an attacker gains knowledge of this password, they can create Golden Tickets!
  • Change this password every year (DoD STIG requirement)
  • Change after AD admins leave

Reference:
Krbtgt Account https://adsecurity.org/?p=483 Golden Ticket Attack https://adsecurity.org/?tag=goldenticket
21 Kerberos Delegation
Kerberos Delegation Types:

  • Unconstrained: Impersonate users connecting to service to ANY Kerberos service.
  • Constrained: Impersonate authenticated users connecting to service to SPECIFIC Kerberos services on servers.
  • Constrained with Protocol Transition: Impersonate any user to SPECIFIC Kerberos services on servers. (aka “Kerberos Magic”)

Resource-based Constrained Delegation: Enables delegation configured on the resource instead of the account
  • Set all AD Admin accounts to: “Account is sensitive and cannot be delegated”
  • Add all AD Admin accounts to the “Protected Users” group (Windows 2012 R2 DCs).
  • Ensure service accounts with Kerberos delegation have long, complex passwords (preferably group Managed Service Accounts).
  • Remove delegation from accounts that don’t require it.
  • Don’t use Domain Controller SPNs when delegating.
  • Work to shift accounts with unconstrained delegation to constrained.
  • Restrict & monitor who has the ability to configure Kerberos delegation.
22 GPO Permissions: Review Owners
Group Policy Objects (GPO) has owners which are able to change permissions. Typically when an account creates a GPO, the account that created has delegate modify rights and it is configured as the owner.
  • Ensure all GPO owners are set to Domain Admins or Enterprise Admins, especially GPOs linked to the domain root and Domain Controllers OU.
23 Review Domain Permissions
Domain permissions should be reviewed to ensure that configuration is appropriate. Security of the domain often depends on proper domain permissions.
  • Review domain root permissions with special attention paid to any non-default admin groups (Domain Admins, domain Administrators, Enterprise Admins, etc) with GenericAll (Full Control), WriteDACL (change permissions), write property (modify), and Extended Rights.
  • Ensure that the domain root owner is configured to Domain Admins or Enterprise Admins.
24 Domain Controllers Running Old Versions
Domain Controllers must be running Microsoft supported Windows versions. You can run all Windows Server 2012 R2 DCs even with older Windows Server versions in the domain (note that some testing to ensure Windows 2003/XP works with the new DCs, especially for SMB shares).		 All DCs should be running a minimum of Windows Server 2012 R2, preferably 2016/2019
25 AD Forest Functional Level / Domain Functional Level Older than Domain Controller Operating System
  • Ensure all Domain Controllers are updated to Windows Server 2012 R2 (or newer) and set DFL/FFL to 2012 R2 (or newer).
  • Change the domain level only after understanding all the implications!