How Security Settings Extension Works

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

In this section

• Security Settings Extension Architecture

• Security Settings Policy Processes and Interactions

• Related Information

The Security Settings extension of the Group Policy Object Editor MMC snap-in allows you to specify security configurations as part of Group Policy objects, which can be linked to Active Directory sites, domains, or organizational units.

An Active Directory-based deployment of security settings policy requires deployment of at least Windows 2000 Server, and Windows 2000 Professional or Windows XP clients. However, to gain full advantage of the latest security settings policies, you need:

• Windows Server 2003 with Active Directory installed and DNS dynamic update protocol properly configured.

• Windows XP client computers.

• Group Policy Object Editor, which you can access by using Group Policy Management Console (GPMC).

• The Security Settings extension of Group Policy Object Editor.

For computers that are not participating in a domain, you can use the Local Security Policy snap-in.

This section discusses how the Security Settings extension of Group Policy Object Editor works. It presents information about how security settings are stored and how security settings policy is processed.

Security Settings Extension Architecture

The Security Settings extension of Group Policy Object Editor is part of the Security Configuration Manager tools, as shown in the following diagram:

Security Settings Architecture

The security settings configuration and analysis tools include a security configuration engine, which provides local computer (non-domain member) and Group Policy-based configuration and analysis of security settings policies. The security configuration engine also supports the creation of security policy files. The primary components of the security configuration engine are:

Scecli.dll

Provides client side interfaces to the security configuration engine and does Resultant Set of Policies (RsoP) logging during policy propagation.

Scesrv.dll

Provides core security engine functionality including support for import, configure, analyze, and policy propagation operations.

Communications between components of the Security Settings extension occurs by using the following methods:

• Component Object Model (COM) calls

• Local remote procedure call (LRPC)

• Lightweight Directory Access Protocol (LDAP)

• Active Directory Service Interfaces (ADSI)

• Server Message Block (SMB)

• Win32 APIs

• Windows Management Instrumentation (WMI) calls

The following table describes the Security Settings-related components:

Components and Description

Security Settings Policy Processes and Interactions

Before learning about how Security Settings policy is processed, it is useful to review some basic concepts related to Group Policy processing.

Group Policy Processing

When a computer starts and a user logs on, computer policy and user policy are applied according to the following sequence:

• The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start.

• An ordered list of Group Policy objects is obtained for the computer. The list might depend on these factors:

  • Whether the computer is part of a domain and, therefore, subject to Group Policy through Active Directory.

  • The location of the computer in Active Directory.

  • Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done.

• Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is a synchronous process by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.

• Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.

• The user presses CTRL+ALT+DEL to log on.

• After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.

• An ordered list of Group Policy objects is obtained for the user. The list might depend on these factors:

  • Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory.

  • Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting.

  • The location of the user in Active Directory.

  • Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done.

• User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.

• Logon scripts run. Unlike Windows NT 4.0 scripts, Group Policy-based logon scripts are hidden and asynchronous by default. The user object script (which, as in Windows NT 4.0, is run in a normal window) runs last.

• The operating system user interface that is prescribed by Group Policy appears.

Note

• In mixed environments, there are three special cases you need to consider:

• If the computer account object is in a Windows NT 4.0 domain and the user account object is in Active Directory, only computer (not user) System Policy is processed when the user logs on. Then, user (not computer) Group Policy is processed.

• If the computer account object is in Active Directory and the user account object is in a Windows NT 4.0 domain, computer (not user) Group Policy is processed during computer startup. When the user logs on, user (not computer) System Policy is processed.

• If the Windows XP computer and user accounts are members of a Windows NT 4.0 domain, only System Policy (not Group Policy) for the computer and user is applied when the user logs on.

Group Policy Objects (GPOs) Storage

A Group Policy object is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at the domain level. The policy setting information of a GPO is stored in the following two locations:

• Group Policy containers in Active Directory. The Group Policy container is an Active Directory container that contains GPO properties, such as version information, GPO status, plus a list of other component settings.

• Group Policy templates in a domain’s system volume folder(Sysvol). The Group Policy template is a file system folder that includes policy data specified by .adm files, security settings, script files, and information about applications that are available for installation. The Group Policy template is located in the Sysvol folder in the domain \Policies subfolder.

The GROUP_POLICY_OBJECT structure provides information about a GPO in a GPO list, including the version number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a string that specifies the path to the file system portion of the GPO.

Group Policy Processing Order

Group Policy settings are processed in the following order:

1. Local Group Policy object: Each Windows XP computer has exactly one Group Policy object that is stored locally.

