AD object creation whenCreated review: approved provisioning

What Is an AD Object Creation Review?

An AD object creation whenCreated review connects recently created directory objects to approved provisioning. The useful outcome is a dated record showing which users, computers and groups were examined, who owns them, which request justified their creation and what evidence remains unresolved. A total of recent objects is a starting point for that work; it does not establish that the creations were malicious or approved.

Microsoft describes whenCreated as a system-set creation timestamp that is replicated and available in the global catalog. It supplies a date, not the identity of the requester or a business justification. Keep those evidence types separate throughout the review. Microsoft Learn: When-Created attribute.

The practical question is whether each observed creation belongs to a documented provisioning process. A new computer may be an expected deployment, a group may support an approved application and a user may be a legitimate joiner. Those possibilities need records and an accountable owner. Names, descriptions and a familiar OU can guide investigation, but they should not replace an approval record.

How It Works: Build a Dated Object Register

Start by recording the domain, search base, queried domain controller, collection time and review interval. Retain the collection settings and any errors alongside the object rows. This makes it possible to distinguish a directory observation from an assumption about what the collection covered.

Maintain one review row per stable object identifier, with the current distinguished name as a readable locator. Preserve population membership separately: an object returned in both the user and computer populations should retain both labels while contributing once to the unique-object register. This matters for group managed service accounts, which the collector's LDAP filters can include in both populations.

Use distinct collections for objects inside the interval, objects outside it, objects with an unavailable date and populations or locations that could not be read. A failed query is a failed observation. It cannot produce a trustworthy empty result. Likewise, an object excluded by a date filter has not been classified as approved.

The recurring AD audit workflow's weekly review of recent creations provides the operational cadence. This register supplies the object and provisioning evidence for that review. Preserve the review interval explicitly instead of treating a product's ten-day lookback as an organizational policy.

Detection: Read whenCreated with an Explicit Scope

Use a host with the Active Directory PowerShell module and an authorized directory reader. The examples below are documentation-based review queries, not commands executed against a customer directory. Replace the example domain and DC before use.

Get-ADObject documents -Filter, additional -Properties, -SearchBase, -SearchScope and -Server. The examples set -SearchScope Subtree to include the search base and its descendants. The filters below combine those parameters with the collector's three population definitions and a whenCreated lower bound. Microsoft Learn: Get-ADObject.

$reviewEnd = [DateTime]::UtcNow
$reviewStart = $reviewEnd.AddDays(-10)
$base = 'DC=contoso,DC=local'
$dc = 'dc01.contoso.local'
$properties = 'whenCreated','objectGUID','objectSid','objectClass'

