Professional Windows Server 1002003 Security A Technical Reference [Electronic resources]

Roberta Bragg

نسخه متنی -صفحه : 194/ 99
نمايش فراداده

Establish Security Configuration

In addition to physical security, DCs must also be secured by configuring DC security settings and by establishing administrative boundaries. Proper configuration supports administrative boundaries, which can ensure better security configuration.Chapter 11 gives more information on using security baselines to establish security for systems throughout the forest.

Administrative boundaries are created by ensuring that administrators are limited to a role-specific scope. Examples of this are using default groups to assign privileges, creating custom groups for this purpose, and using delegation of authority.

DC Security Baseline Configuration

A DC security baseline is the sum of all DC, Active Directory, and DC-based security configuration. Each organization should establish the written policy, document, set using technical controls, and maintain a baseline. Establishing a security configuration baseline for domain controllers consists of accepting or modifying the following:

Default Domain GPO Account Policy settings

Default Domain Controller GPO User Rights policy and Auditing Policy settings

Server-related security settings in the default Domain Controller GPO or in additional GPOs linked to the Domain Controller OU

Domain security settings such as Public Key Policy, IPSec Security Policy, and Software Restriction Policies in either or both default GPOs

Additional security settings, such as permissions on files, folders, registry keys, and printers

A good way to document and provide a tool for quickly setting, resetting, or auditing the base security of DCs is to use security templates. Security templates are collections of security settings that can be either applied to a one computer at a time or imported into a Group Policy and, therefore, applied automatically to many computers. Although not all security settings are exposed in the templates, many are. Additional settings can be added. Default security settings for domain controllers are preconfigured in the default Domain Controller Security Policy, and default security settings for the domain are pre-configured in the default Domain Security Policy and the default Domain Controller security policy. The settings can be adjusted in the default policies. However, you can use security templates as an alternative method of adapting default settings to those more appropriate for your organization. The "Windows Server 2003 Security Guide" provides and describes a baseline template for DCs that hardens DC security. Organizations can use this template, modify it to fit their circumstances, or create their own. Once a security baseline template is constructed, the template is applied by importing it into a GPO that is linked to the Domain Controller OU. You can find more information on the recommendations made in the following by obtaining the guide that comes with preconfigured security templates. The guide includes a baseline template for DCs, servers, and many other server role-specific templates. Download the guide and the templates at http://www.microsoft.com/downloads/details.aspx?familyid=8a2643c1-0685-4d89-b655-521ea6c7b4db&displaylang=en.

Using the template provided with the guide is a good way to get started, but you should establish your specific requirements and adjust the template for your own use. The guide also provides a realistic approach to security by listing settings for legacy clients, enterprise clients, and high-security situations.

Security Template/Domain Policy Configuration

Sections within the Security Template correspond to areas of the DC that should be secured. These same areas are also represented in the Security Settings portion of a Group Policy Object. Two types of security settings, the Account Policy and the Local Policy, are not typically set in security templates. Instead, they are configured directly in the Default Domain Policy and the Default Domain Controller Policy, respectively. Each following section represents some portion of the total security policy that protects Active Directory. Recommendations for their configuration are provided, but the best settings for each organization will have to be determined by that organization.

Domain Account Policy

A strong domain account policy is critical to the protection of AD. Weak passwords and account controls can allow unauthorized access to network resources and to the domain controller. Weak passwords could also allow an attacker to modify Active Directory schema, change data in the Active Directory, and modify permission on Active Directory objects. (Modifying permissions on Active directory objects is also a subtle way to take control of other parts of the network because changes in these permissions is ordinarily difficult to detect. Permissions on active directory objects, for example, can provide administrative control to Exchange Servers, Certification Authorities, certificate templates, and so on.) Administrative accounts cannot be protected if the account policy is not hardened. The account policy consists of Password Policy, Account Lockout Policy, and Kerberos Policy.

Password Policy

A strong password policy cannot be entirely enforced by technical means. While one of the potential password policy settings is Passwords Must Meet Complexity Requirements, this setting requires only that users create passwords composed of three of four things: uppercase and lowercase letters, numbers, and symbols. It does not allow additional specifications. A strong password policy incorporates the complexity requirements enforced by this setting and other practices that help make them more crack-resistant.

Best Practices for Password Policy

Increasing the complexity of passwords provides better protection from known password crackers. A strong password policy should require the following:

Passwords should not incorporate dictionary words, account names, real names, or company names, and of course, passwords should be unique.

