What is a domain?

Let’s start with the basic concepts and then build on them. A domain in a Microsoft network is commonly referred to as an Active Directory Domain Services (AD DS) domain. Each AD DS domain has its own database of objects within it. An object could be a user, a group, a computer, or even a printer.

AD domains are organized into a hierarchical structure with the forest being the highest level, followed by domains and organizational units (OUs). Each forest can have multiple domains, and each domain can have multiple OUs.

Forests and domains and OUs, oh my!

I’m throwing around a lot of terminology here, so let me define some things before moving on:

• Organizational units: OUs are containers for objects stored in Active Directory. They’re typically used to group like objects together — for example, all user accounts for people in the accounting department, or every computer on the second floor of a building. By grouping like items together, it can be simpler to manage these objects because it’s likely they’ll have similar settings or configurations.
• Domains: Think of a domain as a security boundary. A domain contains its own database of the objects it contains. All those objects share that database and any security policies that are assigned within the domain. Additionally, a domain may be set to trust another domain by creating a trust relationship, which may allow users in one domain to access resources in another domain.
• Domain trees: A domain tree is simply a collection of domains. For instance, you may have the domain tree namespace set to sometestorg.com, and the domains underneath that tree would be something along the lines of accounting.sometestorg.com or hr.sometestorg.com. The domains share the namespace with the domain tree.
• Forests: An Active Directory forest is the top-level object. It stores the entirety of Active Directory including all the trees and domains. The first domain created in a forest is referred to as a forest root domain. It will typically share the name of the forest.
• Schema: The Active Directory schema is similar to a dictionary in that it contains definitions. It contains the definition of every object class and every attribute that can be used by an Active Directory object.

Depending on the organization where you work, you may have a small instance of Active Directory that has only one forest and one domain, or you may work for a large company with multiple forests and multiple domains.

You may be asking why you would want to have more than one forest. It's more management overhead, right? Yes, it absolutely is. However, if you work in an environment where separating security boundaries is crucial, then multiple forests are your best bet. A common example is separating the corporate network from the production network. The corporate forest is used to manage corporate workstations where email and Internet are accessed. The production forest is used only to manage authentication traffic to servers or network devices. By separating the forests, and by extension the security boundaries of these two networks, you safeguard the production environment from the potentially malware-laced corporate environment.

Understanding privileged domain groups

When you create an Active Directory domain, several administrative groups are created by default. I've known a few administrators who simply put their accounts into the Enterprise Admins group and never looked back. As a system admin, you really want to enforce the concept of least privilege, meaning that people should have the permissions to do what they need to do, but nothing more. The Enterprise Admins group is a very privileged group to be in and shouldn’t be the solution to all your permissions woes.

Table 5-1 covers the various groups and what permissions you get when you’re placed into them.

Examining Flexible Single Master Operation roles on domain controllers

When Active Directory first came about, there were some definite challenges. Through the years, Microsoft continued to improve on how domain controllers work with Active Directory. It came up with the idea of Flexible Single Master Operation (FSMO). By using FSMO roles, domain controllers don’t fight over who gets to make changes, nor do you have to be as concerned about your main domain controller going down because the roles it was taking care of can be moved to another domain controller.

Here are the FSMO roles you see in today’s domain controllers and what each of them does:

• Forest wide:
  • Schema Master: Manages the read/write copy of your AD schema.
  • Domain Naming Master: Ensures that you don’t create domains with the same name as an existing domain.
• Domain wide:
  • RID Master: Every security principal in Active Directory has a security identifier (SID). That SID is made up of the domain SID, which is the same for all systems in the same domain, and the relative ID (RID), which is unique for each security principal in that domain. The RID Master assigns blocks of SIDs to domain controllers so that they can issue them.
  • PDC Emulator: PDC used to stand for Primary Domain Controller, which was used in environments running Windows NT 4.0 and earlier. The PDC Emulator was introduced to provide support for legacy systems, and it still performs important functions for modern systems. The PDC Emulator is the authoritative domain controller. It handles authentication, password changes, authentication failures and Group Policy Objects and sets the correct time for the entire domain. Next time you’re late for a meeting, blame your PDC emulator!
  • Infrastructure Master: The Infrastructure Master is essentially the translator between domains. It can convert SIDs, globally unique identifiers (GUIDs), and distinguished names (DNs) between domains so that Domain1 understands what Domain2 is requesting. This allows users to access resources on other domains, not just the domain that they exist and authenticate to.

One last important conversation outside of roles is the Global Catalog. A Global Catalog server stores records for all the objects in all the domains in the forest. A domain controller keeps a fully writeable copy of its own Global Catalog, and a read-only copy from the other domains in the same forest. This allows you to search for objects in Active Directory without having to go to each individual domain to do it.

