Appendix A: Security Settings and User Rights

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This appendix lists the Security Settings that are defined by default in the Default Domain Policy GPO. This GPO is created when the first domain controller in the domain is installed by the Active Directory Installation Wizard. If this first domain controller is upgraded from a Windows NT 4.0 domain controller, then the values defined for the Windows NT 4.0 domain are used instead.

These domain-wide account policy settings (Password Policy, Account Lockout Policy and Kerberos Policy) are enforced by the domain controller computers in the domain; therefore, all domain controllers always retrieve the values of these account policy settings from the Default Domain Policy GPO.

Policy	Default Value	Comment
Password Policy
Enforce password history	1 password remembered
Maximum password age	42 days
Minimum password age	0 days
Minimum password length	0 characters
Passwords must meet complexity requirements	Disabled
Store password using reversible encryption for all users in the domain	Disabled
Account Lockout Policy
Account Lockout Threshold	0
Kerberos Policy Since Kerberos support was not available in previous versions of Windows NT, the following Kerberos policy settings are always defined for the first domain controller of a Windows 2000 or Windows Server 2003 domain, regardless of whether it was upgraded or not.
Enforce user logon restrictions.	Enabled
Maximum lifetime that a user ticket can be renewed	7 days
Maximum user ticket lifetime	10 hours
Maximum service ticket lifetime	600 minutes
Maximum tolerance for synchronization of computer clocks	5 minutes
Security Options
Automatically logoff users when logon time expires	Disabled	This is a domain-wide setting even though it appears under the Security Options area.

Security Settings in the Default Domain Controllers Policy

This section lists the Security Settings that are defined by default in the Default Domain Controller Policy GPO. This GPO is created when the first domain controller in the domain is installed via the Active Directory Installation Wizard. If this first domain controller is upgraded from a Windows NT 4.0 domain controller, then the values defined for the Windows NT 4.0 domain are used instead.

By default, these settings apply to all domain controllers in the domain.

Policy	Default Value	Comment
Security Options
Digitally sign server-side communication when possible	Enabled
Audit Policy
Audit Account Logon events	No Auditing
Audit Account Management	No Auditing
Audit Directory Service Access	No Auditing
Audit Logon Events	No Auditing
Audit Object Access	No Auditing
Audit Policy Change	No Auditing
Audit Privilege Use	No Auditing
Audit Process Tracking	No Auditing
Audit System Events	No Auditing
User Rights Policy
Access this computer from the network	Administrators, Authenticated Users, Everyone	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Backup Operators, Guests, Guest, and Users. If a Windows NT 4.0 domain controller is upgraded as the first Windows Server 2003 domain controller, then the Authenticated Users group is automatically given this right.
Act as part of the operating system
Add workstations to the domain	Authenticated Users	This User Right is for the support of legacy APIs. You can also allow users to create computer accounts by using this User Right. Authenticated Users can only create 10 computer accounts using this User Right.
Back up files and directories	Administrators, Backup Operators, Server Operators
Bypass traverse checking	Administrators, Authenticated Users, Everyone	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Backup Operators, Users.
Change the system time	Administrators, Server Operators
Create a pagefile	Administrators
Create a token object
Create permanent shared objects
Debug programs	Administrators
Force shutdown from a remote system	Administrators, Server Operators
Generate security audits
Increase quotas	Administrators
Increase scheduling priority	Administrators
Load and unload device drivers	Administrators
Lock pages in memory
Log on as a batch job
Log on as a service
Log on locally	Account Operators, Administrators, Backup Operators, Server Operators, Print Operators	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Authenticated Users, Guests, Guest, Users, and Everyone.
Manage auditing and security log	Administrators
Modify firmware environment variables	Administrators
Profile single process	Administrators
Profile system performance	Administrators
Replace a process-level token
Restore files and directories	Administrators, Backup Operators, Server Operators
Shut down the system	Account Operators, Administrators, Backup Operators, Server Operators, Print Operators	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Authenticated Users, Guests, Guest, Users, and Everyone.
Take ownership of files or other objects	Administrators
Deny Logon Locally
Deny logon as a batch job
Deny logon as a service
Deny Access to this computer from network
Remove Computer from Docking Station	Administrators	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Users.
Synchronize directory service data
Enable computer and user accounts to be trusted for delegation	Administrators	If the following groups were given this right prior to running the Active Directory Installation Wizard, then they are removed: Users.

Help for Windows NT 4.0 Administrators

This section provides information to help administrators who have been using User Manager to configure security policy settings in the past move to the new model of Group Policy for editing and configuring security policy settings.

Changing Password Policy for the Domain