Passwords should consist of uppercase and lowercase letters, symbols, and numbers.

Passwords should incorporate the use of a symbol and number(s) in the second to seventh position. When users are asked to make complex passwords, they often do so by putting numbers at the end. Because this practice is well known, modern password crackers search there first, so incorporating numbers elsewhere means cracking the password will take longer.

Password history should be kept. A password history stores a user's previously used passwords and prevents reuse.

Minimum password length should be as long as possible, given the tradeoff that longer passwords are more frequently written down. Remember that increasing the length of the password to greater than 8 characters makes it harder to crack with current cracking tools. A password over 14 characters is almost impossible to crack in a reasonable amount of time.

Some accounts should be required to have longer passwords, such as administrative accounts, key recovery or key archival accounts, member of the Schema Admins and Enterprise Admins groups, and so on.

Password aging should be configured to require regular password changes and to prevent immediate password changes. When a password can be immediately changed, some users will do so, even multiple times until they exceed the history limit and thus can reuse a comfortable, familiar password. Combine a 45- to 60-day maximum password age requirement and a long password for the best results.

Requirements must be part of the written password policy and must be enforced through user education and auditing. Some of them can be enforced through the Windows password policy. Each Windows Server 2003 domain has a default password policy, as shown in Figure 10-3. This policy is located in the default domain policy. This policy can be modified, and each domain in the forest can have a separate password policy, but for each domain, all users with domain accounts are subject to the same policy. Thus, the tailspintoys.com domain might have a password policy that specifies a password minimum length of 12 characters, while its child domain, newyork.tailspintoys.com, can have a password policy that specifies a minimum length of 8 characters. However, all users with an account in the domain must have a minimum password length of 12 characters. To modify the policy, do the following:

1.

If using GPMC, navigate to the default domain policy, right-click it, and select Edit.

2.

If you have not installed GPMC, open Active Directory Users and Computers, right-click the domain container, select Properties, select the Group Policy tab, and click the Edit button.

3.

Select the Windows Settings\Security settings\Account Policies\ Password policy.

4.

In the detail pane, double-click the setting to change it.

5.

From the Setting Configuration page, ensure that Define this policy setting is checked and either change the number or select the disabled/enabled box, as shown in Figure 10-4.

Figure 10-4. Setting password age.

6.

Click OK.

Figure 10-3. Viewing the default domain password policy.

[View full size image]

The password policy for the domain affects all domain accounts, but a password policy created for a server or workstation will control passwords created for its own local accounts. To create a password policy that affects all domain accounts, modify the default domain GPO. To create a password policy that affects the local accounts of specific computers, create a GPO and link it to the OU where these computer accounts reside. If a user has both a domain account in the domain and a local account on his workstation, when he logs on using his domain account, the domain password policy will be in effect; when he logs on using his local account, the policy effective for that local computer account will be in effect.

The minimum recommendations for Windows Server 2003 domain password policy are set as the defaults. Table 10-1 lists defaults and recommendations for improving security.

Table 10-1. Password Policy Defaults and Recommendations

Setting

Information

Default

High Security

Minimum password length

The password must be at least this number of characters long.

8

12

Enforce password history

This number of passwords will be remembered.

24

24

Maximum password age

Number of days before the password must be changed.

42

42

Minimum password age

Number of days until the password may be changed.

1

2

Password must meet complexity requirements

Use 3 of these 4 upper- and lowercase characters, numbers,and symbols.

Enable

Enable

Store passwords using reverse encryption for all users in a domain

When selected, passwords are not hashed before being stored. Some applications require this less secure format. It is not recommended that this setting be enabled.

Disable

Disable

Account Lockout Policy

The account lockout policy is not set by default. As shown in Figure 10-5, it can be set to lock out accounts for which a number of incorrect password attempts have been entered.

Figure 10-5. The account lockout policy can lock out accounts after a number of incorrect passwords are entered.

[View full size image]

Account Lockout settings are

Account Lockout Duration Indicates the amount of time before a locked out account is automatically reset. A value of 0 means that an administrator or account that has been given that privilege must manually reset it.

Account Lockout Threshold Indicates how many password errors can be made before the account is locked out.

Reset Account Lockout Counter After Indicates how many minutes to wait before reseting the counter to 0. For example, if 3 is the threshold and 2 wrong attempts have been entered, and the user stops, the counter is reset to 0 after the number of minutes entered for Reset Account Lockout Counter After.