Functional levels

Functional levels are used to tell domain controllers which features can be enabled at the forest or domain levels. With each new version of Active Directory, new features are added that you may want to take advantage of. If you’re creating a new installation of Active Directory, choose the highest functional levels available.

Functional levels can prevent a server from becoming a domain controller if its functional level is too low. Functional levels can be set at the forest level or the domain level. Domains can run with a higher functional level than the forest they’re in, but they can’t run at a lower functional level than the forest.

When you raise the functional level, you can’t add domain controllers that are set to a lower functional level. It’s also important to note that the domain functional level can be equal to or higher than the forest functional level, but it can’t be below it.

In older server operating systems, raising the functional level was a one-time deal. There was no nice way to back out the change if it caused problems. That is no longer the case. You can revert back to an older version with PowerShell as long as the rollback is supported, and none of the new features has been enabled that require the newer functional level. If you did enable them, you have to disable them before you can roll back.

Forest functional level

In order to raise the forest functional level, you have to be a member of the Enterprise Admin group. You must raise the forest functional level from the domain controller that runs the Schema Master role. You can’t do it from the other domain controllers.

To check your current forest functional level, open PowerShell and run the command Get-ADForest.

Domain functional level

In order to raise the domain functional level, you have to be a member of the Domain Admin group. You must raise the domain functional level on the domain controller that runs the PDC Emulator role. You can’t do it from the other domain controllers.

To check your current domain functional level, open PowerShell and run the command Get-ADDomain.

Checking for unsupported roles and features

Microsoft doesn’t publish a list of roles and features that are incompatible with AD DS. If you’re installing AD DS on a system that has other roles and features, there two approaches you can take:

• If the roles and features are no longer in use, uninstall them.
• If the roles and features are in use, back up the system, uninstall the roles and features, install AD DS, and re-install the other roles and features.

The best and safest practice is to install AD DS on a freshly built server, but if you find that you have no choice (this often happens in smaller companies that can’t afford multiple systems), follow the preceding steps.

Installing and configuring Domain Name System

DNS is responsible for resolving easy-to-remember hostnames to not-so-easy-to-remember IP addresses. It’s a requirement for Active Directory to function properly. If DNS is not installed on the system on which you’ll be installing AD DS, but it is available in your environment, then you’re good to go. If DNS does not exist in your environment, you need to install it.

You can install the DNS server role by itself, or you can install it as part of the configuration tasks when you install AD DS. I’m going to show you how to install DNS by itself.

Before you install the DNS role, ensure that your server has a static IP address. If it doesn’t, you’ll be presented with a warning while installing the role. You’ll be allowed to continue with the installation, but your clients could lose connection to the DNS server if the IP address changes.

Installing and configuring Dynamic Host Configuration Protocol

Installing DHCP is the next step on your journey. DHCP is responsible for assigning available IP addresses to systems on your network. This was a huge improvement over having to manually track IP addresses in a spreadsheet like you used to have to do. The DHCP client is enabled on the majority of systems, workstations, and servers. If a system needs a static IP address, like the infrastructure services I’m discussing right now (AD DS, DNS, DHCP), for example, that IP address should be set as a reservation on the DHCP server so that it doesn’t issue an IP address that is already in use.

Installing Active Directory Domain Services

With most things in Windows, you can install this role through the graphical user interface (GUI) or through PowerShell. In this section, I show you how to install this through the GUI, but I point out to you where you can get the PowerShell to rerun this same command if you’re configuring multiple domain controllers.

1. From Server Manager, click Manage and then click Add Roles and Features.
2. On the Before You Begin screen, click Next.
3. On the Select Installation Type screen, click Next.
4. On the Select Destination Server screen, click Next.
5. On the Select Server Roles screen, select Active Directory Domain Services.
6. Click Add Features in the dialog box that pops up.
7. Click Next.
8. On the Select Features screen, click Next.
9. On the Active Directory Domain Services screen, click Next.

10. Click Install.

    Do you have more domain controllers to build? After you’ve installed AD DS, the screen has an Export Configuration Settings link at the bottom. Click this link and save the XML file it generates. When you want to use it to create another domain controller, simply use PowerShell to point the installer to the XML file:

    Install-WindowsFeature –ConfigurationFilePath <path and name of file>

11. Click Close after the installation is complete.

Configuring Active Directory Domain Services

After AD DS is installed, the next natural step is to configure it so that your server can begin its life as a domain controller. Follow these steps:

