10.5 Authorization intermediaries

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.

Table 10.9: Windows 2000/Windows Server 2003 Security Groups

	Usage Scope	Content Scope	Group Definition Storage*	Group Membership Storage
Universal groups	Global (anywhere in the forest or trusted domains or trusted forests)	Principals from any domain in the forest Universal groups Global groups from any domain in the forest	AD Domain NC Global Catalog	AD Domain NC Global Catalog
Global groups	Global (anywhere in the forest or trusted domains or trusted forests)	Principals from the same domain Global groups from the same domain	AD Domain NC Global Catalog	AD Domain NC
Domain local groups	Local domain	Principals from any domain in the forest Universal groups Global groups from any domain in the forest Domain Local groups from the same domain	AD Domain NC Global Catalog	AD Domain NC
Local groups	Local computer	Principals from any domain in the forest Universal groups Global groups from any domain in the forest	SAM	SAM

* 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.

Table 10.10: Effect of the Windows Domain Modes on Windows Group Features

All Domains Supporting NT4 DCs	Domains Including Only Windows 2000 or Windows Server 2003 DCs
Three group scopes: global, local and universal*	Four group scopes: global, domain local, local, and universal
Two group types: security and distribution	Two group types: security and distribution
Domain controllers share local groups	Domain computers share domain local groups
Custom local groups can be defined on any machine	Custom local groups can be defined on any machine with the exception of domain controllers
Groups of the same type cannot be nested	Groups of the same type can be nested
Group scope and type cannot be changed	Group scope and type can be changed

* 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.

Table 10.11: New Built-In Windows 2000 Groups

Built-In Group Name	Group Scope	Meaning
Pre-Windows 2000 Compatible Access	Domain Local	Members of this group have read access to most attributes on user and group AD objects.
Enterprise Admins	Universal	The Enterprise Admins group exists only in the root domain of an AD forest. The members of this group can make forest-wide changes and change the AD configuration-naming context.
Schema Admins	Universal	The Schema Admins group exists only in the root domain of an AD forest. The members of this group can change the AD schema-naming context
Group Policy Creator Owners	Global	Members of this group are authorized to create new Group Policy Objects in the AD.
Domain Controllers	Global	Includes all domain controllers of the domain.
Domain Computers	Global	Includes alll computers that are joined to the domain with the exception of domain controllers.
DnsAdmins	Domain Local	Members of this group can administer the Windows 2000 DNS service.
Replicator	Domain Local	Supports file replication in a domain.
Cert Publishers	Domain Local	Members of this group are permitted to publish certificates to the Active Directory.
RAS and IAS Servers	Domain Local	Servers in this group can access remote access properties of users.
DNSUpdateProxy	Global	DNS clients who are permitted to perform dynamic updates on behalf of some other clients (such as DHCP servers).

Table 10.12: New Built-In Windows Server 2003 Groups

Built-In Group Name	Group Scope	Meaning
HelpServicesGroup	Domain Local	Group for the Help and Support Center.
IIS_WPG	Domain Local	IIS Worker Process Group.
TelnetClients	Domain Local	Members of this group have access to Telnet Server on this system.
Windows Authorization Access Group	Domain Local	Members of this group have access to the computed token-GroupsGlobalAndUniversal attribute on User objects.
Terminal Server License Servers	Domain Local	Terminal Server License Servers.
Remote Desktop Users	Domain Local	Members in this group are granted the right to log on remotely.
Performance Monitor Users	Domain Local	Members of this group have remote access to monitor this computer.
Performance Log Users	Domain Local	Members of this group have remote access to schedule logging of performance counters on this computer.
Network Configuration	Domain Local	Members in this group can have some administrative privileges to manage configuration of networking features.
Incoming forest trust builders	Domain Local	Members of this group can create incoming, one-way trusts to the forest.

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.

Table 10.13: Well-Known Security Principal Groups: Windows Server 2003

Well-Known Security Principal Groups	Membership—Meaning
Digest Authentication	Digest is another authentication packet. This security principal allows specifying who can log on using digest and who cannot.
Network Service	For services not requiring local system, but network access.
NTLM Authentication	Allows setting special permissions for down-level clients authenticating using the less secure NTLM protocol. Whenever a user logs on to a DC using NTLM, this group/SID is added to his or her access token. Access to resources can thus be restricted by using this group in a deny ACE.
Other Organization	Used for forest trust selective authentication. Selective authentication allows distinguishing between users from your own forest and users that come in through a forest trust. See Chapter 3 for more information.
Remote Interactive Logon	Allows assigning permissions for users logged on via Terminal Services/ Remote Desktop.
SChannel Authentication	Allows setting special permissions for clients authenticating via a secure
This Organization	See Other Organization.
Well-Known-Security-ID-System	Local System account.

Table 10.14: Well-Known Security Principals: Windows 2000

Well-Known Security Principal Groups	Membership—Meaning
Everyone	Includes all authenticated users and guests. In Windows Server 2003 the anonymous account is not longer a member of the Everyone group
Anonymous Logon	Includes all users that logged on anonymously.
Authenticated Users	Includes all uses that authenticated to the operating system
Network	Includes all users logged on through a network connection.
Dialup	Includes all users logged on through a dial-up connection.
Batch	Includes all users logged on through a batch scheduler connection.
Interactive	Includes all users logged on interactively.
Service	Includes all principals that logged on as a service.
Enterprise Domain Controllers	Includes all domain controllers in a Windows 2000 forest
Terminal Server User	Includes all users that have logged on to a terminal services server.
System	Represents the local system.
Creator Owner	Placeholder used for inheritance: is replaced by the creator owner of the object that inherits the permission.
Creator Group	Placeholder used for inheritance: is replaced by the primary group of the creator owner of the object that inherits the permission.
Self	Placeholder—represents the object to whose ACLs Self is added.
Proxy	Reserved for future use
Restricted Code	Reserved for future use

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.

Table 10.15: Windows Administrator Groups

Group	Default Members on Workstations, Member Servers	Default Members on Domain Controllers
Enterprise Admins	N/A	Administrator of forest root domain
Domain Admins	N/A	Administrator of the domain*
Administrators	Administrator, Domain Admins†	Administrator, Domain Admins, Enterprise Admins
Users	Authenticated Users, Domain Users	Authenticated Users, Domain Users, Interactive
Power Users	Interactive Users	N/A
Account Operators	N/A	—
Server Operators	N/A	—
Backup Operators	N/A	—
Print Operators	N/A	—

* 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).