The Default Domain Policy is included for one primary reason, with some secondary reasons. The primary reason that the Default Domain Policy is included in Active Directory by default is to establish the Account Policies settings. The Account Policies settings control how user account passwords are defined in Active Directory, as well as in every SAM on every computer that joins the domain. Some of the many secondary reasons for the existence of the Default Domain Policy include autoenrollment settings for PKI, control of Encrypting File System (EFS), establishment of a company-wide screen saver lockout policy, and more.
Account Policies in the Default Domain Policy
From a security standpoint, one of the most important aspects of protecting the network is ensuring that user accounts have complex and secure passwords. The definition of complex and secure might not be the same everywhere, but there must be some form of baseline security regarding passwords on the network. The Default Domain Policy is responsible for defining that for a new Active Directory installation.
The question of where you can set user account password restrictions for an Active Directory domain has caused some confusion. The short answer is that you can establish password policies for domain user accounts in a GPO linked to the domain. By default, this is the Default Domain Policy. If you want to create a different set of password policies not in the Default Domain Policy, you can create a new GPO, configure your settings, link the GPO to the domain node, and then ensure that this GPO has higher precedence than the Default Domain Policy.
Here are some other restrictions regarding password policies within a GPO to control domain user account password restrictions:
GPOs linked to organizational units will not affect the user accounts that are located in the organizational unit.
There is no way to configure a single GPO containing Account Policies settings to control multiple domains.
The Account Policies within the GPOs that control domain user account passwords can be a bit confusing. However, when you understand how they work and the technology behind the settings, it will make much more sense. Some of the confusion involves where these Account Policies can be configured to control domain user account passwords. The answer is simple: in a GPO at the domain level only. The settings do not need to reside in the Default Domain Policy, but they must be in a GPO that is linked to the domain.
Another point of confusion results from the desire to configure the Account Policies within a GPO that is linked to an Organizational Unit, expecting these settings to affect the user accounts that reside in the Organizational Unit. This will not work! If you look at the location of the Account Policies within the GPO, you will see that they are not User Configuration settings. Rather, these settings are under Computer Configuration, so they affect computer accounts only, not user accounts.
The user account does not control the password; the location where the user account is stored controls the password. For a domain, this is domain controllers and Active Directory. For desktops and servers, this is the local SAM. Thus, the Account Policies must affect computer accounts, because the user accounts and their passwords are stored on computers.
A final point of confusion involves administrators of large or complex organizations attempting to have a single set of Account Policies control all of their domains and the user accounts in them. This is also not possible. The Account Policies, and Group Policy in general, are domain centric. (GPOs linked to sites can span domains, but the GPO is still stored in only one domain.) There is no technology built into Windows that allows you to configure a single set of Account Policies that will span multiple domains.
Account Policies are divided into three sections within a GPO: Password Policy, Account Lockout Policy, and Kerberos Policy. These are shown in Figure 1.
Figure 1. The Default Domain Policy is responsible for establishing the default Account Policies for the domain user accounts and all user accounts located on computers that join the domain.
Each of these sections provides options for controlling all areas of the user account password. Table 1 lists all of the possible policy settings that can be configured within these three sections.
Table 1. Default Domain Policy Default Account Policy Settings
|Computer Configuration||Policy Setting||Default Value|
|Windows Settings \Security Settings \Account Policies \Password Policy||Enforce Password History||24 passwords remembered|
| ||Maximum Password Age||42 days|
| ||Minimum Password Age||1 days|
| ||Minimum Password Length||7 characters|
| ||Password must meet complexity requirements||Enabled|
| ||Store passwords using reversible encryption||Disabled|
|Windows Settings \Security Settings \Account Policies \Account Lockout Policy||Account lockout duration||Not defined|
| ||Account lockout threshold||0 invalid log-on attempts|
| ||Reset account lockout counter after||Not defined|
|Windows Settings \Security Settings \Account Policies \Kerberos Policy||Enforce user log-on restrictions||Enabled|
| ||Maximum lifetime for service ticket||600 minutes|
| ||Maximum lifetime for user ticket||10 hours|
| ||Maximum lifetime for user ticket renewal||7 days|
| ||Maximum tolerance for computer clock synchronization||5 minutes|
Other Policy Settings in the Default Domain Policy
Still more default policies are set in the Default Domain Policy. The majority of the remaining settings are located within Computer Configuration\Windows Settings\Security Settings, as shown in Figure 2. These settings exist mainly to control the Public Key Infrastructure environment as a baseline.
Figure 2. The Default Domain Policy configures some important security settings for all computers that join the domain.
The User Configuration section contains a few other settings, which control some of the options for using Remote Installation Services (RIS). Table 2 provides a full list of all Default Domain Policy settings outside of the Account Policies.
Table 2. Default Domain Policy Default Configurations and Values
|Computer Configuration||Policy Setting||Value|
|Windows Settings \Security Settings \Local Polices\Security Options||Network access: Allow anonymous SID/Name translation||Disabled|
| ||Network security: Do not store LAN Manager hash value on next password change||Enabled|
| ||Network security: Force logoff when log-on hours expire||Disabled|
|Windows Settings\Security Settings\Public Key Policies\Encrypting File System||<Certificates>||Administrator is configured for File Recovery|
Default Domain Controllers Policy
The Default Domain Controllers Policy is extremely important for establishing the default security on domain controllers. Windows stand-alone and member servers are not secured as thoroughly as domain controllers, because they need to have more backward compatibility with applications and services that might be running on them. Domain controllers need to be secured more tightly, and the Default Domain Controllers Policy is responsible for making those configurations. Figure 3 shows some of the settings in the Default Domain Controllers Policy.
Figure 3. The Default Domain Controllers Policy creates the default security for all domain controllers that come into the domain.
Three main areas have settings within the Default Domain Controllers Policy. The first establishes the audit policies for the domain controllers. These settings ensure that the domain controllers are logging to the security event logs essential actions that occur. The second area is related to the user rights for the domain controllers. User rights establish which users can perform certain tasks on the computer. Because domain controllers need to be protected, the Default Domain Controllers Policy defines the user rights to create a baseline of security. Finally, some policies are defined to control network communication. The majority of these control whether data and communication will be digitally signed to increase security of the communication. One policy deals with the authentication protocols that the domain controllers will allow.
Table 3 lists all Default Domain Controllers Policy settings that are established by default. Note that user rights that are not filled in are either not defined or defined but left empty.
Table 3. Default Domain Controllers Policy Default Configurations and Values
|Computer Configuration||Policy Setting||Value|
|Windows Settings\Security Settings\Local Policies\User Rights Assignment||Access this computer from the network||Administrators|
ENTERPRISE DOMAIN CONTROLLERS
Pre-Windows 2000 Compatible Access
| ||Add workstations to the domain||Authenticated Users|
| ||Adjust memory quotas for a process||Administrators|
| ||Allow logon locally||Account Operators|
| ||Back up files and directories||Administrators|
| ||Bypass traverse checking||Pre-Windows 2000 Compatible Access|
| ||Change the system time||Administrators|
| ||Create a pagefile||Administrators|
| ||Debug programs||Administrators|
| ||Enable computer and user accounts to be trusted for delegation||Administrators|
| ||Force shutdown from a remote system||Administrators Server Operators|
| ||Generate security audits||LOCAL SERVICE NETWORK SERVICE|
| ||Increase scheduling priority||Administrators|
| ||Load and unload device drivers||Administrators Print Operators|
| ||Log on as a batch job||Performance Log Users Backup Operators|
| ||Manage auditing and security log||Administrators|
| ||Modify firmware environment variables||Administrators|
| ||Profile single process||Administrators|
| ||Profile system performance||Administrators|
| ||Remove computer from docking station||Administrators|
| ||Replace a process level token||LOCAL SERVICE NETWORK SERVICE|
| ||Restore files and directories||Administrators|
| ||Shut down the system||Administrators|
| ||Take ownership of files or other objects||Administrators|
|Windows Settings\Security Settings\Local Policies\Local Polices\Security Options||Domain controller: LDAP server signing requirements||None|
| ||Domain member: Digitally encrypt or sign secure channel data (always)||Enabled|
| ||Microsoft network server: Digitally sign communications (always)||Enabled|
| ||Microsoft network server: Digitally sign communications (if client agrees)||Enabled|
| ||Network security: LAN Manager authentication level||Send NTLMv2 response only|