1. From Server Manager, click the flag, and then click Promote This Server to a Domain Controller, as shown in Figure 5-7.

   

2. On the Deployment Configuration screen, select Add a New Forest.

   There are three options when promoting a server to domain controller:

   • Add a New Forest is typically used when there is no existing AD infrastructure.
   • Add a New Domain to an Existing Forest is used when creating domains other than the forest root domain. As you may imagine, this option is used if there is existing AD infrastructure in place.
   • Add a Domain Controller to an Existing Domain does exactly what it says. You aren’t creating a forest or a domain; you’re just adding a new domain controller.
3. Enter the root domain name, and click Next.

4. On the Domain Controller Options screen, select the functional levels you determined you needed earlier, and then click Next.

   Leave Domain Name System (DNS) and Global Catalog selected. Enter a restore password and save it somewhere you can get to it; if AD ever has to be restored, you need this password to recover.

5. On the next DNS Options screen, click Next.
6. On the Additional Options screen, click Next.
7. On the Paths screen, accept the default locations and click Next.

8. On the Review Options screen, click Next.

   If you’re installing multiple domain controllers, you can click the View script button and see the PowerShell script for the same setup.

   On the Prerequisite Check screen, it’s common to have a few warnings. As long as you have a message at the top that says “All prerequisite checks passed successfully,” you’re good to go. See Figure 5-8 for an example.

9. Click Install.

   After AD DS is installed, the server will automatically restart, and you’ll be able to log in as the domain administrator account. This will initially use the same password as the local admin account on the server. Be sure to change it.

Converting your DNS Zone to an Active Directory Integrated Zone

When you set up DNS earlier in this chapter, you created the zones but chose manual updates rather than dynamic. Now that the DNS zone is associated with Active Directory, you can go back, integrate the DNS zones with Active Directory, and select secure dynamic updates.

Making your DNS zone and Active Directory integrated zone gives you a multi-master environment where any domain controller that is running DNS can update zones as long as they’re an authoritative server for that zone. Zone data is replicated through Active Directory rather than through the traditional zone transfer method. After you’ve chosen to make your zone and Active Directory integrated zone, you can also enable secure dynamic updates. This allows you to control which systems can update record names, as well as keep unauthorized systems from overwriting names in DNS.

Follow these steps to convert your zone to an Active Directory integrated zone and how to enable secure dynamic updates:

1. From Server Manager, click Tools and then click DNS.

2. Expand the server name, and then expand Forward Lookup Zones.

   You should see the zone you created earlier.

3. Right-click the zone and choose Properties.
4. On the General tab, under Type: Primary, click the Change button.
5. With Primary still selected, check the Store the Zone in Active Directory check box and click OK.
6. When you’re asked if you want the zone to be Active Directory integrated, click Yes.

7. Under Dynamic updates, select Secure Only.

   See Figure 5-9 for an example of how your screen should look at this point.

8. Click Apply and then click OK.

9. Expand Reverse Lookup Zones.

   You should see the zone you created earlier.

10. Right-click the zone and choose Properties.
11. On the General tab, under Type: Primary, click the Change button.

    

12. With Primary still selected, check Store the Zone in Active Directory check box and click OK.
13. When you’re asked if you want the zone to be Active Directory integrated, click Yes.

14. Under Dynamic updates, select Secure Only.

    See Figure 5-9 for an example of how your screen should look at this point. Keep in mind that Figure 5-9 is from the Forward Lookup Zone, however the settings themselves are identical.

15. Click Apply, and then click OK.

16. Under Forward Lookup Zones, create the record for this server.

    Future systems should pop up automatically now.

17. Right-click your domain name under Forward Lookup Zones and select New Host (A or AAAA).

    Host records are used by the DNS server to map hostnames to IP addresses. A records match hostnames to IPv4 addresses, while AAAA records map hostnames to IPv6 addresses.

18. Under Name, enter the name of your system.
19. Under IP Address, enter the IP address of the system.

20. Check the Create Associated Pointer (PTR) Record check box.

    This creates a matching entry in the Reverse Lookup Zone.

21. Click Add Host.
22. Click OK on the confirmation box.
23. Click Done in the New Host box.

Now you’re all set. Active Directory is installed, and you’re allowing dynamic updates in DNS in a secure fashion. You created a DNS record for your server. You can test at this point to make sure that name resolution is working properly. Here are the steps to test name resolution:

1. Right-click the Start menu and choose Windows PowerShell.

2. Type nslookup <servername> as shown in Figure 5-10.

   If DNS is working properly, it should return the IP address of the server name that you put in.

