10.4 Windows Server 2003 authorization changes

In this section we discuss the Windows Server 2003 Authorization changes. We cover the effective permissions tab, the changes to the default AD object security descriptor, and the notion of quotas for AD objects.

10.4.1 More restrictive authorization settings

A direct consequence of the Microsoft security push is that Windows Server 2003 includes much more restrictive default authorization settings. Here are some examples:

• The NTFS root directory permissions have been tightened such that nonadministrators cannot write into the root directory nor can they modify files created by other users off of the root. In Windows 2000 Everyone had Full Control permission. The permissions in Windows Server 2003 are:

  • Administrator, System Account, Creator Owner: Full Control

  • Everyone: Read/Execute

  • Users:

    Read/Execute

    Create Folders/Append Data (this and subfolders)

    Create Files/Write Data (subfolders)

• More restrictive default share permissions: Everyone has now read- only permission. In Windows 2000 Everyone had Full Control permission. This means that by default even administrators only have read access to newly created shares.

• More restrictive permissions on critical console applications, such as cmd.exe. Cmd.exe now has the following default ACL:

  • Administrators: Full Control

  • System: Full Control

  • Interactive: Read and Execute

  • Services: Read and Execute

• The Anonymous account is no longer a member of the Everyone group. As a result, Everyone now only contains Authenticated users and Guests.

• Tightened security on Windows event logs

  • For the application and custom logs:

    Interactive users can read and write to it locally. Administrators can access it remotely.

  • For the system log:

    Interactive users can read it locally.

    Localsystem, localservice, and networkservice can write to it locally.

    Only administrators can read it remotely.

Also, the default security settings on the event logs can be customized in Windows Server 2003 using the registry keys next. The permissions in these registry keys are defined in the SDDL format (explained shortly):

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

• HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD

10.4.2 Effective Permissions

The advanced view of the Windows Server 2003 ACL Editor contains a new tab called Effective Permissions (illustrated in Figure 10.25). This tab allows a member of the Domain Admins group to let the system calculate the effective permissions that will be applicable for a particular user account or group when accessing an object. The effective permissions logic takes both the explicit and inherited permissions into account. It also incorporates the group memberships—with the exception of the well-known group member- ships—of the account (or group) in its effective permission calculations.

Figure 10.25: Effective permissions tab.

10.4.3 Default AD security descriptor changes

Windows Server 2003 includes some interesting changes related to the management of the default security descriptor for AD objects. For every AD object class (user, group, and so forth) Microsoft has defined a default security descriptor that describes the default permissions that are set when an AD object instance of a particular object class is created. Windows Server 2003 includes changes to the way you define the content of this security descriptor and the way that you can apply and reapply a particular object instance.

The default security descriptor can be set from the properties of an AD object class. The easiest way to do this is by using the Active Directory Schema MMC snap-in. Before you can use this snap-in you must register the schmmgmt.dll. To do so, type the following at the command line:

Regsvr32 schmmgmt.dll 

To set, for example, the default security descriptor for the user object class, open the Active Directory Schema MMC snap-in, locate the user object in the classes container, then open up the class properties: To change the default security descriptor, go to the default security tab (as illustrated in Figure 10.26). Before, in Windows 2000, this tab was simply named Security—which was a bit confusing.

Figure 10.26: Modifying the default AD Security descriptor.

You can also retrieve the content of the default security descriptor attribute of an AD object class using other tools: You can, for example, use ldp.exe or the AdsiEdit MMC snap-in. In that case look for the defaultSecurityDescriptor attribute of the AD object class. In both cases you will have to decipher the content of the attribute. Both tools display the content of the attribute in a Security Descriptor Definition Language (SDDL) format (see the sidebar on SDDL). SDDL is the native format used to store security descriptor information in the AD. Following is another sidebar on how to use ldp.exe to retrieve the defaultSecurity- Descriptor attribute.

To retrieve all default security descriptors stored in the AD schema, you can also use the following ldifde command:

Ldifde – f ADdefaults.txt –d cn=schema,cn=configuration,dc=<domainname> -r (objectCategory=classSchema) –l defaultsecuritydescriptor 

To reset an object instance’s security descriptor to the content of the default security descriptor of the object class, Microsoft added a new pushbutton in the advanced view of the ACL editor. This pushbutton is called Default and is illustrated in Figures 10.7, 10.14, and 10.18. Resetting the security settings of an object to the defaults will only replace the explicit permissions that are set directly on the object. The inherited permissions will stay as they are.

10.4.4 AD link value replication and group membership updates

An important deficiency of the way that groups are implemented in Windows 2000 AD is that a group’s membership attribute is completely replicated between DCs every time a group membership change occurs. A change can be as small as adding or removing a single user to/from the group. This is because group membership is implemented as a multivalue AD attribute and multivalue attributes are replicated as a single data blob.

The key problem with this implementation is that when administrators are updating group membership simultaneously on different DCs, during replication of these updates one of the administrator’s changes will be over- written by the other administrator’s changes. In Windows 2000 AD the last writer wins and the first writer’s changes are lost.

Introducing the Security Descriptor Definition Language (SDDL)

The Security Descriptor Definition Language is a text format defined by Microsoft for storing and transporting information in a security descriptor. The SDDL syntax is explained in great detail at the following MSDN URL: http://msdn.microsoft.com/library/en-us/security/ security/security_descriptor_string_format.asp.

