Active Directory Permissions

Overview

Three products in the TontonTools suite access Active Directory: Delete Device Everywhere (DDE), Get Primary Device And Email From User (GPDEU), and Get Primary User And Email From Device (GPUED). The other seven products do not touch AD directly — they reach AD-sourced data through one of two indirect channels: SCCM (which has its own AD Discovery), or Microsoft Graph against Entra ID (which is synchronized from on-premises AD via Entra Connect). This page documents the AD permissions required by the three tools that touch AD directly and explains why the others don't need any AD grant at all.

Two ways the suite accesses Active Directory

The two access patterns are deliberate. DDE needs to delete computer objects — an operation that benefits from the explicitness and reliability of direct LDAP. GPDEU and GPUED need to read user attributes — an operation that is more conveniently expressed as a Get-ADUser PowerShell call. Both patterns are documented below so that AD administrators know exactly what to expect on the wire and what to grant on the operator accounts.

Pattern A — Direct LDAP via System.DirectoryServices (DDE only)

DDE uses DirectoryEntry and DirectorySearcher from System.DirectoryServices — the .NET namespace for direct LDAP access. The operator supplies an LDAP root path (e.g. LDAP://DC=corp,DC=contoso,DC=com) in the Credentials dialog. DDE then runs a search with the filter (&(objectClass=computer)(cn=<deviceName>)) to locate the computer object, reads its distinguishedName and selected attributes, and finally calls DeleteTree() followed by CommitChanges() to remove the object.

Pattern B — PowerShell ActiveDirectory module via RSAT (GPDEU, GPUED)

GPDEU and GPUED use PowerShell.Create() from System.Management.Automation to invoke the Get-ADUser cmdlet from the RSAT ActiveDirectory PowerShell module. The cmdlet, under the hood, talks LDAP to a domain controller — but from the operator's perspective, it's a standard PowerShell call against Get-ADUser -Identity <sam> -Properties <attribute>. The attributes the tools care about are mail (for email resolution) and displayName (for the friendly display name).

AD permissions required per tool

In Active Directory, default ACLs already grant most of what GPDEU and GPUED need (read access on standard user attributes is granted to Authenticated Users by default in most environments). DDE requires explicit delegation because deleting a computer object is not a default-allowed operation. The table below specifies what each tool needs, expressed as the minimum AD permission that must be granted to the operator account.

A common pattern: create an AD security group named (for example) DDE-Operators, grant it the "Delete computer objects" delegation on the OUs containing decommissioning candidates, and add operators to the group. The group can be removed entirely when DDE is no longer in use, without affecting any other system.

Why the other seven tools don't need AD permissions directly

A natural question for an AD administrator reading this page: if AUC, ADC, CDS, SIM, ODM, DDM, and ODC operate on identity-tied data — users, computers, groups — how can they function without any AD permission grant? The answer is that they consume AD data through two well-established relay systems, both of which already have their own credentials and their own permission models.

Relay 1 — SCCM Discovery brings AD data into the SCCM database

SCCM runs scheduled discovery cycles (Active Directory System Discovery, Active Directory User Discovery, Active Directory Group Discovery, and Active Directory Forest Discovery) that import AD objects into the SCCM database. From that moment on, querying SMS_R_System or SMS_R_User via WMI returns AD data — name, sAMAccountName, distinguishedName, group memberships, lastLogonTimestamp — without ever talking to a domain controller.

AUC, ADC, CDS, GPDEU, GPUED, and SIM rely on this relay. The AD permissions they would have needed (read on user / computer / group objects) are held by the SCCM site server's computer account (or a dedicated SCCM discovery account), not by the operator. The operator only needs SCCM permissions, documented separately.

Relay 2 — Entra Connect synchronizes AD objects into Entra ID, accessible via Graph

For hybrid-identity environments, Microsoft Entra Connect (formerly Azure AD Connect) replicates on-premises AD users, groups, and computers into Entra ID on a regular cycle. From the cloud side, these objects look like native Entra ID objects and are queried via Microsoft Graph (GET /users, GET /devices, GET /groups). The on-premises origin is exposed via attributes like onPremisesSyncEnabled, onPremisesLastSyncDateTime, and onPremisesDistinguishedName, but the access path is purely cloud.

ODM, DDM, and ODC are entirely cloud-driven. They never query AD, they never talk WMI to SCCM. Their identity-tied data comes from Entra ID via Graph, and the permissions they need are Graph permissions on the Entra ID App Registration — never an AD delegation.

Summary of the three identity-data chains

Prerequisites per tool

Authentication model

All three AD-touching tools authenticate to the domain controller as the signed-in Windows user via Kerberos (NTLM as automatic fallback). No service account is required, no credentials are typed, no LDAP bind string is sent over the wire. The operator simply needs to be logged into a domain-joined workstation with their own domain account.

For DDE specifically, the operator can override the default LDAP root path in the Credentials dialog if they need to query a non-default partition (e.g. a child domain, a different forest reachable via trust). The override changes the LDAP search base; it does not change the authentication mechanism. The bind is always under the current Windows session.

Verifying AD connectivity before using the tools

Three quick PowerShell checks cover the full AD-side prerequisites:

If the first check fails, the workstation is not on the domain (or DNS is misconfigured). If the second check fails but the first succeeds, a firewall is blocking LDAP. If the third check fails, install RSAT before using GPDEU or GPUED.

Common errors and how to fix them

For the SCCM permissions used by the six SCCM-touching products (including DDE, GPDEU, GPUED which use both SCCM and AD), see the SCCM permissions reference. For the Microsoft Graph permissions used by every cloud-touching tool, see the Microsoft Graph permissions reference. For the overall security and data-handling model, see Security & Data Handling.