redircmp redirusr default containers group policy: AD guide

What Are Default Containers in Active Directory?

The practical question behind redircmp redirusr default containers group policy is where new identities land, and whether that location belongs to the policy structure you intended. Active Directory supplies CN=Computers and CN=Users when the domain is installed. They are containers, rather than organizational units. Microsoft's container redirection guidance explains their default role, while its Group Policy overview identifies an OU as the lowest level in AD at which Group Policy can be assigned.

You cannot link a GPO directly to these default containers. That does not mean their computers and users receive no Group Policy: site-linked and domain-linked GPOs can still apply, and local policy remains relevant. The gap is more specific. An object in CN=Computers sits outside the subtree of a policy linked only to your workstation or server OU. Microsoft's Redircmp reference confirms the absence of a direct Group Policy link to the default container. The site, domain, and OU scope rules are documented in the Group Policy overview cited above.

This guide separates four questions: where objects currently reside, where future default creation will place them, which policies actually reach the client, and which computer accounts need a provisioning review. A default-container finding answers the first question. Redirection addresses the second. Neither establishes the client's LAPS state or the security of a staged machine account.

How It Works: Destination and Policy Scope Are Separate

Default creation follows a directory reference

Microsoft documents the default destinations in the domain's wellKnownObjects attribute. Older creation APIs consult these references for users, groups, and computers. The redirection utilities change those references to administrator-selected OUs; they do not turn the original containers into OUs. New objects created through the affected default paths then use the new destination. KB324949 describes both the references and the operations that depend on them.

A join workflow can also supply a destination explicitly. The netdom join reference documents /ou and states that account creation uses the domain's default computer destination when that option is omitted. In a standard, unredirected installation that is CN=Computers; after redirection it can be the designated OU. An existing account reused for a join presents another case. Therefore, avoid assuming every join necessarily creates a new object in the default container.

For users, redirusr affects the default creation location of users, groups, and trust user accounts created through the documented APIs. Placement of a group does not mean the group itself processes user configuration like a signed-in user. Keep account inventory and policy processing distinct, and preserve the default accounts unless a separately reviewed change requires otherwise. S1 describes the broader set of objects affected by the Users destination.

OU placement creates an eligible path, not a completed control

Group Policy scope follows links at sites, domains, and OUs, including the relevant parent OU hierarchy. Moving a computer into an intended OU can bring it under that hierarchy, but it is still necessary to validate processing and the intended settings. Microsoft's overview describes the location-based scope and client-side processing.

Our GPO security filtering guide addresses the next layer: link scope, computer Read, user Apply, and the distinction between granting retrieval and broadening the audience. Its thesis is that the right location and a linked policy are insufficient without the required permissions and processing conditions. Use that review after correcting placement.

LAPS adds its own deployment requirements. Microsoft's AD-backed Windows LAPS procedure separates device write permission, password retrieval permission, device policy, and verification of directory updates. Consequently, a computer outside an OU that is the only source of its LAPS policy may have a coverage problem; a computer receiving equivalent policy through another supported route may not.

The related LAPS coverage gaps guide examines partial deployment, legacy storage, excessive recovery rights, and the evidence needed to validate rotation. It provides the follow-up review when placement exposes a possible gap. Counting computers in CN=Computers is not a measurement of computers without LAPS.

Measure Placement Before Changing Defaults

1. Inventory computers in the default container

Use a defined domain and record the search base, collection time, enabled state, and object identifiers. The following reader example adapts the documented Filter, SearchBase, SearchScope, and Properties parameters from Get-ADComputer. The domain and object names throughout this guide are fictional placeholders.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

The intention is to enumerate direct children for a placement review. This query includes disabled accounts, whereas the reviewed EtcSec placement detector excludes them. Keep those populations separate when comparing results. An administrative inventory and a detector count need not be identical because their predicates differ.

A container count measures directory placement, not protection coverage. Decide which objects belong in production, which are approved staging accounts, and which need investigation. For each object, record the proposed destination and responsible owner. These are review decisions; the command provides directory data rather than an assessment of endpoint protection.

2. Inventory users without treating the container as one account class

The following example substitutes the default Users container into the documented container-search pattern and requests enabled state through Properties. Get-ADUser documents both parameters:

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