2. Site: Any Group Policy objects that have been linked to the site are processed next. Processing is synchronous and in an order that is specified by the administrator.

3. Domain: Processing of multiple domain-linked Group Policy objects is synchronous and in an order specified by the administrator.

4. Organizational units: Group Policy objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy objects that are linked to its child organizational unit, and so on. Finally, the Group Policy objects that are linked to the organizational unit that contains the user or computer are processed.

At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy objects can be linked. If several Group Policy objects are linked to an organizational unit, their processing is synchronous and in an order that is specified by the administrator.

This order means that the local Group Policy object is processed first, and Group Policy objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy objects.

This is the default processing order and administrators can specify exceptions to this order. A Group Policy object that is linked to a site, domain, or organizational unit (not a local Group Policy object) can be set to Enforced with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as Block Inheritance. Group Policy object links that are set to Enforced are always applied, however, and they cannot be blocked.

Security Settings Policy Processing

Security Settings policy is processed in the context of Group Policy processing.

1. During Group Policy processing, the Group Policy engine determines which security settings policies to apply.

2. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension.

3. The Security Settings extension downloads the policy from the appropriate location such as a specific domain controller.

4. The Security Settings extension merges all security settings policies according to precedence rules. The processing is according to the Group Policy processing order of local, site, domain, and organizational unit (OU), as described earlier in the Group Policy Processing Order section.If multiple GPOs are in effect for a given computer and there are no conflicting policies, then the policies are cumulative and are merged.

   This example uses the Active Directory structure shown in the following figure (Multiple GPOs and Merging of Security Policy). A given computer is a member of OU2, to which the GroupMembershipPolGPO GPO is linked. This computer is also subject to the UserRightsPolGPO GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting policies exist so the computer receives all of the policies contained in both the UserRightsPolGPO and the GroupMembershipPolGPO GPOs.

   Multiple GPOs and Merging of Security Policy

   

5. The resultant security policies are stored in secedit.sdb, the security settings database. The security engine gets the security template files and imports them to secedit.sdb.

6. The security settings policies are applied to computers.

The following figure illustrates the security settings policy processing.

Security Settings Policy Processing

Merging of Security Policies on Domain Controllers

Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:

• Network Security: Force logoff when logon hours expire

• Accounts: Administrator account status

• Accounts: Guest account status

• Accounts: Rename administrator account

• Accounts: Rename guest account

Another mechanism exists that allows security policy changes made by administrators using net accounts to be merged into the Default Domain Policy GPO. User rights changes that are made by using Local Security Authority (LSA) APIs are filtered into the Default Domain Controllers Policy GPO.

Special Considerations for Domain Controllers

If an application is installed on a primary domain controller (PDC) with operations master role (also known as flexible single master operations or FSMO) and the application makes changes to user rights or password policy, these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll receives a notification of any changes made to the security account manager (SAM) and LSA that need to be synchronized across domain controllers and incorporates the changes into the Default Domain Controller Policy GPO by using Scecli.dll template modification APIs.

When Security Settings are Applied

There are several instances after you have edited the security settings policies, when the settings are refreshed on the computers in the organizational unit linked to your Group Policy object:

• When a computer is restarted.

• Every 90 minutes on a workstation or server and every 5 minutes on a domain controller.

• By default, Security Policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO has not changed.

  It is possible to change this default period by using the registry entry MaxNoGPOListChangesInterval in the following subkey:

  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon \GPExtentions\{827D319E-6AC-11D2-A4EA-00C04F79F83A},

  The data type of this entry is REG_DWORD and the value is number of minutes.

Note

• Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference on the Microsoft Windows Server 2003 Deployment Kit companion CD.

Persistence of Security Settings Policy

Security settings can persist even if a setting is no longer defined in the policy that originally applied it.

In Windows Server 2003 and Windows XP, security settings might persist in the following cases:

• The setting has not been previously defined for the computer.

• The setting is for a registry security object.

• The settings are for a file system security object.

In Windows 2000, security settings might persist even if the setting is no longer defined in the GPO that originally applied it. All settings applied through local policy or through a Group Policy object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is. This behavior is sometimes referred to as “tattooing.”

Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values.

On domain controllers running Windows Server 2003 or Windows 2000, all security settings persist.

Permissions Required for Policy to Apply

Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy object apply to users or groups, and computers.

Filtering Security Policy

By default, all GPOs have Read and Apply Group Policy both Allowed for the AuthenticatedUsers group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or will not have a Group Policy object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.

Note

• Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.

Migration of GPOs Containing Security Settings

In some situations, a policy administrator might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings.

Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the Sysvol share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as taking a folder and copying it from one computer to another.

