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

Windows 2000 introduced quite a few fundamental authorization changes. Because these are so important, we will also discuss them in the context of this book on Windows Server 2003 security. Most of the authorization changes applicable to Windows 2000 are still valid for Windows Server 2003. If this is not the case it will be explicitly mentionned.

Microsoft included the following major authorization changes in Windows 2000:

• Inclusion of a new ACL editor

• Fine-grain control over inheritance

• Support for object-type ACEs

• Support for property-based and property set–based ACEs

• Support for extended rights

• New ACL evaluation rules

In the following, objects can refer to any securable object. These can be file system, share, printer, registry, Active Directory (AD), or service objects. As mentioned before, a securable object can also be a less tangible object, such as a process or a Windows station.

Some securable objects can contain other securable objects; they are called container objects. A container object can be a file system container (a folder), a registry container (a key), a printer container (a printer contains documents), or an Active Directory container (an Organizational Unit).

Table 10.3 shows a subset of the securable objects available in Windows 2000 and Windows Server 2003 and which new authorization feature is or can be applied to their ACLs. This table does not list all Windows objects on which authorization settings can be set. For example, service and windows station objects are not listed.

Some of the new features (the ones marked with (*) in Table 10.3) are part of a new ACL structure version (version 4). In Windows 2000 and Windows Server 2003, this new ACL structure has been implemented only for AD objects. The main change in version 4 ACLs is the support for object-type ACEs, which enable property-based ACEs, extended rights, and property sets. The principal reason why Microsoft incorporated this new ACL version change was to enable the definition of authorization data on AD objects in a more granular way. These ACL changes, for example, enable fine-grain administrative delegation on AD objects.

10.3.1 New ACL editor

To enable a proper display of the ACE changes mentioned earlier, Microsoft provided a new ACL editor, which was shipped for the first time with NT4 SP4. In NT4 you can install it as part of the Security Configuration Editor (SCE) installation.

The most important characteristic of this ACL editor is its object independency: The same editor is used to set authorization settings on different types of securable objects. The new ACL editor also supports deny ACEs and the new ACL evaluation rules.

Although NT4 supported deny ACEs, the ACL editor could not display them properly. In NT4 you set deny ACEs programmatically. An error message was displayed when opening an ACL that was holding a deny ACE using the NT4 ACL editor. NT4 can display deny ACEs properly in the ACL editor on systems that have the Security Configuration Tool Set (SCTS) installed.

The new ACL editor also has a brand-new Graphical User Interface (GUI), consisting of a basic view and an advanced view. Figure 10.5 shows the basic view of the new ACL editor. Pushing the Advanced… button brings you to the advanced view. The advanced view is used to set more granular access permissions, control inheritance, change ownership, see the effective permissions for a particular account (a new feature in Windows Server 2003), and set auditing settings.

Figure 10.5: Windows 2000 ACL editor GUI.

The permissions displayed in the basic view of the ACL editor are, in fact, groups of permissions. To see what permissions are contained in a group of permissions, go to the advanced view of the ACL editor. The use of groups of permissions in the basic view can lead to situations such as the one illustrated in Figure 10.5. In this example the administrator denied access to user Joe to read the attributes of the book file system folder. Because read attributes are an individual permission rather than a group of permissions, they will not be displayed in the ACL editor’s basic view.

10.3.2 Fine-grain control over inheritance

ACL inheritance is a mechanism that lets container objects pass access control information to their child objects. A container’s child objects can be noncontainer objects but also other container objects. From an administrator point of view, ACL inheritance simplifies authorization management. An administrator can set the ACL on a parent object and, if inheritance is enabled, he or she should not bother about setting ACLs on each individual child object. From a software logic point of view, ACL inheritance makes authorization evaluation much more complex. During the authorization process the SRM needs to consider multiple ACLs: not just an object’s proper ACLs (also known as explicit ACLs), but also all the inherited ACLs. Inherited ACLs can come from an object’s immediate parent, but also from parent objects that are higher up in the object hierarchy.

Comparing NT4 and Windows 2000 inheritance

Table 10.4 compares ACL inheritance in NT4 and Windows 2000. NT4 clearly offers no or very limited means to control ACL inheritance.

As in NT4 and Windows 2000, Windows Server 2003 uses static ACL inheritance. Static inheritance means that an object inherits permissions from its parent object when the object is created and when the permissions on the parent object are changed. In NT4 static inheritance happened following an explicit administrator action: he or she had to select “Replace Permissions” on Subdirectories and Replace Permissions on Existing Files” in the NT4 Folder Permissions dialog box to apply permissions to child objects when they were changed at the parent object. Windows 2000 and Windows Server 2003 will automatically update the child’s ACLs when an administrator changes a parent object’s ACL’s change and clicks apply in the ACL editor.

Static inheritance obviously takes some processor power while the permissions are copied to all child objects, but the impact of this is almost negligible when compared to the impact of dynamic inheritance. With dynamic inheritance (which is, for example, used in NDS), each opening of an object requires checking not only the explicit permissions on the object itself but also the permissions of all its parent objects.

Another important difference is that Windows 2000 does not overwrite the child’s proper explicit ACEs with the inherited parent ACEs. Windows 2000 simply adds inherited ACEs to the child’s ACLs and tags them with a special inherited flag. You can observe the presence of this flag in the basic and advanced view of the ACL editor (as illustrated in Figures 10.6 and10.7 for the advanced view).

Figure 10.6: Inheritance in the ACL editor’s advanced view (Windows 2000).

To stress the fact that inherited ACLs cannot be edited in the ACL editor of a child object, Microsoft grays out the keys in the type column. Also, Microsoft added an explanatory text in the dialog box telling the user “this permission is inherited” and “you can edit the permission only at the parent object.” The latter two features are only available in Windows 2000 (as shown in Figure 10.6). In Windows Server 2003, Microsoft got rid of the keys and the explanatory text and instead added a new “Inherited From” column showing from which parent object a child object inherits a particular permission. The new interface is illustrated in Figure 10.7. In the ACL editor’s basic view inherited permissions are associated to a grey checkbox.

Figure 10.7: Inheritance in the ACL editor’s advanced view (Windows Server 2003).

In NT4 inherited permissions could be edited on the child object, because both the child object’s proper ACLs and the inherited ACLs were merged, making the inherited ACLs unrecognizable.

An interesting detail from both an ACL inheritance and an AD replication point of view is the way ACL changes on AD container objects are replicated in the Active Directory. Because AD is a multimaster database, ACL changes made on one instance of the AD also need to be replicated to every other instance of the AD database. To limit the bandwidth impact, Microsoft only replicates the explicit permissions—and not the inherited permissions—between AD instances. This feature, combined with the static inheritance, means that when the permissions are evaluated on an AD child object, it should always have the latest ACL information, unless some permission change on another AD instance has not replicated to the child object’s AD instance.

An important change in the way inherited ACEs are stored in AD is the concept of single-instance storage for ACEs which Microsoft introduces in Windows Server 2003. This feature significantly reduces the space that is required in the AD database for ACE storage. The internal HP AD, for example, shrank from 12 GB down to 7 GB because of this feature. Single-instance storage for ACEs basically means that child objects just contain a pointer to the inherited ACEs that are stored in the parent object’s explicit ACEs—inherited ACEs are not copied to every single child object.

Controlling inheritance

By default, Windows 2000 ACL inheritance makes permissions automatically flow down from container objects to all child objects. This default behavior can be modified by blocking ACL inheritance on a child object or by enforcing inheritance^[1] or limiting the inheritance scope on a container object. Thanks to these features, both entire subtrees and leaf objects can be excluded from ACL inheritance in an object hierarchy (as illustrated in Figure 10.8). What these features really mean is that ACEs that are marked as inheritable are or are not written to the ACLs of all or specific child containers or objects.

Figure 10.8: Controlling inheritance using blocking.