As you can see, integrating DNS after the fact can be rather time consuming. You can install it at the same time as Active Directory and save yourself quite a bit of the configuration work. However, now you’ve seen it done the long way, so the shorter way will be much simpler.

Authorizing your DHCP Server for your Active Directory environment

There’s one last thing you need to do before you can use DHCP properly. Earlier, you installed DHCP and then set up a scope. Now that this server is a domain controller, you need to authorize DHCP in Active Directory so it can start handing out IP addresses for domain joined systems. By authorizing your DHCP server, you prevent rogue DHCP servers from appearing on your network. Rogue DHCP servers can cause a denial of service attack. To authorize your DHCP server, follow these steps:

1. Starting with Server Manager, choose Tools ⇒  DHCP.
2. Right-click the server’s name and select Authorize.

3. Click Action and then click Refresh.

   The red downward-facing arrow that was on IPv4 should be a green check mark now.

Now your DHCP is configured to work with your Active Directory domain. Anytime you stand up new DHCP servers and you want them to work with your Active Directory environment, you need to authorize them.

Configuring the user accounts

Now that Active Directory is installed, you may want to start creating user accounts. The main purpose of Active Directory is for authentication after all! Here’s how to create your first user account in Active Directory:

1. From Server Manager, choose Tools ⇒  Active Directory Users and Computers.
2. Expand your domain name by clicking the arrow next to it.

3. Click Users (this is the Users OU) to select it.

   You see the built-in accounts and groups.

4. Right-click Users, and choose New ⇒  User, as shown in Figure 5-11.

5. Fill in the First Name and Last Name fields.

   Notice that Full Name fills in automatically with what you typed.

6. Enter what you want the user’s login name to be.

   In my example, for John Smith, I’m creating a username of jsmith (see Figure 5-12).

   

   

7. Click Next.
8. Set the temporary password for the user.
9. Type it in again in the Confirm Password field.
10. Leave the User Must Change Password at Next Logon box checked and click Next.
11. Click Finish.
12. Double-click the new user, John Smith.

13. Click the Member Of tab.

    You see that John Smith is a member of Domain Users.

    Let’s say that John will be managing our DNS and DHCP servers.

14. Click Add and type DnsAdmins and then click OK.
15. Click Add again and type DHCP Administrators and then click OK.
16. Click OK once more to close out of John’s configuration.

Sharing resources on a domain

Sharing resources on the domain is pretty similar to sharing resources off the domain. When working in an Active Directory domain, the best way to manage access to resources is to use groups.

Let’s create a group called File Share Users, add John Smith to it, and then assign it permissions on a folder share. Follow these steps:

1. Right-click the Users OU, and choose New ⇒  Group.
2. Enter a Group Name, and then click OK.
3. Double-click the new group (in my case, that’s File Share Users) and click the Members tab.
4. Click Add.
5. Type John Smith and then click OK.
6. Click OK once more to exit out of the group’s configuration screen.
7. Click the File Explorer icon in the bottom of the screen (it looks like a folder).
8. Click This PC and determine which volume you want to create this folder share on.

9. Double-click the volume to open it.

   In my example, I am just going to use the C: volume for the folder.

10. Right-click the blank space and choose New ⇒  Folder.
11. Name the folder Files.
12. Right-click the Files folder and choose Give Access To ⇒  Specific People.

13. In the box, type the name of the group you created earlier (in my case, File Share Users), and then click Add.

    The security group is added with read permissions.

14. Click the arrow next to Read, and choose Read/Write, as shown in Figure 5-13.
15. Click Share.
16. On the Your Folder Is Shared screen, click Done.

When a user in the security group wants to access the share that you just created, all he has to do is the following:

1. Click the Start menu.

2. Type \servernamesharename.

   In my case, this is \server2022-dcFiles.

3. Press Enter.

   This takes the user to the shared folder.

The great thing about this approach is that new users only need to be added to the security group File Share Users, and they have read/write access to the folder share that you created.

Joining clients to the domain

The last step on this journey is, of course, joining other systems to the domain so that you can then authenticate with domain credentials rather than local credentials. In this section, I cover doing this in both Server with Desktop Experience and Server Core.

By default, any member of the Authenticated Users group can add a workstation to an Active Directory domain. Members in the Authenticated Users group can add up to ten workstations. (This should be changed depending on your organization’s policies.) It can be adjusted domain wide in the Default Domain Controllers Policy in the Group Policy Management Console, located under Computer Configuration, then Policies, then Windows Settings, then Security Settings, then Local Policies, and then User Rights Assignment. Double-click Add Workstations to Domain. Add the security group you want to use to allow systems to be added to the domain (I’ve often seen Domain Administrators used here) and remove Authenticated Users.