Group Policy Objects (part 1)
Group Policy Objects (GPOs) are one of the cornerstones of what makes Windows 2000 Server or Windows Server 2003 as powerful as they are. The Active Directory both stores and allows you to manipulate hundreds of settings that can lead to a 'safe and consistent computing environment' (as administrators might describe their efforts), or 'lockdown' as perhaps some users might insist.
26 July 2005
GPOs can be rolled-out at local, site, domain or organisational unit (OU) level - each overwriting the last in turn, if settings conflict to leave a general policy of 'closest to the user/PC' wins.
Use Group Policy to define security configurations for groups of users and computers, including the following security settings:
- Account policies (password policy, account lockout policy, and Kerberos policy)
- Local policies (user rights assignment, audit policy, and security options)
- IPSec policies
- Software restriction policies
- Wireless network configurations
- File and registry ACLs
- Service startup modes
- Public key policies
The Group Policy settings which you create are contained in a GPO. By associating a GPO with selected Active Directory system containers - sites, domains, and OUs - you can apply the GPO's policy settings to the users and computers in those Active Directory containers. Although some security settings affect user accounts, most settings are controlled by computer settings that must be applied to computers accounts; only software restriction policies and public key policies can be applied to user accounts.
From the initial 'shrink wrap' installation, you have some GPO protective settings in place - including an OU call domain controllers, which will automatically house any current or new domain controllers (you are advised to leave them there throughout). Servers and PCs (be they laptop or workstation) are automatically housed in the computers container, subject to the over-arching domain security policy from the start. You are encouraged to move such machines into OUs as your OU structure builds - allowing you the flexibility to further enhance your security environment by the addition of bespoke policies.
At this point it is pretty much an open canvas with a myriad of settings to choose from. It could therefore be quite easy to lose your way and have 'inconsistent behaviour' (a nice term which administrators use when they don't really know what's gone wrong).
To assist in setting security Microsoft have supplied a number of templates. Their physical location is %systemroot%\winnt\security\templates. There are two main Microsoft Management Console (MMCs) tools for viewing and applying them: The Security Configuration & Analysis Tool and Security Templates. These powerful yet simple to use MMCs allow us to see what settings are already applied, to parse in another template and see what differences there would be should we apply that new template, and even allow us to change the parameters of any new template before we apply it. It is therefore advisable to understand these templates before deciding to apply them or overwrite them as you see fit. The Windows Server 2003 templates are discussed below (Windows 2000 follows pretty much the same rules but have fewer settings, for example wireless policy etc).
Best practice is to use the Security Configuration and Analysis snap-in to apply templates or settings at local machine level only and to use Group Policy to import the templates to the GPO thus ensuring that any user or PC object in the container, to which the GPO is attached, will inherit those settings.
Selecting Predefined Security Templates
Windows Server 2003 includes a set of predefined security templates that you can use to create customised security policies. You can customise the templates by using the Security Templates snap-in. It is recommended that you save one of the predefined templates under another name, and then modify it to meet the needs of your organisation. You can use a template to configure either a single computer or an entire domain. You can also use a security template - with the Security Configuration and Analysis snap-in - as a baseline for analysing the local computer for potential security problems or policy violations. The default templates are as follows:
Setup Security.inf
Setup security.inf is a computer-specific template that represents the default security settings that are applied when the operating system is installed -including the file permissions for the root of the system drive.
The Setup security.inf template is created for each computer during installation. It can vary from computer to computer and is based on whether the installation was a clean installation or an upgrade. This template can be used on servers and client computers; it cannot be applied to domain controllers. You can apply portions of this template for disaster recovery purposes.
Do not apply Setup security.inf using Group Policy. It contains a large amount of data and can seriously degrade performance if it is applied by using Group Policy. Degraded performance can occur because policy is periodically refreshed, and a large amount of data then moves through the domain.
DC Security.inf
This template is created when Active Directory is installed onto a server. It reflects file, registry, and system service default security settings. Reapplying this template resets these settings to default values. Note that this template might overwrite permissions on new files, registry keys, and system services that are created by other applications
Compatws.inf
Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Of the three, the Administrators group has the most permissions, while the Users group has the least. Because of this, you can significantly improve security, reliability, and the total cost of system ownership by:
- Making sure that end users are members of the Users group.
- Deploying applications that can be run successfully by members of the Users group.
Members of the Users group can successfully run applications that are a part of the Windows Logo Program. However, members of the Users group might not be able to run applications that do not meet the requirements of the program. If other applications must be supported, there are two options:
- Permit members of the Users group to be members of the Power Users group.
- Relax the default permissions that are granted to the Users group.
Because Power Users have additional permissions such as creating users, groups, printers and shares, some administrators prefer to relax the default User permissions. The Compatible template changes the default file and registry permissions that are granted to the Users group in a way that is consistent with the requirements of most applications that do not belong to the Windows Logo Program. Additionally, because it is assumed that the administrator who is applying the Compatible template does not want members of the Users group to be Power Users, the Compatible template also removes all members of the Power Users group. Do not apply the Compatible template to domain controllers. For example, do not import the Compatible template to the Default Domain GPO or the Default Domain Controllers GPO.
Secure*.inf
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 prevent anonymous users, such as users from untrusted domains, from:
- Enumerating account names and shares.
- Performing Security ID (SID)-to-name or name-to-SID translations. If this is allowed, anonymous users can request user names (such as the administrator's user name) based on the user's security ID (SID) as well as requesting the SID for a user based on the user name.
The Secure templates enable server-side server message block (SMB) packet signing. By default, SMB packet signing is disabled for member servers. Because 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.
Additionally, the Secure templates limit the use of LAN Manager and NTLM authentication protocols by configuring clients to send only NTLM version 2 (NTLMv2) responses and by configuring servers to refuse LAN Manager responses.
Considerations for applying Securews.inf to a member computer include:
- All domain controllers that contain the accounts of all users that log on to the client must run Windows NT 4.0 Service Pack 4 (SP4) or later, Windows 2000, or Windows Server 2003.
- If the member computer is joined to a domain that contains domain controllers that are running Windows NT 4.0, the clocks on both the domain controllers and the member computers must be set within 30 minutes of each other (Clock Scew).
If a client is configured with Securews.inf, it cannot connect to:
- Servers that only use the LAN Manager authentication protocol or that run Windows NT 4.0 Service Pack 3 (SP3) or earlier using a local account that is defined on the target server.
- Servers running Windows 2000 SP3 and earlier or Windows NT 4.0 using a local account that is defined on the target server unless the clock on the target server is set within 30 minutes of the clock on the client.
- Computers running Windows XP by using a local account that is defined on the target computer unless the clock on the target computer is set within 36 hours of the clock on the client.
- Servers running LAN Manager that are running in share-level security mode.
If a server is configured with Securews.inf:
A user with a local account on the server cannot connect to the server by using that local account from a client computer that is running only LAN Manager.
For Windows 2000 SP3 and earlier, a client using a local account on the server that is also configured to use NTLMv2 authentication cannot connect unless the clocks on the two computers are set within 30 minutes of each other.
Likewise, if a domain controller is configured with Securedc.inf, a user who has an account in that domain cannot connect to any member server from a client computer that is running only LAN Manager using that domain account. These issues are well documented on Microsoft support site, www.support.microsoft.com