An SDDL string can contain four tokens to indicate each of the four main components of a security descriptor: owner (O:), primary group (G:), DACL (D:), and SACL (S:). Next are an SDDL string example and its meaning.

O:BA G:SY D: (D;;0xf0007;;;BG) (A;;0x3;;;SU)

O:BA	Object owner is the built-in administrator (BA)
G:SY Primary group is the system (SY)	Primary group is the system (SY)
D: Start of the DACL portion	Start of the DACL portion
(D;;0xf0007;;;BG) Deny built-in guests (BG) all access	Deny built-in guests (BG) all access
(A;;0x3;;;SU) Allow service accounts read and write permission	Allow service accounts read and write permission

Windows Server 2003 AD replication introduces a new feature known as Link Value Replication (LVR) that resolves the above problem. Thanks to LVR, individual values of a multivalue attribute can be replicated separately between AD instances. Besides reducing AD replication traffic, network bandwidth usage, processor, and memory usage, LVR also helps AD get rid of the group membership limit (approximately 5,000) that exists in Windows 2000.

LVR is only available if the Windows Server 2003 forest is in the Windows 2003 interim or native Windows 2003 functionality level (meaning that the forest does not include Windows 2000 DCs).

10.4.5 Quotas for AD objects

AD object quotas determine the number of objects that can be owned in a given AD naming context or partition by a particular security principal. Quotas can help prevent denial of service (DOS) attacks on AD domain controllers. Without them (which is the case for Windows 2000), a security principal could, for example, create AD objects until a domain controller runs out of storage space.

AD object quotas are specified and administered for each individual AD naming context and partition. You cannot define them for the schema naming context. You can define a default quota for every AD naming context and partition. If you do not explicitly set a default quota on a partition, the default quota of the partition is unlimited.

Using Ldp.exe to Retrieve the defaultSecurityDescriptor AD Attribute You can start Ldp^* by typing ldp at the command line or in the Run… menu option. Then complete the following steps:

• From the Connection menu option, select Connect... Enter the name of the AD server in the Connect dialog box.

• From the Connection menu option, select Bind… Enter a set of valid credentials in the bind dialog box.

• From the View menu option, select Tree. Enter the following base DN to retrieve, for example, the defaultSecurityDescriptor attribute of the user object class:

  cn=user,cn=schema,cn=configuration,DC=<domainname>,DC=<domainextension> 

• Locate the content of the defaultSecurityDescriptor attribute in the right pane (as illustrated in Figure 10.27).

  
  Figure 10.27: Using ldp.exe.

Tombstone objects owned by a security principal are also counted as part of the AD object quota consumption of the principal. For each naming context and partition, you can specify a tombstone quota factor that determines the weight that is given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given naming context or partition is set to 25, then a tombstone object in the partition is counted as0.25 of a normal AD object. The default tombstone quota factor for each partition is set to 100. This means that, by default, normal and tombstone objects are weighted equally.

You can assign quotas to every security principal: This includes users, computers, groups, and iNetOrgPerson objects. When a security principal is covered by multiple quotas, the effective quota is the maximum of the quotas assigned to the security principal. A user could, for example, be assigned an individual quota and also belong to a security group that has quotas assigned to it. Members of the Domain and Enterprise Administrator groups are exempt from quotas.

AD object quotas are stored in the NTDS Quotas container of the AD naming context or partition as objects of the msDS-QuotaControl class.

Only domain controllers running Windows Server 2003 can enforce quotas. Quotas are enforced only on originating directory operations; they are not enforced on replicated operations. To effectively use AD object quotas in an AD domain directory partition, all domain controllers in that domain must be running Windows Server 2003. To use AD object quotas in an AD configuration partition, all domain controllers in the forest must be running Windows Server 2003. In other words, all domains and the forest should be at Windows Server 2003 functionality level 2. The availability of the quota feature itself is not related to any specific functionality level— it is available right away on any Windows Server 2003 domain controller. However, if there are still Windows 2000 domain controllers in a domain where quotas are enforced, then users could still connect to one of these domain controllers and work around the quota restrictions.

Windows 2000 includes a very limited version of the AD quota system that is coming with Windows Server 2003: You can restrict how many computer accounts can be created by a particular user account. To do so, use the ms-DS-MachineAccountQuota attribute of the AD domain object. The restriction does not apply to members of the Domain Admins and Account Operators groups. The ms-DS-MachineAccountQuota attribute is still supported in Windows Server 2003 (default value is 10).

To disable the addition of computer accounts, you can set this attribute to 0. A similar effect can be obtained by taking away the “Add workstations to domain” user right from the Authenticated Users group. In both Windows 2000 and Windows Server 2003, this right is given by default to the Authenticated Users group.

Setting and Testing AD Object Quotas To set an AD object quota of 10 for user Joe in the Accounting domain naming context, type the following dsadd command:

Dsadd quota -part DC=Accounting,DC=COM –acct Accounting\Joe –qlimit 10 -desc "Quota for Joe"

If user Joe tries to create more than 10 AD objects in the Accounting domain, an error similar to the one shown in Figure 10.28 will be generated.

Figure 10.28: AD object quota error.

To modify the tombstone quota factor for the Accounting domain naming context, use the following dsmod command:

Dsmod partition DC=Accounting,DC=COM -qtmbstnwt 25

To modify the default object quota setting to 0 for the Accounting domain naming context, use the following dsmod command:

Dsmod partition DC=Accounting,DC=COM -qdefault 0