You may want to use inheritance control to apply special authorization rules to the file system folder or AD organizational unit of your organization’s very special departments. In the example of Figure 10.8, the inheritance of the permissions that are explicitly set on the AD Organizational Unit A is blocked on the level of the E OU. As a consequence, inheritance is also blocked on all underlying OUs (F and G). On OU E an explicit permission is set that gives only read-write access to the research department admins.

To block inheritance on the child object level, uncheck the “Allow inheritable permissions from the parent to propagate to this object and all child objects” (available only in the advanced view of the ACL editor^[2]) (as illustrated in Figure 10.7 for AD and in Figure 10.9 for the file system). If you uncheck this box, Windows will bring up a dialog box (illustrated in Figure10.10) that gives you the option to “Copy the previously inherited permissions to the object,” to “Remove the inherited permissions and keep only the permissions explicitly specified on this object,” or to cancel the action. The first choice removes the inherited flag from inherited ACEs and makes them explicit ACEs. The second choice effectively removes inherited ACEs.

Figure 10.9: Setting inheritance in the ACL editor (file system).

Figure 10.10: ACL editor warning message.

When you recheck the “Allow inheritable permissions from the parent to propagate to this object and all child objects” checkbox (after you first unchecked it and removed the inherited permissions), you can reapply all inherited permissions. Before doing so in AD, the security system will warn you about the possible directory size and performance impact of reapplying all the inherited permissions (illustrated in Figure 10.11).

Figure 10.11: ACL editor warning message (AD only).

To reset the inheritance-blocking settings mentioned previously, the administrator of a child’s parent container can enforce the writing of the inheritable ACEs to the child object’s ACEs. This is done using the “Replace permission entries on all child objects with entries shown here that apply to child objects” checkbox (as illustrated in Figure 10.9). “This setting will only provoke the system to overwrite existing ACLs and re-enable inheritance for once, which is when the administrator presses OK. It will not ensure that inheritance blocking won’t occur again later on when the administrator of the child object decides to do so. This option is available for file system and registry permission inheritance. It is not available for AD permission inheritance.

Another way to control inheritance on the parent container level is by using ACL inheritance scoping, which is based on special inheritance flags that are added to a parent object’s ACEs. The flags are listed in the top row of Table 10.5. The ones listed in Table 10.5 apply to file system ACEs only.

The flags can be set from the advanced view of the ACL editor, using the View/Edit… push button (as illustrated in Figure 10.12). In the Apply onto listbox, different scopes can be selected: “This folder only,” “files only,” and so forth. Table 10.5 shows the inheritance flags corresponding to the setting chosen from the Apply onto… listbox. A noncontainer object obviously does not have these settings. In this case the Apply onto… box just shows “this object only.”

Figure 10.12: Setting inheritance in the ACL editor (file system).

A flag that is not listed in Table 10.5 is the nonpropagate flag. This flag cannot be set using the Apply onto… drop-down box but by using the “Apply these permissions to objects and/or containers within this container only” checkbox (this checkbox is available from the advanced view only using the View/Edit… pushbutton)—as illustrated in Figure 10.12. The nonpropagate flag and the corresponding checkbox control the recursion depth of permission inheritance. If you check the checkbox, the parent’s permissions will only be propagated one level down the hierarchy (only to child objects, not to grandchild objects). If you uncheck it, permission inheritance will be applied recursively all the way down the object tree.

AD permissions have a much richer set of inheritance scoping flags. In short, the AD permission inheritance scopes can be classified as follows:

• This object only: Permissions will only be set explicitly on the selected object and will not be inherited by child objects.

• This object and all child objects: Permissions will be set explicitly on the selected object and will be inherited by child objects.

• Child objects only: Permissions will not be set on the selected object but will only be inherited by child objects.

• Specific object type: Permissions will only be inherited by child objects of the specified type. The object type can be any object available in the Active Directory, including object types created by extending the AD schema. Inheritance based on the object type will be covered in more detail in the section on object type–based ACEs.

10.3.3 Object type–based ACEs

