Appendix A: Security Settings and User Rights
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. |
||||||||||
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 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. |
|||||||||
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.
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.
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.
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.
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.