Default Domain Policy — Essential Changes

The Default Domain Policy provided by Microsoft is a starting point, not a production configuration. I’ll outline changes you should make immediately and others you should definitely leave alone. This Default Domain Policy applies to all objects in the domain. It is created automatically and, by default, contains a password policy and a few Kerberos settings.

First, the golden rule: the Default Domain Policy should contain only the password policy and the account lockout policy. Everything else—firewalls, specific security settings, application configurations—must be configured using dedicated GPOs linked to the appropriate OUs. This is a convention, not a technical constraint; it greatly simplifies troubleshooting and maintenance. If you think a GPO is messing things up, you can simply disable it. If you’ve put everything into a single GPO, well, too bad for you.

Fix 1 — Password Policy

Microsoft’s default settings are… no comment. In 2026, a minimum length of 7 characters and a lockout threshold of 0 attempts (disabled) do not meet any serious security recommendations.

Computer Configuration → Policies → Windows Settings
  → Security Settings → Account Policies → Password Policy

> Note: The CIS Benchmark 2025 recommends a minimum of 14 characters. 12 is a reasonable compromise for a personal infrastructure where user convenience also matters. On an exposed production infrastructure, go with a minimum of 14.

Kerberos Settings — Do Not Change

The Default Domain Policy also contains a Kerberos policy. The default values are correct and do not need to be changed in the vast majority of cases:

The 5-minute clock tolerance is particularly important: if a workstation’s clock is more than 5 minutes off from the DC, Kerberos will refuse authentication. This is why NTP synchronization on all workstations in the domain is not optional.

Fix 2 — The Lockout Policy

A threshold of 0 means that account lockout is disabled. A user can attempt an unlimited number of passwords without ever being locked out. This is an open invitation to brute-force attacks.

Computer Configuration → Policies → Windows Settings
  → Security Settings → Account Policies → Account Lockout Policy

> 5 attempts is a reasonable compromise between security and operational convenience. Any lower, the helpdesk is overwhelmed with account unlock requests. Any higher, it leaves too much room for dictionary attacks.

Fix 3 — Disable adding machines to the domain

By default, any authenticated domain user can join up to 10 machines to the domain. This is the ms-DS-MachineAccountQuota attribute, set to 10 when the AD is created.

This configuration means that a standard user, with only their domain credentials, can add an unmanaged machine to the network. In a home or corporate environment, this is an unnecessary risk.

The fix operates on two complementary levels.

Level 1 — GPO User Rights

In the Default Domain Policy:

Computer Configuration → Policies → Windows Settings
  → Security Settings → Local Policies → User Rights Assignment
    → "Add workstations to the domain"
      → Remove "Authenticated users"
      → Add only: "Domain admins"

Level 2 — AD Attribute ms-DS-MachineAccountQuota

The GPO above controls local permissions, but the AD attribute controls the limit at the domain level. Both must be configured.

In ADSI Edit (adsiedit.msc):

Connect → Default Naming Context
  → DC=mydomain,DC=lan → Right-click → Properties
    → ms-DS-MachineAccountQuota → Modify → 0

Value 0 = no non-administrator users can join a machine to the domain.

Repeat the operation on every domain in the forest.

Bonus Fix — LDAP Signing

WARNING: This setting is configured in the Default Domain Controllers Policy, not in the Default Domain Policy. It is a setting specific to domain controllers.

Default Domain Controllers Policy → Edit
  → Computer Configuration → Policies → Windows Settings
    → Security Settings → Local Policies → Security Options
      → "Domain Controller: LDAP Server Signing Requirements"
        → Require signing

Without LDAP signing, unencrypted communications between clients and the DC are vulnerable to LDAP relay attacks—an attacker on the network can intercept and relay LDAP authentications to impersonate identities.

> Note: This setting may break legacy applications that use unauthenticated LDAP. Before enabling, monitor Windows event logs: > - Event ID 2886 — Unsigned LDAP detected > - Event ID 2887 — Unsecured LDAP connection denied