When an online guessing or brute-force attack is launched against the account database, the account lockout feature can prevent all but the very lucky attacker from succeeding. However, should an attack be launched against the entire database, it could lock out so many users that, although no password is compromised, a denial of service attack is successful. Another problem can occur if the accounts do not reset fast enough: remote users might accidentally lock themselves out, and because they are unable to reach the help desk, might not be able to obtain critical access.

Although opinions vary, a reasonable approach is to set account lockout threshold high, for example, 25 attempts. In this way, accidental lockouts cannot occur, and the chance for compromise is slim. The account lockout reset function should also be used. Also, if systems are being monitored, and a large-scale attack is occurring, it will be obvious, and it may be possible to block any access from that source before the DoS causes undue harm.

Best Practices for Account Lockout Policy

No monitoring system is foolproof, and it may be that you will not set a lockout policy to avoid the chance of a DoS. The decision to set or not set an account lockout policy may also be based on determining which is more important. In a large organization where such a DoS would prevent operations that are critical to the business, you may determine that account lockout will not be set. However, where ultimate security (rather than operations) is the driver, account lockout will be set. In this case, the possible harm done by unauthorized access due to a remote cracking attack on accounts may be worse than a loss of operations caused by to a DoS. To summarize:

Set an account lockout policy to prevent remote account cracking attacks from succeeding.

Do not set an account lockout policy if operations are more important than blocking remote cracking attacks using lockout.

If an account lockout policy is set, set the number of incorrect attempts required before lockout to a high number.

Do not require administrator reset of locked accounts except in high-security situations.

Kerberos Policy

The Kerberos Policy settings should remain as set by default, as shown in Figure 10-6.

Figure 10-6. Keep Kerberos settings at their defaults.

[View full size image]

Two settings are often changed because administrators are seeking better performance. However, these settings should not be changed:

Enforce User Logon Restrictions Enabled by default, this setting ensures that the user rights policy is checked before users are granted service ticket. The user rights policy includes items such as the right to log on from the network, which may affect whether a ticket is granted or not. When this setting is disabled, the check is not made, and it may be possible for a user who is not authorized to authenticate to a server to do so.

Time Maximum Tolerance For Computer Clock Synchronization This setting is set by default to 5 minutes, and it defines the amount of time difference between the timestamp on client authentication requests and the time on the DC. If the time difference is greater than this value, the request is denied. When this setting is increased, there is more time for a possible replay attack. An example of a replay attack would be the case where a user Kerberos TGT is captured and repurposed in an attempt to obtain a session ticket for some resource. Such an attack would be difficult, but given enough time, anything is possible. However, with the default tolerance intact, it is likely that the timestamp on the credentials would be much older than the time on the KDC computer, and therefore, the replay attack would be unsuccessful.

Local Policy

The Local Policy section of Group Policy consists of Audit Policy, User Rights Assignment, and Security Options. Audit Policy, including the ability to monitor the use of Active Directory objects, is discussed in Chapters 19.

User Rights

User Rights for users in the domain should be defined in the default Domain Controllers Policy, as shown in Figure 10-7. (User Rights for local users on specific servers should be defined in a GPO linked to the OU in which the computer account resides.)

Figure 10-7. User Rights for domain users are configured in the default Domain Controllers policy for the domain.

[View full size image]

User rights in Windows Server 2003 are less extensive than in previous version of the Windows operating system but can still be hardened. Consider the following suggestions for user right management as part of your security plan for AD:

The Allow Log On Locally right is necessary for interactive logon at the DC console. This right is given by default to the groups Administrators, Backup Operators, Account Operators, and Server Operators. Account Operators manage domain accounts but do not need to do so by logging on to a DC console. Instead, they should be using administrative tools from a workstation. Remove the group Account Operators from this right.

The Shut Down The System right is necessary to shut down the DC using operating system commands. This right is given by default to the groups Administrators, Backup Operators, Print Operators, and Server Operators. Print Operators and Account Operators do not need this right. Remove the groups Account Operators and Print Operators from this right. Backup Operators should not need this right, and you may find you can remove that group.

The Backup Operators group has the right to back up and restore files and directories. If followed, the security principles of least privilege and of separation of duties would separate these rights. Instead of giving this group both rights, create a separate "recovery operators" group; remove Backup Operators from the right to restore files and folders, and add the new recovery operators group to that right.

The Deny Access To This Computer From The Network right should be given to the local Administrator account, the Support_388945a0 account, the guest account, and all NON operating system service accounts. Requiring the local Administrator account to be used locally prevents attacks that rely on the knowledge of the known administrator SID. The support_388945a0 account can be programmed for use by help services and should not be allowed access to a DC. If a domain account is assigned as a service account on some server in the domain, that account may have elevated privileges, and its compromise might be used to leverage an attack against the DC. If these accounts are denied logon access, that attack vector will be mitigated.