To change password policy for the domain, open the Default Domain GPO from the Administrative Tools menu:

Click Start, point to Programs, click Administrative Tools, and then click Domain Security Policy.
In the Domain Security Policy console, expand Security Settings, expand Account Policies, expand Password Policy, and then select the policy you want to modify in the results pane. You can then make changes.

Changing Auditing Policy or User Rights for Domain Controllers

To change the Audit policies or User Rights defined for domain controllers, open the Default Domain Controllers GPO from the Administrative Tools menu:

Click Start, point to Programs, click Administrative Tools, and then click Domain Controller Security Policy.
In the Domain Controller Security Policy console, expand Security Settings, expand Local Policies, click either Audit Policy or User Rights Assignment, and then select the policy you want to modify in the results pane.

Changing local Password Policy on member Workstations or Servers (Non-Domain Controllers)

Because the Default Domain Policy GPO applies to all computers in the domain and because domain-level policy settings override local policy settings, member workstations and servers apply the Default Domain password policy settings to their local account databases by default. If this does not meet your requirements, then the permissions on the Default Domain GPO have to be reconfigured so that member computers that you do not want to receive this policy do not have the Apply Group Policy permission on the Default Domain GPO. After the permissions are configured so that the member computer does not have access to the default domain policy, local policy settings will no longer be overridden by the password policy settings defined in the Default Domain GPO.

To modify Local Password Policy security settings using the Local Security Policy UI:

Click Start, point to Programs, click Administrative Tools, and then click Local Security Policy.
In the Local Security Settings console, expand Security Settings, expand Account Policies, click Password Policy, and then select in the results pane the policy you want to edit.

Frequently Asked Questions about Security Settings

Is it possible to define different account policies (Password, Lockout, or Kerberos Policies) for different organizational units?

No. All domain controllers for a domain enforce the account policy settings that are defined in the Default Domain Policy. Domain controllers ignore password, lockout, or Kerberos policy settings defined at an organizational unit or Local GPO level.

After modifying a local security setting, the change does not take effect. What is happening?

The Group Policy model specifies that any policy settings configured locally may be overridden by like policy settings specified in the domain. The Local Security Settings UI lists the local security setting and the effective security setting for each policy item. (You can access the Local Security Settings UI by clicking Start, pointing to Programs, clicking Administrative Tools, and selecting Local Security Policy). If the effective security setting is different from the local security setting, it implies that there is a policy from the domain that is overriding your setting.

After modifying a domain-level-policy security setting, the change does not take effect. What is happening?

The Group Policy model applies domain-level policy changes periodically; therefore, it is likely that the policy changes made in the directory have not been made to your computer yet. To trigger a policy propagation on a local computer, type the following at the command line:

secedit /refreshpolicy MACHINE_POLICY

This will cause any changes made to domain-level policy settings to be applied to the local computer. To force a reapplication of policy to domain-level policy settings, regardless of whether there has been a change or not, type the following at the command line:

secedit /refreshpolicy MACHINE_POLICY /enforce

You can determine whether or not security was applied successfully by viewing the Application Event Log. If an error occurred during the process of applying security policy, you can get detailed information by setting the following REG_DWORD to 0x02:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\ExtensionDebugLevel

When this value is set, the Security Templates will log policy-processing information in the Winlogon.log file at %windir%\Security\Logs\Winlogon.log.

What is the Add Workstation to Domain Logon right, and how does it relate to delegating similar permissions on the directory?

The Add Workstation to Domain user right is supported for applications that use earlier SAM (Security Accounts Manager) NET APIs to create computer accounts. Users that have this right are allowed to create 10 computer accounts in the Active Directory Computers container using these earlier APIs. When a user creates a computer account using this user right, the Domain Admins group becomes the owner of the computer object. Note that this right is not recognized when LDAP is used to create computer accounts.

In Windows 2000 and later, the recommended way to allow a user or group to create computer accounts is by granting that user or group the permission to Create Computer Objects on the desired container. This can be accomplished in GPMC. When a computer account is created using access control permissions, the actual creator of the object becomes the owner of that object.

Note

The create-computer-object permission should not be granted indiscriminately. Allowing users to create computers in the domain is similar to allowing users to create user accounts in the domain. Unlike Windows NT 4.0, Windows Server 2003 computer objects can be used to do network authentication and, hence, to access resources over the network. Users that have access permissions to create computer objects are also not subject to any quota restrictions. That is, they can create any number of computer accounts.

The best security practice would be to grant only trusted users (by using a group) the permission to create computer objects. At the time the computer object is created, the creator can define which users are allowed to use that computer object to join their physical computer to the domain.