$users = Get-ADObject -Filter {objectClass -eq 'user' -and (objectCategory -eq 'person' -or objectClass -eq 'msDS-GroupManagedServiceAccount') -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$computers = Get-ADObject -Filter {objectClass -eq 'computer' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$groups = Get-ADObject -Filter {objectClass -eq 'group' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

The lower-bound queries omit older and unavailable dates. For a separate scoped observation, read without a date predicate:

$scopeObjects = Get-ADObject -Filter * -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

That broader read is not equivalent to the three population queries. Classify its objects before comparison. By default the cmdlet excludes deleted objects; neither read reconstructs a complete historical directory.

Step 1: Preserve the Observation

Save the query definitions and their successful or failed outcomes before interpreting the rows. If a query stops with an error, record the error and the affected scope and investigate the collection failure. Do not substitute an empty array and continue as though the population was reviewed.

For returned dates, retain the original value and normalize the register display to UTC. Evaluate the lower boundary consistently: the collector uses a strict comparison after its reference time minus ten days. A timestamp exactly on that boundary is excluded. Its code has no upper bound at the reference time, so separately flag any returned date after the recorded review end instead of silently folding it into the normal interval.

Step 2: Reconcile Unique Objects

Combine observations by object GUID, retain all population labels and compare the resulting register with the collector's population counts. Explain differences through scope, limits, date handling and overlapping classes before treating them as unexplained creations. A deduplicated count can legitimately differ from the sum of user, computer and group observations.

Keep disabled accounts in the review. A disabled state does not answer why an object was created or whether its provisioning request was approved. The recent-objects detector itself does not exclude disabled users or computers.

Step 3: Connect Each Row to Provisioning

Ask the accountable owner to supply the request and approval evidence for the specific object. Match identifiers, intended class, location and purpose, rather than accepting a generic deployment ticket that could refer to several unrelated objects. Record disagreement between the request and observed object as a follow-up item.

An owner response without supporting evidence remains a statement to evaluate. Conversely, a missing response is unresolved provenance, not proof of attacker activity. Keep those outcomes distinct so that remediation targets the actual evidence gap.

Detection: Correlate Event ID 5137 Only with Proven Coverage

Event ID 5137 records directory object creation on a domain controller with success auditing enabled under Audit Directory Service Changes. Microsoft specifies that the parent object's SACL must audit the relevant Create action for the object class. Both controls must have applied before creation; retained local or central records must cover that time. Microsoft Learn: Event 5137.

Match ObjectGUID, supported by ObjectDN and ObjectClass, to the register. Preserve the event's UTC time, emitting DC and record identifier. SubjectUserSid, SubjectUserName and SubjectDomainName identify the requesting account. SubjectLogonId can support session correlation; it does not identify the human behind automation or prove approval.

The audit policy configuration guide explains why events must first be generated. For 5137, add parent Create SACL and retention evidence; the creation counter proves none of them.

Remediation: Resolve Unapproved Creation and Evidence Gaps

Remediation starts with the disposition of each object, not with reducing a recent-creation count. Approved provisioning should remain documented even while the object stays inside the lookback window. An unresolved creation needs an owner and an investigation path.

1. Complete the provisioning record. Attach the object identifier, request, approval and owner response to the review row. Confirm that the observed purpose and placement agree with the approved request. Record any justified exception and the person responsible for its resolution.
2. Escalate unexplained or inconsistent creation. Preserve directory observations and available event records. Ask the identity and service owners to assess the object's intended use and current exposure. Route confirmed unauthorized objects through the organization's incident and change processes, with an explicit containment decision.
3. Repair collection gaps. Review search bases, configured population limits and query failures. Repeat the scoped reads after the cause is addressed and retain the new observation time. Keep earlier failed observations in the register so the final record does not imply uninterrupted coverage.
4. Repair future event coverage. Have authorized administrators verify effective Directory Service Changes success auditing and the relevant parent Create SACLs. Check that retained archives can actually be searched. Validate future generation and collection through an approved test creation, then preserve the resulting evidence.
5. Verify closure against the register. Reconcile the refreshed unique-object register with approved provisioning and documented exceptions. Close only the decisions supported by evidence; carry unknown provenance and incomplete scope forward as open items.

Avoid automatic deletion or disabling based solely on age, an unfamiliar name or a missing creation event. Those signals justify investigation, while the remediation decision requires evidence about the object and its dependencies. The examples in this article perform directory reads; they do not authorize a directory change.

How EtcSec Detects This

At collector commit 9f698083354a1cb7f625df5cb490a515823c3257, RECENT_OBJECTS_CREATED is an Info finding. Its Detect() sums user, computer and group entries whose Created value is nonzero and strictly after DetectorData.Now - 10 × 24 hours. Ten days is a product heuristic. The comparison has no upper bound at Now, and the detector does not exclude disabled accounts.

The finding provides a total and the aggregate newUsers, newComputers and newGroups counters. It supplies no per-object AffectedEntities list and determines neither requester, intent nor authorization. The LDAP parsers obtain Created from whenCreated; absent values or formats not understood by parseADTime become zero and are excluded from this calculation.

Collection depends on BaseDN and MaxUsers, MaxGroups and MaxComputers. An error while retrieving any of the three populations stops collection. The populations can overlap: the user filter includes gMSAs and the computer filter can return the same objects. Consequently, the summed count is not a unique inventory of all AD objects.

Use this finding to initiate the independent register and provisioning review described above. A smaller count on a later audit can simply reflect objects aging beyond the lookback, a changed scope or a collection difference. Verify the review decisions and evidence directly before closing the work.