e-academy – IT training excellence in Cardiff, Newport, Bristol and South Wales

Group Policy Objects (part 2)

We continue our look at Group Policy Objects, one of the cornerstones of what makes Windows 2000 Server or Windows Server 2003 as powerful as they are.

26 July 2005

Hisec*.inf

The Highly Secure templates are supersets of the Secure templates that require greater levels of encryption and signing for authentication and for the data that flows over secure channels and between SMB clients and servers. For example, the Secure templates cause servers to refuse LAN Manager responses; the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. The Secure template enables server-side SMB packet signing; the Highly Secure template requires it. The Highly Secure templates limit the use of cached logon data, such as data stored by Winlogon and Stored User Names and Passwords. Hisecws.inf uses Restricted Group settings to:

  • Remove all members of the Power Users group.
  • Make sure that only the Domain Admins group and the local Administrator account are members of the local Administrators group.

Hisecws.inf defines these group restrictions under the assumption that users only use applications that belong to the Windows Logo Program. When using those applications, neither the Compatible template nor the Power Users group is needed. Instead, users can run those applications successfully under the secure context of a member of the Users group. The Users group is defined by the default security settings of the file system and registry. Members of the Administrators group can still use any application.

Additionally, the Highly Secure templates require strong encryption and signing for the secure channel data that constitutes domain-to-member and domain-to-domain trust relationships. Thus, consideration for applying Hisecws.inf to a member computer include:

  • All of the domain controllers that contain the accounts of all users that can log on to the client must be running Windows NT 4.0 SP4 or later, Windows 2000, or Windows Server 2003.
  • All of the domain controllers for the domain that the client is joined to must run Windows 2000 or Windows Server 2003.

Clients that are configured with Hisecws.inf cannot connect to:

  • Computers that only run LAN Manager or computers running Windows NT 4.0 SP3 or earlier using a local account defined on the target server.
  • Servers running Windows 2000 SP3 and earlier or Windows NT 4.0 SP4 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 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.
  • LAN Manager servers that are operating in share-level security mode.

To apply Hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must run Windows 2000 or Windows Server 2003 operating systems.

If a server is configured with Hisecws.inf:

  • A user who has a local account on that server cannot connect to that server from a client that does not support NTLMv2.
  • A client that has a local account on that server cannot connect to that server unless the client is configured to send NTLMv2 responses.
  • All clients that want to use SMB to connect to the server must enable client-side SMB packet signing. By default, all clients running Windows 2000 and Windows XP operating systems enable client-side SMB packet signing.

If a domain controller is configured with Hisecdc.inf:

  • If a user attempts to connect to member servers by using a domain account in the same domain, the connection will fail if the user's client only uses the LAN Manager authentication protocol.
  • LDAP clients cannot bind with the Active Directory LDAP server unless data signing is negotiated. LDAP BIND requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients included with Windows XP request data signing if Transport Layer Security/Secure Sockets Layer (TLS/SSL) is not already being used. If TLS/SSL is being used, data signing is negotiated.
  • A user who has an account in that domain cannot connect to member servers by using that domain account unless:
    • Both the client and target server are running Windows 2000, Windows XP, or Windows Server 2003, and both can use Kerberos-based authentication instead of LAN Manager-based authentication.
    • The client is configured to send NTLMv2 responses.

Rootsec.inf

Rootsec.inf specifies the root permissions. 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 permissions that are defined on child objects; it propagates only the permissions that are inherited by child objects.

Iesacls.inf

Microsoft Windows 2003 lockdown for Internet Explorer settings. These settings equal, or surpass, the old Internet Explorr lockdown tool settings. By default IIS 6.0 is not installed on Microsoft Windows Server 2003.

Notssid.inf

The default file system and registry ACLs on servers assign permissions to a Terminal Server security identifier (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 Terminal Server SIDs that are not necessary from the file system and registry locations. However, removing the access control entry (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, run Terminal Server in Full Security mode. When you run Terminal Server in Full Security mode, the Terminal Server SID is not used.

As you can see they are relatively complex but at least they exist in easily applied templates. Once you are sure of either your default level of security or the level that you aspire to achieve then you can crack on and apply the templates including amending them where necessary. If you intend to amend the templates it is of course always better to use the MMC to parse in the templates then change them but save to a new template (you can save your own templates) thus you will always be able to back track to the Microsoft templates as described above. Only administrators have permissions to modify the templates in the Security folder; users without administrative permissions can save their templates to another folder.

Microsoft is adding template settings all the time through various upgrades and service packs so the search for settings that ensure a secure network that still allows user functionality is here but continues...