The following security policies can contain security principals and might require some additional work to successfully move them from one domain to another.

• User rights assignment

• Restricted groups

• Services

• File system

• Registry

• The GPO DACL, if you choose to preserve it during a copy operation

To ensure that data is copied correctly, administrators can use Group Policy Management Console (GPMC). When migrating a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also introduces migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs.

For more information about GPMC, see “How Group Policy Management Console Works” in this collection.

Security Settings Policies

Security Settings includes the following types of policies:

Account Policies

Defined for computers, account policies affect how user accounts can interact with the computer or domain. Account policies are implemented at the domain level. For domain controllers, Windows Server 2003 and Windows 2000 allow only one domain account policy: the account policy applied to the root domain of the domain tree. The domain account policy becomes the default account policy of any Windows-based computer that is a member of the domain; this account policy affects all domain users. If an account policy is defined for an organizational unit (OU), it will affect only local accounts on member servers. The account policy settings for the OU affect the local policy on any computers contained in the OU.

For domain accounts, only one account policy is permitted per domain. This account policy must be specified in the Default Domain Policy GPO, or in a new GPO that is linked to the root of the domain and has precedence over the Default Domain Policy GPO. The Default Domain Policy GPO is created when a computer running Windows Server 2003 or Windows 2000 Server is first promoted to domain controller. A domain controller always gets the account policy from a GPO linked to the domain, by default from the Default Domain Policy GPO.

Account policies include the following types of policies:

Password Policy

Used for domain or local user accounts. Determines settings for passwords, such as enforcement and lifetimes.

Account Lockout Policy

Used for domain or local user accounts. Determines the circumstances and length of time that an account will be locked out of the system.

Kerberos Policy

Used for domain user accounts. Determines Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in local computer policy.

Local Policies

These policies apply to the local computer and include the following settings:

Audit Policy

Determine whether security events are logged into the Security log on the computer. Also determines whether to log successful attempts, failed attempts or both. (The Security log is part of Event Viewer.)

User Rights Assignment

Determine which users or groups have logon rights or privileges on the computer.

Security Options

Enable or disable security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

Event Log

Event Log security policies specify attributes for events logs such as log size maximum, access rights, and retention methods. There are settings for application, security, and system logs.

Restricted Groups

You can define two properties for restricted groups, Members, and Members Of. The Members list defines who belongs and who does not belong to the restricted group. The Member Of list specifies which other groups the restricted group belongs to.

System Services

You can specify security policy for starting system services in automatic or manual mode, or to disable them. You can also set security properties on the objects to specify access permissions, inheritance or auditing settings, and ownership.

Registry

You can configure security descriptors for registry keys.

File System

You can use Security Settings to configure security descriptors for files, folders for file system objects.

Predefined Security Templates

Windows 2000 and Windows Server 2003 provide predefined security templates that you can use as a starting point for creating security policies that are customized to meet different organizational requirements. The templates can be customized using the Security Templates snap-in. After you customize the predefined security templates, they can be used to configure an individual computer or multiple computers. To configure individual computers, you can use the Security Configuration and Analysis snap-in, the secedit.exe command line tool, or you can import the template into Local Security Settings. You can configure multiple computers by importing a template into a Group Policy object.

You can also use a security template as a baseline for analyzing a system for potential security gaps or policy violations using the Security Configuration and Analysis snap-in. By default, the predefined security templates are stored in: Systemroot\Security\Templates.

Compatible (compatws.inf)

Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the highest privilege, while Users have the lowest. One way to significantly improve the security, reliability, and total cost of system ownership is to do the following:

• Make sure that end-users are members of the Users group

• Deploy applications that can run successfully under a User context.

  Applications that comply with the Certified for Windows Program meet this criterion. However, applications that are not certified for Windows 2000 or Windows Server 2003 might not run under a User context. The Certified for Windows Program is designed to ensure that applications that run on Windows Server 2003 or Windows 2000 Server can meet the highest standards for reliability, availability, security, and supportability.

  If you must support non-certified applications, you have two options:

  • Allow end-users to be members of the Power Users group.

  • Relax the default permissions granted to the Users group.

Since Power Users have inherent capabilities, such as creating users, groups, printers and shares, some customers would rather relax the default User permissions than allow end-users to be members of the Power Users group. This is precisely what the Compatible template is for. The Compatible template loosens the default file and registry permissions granted to Users in a manner that is consistent with the requirements of most non-certified applications. Additionally, since it is assumed that the administrator applying the compatible template does not want end users to be Power Users, the compatible template also removes all members of the Power Users group.

Note