Object type–based ACEs are a new feature of version 4 ACLs. Microsoft implemented them in Windows 2000 and Windows Server 2003 for AD objects. Object type–based ACEs include two new ACE fields: an object type field and an inherited object type field. Using these two fields, an administrator can create fine-grain authorization settings for AD objects:

• He or she can define to which object types an ACE applies. The object type field of an ACE refers to an object GUID. The GUID can be linked to an object type, an object property, a set of object properties, or an extended right.

• He or she can define which object types will inherit the authorization information defined in an ACE. The ACE field used for this feature is the inherited object-type field. Like the object-type field, it contains a GUID.

The following sections explain how you can set authorization based on the object type, a property, a property set, or an extended right. We will also come back to the effect of object type–based ACEs on AD object ACL inheritance.

Setting authorization based on the object type

Object type–based ACEs can be used to set permissions based on the AD object type. Let’s illustrate this with an example. As mentioned earlier in this book, AD objects can be grouped in containers, called Organizational Units. Figure 10.13 shows how authorization could be set on the “Brussels” OU using object type–based ACEs:

• Jan cannot create user child objects in the Brussels OU.

• Wim cannot create computer child objects in the Brussels OU.

• Marc can create group child objects in the Brussels OU.

• Paul can create computer child objects in the Brussels OU.

  Figure 10.13: Object type–based ACEs.

Figure 10.14 shows how these object type–based ACEs are displayed in the ACL editor. You get this view from the Advanced View of the ACL editor. Notice that the ACEs are ordered in canonical order. The concept of canonical order will be explained below in Section 10.3.4. Figure 10.15 shows how one of the ACEs (the one that allows Marc to create group objects) is set in the advanced view.

Figure 10.14: Object type-based ACEs in the ACL editor—advanced view.

Figure 10.15: Object type-based ACEs in the ACL editor—advanced view, permission entry details.

Setting authorization based on a property or a property set

Object type–based ACEs can also be used to set authorization based on an AD object property or a set of object properties. Examples of user object properties are a user’s first name, Home Directory, City, and Manager’s name. An example of a property set is Personal Information: It includes a user’s Address, Telephone Number, and 39 other attributes. Table 10.6 provides an overview of the property sets available in Windows Server 2003 AD and the object classes to which they can be applied. Contrary to Windows 2000 in Windows Server 2003 the default property sets can be edited.

Modifying the AD Authorization Information Displayed in the ACL Editor Because the number of different object classes and properties that are available in the AD is relatively big, by default, the Advanced View of the ACL editor only displays a subset of the object classes and properties. To change the items displayed in the ACL editor, you can edit the dssec.dat file (illustrated in Figure 10.16) that is located in the %systemroot%\ System32 directory of every machine, where the Active Directory Users and Computers MMC snap-in is installed.

Figure 10.16: Dssec.dat content.

The dssec.dat file contains a bracketed entry for every object class. If an object class’s @ value is set to 7, the type is not displayed in the ACL editor; if it is set to 0, it is displayed. The same is true for the different object properties. If a property’s value is set to 7, it is not displayed, 6 means that only the read permission is included, 5 means that only the write permission is included, and 0 means that both the read and write permissions are included for the property. To reflect the changes made to dssec.dat close and restart the MMC AD User and Computers snap-in. Another solution is to simply edit the AD object permissions using the ADSIEdit tool which is installed with the Windows Support Tools. This tool bypasses the display restrictions set in the dssec.dat file and displays all object tyypes, attributes, and permissions.

How to create custom property sets for your organization is explained in the Windows platform SDK. For more information on how property sets are stored in AD, see the following sidebar on “How Property Sets are Defined.”

Figure 10.17 shows how authorization can be set on an AD user object Jan, based on its properties and the available property sets.

Figure 10.17: Property-based ACEs.

• Jan cannot change the name of his manager. (Note that in the ACL user Jan is referred to using the Self security identity.)

• Wim can change all properties of Jan’s user object.

• Jan can change his personal information.

