Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

In large distributed computing environments such as a Windows domain, consisting of many subjects and even more objects, the management of authorization data may become a very tedious and time-consuming task. With the exception of the full control permission that is automatically given to the owner of the object, all other permissions must be set manually by an administrator or by the object’s owner. To ease authorization management, Windows includes the following authorization intermediaries: groups and user rights.

• Groups provide a way to group entities with similar capabilities. They facilitate authorization management of object permissions. Administrators typically add all authenticated Windows entities (users and machines) that have similar resource permissions or user rights to the same group.

• User rights define the capabilities of subjects to manage system resources and to perform system-related tasks. For instance, who can log on locally to a domain controller? Who can change the system time? Who can load device drivers? They facilitate authorization management for system resources and system-related tasks. User rights should not be confused with access rights or permissions. User rights apply to a computer system; access rights apply to an object.

Group intermediaries can be used to ease the administration of user rights intermediaries. For example, you can give all the members of the IT support department the right to add computers to the domain.

10.5.1 Groups

The following list gives an overview of the four major differences between the way groups are implemented in NT4 and in Windows 2000/Windows Server 2003.

Windows 2000 and Windows Server 2003 support two types of groups: security groups and distribution groups. Distribution groups are mail-oriented. They demonstrate the tight integration of the Microsoft Exchange mail server (Exchange 2000 and Exchange 2003) and the Windows Operating System. Contrary to a security group, a distribution group does not have an SID and cannot be used in any security-related process (authorization or delegation).

Windows 2000 and Windows Server 2003 support four types of security groups. They are listed in Table 10.9 together with their usage scope (where can I use the group?), their content scope (what can be contained in the group?), and the database or file that holds the group definition and membership.

* This means: where the group’s name, type and SID are stored.

The usage scope deserves some more explanation. A global usage scope means that the group can be used in the ACL of any object, anywhere in the forest (or trusted domains or trusted forests). A local usage scope means that the group can be used only in the ACL of an object in the local domain (for a domain local group) or in the ACL of an object on the local computer (for a local group).

Windows 2000 and Windows Server 2003 groups can be nested. An administrator can, for instance, create a global group Employees and embed two other global groups in it: Consultants and Managers. This feature is only available if your domain does not include any NT4 domain controllers. The group scope and group type of domain local, global, and universal security and distribution groups can be changed, as long as the domain does not include any NT4 domain controllers. Furthermore, the members of the group and the group itself need to meet the criteria for the usage scope and content scope that the group would require to have after the conversion takes place. For example, you cannot convert a domain local group to a universal group, if the domain local group contains another domain local group as a member. Similarily, you cannot convert a universal group to a global group, if the universal group is a member of another universal group in a different domain.

• A universal group can be converted to a domain local or a global group.

• A domain local group can be converted to a universal group.

• A global group can be converted to a universal group.

• A security group can be converted to a distribution group and the other way around. Before a security group is converted to a distribution group, Windows warns you about the possible authorization consequences of doing so (as illustrated in Figure 10.29).

  Figure 10.29: Security to distribution group conversion warning.

A special note should be made on local groups. As Table 10.6 shows, local groups are very different from the three other group categories. They are only meaningful on the local computer, cannot be nested, and are stored in the SAM. Local groups are sometimes referred to as aliases. An alias identifies an object in a different way.

Groups in Windows 2000 mixed and native mode

The availability of some of the group features listed in the previous section depends on whether your Windows domain contains NT4 domain controllers or not. Translated in Windows Server 2003 speak: They are dependent on the functionality level of your Windows domain. For more information on the Windows Server 2003 functionality levels, see Chapter 2 of this book. Table 10.10 gives an overview of the Windows group features and their availability.

* Universal groups can be created in mixed mode domains, but these can only be universal distribution groups.

Built-in security groups

The goal of this section is not to provide a complete overview of the built-in Windows Server 2000 and Windows Server 2003 security groups. We will focus on the differences with NT4. Table 10.11 lists the new Windows 2000 built-in security groups. Table 10.12 lists the new Windows Server 2003 built-in security groups.

The Domain Controllers, Domain Computers as well as the Domain Users group are used as the primary group of the respective security principals. As such, AD objects are not an explicit member of these groups: the OS computes their membership dynamically. Every AD object can only have one of them as its primary group. Also the pre-Windows 2000 compatible Access group deserves some more explanation. It enables applications that cannot run using the AD authorization settings as they are enforced by a Windows 2000 Domain Controller, to run in a Windows 2000 or Windows Server 2003 environment. If the application’s security identity is a member of this group, the application will be capable of reading AD user and group objects.

Well-known security principal groups

A very powerful type of group is the security group, whose membership is controlled automatically by the operating system. A user becomes a member of a well-known security principal group if he or she meets a certain condition. Although their membership cannot be controlled, they can be used, like any other group, for delegation and authorization settings. An interesting characteristic of these groups is the way they are replicated between AD instances: Even though they may contain thousands of objects, their membership is not replicated. Like the three primary groups (Domain Users, Domain Controllers and Domain Computers) that were mentioned above, the OS computes their membership dynamically. The well-known security principal groups are stored in the AD configuration-naming context Well-known Security Principals container. All of the special security groups are listed in Table 10.13. The ones that are new to Windows Server 2003 are listed in Table 10.14.

Administrator groups

The pyramid shown in Figure 10.30 shows the level of administrative privileges Windows 2000 gives to its default security groups. Table 10.15 shows the default memberships of these groups on a Windows 2000 workstation, member server, and domain controller. Notice that some groups are not available on all Windows computer types (N/A) and that some groups, by default, do not have members (—).

Figure 10.30: Windows administrator pyramid.

* The enterprise admins group is only defined on the domain controllers of the root domain of a forest.

† The Domain Admins group is added to the local Administrators group when the machine joins a domain. The same is true for the Domain Users and the local Users group.

Let’s look a bit more in detail at the power of the Windows Enterprise Admins, Domain Admins, and Administrators groups. It is also worth comparing these groups to the administrator groups that were available in NT4.

NT4 had two administrator groups: Domain Admins and Administrators:

• The Administrators group on domain controllers was one and the same group shared between all domain controllers of a domain. A member of this group had the right to manage all domain resources, including users, groups, rights, account policy, audit policy, trusts, shares, and the services on all domain controllers.

• The Administrators group on a member server or a workstation had the right to manage all resources on the local workstation or member server system.

• The Domain Admins group did not have proper rights. Members of the Domain Admins group receive administrative right over every system in a domain because, by default, when a system joined the domain, the Domain Admins group was added to the local Administrators group.

A key problem of NT4 is its inflexible nature on the level of granular administration. If you wanted to give an administrator permission to manage a subset of domain accounts, you either added him to the Account Operators or Domain Admins group. This gave him or her administrative control not just over the subset but over every account in your domain. The Account Operators group merely denied its members to change administrative accounts in the domain.

Windows 2000 and Windows Server 2003 have three administrator groups: Enterprise Admins, Domain Admins, and Administrators:

• The Enterprise Admins group is created in the first domain that is created in the forest. The Enterprise Admins group is added automatically to every Administrators group of the domain controllers in every domain that joins the forest. This means that, by default, a member of the Enterprise Admins can manage the configuration of a forest and also every domain controller in the forest. Table 10.16 lists some Windows administrative tasks that require enterprise administrator rights and permissions.

  Table 10.16: Administrator Tasks That Require Enterprise Administrator Permissions

  Task	Reason
  Create new domain in forest	Creates crossRef objects in CN=Partitions, CN=Configuration subtree.
  Manage Sites and Subnets	Creates and modifies objects in CN=Sites, CN=Configuration subtree.
  Install Enterprise Certification Authority	Creates CA object in CN=Public Key Services, CN=Services, CN= Configuration subtree.
  Install Certification Authority for a child domain	Creates objects in CN=Public Key Services, CN=Services CN= Configuration subtree.
  Create Admission Control Service (ACS) policies	Creates subnet objects in CN=Subnets, CN=Sites, CN=Configuration. Creates CN=ACS, CN=Subnets, CN=Sites, CN=Configuration and objects in this subtree.
  Install first Exchange server in forest	Extends schema configuration naming context. Creates objects in CN=DisplaySpecifiers, CN=Configuration subtree. Creates CN=MS Exchange, CN=Services, CN=Configuration and objects in this subtree.
  Authorize a DHCP server	Creates CN=DHCPRoot, CN=NetServices, CN=Services, CN= Configuration and objects in this subtree.
  Set up printer location tracking	Sets location attribute on subnet or site objects in CN=Sites, CN= Configuration subtree. Sets location attribute on computer object in any domain.
  Set up Simple Certificate Enrollment Protocol (SCEP)	Changes ACL on objects in CN=Public Key Services, CN=Services CN=Configuration subtree.

