To fully understand the options for customizing security templates, we must first review what a standard security template provides, as well as the structure of the template. You will then have a much better understanding of what you can add to security templates.
The standard security templates provided with the operating system are stored in the C:WindowsSecurityTemplates folder by default. Every security template has the same structure and the same configurable security attributes. To access and modify these security templates, you use the Security Templates snap-in. Figure 15-1 shows the Security Templates snap-in, as well as the security template structure.
More Info
For more information about the standard security templates and how to access the Security Templates snap-in, see Chapter 5.
The account policies settings affect how user accounts can interact with the computer or domain with regard to authentication and passwords. Each domain account can have only one account policy. The account policy must be defined in the Default Domain policy (or in another GPO linked to the domain level), and it is enforced by the domain controllers that manage the domain. Domain controllers always obtain the account policy from the Default Domain Policy Group Policy object (GPO), even if a different account policy has been applied to the organizational unit (OU) that contains the domain controller computer accounts. By default, clients and servers that are joined to the domain also receive the same account policy for their local user accounts. However, you can configure the account policy for the client and server local SAM to be different from the domain account policy by defining an account policy that is linked to an OU containing the client and server accounts.
Account policies have three subsets: Password Policy, Account Lockout Policy, and Kerberos Policy, as shown in Figure 15-2.
Password Policy. These settings are for passwords, such as password length, maximum password age, and password complexity. These settings are applied to domain accounts and local user accounts. They can’t be extended with custom password policy categories added to the security template.
Account Lockout Policy. These settings determine the circumstances and length of time that an account can be locked out of the system. They apply to domain accounts and local user accounts. These settings can’t be extended with custom account lockout policy categories added to the security template.
Kerberos Policy. These are Kerberos-related settings such as ticket lifetimes and enforcement. Kerberos policies do not exist in Local Computer Policy. They are used for domain user accounts and even though they are available to configure in a GPO linked to an OU, they are only valid at the domain level. These settings can’t be extended with custom Kerberos policy categories.
More Info
For more information about password policies, account lockout policies, and kerberos policies, see Chapter 5.
Local policies include various security settings that apply to computers. There are three categories of settings under local policies: Audit Policy, User Rights Assignment, and Security Options.
More Info
For information about audit policy categories, user rights, and security options, see Chapter 5.
Audit Policy. These settings determine whether security events are logged in the Security log in Event Viewer on the computer. For example, they determine whether a logon or attempt to access a resource has been successful or has failed. These settings can’t be extended with custom audit policy categories.
Tip
Before you implement an audit policy, you must decide which event categories you want to audit. The audit settings that you choose for the different event categories define your auditing policy. On member servers and workstations that are joined to a domain, audit settings for all of the event categories are undefined by default. On domain controllers, auditing is turned on for most of the audit policy settings by default. By defining audit settings for specific event categories, you can create an audit policy that suits the security needs of your organization.
User Rights Assignment. These settings determine which users or groups have logon rights or privileges on the computer. These settings can’t be extended with custom user rights.
Security Options. These options enable or disable various 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. These settings can be expanded with custom security options.
Note
See the "Customizing Security Options" section in this chapter for more information on how to customize your own settings within the security templates.
The Event Log settings define attributes related to the application, security, and system logs. You can configure maximum log size, access rights to the logs, and the retention method of the logs. These settings can’t be expanded with custom event log categories in a security template.
The application and system logs track events on every computer by default. The security log on member servers and clients does not track any events by default, but Windows Server 2003 domain controllers do. To start tracking security events on member servers and clients, you must first enable auditing, as described in the "Local Policies" section. You must also enable auditing on the appropriate resource (file, folder, registry key, printer, or Active Directory object) to begin tracking object access events. All event logs are accessed and reviewed from the Event Viewer.
The Restricted Groups settings allow the administrator to control two properties for security groups on both local computers and in Active Directory. The first property that can be controlled is the list of members of the group. The Members setting within the restricted groups interface controls this behavior, as shown in Figure 15-3.
The Members Of setting controls the groups to which the configured group belongs. This, too, can be seen in Figure 15-3.
Tip
An empty Member Of list means that the groups to which the restricted group belongs are not specified within the policy.
You can use Restricted Groups policy to control group membership. Using the policy, you can specify which members can be part of a group. Any members that are not specified in the policy are removed during Group Policy refresh. In addition, the second membership configuration option ensures that each Restricted Group is a member of only those groups that are specified in the Member Of column.
For example, you can create a Restricted Groups policy to allow only specified users (for example, Alice and John) to be members of the Administrators group. When policy is refreshed, only Alice and John will remain as members of the Administrators group.
The System Services area of the security templates allows an administrator to centrally control services on clients, servers, and domain controllers. System Services can define the startup mode for any service on any computer in the domain. The startup mode options include Manual, Automatic, and Disabled. System Services also defines the access permissions for services on the target computer. Permissions can be set to allow any combination of starting, stopping, or pausing a service on the computer. This greatly improves control over the services running on computers in the domain. Figure 15-4 shows the interface for a standard service that you can specify within the security templates.
The System Services area of the security templates is dynamic in that the list of services corresponds to the computer performing the administration of the security template or GPO. Therefore, the service you need to configure for a workstation or server might not be listed as you attempt to configure the services. This behavior can be controlled and in some ways customized. See the "Customizing Services in the Security Templates" section in this chapter for more information on customizing system services within a security template.
The Registry section within the security template allows an administrator to define access permissions on registry keys on the target computer. When you configure a registry key within the security template, you see a list with HKEY_CLASSES_ROOT, HKEY_LOCAL_MACHINE, and HKEY_USERS that let’s you find the key that you want to control. This interface can be seen in Figure 15-5.
After selecting the registry key, you will have the option to configure all aspects of the security permissions for the object. This includes the following, which can be seen in Figure 15-6:
Discretionary access control list (DACL). The part of the security descriptor that grants or denies specific users and groups permission to access the object.
System access control list (SACL). The part of the security descriptor that triggers the auditing of events to be logged in the security log.
Ownership. The part of the security descriptor that controls which user or group has ultimate control over the object, including the ability to change any permission, modify the contents, and delete the object.
More Info
For more information about the accessing and editing the registry, search for "registry", "registry editing tools", and "overview of the windows registry" in TechNet at http://www.microsoft.com/technet. For information about the registry settings in the security templates, see Chapter 5.
The File System section within the security template is similar to the registry section. It allows an administrator to define access permissions on files and folders on the target computer. When you configure a file or folder within the security template, you are shown a list of all files and folders on the local computer, as shown in Figure 15-7.
Again, like the registry keys, the file and folder permissions can be finely controlled. You can control the DACL, SACL, and ownership using security templates.
More Info
For more information about file and folder permissions, permission inheritance, auditing, and ownership, search for "dacl", "sacl", "ownership", "security descriptors", and "ACL inheritance" in TechNet at http://www.microsoft.com/technet.