• Marc can read all information contained in Jan’s Home Address property set.

  How AD Property Sets Are Defined Property sets allow attributes to be grouped for authorization purposes. They enable administrators, for example, to set read-write access on an AD object using a single ACE.

  Each property set is identified by a GUID. The GUID is stored in the rightsGUID of the property set’s ControlObjectAccess object in the Configuration naming context Extended-Rights container. All member attributes of the same property set have the same GUID stored in their attributeSecurityGUID property. This is illustrated in Figure 10.20 for the Telephone-Number attribute, which is part of the Personal Information property set.

Figure 10.18 shows how these property-based ACEs are displayed in the ACL editor. Figure 10.19 shows how one of the ACEs (the one that allows Jan to change his personal information) is set in the advanced view of the ACL editor.

Figure 10.18: Property-based ACEs in the ACL editor.

Figure 10.19: Property-based ACEs in the ACL editor.

Figure 10.20: Changing the attributeSecurityGUID property for the Telephone-Number attribute.

Setting authorization using extended rights

Extended rights are special AD object–related actions or operations that are not covered by any of the standard Windows access rights (read, write, execute, delete). Good examples are the mailbox-specific send as and receive as extended rights. Although they are not linked to object properties, extended rights are displayed together with the standard object permissions in the ACL editor (as Figure 10.21 shows).

Figure 10.21: Extended rights types.

Extended rights can be classified in three types:

1. Extended rights that are enforced by the AD. They grant or deny a read or write operation to an Active Directory property set (see Table 10.7).

   Table 10.7: New Windows Server 2003 Extended Rights

   Extended Right	Meaning
   Allowed-To-Authenticate	Used for cross-forest selective authentication (feature of forest trust).
   Create-Inbound-Forest-Trust	Allows the creation of inbound forest trust relationships.
   DS-Execute-Intentions-Script	Should be granted to the partitions container. Allows the Rendom.exe or prepare operation to be used in a domain rename.
   DS-Query-Self-Quota	Allows a user to query the user’s own AD quotas (quotas are explained later in this chapter).
   DS-Replication-Get-Changes-All	Allows the replication of secret domain data.
   DS-Replication-Monitor-Topology	Allows the reading of replication monitoring data, such as replication status and object metadata.
   Enable-Per-User-Reversibly-Encrypted-Password	Allows users to enable or disable the “reversible encrypted password” setting for user and computer objects.
   Generate-RSoP-Logging	The user who has this right on an OU/Domain will be able to generate logging mode RSoP data for the users/computers within the OU.
   Generate-RSoP-Planning	The user who has this right on an OU/Domain will be able to generate planning mode RSoP data for the users/computers within the OU.
   Migrate-SID-History	Enables a user to migrate the SID-History without administrator privileges.
   Reanimate-Tombstones	Allows for the restoration of deleted AD objects.
   Refresh-Group-Cache	Used for GC-less logon. No GC logon relies on caching group memberships and this control access right is used to permission administrators and operators with rights to cause an immediate refresh of the cache, contacting an available GC.
   SAM-Enumerate-Entire-Domain	Allows usage of NetAPI calls that read whole domain.
   Unexpire-Password	Allows a user to restore an expired password for a user object.
   Update-Password-Not-Required-Bit	Allows a user to enable or disable the “password not required” setting for user objects.

2. Extended rights that are enforced by applications such as Exchange or Outlook (see Table 10.7).

3. Extended rights that are enforced by the system. These are rights for specific operations that require validation before modification. They are also referred to as Validated Writes (see Table 10.8).

   Table 10.8: Windows Server 2003 Validated Writes

   Validated Write	Meaning
   Add/Remove self as member (Self-Membership)	Enables updating membership of a group in terms of adding or removing one’s own account.
   Validated write to DNS host name (Validated-DNS-Host-Name)	Enables setting of a DNS host name attribute that is compliant with the computer name and domain name.
   Validated write to service principal name (Validated-SPN)	Enables setting of the SPN attribute which is compliant to the DNS host name of the computer.

Figure 10.21 shows an example of each of the three extended right types:

1. The Read Personal Information extended right is enforced by the AD.