For similar reasons, the Support_-388945a0 account and the Guest account should be denied the ability to log on as batch job to prevent these accounts from being used to execute a virus, Trojan, or worm.

The Deny Log on Through Terminal Services right should be given to the built-in administrator account and the NON-operating systems account for the reasons given previously.

Careful consideration of the way groups are used in your organization may suggest other uses of User Rights to provide protection for domain controllers, and hence Active Directory. Be sure to test these changes before using them on production domain controllers.

TIP: USE AD SECURITY SETTINGS TO BENEFIT OTHER SYSTEMS

Active Directory is not the only beneficiary of hardening user rights. Other computers and operations can benefit as well. For example, the user right Logon To This System From the Network can be modified on servers and other computers to which you want to restrict access. To secure file servers that store sensitive documents, change this right to only include those groups that should have access to the documents. There is no need to allow every employee access to the servers. Although file permissions allow you to control access to the files, preventing unauthorized users from even authenticating to the file server provides another layer of protection.

Security Options

Security Options make registry changes that affect security. Several of these options can be used to secure DCs. In addition to the registry changes made by Security Options that are visible in the GUI, other registry entries can be made that will tighten security. These registry entries can be applied in numerous ways, one of them being by adding them to a security template and then importing the template into a GPO.

Table 10-2 lists and discusses the recommendations for Security Options settings that differ from the default. Security Options, such as auditing related policies, that are discussed in other chapters are not included in Table 10-2.

Table 10-2. Security Options for DCs

Policy

Recommendation

Information

Accounts: Guest Account Status

Disabled

The guest account can provide access for those without credentials and should be disabled.

Devices: Allowed to Format and Eject Removable Media

Define and grant to administrators

Preventing unauthorized individuals from obtaining data by removing drives is always a good idea. However, realize that most drives can be physically removed; do not rely on the operating system to eject them. Setting this option only prevents the operating system's utility from working. This is a somewhat helpful deterrent because when drives are removed without stopping, or ejecting using this utility, the data on them may be corrupted.

Devices: Prevent Users from Installing Printer Drivers

Enable

Enabling this option restricts this right to server operators and administrators. Users won't be able to install printers. Although installing printer drivers may seem harmless, a malicious person might disguise attack code in a printer driver, and simple disk space attacks can be mounted that cause a DoS attack by filling up the printer spool and hence the disk by submitting large print jobs.

Devices: Restrict CD-ROM Access to Locally Logged on Users

Enabled

If enabled, when an administrator is logged on at the console of the DC, only administrators can access CD-ROM media in the computer drive. When administrators are installing software and service packs, no one should be able to interfere or copy data from the CD-ROM. If no one is logged on, this restriction is not enforced. (Administrators should be counseled to remove CD-ROMs.)

Devices: Restrict Floppy Access to Locally Logged on User

Enabled

See the previous paragraph on restricting CD-ROM access.

Devices: Unsigned Driver Installation Behavior

Do not allow installation

Ensure unsigned, possibly unsafe drivers are not loaded on DCs. If a driver that must be used on the DC is not signed, temporarily change the policy to allow a warning, install the driver, and then return the policy to Do not allow installation.

Domain Controller: Allow Server Operators to Schedule Tasks

Disabled

Disable to restrict task scheduling to administrators. Scheduling tasks on a domain controller should be restricted. This option applies only to domain controllers.

Domain Controller: LDAP Server Signing Requirement

Require signing

Protect LDAP traffic between Active Directory and administrator workstations by using LDAP packet signing. LDAP packet signing does not encrypt; instead, it digitally signs the packets. If an attacker were to alter the packet and put it back on the network, the digital signature would be incorrect, and the receiving DC recognizes this and drops the packet.

Interactive Logon: Do Not Display Last User Name

Enabled

Protect the names of authorized administrator accounts. Enable this setting, and the account name of the last user logged on won't be displayed to the next person who happens to come along. Keeping administrator account names secret ensures that an attacker must work harder to obtain access.

Interactive Logon: Message Text for Users Attempting to Logon

Provide a message that warns users that only authorized administrators have the right to logon interactively

A legal notice announces that attempting to gain access is wrong. Although it will not prevent an attacker from compromising a system, it may help in their prosecution. Cases have been thrown out of court because the computer splash screen or notice message said "welcome," and an attacker said she thought that meant she was welcome to attempt access. Obtain approval from your legal department for the wording of this message.