• The Compatible template should not be applied to domain controller computers. For example, do not import the compatible template to the Default Domain Policy GPO or the Default Domain Controller Policy GPO.

Information about the Microsoft Certified for Windows Program is available on the Windows Server 2003 Web site.

Secure (secure*.inf)

The Secure templates (secure*.inf) define enhanced security settings that are least likely to impact application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings.

The Secure templates also limit the use of the LAN Manager and NTLM authentication protocols by configuring clients to send only NTLMv2 responses and Servers to refuse LAN Manager responses:

• In order to apply securews.inf to a member computer, all of the domain controllers that contain the accounts of all users that will logon to the client must be running Windows NT 4.0 Service Pack 4 or higher.

• In order to apply securews.inf to a member computer that is joined to a domain containing Windows NT 4.0 domain controllers, the clocks between the NT 4.0 domain controllers and the member computers must be within 30 minutes of each other.

• If a client is configured with securews.inf, it will not be able to connect to servers that only use the LAN Manager authentication protocol or Windows NT 4.0 servers prior to SP 4 using a local account defined on the target server.

• If a client is configured with securews.inf, it will not be able to connect to Windows 2000 or Windows NT 4.0 servers using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.

• If a client is configured with securews.inf, it will not be able to connect to a computer running Windows XP by using a local account that is defined on the target computer unless the clock on the target computer is within 20 hours of the clock on the client.

• If a client is configured with securews.inf, then it will not be able to connect to servers running LAN Manager that are operating in share-level security mode.

• If a server is configured with securews.inf, then a user with a local account on that server will not be able to connect to the server by using that local account from a client computer that is running only LAN Manager.

• If a Windows 2000 server is configured with securews.inf, then a client using a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two computers are within 30 minutes of each other.

• If a computer running Windows 2000 or Windows Server 2003 is configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two computers are within 20 hours of each other.

• If a domain controller is configured with securedc.inf, then a user with an account in that domain will not be able to connect to any member server from a client computer that is running only LAN Manager using their domain account.

LAN Manager clients include Windows for Workgroups, Windows 95, and Windows 98 platforms that do not have the Active Directory Client Extensions Pack installed. If the Active Directory Client Extensions Pack is installed on Windows 95 or Windows 98 platforms, those clients can use NTLMv2. Microsoft Windows Millennium Edition supports NTLMv2.

Windows NT-based computers (SP 4 and higher) can be configured to send only NTLMv2 responses by setting HKEY_LOCAL_MACHINE\System CurrentControlSet\Control\Lsa\LMCompatibilityLevel =3 or higher. The LMCompatibilityLevel registry value is exposed in the Local Policies\Security Options node of the Security Configuration Manager tools (Local Security Policy and Security Settings extension of Group Policy Object Editor) as Network Security: Lan Manager authentication level policy setting*.* Clients that have the secure or high secure template applied to them will have LMCompatibility set to 3 or higher.

The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (for example, users from untrusted domains) from doing the following:

• Enumerating account names and shares

• Performing SID to Name or Name to SID translations

Finally, the Secure templates enable server-side SMB packet signing, which is disabled by default for workstations and servers. Since client-side SMB packet signing is enabled by default, SMB packet signing is always negotiated when workstations and servers are operating at the secure level.

High Secure (hisec*.inf)

The High Secure templates are supersets of the Secure templates that impose further restrictions on the levels of encryption and signing required for authentication and for the data that flows over Secure Channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LAN Manager responses, the High Secure templates cause servers to refuse both LAN Manager and NTLM responses. The secure template enables server-side SMB packet signing, but the High Secure template requires it. The High Secure Template also requires strong (128 bit) encryption and signing for the Secure Channel data that constitutes domain-member and domain-domain trust relationships.

• To apply hisecws.inf to a member computer, the following requirements must be met:

  • All the domain controllers that contain the accounts of all users that will logon to the client must be running Windows NT 4.0 Service Pack 4 or higher, Windows 2000, or Windows Server 2003.

  • All the domain controllers for the domain to which the client is joined must be running at least Windows 2000.

• To apply hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must be running Windows 2000 or later.

• If a client is configured with hisecws.inf, it will not be able to connect to servers running only LAN Manager or Windows NT 4.0 servers prior to SP 4 using a local account defined on the target server.

• If a client is configured with hisecws.inf, it will not be able to connect to Windows 2000 or Windows NT 4.0 servers using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.

• If a client is configured with hisecws.inf, it will not be able to connect to a computer running Windows 2000 server or Windows Server 2003 using a local account defined on the target server unless the clock on the target server is within 20 hours of the clock on the client.

