The ACL model in Active Directory (AD) is flexible and granular. However, there's one restriction that Windows 2000 AD ACLs can't enforce: limiting the number of objects created in a partition. You can, of course, restrict who can create objects in a container, but after you give a user the ability to create objects (e.g., by using the Create All Child Objects right), that user can create as many objects as he or she wants. A malicious user who has the rights to create objects in a domain could fill up a domain controller's (DC's) hard disk simply by creating a lot of objects.
AD Quotas
Windows Server 2003 has a new AD quotas feature that lets you monitor and limit the number of objects a security principal (user, group, or computer) can create in a partition. This feature is similar to the built-in quota that Win2K and later versions assign to authenticated users for creating computer objects except that the new Windows 2003 quotas apply to all object types. For example, the new computer account quota limits users to creating no more than 10 computer objects (i.e., accounts) in a domain.
Quota objects are stored in the NTDS Quotas container in all Windows 2003-based partitions (including application partitions), except the Schema partition. Quotas can't be associated with the Schema partition because adding to the schema is a highly restricted operation that only members of the Schema Admins group can do. By default, tools such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in hide the NTDS Quotas container from view, but you can see the container by selecting View, Advanced Features from the snap-in's menu. The NTDS Quotas container has an object class of msDS-QuotaContainer that has several attributes that define default quota behavior. Table 1 lists some of the important attributes of msDS-QuotaContainer objects. Quota objects have an object class of msDS-QuotaControl. Table 2 lists the most interesting quota object attributes.
Adding Quotas
Unfortunately, you can't use the Active Directory Users and Computers snap-in or any of the other AD MMC snap-ins to create quotas. The only tools Microsoft provides for creating and managing quotas are the Directory Service (DS) utilities, including Dsadd, Dsmod, and Dsquery. To use Dsadd to create a quota for a specific partition, you need to specify values for the attributes that Table 2 lists.
Here's the generic command for creating a quota. Note that the last line (in brackets) is optional.
dsadd quota -part <PartitionDN> -qlimit <QuotaLimit> -acct <PrincipalName> \[-rdn <QuotaName>\]
The following command creates a quota that lets user cn=rallen create only five objects in the dc=rallencorp,dc=com partition.
dsadd quota -part dc=rallencorp,dc=com -qlimit 5 -acct cn=rallen,cn=users, dc=rallencorp,dc=com \[-rdn rallen_quota\]
The Tombstone Factor
Tombstone objects add an interesting twist to quotas. When a security principal (i.e., a user, group, or computer) deletes an object, Windows creates a tombstone object for a designated period of time (60 days by default) before purging the tombstone from the system. These tombstone objects count toward the security principal's quota.
By default, each tombstone object counts as one object. Thus, if a user creates an object and deletes another object, those objects would count as two objects toward any quotas that apply to the user. If a user creates an object and later deletes the same object, the entire process would count as only one object against the user's quota. When AD removes the tombstone object at the end of the designated time period, AD decrements one object from the user's quota.
You can change the msDS-QuotaContainer object's msDS-TombstoneQuotaFactor attribute to a value other than 100 percent to adjust how much each tombstone object counts against a security principal's quota usage. If you set the attribute to 50, a user with a quota limit of 10 could delete 20 objects (i.e., create 20 tombstone objects). If you don't care how many objects your users delete, you can set the tombstone quota factor to 0.
Setting Default Quotas
Because you can assign quotas to the different types of security principals, multiple quotas might apply to an individual principal. In such a case, the quota with the highest limit will be in force for the principal.
You can create a default quota for a partition that applies to all the security principals except for the members of the Enterprise Admins and Domain Admins groups and principals for which you've configured a quota. Even if you configure a default quota for all users, administrators won't have any restrictions and principals for which you've configured a quota will use that quota rather than the default quota.
The easiest way to apply a default quota is to modify the msDS-DefaultQuota attribute on the NTDS Quotas container for the target partition. You need to be careful when setting the default quota because it applies to every nonadministrator security principal for which you haven't set an individual quota. If you set the default quota to 0, for example, computers wouldn't be able to dynamically update their DNS records in an AD-integrated zone because that process creates an object. This situation might not apply to your environment, but the point is that you need to consider the effects of a default quota and test it thoroughly before implementing it.
Finding a User's Quota
If you implement quotas, users will undoubtedly want to be able to find how much of their quota they've used. You can determine a user's quota usage in several ways. One method is to use the Dsget User command:
dsget user "<UserDN>" -part <PartitionDN> -qlimit -qused
This command displays the effective quota limit and how much of his or her quota a particular user has used. For example, the following command returns the quota usage for the cn=rallen user in the dc=rallencorp,dc=com partition:
dsget user "cn=rallen, cn=users,dc=rallencorp,dc=com" -part "dc=rallencorp,dc=com" -qlimit -qused
You can use similar parameters with the Dsget Computer and Dsget Group commands to find the quota usage for those types of objects.
Users can also determine their quota usage by querying the msDS-QuotaUsed and msDS-QuotaEffective attributes on the NTDS Quotas container for a partition. These two attributes are constructed, which means the attributes are dynamically calculated based on the user who's accessing them. The msDS-QuotaUsed attribute returns how much of the quota the user has used, and the msDS-QuotaEffective attribute contains the effective quota limit based on all applied quotas.
If you want to know which users in a partition are creating the most objects, you can view the msDS-TopQuotaUsage attribute on the partition's NTDS Quotas container, which returns information about the users with the top quota usage. Each value of this multivalued attribute contains blocks of data formatted in XML-like language. Each block includes the SID of the security principal (<ownerSID>), the total number of objects the principal has created (<quotaUsed>), the number of tombstone objects (<tombstonedCount>), and the number of active objects (<liveCount>). Figure 1 shows an example of the information the attribute can contain.
As you can see, the account name of the security principal isn't identified in the XML code. The code returns only the SID of the account. If you want to translate the SID to a user or group name, you can use the SidToName utility, which you can download from http://www.joeware.net/win32/index.html.
Implementing Quotas
Quotas are a new Windows 2003 AD feature that let you limit the number of objects users create in a partition. You can set default quota limits for all security principals in a domain to prevent malicious users from filling the hard disks on your DCs. Be sure to think through and thoroughly test any quotas in a test domain before you put them into production. Currently, you must use the DS command-line utilities to manage quotas. Perhaps in the near future, Microsoft will simplify quota management by integrating it into the AD MMC snap-ins.
