Joining a Computer to an Active Directory Domain

In previous posts, I set up a Window Server 2016 instance running Active Directory domain Services. I have also set up another VM, running a basic installation of Windows 10. In this post, I will demonstrate how to join a client computer running Windows 10 to an Active Directory domain.

Computers running Windows 10 Professional, Enterprise, or Education can join AD domains; Windows 10 Home cannot.

First, click the Start button. Then, click on the Settings icon (the gear icon).

The Settings window will open. Click "Accounts."

Click "Access work or school" in the left-hand pane.

In the right-hand pane click the "+ Connect" button.

The account connection wizard will appear. Since we're connecting to a local Active Directory domain, click "Join this device to a local Active Directory domain."

Enter the name of the domain to be joined, then click "Next."

Enter your domain credentials. The account you use does not necessarily have to be a domain administrator account, but it does need to have delegated rights to create computer objects in AD. Click "OK."

If you wish to create a local account on the computer at this time, you can do so here. Enter the account name, and select whether the account will be a Standard User or Administrator, then click "Next" to continue the normal new user setup. In this case, I will instead click "Skip."

The computer will need to reboot in order to finish joining the domain. Click "Restart now."

Once the computer reboots, the login screen will appear slightly different. In the bottom-left of the screen, you will see an option for "Other user" to allow domain accounts to log in, and underneath the password field you can see the name of the domain to which this computer is joined.

Authorizing a DHCP Server with Active Directory