• If a client is configured with hisecws.inf, then it will not be able to connect to servers running LAN Manager operating in share level security mode.

• If a server is configured with hisecws.inf, then a client with a local account on that server will not be able to connect to it from a client that does not support NTLMv2.

• If a server is configured with hisecws.inf, then a Windows NT client with a local account on that server will not be able to connect to the server unless the Windows NT client is configured to send NTLMv2 responses.

• If a server is configured with hisecws.inf, then all clients that want to use SMB to connect to that server must have client-side SMB packet signing-enabled. Client-side SMB packet-signing is enabled by default for all Windows 2000 computers.

• If a domain controller is configured with hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers by using the domain account if the connection is being made from a computer using only LAN Manager authentication protocol.

• If a domain controller is configured with hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers using that domain account unless the following conditions apply:

  • Both client and target server are Windows 2000 or Windows Server 2003 and, thus, can use Kerberos rather than LAN Manager-based authentication.

  • The client is configured to send NTLMv2 responses.

• If a domain controller is configured with hisecdc.inf, then LDAP clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. Thus, bind requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XP or Windows Server 2003 request data signing if Transport Layer Security\Secure Sockets Layer (TLS\SSL) protocol is not already being used. If TLS\SSL is being used, then data signing is considered to be negotiated.

Clients that do not support NTLMv2 include Windows for Workgroups, Windows NT clients prior to SP 4, and Windows 95 and Windows 98 platforms that do not have the DS Client Pack installed. Windows NT-based computers (SP 4 and higher) can be configured to send only NTLMv2 responses by setting HKEY_LOCAL_MACHINE\System CurrentControlSet\Control\Lsa\LMCompatibilityLevel = 3 or higher. The LMCompatibilityLevel registry value is exposed in the Local Policies\Security Options node of the security configuration manager tools (Local Security Settings and Security Settings extension of Group Policy Object Editor) as the Network Security: Lan Manager authentication level policy setting. Clients that have the secure or high secure template applied to them will have LMCompatibility set to 3 or higher.

In addition to further restrictions on the use of computers running LAN Manager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the High Secure templates also restrict clients from caching domain credentials for subsequent logons when the domain controllers aren’t available. For example, this would prohibit traveling users who don’t have a network connection available for domain authentication from being able to login to their laptop.

Finally, Hisecws.inf uses restricted group settings to:

• Remove all members of the Power Users group.

• Ensure that only Domain Admins and the local Administrator account are members of the local Administrators group.

Hisecws defines these group restrictions under the assumption that only applications that are certified for Windows 2000 or Windows Server 2003 are deployed. With certified applications in place, neither the unsecured Compatible template nor the unsecured Power Users group is needed. Instead, end users can successfully run certified applications under the secure context of a normal User, which is defined by the default file system and registry ACLs.

Root Directory Permissions (rootsec.inf)

Specifies the new root permissions introduced with Windows XP. By default, rootsec.inf defines these permissions for the root of the system drive. This template can be used to reapply the root directory permissions if they are inadvertently changed or the template can be modified to apply the same root permissions to other volumes. As specified, the template does not overwrite explicit ACEs defined on child objects, it propagates only the permissions that are inherited by child objects.

No Terminal Server SID (notssid.inf)

The default file system and registry ACLs on servers grant permissions to a Terminal Server SID. The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not being used, this template can be applied to remove the unnecessary Terminal Server SID from these file system and registry locations. Removing the ACE for the Terminal Server SID from these default file system and registry locations does not increase the security of the system. Instead of removing the Terminal Server SID, it is recommended to simply run Terminal Server in Full Security mode rather than Application Compatibility mode. When running in Full Security mode, the Terminal Server SID is not used.

Setup security.inf

Setup security is a computer-specific template that represents the default security settings applied during installation of the operating system including the file permissions for the root of the system drive. This template, or portions thereof, can be used for disaster recovery purposes. Setup security.inf should not be applied by using Group Policy.

Note

• Do not apply the predefined security templates to production systems without performing comprehensive testing first to ensure that the security and functionality requirements for your specific organization are met.

You can view Security template settings by using the Security Templates snap-in. You can also examine the changes that a template would make if it were applied by using the Security Configuration and Analysis snap-in. To examine the proposed changes, import the template into a database then perform an analysis against that database. Performing an analysis does not change any system settings, but will highlight the differences between the settings specified in the template and the settings as they currently exist on the system.

Related Information

The following resources contain additional information that is relevant to this section.

• “How Core Group Policy Works” in the Group Policy Collection.

• For information about the Microsoft Certified for Windows Program, see the Windows Server 2003 Web site.