In a previous series of Daily Drill Downs, I introduced you to Microsoft’s Active Directory (AD). Now that you have some background in Active Directory’s purpose and structure, you should be ready to start deploying domain controllers. In this Daily Drill Down, I’ll show you how to install and configure Active Directory.
If you haven’t already done so, spend the time to fully evaluate your domain requirements and design your domain structure across the enterprise. You’ll need a complete picture of the structure you want to achieve before starting the AD installation process.
The installation process requires several steps:
- Defining the domain structure and determining server properties
- Installing the computer that will serve as the first domain controller (DC) in the root domain
- Promoting the computer to a DC, making it the root DC
- Configuring the DC in DNS (and/or WINS)
- Configuring the initial organizational units (OUs)
- Delegating administration within the domain
- Ensuring security and disaster recovery
First, decide the NetBIOS name for the server. The NetBIOS name will be used to construct the computer’s DNS name and will be prepended to the domain name to form the machine’s Fully Qualified Distinguished Name(FQDN). In general, you should choose a descriptive but short name. For example, you might assign the name DC00, identifying the computer as the first domain controller.
Next, determine the server’s IP address(es). You don’t necessarily have to assign the IP address that the server will have when in production, since you can change the address later. However, you won’t be able to install Active Directory unless the computer is connected to a network, so at the minimum, the computer must be connected to a hub. Select an available IP address from the subnet on which the computer will be installed, an address from a reserved pool in the subnet, or a non-conflicting private IP address. Once the server is fully tested, you can change the IP address and place it on its target subnet.
When you install the server, Setup asks you to join either a domain or a workgroup. Choose a workgroup name you’ll use during installation. The workgroup name must be different from the domain name you’ll eventually use, so plan accordingly. The workgroup assignment is temporary, so the workgroup name is irrelevant, other than it must not match the domain name.
Decide which services you’ll need to install on the server. You might choose to install only a minimum set initially to ensure that the system is stable. Then, add services one at a time, allowing an appropriate testing period before adding the next service. If you intend to use Terminal Services for remote administration, install Terminal Services during initial setup and choose Remote Administration mode.
Rather than install the AD and promote the machine to a DC right away, you should ensure that the installation is stable by letting it run for a few weeks. During the burn-in period, use the server in various capacities for testing purposes, leaving the system up without rebooting if possible. Identify and fix any problems that come along.
One final item: Make sure you have an NTFS partition with sufficient free space to accommodate the AD’s files. You’ll need at least 1 GB but much more if your AD will encompass several domains, many users, and so on. Keep in mind that the NTFS volume must be one created with Windows 2000’s NTFS 5.0.
Because Active Directory relies on the Windows 2000 DNS to locate domain controllers, you’ll need to deploy at least one Windows 2000 DNS server. The DNS service can reside on a DC or on a member server, although there are advantages to installing the DNS service on a DC. The first and perhaps most obvious advantage is you don’t duplicate hardware—a cost savings. The ability to replicate the DNS data across the domain is another important consideration for installing the DNS service on a DC.
You can install and configure DNS on the first DC prior to running the Active Directory Wizard to install the AD or as part of the AD installation process (see Figure A). The latter option is particularly useful when you’re setting up your first DC and no DNS server is currently defined.
|You can install and configure DNS as part of the AD installation process.|
Installing the DC for the root domains
With your domain structure in hand and other design questions answered, start by installing the first domain controller in the root domain (the first domain in the forest). The root domain is the pattern for all other domains in the forest, defining the schema, configuration, and global catalog for the forest. The root domain defines the naming structure for the first domain, so take the time to fully consider how the domain name you select will impact child domains and users in the domain.
When you’re ready to install Active Directory, run the Configure Your Server Wizard from the Administrative Tools folder. Select Active Directory from the left frame, and then scroll down and select Start The Active Directory Wizard.
If you don’t want to use the wizard or the GUI, you can also run DCPROMO from a console prompt.
The wizard will prompt you for the domain type. Select Domain Controller For A New Domain. The wizard will then prompt you for the following additional information:
- Create Tree Or Child Domain: Select the option to create a new domain tree since this is the first domain in the forest. When you install other DCs in the same forest, you’ll use the child domain option instead.
- Create Or Join Forest: This is the first domain, so choose the option to create a new domain forest. As you create other DCs, you’ll choose to join an existing forest.
- New Domain Name: Specify the DNS name of the domain, such as techrepublic.com.
- NetBIOS Domain Name: In general, you should accept the default NetBIOS domain name, which the wizard determines from the DNS domain name you specified in the previous dialog.
- Database And Log Locations: Specify the locations for the AD database and log files. If you have multiple SCSI drives, you’ll get better performance by placing the database and log files on different drives.
- Shared System Volume: Specify the location for the Sysvol folder, which is used for replication.
- Permissions: Some services such as the NT Remote Access Service need to read information from the AD (user account properties, for example). If you have Windows NT Servers in the network that host these types of services, choose Permissions Compatible With Pre-Windows 2000 Servers. If all servers in the network will be running Windows 2000 or you upgraded the dependent servers to Windows 2000 before installing the Windows 2000 DC, you can use the second option.
- Directory Services Restore Mode Administrator Password: Specify the password to use when starting a DC in Restore mode for the purpose of restoring the system state data.
If yours is a simple network topology, then the next step might be as simple as setting up one other DC in the domain for fault tolerance and redundancy, then starting the process of creating user accounts. In a complex topology, however, you’ll probably end up creating additional DCs in the root domain and then child domains, sites, OUs, and so on.
A site is an AD object that represents a network location or group of network locations, identified by one or more TCP/IP network segments. Sites enable Windows 2000 to design a replication topology and allow you to structure your directory services along physical network boundaries.
Windows 2000 automatically creates a default site named Default-First-Site-Name when you install the first domain controller, placing the new DC in that site. Although you could use the site as is, you’ll probably want to change the name of the site after installing the DC, or even create a new site and then move the DC into the new site, abandoning the original.
When you add a new DC on the same subnet as an existing site, Windows 2000 automatically places the DC in the site associated with the subnet. Perhaps you installed the DC with a private subnet for testing and now need to apply the working IP address. Or, perhaps you need to ship the server to a different location for installation. Whatever the case, you need to create a site and place the DC in the site.
To create a site, open the Active Directory Sites And Services console from the Administrative Tools folder. Right-click the Site folder in the left pane and choose New Site. Select the desired site link object for the site, specify a name, and click OK. Each new site you create contains a Servers container that holds the DCs that belong to the site. Each site also contains two other objects:
- Licensing Site Settings: These properties identify the computer and domain that licenses the site.
- NTDS Site Settings: Use these settings to change the replication frequency and specify the DC and site from which the directory is replicated. Changing these settings overrides the default settings and is required only when you need a non-standard replication topology based on your network structure or related factors. Keep in mind that the settings are one way and that you’ll need to configure the other end of the connection to provide full replication.
Next, create subnet objects to define the subnets in which DCs will reside. Right-click the Subnets folder in the left pane and choose New Subnet. In the resulting dialog box, specify the IP address and subnet mask that define the subnet, then select the site object that applies to the specified subnet, as shown in Figure B.
|Create a site by defining the subnet for the site and the site object that applies to the subnet.|
Now create additional site link objects if needed. Expand Inter-Site Transports, and then right-click either IP or SMTP, as appropriate, and select New Site Link. Add and remove sites to and from the link as needed. A site link must contain at least two sites.
Finally, create site link bridge objects if required. Right-click the transport and choose New Site Link Bridge. The process for creating a site link bridge is nearly identical to creating a site link, with the exception that you select site links rather than sites.
With your subnets and sites defined, turn your attention to creating Organizational Units (OUs). As a review, OUs are container objects with which you can partition a domain. OUs are extremely useful for assigning security policies and delegating administrative authority. Keep in mind that OUs are not security principals and you can’t use them to grant or deny access to resources. However, you can apply security to groups and users by placing them in specific OUs with the desired security policies. You can create nested OUs to accommodate network or organizational structure, but keep the nesting structure relatively shallow for simplicity. Also, bear in mind that OUs are administrative tools, not end-user tools, so structure the OUs accordingly.
To create OUs, open the Active Directory Users and Computers console from the Administrative Tools folder. Right-click the domain in which you want to create the OU, and choose New | Organizational Unit. Specify the name for the OU and click OK.
While you can certainly delegate administration for your OUs at a later time, you should consider delegating the OUs immediately after you create them. Delegating administration early in the process enables delegated administrators to begin working immediately on the OU, which is particularly important in very complex networks where a team approach is the only practical way to develop the domain structure.
Delegating an OU is a simple process, thanks to the Delegate Control Wizard. First, make sure that the desired security accounts or groups are in place. Then in the Active Directory Users And Computers console, right-click the OU and choose Delegate Control. The wizard first prompts you for the accounts or groups to which you want to delegate OU control. You then specify which tasks to delegate from a list of predefined tasks or create a custom task to delegate (Figure C). Use the custom task option if you need more granular control over delegation of OU tasks.
|You can choose from a set of predefined tasks to delegate or design your own delegation criteria.|
Setting up other global catalog servers
As we explained previously, the global catalog (GC) contains a full writeable replica of all objects in the AD for its host domain. It also contains a partial, read-only replica of the other domains in the forest. This read-only replica contains a copy of all objects in the domain forest, minus all but the attributes useful for searching. In essence, the GC serves as a flat database of the objects in the forest that enables quick location of any object in the directory—it’s the directory’s directory. The GC is built automatically by the AD’s replication mechanisms.
The GC handles logon authority for its host domain and is a critical AD component. It’s therefore extremely important to provide redundancy of the GC across the enterprise. A network segment that is subject to disconnection from the site where the GC is hosted should have its own GC server. If the network connection is down and no GC server is available, clients will have difficulty logging on. Native-mode DCs require access to the GC to determine complete group membership access levels for each user, and if the GC is unavailable, the DC denies logon. So, having spare GC servers is crucial.
To configure a computer as a GC server, first install it as a DC. Open the Active Directory Sites And Services console, expand the target site to locate the DC in the Servers node, and then expand the server. Right-click NTDS Settings and choose Properties. Select the Global Catalog check box and click OK.
Fine-tuning AD security
At this point, you should review everything you’ve done and complete any missed tasks. Flesh out the structure of your AD installation to add other domains, sites, OUs, groups, accounts, and so on. Then, turn your attention to applying security to the AD. Each object in the AD provides an Access Control List (ACL) that controls access to the object.
You need to take the time to perform an exhaustive review of security settings throughout the AD, verifying security for each object. Open an object’s Property sheet, click the Security tab, and then assign access as needed.
Where to go from here
Active Directory is a complex topic, particularly in the context of a very large enterprise with many domains. If you need additional resources to help you define your domain structure, create DCs, define sites and OUs, delegate administration, and perform other AD design tasks, check out these resources:
- Microsoft Windows 2000 Resource Kit Deployment Planning Guide
- Microsoft Windows 2000 Server Help documentation
- Microsoft TechNet
- Windows 2000 Server Bible, from IDG Books
Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota WebWorks, a Midwest-based Web development firm.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.