In Active Directory, the Deleted Objects container is a hidden location where objects reside temporarily after they have been deleted, before they are fully removed by the tombstone or recycle bin process. This container plays a critical role in object recovery and directory hygiene. By default, permissions on it are limited and the container itself is often overlooked since it is out of sight.
There are scenarios where administrators or delegated support staff need access to view or restore items in this container, especially when using the Active Directory Recycle Bin or troubleshooting accidental deletions. In this post we will look at what the Deleted Objects container is, why permissions need to be set on it, and how to configure those permissions for Microsoft Defender for Identity (MDI) .
One of the deployment tasks for MDI is to grant the Directory Service account permission to the Deleted Objects container in AD. By default, only the System account and members of the Administrators group can view the contents of this container. When Exchange Server is deployed, the Exchange Trusted Subsystem is also granted access.
MDI monitors directory activities in real time to detect identitybased threats such as reconnaissance, lateral movement, and privilege escalation. One critical aspect of this monitoring is tracking the lifecycle of user and computer accounts, including when they are deleted. For MDI to accurately correlate activities involving accounts that were recently removed, it must be able to:
- Detect account deletions in near real time
- Correlate security events and relationships involving deleted objects
- Resolve historical references
To achieve this, the directory access account requires read permissions on the deleted objects container in. This permission is readonly. MDI never modifies or restores deleted items.
There is sample code to assign the permissions in the documentation.
However, what do those permissions look like before and after?
Before Snapshot
This is a simple lab environment. The venerable dsacls tool was used to list the staring permissions.
DSacls.exe "CN=Deleted Objects,DC=Wingtiptoys,DC=ca”
If we use the article steps in LDP.exe to view the Deleted Objects container, these are the starting permissions as seen there:
Assign MDI Directory Service Account Permissions
In this example, the Directory Service account is a gMSA and there is an existing group that is used to grant access to the gMSA. This will also be used to grant access to the Deleted Objects container.
The group is called: Defender-Identity-gMSA-Access
In the sample code to assign the permissions in the documentation a new group is created, that step is not used here and the existing group is specified instead.
The code below was added to a local script file - .\MDI-Set-Deleted-Object-perms.ps1
# Specify the existing group in AD DS that will be used to grant the gMSA permission to the Deleted Objects container
$Identity = “Defender-Identity-gMSA-Access”
# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params
# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params
After Snapshot
Running the sample code above also reports the permissions before and after on the Deleted Objects container.
Note that the highlighted section is new as it pertains to the gMSA-Access group.
The same can be seen by re-running the initial DSAcls.exe query
Cheers,
Rhoderick