This retrieves users, rather than a complete inventory of every group and special object in the container. Microsoft's redirection guidance specifically discusses default groups and trust user accounts. Before migration, distinguish ordinary users from built-in or application-dependent accounts and establish which objects must remain in place.

Review the source and destination together. A user moved to a different OU can enter a different user-policy hierarchy, just as a computer can enter a different computer-policy hierarchy. Use the Group Policy scope model to identify the expected change before moving the object, rather than treating a cleaner directory view as the completion criterion.

3. Review the machine-account provisioning signal separately

A computer can be staged in an appropriate OU and still require review. Conversely, an active computer in the default container need not match the staging signal. To obtain the underlying attribute, this example uses the documented Properties parameter from Get-ADComputer:

Get-ADComputer -Filter * -Properties userAccountControl

Microsoft's UserAccountControl reference assigns PASSWD_NOTREQD the value 0x20 and WORKSTATION_TRUST_ACCOUNT the value 0x1000. The collector combines them into 0x1020, decimal 4128, and tests whether both bits are present. The exact predicate is discussed below; do not substitute an equality test against the entire attribute.

For matching accounts, ask who created the object, what provisioning request it supports, whether the intended machine has joined, and what independent activity evidence exists. Establish a local review period with the account owner. The detector supplies no age threshold and no verified join history, so neither belongs in a purported detector result.

Detection: Correlate Directory Signals with Client Results

A misplaced object is a candidate for a scope review

Treat placement as a signal to investigate the intended policy relationship. Record the baseline GPOs expected for the computer, their link locations, and the client's actual results. The gpresult documentation defines Resultant Set of Policy reporting and the computer scope and summary switches used here:

gpresult /scope computer /r

Run the documented reader check on the concerned computer with the appropriate access. Compare applied GPOs with the expected baseline, then verify the settings that matter. A report showing policy application is different evidence from a successful LAPS backup or the effective state of an audit setting. No output from a real domain is claimed in this article.

For native AD-backed Windows LAPS, Microsoft's deployment procedure identifies event 10018 as evidence that a new password was successfully updated in AD. Use it as a separate outcome check where that deployment applies. A missing event requires investigation of timing and available logs; it is not proof derived from the object's DN.

Historical default passwords require version context

Pre-creation can be a legitimate workflow. Microsoft's domain join permissions guidance describes one administrator creating a computer account and another authorized identity reusing it. A staged account deserves lifecycle management, but staging alone does not establish a compromise.

There is a distinct historical risk. The NetProvisionComputerAccount reference documents an explicit option that uses the lowercase machine name as the initial password and recommends avoiding that option where possible. This describes a particular provisioning mode. The UAC mask does not read the secret and cannot establish that the option was used, that a password is empty or predictable, or that authentication succeeded.

Version matters. Microsoft's Windows Server 2025 changes describe randomly generated initial computer-account passwords, controls rejecting name-derived defaults, and ADUC/ADAC no longer allowing pre-Windows 2000 account creation. The documented policy is Domain controller: Refuse setting default machine account password. Check domain-controller versions, creation tools, and this policy before applying the historical model to current accounts. An abandoned identity still needs an owner and a lifecycle decision even when its initial secret was random.

Remediation: Redirect Future Creation and Migrate Existing Objects

1. Design the target OUs and their responsibilities

Choose target OUs according to administration and policy requirements. Decide whether default creation should enter a staging OU or the final production hierarchy, and document who completes the transition. An OU named “Staging” is useful only when its intended policy and responsible team are clear. The Group Policy overview discusses balancing delegation and policy requirements.

The following commands adapt example 1 of New-ADOrganizationalUnit, substituting two target names and the fictional domain. The documented example creates an OU with accidental-deletion protection implicitly enabled. Each operation is shown separately:

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Prepare the intended policies and delegation before using these OUs as defaults. Creating the OU is an object-management operation; it does not link a GPO, authorize provisioning, or establish that a device has processed a baseline.

2. Verify the redirection prerequisites

KB324949 requires Windows Server 2003 domain functional level or higher, an existing target OU, Domain Administrator credentials, and an accessible PDC. Check the actual domain configuration rather than inferring functional level from a single server's operating system.

The older Redircmp page lists historical functional-level versions. Use the current KB's “2003 or higher” requirement for this procedure. The Redircmp reference also requires an elevated command prompt. Raising a domain functional level, if needed, is a separate compatibility decision; it should not be presented as an incidental step in an article about object placement.

