Active Directory Cookbook for windows server 2003- P49 potx

491 Recipe 15.13 Creating a Quota This recipe requires a Windows Server 2003 domain controller. 15.13.1 Problem You want to limit the number of objects a security principal can create in a partition by creating a quota. 15.13.2 Solution 15.13.2.1 Using a command-line interface > dsadd quota -part <PartitionDN> -qlimit <QuotaLimit> -acct <PrincipalName>[RETURN] [-rdn <QuotaName>] The following command creates a quota specification that allows the RALLENCORP\rallen user to create only 5 objects in the dc=rallencorp,dc=com partition: > dsadd quota -part dc=rallencorp,dc=com -qlimit 5 -acct RALLENCORP\rallen 15.13.3 Discussion Quotas are a new feature in Windows Server 2003 that allow an administrator to limit the number of objects that a user (or group of users) can create. This is similar in nature to the quota for creating computer objects found in Windows 2000 (see Recipe 8.9 for more details), except the quotas in Windows Server 2003 apply to the creation of all object types. There are three things that need to be set when creating a quota specification, including: Partition Currently, quotas can apply only to an entire partition. You cannot create a quota that pertains only to a subtree in a partition. You can create quotas for any partition, including application partitions, except for the schema-naming context. The reasoning behind this restriction is that the schema is a highly protected area of the directory and you shouldn't need to restrict how many objects get created there. Target security principal A quota can be defined for any type of security principal. The msDS-QuotaTrustee attribute on the quota object stores the target principal in the form of a SID. 492 Limit This determines how many objects the target security principal can create. The quota limit is a combination of the new objects that a user creates plus any tombstone objects that are created by that user. If a user creates an object and then deletes another object, that would count as 2 toward any quotas that apply to the user. This is because when an object is deleted, a tombstone object is created in its place, which counts as another object creation. If a user creates an object and later deletes the same object, this would count as only 1 object against their quota. After the tombstone object is removed from Active Directory (60 days by default), the user's quota would be decremented. By default, a tombstone object counts as 1 object, but that is configurable. See Recipe 15.15 for more on changing the tombstone quota factor. Since quotas can be assigned to users, groups, or computers, it is conceivable that multiple quotas may apply to a user. In this case, the quota with the highest limit will be in force for the user. You can also create a default quota for a partition that applies to all security principals. See Recipe 15.16 for more information on configuring the default quota. Quotas do not apply to members of the Enterprise Admins and Domain Admins groups. Even if you've configured a default quota for all users, members of those administrative groups will not have any restrictions. 15.13.4 See Also Recipe 8.9 for more on the computer object quota, Introduction in Chapter 15 for more on the attributes of quota objects, Recipe 15.14 for finding the quotas assigned to a security principal, Recipe 15.15 for changing the tombstone quota factor, and Recipe 15.16 for setting a default quota Recipe 15.14 Finding the Quotas Assigned to a Security Principal This recipe requires a Windows Server 2003 domain controller. 15.14.1 Problem You want to find the quotas that have been configured for a security principal (i.e., user, group, or computer). 15.14.2 Solution 15.14.2.1 Using a command-line interface > dsquery quota -part <PartitionDN> -acct <PrincipalName> 493 The following command searches for quotas that have been assigned to the RALLENCORP\rallen user in the dc=rallencorp,dc=com partition: > dsquery quota -part dc=rallencorp,dc=com -acct RALLENCORP\rallen 15.14.3 Discussion The dsquery solution will find only quotas that have been directly assigned to a security principal. The msDS-QuotaTrustee attribute on quota objects defines a SID that the quota applies to. The dsquery quota command will look up the SID for the specified account and match that against quota objects that reference that SID. Unfortunately, this doesn't quite show the whole picture. A user could have a quota assigned directly, which the dsquery command would show, but the user could also be part of one or more groups that have quotas assigned. These won't show up using dsquery. A more robust solution would entail retrieving the tokenGroups attribute of the user, which contains a list of SIDs for all expanded group memberships, and then querying each of those groups to determine whether any of them have quotas assigned. This is actually the type of algorithm that is used to determine a user's effective quota, as shown in Recipe 15.17. 15.14.4 See Also Recipe 15.13 for creating a quota Recipe 15.15 Changing How Tombstone Objects Count Against Quota Usage This recipe requires a Windows Server 2003 domain controller. 15.15.1 Problem You want to change the relative weight of tombstone objects in quota calculations. 15.15.2 Solution 15.15.2.1 Using a graphical user interface 1. Open ADSI Edit. 2. Connect to the partition on which you want to modify this setting (has to be done on a per partition basis). 3. In the left pane, expand the root of the partition. 4. Right-click on cn=NTDS Quotas and select Properties. 5. Set the msDS-TombstoneQuotaFactor attribute to a value between 0 and 100. 494 6. Click OK. 15.15.2.2 Using a command-line interface Create an LDIF file called change_tombstone_quota.ldf with the following contents: dn: cn=NTDS Quotas,<PartitionDN> changetype: modify replace: msDs-TombstoneQuotaFactor msDs-TombstoneQuotaFactor: <0-100> - then run the following command: > ldifde -v -i -f change_tombstone_quota.ldf 15.15.2.3 Using VBScript ' This code modifies the tombstone quota factor for the specified partition ' SCRIPT CONFIGURATION strPartitionDN = "<PartitionDN>" ' e.g. dc=rallencorp,dc=com intTombstoneFactor = <0-100> ' e.g. 50 ' END CONFIGURATION set objPart = GetObject("LDAP://cn=NTDS Quotas," & strPartitionDN ) objPart.Put "msDs-TombstoneQuotaFactor", intTombstoneLifetime objPart.SetInfo WScript.Echo "Set the tombstone quota factor for " & _ strPartitionDN & " to " & intTombstoneFactor 15.15.3 Discussion The tombstone quota factor is a percentage that determines how much each tombstone object counts against a security principal's quota usage. By default, tombstone objects count as one object. This means if a user's quota is set to 10, and the user deletes 10 objects, that user will not be able to create or delete any other objects until those tombstone objects have been purged from Active Directory. The msDs-TombstoneQuotaFactor attribute on the NTDS Quota container for each partition defines the tombstone quota factor. As mentioned previously, the default is that tombstone objects count 100% of a normal object, and thus, the msDs-TombstoneQuotaFactor attribute contains 100 by default. If you modify that attribute to contain 50, and a user has a quota limit of 10, then that user could delete 20 objects (i.e., create 20 tombstone objects) because 20 x 50% = 10. You may not care about how many objects your users delete; in which case, you'd want to set the tombstone quota factor to 0. 495 Recipe 15.16 Setting the Default Quota for All Security Principals in a Partition This recipe requires a Windows Server 2003 domain controller. 15.16.1 Problem You want to set a default quota for all security principals. 15.16.2 Solution 15.16.2.1 Using a graphical user interface 1. Open ADSI Edit. 2. Connect to the partition you want to modify (has to be done on a per partition basis). 3. In the left pane, expand the root of the partition. 4. Right-click on cn=NTDS Quotas and select Properties. 5. Set the msDS-DefaultQuota attribute to the number objects that security principals should be allowed to create if they are not assigned another quota. 6. Click OK. 15.16.2.2 Using a command-line interface Create an LDIF file called set_default_quota.ldf with the following contents: dn: cn=NTDS Quotas,<PartitionDN> changetype: modify replace: msDs-DefaultQuota msDs-DefaultQuota: <NumberOfObjects> - then run the following command: > ldifde -v -i -f set_default_quota.ldf 15.16.2.3 Using VBScript ' This code sets the default quota for the specified partition ' SCRIPT CONFIGURATION strPartitionDN = "<PartitionDN>" ' e.g. dc=rallencorp,dc=com intDefaultQuota = <NumberOfObjects> ' e.g. 10 ' END CONFIGURATION set objPart = GetObject("LDAP://cn=NTDS Quotas," & strPartitionDN ) objPart.Put "msDs-DefaultQuota", intDefaultQuota objPart.SetInfo WScript.Echo "Set the default quota for " & _ 496 strPartitionDN & " to " & intDefaultQuota 15.16.3 Discussion The easiest way to apply a default quota to all of your users is to modify the msDS- DefaultQuota attribute on the NTDS Quotas container for the target partition. This attribute contains the default quota limit that is used if no other quotas have been assigned to a security principal. You should be careful when setting the default quota because it applies to every non- administrator security principal. If you set the default to 0, for example, computers would not be able to dynamically update their DNS records in an AD-integrated zone because that creates an object. This may not be applicable in your environment, but the point is that you need to consider the impact of the default quota and test it thoroughly before implementing it. Recipe 15.17 Finding the Quota Usage for a Security Principal This recipe requires a Windows Server 2003 domain controller. 15.17.1 Problem You want to find the quota usage for a certain security principal. 15.17.2 Solution The quota usage of a security principal can be determined a few different ways. First, you can use the dsget command. Here is an example: > dsget user "<UserDN>" -part <PartitionDN> -qlimit -qused This displays the effective quota limit and how much quota has been used for a particular user. You can use similar parameters with dsget computer and dsget group to find the quota usage for those types of objects. Users can find their own quota usage by querying the msDs-QuotaUsed and msDs- QuotaEffective attributes on the cn=NTDS Quotas container for a partition. These two attributes are constructed, which means they are dynamically calculated based on the user that is accessing them (see Recipe 10.15 for more on constructed attributes). The msDs-QuotaUsed attribute returns how much of the quota has been used by the user and the msDs- QuotaEffective attribute contains the quota limit. 497 Alternatively, view the msDs-TopQuotaUsage attribute on a partition's cn=NTDS Quotas container, which contains the user's with the top quota usage. This attribute is multi-valued, with each value being XML-like text that contains the SID and how much of the quota the principal has used. See the Discussion section for an example. 15.17.3 Discussion If you implement quotas, you'll certainly need to tell users what their quotas are (or provide instructions on how they can find out for themselves). Currently, there are a few ways to determine quota usage as outlined in the Solution section. Perhaps the most interesting is obtaining the top-quota usage. Each value of the msDs- TopQuotaUsage attribute contains an entry that details someone that has high-quota usage (at the time of publication of this book, it was unknown exactly what "high" constituted). Each value of the msDs-TopQuotaUsage attribute contains blocks of data formatted in XML-like language. Each block has the SID of the security principal (<ownerSID>), quota used (<quotaUsed>), number of tombstone objects created (<tombstonedCount>) and the number of objects that are still active (<liveCount>) (i.e., not tombstoned). Here is an example of what the attribute can contain: >> Dn: CN=NTDS Quotas,DC=rallencorp,DC=com 3> msDS-TopQuotaUsage: <MS_DS_TOP_QUOTA_USAGE> <partitionDN> DC=rallencorp,DC=com </partitionDN> <ownerSID> S-1-5-21-1422208173-2062366415-1864960452-512 </ownerSID> <quotaUsed> 152 </quotaUsed> <tombstonedCount> 2 </tombstonedCount> <liveCount> 150 </liveCount> </MS_DS_TOP_QUOTA_USAGE> ; <MS_DS_TOP_QUOTA_USAGE> <partitionDN> DC=rallencorp,DC=com </partitionDN> <ownerSID> S-1-5-18 </ownerSID> <quotaUsed> 43 </quotaUsed> <tombstonedCount> 32 </tombstonedCount> <liveCount> 11 </liveCount> </MS_DS_TOP_QUOTA_USAGE> ; <MS_DS_TOP_QUOTA_USAGE> <partitionDN> DC=rallencorp,DC=com </partitionDN> <ownerSID> S-1-5-32-544 </ownerSID> <quotaUsed> 14 </quotaUsed> <tombstonedCount> 0 </tombstonedCount> <liveCount> 14 </liveCount> </MS_DS_TOP_QUOTA_USAGE> 15.17.4 See Also Recipe 15.14 for more on finding the quotas assigned to a security principal 498 Chapter 16. Backup, Recovery, DIT Maintenance, and Deleted Objects Introduction Recipe 16.1. Backing Up Active Directory Recipe 16.2. Restarting a Domain Controller in Directory Services Restore Mode Recipe 16.3. Resetting the Directory Service Restore Mode Administrator Password Recipe 16.4. Performing a Nonauthoritative Restore Recipe 16.5. Performing an Authoritative Restore of an Object or Subtree Recipe 16.6. Performing a Complete Authoritative Restore Recipe 16.7. Checking the DIT File's Integrity Recipe 16.8. Moving the DIT Files Recipe 16.9. Repairing or Recovering the DIT Recipe 16.10. Performing an Online Defrag Manually Recipe 16.11. Determining How Much Whitespace Is in the DIT Recipe 16.12. Performing an Offline Defrag to Reclaim Space Recipe 16.13. Changing the Garbage Collection Interval Recipe 16.14. Logging the Number of Expired Tombstone Objects Recipe 16.15. Determining the Size of the Active Directory Database Recipe 16.16. Searching for Deleted Objects Recipe 16.17. Restoring a Deleted Object Recipe 16.18. Modifying the Tombstone Lifetime for a Domain 499 Introduction The AD Directory Information Tree (DIT) is implemented as a transactional database using the Extensible Storage Engine (ESE). The primary database file is named ntds.dit and by default is stored in %SystemRoot%\NTDS, but can be relocated during the initial promotion process or manually via the ntdsutil command (see Recipe 16.8 for more details). Each database write transaction is initially stored in a log file called edb.log, which is stored in the same directory as ntds.dit. That log file can grow to 10 MB in size after which additional log files are created (e.g., edb00001.log), each growing to up to 10 MB. After the transactions in the log files are committed to the database, the files are rotated. These log files are useful when a domain controller is shut down unexpectedly. When the DC comes back online, Active Directory can replay the log files and apply any transactions that may have not previously been written to disk. The edb.chk file stores the last committed transaction, which can be used to determine the transactions in the log files that have yet to be committed. Two 10 MB placeholder files called res1.log and res2.log are used if the disk runs out of space and Active Directory needs to commit changes. In order to recover portions of Active Directory, or the entire directory itself, you need to have a solid backup strategy in place. You can back up Active Directory while it is online, which means you do not need to worry about having regular downtime just to do backups. Restoring Active Directory is also easy. To do any type of restore, you have to boot into offline mode, more commonly referred to as Directory Services (DS) Restore Mode, where the Active Directory database is not active. You can then restore a single object, an entire subtree, or the complete database if necessary. For a detailed discussion on backing up and restoring Active Directory, see Chapter 13 in Active Directory, Second Edition (O'Reilly). You need to be familiar with how deleted objects are treated in Active Directory, which can affect your backup procedures. When an object is deleted, the original object is removed, but a tombstone object is created in its place that contains a small subset of the original object's attributes. These objects are stored in the cn=Deleted Objects container in the naming context the original object was located in. The deleted object is named using the following format: <OrigName>\0ADEL:<ObjectGUID>, where <OrigName> was the original RDN of the object, <ObjectGUID> is the GUID of the original object, and \0 is a null-terminated character. For example, if I deleted the jsmith user object, its tombstone object would have a distinguished name, such as the following: CN=jsmith\0ADEL:fce1ca8e-a5ec-4a29-96e1-c8013e533d2c,CN=Deleted[RETURN] Objects,DC=rallencorp,DC=com After a period of time known as the tombstone lifetime (60 days is the default), the tombstone object is finally removed from Active Directory. At that point, no remnants of the former object exist in Active Directory. 500 Tombstone objects are important to understand in regard to your backup strategy because you should not keep backups longer than the tombstone lifetime. If you attempt to restore a backup that is older than the tombstone lifetime, it may introduce objects that were deleted, but the tombstone object no longer exists. Under normal conditions, if you do a nonauthoritative restore from backup, objects that were valid when the backup was taken, but were deleted afterward will not be re-added. A check is done before injecting new objects via the nonauthoritative restore to determine if a tombstone object exists for it. If a tombstone object exists for it, Active Directory knows the object was deleted after the backup. If the tombstone object has already expired (e.g., the backup is older than 60 days), Active Directory has no way to determine if the object was previously deleted and will happily re-add it. Reinjected deleted objects are referred to as lingering or zombie objects. The tombstone lifetime value is stored in the tombStoneLifetime attribute on the following object: cn=Directory Service,cn=Windows NT, cn=Services, cn=Configuration, <ForestRootDN>. The Anatomy of a Deleted Object Deleted objects are stored in the Deleted Objects container of a naming context. You cannot browse that container by default. You need to enable an LDAP control, as explained in Recipe 16.16, to view deleted objects. Table 16-1 contains some of the attributes that are stored with deleted objects. The attributes that are preserved in tombstone objects are determined by attributeSchema objects that have the 01000 bit enabled (8 in decimal) in the searchFlags attribute. Table 16-1. Useful attributes of deleted objects Attribute Description isDeleted The value for this attribute is TRUE for deleted objects. lastKnownParent Distinguished name of container the object was contained in. This is new in Windows Server 2003. name RDN of the object original object. userAccountControl This attribute is copied from the original object after it is deleted. This only applies to user and computer objects. objectSID This attribute is copied from the original object after it is deleted. This only applies to user and computer objects. sAMAccountName This attribute is copied from the original object after it is deleted. This only applies to user and computer objects. . up and restoring Active Directory, see Chapter 13 in Active Directory, Second Edition (O'Reilly). You need to be familiar with how deleted objects are treated in Active Directory, which. are used if the disk runs out of space and Active Directory needs to commit changes. In order to recover portions of Active Directory, or the entire directory itself, you need to have a solid. as Directory Services (DS) Restore Mode, where the Active Directory database is not active. You can then restore a single object, an entire subtree, or the complete database if necessary. For