Figure 16-7: Local Security Settings snap-in
By using Local Security Policy you can modify numerous security-relevant settings, including file system ACLs, registry ACLs, service ACLs and group membership. These settings can be used to manage a single computer or many computers at once. For computers that are not joined to an Active Directory domain, the Security Templates and Security Configuration and Analysis MMC snap-in components of Security Configuration Manager can be used to create security templates and apply them to individual computers.
| Note | Security settings that are defined via domain-based Group Policy always override security settings that are configured locally. |
Windows XP Professional allows you to configure security settings in the following areas:
Account Policies. This includes password policies such as minimum password length and account lockout parameters.
Local Policies. This includes auditing policy, assignment of user rights and privileges, and various security options that can be configured locally on a particular Windows XP Professional based computer.
Event Log Settings. This is used to configure auditing for security events such as successful and failed logon and logoff attempts.
Public Key Policies. These are used to configure encrypted data recovery agents, domain roots, and trusted certificate authorities.
Software Restriction Policies. This is a new Windows XP Professional policy-driven feature that allows you to prevent unwanted applications, such as viruses or other harmful software, from running.
IP Security Policy. This is used to configure network Internet Protocol (IP) security.
Restricted Groups. This is used to manage the members of built-in groups that have certain predefined capabilities. These groups include built-in groups such as Administrators, Power Users, Print Operators, Server Operators, and so on, as well as domain groups, such as domain Administrators. You can also add groups that you consider to be sensitive or privileged to the Restricted Groups list, along with their membership information. This allows you to track and manage these groups as part of system security configuration or policy.
System Services. This is used to configure and manage security settings for areas such as network services, file and print services, telephony and fax services, and Internet/intranet services. Security policy allows you to configure the service startup mode (automatic, manual, or disabled) as well as security on the service.
Registry. This is used to manage the security descriptors on registry subkeys and entries.
File System. This is used to configure and manage security settings on the local file system. The configuration file contains a list of fully qualified file or directory paths and security descriptors for each.
Administrators who have implemented an Active Directory domain structure can configure and apply additional security configuration options, such as Kerberos policy, for their clients running Windows 2000 Professional and Windows XP Professional.
| Note | For information about the use and management of Group Policy in Active Directory environments, see Group Policy in the Distributed Systems Guide. For more information about individual policy settings, see Security Event Messages in this book. |
When users run applications, they do so in the security context defined by their rights and restrictions. For example, a user might have the right to view and edit documents by using Microsoft Word, but not have the right to install or modify the application itself. These rights and restrictions do not always prevent untrusted applications from taking advantage of the security contexts of trusted applications. The increasing number of stealth applications distributed through e-mail and the Internet create a need for a more precise level of administrative control over the relationship between applications and the user s security context.
Software Restriction Policies are designed to assist you in regulating unknown or untrusted applications by allowing you to classify applications as trusted or untrusted. After trusted and untrusted applications have been identified, you can then apply a policy that regulates each application s ability to execute. This policy can apply to an entire computer or to individual users.
Software Restriction Policies includes two key items:
Security Levels, which define the default authorization level at which a user is allowed to run a piece of software.
Additional Rules, which specify the maximum authorization level at which a piece of software is allowed to run on that computer.
When a user attempts to run a software application, the computer uses the maximum values of these two components to determine the authorization level at which the application is allowed to run.
There are two default Security Levels, Unrestricted and Disallowed. You can use Unrestricted settings to define just the set of programs that are allowed to run. Disallowed can be used to specify only the programs that are forbidden to run.
Configuring applications as Disallowed is more secure than configuring applications as Unrestricted because it allows you to isolate specific unacceptable applications based on well-defined criteria. You can define default Security Level rules for each of the following criteria associated with an application:
Path. You can allow or disallow an application by creating a rule based on the application s file path.
When a path rule specifies a folder, it matches any program contained in that folder and any programs contained in subfolders. A path rule can use environmental variables, such as %WINDIR%. This makes the rule adaptable to a particular user s environment. A path rule can also incorporate wildcards, so that specifications such as *.VBS, for example, match all Visual Basic Script files.
Hash. You can allow or disallow an application based on the application s hashed file contents.
A hash is a fingerprint that uniquely identifies a file even if the file is moved or renamed. If software is renamed or moved, the hash rule will still apply because it is based on a cryptographic calculation derived from the contents of the file.
Certificate. You can allow or disallow an application based on the certificate associated with that application.
A certificate rule can apply to a self-signed certificate, a certificate issued from a commercial certification authority, or a certificate issued from a Windows 2000 public key infrastructure. Because they use signed hashes contained in the file signature, certificate rules are applied to files regardless of file name or location.
Internet Zone. You can allow or disallow an application based on the Internet zone from which the application is downloaded.
Applications can be downloaded from the following zones: Internet, Intranet, Restricted Sites, Trusted Sites, and My Computer. The Internet zone rules apply only to Windows Installer packages.
The following Additional Rules allow you to further refine your Software Restriction Policies:
Enforcement Properties. Determines whether software library files are excluded from the software policy restrictions. Also, you can use this option to prevent software policy restrictions from applying to local administrators.
Designated File Types. Allows you to add or delete file types from the list of what is considered to be executable code.
Trusted Publishers. Allows you to define who (end users, local administrators, or enterprise administrators) can select trusted publishers. In addition, you can use this option to specify revocation-checking options.
How you use Software Restriction Policies depends in large part upon how well you know what software applications your users are running. If you know all of the client software that will be allowed, then you can use Software Restriction Policies to enforce the use of allowed software only. If you do not know all of the applications that your users will run, you can still use Software Restriction Policies in a more limited way by disallowing applications that you are certain you do not want.
You can use Software Restriction Policies to protect users from viruses without preventing useful programs from running. For example, a number of recent worm viruses were authored using a language called Visual Basic Script. Many system administrators also use VB Script to perform system management tasks. An administrator might want to protect his computers from all VB Script based viruses, but still use VB Script for systems management and login scripts.
To do this, he or she can create a path rule such as *.VBS that disallows all VB Script files, and create a certificate rule identifying the certificate used by the IT department to sign administrative scripts. The IT department would sign all VB scripts using that trusted certificate. Any script not signed by that certificate would be prevented from running.
Windows XP Professional provides predefined security templates as a starting point for creating security policies that can be customized to meet different organizational requirements. You can customize the templates by using the Security Templates snap-in.
After the predefined security templates are customized, they can be used to configure an individual computer or thousands of computers. Individual computers can be configured by using the Security Configuration and Analysis snap-in or the Secedit.exe command-line tool, or by importing the template into the Local Security Settings snap-in. You can configure multiple computers by importing a template into Group Policy.
You can also use a security template in conjunction with the Security Configuration and Analysis snap-in as a baseline for analyzing a system for potential security holes or policy violations. To examine the proposed changes, import the template into a database and 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.
| Note | The predefined security templates should not be applied to production systems without comprehensive testing to ensure that they meet the security and functionality requirements for your specific organization. |
By default, the predefined security templates are stored in the Systemroot \Security\Templates folder. The predefined templates include:
Compatible (Compatws.inf)
Secure (Secure*.inf)
High Secure (Hisec*.inf)
Root Directory Permissions (Rootsec.inf)
Setup Security (Setup Security.inf)
Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges, while Users have the least. Thus, you can significantly improve the security, reliability, and total cost of system ownership by:
Ensuring that end-users are members of the Users group.
Deploying applications that run successfully under a User context.
Applications that comply with the Windows 2000 Application Specification can run successfully under a User context. However, applications that are not certified for Windows 2000 are not likely to run under a User context. Thus, if non-certified applications must be supported, there are two primary options:
Allow users of such applications to be members of the Power Users group.
Relax the default permissions granted to the Users group.
Because Power Users have inherent capabilities such as creating users, groups, printers and shares, some administrators would rather relax the default User permissions than allow users of non-certified applications to be members of the Power Users group. This is precisely what the Compatible template is for. It loosens the default file and registry permissions granted to the Users group in a manner that is consistent with the requirements of most non-certified applications. Also, because it is assumed that the administrator applying the Compatible template does not want users of non-certified applications to be Power Users, the Compatible template also removes all members of the Power Users group.
Because of the heightened security guidelines that must be applied to domain controllers, it is best if the Compatible template is not applied to domain controllers or imported into the default domain or default domain controller Group Policy objects.
The Secure templates 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 limit the use of the NTLM authentication protocol by configuring clients to send only NTLM version 2 responses and configuring servers to refuse LanManager responses.
In order to apply Securews.inf to a member computer, all of the domain controllers that contain the accounts of users that log on to the client must be running Windows NT 4.0 Service Pack 4 or higher. If a server is configured with Securews.inf, a client with a local account on that server will not be able to connect to it from a LanManager client using that local account. If a domain controller is configured with Securedc.inf, a user with an account in that domain will not be able to connect to any member server from a LanManager client by using their domain account.
| Note | You can use LanManager on clients running Microsoft Windows for Workgroups, as well as Microsoft Windows 95 and Microsoft Windows 98, without the DS Client Pack installed. If the DS Client Pack is installed on clients running Windows 95 and Windows 98, those clients can use NTLMv2. Windows Me supports NTLMv2. |
The Secure templates also provide further restrictions by preventing anonymous users (for example, users from untrusted domains) from:
Enumerating account names and shares
Performing SID to name or name to SID translations
Finally, the Secure templates enable server-side Server Message Block (SMB) packet signing, which is disabled by default for workstations and servers. Because client-side SMB packet signing is enabled by default, SMB packet signing will always be negotiated when workstations and servers are operating at the secure level.
The High Secure templates are supersets of the secure templates and 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 NTLM responses, the High Secure templates cause servers to refuse both LanManager and NTLM responses. While the Secure templates enable server-side SMB packet signing, the High Secure templates require it. Also, the High Secure templates require strong (128-bit) encryption and signing for the Secure Channel data that constitute domain-to-member and domain-to-domain trust relationships. Therefore, in order to apply Hisecws.inf to a member computer:
All of the domain controllers that contain the accounts of all users that will log on to the client must be running Windows NT 4.0 Service Pack 4 or higher.
All of the domain controllers for the domain that the client is joined to must be running Windows 2000 or later.
The following rules also apply to the High Secure template:
In order 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 server is configured with Hisecws.inf, 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, all clients that wish 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 XP Professional based computers.
If a domain controller is configured with Hisecdc.inf, a user with an account in that domain will not be able to connect to any member server from a client that does not support NTLMv2.
If a domain controller is configured with Hisecdc.inf, Lightweight Directory Access Protocol (LDAP) clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. Thus, bind requests that use ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with Windows XP Professional request data signing if Transport Layer Security\Secure Sockets Layer (TLS\SSL) is not already in use. If TLS\SSL is in use, data signing is considered to be negotiated.
In addition to further restrictions on the use of downlevel LanManager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the High Secure templates also limit the use of cached logon data such as those data stored by Winlogon and Stored User Names and Passwords.
Finally, the template Hisecws.inf removes all members of the Power Users group based on the assumption that only applications that are certified for Windows 2000 have been deployed. With certified applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can successfully run certified applications under the secure context of a normal User.
By default, the Rootsec.inf template specifies the new permissions, introduced in Windows XP Professional, for the root of the system drive. This template can be used to reapply the default root directory permissions if they are inadvertently changed. In addition, the template can be used to apply the same root permissions to other volumes.
| Note | This template does not overwrite explicit ACEs defined on child objects. It propagates only the permissions that are inherited by child objects. |
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 replaces the combination of Basic.inf and Ocfiles.inf that existed in versions of Windows earlier than Windows XP Professional. Setup security.inf should not be applied by using Group Policy.
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 in use, 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 does not, however, increase the security of the system. Therefore, instead of removing the Terminal Server SID, it is recommended that you run Terminal Server in full security mode rather than application compatibility mode. When Terminal Server is running in full security mode, the Terminal Server SID is not used.
To view and implement security policy on a local computer, you must have Administrator rights to the computer. Administrators can use the following Windows XP Professional tools to view and configure security policy settings:
Local Security Policy. This Group Policy snap-in can be used to configure security settings on individual computers. The Local Security Policy snap-in can be used to configure Account Policies, Audit Policies, User Rights, and numerous other security options.
Security Settings extension to Group Policy. This Group Policy snap-in can be used to establish security policies for domains or organizational units (OUs). The Group Policy snap-in can be used to configure the same settings that Local Security Policy configures, as well as Event Log settings, Restricted Groups, System Services, file ACLs and registry ACLs.
Security Templates snap-in. This is a stand-alone Microsoft Management Console snap-in that can be used to create a text-based template file that contains security settings for all security areas. The security templates snap-in can be used to configure Account Policies, Local Policies, Event Log settings, Restricted Groups, System Services, registry settings, and File System settings.
Security Configuration and Analysis snap-in. This is a stand-alone MMC snap-in that can configure or analyze Windows XP Professional operating system security. Its operation is based on the contents of a security template that was created by using the Security Templates snap-in.
Secedit.exe. This is a command-line version of the Security Configuration and Analysis snap-in. It allows security configuration and analysis to be performed without a graphical user interface (GUI).
You can use the following procedure to view the security policy settings on a computer running Windows XP Professional.
To view Local Security Policy settings
In Control Panel, click Performance and Maintenance, click Administrative Tools, and then double-click Local Security Policy.
The Local Security Settings snap-in is illustrated in Figure 16-7. You can also view the Local Security Settings container from the command line.
Figure 16-7: Local Security Settings snap-in
To view the Local Security Settings container from the command line
In the Run dialog box, type:
secpol.msc
To modify a local security policy setting, double-click the security item and revise the policy as needed. For example, you can use the following procedure to set the local policy Prevent users from installing printer drivers.
To set the Prevent users from installing printer drivers local policy
In the Local Security Settings snap-in, in the left pane under Security Settings, click the PLUS SIGN (+) to expand Local Policies.
Click Security Options.
In the right pane, double-click Devices: Prevent users from installing printer drivers.
Click Enabled, and then click OK.
In the left pane, right-click Security Settings, and then click Reload.
To edit a Group Policy object, the user must have both Read and Write access to the Group Policy object, and must be one of the following:
A member of the Administrators group for the local computer, domain, or enterprise.
A member of the Group Policy Creator Owners group who has previously created the Group Policy object.
A user with delegated access to the Group Policy object. That is, an administrator or a user who has had access delegated to him or her by someone with the appropriate rights using the Security tab on the Group Policy Object Properties page.
By default, Group Policy objects allow members of the Domain Administrators, Enterprise Administrators, and Group Policy Creator Owners groups Full Control without the Apply Group Policy attribute set. This means that they can edit the Group Policy object, but the policies contained in that Group Policy object do not apply to them.
By default, Authenticated Users have Read access to the Group Policy object with the Apply Group Policy attribute set. This means that Group Policy affects them.
Domain Administrators and Enterprise Administrators are also members of Authenticated Users; therefore, members of those groups are, by default, affected by Group Policy objects unless you explicitly exclude them.
When a non-administrator creates a Group Policy object, this person becomes the Creator Owner of the Group Policy object (GPO) and can edit the GPO. When an administrator creates a Group Policy object, the Domain Administrators group becomes the Creator Owner of the GPO; therefore any member of the Domain Administrators group can edit the GPO.
You can delegate Group Policy by creating and saving the Group Policy snap-in consoles (.msc files), and then specifying which users and groups have access permissions to the Group Policy object or to an Active Directory container. You can define permissions for a Group Policy object by using the Security tab on the Properties page of the Group Policy object; these permissions grant or deny access by specified groups to a Group Policy object.
This type of delegation is also enhanced by the policy settings available for MMC. Several policies are available in the Administrative Templates node, which is located under Windows Components in the Microsoft Management Console. These policies enable the administrator to define which MMC snap-ins the affected user can or cannot run. The policy definitions can be inclusive, which allows only a specified set of snap-ins to run, or they can be exclusive, which does not allow a specified set of snap-ins to run.
The Security Templates snap-in allows you to create a text-based template file that can contain security settings for all of the security areas supported by local security policy. You can then use these template files to configure or analyze system security in the following ways:
You can import a template file into the Security Settings extension to configure local, domain, or OU security policy.
You can use the Security Configuration and Analysis snap-in to configure or analyze system security based on a text-based security template.
You can use the Secedit.exe command-line tool directly or in conjunction with other management tools such as Microsoft Systems Management Server or Task Scheduler to deploy a security template or trigger a security analysis.
To load the Security Templates snap-in and view security policy settings
In the Run dialog box, type:
mmc /s
Click OK.
On the File menu, click Add\Remove Snap-in, and then click Add.
In Available Standalone Snap-ins, select Security Templates.
Click Add, and then click Close.
Click OK.
In the left pane, click the PLUS SIGN (+) to expand Security Templates.
Expand C:\Windows\security\templates.
The Security Templates snap-in is illustrated in Figure 16-8.
| Note | If you installed Windows XP Professional in a different drive or directory, that path will display instead of C:\Windows.
|
You can create your own security template, or you can select the existing template that most closely meets your needs and make any additions or changes that you want to that template.
To create a new security template
Double-click Security Templates, right-click the default templates folder, and then click New Template.
This creates a blank template file without any security settings. You can now completely customize the template to meet the needs of your organization.
Once you create your template or make all of the desired changes to an existing template, it is automatically saved to the templates directory. By using Save As, you can overwrite the existing template of that name or save the template under a new name.
| Tip | Do not overwrite the default templates in case you later realize that the template you create does not work as desired. |
To save a new or modified security template
Right-click the template name, select Save As from the shortcut menu, fill in a new name, and then click OK.
After you create a security template for your environment, you need to apply it to your computer. When you apply a template to existing security settings, the settings in the template are merged into the computer s security settings.
To apply a security template to a computer
In the Group Policy snap-in, double-click Computer Configuration\Windows Settings.
Right-click Security Settings, and then click Import Policy.
Select the template file that you want to import into your environment.
Click OK.
You can also export the security template for your system from the Group Policy snap-in.
To export a security template
In the Group Policy snap-in, double-click Computer Configuration\Windows Settings.
Right-click Security Settings, and then click Export List.
Type in the name and location for the text file that you are exporting.
Alternatively, you can navigate to the \%systemroot%\Security\Templates folder and copy the appropriate template file to another network location or to a floppy disk.
You can perform the following key security-related tasks by using Windows XP Professional security templates:
Configure permissions for a file system directory.
Create a restricted Group Policy.
Inherit, overwrite, and ignore policy changes.
You can use the following procedure to configure permissions for file system directories.
To configure permissions for file system directories
Open the Security Templates snap-in and expand Securews.inf.
Right-click File System in the left pane, and then click Add File.
Click the %systemroot%\repair folder, and then click OK.
This brings up the Security Properties dialog box, which allows you to specify permissions for the %systemroot%\repair directory in the Securews.inf template.
Click the Add button, and in the drop-down box select Administrators group.
Click Add, and then click OK.
Select the Full Control check box.
Click the Advanced button. Clear the Inherit from parent the permission entries that apply to child objects check box.
Click OK.
Select the Replace existing permission on all subfolders and files with inheritable permissions button, and then click OK.
A restricted Group Policy allows you to define who can and cannot belong to a specific group. When a template (or policy) that defines a restricted group is applied to a system, the Security Configuration Tool Set adds members to the group and removes members from the group to ensure that the actual group membership coincides with the settings defined in the template (or policy). The following procedure describes how to create a restricted Group Policy.
To create a restricted Group Policy
In the left pane, in Security Templates, double-click a security template.
Right-click Restricted Groups, and then select Add Group.
In the Group dialog box, type the group name, and then click OK.
Double-click the Restricted Groups folder.
| Tip | To assist in troubleshooting, use a name that indicates that the group is affected by a restricted Group Policy. |
In the right pane, double-click the new group name. You can now define who can be a member of the restricted group and specify other groups of which that group can be a member.
Click Add in the Members of this group section and then click Browse.
In the Select Users dialog box, locate and select user names.
Click Add, and then click OK.
The restricted Group Policy defines which users can be members of the specified local group when the specified template is used to configure a Windows 2000 or Windows XP Professional based system. During configuration, the Security Configuration Tool Set removes all other users that belong to the group at the time of configuration. Similarly, if at the time of configuration the specified user does not belong to the specified group, the Security Configuration Tool Set adds the user to the group.
If no users are specified as members of a defined restricted group, the Security Configuration Tool Set removes all current members of that group when the template is used to configure a system.
If no groups are specified for a restricted group to belong to, no action is taken to adjust membership in other groups.
After you define permissions for a file system or registry object, you can use the Security Configuration Tool Set to configure the object s children.
If you select Propagate inheritable permissions to all subfolders and files, normal Windows XP Professional ACL inheritance procedures are put into effect that is, any inherited permissions on child objects are adjusted according to the new permissions defined for this parent. Any explicit access control entry (ACE) defined for a child object remains unchanged.
If you select Replace existing permissions on all subfolders and files with inheritable permissions, all explicit ACEs for all child objects (which are not otherwise listed in the template) are removed, and all child objects are set to inherit the inheritable permissions defined for this parent.
To prevent a child object from being overwritten by a parent, the child object can be added to the template and ignored. If a child object is added to the template and ignored, that child s inheritance mode and explicit ACEs remain untouched.
Choosing the option Do not allow permissions on this file or folder to be replaced makes sense only if an ancestor of that object is configured to overwrite children. If no ancestor exists in the template, ignoring an object has no impact. If an ancestor exists but is configured so that children inherit, then ignoring a child has no impact.
By saving a security template file, you can copy the file containing your desired configuration settings to multiple computers running Windows XP Professional.
You can analyze, summarize, and evaluate your security policy configuration by using Security Configuration and Analysis tools. For more information about using the Security Configuration and Analysis tools, see Auditing and Analyzing Access Control later in this chapter.
