We were recently working with a client who was trying to set up defender for identity and having difficulty. The resolution was not simple so we wanted to document this for benefit of everyone else who might be faced with the same.
Microsoft kindly provide a PowerShell script [https://github.com/microsoft/Microsoft-Defender-for-Identity/blob/main/Test-MdiReadiness/Test-MdiReadiness.ps1] to check that the Domain Services and Domain Controllers, CA servers and Entra Connect are correctly configured. Much of this is essentially group policy, auditing configuration and power profile configuration. Some additional steps are required for any virtualised machines. As you can see below this was the issue for the client. They simply couldn’t resolve the ObjectAuditing failure that is shown in red below.
The client had followed the configuration steps to the letter but still could not resolve this failure. So they asked HRP to take a look.
We first reviewed the steps from Microsoft [Configure audit policies for Windows event logs – Microsoft Defender for Identity | Microsoft Learn] to check if all the settings had been correctly applied. Which they had. How strange you say.
It’s worth noting at this point that the client only had Server 2019 and Server 2022 domain controllers across their estate.
According to the Microsoft setup instructions, the following Auditing permissions need to be set in order to correctly configure ObjectAuditing.
- Descendant User Objects
- Descendant Group Objects
- Descendant Computer Objects
- Descendant msDS-GroupManagedServiceAccount Objects
- Descendant msDS-ManagedServiceAccount Objects
- Descendant msDS-DelegatedManagedServiceAccount Objects (Only available to be selected if Server 2025 Domain Controllers are present)
All of which were set correctly that could be – since the client did not have any Server 2025 domain controllers.
Yet still the failure was present.
So next step was to review the PowerShell script and check what it was looking for. As you can see from the below it is expecting to see the following ACE entries with the relevant values for AccessMask and AuditFlagsValue.
ObjectAuditing = @
'SecurityIdentifier,AccessMask,AuditFlagsValue,InheritedObjectAceType,Description
S-1-1-0,852331,1,bf967aba-0de6-11d0-a285-00aa003049e2,Descendant User Objects
S-1-1-0,852331,1,bf967a9c-0de6-11d0-a285-00aa003049e2,Descendant Group Objects
S-1-1-0,852331,1,bf967a86-0de6-11d0-a285-00aa003049e2,Descendant Computer Objects
S-1-1-0,852331,1,ce206244-5827-4a86-ba1c-1c0c386c1b64,Descendant msDS-ManagedServiceAccount Objects
S-1-1-0,852075,1,7b8b558a-93a5-4af7-adca-c017e67f1057,Descendant msDS-GroupManagedServiceAccount Objects
S-1-1-0,852075,1,0feb936f-47b3-49f2-9386-1dedc2c23765,Descendant msDS-DelegatedManagedServiceAccount Objects
'@Next we turned our attention to the JSON file which is produced when the script is run. Thankfully this contains a bit more information that we can work with.
{
"ObjectAceFlags": 2,
"ObjectAceType": "00000000-0000-0000-0000-000000000000",
"InheritedObjectAceType": "7b8b558a-93a5-4af7-adca-c017e67f1057",
"BinaryLength": 40,
"AceQualifier": 2,
"IsCallback": false,
"OpaqueLength": 0,
"AccessMask": 852331,
"SecurityIdentifier": {
"BinaryLength": 12,
"AccountDomainSid": null,
"Value": "S-1-1-0"
},
"AceType": 7,
"AceFlags": 74,
"IsInherited": false,
"InheritanceFlags": 1,
"PropagationFlags": 2,
"AuditFlags": 1,
"AccessMaskDetails": "CreateChild, DeleteChild, Self, WriteProperty, DeleteTree, ExtendedRight, Delete, WriteDacl, WriteOwner",
"AuditFlagsValue": 1,
"AceFlagsValue": 74
},So this extract above is for the msDS-GroupManagedServiceAccount ACE entry. The only thing we noted is that the AccessMask value is not set to 852075. It’s 852331 like all the others. Makes sense give the same permissions have been applied to all the objects. So we fired up ldp.exe and took a look at the ACE entry which shows like all the others the Access mask has everything selected BUT Read property, List, List object, Read permissions and Write SACL.
So looking further having read [Access Rights and Access Masks – Win32 apps | Microsoft Learn] it seems that we have an extra 256 bits selected from what is intended. Obvious thought then that something needs removing from the mask – well you’d be wrong !!! It turns out the script whilst does return the AccessMask value doesn’t fail because of it.
So what now then. Well after having a long hard think and reviewing the PowerShell function that actually reports the failure it seems that because the msDS-DelegatedManagedServiceAccount ACE entry isn’t set it causes the script to report a failure. Really the script should be checking if there is a 2025 DC in operation and determining the result based on that. As for the AccessMask inconsistency – well we raised a case to Microsoft – which has literally been bounced around from Mindtree to Teknowledge and now to Convergys. What a shame Microsoft don’t have their own support staff. After all they developed the code.
We will update this post once we have feedback from Microsoft’s support teams.
Whilst that case is milling around within Microsoft’s support system we quickly spun up a VM running Windows Server 2025 and promptly installed AD Domain Services. We had to lift the schema as the Forest and Domain were still set to Windows Server 2012 R2…. So after many days of change paperwork and weeks of testing in pre-production we lifted the functional level. Once we’d done that we could promote it to a Domain Controller and hey presto our missing ACE was there to select in the list.
Now we have a full set of greens in the output.
Obviously we couldn’t post the clients domain in all the screenshots so this was reproduced in our HRP lab.