Active Directory Cookbook for windows server 2003- P49 potx

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 >

Trang 1

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

Trang 2

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

15.14.1 Problem

You want to find the quotas that have been configured for a security principal (i.e., user, group,

or computer)

> dsquery quota -part <PartitionDN> -acct <PrincipalName>

Trang 3

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

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

15.15.1 Problem

You want to change the relative weight of tombstone objects in quota calculations

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

Trang 4

6 Click OK

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

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

Trang 5

Recipe 15.16 Setting the Default Quota for All Security Principals in a Partition

15.16.1 Problem

You want to set a default quota for all security principals

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

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 " & _

Trang 6

strPartitionDN & " to " & intDefaultQuota

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

15.17.1 Problem

You want to find the quota usage for a certain security principal

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 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

Trang 7

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

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>

</MS_DS_TOP_QUOTA_USAGE>

;

;

15.17.4 See Also

Recipe 15.14 for more on finding the quotas assigned to a security principal

Trang 8

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

Trang 9

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

Trang 10

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

sAMAccountName This attribute is copied from the original object after it is deleted This

Định dạng
Số trang	10
Dung lượng	40,86 KB