I set up a client VM running Windows 10 to work with my virtual Windows Server 2016 instance. (The installation and setup for Windows 10 is very similar to that of Windows Server, which I've already documented, so please see that post  or this guide on HowToGeek for information on how to do that.)

In the course of doing the first-time setup on the client VM, I noticed that even though a DHCP server is running on the virtual network to which the client is attached, it was still getting a APIPA address.

So, to begin the investigation, I opened my server VM and navigated to the DHCP tab of Server Manager. Then, I right-clicked on my server name, and opened the DHCP Manager. I noticed that both IPv4 and IPv6 scopes showed "down" icons, and when I clicked on IPv4, I saw this message.

As the message informs us, Active Directory requires DHCP servers to be authorized by an AD administrator before it will allow the server to manage IP addresses. This helps prevent scenarios where a rogue DHCP server (whether on a user's home router they brought in, or one set up for a purposeful attack) grants addresses to clients, causing widespread network difficulties.

All we need to do to authorize this server to act as a DHCP server for the Active Directory forest is to right-click on the server in the left pane of DHCP Manager, then click "Authorize" in the context menu. (If I had not been logged in as an AD administrator, I would have been prompted to enter my credentials.)

This change isn't instant; for a minute or so, the scopes remained in the "down" state. I hit F5 to refresh the window, and was relieved to find that the DHCP server was again working.

I returned to the client VM, and found that in the few seconds it took to switch windows it had already acquired an IP address in the range served by my DHCP server. It works!

Setting Up Active Directory Domain Services on Windows Server 2016

In this post, I will be setting up the Active Directory Domain Services (AD DS) on a virtualized instance of Windows Server 2016.

First, open the Add Roles and Features Wizard. Check the box for "Active Directory Domain Services."

 

Once that box is checked, the wizard will let you know that several additional features are required to be installed as part of setting up AD DS. Observe this message, then click "Add Features."

On the Features page, we can see that the features indicated in the previous message are checked; in this screenshot, you can see "Group Policy Management" is checked. Click "Next."

The wizard now describes the uses of AD DS, and indicates that a DNS server must be running on the network for AD to work. I set this up in a previous post, so we will not need to do so now; however, as the wizard states, if no DNS server is available, it will automatically walk you through setting one up on the server. Click "Next."

Confirm that the selections to be installed are correct, then click "Install."

Once the installation completes, a new tab will appear in the left pane of Server Manager, labelled "AD DS". Click this tab.

 

We can now see that the AD DS services are available on this server. However, notice that there is a yellow alert triangle in the top bar of Server Manager (a warning message also appears above the server name). Click the alert triangle/flag icon to view the alert.

Though we have installed the AD DS services on this server, we have still not set it up as a domain controller. Click "Promote this server to a domain controller."

The AD DS Configuration Wizard appears. On this first screen, we have a few options, the one we should choose depending on our current environment:

• If there is an existing domain, and you are adding a new domain controller to it, select the first option.
• If you are adding a new domain to an environment that already has other domains (a forest), select the second option.
• If you are setting up the first domain in this environment, or want to create a new forest, select the third option.

In this post, I am setting up a whole new forest, so I will select that option and enter my root domain name. Complete this screen, then click "Next."

Since I'm creating a new forest and domain, the wizard asks me to choose the functional levels for each. In an environment with other existing clients or servers, you should choose the option that most closely matches the functional level of the existing environment - if your forest uses the Windows Server 2016 functional level, you will only be able to add domain controllers running Windows Server 2016, while if the forest uses Windows Server 2003 functional level, any version of Windows Server newer than 2003 will work.
Since there is only one server in my environment, I'll use Windows Server 2016 to get all of the newest functionality.

The other options on this screen relate to whether or not it should be a DNS server (it is), whether it should hold the Global Catalog, and whether it should be a Read Only Domain Controller (RODC).
The Global Catalog holds a partial copy of all of the AD objects that exist across all of the domain controllers in this domain, which makes searching for objects faster as it avoids needing to query several servers to find things.
A Read Only Domain Controller, as its name suggests, holds a read-only copy of the AD database. This is useful in particular for remote site environments, where it may be more difficult to ensure physical security, and where network bandwidth may be less impressive compared to the main site. As it is read-only, even with physical access an intruder will not be able to make changes that affect the local site or the rest of the domain. Because it allows users to authenticate to a domain controller at their local site, rather than having to do so across a potentially slow link to a DC at the main site, a RODC improves login times.

The final thing to do on this screen is to set a Directory Services Restore Mode (DSRM) password. DSRM is like Safe Mode for Active Directory, and can be used to repair the AD database in case of corruption. Be sure to set this to something secure, and make sure not to forget it.

Complete this screen, then click "Next."

The wizard warns us that it is unable to create a delegation for this DNS server in its authoritative parent zone because such a parent zone cannot be found. According to this page from Microsoft, this is both very common in this VM configuration and not a problem (as, for demonstration purposes, we don't care about authentication from the internet or other domains), so make a mental note and click "OK."

The next screen asks you to set the NetBIOS name for the new domain. Most likely, you should use something similar to the root domain name you entered previously. Enter the NetBIOS domain name, then click "Next."

This screen allows you to choose where AD DS will store its database files, log files, and its SYSVOL share. The AD database contains all of the objects that are part of the domain, the log files are obviously log files, and the SYSVOL share contains scripts and other files that actually implement Group Policy and other management tasks. If you wish, change the default location for each of these, then click "Next."

Finally, we reach the summary screen for the AD DS wizard. Scroll through the text box to confirm that everything is as you desire. If you would like, you can export the script that the wizard will use to create the domain to a PowerShell file so that you can more easily set up more identical instances by clicking "View script." Click "Next."

The wizard will run a check to make sure that your server is healthy and has all of its prerequisites met before beginning the installation. Since we're using the Windows Server 2016 functional level, the wizard warns us that default security settings will prevent weak security algorithms from creating secure sessions, and provides a link to a KB article  with more information.
Another message, a repeat of the DNS delegation warning, can be ignored.
As the wizard warns, after the installation is complete, the server will need to reboot. If all of the prerequisite checks pass, and you are ready to reboot the server, click "Install."

Once the installation nears its end, you will see a message warning that you are about to be signed out. Click "Close." You will be signed out, then the server will reboot.

Once the server comes back up, you may see the message "Please wait for the gpsvc" for several minutes as AD and the Group Policy services initialize themselves for the first time.

Finally, once the installation and configuration completes, you will see the Windows Server 2016 login screen. Note that the username now has the domain's NetBIOS name prepended, as the server is now a member of the domain we've just created. Log in to the server, then wait for Server Manager to open.

Back on the AD DS tab of Server Manager, right-click on the server. As you can see in this screenshot, we now have a multitude of options related to Active Directory. The installation is complete, but we'll still want to create at least one user account so that we can actually work with the domain. Click "Active Directory Users and Computers".

Right-click on "Users", then click on "New > User".

Fill out the form with the new user's information (I'm using my own in this case), then click "Next."

Here, you can set a password for the new user. If you are creating this account for someone else, you can give it something simple like "Password1" and check the top box labelled "User must change password at next logon." Enter a password, select any applicable options, then click "Next."

Confirm that the details are correct, then click "Finish."

In this case, I want to add my newly-created AD account to the Domain Admins group. Right-click on the account, then click "Add to a group..."

Enter the name of the group you wish to add this user to, then click "Check Names." If the name is correct, it will be underlined; if it is close, the wizard will try to guess the correct name; if it is not close to being correct, the wizard will allow you to browse to select the correct group. Once you have a group name underlined, click "OK."

A message will appear to confirm that the user has been added to the group. Click "OK." You now have a domain administrator account that you can use to join clients to the domain, etc.

You may wish to check the DNS Manager to see if a forward lookup zone called "_msdcs.<your domain>" was created. If it was not, create it manually (as a top-level forward lookup zone, not under <your domain>). Then, open Command Prompt and run "net stop netlogon" then "net start netlogon" to create the necessary DNS records. If these are not created automatically or manually, no clients will be able to join to the domain.

Setting up a DNS server on Windows Server 2016

So far, we have a server running Windows Server 2016 that also acts as a DHCP server. Eventually, we'll want to set up Active Directory Domain Services so that we can provide authentication services and manage client computers with Group Policy, but before we can do that, we'll need a DNS server running on our virtual network. In this tutorial, I will be installing the DNS server role on the virtualized server.

First, open the Add Roles and Features wizard. (Please see previous posts for information on how to do this.) Then, check the box for "DNS Server."

When you click this box, a window will pop up to inform you that an additional feature, the "DNS Server Tools" under the Remote Server Administration Tools category, must also be installed. Click the "Add Features" button.

The wizard next gives an explanation of what DNS is and does, and notes that the AD Domain Services requires a DNS server to be running in order to add that role. Click "Next."

The standard installation confirmation dialog appears. Make sure that everything is as you wish, then click "Install."

After installation is complete, there is a new tab on the left-hand column of the Server Manager window, labelled "DNS." Click on it.

On the DNS page of Server Manager, right-click on the server, then click "DNS Manager."

The DNS Manager window will open. As you can see, the DNS server is working, but there are no forward or reverse lookup zones, so nothing will actually be resolved. Right-click on the server, then click "Configure a DNS Server..."

The Configure a DNS Server Wizard appears. Click "Next."

This wizard is very handy because it allows us to set up both forward (URL > IP) and reverse (IP > URL) lookup zones. The wizard says that small networks can get by with forward lookup zones only, but for the sake of experimentation and fun, I'll be configuring both. Select the middle option, then click "Next."

Confirm that you want to create a forward lookup zone, then click "Next."

We can create three types of DNS zones: 

• Primary zones, which exist on this server
• Secondary zones, which exist on another server, which we can copy to this server as a load balancing/fault tolerance measure
• Stub zones, which are like Secondary zones, but only contain information about DNS servers for that zone. This is used as a form of request forwarding that does not require manual updating of DNS server IP addresses, etc. It could be used to allow two different organizations' networks to forward DNS traffic to each other without exposing all of their DNS records (as sharing a Secondary zone would) or manual IP updating with direct forwarding.

In this case, we want a Primary zone. Select the top option, then click "Next."

The zone needs a name to determine for what names the zone will be authoritative. As the dialog mentions, if you already have a domain name for your organization, you could use that, or some permutation thereof. In this case, as I do not have a domain name, I will just use "westbrook.local." Enter your zone name, then click "Next."

If you already have a DNS zone file that you would like to use for this zone, you can choose it, or you can create a new file with a given name. Choose the option you need, then click "Next."

DNS zones can be updated automatically, either securely (recommended) or non-securely (which the wizard explicitly recommends against.) However, to use secure updates, the zone must be integrated with Active Directory, which we don't have set up yet, so in the meantime choose "Do not allow dynamic updates" and click "Next."

The new forward lookup zone is now created. We'll follow a similar process to set up an associated reverse lookup zone. Click "Next."

We'll be creating a Primary reverse lookup zone. Select that option, then click "Next."

Right now, we'll set up an IPv4 reverse lookup zone. Select that, then click "Next."

Reverse lookup zones translate IP addresses into URLs, so we need to specify the network segment for which this zone is authoritative. Our network is a simple local one, so I'll enter 192.168.1. Enter your network ID, then click "Next."

If you want to use a prebuilt record file for this zone, you may. Choose the appropriate option, then click "Next."

Choose the type of dynamic updating you want to use, if any, then click "Next."

If we wish, we can now set up DNS forwarding. This allows us to spread out the workload of domain name resolution across many different servers - one server could serve "westbrook.local", while another might serve "westbrook.com", etc. I've chosen to forward DNS requests to Google's DNS servers, 8.8.8.8 and 8.8.4.4. Enter your forwarding servers, if any, then click "Next."

With that, the DNS server configuration wizard is complete. Click "Finish."

As you can see in this screenshot, the new DNS zones we have created are in the "Running" state, and should resolve any "westbrook.local" requests made by clients connected to the virtual network.