SOLVED

Remove dormant accounts from sensitive groups

Copper Contributor

Hi!

 

I'm having an issue with "remove dormant accounts from sensitive groups" in Secure Score. 

 

The sensors are installed on an old Active Directory domain, and i do not know the history of it. But i have several users that are removed from sensitive groups, but still remain in the list. And when checking the reason they get tagged as sensistive users in the Defender portal, the only reason listed is this:

 

"{Replicating Directory Changes permission on [{DomainReplicationAuthorizedIdsCount, plural, =0 {} =1 {{DomainReplicationAuthorizedIds}} other {# domains}}]{DomainReplicationAuthorizedIdsLinkify}}"


Has anyone been down this rabbit hole before and could shed some light on this issue?

14 Replies

@trond_kristiansen I am not sure how long you've waited after removing the groups, but I think you're aware it takes time for Secure Score to update. if it's longer than 24 hours, check the permissions for the account and groups in Actie Directory.

 

The permissions "Replicating Directory Changes permission" makes it possible to replicate all hashes for the entire domain which means a malicious actor has all "passwords" for all accounts within the domain. The attack is called "DC Sync" and it acts as a Domain Controller and synchronizes all hashes and other interesting information. By default, only Domain Administrators has "Replicating Directory Changes permission" permissions, but I recon the account does have these permissions as well.

 

If you open "Active Directory User and Computers" on a Domain Controller within the forest, right-click the domain and select "properties". On the  security tab, check the effective permissions for the user and find out if it's the user or group which has permissions to replicate directory changes.

 

For more information you can check the following learn page:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/grant-replicating-dir...

 

If you have any questions, please let me know.

@thalpius, thank you for your response.

Unfortunatly, the users in question does not have has "Replicating Directory Changes permission" permissions on the domain, so i'm still a bit lost.

Could it be other attributes or permissions it triggers on?

@trond_kristiansen I think it can, but looking at the message, I was assuming it's "Replicating Directory Changes permission" permission.

 

You can use the following PowerShell cmdlet to be sure (change the domain and user to your environment):

 

 

 

Import-Module ActiveDirectory
(Get-Acl "ad:\dc=domain,dc=local").Access | ? {$_.IdentityReference -match 'UserName' -and ($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or$_.ObjectType -eq "89e95b76-444d-4c62-991a-0facbeda640c" ) }

 

 

This contains the following control access right:

 

  • DS-Replication-Get-Changes-All
  • DS-Replication-Get-Changes
  • DS-Replication-Get-Changes-In-Filtered-Set

@thalpius! Thank you for helping out on this.

Still no luck. I did run Get-Acl as you suggested, but it does not show anything. I then tried an account i know has the Replicating Directory Changes permission, and the result was as it should.

So it must be something else it triggers on,.

I also assumed it had to do with "Replicating Directory Changes permission" 🙂 But i'm a bit out of suggestions..

@trond_kristiansen Aah ok. Didn't know you assumed about the permissions. Accounts become dormant if they are not used for a period of 180 days. There's a list of "sensitive groups" as well. I've created a blog post about this, maybe that helps:

https://thalpius.com/2023/07/11/microsoft-defender-for-identity-recommended-actions-remove-dormant-a...

@thalpiusI really appreciate your insight and effort on this matter. Sorry if i was a bit unclear in my problem description.

Your tips on how to find 'Replicating Directory Changes permission' was great. Especially the Get-Acl powershell code. Great blog about the sensitive groups too!

However, the users i'm struggeling with might have been in one of those groups at one time during the last 10-15 years. Most of these users have the 'adminCount' attribute set to '1', so i've tried clearing that attribute and enabled permission inheritance on the user objects, and one of those users actually disappeard from the list in Secure Score. But when checking that specific user in the defender portal, it's still marked as sensitive with the same message as from my original post.

So i'm still a bit confused as to why they are tagged as sensitve when they're not a member of any of the sensitive groups nor having any 'Replicating Directory Changes permission' on the domain.. 😐

@trond_kristiansen 

 

I have the exact same problem with two accounts in our domain as well. The accounts used to be "Domain/Enterprise Admins", but have since been disabled, and all administrative access removed. 

I've looked everywhere, and the accounts does not have the "Replicating Directory Changes permission" anywhere. 

The powershell commands shows nothing for the two affected accounts, but shows (correctly) that a full Domain/Enterprise Admin has those rights.

Så either the Defender for Identity sensor, triggers on something else, or there is some bug in the detection routines. 

I've had accounts previously, where I've removed administrative access, and the "Removed dormant accounts from sensitive groups" has cleared fine.

Didn't see the tip about adminCount=1, the first time I replied. Both my problem accounts had this, so I've tried clearing it now, and hopefully that will fix my problem.
I have the same issue, user previously had Enterprise Admin and admincount=1, has since been removed from all groups, I've tried setting admincount to null and 0, no security permissions on the account allow replicating directory changes yet it's still listed in the "remove dormant accounts from sensitive groups" in Secure Score and marked as sensitive in AAD.

I even tried removing the user from the sync to delete from AAD and then adding back but this did not work.

Did anyone find a workaround for this?
@Jings, @nick-365
Sorry for the late response to the both of you! No, i still havent found the originating reason for this, and the problem still remains. I would've loved to get to the bottom of it..
This evaluation by MS just doesn't appear to be completely accurate. My MSOL account for AD connect keeps showing up.
best response confirmed by trond_kristiansen (Copper Contributor)
Solution
On the 15th of february 2024, the two accounts I had listed as affected by "Remove dormant accounts from sensitive groups" finally cleared, and the Secure Score was updated as "Completed"
I have not changed anything for months, so I presume this is a fix thats rolled out from MS?
Can anyone else confirm this?

@Jings yes mine too! It seems finally MS have fixed this

Same result here! My list is down from about 20 accounts to 3, so it seems to be fixed! 🙂
@Jings, thank you for bringing this to my attention!
1 best response

Accepted Solutions
best response confirmed by trond_kristiansen (Copper Contributor)
Solution
On the 15th of february 2024, the two accounts I had listed as affected by "Remove dormant accounts from sensitive groups" finally cleared, and the Secure Score was updated as "Completed"
I have not changed anything for months, so I presume this is a fix thats rolled out from MS?
Can anyone else confirm this?

View solution in original post