2. The Send As extended right is enforced by an application.

3. The Add/Remove self as member right is enforced by the system itself.

To get an overview of the extended rights, look at the Extended-rights container in the AD configuration naming context. As for property sets, an organization can create additional custom extended rights. Also as for property sets, the way to set these up is explained in the Windows platform SDK. Table 10.7 gives an overview of the new extended rights coming with Windows Server 2003. Table 10.8 gives an overview of the validated writes coming with Windows Server 2003 (which are also available in Windows 2000).

Object type–based ACEs and inheritance

An object type–based ACE also contains a special field that can be used to define which child objects will inherit the ACE. This feature can be controlled from the ACL editor GUI using the permission entry dialog box (see Figure 10.17). To set which object types will inherit the permission you set, select the object type from the Apply onto… drop-down box. Then check the “apply these permissions to objects and/or containers within this container only” property to limit permission inheritance to direct child objects only. Unchecking this property will apply the permissions to all container objects and all objects of that particular type all the way down the object tree.

10.3.4 ACL evaluation process

In Section 10.2 on the Windows authorization model, we introduced the entities that are involved in the authorization evaluation process: the subject (using an access token and an access mask), the object (having a security descriptor), and, of course, the Security Reference Monitor (SRM). In this section we look at how the SRM decides on letting a process access a resource or keeping a process from accessing a resource. We explain how the SRM generates the granted access mask, based on the access token, the access mask, the security descriptor, and the ACL Evaluation Rules.

The basic process

The basic ACL evaluation process can be summarized as follows:

• The SRM receives an access token and an access mask from some server process. Remember that the access mask tells the SRM what the process wants to do on behalf of a user.

• For every access right contained in the access mask, the SRM will then check the DACL of the object’s security descriptor. It will check every ACE for an allow or deny permission matching that particular access right and the user SID or one of the user’s group SIDs. Remember that user and group SIDs are contained in the access token.

• This ACL evaluation process will end when one of the following conditions occurs:

• The SRM finds a deny permission for one of the access rights that was requested in the access mask. The granted access mask will be empty and access will be denied.

• The SRM finds matching allow permissions for all the access rights that were requested in the access mask. The granted access mask will be complete and access will be granted.

• The SRM reaches the end of the object’s security descriptor and did not find a match for every requested access right. The granted access mask will be cleared and access will be denied. This is very important: If no matching entry is found for every single requested access right, access is denied.

Evaluation rules and order

All of the authorization changes listed in the previous sections forced Microsoft to review the Discretionary ACL evaluation rules and order. The new DACL evaluation order is illustrated in Figure 10.22. Microsoft calls the new evaluation order the canonical order.

This canonical evaluation order contains three fundamental rules:

1. Explicitly defined authorization settings always have precedence over inherited authorization settings. This is a direct consequence of the Windows discretionary access control model.

2. Parent object authorization settings defined at a lower level in the object hierarchy have precedence over parent object authorization settings defined at a higher level of the object hierarchy.

3. Deny permissions have precedence over allow permissions at the same level. If this was not the case, a user with a deny access right could still be allowed to access a resource based on, for example, an allow ACE for one of the user’s groups. In this case the evaluation order would be: Allow for the group/Deny for the user. Because ACL processing stops when all access rights in the access mask are granted, the evaluation process would not even get to the deny ACE for the user object. Allow permissions may still have precedence over allow permissions based on the first rule: an explicit allow permission always has precedence over an inherited deny permission.

   Figure 10.22: Canonical evaluation order.

Figures 10.23 and 10.24 give some ACL evaluation examples. In both examples a process impersonating a user Jan is requesting read and delete access to a resource. The user Jan is a member of two groups: consultants and AMTG:

• In the first example (Figure 10.23), access is denied based on a deny delete permission for the consultants group (this is an inherited ACE). Note that even though Jan was granted read access, the granted access mask is empty. The impersonating process requests both read and delete access.

  Figure 10.23: ACL evaluation example 1.