Interactive Logon: Message Title for Users Attempting to Logon

Provide a title for the warning

See previous paragraph on using message text.

Interactive Logon: Number of previous logons to cache (in case domain controller is not available)

0

When set to 0, no logon credentials are cached. Each time an administrator needs access, his logon credentials will be checked against the domain database. When this option allows cached logons, a rogue administrator whose administrative status may have been revoked might be able to gain access to a domain controller based on a cached logon.

Interactive Logon: Prompt user to change password before expiration

14 days

Advance notification allows users to prepare and figure out a password to be used. When users are given this time, there is a better chance that stronger passwords will be used, and that passwords will not be written down or written down in insecure places.

Interactive logon: Require Domain Controller Authentication to Unlock Workstation

Enabled

The locking function prevents unauthorized access (only the account that locked the computer or an administrator can unlock the system). By default, cached credentials are used; that is, the user's account is not authenticated with the DC. This means that no password changes, account status, or group membership is checked. It would be possible to disable the administrator's account and not keep him from returning and unlocking the account. If the setting Interactive Logon: Number of Previous Logons to Cache is set to 0, this is not possible. However, if it cannot be set to 0, this setting should be enabled.

Interactive Logon: Smart Card Removal Behavior

Force Logoff

This setting has no effect if smart cards are not enabled. However, if they are, when a smart card is removed, the user will be logged off. If administrators are required to use smart cards, this policy ensures that as long as the administrator removes her smart card, the administrator's console session will not be left open.

Network Access: Allow Anonymous SID/NAME Translation

Disabled if legacy systems do not need it

If enabled, because the administrator SID is well known, it could be used to find the name of the administrator account and then use this to initiate a password-guessing attack. Some legacy systems (NT 4.0 RAS, Windows 2000 RAS in Windows NT 4.0 domains, web applications using basic authentication with anonymous access disabled) need this ability, so you may not be able to implement in all domains.

Network Security: Force Logoff when Logon Hours Expire

Enabled

Forcibly disconnects SMB sessions after logon hours expire. Logon hours are set per user account in the user account properties pages. If logon hours are set, this setting prevents users from leaving a system logged on and connected after hours. When sessions are left unattended, an unauthorized user can gain access. These sessions are especially vulnerable to abuse during hours when few people are around.

Network Security: LDAP Client Signing

Requiredunless legacy clients are used

When LDAP signing is required by domain controllers, workstations must be able to do so, or there will be failure in authentication, group policy, and logon scripts. If legacy clients are used, LDAP signing cannot be required. This setting is also necessary in the domain controller policy because domain controllers must also communicate with each other.

If you are familiar with previous versions of Windows, you may recognize Security Options as items previously set directly in the registry. In fact, when Security Options are enabled and Group Policy applied, equivalent registry settings are made. Using Security Options prevents the problems that direct registry editing can cause, such as adding the wrong settings (hence security is not strengthened) or the destruction of some critical part of the registry (hence possibly damaging operating system or other component operation). In addition to preconfigured Security Options, however, other hardening techniques can be implemented directly through registry entries. These changes can be automated by making them part of a security template and automatically applying them instead of requiring a direct registry edit. An example of such an entry is disabling 8.3 names. The NTFS file system automatically creates old 8.3 names from long file names. 8.3 names can therefore be used to support legacy applications. However, they may provide attackers access from systems that do not understand longer file names or allow hard-coded attacks that use 8.3 names to succeed. You should not be running applications on the DC that need the 8.3 name. Because many malicious scripts, including viruses, are 16-bit applications and are written with 8.3 names coded in, preventing 8.3 name generations may block some of these scripts from running. To disable 8.3 name generation, set the value of the following REG_DWORD value to 1:

Hklm\system\currentcontrolset\control\file systemNtfsDisable8dot3NameCreation

Event Log Settings

Event log settings for the three logs identified in Group Policy (security, application, system) as displayed in Figure 10-8 should be adjusted to support the amount of security auditing enabled. By default, these settings are not defined. Recommended settings for the domain controller event logs are as follows:

Log file size 128 MB

Prevent local guest group from accessing application, security or systems log (3 policies) Enabled

Retain eventlog log (where eventlog is the name of a log) Can remain not defined because the retention method is set to overwrite events as needed

Retention method for logs (3 policies) Overwrite events as needed

