Objectives
This chapter provides a brief introduction to Active Directory and its design-related characteristics. In doing so, it provides important background information regarding the unification of directory services. No formal exam objectives are covered, but you will be better prepared to approach the exam objectives after reading this chapter.
This key feature of Windows has been in the works for some time. A unified directory service is just what you may already expect, a single directory providing various services to multiple directory service-enabled applications that may request them. Active Directory as a unified directory, as well as additional Active Directory facts, are presented in this chapter.
Outline
Active Directory Is a Unified Directory
Active Directory Features and Benefits
Migration from Previous Versions of NT
Study Strategies
Understand the core underlying functions of Active Directory, such as Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS). Being able to break down Active Directory down into manageable and comprehensible sections will make it easier to design.
Be able to identify Windows NT 3.5x and 4.0 domain models and how to map those to Windows 2000 and Active Directory.
Do not focus solely on the technical aspects of Windows 2000. It is a business system as much as it is an operating system, and you need to understand how to effectively model the operating system according to business objectives.
Read up on DNS because it is core to Active Directory. If you feel you don't have a good understanding of it, you may want to read part of Chapter 10, "DNS and Active Directory," now.
Microsoft's Active Directory is a directory service completely integrated with the Windows 2000 line of server and workstation products. It provides an extensible, flexible, and powerful set of features, tools, and utilities designed to scale from the smallest of home businesses to the largest worldwide corporate enterprises. Network administrators, management, developers, and users utilize Active Directory to gain access to resources.
This chapter focuses on the Windows 2000 architecture as it relates to Active Directory and on specific design related components of Active Directory itself. It confirms the fact that with the introduction of a new operating system (OS), a wide array of upgrade and migration scenarios are bound to appear. Design considerations for upgrading each of the four Windows NT domain models are discussed briefly and we also make a brief stop on Novell Street.
Finally, various development interfaces are introduced at a high level along with some of the new design-focused Windows 2000 features. Because this chapter addresses general concepts rather than specific objectives, a case study is not presented.
If you are reading this book, you most likely already know what a directory is. You could call the yellow pages a directory, or a physician list, or an online search tool such as Yahoo! or AltaVista, or…you get the point! Directories of some fashion are all around us; heck, these days even when we flip channels on cable television we are presented with a channel guide—another directory.
Windows 2000 Active Directory directory services is essentially two parts:
Directory. . A directory is a physical storage container that contains anywhere from a few up to millions of various types of objects. The most popular directory is a phone book, which contains names, phone numbers, and addresses—types of objects.
Services. . The primary function of a service with regard to a directory is to make the information in the directory useful. The Web interfaces of popular search engines Yahoo.com, AltaVista.com, and Lycos.com are all examples of services that provide you easy access to the information in the directory—the Internet.
Now you have the "textbook" definitions of a directory and a directory service. Next let's take a look at Active Directory as a provider of services. Figure 1.1 illustrates this concept.
The notion of a single logon for access to all available network resources is not new; in fact, it can be argued that at one time a few years ago, it actually existed. Remember the mainframe and dumb terminal days? Okay, not the best reference, but it gets the point across. With the ever more complicated world of directory services and productivity standards and heterogeneous systems with a need to talk to one another, the need for a standards-based directory service is more apparent than ever.
Microsoft's Active Directory incorporates the Internet concept of a namespace with the operating system's core directory services. This allows administrators to unify the multiple namespaces that exist across heterogeneous applications throughout the enterprise. It uses the Internet standard Lightweight Directory Access Protocol (LDAP, which you'll learn more about in the next section) as its core protocol, which allows it to cross operating system boundaries and integrate multiple namespaces. It can manage other Network Operating System (NOS) directories and application-specific directories and helps reduce the administrative load required to maintain several dissimilar namespaces and their associated directory services.
X.500 is the Open Systems Interconnect (OSI) directory standard. It defines a namespace, an information model, a functional model, and an authentication framework. Additionally, X.500 defines Directory Access Protocol (DAP), an OSI standard protocol for accessing an X.500 directory. DAP is extremely feature rich and carries a lot of overhead. Its clients rarely, if ever, use many of its features. Because DAP is so difficult to implement and requires so much raw power to run, an alternative protocol was created. This new protocol, LDAP, was created to leverage the relatively low overhead of the TCP/IP suite of protocols to access X.500 directories. Remember this: Active Directory is not an X.500 directory. It uses LDAP as the access protocol and supports the X.500 information model without having to host the entire X.500 overhead. X.500 directories accessed with LDAP remain intact and require no changes for LDAP to be successful.
As previously stated, LDAP is the core protocol that enables Windows 2000 to leverage the benefits of X.500 style directories without the X.500 burden. LDAP defines the following components:
Organizational model. . Defines organization of data in the directory.
Security model. . Defines a manner in which data in the directory may be securely accessed.
Functional model. . Defines the operations used in querying and modifying data in the directory.
Topological model. . Defines how the directory service integrates with other directory services to form a global directory on the Internet.
One integral piece of Active Directory yet to be mentioned is another old Internet standard, Domain Name System (DNS). By utilizing DNS for name resolution within LDAP queries, Active Directory is able to support working with directory services running on non-Microsoft systems.
Note
DNS . Chapter 10, "DNS and Active Directory" is devoted to DNS and its integration with Active Directory.
Microsoft realizes that good applications need to support several industry standards, so it has built the following support into the native Active Directory implementation:
Subsets of the 1993 Directory Access Protocol (DAP)
1993 Directory System Protocol (DSP)
Directory Information Shadowing Protocol (DISP)
Lightweight Directory Access Protocol (LDAP)
Microsoft continues to work with standards organizations such as the Internet Engineering Task Force (IETF) to further refine standards with a goal that someday we'll be able to achieve seamless integration of standards-based directory services across the board.
Note
The LDAP Standard . The LDAP (version 3) standard is defined by the IETF under RFC-1823. Active Directory supports both version 2 and version 3 of the LDAP implementation.
Note
IETF RFCs . Throughout this text, we will reference standards using IETF Request For Comments (RFC) numbers where appropriate. To access an RFC, connect to http://www.ietf.org/rfc.html and search for the appropriate RFC number.
Active Directory features and benefits don't stop with X.500 and LDAP support. There are a considerable number of enhancements over the previous versions of Windows NT, which are highlighted in the following sections.
Active Directory support for the DNS standard implementation is huge. It provides a common namespace between the Internet and your internal network. As discussed in the previous section, the support for LDAP and the X.500 functional model provides a common and intuitive query process for retrieving resources from the directory.
Active Directory uses RFC-822 standard naming formats, which are very similar to email addresses, as a "friendly" name. This friendly name can be used for email, printed on a business card, and logged on to the network.
Finally, LDAP URLs and X.500 names allow any client to access data from anywhere providing they work from an LDAP-enabled client and have security clearance. An LDAP URL is in this form:
LDAP://a_server.mycompany.com/CN=joesmith,OU=whitepapers, OU=OpSys,OU=Windows2000,DC=Microsoft,DC=com
Most LDAP URLs are handled by the LDAP-enabled application program and remain unnoticed by users.
Without question, the biggest draw from the development community to Microsoft products is the rich set of Application Programming Interfaces (APIs). APIs provide a standard set of functions to which developers may write code. These functions allow access to Active Directory resources, thereby encouraging the development of application programs and tools that make use of the directory's services. The following sections describe the three major API sets.
Active Directory Services Interface (ADSI) is a set of Component Object Model (COM) interfaces that give developers the ability to query and manipulate directory services without knowing specific information about how the directory services are implemented. ADSI is a part of the Open Directory Services Interface (ODSI), which is the Windows Open Systems Architecture (WOSA) standard for manipulating multiple directory services. ADSI objects are available to provide access to Windows 2000, Windows NT 4.0, NetWare 3.x through 5.x, and any other directory service that supports LDAP. It greatly simplifies the development of distributed applications as well as the administration of distributed systems because it abstracts the capabilities of directory services from different network providers and provides a single common set of APIs for managing distributed network resources. Figure 1.2 illustrates how clients and servers currently access directory services through proprietary API calls. Figure 1.3 introduces ADSI as a means of abstracting multiple directory services interfaces and representing them to the developer, administrator, or user in a standard set of COM objects.
Figure 1.3. Heterogeneous directories abstracted by the ADSI and represented as a common set of objects.
The ADSI objects are designed to meet the needs of not only developers using traditional C and C++ but also the network administrator and the end-user. The following list highlights the intended usage of ADSI for the three groups.
Developers. . This area is what systems engineers and consultants would refer to as "hard core" developing. Developers use a compiled language such as C++ to write distributed applications to manage network resources, print queues, and more.
System Administrators. . This area of usage would include scripts written in an interpreted language, such as VBScript. System administrators would be able to develop small and minimally complicated script applets they could utilize over and over again. Common operations for this would be in the area of adding a large number of users to the directory and adding them to specific security groups.
Users. . Users would even have the ability to develop simple scripts that could query Active Directory with the help of a COM object. This query may yield such information as the number of print jobs in a queue for a specific group of users.
Active Directory provides easy-to-use, yet powerful administration tools. These tools present objects in a hierarchical organization to the administrator, which gives him the ability to effectively model large organizations. The graphical user interface features a highly anticipated drag and drop control console tool. This tool is most useful in the restructuring of Active Directory domain objects using a process called pruning and grafting. To prune is to cut and to graft is to paste. If you, for example, create a large number of objects in the wrong place in the directory and need to move them to another area, you would utilize this process.
Note
Further Details on Pruning and Grafting . For more information on pruning and grafting, see the Microsoft Windows 2000 Distributed Systems Guide, which can be found on Microsoft TechNet, as well as at http://www.microsoft.com/windows2000.
Sitting at the core of Active Directory is the schema. The schema defines classes, attributes, and attribute syntax (rules) for all Active Directory objects. When you right-click on an Active Directory object, such as the user object in Figure 1.4, you'll see several of the standard user object attributes, such as first name, last name, and so on.
Active Directory provides an installable interface to the schema through the Microsoft Management Console (MMC). From this interface (shown in Figure 1.5), on a domain controller specified as the Schema Master, an administrator may extend the schema to include additional objects and object attributes after modification of the schema has been enabled.
Suppose, for example, a company develops an application that utilizes an employee's Social Security number. The schema by default does not provide an attribute for the Social Security number, so the administrator would need to add it to and associate it with the user object class. We'll cover the schema and modification policies in more detail in Chapter 13, "Developing a Schema Modification Plan." For now, just understand that the schema may be extended to include custom attributes.
To enable for all domains the ability to locate objects across an entire Active Directory forest, special servers called global catalog servers maintain partial directory information from all domains in a forest. The global catalog servers provide users with quick returns on Active Directory queries. Global catalog servers contain a replica of all objects in each domain in the forest, but only a specific sub-set of each object's attributes. This "abbreviated catalog" is generated through a special partial replication process. If a global catalog server cannot satisfy a query within its partial replica, it forwards the request to the source domain's full database replica for fulfillment.
Active Directory is a true distributed database. Instead of having a single primary domain controller and several backup domain controllers, such as previous versions of Windows NT, Windows 2000 implements Active Directory domain controllers as equals.
Note
Multi-Master Exceptions . There are a few exceptions to the notion of "all domain controllers are created equal," so Microsoft created the operations masters, which will be discussed in detail in Chapter 12, "Designing an OU and Group Policy Management Structure."
It is estimated that 99 percent of the activity to which Active Directory must respond is query (read) activity. The remaining 1 percent is update (write) activity. This fact is highly responsible for the need to distribute databases. Creating multiple replicas of the directory and keeping them consistent significantly increases the number of queries that can be processed with little or no performance degradation. This disbursement and synchronization of Active Directory information is known as multi-master replication.
Microsoft generally does a pretty good job of providing a smooth transition from one platform to another, and that doesn't change with Windows 2000, although it does require quite a bit more planning! Active Directory operates in mixed mode by default. Mixed-mode (as opposed to native-mode) domains are domains in which Active Directory domain controllers may exist simultaneously with down-level Windows NT 3.51 and Windows NT 4.0 domain controllers. In this situation, Active Directory domain controllers work and act just like down-level domain controllers. We'll discuss upgrade design considerations in various chapters in Part IV, "Designing a Directory Service Architecture."
Note
Mixed and Native Modes . Mixed-mode operation will be essential during the Windows 2000 migration process, but it is important to point out that is has several limitations. Once you complete a migration, you should set your sights on a native-mode implementation plan to leverage the full benefit of Windows 2000.
One other area of interest in terms of backward compatibility is name resolution services. Mixed-mode domain controllers still understand NetBIOS. Native-mode domain controllers give you the option of eliminating NetBIOS name resolution in lieu of dedicated SMB ports. This provides for more efficient name resolution. Since several applications (including Microsoft BackOffice 4.5) still have NetBIOS roots, removal of NetBIOS is not likely to be an option for a while.
It is important to realize that native-mode Windows 2000 still understands NetBIOS. You control whether it continues to do so. Many people have the misconception that once you go to native mode, you lose NetBIOS—that is simply not true.
Interoperability is an extremely broad topic, especially when it is used in reference to Microsoft products. This section focuses on Active Directory interoperability with Novell NetWare and Microsoft Exchange, and then takes a look at future interoperability endeavors.
At the time of this writing, Microsoft had released the second release candidate of the Microsoft Directory Synchronization Services (MSDSS) utility (packaged with Services for Netware 5.0). This utility provides one- or two-way synchronization between Active Directory and Novell Directory Services (NDS), and one-way synchronization between Active Directory and the Novell Bindery. This utility requires Novell's Windows 2000 client (4.7) on the server and cannot co-exist with other NetWare interoperability solutions, such as Gateway Services for NetWare.
Two-way synchronization gives the administrator the option to use the Active Directory Users and Computers user interface or the Novell NDS administration utilities to make changes to directory objects. One-way synchronization forces the administrator to make all directory changes in Active Directory.
Windows 2000 introduces a plethora of new technologies for building solutions, among which are integration solutions for both Microsoft products and other third-party products through the use of ADSI. Microsoft Exchange 5.5 is the first Microsoft product to make use of ADSI (and other technologies such as Collaborative Data Objects) to provide collaboration and information sharing between Exchange 5.5 and Active Directory through the use of an Active Directory Connector (ADC). Administrators of Exchange can leverage the next-generation administration tools of Windows 2000 to manage down-level Exchange servers and synchronize the Exchange and Windows 2000 directories. This synchronization must be configured and is not without limits.
Exchange 2000—and, on a broader scale, the next generation of Microsoft BackOffice products—will be tightly integrated with Windows 2000 and Active Directory, and will take full advantage of the Windows 2000 security model, replication, authentication, and more.
Microsoft introduced the Joint Development Program (JDP) for select alliance partners to develop applications that (among other things) leverage Active Directory services. We can expect to see several applications spawn from this program throughout the life-cycle of Windows 2000. Additionally, it would be safe to assume that a very high percentage of the development community will be creating and upgrading applications to leverage the benefits of Active Directory.
The Windows 2000 API sets, specifically the ADSI and LDAP C APIs, provide the foundation for the development of Active Directory-aware applications, including interoperability packages.
Remember Microsoft Exchange 4.0? Do you see any similarities between the Exchange directory and Active Directory? The Exchange 4.0 directory structure and its extensible storage engine (ESE) provide the foundation for Active Directory. The ESE provides the following two benefits that Microsoft was able to capitalize on in migrating it to a general-purpose directory service:
Active Directory supports multiple stores (the directory database) and each store is capable of reaching sizes up to 17TB, which is millions of objects per store.
Domain Name System (DNS) is an Internet standard name resolution service that maps fully qualified domain names (FQDNs) to IP addresses. The Windows 2000 implementation of DNS includes some major enhancements over the traditional DNS, which enable it to become the core name resolution backbone on both sides of the corporate firewall. The following list outlines these major enhancements:
Service Resource Records (SRV RR). . SRV records (as these are commonly called) are used to specify the location of a server for a specific protocol, service, and domain. They are defined in RFC-2052.
Dynamic update protocol. . Dynamic update protocol provides a means of automatically updating primary DNS zone data. The dynamic update protocol is defined in RFC-2136. This is where the "dynamic" comes in with Dynamic DNS (DDNS).
Incremental zone transfer. . Incremental zone transfer allows for the partial transfer of a DNS zone file to its replication partners. This partial replication sends only modifications to the requesting server, and therefore drastically decreases the overhead involved in transferring an entire zone file. Incremental zone transfer is defined in RFC-1995.
Active Directory integrated zones. . If you opt to use the Microsoft implementation of DNS, you can store your zone files in Active Directory and take advantage of its replication topology. This option alleviates the hassle of maintaining flat text files for your DNS zones.
Note
DNS or DDNS? . DNS and DDNS both refer to Domain Name System. A DNS that supports dynamic update protocol may be referred to as DDNS or DNS. In this book, we will use both at times, but DNS in general.
Windows Internet Name Service (WINS) and Dynamic Host Configuration Protocol (DHCP) have both been revised to provide support for dynamic DNS. We address DHCP and WINS integration with DNS in Chapter 10.
Windows 2000 implements a distributed security model based on the MIT Kerberos v5 authentication protocol. Kerberos is used for distributed security within a tree, and incorporates the native Windows 2000 Access Control Lists (ACLs) for both public and private key security. Active Directory replaces the registry as the store for the security system and manages user accounts, domains, and group accounts as a trusted component within the Local Security Authority (LSA).
For objects that do not have Kerberos credentials, Active Directory supports the use of X.509 v3 public key certificates. In this scenario, an outsider such as a subcontractor would be granted secure access to specific internal information. The X.509 v3 specifications require certificates be issued by a trusted certificate authority, such as Verisign.
The transition to Windows 2000 should be a methodically planned strategic process that takes into account not only the existing Windows NT infrastructure, but also strategic business initiatives, company goals, administrative requirements, and company direction. Take your time in reading this next sentence, and make sure you remember it as you read through this book: The complexity of migrating to Windows 2000 is not in the upgrade process itself, but in the planning process where you determine the position of the company now and the direction of the company in the 3–5-year future and develop an upgrade strategy that meets the needs of every business objective. Parts II and III of this book will be dedicated to helping you prepare for these types of migrations.
The remainder of this section focuses on the four Windows NT 3.5x and 4.x domain models and describes the process by which each model should be approached in terms of a Windows 2000 upgrade.
We will not cover the Windows 2000 and Active Directory installation processes in this book; however, you will see references to pertinent resource materials throughout.
Table 1.1 lists the recommended in-place upgrade strategy for Windows NT 3.5x and 4.x servers and domain controllers to Windows 2000.
Microsoft recommends that you do an incremental in-place upgrade. Through this process, you can slowly and methodically upgrade servers to Windows 2000, while maintaining all the functionality of your underlying Windows NT networks. This process is also transparent to client computers, which may continue logging on to the domain as they always have.
The following steps contain the generalized high-level, step-by-step processes recommended for the migration to Windows 2000. These steps are not detailed and should not be referenced during an actual migration. Derivations of each of these steps can be applied to all four migration processes. They are presented to give you exposure to the high level processes you can expect to perform during migration.
Analyze the business requirements. See Part II, "Analyzing Business Requirements."
Analyze the technical requirements. See Part III, "Analyzing Technical Requirements."
Develop a project plan and supporting documents. See Part V, "Preparing for Implementation."
Execute the project plan.
The following steps highlight the general steps you might take to migrate a single Windows NT domain to Windows 2000:
Verify that a full backup of the domain controllers (PDCs and BDCs) exists.
Remove a BDC from the network. By taking a BDC offline, you ensure that you have a current, untouched copy of your SAM database available in case of disaster.
Upgrade the PDC to your first Windows 2000 domain controller. This first domain controller will become your "root" server in the Windows 2000 domain.
Verify the functionality of the upgraded PDC. At this stage, clients may continue to log on as if the PDC were still a Windows NT 4.0 server.
Once you are satisfied, bring the offline BDC back online and upgrade it to Windows 2000 as an additional domain controller in the same domain. For multiple-domain models (single master, multi master, and complete trust), you'll need to repeat this process for each account database. Additionally, it is recommended for the multi master and complete trust models to create a "phantom" top-level domain and insert all account domains as children of this phantom domain. Chapters 10 and 11 provide more detailed description of domain namespace options, including the phantom domain.
Finally, upgrade all member servers and workstations at your leisure. Because they will not be Active Directory domain controllers, these servers and workstations may be upgraded before, during, or after the project.
After all computers are upgraded to Windows 2000 Server or Professional, you may opt to turn to native mode to receive the added functionality of nested groups, universal groups, and change and configuration management utilities.
Note
Antiques . You probably have noticed that we've "ignored" Microsoft operating systems prior to Windows NT 3.5x. If you have Windows NT servers previous to version 3.5x, you should upgrade them to version 3.5x or 4.x before attempting a Windows 2000 upgrade.
The single domain model is by far the most simplistic domain model to migrate to Windows 2000. There are always options to split the single domain into multiple child domains of a single parent, but this is not recommended unless the business direction requires it. Be sure to develop and stick with a migration plan and an Active Directory design that best fits the needs of your company. In Figure 1.6, SingleDom, Inc., a company utilizing the single domain model, performs an upgrade to Windows 2000 and Active Directory. Notice the offline area. It is a key part of ensuring that you'll have the ability to recover from disaster during the upgrade process.
The single master domain model presents a few options for the migration process. Depending on the business model, administrative model, and infrastructure of the company, the migration team may decide to collapse resource domains and utilize a single Active Directory domain model. The removal of resource domains can greatly reduce administrative overhead and lead to a more manageable network. The most notable reason for implementing Windows NT single master domain models centers around the limitations of the SAM database size of 40MB. This reason is no longer valid in Windows 2000 and you should consider collapsing the resource domains into Windows 2000 organizational units (OUs). The same scenario applies if resource domains were created to delegate administrative control. On the other hand, if you find the creation of resource domains falls into one of the following categories, then you would want to keep them as child domains of your master domain.
Support for decentralized administration
Support for multiple domain policies
Support for international differences
Isolation of domain replication traffic
Balancing of domain replication traffic
Note
Organizational Units . OUs provide a means by which you can partition a domain into a hierarchical structure. They are used mainly for administrative purposes. Chapter 12 explains OUs in more detail.
It is very important to identify the necessity of resource domains during the planning phase of your migration. You do not want to collapse a resource domain if the reason for its existence falls one of the categories within the preceding list. In Figure 1.7, MasterDom, Inc., a company utilizing a single master domain model with two resource domains, decided to collapse the resource domains into OUs of masterdom.com.
In a multiple master (multi-master) domain model, two or more master account databases exist on the network and provide the account base for one or more resource domains each. Each master domain trusts all other master domains, and each resource domain trusts all master domains. However, the master domains do not trust the resource domains. This scenario presents some additional challenges to the migration team. The best solution for migrating the multi-master model is to create a brand new phantom top-level root domain (company.com) and upgrade all master domain PDCs to child domains of the phantom root domain (master1.company. com) and (master2.company.com).
Note
Why Phantom Domains? . A phantom root-level domain may be utilized for numerous reasons. In this case, we chose to use one to keep both master domains operating at the same hierarchical level within the domain tree.
The resource domains should collapse to organizational units in the domain from which they were resources. Alternatively, one of the master domains could be selected to be the root of the Windows 2000 domain tree, and all other master domains could become child domains of it. This would probably create some tension between administrative teams in competing for that top-level domain spot since security can filter down from the top. Figure 1.8 depicts a company utilizing the multiple master domain model that chose to use a phantom top-level root domain in its migration.
Anyone who's been in the Windows NT world for any length of time undoubtedly has heard other names for the complete trust model—names that cannot be mentioned in this book. Active Directory can ease the pain and suffering administrators often go through when they are responsible for a complete trust model. Migrating a complete trust model to Windows 2000 would enable a company to design a much more streamlined and manageable architecture.
There are a few approaches to consider for this migration process, and the one you choose should match your business objectives and administrative structure. First, as with the multi-master model, consider creating a phantom top-level domain. This domain would do little more than provide the namespace for the rest of the directory. You could then migrate all domains to Windows 2000 as child domains of the phantom domain. This approach is the most attractive, again, because all account domains are treated as equals. This approach does not scale well, however, if administrative control needs to be centralized. The other approach is to structure the existing domains around your organizational and administrative hierarchy. For example, if in your complete trust model you have a specific domain for your corporate office, you may want to make that your top-level domain. All other domains would fall under it in a hierarchical tree. This would give the corporate office the opportunity to gain administrative control over all domains in the tree, but would also create opportunity for domain-level administration. This is referred to as a hybrid administration model. Figure 1.9 shows how a company using a complete trust model might implement Windows 2000 and Active Directory. In this figure, domain1 was the focal point of corporate control and so was used as the top-level Active Directory domain.
Microsoft includes an updated NetWare Migration Tool with Windows 2000. The Directory Service Migration Tool can be used to migrate NetWare 3.x, 4.x, and 5.x Bindery, and NDS based objects as well as volume data to Windows 2000. The tool is designed to work in a three-step process:
Create and model a view from NetWare.
Configure a view to Active Directory.
Migrate NetWare volumes to Windows 2000.
One of the problems with previous versions of the Netware Migration utility was that there wasn't much you could do with the NetWare structural information—that is, information from NDS or the Bindery basically came across as is, and then you had to go back and spend numerous hours reconfiguring it to fit your needs. The Directory Service Migration Tool introduces the concept of modeling directory data before you perform a migration. This powerful feature allows you to perform operations on data, such as modifying object data to fit your needs. For example, you can create, delete, and move objects, or add users to groups. You can also define options for setting passwords.
After you have modeled your data to fit your needs, you can perform an operation called configuring a view to Active Directory. This operation shows the source (NetWare) and destination (Active Directory) containers for your modeled objects. At this point you can commit your modeled data to Active Directory, which will create all the objects based on your view in Active Directory. Once this operation finishes, it is a good practice to use the Windows 2000 Directory Management Tools to verify successful directory migration.
Finally, you can migrate NetWare volumes to Windows 2000 using the Directory Service Migration Tool. You can migrate files, security attributes, and volume objects using a wizard-based utility.
As you've probably been able to guess, Windows 2000 deployment, and specifically Active Directory design, requires quite a bit of up-front planning and analysis. The entirety of Part II of this book is dedicated to business analysis, something we've rarely, if ever, seen in an MCSE Training Guide (or MCSE exam). As you read on, keep in mind that Microsoft developed Windows 2000 with the business needs of business in mind, not just the technology interests of the IT department. That alone plays a major role in way the material in this book is presented, as you are about to see. The goal of Windows 2000 is to change the way businesses operate by making them more efficient, scalable, and, of course, more cost efficient by reducing the total cost of ownership.
Active Directory is a directory service completely integrated with Windows 2000. A directory is a collection of objects and services providing a method for making directory information accessible for users. Active Directory is a unified directory, which means that it provides the capability for other directories to integrate their services to form a single directory service.
Active Directory introduces the Internet concept of a namespace within the core Windows 2000 operating system. Active Directory (AD) is designed around and integrates tightly with the DNS namespace and uses LDAP as its core standard protocol. LDAP was derived from X.500 DAP standards as a means to "lighten" the load of a full X.500 implementation, which is extremely resource intensive.
AD incorporates a rich set of APIs, including the ADSI, MAPI, and LDAP C APIs. ADSI provides a set of COM objects that allow developers, and the occasional brave systems engineer, to write code to interface with Active Directory services. MAPI functionality is carried over from previous versions of Windows NT for backward compatibility reasons. Although many applications continue to use MAPI, it is expected that MAPI will be replaced by ADSI and other more robust APIs in the near future. Finally, the LDAP C API exists primarily for the C or C++ developer tasked with developing distributed applications.
Pruning and grafting, two relatively new terms in the Microsoft genre, are supported under the drag-and-drop administration functionality. To prune is to cut and to graft is to paste. These procedures can work together to move a large group of objects between domains or OUs.
The Active Directory schema—a database of objects, attributes, and attribute syntax—can be extended to support new objects and/or additional object attributes and attribute syntax.
Global catalog servers are servers earmarked to partake in a partial replication process with all domains in the forest. The result of this partial replication is a server with slices of all other domain directory databases. One advantage to having global catalog servers in an enterprise implementation of Windows 2000 is quicker and easier cross-domain lookups.
Active Directory can scale to support millions of objects, with an estimated hard database size limit of 17TB. It includes a new version of DNS—Dynamic DNS—in which resource records may be dynamically updated using the dynamic update protocol. It also supports incremental (partial) zone transfer.
Migrations from previous versions of Windows NT should be scrutinized extensively before execution. All four previous domain models have a boilerplate upgrade path. However, all cases are unique and it's always possible that an exception ends up being a showstopper.
Part II of this book is dedicated to the planning and analysis of the business model in preparation for Windows 2000 and Active Directory.
This exercise demonstrates how to prepare for and install the Active Directory Schema manager. The schema manager is not installed by default, and there are a few requirements you need to meet before you can install the schema manager.
Estimated Time: 10 minutes
Log on to your Windows 2000 domain controller as the administrator.
Insert the Windows 2000 server CD and browse to the i386 (or alpha) directory.
Double-click the adminpak.msi file. Follow the directions on screen to install the Admin Tools.
Click Finish to complete the installation.
Click Start, then Run, and type
mmc /a. This opens the Microsoft Management Console in Administrative mode.Click the Console button, and click Add. Choose the Active Directory Schema snap-in and click Add and then close the Add Stand-Alone Snap-In window.
Click OK to close the Add/Remove Snap-In window. The Active Directory Schema snap-in should appear in the left MMC pane.
Expand the Schema snap-in to reveal object classes and attributes.
Lightweight Directory Access Protocol, or LDAP, is the core Active Directory protocol. Active Directory supports versions 2 and 3 of LDAP. LDAP was derived from the X.500 Directory Access Protocol (DAP) as an alternative to carrying the significant overhead that DAP requires. See "LDAP Is Core." | |
Active Directory is designed around the Domain Name System (DNS) namespace. Careful consideration should be given to naming Active Directory domains, so that they scale at the same rate as the DNS database does. See Support for Open Standards and "Dynamic DNS." | |
Active Directory provides three sets of feature-rich APIs: ADSI, MAPI, and LDAP C API. ADSI provides a set of COM objects to developers for access to the Active Directory database. See "Rich Set of APIs." | |
Objects, object attributes, and attribute syntax. Please see Exercise 1.1 for hands-on experience with the Active Directory schema. See "Extensible Schema." | |
The global catalog server participates in partial replication, a process by which all domains in a domain tree replicate a partially scaled-down model of their active directory database. The global catalog server is then used to provide cross-domain directory queries. See "Global Catalog Servers." | |
Microsoft Dynamic DNS provides the following four key benefits:
See Dynamic DNS for more details. | |
The Microsoft Windows 2000 Private Key infrastructure is based on the MIT Kerberos v5 authentication protocol. Kerberos is used for distributed security within a tree and incorporates the native Windows 2000 ACLs for both public and private key security. See "Public/Private Key Infrastructure." | |
False. You should take a fully synchronized BDC offline and upgrade the PDC first. This ensures that the current SAM database is updated first. Once you verify that all is well, you then upgrade all your BDCs and other computers. See "Microsoft's Recommended Migration Approach." | |
Non-Microsoft DNS servers must support, at the very minimum, SRV resource records. It may be impractical to implement a very large Windows 2000 network without support for dynamic update as well, because you would have to manually update SRV records. See "Non-Microsoft DNS Servers." | |
A directory is a physical storage container that contains from a few up to millions of various types of objects. A directory service provides a function that makes information in the active directory useful. See "'Directory' Defined." |
B, D. Before extending the schema, an administrator must be logged on to the domain as a member of the Schema Admins group. Additionally, the schema needs to be enabled for modification. This is performed on the Change Schema Master window presented by performing a right-click on the Active Directory Schema snap-in and selecting Operations Masters. See "Extensible Schema." | |
A, D, F. Each domain controller in Windows 2000 will contain its very own read/write copy of the Active Directory database for its domain only. This makes option A correct, but option E incorrect. There is no concept of a "multi-master mode." Multi-master is a term used to describe Windows 2000 Active Directory replication. Down-level clients can still log on to the Windows 2000 domain as long as NetBIOS has not been removed. There is a concept of a PDC in Windows 2000. It is an Operations Master role called the PDC emulator. It mimics down-level PDCs so that down-level clients and servers can operate. 99% of the anticipated Active Directory activity will be read and the other 1% will be write. Finally, it is true that some operations, such as schema modifications and domain name generation, are not designed to operate in a multi-master world—so Active Directory maintains single master of operations roles, which are described in detail in Chapter 12. See "Multi-Master Replication Model." | |
A. Pruning and grafting is a process by which you may restructure certain aspects of Active Directory domains. Pruning and grafting is similar to the "cut and paste" technique available in many applications, but only in theory. If you answered drag and drop, give yourself half credit, because pruning and grafting are tools within the Drag and Drop administration initiative. Finally, delete and redo is always an option, but not nearly efficient enough to be considered a solution for this question. See "Drag and Drop Administration." | |
C. ADSI provides developers with a "portal" to Active Directory services and information. MAPI is used to interface with messaging applications, such as Microsoft Exchange. The LDAP C API could be used in this situation, but is not an efficient solution because it operates at a much lower level than ADSI. Open Database Connectivity (ODBC) is used primarily for access to ODBC-compliant database applications, such as Microsoft SQL Server or Access. See "ADSI." | |
D. To be properly resolved by a DNS server, a computer must first be represented by a DNS server host record. Non-dynamic DNS servers must be updated with this information manually. Microsoft Dynamic DNS servers have the capability of allowing dynamic updates from Windows 2000 clients and servers, and from DHCP and WINS servers who can act as a proxy to down-level clients. You can tell if a particular computer has DNS name resolution by pinging a FQDN, such as |
Windows 2000 (and Active Directory) white papers. http://www.microsoft.com/windows2000.
Cone, Boggs, and Perez. Planning for Windows 2000. New Riders, 1999.
Microsoft TechNet Articles.
"Active Directory Logical Structure."
"Aligning Business and IT Goals."
"Business Opportunities with Windows 2000."
"Designing the Active Directory Structure."
"Planning for Windows 2000 in the Enterprise."