When using either Group Managed Service Accounts (gMSAs) or Delegated Managed Service Accounts (dMSAs) (currently only possible Windows Server 2025 DCs), in addition to some account metadata, the KDS Root Key(s) available in the AD forest play a very important part in the password (re)calculation by the writable DCs (RWDCs) when servicing a managed password request from any server that uses the corresponding gMSA/dMSA. The set of “secret” data is stored in the msKds* attributes of the KDS Root Key Object. While the KDS Root Key object exists on ALL DCs in the AD forest, the secret data is only available on RWDCs (figure 1) and not on RODCs (figure 2). From any KDS Root Key object, the msKds* attributes are all part of the Filtered Attribute Set (FAS). All the attributes that are part of the FAS can be found when querying the Schema Partition using the filter “(&(objectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))“.
If you want to know which KDS Root Key is being used by any given gMSA or dMSA, when that KDS Root Key created, etc, etc, then I suggest you have a look at the following PowerShell code:
As the KDS Root Key objects contain the secret data to calculate previous, current or even future passwords using the metadata of ANY gMSA/dMSA account (see: Get-ADDBServiceAccount From DSInternals), you can imagine those KDS Root Key objects should be protected.
By default, nobody needs any access to the KDS Root Keys or their secret data, besides RWDCs for valid purposes, and obviously attackers for bad purposes like Golden gMSA Attack or Golden dMSA Attack.
To gain OFFline access to the KDS Root Key objects, the following actions should be audited/monitored to understand if those are valid or not:
- Stopping the NTDS Service on RWDCs
- Restarting the RWDC
- Creation of IFM Sets on RWDCs through NTDSUTIL or any other way
- Creation of snapshots on RWDC through NTDSUTIL or any other way using some VSS Provider
Officially, for ONline access, ONLY the RWDCs need access the KDS Root Key objects to (re)calculate the password of the corresponding gMSA/dMSA when servicing a managed password request from any server that uses the corresponding gMSA/dMSA. Nobody else should have or need access to any KDS Root Key object! But… are you also aware the any online access is NOT audited in any way by default? There is a solution to enable auditing for any access to any KDS Root Key object. This is done by configuring/enabling in ALL AD domains of the AD forest and configuring a SACL on “CN=Master Root Keys”!
STEP1: Configure And Enable Advanced Auditing In EVERY AD Domain In The AD Forest
- Make sure to use a GPO that targets all RWDCs of the AD domain
- Within the GPO configure: Computer Configuration > Policies > Windows Settings > Security Settgins > Local Policies > Security Options > Audit: Force Audit Policy Subcategory Settings (Windows Vista) To Override Audit Policy Category Settings = ENABLED (figure 5)
- Within the GPO configure: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access > Audit Directory Service Access = ENABLED for SUCCESS events (figure 6)
STEP2: Configure The SACL On The Object “CN=Master Root Keys” In The Configuration NC/Partition
The configuration of the SACL can be done in may ways, of them being the use of LDP. There is an easier way though, which is using the PowerShell code available through Configuring The SACL On The “Master Root Keys” Container To Audit Access To KDS Root Key. When running that PowerShell code should see something similar to what you see in figure 7.
To check for the correct configuration you can also use LDP
- Start LDP
- Connect to an RWDC and bind using the correct credentials
- Target the Configuration NC “CN=Configuration,DC=<YOUR FOREST ROOT DOMAIN>,DC=<YOUR TLD>”
- Navigate to
- “CN=Services,CN=Configuration,DC=<YOUR FOREST ROOT DOMAIN>,DC=<YOUR TLD>”
- “CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<YOUR FOREST ROOT DOMAIN>,DC=<YOUR TLD>”
- “CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<YOUR FOREST ROOT DOMAIN>,DC=<YOUR TLD>”
- Right-click on “CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<YOUR FOREST ROOT DOMAIN>,DC=<YOUR TLD>” > Advanced > Security Descriptor, then check SACL and click OK
You should then see something similar to what you see in the figure 8
When someone access the attribute “msKds-RootKeyData” of any KDS Root Key object, you should see something similar to figure 9 and figure 10.
But… as mentioned earlier, you should also expect RWDCs (figure 11) to access the attribute “msKds-RootKeyData” of a KDS Root Key object to be able to calculate the password of the corresponding gMSA/dMSA as requested.
Cheers,
Jorge
————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################
————————————————————————————————————————————————————
Identity | Security | Recovery
————————————————————————————————————————————————————-
Jorge's Quest For Knowledge! 