U.S. Patent and Trademark Office Active Directory Audit Findings
These were what I call a rare finds and its some really great real world reading into Active Directory security auditing and should be used as a security primer for any corporate network. Below is a link to a full report of deficient findings with the U.S. Patent and Trademark Office.
If you want the direct link to the actual PDF of the report:
Originally I found this in this article which has a lot of other data in relation to active directory security observations from other security companies.
Every system administrator should really have this slide hung up on their wall:
This is is also a really good slide to hang up on your wall so that system administrators can prioritize their active directory threats:
So lets dig a little deeper on prioritizing and remediating each threat.
LLMNR and NetBIOS poisoning (apply mitigation to Domain Controllers, Member Servers, and workstations)
Computer Configuration>Policies>Administrative Templates>MS Security Guide
Computer Configuration>Policies>Administrative Templates>Network>DNS Client
Require SMB Message signing (apply mitigation to Domain Controllers, Member Servers, and workstations)
Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options
Clear Text Credentials stored in memory (apply mitigation to Domain Controllers, Member Servers, and workstations)
Computer Configuration>Policies>Administrative Templates>MS Security Guide>WDigest Authentication
(Newer OS’s such as Windows 10, Server 2012 R2…etc has this disabled by default. For Auditing purposes I suggest having this disabled as part your GPO security strategy to re-enforce this setting)
Kerbtoasting or err Kerberoasting (apply mitigation to Domain Controllers, Member Servers, and workstations)
Article Reference on Kerberoasting:
Mitigation techniques to prevent kerberoasting and how to provide strong Kerberos encryption for Active Directory Domain Controller Environments.
Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options
(Choose AES128, AES256 and future encryption types)
(Optional)Enable on end user accounts that they support AES 128 and AES 256 bit encryption. If option above is set. Setting individual accounts to support Kerberos AES 128 or 256 should not be necessary.
Below illustrations the Kerberos Ticket Encryption Types on my login.
Service accounts should have atleast a random 25 character password to prevent Kerbtoasting attacks. Knowbe4 offers a free tool to do weak password testing in your domain environment. Its a quick win and can give you insight into weak or insecure passwords that may used on accounts in your environment. Below is a link to that free tool to audit your passwords:
How to secure Active Directory Ports and Services:
Microsoft has some excellent documentation on what ports are used for active directory up to 2012 R2:
A few notes about Active directory ports and services. SMB1 should be disabled on domain controllers. The admin templates to gain access to these settings can be found in Microsoft Security Compliance toolkit.
As I stated above LLMNR and Netbios should be disabled on domain controllers also.
Remote Desktop Protocol Observations: (Please deter use of RDP. Use powershell remoting instead)
Enterprise environments typically have access turned on for RDP client connections. At worse you can hop to any endpoint in a corporate network using RDP. When you import the domain controller baseline for Windows server 2019 you will have the following options set:
This does not turn on RDP but these security opens would automatically be enabled if RDP is turned on. One thing this baseline is missing is network level authentication for RDP. NLA should be turned on as an enhanced mitigation option for any unauthorized access to a workstation or server. This option can be found in the security section of remote desktop session host area in windows components.
Also if RDP access is turned on it should be limited to local administrators of member servers/workstations:
Personally I would deter the use of RDP especially if you migrate your domain controllers to server core (highly recommend doing to lower your threat surface). Instead please use Windows Admin Center. You will find that you can do pretty much everything in terms of administration through Windows Admin center or traditional MMC consoles.
Powershell Remoting is also an alternative to RDP especially on server core. PS Remoting is my go to especially on server core. By default Regardless of the transport protocol used (HTTP or HTTPS), PowerShell Remoting always encrypts all communication after initial authentication with a per-session AES-256 symmetric key. Also I would deter the use of doing IP based powershell remoting as the fallback method is NTLM. Kerberos does not support IP based powershell remoting. For more information about this and how to secure your experience I would suggest this document.
Also please do the following if you decide to use Powershell Remoting over RDP.
For extra points I would not make powershell remoting to your domain controllers available from anywhere. Within the WINRM Client section there is a setting to allow remote server management through WinRM. I would stick your /24 address of your PAW workstations or specific IP of a Jump box you have that has a static IP.
You can also do this through the windows firewall and define a remote IP or /24 address by doing the following on the Domain Controller throuh PowerShell:
Set-NetFirewallRule -DisplayName “Windows Remote Management (HTTP-In)” -Profile Domain,Private -RemoteAddress “172.16.2.1/24”
In this example this will modify the existing rule and allow any inbound traffic from any IP address matching 172.16.2.x.
Sample output:
(Note this will kick out the public firewall rule for this. Which should be fine.)
Collection of security baselines for Microsoft Operating Systems:
Alternative security Baselines:
(DISA Stigs)
(CIS Benchmarks)
PDF Guides are free. You will have to build Group Policy Objects manually if you are not a member.
(NSA Bitlocker Guidance)
These are archived by the NSA and is no longer maintained. They are still however worth a look:
Microsoft also has a good reference guide for securing active directory. This is probably one of the better places to start.
For workstation guidance in combination with maintaining active directory I would highly recommend going through Microsoft’s privileged access workstation material.
I will probably add a few more things to this post over time.
