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.
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
Create Folders/Append Data (this and
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
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
The advanced view of the Windows Server 2003 ACL Editor contains a new tab called Effective Permissions (
Figure 10.25: Effective permissions tab.
Windows Server 2003 includes some interesting changes
The default security descriptor can be set from the properties of an AD object class. The
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
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 – 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.
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
The key problem with this implementation is that when administrators are updating group membership
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
indicateeach of the four main componentsof 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)
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).
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
nameof 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:
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.
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
triesto 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