Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Appendix A: Security Settings and User Rights

Updated: April 7, 2003

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:

  1. Click Start, point to Programs, click Administrative Tools, and then click Domain Security Policy.

  2. 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:

  1. Click Start, point to Programs, click Administrative Tools, and then click Domain Controller Security Policy.

  2. 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:

  1. Click Start, point to Programs, click Administrative Tools, and then click Local Security Policy.

  2. 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.

noteNote
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.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.