aus einem Kapitel des Windows 2000 Resource Kits
In this chapter::
Deliverables:
Active Directory is a directory service that is completely integrated with Windows 2000 Server, offering the hierarchical view, extensibility, scalability, and distributed security required today by large organizations. Network administrators, developers, and users gain access to a directory service that:
Active Directory enables administrators to use the directory service as a source of information, as well as an administrative service.
With Active Directory you can centrally manage resources distributed across your enterprise network. As an increased number of distributed applications take advantage of the Active Directory, you will benefit by not having to implement and manage additional directory services. The result is that you save administrative and hardware costs.
When you plan for deploying Active Directory within your enterprise, consider the following key elements:
By following the guidelines in this chapter you will be able to formulate a plan that will enable you to administer your network efficiently. During this process you will accomplish the tasks in a parallel and iterative fashion.
For the location of planning checklists and templates that you can use to create your own working documents, see Appendix A.
To design your domain namespace, you will need to perform the following primary tasks:
Every Active Directory namespace design includes at least one domain. One domain may be sufficient for some organizations, and it is easier to administer and maintain than multiple domains. Each domain has one or more servers that serve as domain controllers.
Each domain controller stores a complete copy of the domain directory database and enables you to manage changes and updates to the directory. When you perform an action that results in an update to the directory, that update automatically replicates or copies the information to all other domain controllers in the domain.
You may need to create additional domains for one or more of the following reasons:
To predict how many domains you will require in your environment, attempt to estimate the number of attributes and objects that each domain will maintain for at least a three year period of time. While these numbers will depend on your unique business environment, you will want to make a high end estimation of objects and attributes. Take time to determine what you will store in the directory and the features you will use.
You need to make thoughtful decisions at this stage since changes in the overall domain architecture, such as domain consolidation and recreation, can be an IT-intensive support proposition. Also, adding more domains could increase server hardware costs because it requires adding more domain controllers.
If you design your domain namespace correctly, you will be able to withstand future business reorganizations without the need to restructure the existing domain hierarchy.
A global catalog server is a domain controller with at least a partial replica of each domain in the enterprise. The global catalog enables users to find objects of interest (such as users, file servers, printers, and more) quickly without needing to know a specific domain location. The Active Directory replication system automatically builds the global catalog using a default set of attributes. You can specify additional attributes by modifying the definition of those attributes in the schema. However, the attributes you want to replicate to the global catalog are those most frequently used in search operations, such as a user's logon name, which is needed to locate the actual object. Be cautious about specifying too many attributes as replicating to the global catalog will increase replication traffic.
Once you have decided on the number of domains for your organization, you will need to arrange them in a logical structure and assign each domain a DNS name. Every Active Directory domain requires a DNS name that reflects its position in the namespace.
The first domain in a namespace is called the root domain. Consider the guidelines below when choosing a domain name for the root Active Directory domain.
Choose a domain name that meets the following criteria:
When you register your name with an Internet registration authority it provides validation that the name you chose is exclusive to your organization. If your organization already has an established DNS infrastructure, you should determine whether you will use the established, registered DNS name. If you decide to use a name other than the established DNS name, your organization will be responsible for the registration costs of two DNS names.
Avoid naming your domains for divisions, departments, buildings, floors, or groups. The life of a domain can be from three to five years (or longer if it is an organization's registered organization name) and divisions, departments, and groups, can be renamed and reorganized many times in that timeframe.
Choosing a name for your domain namespace appears easy but this will prove to be one of the most political and iterative tasks during the course of your deployment planning.
A tree is a set of one or more Windows 2000 domains with contiguous names. Figure 1 presents a single tree with a contiguous namespace; company.com is the root domain, child.company.com is the child domain, and grandchild.child.company.com is the grandchild domain. These domain names are contiguous because each inherits the name of the domain ahead of it in the domain hierarchy.
Figure 1 A Single Tree With Three Domains Forming a Contiguous Namespace
The smallest tree is a single Windows 2000 domain. You can construct a larger tree by adding more domains to form a larger contiguous namespace. If you add more domains, you will hierarchically branch them from the root domain.
If your current organizational structure lends itself to a contiguous DNS namespace, you should set up all of your domains in a single tree. The advantage to implementing a single tree structure is that it is easier to reference and explain, and it is simpler to manage in DNS because all of the names fall under a single root name.
The advantage to implementing more than one tree is to accommodate two distinct DNS names. For instance, you might have subsidiaries that each require a separate namespace.
As you create domains and link them to the root domain, you enable default transitive trust relationships. Transitive trusts enable users in one linked domain to access resources in another linked domain, subject to access control. Trusts determine whether a user will be authenticated or not. Once a user is authenticated, Access Control Lists (ACLs) grant or deny access rights to users, groups, or resources. The trust hierarchy within a tree follows the naming hierarchy. Figure 1 provides an example of a transitive trust relationship; child.company.com trusts company.com. Access control is covered in more detail later in this chapter.
Use the Active Directory Domains and Trusts MMC snap-in to manage domains in the forest and trust relationships between external domains.
For in depth information about trust relationships and access control see the Microsoft Windows 2000 Server Distributed Systems Guide.
A forest is a collection of domains that share a common schema, configuration, and global catalog, and are all connected via transitive trusts. A schema contains definitions for every object that can exist in a directory service.
Each tree in a forest has its own unique, non-contiguous namespace. If you require multiple trees in your forest, the ‘top’ is the root domain of the first tree, and subsequent trees trust the ‘top’. By default, the name of the root domain of the first tree is used to refer to a given forest.
Figure 2 illustrates two trees in a forest, company.com and abctransport.com, that do not form a contiguous namespace. Tree one is the first tree, company.com, also called the ‘top’ tree.
Figure 2 Non-Contiguous Namespaces Exist Between Trees in a Forest
As with domains, transitive trusts between trees in a forest enable users in one linked tree to access resources in another linked tree, subject to access control. In Figure 2, notice the transitive trust relationships between Tree 1 and Tree 2. All domains within Tree 1 and Tree 2 trust one another due to the transitive trust relationship that is in place at the root domain level.
The main reason you would create an additional forest is if you and another administrative entity require separate control over the schema. This would be the case if two administratively independent units in your organization have different schema requirements. The merged conglomerates could be forced to occupy a single forest, sharing one schema, or it might be possible for them to continue to exist as two individual organizations in separate forests.
Another reason you would create an additional forest is if you conduct business with partners such as joint ventures or subsidiaries, or if you have some other limited ‘trust’ business relationships. When you create additional forests for this purpose, it enables you to provide business partners with controlled access to your namespace. In this situation, the user accounts of a partner’s domain reside in non-contiguous domains that you link to your corporate network directory service by explicit one-way trusts. Setting up explicit one-way trusts between these domains allows you to tailor access rights for these individuals and also monitor the interaction.
Explicit one-way trusts enable domains which are members of another Active Directory forest or members of Windows NT Server 3.51/ 4.0 domains to have access to a particular Windows 2000 domain. Figure 3 depicts how you can use explicit one-way trusts in your organization to allow business partners and servers with any version of Windows NT to access Windows 2000 resources.
Figure 3 Explicit One-way Trust Relationships.
Explicit one-way trust relationships limit the scope of authenticated access to the member domain that is explicitly trusted. Windows 2000 explicit one-way trusts are similar to Windows NT 4.0 trusts and they are not transitive.
If you have an existing DNS server in your environment, determine if it meets the following DNS name requirements:
If the existing DNS server supports the requirements above, there is no need to implement a new DNS server. If the existing DNS server does not support the requirements behind your DNS name, you must either upgrade or migrate to a DNS server that does, such as Microsoft DNS Server. Alternatively, you can choose a new name. One way of choosing a new name is to delegate a portion of the existing DNS namespace to a linking DNS server.
For more information about SRV RRs and IETF RFCs, see “DNS and Dynamic DNS” and “Windows 2000 Implementation of DNS” in the Microsoft Windows 2000 TCP/IP Core Networking Guide.
If you do not have a DNS server or if you are planning to replace the existing DNS server, use Microsoft DNS Server included with Windows 2000 Server. Microsoft DNS Server provides Active Directory integration and secure updates and it supports the extended character set and Unicode. For more information about Unicode characters, see Appendix C.
Microsoft DNS Server includes support for a dynamic update capability, a standard protocol that dynamically updates the DNS database of records. By configuring for the DNS update capability, you enable the servers and clients in your environment to add records automatically to the DNS database for you. This allows you to reduce administration costs because you do not have to add records manually, as is required for all non-dynamic DNS services. When you install a domain controller, the server registers multiple records in the dynamic DNS.
Whatever DNS server you choose, it must support the SRV RR (IETF RFC 2052). Additionally, it is best if the DNS server you choose supports the dynamic update protocol (IETF RFC 2136) and incremental zone transfer (IETF RFC 1995). You will want to perform testing with third-party servers for compatibility and also perform Dynamic Host Configuration Protocol (DHCP) testing, since DHCP has been enhanced to update DNS. Active Directory supports directory service-integrated DNS. Active Directory integrated zones are stored and replicated as directory data, instead of being stored in standard zone files.
A zone is a portion of the DNS namespace that corresponds to a series of records in a file stored on a DNS server. Zones do not correspond exactly to DNS domains. Rather, you can partition a domain into several sub-domains and then designate each sub-domain as a zone. You control these sub-domains or zones using separate DNS servers. You can configure a single DNS server to manage one zone or multiple zones, depending on your needs. You can divide a domain into multiple zones to distribute administrative tasks to different groups and to provide efficient data distribution.
With directory service-integrated DNS, you can select zones, thereby saving bandwidth. By replicating only the records that have changed instead of the whole zone, Active Directory integration can save on network traffic.
For more information about the dynamic DNS capability and zones, see “DNS and Dynamic DNS” in the Microsoft Windows 2000 Server TCP/IP Core Networking Guide.
If you currently have a DNS server in your environment that does not meet the requirements mentioned previously, you can implement Microsoft DNS Server to coexist with your current DNS server. Do this by delegating a zone to the Microsoft DNS server.. For example, ABC Transportation Company has an existing DNS server and DNS name, abctransport.com as shown in Figure 4. Since the existing DNS server does not support SRV RR or dynamic updates, they delegated a sub-domain to a new Microsoft DNS Server and named it root.abctransport.com. With the Windows 2000 domain branched off of their existing DNS domain, they get the support they need for the SRV RR and dynamic update and it also allows them to keep the existing structure.
Figure 4 Microsoft DNS Server Implemented as a Delegated Sub-Domain
Notice in Figure 4 that the Windows 2000 DNS names are longer because they inherit from the previously established DNS name.
To help you create your own domain design document, refer to Appendix A for the “Domain Design Checklist.”
An organizational unit (OU) is a container that you use to organize objects within a domain into logical administrative sub-groupings. An OU can contain, but is not limited to, the following objects:
When you design an OU structure, you are essentially creating an administrative model. An administrative model defines who in your organization is responsible for managing specific users and resources across the enterprise network, and the level of control each administrator maintains.
While you could model your OUs after your organizational structure (geographical locations, business units, divisions, or departments), this is not always the best practice. A good way to organize the OU hierarchy would be to mirror the way the directory will be administered. Create an OU structure to help you delegate administration, replace resource domains, and apply policy. You do not need to organize the tree for ease of browsing because Active Directory contains a powerful query capability. In reality, a directory with an elaborate OU structure will become more work to manage than is necessary.
The following steps are recommended for planning your OU structure:
To begin, you will create an OU structure for your first domain. You can use this domain and OU structure as a model for any child domains you add to your enterprise later. The OU structure you design should be able to facilitate future reorganizations with minimal object movement. Therefore, create an OU structure for your organization that will do the following:
If you have configured your network such that the application of Group Policy to certain computer and user objects requires directory access over slow Wide Area Network (WAN) links, then the depth of these nested computer and user objects within the OU hierarchy may have a performance impact. OU Nesting provides for finer control and easier management of OUs. Each level of OU nesting requires remote directory access for verification that policy is being applied.
Any time you create an OU, ask yourself these important questions:
When you create an OU, you can determine who will be able to view and control certain objects, and what level of control each administrator will have over the objects. You may allow some users or groups to have full access to certain OUs and objects, and other users to be completely restricted from access. This means they are unable to view the OU and are not even aware that it exists.
To deploy a distributed computing architecture such as Windows 2000 Server, you need to identify tasks performed by the different administrative groups within your organization, some perhaps at a central location and others at remote locations. Depending on the size and structure of your business, you will design your OU structure using a centralized administrative model, a decentralized administrative model, or a combination of both. Many enterprise organizations use a centralized administration model and manage all resources from one location. Small or highly-distributed organizations are likely to adopt the decentralized model and delegate tasks to subsidiaries or branch offices. Active Directory accommodates both models equally well.
You can combine aspects of both the centralized and decentralized administrative models. To do this, delegate certain tasks such as account creation or modification to subsidiaries or branch offices and control the principal tasks centrally from headquarters.
There are many factors such as geography, business requirements, and technology infrastructure that dictate which tasks will be performed centrally or locally. For example, data integrity and capacity planning may be performed centrally, while each branch office is responsible locally for end-user assistance.
If you have multiple domains, after your initial pass at creating your OU structure for the first domain, determine whether or not you can use the same model across all domains. If not, you may want to redesign the OU structure so that it is consistent across all domains.
Active Directory security supports delegation of administration, which enables administrators to grant specific administrative rights for containers and sub-trees to other users and groups. You can define levels of responsibility to create new users or groups at the OU level at which you create accounts. You can create a tree of OUs within each domain and delegate authority for parts of the OU sub-tree to others. In fact, you can delegate authority for parts of the OU sub-tree down to the lowest level of your organization without having to create a large number of domains, as was necessary with Windows NT Server 4.0.
You can configure the scope of the administrative responsibility you delegate in a variety of ways.. Start delegating administration by taking current administrative groups within your IT organization and mapping their roles to the appropriate roles in the new model. For example, you can delegate authorization for users or groups to:
When deciding how to structure your OUs, consider the hierarchy of administration. You can grant access rights to an administrator to manage a small set of users or groups within his or her area of responsibility and at the same time not grant access rights to manage accounts in other parts of the organization. The owner of an OU can delegate administration of child objects to the appropriate manager or group leader
The OU owner is responsible for determining the following with regard to permissions:
Using Access Rights
Active Directory is part of the Windows NT/2000 Trusted Computing Base and is a key component of the Windows NT/2000 security infrastructure. Each object in Active Directory has an ACL which stores the following information:
In Windows NT Server 3.51/4.0, delegation of administration is achieved through resource domains. This requires administrative personnel to manage trusts and it also requires additional hardware for domain controllers. With Windows 2000, you can reduce these administrative and hardware costs by replacing your resource domains with a hierarchy of OUs.
You can use the upgrade to Active Directory as a means of reducing the number of domains in your environment, thus simplifying your network administration and network structure.
Note When deciding whether to upgrade a resource domain to an OU, be certain to weigh the costs required to collapse the resource domains against the costs of leaving them in place.
For more information about replacing resource domains with OUs, see the chapter “Determining Upgrade Strategies from Windows NT 3.51and Windows NT 4.0” in this book.
To help you create your own OU structure design document, see Appendix A for the “OU Structure Planning Checklist.”
A Windows 2000 site is a set of Internet Protocol (IP) sub-nets, typically with high bandwidth connectivity between them. Sites control how replication occurs in your LAN or WAN environment. A site may contain domain controllers from several domains; and domain controllers from a single domain may be present in several sites.
Sites provide the following functions:
Sites are not bound in any way to the Active Directory namespace. The name of a directory object does not reflect the site or sites in which the object is stored. However, Active Directory does use site information. You need to understand this relationship to determine when to place two IP sub-nets in one site or when to create a new site. Active Directory uses site information in the following ways:
When designing the Active Directory structure, it is important for you to view the geographic profile of the network. The underlying network determines, to a great extent, the topology for an organization and its configuration. Site boundaries, site connections, message routing, directory replication, and system administration all depend on network topology. The key network areas that affect the topology for an organization are:
Keep in mind that future plans for sites (e.g., growth, downsizing, move, and more) affect the network topology as well.
You learned how to assess your network infrastructure in an earlier chapter, “Assessing the Existing IT Infrastructure”. You will use the data you collected from that assessment to help you determine the sites for your organization.
When analyzing connectivity between potential sites, answer the following questions:
Use the Windows 2000 Site Replication Manager snap-in to add, modify, or delete sub-nets and sites.
...
By placing a domain controller at each site, all users will have a local computer that can service query requests without requiring slow-link traffic. You can configure domain controllers at smaller sites to receive directory replication updates only during off-hours, to help optimize traffic flow.
Consider the following guidelines for placing domain controllers in your enterprise:
At a minimum, you must have at least one global catalog in the forest so that your users can log on to the network. That is why the first domain controller you install in a forest is automatically configured as a global catalog.
Consider the following guidelines for placing global catalogs in your enterprise:
Be certain that each global catalog server in your enterprise has the capacity to hold all objects from all other domains in the forest.
In Windows 2000, Group Policies allow you to define settings for groups of users and computers. Groups may contain users, computers and other groups. Groups simplify the management of large numbers of objects.
Essentially, Group Policies express business rules. Commonly-used policies in distributed systems define how users access, configure, and use resources on the network. For example, when a user logs on, policies determine what applications they see on their desktop. When a service (for example, SQL Server) commences on a computer, policies determine who and how many users can connect to the service. Policies can determine which documents and other services employees can access.
Policy-based administration enables you to create and apply policy for a specific state of a user or computer environment once, and then rely on the system to enforce that policy. You can manage a small number of policies rather than a large number of computers because you can apply a single policy to many users or computers.
Group Policy can only be applied to the Site, Domain and OU containers in the Active Directory. The Group Policy settings you create are contained in Group Policy Objects (GPOs). Administrators can delegate control of these GPOs.
You can create a specific desktop configuration for a particular group of users and computers using the Group Policy Microsoft Management Console (MMC) snap-in extension. The Group Policy MMC snap-in extension interface shows two parent nodes at the root of the namespace: computer settings and user settings. These are the parent folders you will use to configure specific desktop environments and to enforce Group Policies on computers and users on the network.
Computer Configuration include policies that specify operating system behavior, desktop appearance, application settings, assigned applications, file deployment options, security settings, and computer startup and shutdown scripts. Computer-related Group Policies are applied when the operating system initializes.
User Configuration include all user-specific information such as operating system behavior, desktop settings, application settings, assigned and published applications, file deployment options, security settings, and user logon and logoff scripts. User-related Group Policy is applied when users log on to the computer.
With the Group Policy MMC snap-in extension, you can specify settings for the following functions and features:
When you plan and design your Active Directory structure, you need to consider how you will implement Group Policy for your organization. This is crucial because how you apply Group Policy depends on how you have defined the Active Directory structure. If you carefully construct your Active Directory design with Group Policy in mind, you will be able to make the most of your Active Directory structure and simplify your Group Policy implementation and administration.
When you apply Group Policy to GPOs, Windows 2000 processes Group Policy hierarchically in the order of Active Directory containers as listed below:
The Active Directory container (site, domain, or OU) closest to the computer or user object overrides Group Policy set in a higher-level Active Directory container. For example, if you apply a Group Policy at the domain-level and then later apply another policy at the OU-level, the policy set at the OU-level will override the policy set at the domain-level as the OU policy is nearest to the computer or user object.
By default, the Group Policy settings you define are cumulative and are inherited from parent Active Directory containers. This is the default action and mechanisms exist that let you either force or prevent Group Policies from affecting users or computers in sites, domains, or OUs. However, for optimum performance and simplification, it is best to minimize the use of these mechanisms when applying Group Policy.
A single computer may require its own Group Policy, but normally organizations will group users and computers together in OUs and apply policy at the highest level possible.
While the default for Group Policy affects all computers and users in a selected site, domain, or OU, you can use one or more ‘Computer’ or ‘User’ memberships in Windows 2000 security groups to filter the effect of a GPO.
Group Policy provides a flexible framework for you to meet a variety of business requirements. The overriding caution is to use the simplest combination of these capabilities as possible, and to plan their use carefully.
When planning Group Policies in your organization consider the following:
When designing Group Policy and selecting the scenarios to use for your organization, consider the following factors:
Whether or not you implement Group Policy in a modular fashion (such as creating a GPO specifically for software management options, a GPO specifically for security configuration options, and so on) will be determined by the administrative requirements and roles in your organization. For example, if administrators are organized according to their duties you may find it useful to define policies in GPO modules.
Delegation of authority will depend largely on whether you use centralized or decentralized administration in your organization. Based on particular corporate requirements, network administrators can use ACL permissions to determine which administrator groups can modify policies in GPOs.
Network administrators can define groups of administrators (for example, software management administrators), and then provide them with read/write access to selected GPOs. This allows the network administrator to delegate control of the GPO policies. Administrators who have read/write access to a GPO can control all aspects of that GPO. If you are a network administrator that uses centralized administration, you may choose to give other administrators read-only access to GPOs. Doing so would allow those administrators to view the GPOs, but they would not be able to change them.
Security groups are the primary method for securing resources. Network administrators typically group users according to the network access their jobs require. For example, accountants working at a certain level will most likely need access to the same servers, directories, and files. Administrators can simultaneously grant users rights and permissions to network resources by granting rights and permissions to group accounts. Groups may contain users, computers and other groups. Groups simplify the management of large numbers of objects.
Windows 2000 includes the following new group features:
Security groups can play a role in the filtering of policy. For example, you might place all engineers, who require access to the same published engineering applications, in an OU. If one of the engineers is promoted and requires access to management-based applications, in addition to the other engineering applications, you could create a Group Policy filter to permit the engineering manager to access the engineering and management applications from the same OU. The policy that distributes the management-based applications must be applied to the engineering OU or a parent OU of the engineering OU.
If you are planning to integrate Exchange e-mail with the Active Directory in Windows 2000, you may use these new groups as distribution lists. These updated group structures are only available on a Windows 2000 domain controller.
To devise a deployment strategy for security groups, it is recommended that you perform the following tasks:
Windows 2000 Server includes three types of security groups, universal, global, and domain local. These three group types (defined separately later in this chapter) provide a rich and flexible access control environment and reduce replication traffic to the global catalog caused by group membership changes.
Unlike local and global groups of Windows NT 4.0, you can nest the Windows 2000 universal, global, and domain local groups. For example, an organization may have a production division that encompasses manufacturing, packaging, and shipping responsibilities. The production division represents a universal group. Manufacturing, packaging, and shipping departments represent global groups which nest within the production universal group. You may also add group members to the manufacturing, packaging, and shipping groups individually. The permissions you assign to the objects in the production group may be inherited through all of its members, with additional group object-specific ACLs assigned to each member. When you want to create an appropriate range of permissions for group objects, use the nesting technique.
As with nesting OUs, technically there is no limitation on how deep you can nest groups. However, if you nest groups too deep it could result in some network performance limitations.
The principle benefit of universal groups is that, not only can they contain members from any domain in the forest, but they can be used in an ACL on any object in the forest. This is in contrast to global groups and domain local groups. Global groups can only contain members from the same domain and can be referenced on any ACL. Domain local groups can contain members from any domain but can only be referenced in ACLs in the same domain.
The primary goal when creating and updating universal groups is to minimize replication traffic on the network. When you update the membership of a universal group, the complete membership of that universal group is replicated to all of the other global catalog servers in the forest. This can create a significant amount of replication traffic. With this in mind, consider the following objectives for creating and updating universal groups in your organization:
Windows 2000 Server global groups are similar to the Windows NT 4.0 global groups. However, now you can place users and other global groups into global groups (when in native Windows 2000 mode). Replication for global groups takes place within a domain boundary and not throughout the tree.
Global groups are literally global in scope. Global groups appear in the global catalog, but their members do not. All other trusted domains can view and access global groups.
Global groups cannot contain domain local or universal groups. They can only contain other global groups or individual users. Therefore, you would not make extensive use of global groups if your only objective was to grant permissions to resources within your own domain.
Some objectives to consider when creating global groups are:
Domain local groups are the least flexible groups. Domain local group memberships are valid only in the domain where they are defined and are not replicated to the global catalog. The domain local group is only useful within your own domain. Domain local groups allow you to take a combination of individual users, global groups from your domain and other trusted domains, and universal groups, and house them altogether. You can use domain local groups to import groups from other domains.
When creating domain local groups be aware that the same replication rules apply to domain local groups as the other two group types. Therefore, you will want to keep membership size small and take advantage of nesting.
Installing Active Directory on the first domain controller in a network creates a default schema. The default schema contains definitions of commonly-used objects and properties, such as users, computers, printers, groups, and more. The default schema also contains definitions of objects and properties that Active Directory uses to function.
The Active Directory schema is extensible, which means that you can define new directory object types and attributes, and new attributes for existing objects. Modifying the schema is not an operation that you should consider doing lightly as it has serious implications throughout the directory. You should modify the schema only when absolutely necessary. By default, write access to the schema is limited to members of the Schema Administrators Group. This group will only exist on the forest root domain. It is extremely important that you plan well before populating the schema.
You will want to set up a process to implement any schema alterations. You can appoint a committee of individuals to receive formal requests for schema changes. This committee of individuals would perform the following duties:
The most common schema modifications you will make is adding a new object class, creating new attributes and associating them with existing classes.
You should only create an entirely new class when no current class meets your needs. You can extend the schema by using the Schema Manager tool within the Windows 2000 Advanced Server Resource Kit or using ADSI.
The schema is implemented and stored on every domain controller within Active Directory and can be updated dynamically. As a result, an application can extend the schema with new attributes and classes, and can use the extensions immediately.
Extending the schema is a relatively complex operation; schema changes are replicated to every domain controller in the forest. Consider your needs carefully and assess whether an extension is really necessary.
To begin the process of implementing and maintaining the schema, you will want to appoint a committee to supervise changes to the schema. The members of that committee should contain individuals who have some expertise with directory services. It is important that these individuals understand that schema and configuration changes have forest-wide impact. The schema change committee should work with you to create a forest-wide change policy.
A forest-wide change policy is a proprietary document which outlines the disciplines for approving or disapproving schema alterations in your organization. When you begin to create a forest-wide change policy for your organization, address the following questions:
Use the following checklist of questions to help you create a domain design document for your organization.
Use the following checklist of questions to help you create an OU structure planning document for your organization.
When making changes to the schema, consider your needs carefully and assess whether an extension is really necessary. It is a good idea to appoint a committee of individuals who will approve or disapprove of all requisitioned changes.
The following are questions you should ask yourself when you begin to create a forest-wide change policy document for your organization.
The following are questions you should ask yourself when determining who will make schema changes:
The following are questions the appointed schema change policy committee should ask themselves about each proposed change: