I'm in the process of cleaning up my Active Directory and I've come across some unknown SIDs that have permissions set at the domain root and various organizational units. After doing some thorough checks, it's clear that these SIDs are orphaned permissions.
However, when I attempt to remove them through Active Directory Users and Computers (ADUC) by navigating to security settings, I receive a warning about adding 122 new permissions to the access control list. I canceled the first time because it altered the domain root permissions in an unexpected way, leaving gaps except for the usual administrative groups like administrators and domain admins. I even restored the permissions from a backup of the SDDL after that mishap.
I've tried using ADSI Edit but faced the same issues, and my attempts to script a removal using CMD's DSACLS didn't work either. I really need to get rid of these orphaned SIDs since they hold administrative delegated permissions at the root level. Does anyone have advice on how to tackle this? Thanks for the help!
3 Answers
The security dynamics of Active Directory can be tricky for sure. I recommend checking out Hack The Box for some good remediation techniques to help fix your issue.
You might want to check around in other forums focused on Active Directory for more ideas. Those unexplained changes in the ACL could be related to other security groups tied to your privileged accounts. Normally, I'd escalate situations like this to the Enterprise Admin since they manage an account with minimal permissions specifically for handling these kinds of problems.
Man, dealing with orphaned SIDs can be a real headache! First off, did you back up AD before experimenting with the script or ADSI edit? Assuming you have a backup, I’d suggest trying PowerShell commands to handle this:
1. Use `Get-ACL` and `Set-ACL` for more control than what DSACLS offers:
```
$acl = Get-ACL "AD:"
$acl.RemoveAccessRule()
Set-ACL "AD:" $acl
```
2. Check the inheritance settings because that warning about new permissions could stem from that. Try turning off inheritance at the domain root, remove the orphaned SID, and then turn inheritance back on.
3. If you feel up for it, ntdsutil might be an option for deeper conflicts.
4. As a last resort, consider reaching out to Microsoft Support for assistance.
Just ensure you have a revert plan in place before diving into these changes!
Solid advice here; those warnings can look scary but often make sense when you evaluate what gets inherited. Just be thorough with your backups before making changes.
I'm with you on the inheritance theory. I recommend fetching the ACLs via PowerShell or checking them out through ADUC, and then cleaning up the permissions. It can feel daunting, but once you get the hang of it, it’s manageable. If you're cautious, consider simulating with NTFS permissions to get a better grasp of how changes affect your setup. Good luck!