3. Change the computer and user defaults independently

The next two commands reproduce Microsoft's examples from S1, with the command prompt prefix omitted. Each command changes a separate default destination:

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

The generic documented syntax is redircmp container-dn and c:\windows\system32\redirusr container-dn. The argument is the target OU's distinguished name. Substitute the approved destination; a successful command addresses future creation through the affected default paths.

Existing objects are not moved by either utility. Reconcile future placement and existing placement as separate work items. Explicit-OU provisioning and account reuse also need their own validation, rather than being inferred from the new default.

4. Migrate selected existing objects with a policy review

Assess application dependencies, account purpose, and the expected policy change before selecting each object. The following command adapts the documented Identity and TargetPath syntax from Move-ADObject to a fictional existing computer:

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Select actual objects through a reviewed inventory. Do not use an unqualified bulk move of everything in CN=Users or CN=Computers. The redirection KB discusses backward compatibility and default accounts; the Group Policy overview explains the inheritance that makes a destination change operationally significant.

After the move, confirm the object's new location and repeat the client's policy review. Close the placement task with directory evidence, and close any protection gap with evidence for that protection. Those are related checks with different completion criteria.

5. Delegate creation, reuse, and policy management deliberately

Microsoft's Delegation of Control guidance separates tasks such as joining computers, managing users, and managing GPO links. Delegate the necessary tasks at the appropriate scope. Changing a default destination does not grant the joining identity permission to create or reuse accounts there.

For reused computer accounts, review the owner and required permissions against the domain join permissions procedure. Diagnose a failed join within those requirements. Do not broaden administrative membership or bypass ownership checks merely to make a newly redirected workflow function.

For native Windows LAPS backed by AD, the deployment procedure documents device self-update permission. This example substitutes the approved computer OU into that command:

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

This does not configure LAPS policy or establish password retrieval rights. Validate the intended policy and a successful client update separately. Also review the approved recovery population; bringing a computer into policy scope does not resolve excessive recovery access.

6. Review staged accounts and test future workflows

For each staging candidate, retain the business purpose, owner, provisioning tool, and evidence supporting continued use. Determine whether the account should complete provisioning, remain in an approved staging process, or enter the organization's retirement procedure. No universal age threshold or automatic deletion rule is inferred from the UAC mask.

After remediation, test an authorized new-account workflow using the default path and a workflow reusing a pre-created account. Verify the resulting destination, permissions, expected GPO application, and applicable service outcomes. Microsoft's join permissions and netdom destination rules explain why these workflows must be considered separately.

All commands in this guide are documented reader examples or explicitly identified adaptations. They were not executed against an AD domain for this article, and they are not evidence of successful redirection, migration, or rotation.

How EtcSec Detects This

The following descriptions reflect the reviewed Detect() implementations in etc-collector commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Paths below are relative to public/internal/audit/detectors/.

COMPUTER_WRONG_OU, in ad/computers/organization/wrong-ou.go:35, skips disabled computers, lowercases the DN, and searches for ,cn=computers,dc= at lines 39–49. It reports Low severity. This is a substring test, rather than a parsed comparison of the object's parent with a configured target OU. It does not inventory effective GPO application or establish absence of LAPS, hardening, or auditing.

COMPUTER_PRE_CREATED, in ad/computers/status/pre-created.go:35, tests UserAccountControl & 0x1020 == 0x1020 at lines 38–41. Additional bits are permitted, including disabled state. Its Medium finding has no DN condition, age threshold, logon-history test, or secret-value inspection. The finding name identifies a staging-review signal; the predicate does not prove the computer never joined.

An adjacent control, SERVER_NO_ADMIN_GROUP, is reviewed but is not tagged on this article. In ad/computers/organization/server-no-admin-group.go:43, it selects enabled computers heuristically classified as servers and checks coverage through enabled links to parsed Restricted Groups data containing a nonempty Administrators membership. Its helpers are at lines 102–186. It does not specifically detect residence in CN=Computers, calculate effective filtering, or inspect the server's actual local membership. With no supplied GPO policy data, its zero count does not establish conformity.

Use these findings to choose the next validation step. Correct placement, verify future provisioning, establish actual client protection, and resolve staging ownership separately. A cleared directory predicate is useful evidence for that predicate; successful operational remediation requires the corresponding outcome evidence.