Migration Considerations: Centralized Versus Decentralized Management

Posted by arlene

When planning the domain layout for your organization, you should consider the type of management control (centralized versus decentralized), security policies, and the network infrastructure. When deciding whether to use many or fewer domains as the basis for dividing resources and users, consider what happens on the domain level. Each domain controller in a domain holds a complete copy of the domain’s portion of the directory database. Replication between domain controllers happens only within a domain. That is, when you add a new user, file, or print resource, the information is replicated via multimaster replication to all other domain controllers in the domain. The information is not replicated outside of the domain to the domain controllers in other domains (although some attributes are stored in the global catalog). Thus, by using a larger number of domains for geographically dispersed networks, you can reduce replication traffic.

Security policy also is implemented on a domain basis. If different departments in your business have widely varying security requirements, you might need to use the domain as a tool for organizing users and resources. You cannot define different password history values or set a security policy of how strong a password must be based on the OU.

Delegation of Administrative Rights Reduces the Need for Multiple Domains

In Windows NT, several built-in domain groups were used to grant administrative rights to users. Those included the all-powerful Domain Admins group, whose members can perform all administrative functions in the domain (unless the local administrator chose to take the Domain Admins group out of the Administrators group), down to the Account Operators and Backup Operators groups, which have access to only specific management functions. Although having these built-in user groups made it easy to grant specific users only a portion of the administrative rights that Ire possible in a domain, the drawback is that these rights exist throughout the domain. For example, if a user is a member of the Account Operators group, that user can potentially modify any user account in the domain (other than the Administrator accounts).

The Active Directory provides for the capability to delegate the assignment of administrative rights, down to the level of the OU. Because user accounts are not stored in the Registry-based SAM (Security Accounts Manager) database anymore, but are instead objects in the directory database, you can grant or deny administrative privileges on specific portions of the directory tree.

Two important concepts to understand about administrative privileges in the Active Directory are

• Per-property access rights
• Inheritance of access rights

Each object in the Active Directory can have an ACL attached to it, which defines who is allowed to perform what functions on the object. This access can be defined down to the property (or attribute) level. That means you can grant a specific user the ability to manage all aspects of user account management for a particular container object (OU), or the ability to modify selected properties of user objects within the container, such as the users‘ passwords or default directories.

Each object in the directory is made up of specific attributes, called properties. Each property is a single type of information about the object. You can grant or deny administrative privileges on each and every property of a particular object type. To make things even easier, you also can grant or deny administrative privileges on groups of properties. The property set attribute of the schema defines groups of properties that can be administered together. If the default definitions of this attribute do not meet your needs, you can modify the schema.

Caution

You should think carefully before modifying the schema. Changes to the schema cannot be undone. Although you can disable objects or attributes that you add, this applies only to new instances of these objects or attributes and not those created before you made schema changes. In other words, don’t change the schema unless you have an absolute need to do so. The objects that are provided with the Active Directory should satisfy most business needs.

Inheritance of access rights is another concept that makes delegating administrative authority more convenient. If you think of the Active Directory as a hierarchical structure organized in a tree fashion, you can pick a particular point in the tree and grant access rights to a user from that point to objects farther down the tree. The administrative rights flow down the tree to include other container objects and finally down to the end leaf objects of the tree. When a new child object is created in the directory tree, the access rights that apply to the container object that holds the child object are included with the default access rights created on the child object. This is true unless you place ACLs on specific objects or OUs to prevent this inheritance.

This method of inheritance allows for faster authentication time when the operating system must determine access rights. It isn’t necessary to trace back up the hierarchy through all parent objects to determine the access rights of a particular child object. The child object contains all the information that’s required to perform an access right check.

Possibly related posts: (automatically generated)
Migration Considerations: Centralized Versus Decentralized Management

• Microsoft Directory Synchronization Services (MSDSS) continue...
• PKI (public key infrastructure) Management and Certificate Lifecycle
• Microsoft Directory Synchronization Services (MSDSS)
• Email Permission Marketing Campaigns Part 2
• Data Repositories
• Network and Servers Technical Compare continue...
• Early Directory Technologies part 2
• Windows NT Domain Models
• Client/Server must Know
• Data Warehouse, Databases Easy Access Top ten Considerations part 2