Figure 10-8. The security log settings on a DC should be increased to manage the large volume of audit records that will be produced.

[View full size image]

In addition to the event log files available on all Windows Server 2003 computers, several other event logs are present on domain controllers:

Directory Service

DNS Server

File Replication Service

Settings for these event logs must be set by opening their property pages, as shown in Figure 10-9, or must be scripted. Property pages are available by opening the Event Viewer, right-clicking the event log, and selecting Properties.

Figure 10-9. Configure event log settings from event log property pages.

System Services

Windows Server 2003 disables many services by default and doesn't start others. However, ensure that disabled services remain disabled unless needed, and you may want to disable other services. A full discussion of services in a baseline template for servers and workstations in a domain is included in Chapter 11. You need to add additional services to this baseline in order for domain controllers to function.

The following services are disabled in sample Microsoft baseline security templates for servers, but they need to be enabled for domain controllers. (A baseline template for domain controllers is also available from Microsoft.) You may need to enable other services, depending on the other functions a specific DC is used for. For example, if DNS is installed on a domain controller, the DNS server service needs to be enabled. The following additional services are necessary for domain controllers to function:

Distributed File System Required for the Active Directory SYSVOL share.

File Replication Service Needed for File Replication of SYSVOL.

Kerberos Key Distribution Center Enables logon using Kerberos protocol.

Intersite Messaging Used for mail-based replication between sites.

Remote Procedure Call (RPC) Locator Used for management of RPC name service database. RPC is used during replication.

In addition to controlling whether services are disabled or enabled, services settings determine whether a service is interactively started or stopped and whether it is started or not during boot. These settings can be configured interactively through the Services administrative tool, or set in the Services section of a GPO. The Services section of a GPO can be used to control who has the authority to stop, start, and otherwise change services configuration. To prevent unauthorized management of services, follow these steps:

1.

Open the GPO in the GPO editor and select the System Services node.

2.

In the details pane, right-click the service and select Properties.

3.

Check Define this policy setting and click the Edit Security button.

4.

Note that the default setting only allows Administrators and the system to change settings. Use the object editor to select a group that represents a subset of Administrators who are authorized to manage services. For example, you may want to allow only the EnterpriseAdmins group Full Control over the DNS Server service. The DnsAdmins group already has, by default, the right to stop, start, pause, and continue the service, as shown in Figure 10-10.

Figure 10-10. Control who can manage services by setting permissions on the service object in the GPO.

Registry and File System

The Registry and File System section of a GPO can be used to provide systematic refresh of critical security permission on registry keys, files, and folders. However, even if there are no changes, security settings are periodically refreshed. If a significant number of permissions are part of the GPO, the amount of information replicated can impact the efficiency of replication and even prevent it from occurring. The constant, large download to domain member computers can significantly impact network efficiency. Best practices now recommend that this element be used cautiously in a GPO and rarely, if ever, in a large Active Directory forest. However, the use of a security template and the Security Configuration and Analysis tool to set security on the entire systems path is a sound concept. A template is used during server installation and during dcpromo to initially set file and folder security. These default templates should be modified, if necessary, with any specific changes required by your organization. After installation, browse the Setup Security template to see the security that was set during installation. Looking at the File System portion of this template, as shown in Figure 10-11, gives you an idea of the large number of permissions. This template could also be used to reset these permissions to the defaults. However, you should realize that any permission set on a file or folder not listed here would not be changed when the template is applied.

Figure 10-11. Security templates are used to set file system permissions.

[View full size image]

Be extremely careful when modifying permissions on system folders, files, and registry keys. There are many reasons for the settings as they stand, and it is possible that changing these settings will break some critical function. Be especially careful in implementing without first reviewing recommendations found in articles and on web sites because they may have been developed for very specific circumstances. Look for evidence of testing in environments similar to yours, and prepare to do significant testing of your own. Any change to system file and folder permissions or registry permissions, especially on a domain controller, can cause problems that are not immediately evident and may not be immediately diagnosed as a file or registry key permission problem.

TIP: TEMPLATE REGISTRY SETTINGS ARE ONLY FOR PERMISSIONS

The Registry section is just for setting permissions on keys. You cannot change registry settings at that location. To make changes to registry settings using GPOs or security templates, you must either use the predefined security options from the Security Options section of the GPO or template, or add registry settings to the Registry Keys section of a security template, as shown in Figure 10-12. A modified security template can be imported into a GPO.

Figure 10-12. A registry setting added to the Registry Values section of a security template will be applied to any computer the security template is applied to.

[View full size image]