• In the second example (Figure 10.24), access is allowed based on an allow read permission for Jan (explicit permission) and an allow delete permission for AMTG (inherited permission). The granted access mask has both the read and delete access rights set.

  Figure 10.24: ACL evaluation example 2.

An interesting property of the Windows 2000 ACL editor is that it displays the ACLs in canonical order in the advanced view (as illustrated in Figures 10.7, 10.9, 10.14, and 10.18). But the Windows 2000 ACL editor’s support for canonical order also has its limits: it can only display ACLs that are in canonical order and fails if ACLs are set in a different order. This could be an explicit allow permission preceding an explicit deny permission, which is called a non-canonical order. This does not mean that you cannot set ACLs in a noncanonical order—it simply means when you want to do this, you cannot use the ACL editor and you will have to do it programmatically. When you try to edit noncanonical ACLs in the AD Users and Computers MMC snap-in, the ACL Editor returns the following error: “Windows can not edit the permissions on <object_name> because they have been written in a non-standard format by another application. To enable editing, you must use the application to restore the permissions to a standard format.”

Putting ACLs in noncanonical order can be interesting for certain applications. For example, in Exchange noncanonical order allows you to hide distribution list member objects from the global address list (GAL) for everyone (deny read members for everyone ACE), while still allowing Exchange servers to read and edit the objects (allow read-write members for Exchange Servers). In noncanonical order the allow ACE for Exchange Servers precedes the Deny ACE for everyone on objects to be hidden in the GAL.

In the ACL evaluation process, special care must be taken of empty and missing DACLs. A missing DACL is also known as a null DACL. An empty DACL does not grant access to anyone. A null DACL gives access to everyone. In the case of a null DACL, the SRM simply copies the requested access mask to the granted access mask.

10.3.5 SID History

SID History is an AD user account attribute^[3] that is used to facilitate the authorization process in Windows domain migration scenarios. It was introduced in Windows 2000 and is still used in Windows Server 2003. SID History helps in migration scenarios where a new domain infrastructure is created in parallel with the old domain infrastructure. In other words, there is a period of coexistence where the old and the new domains are both operational. In such scenarios it is typically required that newly created user accounts in the new infrastructure can still access resources in the old infrastructure. The key problem here is that the resources in the old infrastructure are secured using ACLs that refer to the old security identities (SIDs) of the user accounts defined in the old infrastructure.

To resolve this problem Microsoft’s provides an API—called the clone- principal API—that when a new user or group object is created in AD (e.g., during a migration), can be leveraged to automatically add the old objects’s SID to the SID history attribute of the new object. The content of the SID history attribute of the user’s proper user account and of the groups which the user is a member of are also added to the user’s access token. This means that when the user logs on to the new infrastructure using his or her new account, the security system will create an access token that not only refers to the new SID, but also to the old SID. That way the user will be able to access resources secured with the old SID that are hosted in the old infrastructure transparently.

The cloneprincipal API is used by Microsoft’s Active Directory Migration Tool (ADMT-currently version 2), as well as other third party migration tools on the market. ADMT is a freeware migration tool downloadable from the Microsoft Web site.

SID History is not available in a Windows 2000 mixed-mode domain. It is available in Windows 2000 native mode and all higher Windows Server 2003 domain functionality levels (Windows Server 2003 interim and Windows Server 2003).

Although SID History eases the migration process, it also represents some problems:

• The fact that a migrated user can use different security identifiers can be regarded as a security breach. Because there is no one-to-one map- ping between a user’s account and its security identifier, security auditing becomes a more difficult task.

• Another problem is token bloat. It is a direct result of augmenting the number of entries in access tokens. It may make you end up with decreasing network performance or access tokens that grow beyond the size of 8 Kb, which is the default access token limit. Token bloat can also occur if a user belongs to too many groups.

^[1]Enforcement of inherited permissions is not possible for AD permission inheritance.

^[2]This was not true in Windows 2000. In Windows 2000 this option was available in both the basic view and the advanced view of the ACL editor.

^[3]The exact name of the attribute is SidHistory.