The Enterprise Admins group is not added to the Domain Admins group and the Administrators group on member servers and workstations. By default, it is also not possible for a member of the Enterprise Admins group to grant himself administrative rights on all servers and workstations in a forest simply by changing the group memberships of the Domain Admins groups. This is because:

• Domain Admins are global groups in their respective domain;

• Enterprise Admins is a universal group in the root domain;

• A universal group cannot be added to a global group;

• The group-type of the Domain Admins group cannot be changed;

• A user from one domain cannot be added to a global group of another domain.

• Members of the Enterprise admins group have however the power to create other accounts (in each domain of the forest) which they can then add to the respective domain admins group. They can also use the restricted groups GPO settings to enforce the addition of the Enterprise Admins group to all local Administrators groups.

• The same rules as in NT4 apply to the Domain Admins and the Administrators group on member servers and workstations.

Both Windows 2000 and Windows Sever 2003 include major enhancements on the level of granular administration. In both OSs it is also possible to grant an administrator the permission to manage only a subset of the domain accounts. We will come back to this in Section 10.7.

AdminSDHolder and permissions on administrator accounts

To protect against unauthorized modification of the permissions set on accounts that are members of one of the built-in Windows administrator groups, Microsoft provides a mechanism that automatically resets the permissions on these accounts at regular intervals.

In Windows 2000 this feature applies to members of the Enterprise Admins, Schema Admins, Domain Admins, and Administrators groups. In Windows Server 2003^[4] it also applies to members of the Account Opera- tors, Server Operators, Print Operators, Backup Operators, and Cert Publishers groups.

This mechanism is based on a special AD container object called AdminSDHolder (Administrator Security Descriptor Holder object). Every hour the holder of the PDC Emulator master of operations (FSMO) role compares the permissions on the administrator accounts against the permissions on the CN=AdminSDHolder, CN=System, DC=<DomainName>,DC=<Domain- Extension> container. If the permissions are different, the security descriptor on the administrator object is changed to reflect the permissions on the AdminSDHolder container. In order for this process to work, AdminSDHolder also automatically disables permission inheritance on the AD administrator objects.

To change the permissions the PDC emulator applies to the administrator accounts, you must change the permissions on the AdminSDHolder container. Because AdminSDHolder is a container object, not all permissions applicable to a user account object can be set from the Windows GUI. For example, you cannot set the change password permission from the GUI. To do so, you can use the dsacls command-line utility as shown in the following example:

dsacls cn=adminsdholder,cn=system,dc=<domainname> /G “Everyone:CA;Change Password”

10.5.2 Group usage guidelines

Windows 2000 and Windows Server 2003 administrators are facing the same authorization administration problem as they did in NT4: They must give a universe of users access to a universe of resources. It is obvious that groups can make the life of administrators much easier. What are some of the basic rules an administrator should use when dealing with groups for authorization? Here is a starting point (illustrated in Figure 10.31):

Figure 10.31: Group usage guidelines.

• Use global groups to group users, use local groups (SAM local or domain local) to set the ACLs on resources, and put global groups into local groups to apply authorization settings.

• Use universal groups to give users access to resources that are located in more than a single domain. This means that you should put global groups into universal groups, put the universal groups into local groups, and then use these local groups to set the resources’ ACLs.

• Use universal groups when the group’s membership is close to static. Universal groups cause more network traffic when their membership changes frequently, than this is the case with domain local or global groups. The reason for this was shown in Table 10.6: The member- ship of a universal group is stored in the Global Catalog (GC) that is replicated forest-wide. Specific applications may demand more usage of universal groups than would make sense from a pure AD replication perspective. For example, you should always use universal groups as distribution lists for Exchange 2000 and later. This is because of the way Exchange resolves distribution list (DL) memberships. An Exchange server talks to a GC server to resolve a DL’s membership. If a DL contains a global group from another domain, then the global group will always be emtpy from an Exchange perspective. Remember that global group memberships are only available on the DCs of the global group’s definition domain.

User rights can be split into two categories: logon rights and user privileges. Logon rights control who can log on to a computer system and how he or she can do the logon. User privileges are used to control access to system resources and system-related operations.

^[4]The same is true on Windows 2000 if you have installed the hotfix that is mentioned .in Microsoft KB article Q327825 or you have installed Windows 2000 Service Pack 4 (SP4).