Using AD DS to organize your network

There is not a single tool that is used to manage all facets of Active Directory. Since it is such an expansive technology, our configuration of the directory is spread across a number of different management consoles. Let's take a look at each of them, and a couple of the most common tasks that you will be performing inside these tools. Any of these management consoles can be launched from any of your domain controller servers, and just like we looked at in a previous chapter, the easiest way to launch these consoles are right from the Tools menu in the upper-right corner of Server Manager.

Active Directory Users and Computers

I'll start with the tool that is alphabetically last in the list of our Active Directory tools, because this is by far the one which the everyday server administrator will use most often. AD Users and Computers is the console from which all of the user accounts and computer accounts are created and managed. Open it up, and you will see the name of your domain listed in the left column. Expand your domain name, and you see a number of folders listed here. If you are opening this on an existing domain controller in a well-grown network, you may have pages and pages of folders listed here. If this is a new environment, there are only a handful. The most important to point out there are Computers and Users. As common sense would dictate, these are the default containers in which new computer accounts and user accounts that join the domain will be located.

While this window looks quite a bit like File Explorer with a tree of folders, these "folders" really aren't folders at all. Each manila colored folder icon that you see here is known as an Organizational Unit (OU). OUs are the structural containers that we use inside Active Directory in order to organize our objects and keep them all in senseful places. Just like with folders on a file server, you can create your own hierarchy of organizational units here, in order to sort and manipulate the location inside Active Directory of all your domain-joined network objects and devices. In the following screenshot, you can see that instead of having just a plain Users and Computers OUs, I have created some new OUs including subcategories so that as I grow my environment, I will have a more structured and organized directory.

User accounts

Now that we have some OUs ready to structure our objects, let's create a new user. Say we have a new Server Administrator coming onboard, and we need to get him an Active Directory login so that he can start his job. Simply find the appropriate OU for his account to reside within, right-click on the OU, and navigate to New | User. We are then presented with an information gathering screen about all the things that AD needs in order to create this new account.

When finished, our new admin will be able to utilize his new username and password in order to log in to computers and servers on the network, within the security boundaries we have established on those machines, of course. But that is another topic for another chapter.

Security Groups

Another useful unit of organization inside Active Directory is Security Groups. We can do quite a bit of distinguishing between different types and kinds of users and computer accounts using organizational units, but what about when we need a little cross-contamination in this structure? Perhaps we have an employee that handles some HR and some accounting responsibilities. Maybe it is more likely that we have configured file and folder permissions on our file servers so that only people who are part of certain groups have access to read and write into particular folders. Susie from HR needs to have access to the payroll folder, but Jim from HR does not. By creating Security Groups inside Active Directory, we enable the adding and removing of specific user accounts, computer accounts, or even other groups so that we can granularly define access to our resources. You create new groups in the same way that you create user accounts, by choosing the OU where you want the new group to reside, then right-clicking on that OU and navigating to New | Group. Once your group has been created, right-click on it and head into Properties. You can then click on the Members tab; this is where you add in all of the users that you want to be a part of this new group.

Prestaging computer accounts

While it is very common to utilize Active Directory Users and Computers for creating new user accounts, it is far less common to even think about opening this tool when joining new computers to your domain. This is because the way that the majority of domains are configured, new computers are allowed to the join the domain without any kind of prestaging. In other words, as long as someone knows a username and password that has administrative rights within the domain, they can sit down at any computer connected to the network and walk through the domain-join process on that local computer. It will successfully join the domain, and Active Directory will create a new computer object for it automatically. These auto-generating computer objects place themselves inside the default Computers OU, so in many networks if you click on that Computers OU, you will see a number of different machines listed, and they might even be a mix of both desktop computers and servers that were recently joined to the domain and haven't been moved to an appropriate, more specific OU yet. In my growing lab environment, I recently joined a client computer called Win10 and a couple of servers called CA1 and DC2 to the domain.

I did nothing in Active Directory prior to joining these machines to the domain, and so you can see that the new computer objects are still sitting inside that default Computers container.

Allowing new computer accounts to place themselves inside the default Computers OU is generally not a big problem for client systems, but if you allow servers to be autogenerated in that folder, it can cause you big issues. Many companies have security policies in place across the network, and these policies are often created in a way that they will be automatically applied to any computer account residing in one of the generalized OUs. Using security policies can be a great way to lock down parts of client machines that the user doesn't need to access or utilize, but if you inadvertently cause these "lockdown" policies to apply to your new servers as soon as they join the domain, you can effectively break the server before you even start configuring it. Trust me, I've done it. And unfortunately your new server accounts that get added to Active Directory will be identified and categorized the same as any client workstation that is added to the domain, so you cannot specify a different default container for servers simply because they are a server and not a regular workstation.

So what can be done to alleviate this potential problem? Prestaging the accounts for your new servers. You can even prestage all new computer accounts as a matter of principle, but I typically only see that requirement in large enterprises. Prestaging a computer account is very much like creating a new user account. Prior to joining the computer to the domain, you create the account for it inside Active Directory.

By accomplishing the creation of the object before the domain-join process, you get to choose which OU the computer will reside in when it joins the domain. You can then ensure that this is an OU which will or will not receive the security settings and policies that you intend to have in place on this new computer or server. I highly recommend prestaging all computer accounts in Active Directory for any new servers that you bring online. If you make it a practice, even if it's not absolutely required all the time, you will create a good habit that may someday save you from having to rebuild a server that you broke simply by joining it to your domain.

Active Directory Domains and Trusts

This tool is generally only used in larger environments that have more than one domain within the same network. A company may utilize multiple domain names in order to segregate resources or services, or for better organizational structure of their servers and namespaces within the company. There is also another tier in the hierarchical structure of Active Directory that we haven't talked about, and that is called a forest. The forest is basically the top level of your Active Directory structure, with domains and subdomains coming in under that forest umbrella. Another way to think of the forest is the boundary of your AD structure. If you have multiple domains beneath a single forest, it does not necessarily mean that those domains trust each other. So users from one domain may or may not have permissions to access resources on one of the other domains, based on the level of trust that exists between those domains. When you have a domain and are adding child domains under it, there are trusts placed automatically between those domains, but if you have a need to merge some domains together in a way other than the default permissions, Active Directory Domains and Trusts is the management tool you use in order to establish and modify those trust permissions.

Growing organizations often find themselves in a position where they need to regularly manage domain trusts as a result of business acquisitions. If Contoso acquires Fabrikam, and both companies have fully functional domain environments, it is often advantageous to work through an extended migration process in bringing the Fabrikam employees over to Contoso's Active Directory, rather than suffer all the loss associated with simply turning off Fabrikam's network. So for a certain period of time, you would want to run both domains simultaneously, and could establish a trust between those domains in order to make that possible.

If you find yourself in a position where a domain migration of any sort is necessary, there is a tool available that you may want to try out. It is called the Active Directory Migration Tool (ADMT) and can be very useful in situations like the one described earlier. If you are interested in taking a closer look at this tool, you can download it from the link https://www.microsoft.com/en-us/download/details.aspx?id=19188.

Active Directory Sites and Services

Sites and Services is another tool that is generally only employed by companies with larger Active Directory infrastructures. As is the case with any server, if having one domain controller is good, then having two domain controllers is even better. The larger your company grows, so does your Active Directory infrastructure. Before you know it, you will be looking into setting up servers in a second location, then a third, and so on. In a domain-centric network, having domain controller servers in each significant site is a general practice, and you could soon be looking at dozens of domain controller servers running in your network.

Turning on new domain controllers and joining them to your existing domain so that they start servicing users and computers, is pretty easy. The harder part is keeping all of the traffic organized and flowing where you want it to. If you have a primary datacenter where the majority of your servers are located, you probably have multiple DCs onsite in that datacenter. In fact, in order to make your AD highly available, it is essential that you have at least two domain controllers. But then you build a new office that is significantly sized where it makes sense to install a local DC server in that office also, so that the computers in that office aren't reaching over the Wide Area Network (WAN) in order to authenticate all the time. If you were to spin up a server in the new office and turn it into a domain controller for your network, it would immediately start working. The problem is that the client computers aren't always smart enough to know which DC they need to talk to. You may now have computers in the remote office that are still authenticating back to the main datacentres' DCs. Even worse, you probably also have computers in the main office that are now reaching over the WAN to authenticate with the new DC that is in the remote office, even though there are DCs right on the local network with them!

This is the situation where Active Directory Sites and Services become essential. In here, you build out your different physical sites and assign the domain controllers to these sites. Domain-joined users and computers within this network now follow the rules that you have put into place via Sites and Services, so that they are always talking to and authenticating from their local domain controller servers. This saves time as the connections are faster and more efficient, and it also saves unnecessary bandwidth and data consumption on the WAN, which often saves you dollars.

Here's a quick look into Active Directory Sites and Services. There is a good chance you will have to make use of this tool someday if you are part of a growing organization:

Active Directory Administrative Center

While the tools we have looked at so far are critical to understand and be familiar with in order to manage Active Directory, you can tell that their aesthetics are a bit dated. The Active Directory Administrative Center, on the other hand, has a much more streamlined interface that looks and feels like Server Manager that we are all becoming more and more comfortable with. Many of the functions available within the ADAC accomplish the same things that we can do through the other tools already, but it pulls these functions into a more structured interface that brings some of the most commonly utilized functions up to the surface and makes them easier to run.

One great example is right on the landing page of ADAC. A common helpdesk task in any network is the resetting of passwords for user accounts. Whether the user forgot their password, changed it recently and mistyped it, or if you are resetting a password during some other sort of troubleshooting, resetting a password for a user account typically involves numerous mouse clicks in order to get the job done. Now there is a quick link called Reset Password, shown right here on the main page of the Active Directory Administrative Center. Also useful is the Global Search feature right next to it, where you can type in anything to the search field and it will scour your entire directory for results relating to your search.

This is another common task in AD that previously required multiple clicks to accomplish.

If you click on the name of your domain in the left navigational tree, you will dive a little deeper into the capabilities of ADAC. As you can see, the information listed here is being pulled from Active Directory and looks like the same information you would see in AD Users and Computers. That is correct, except instead of having to right-click for every function like new user creations or searches, you now have some quick Tasks available on the right that can quickly launch you into accomplishing these functions. Also interesting are the links for raising the forest or domain functional level on this screen. In order to do this using the classic tools, I see most admins accomplish this by launching AD Domains and Trusts. So one of the big benefits of the newer ADAC tool is that it is capable of giving you a centralized management window from which you can accomplish tasks that would normally have taken multiple windows and management consoles. Do you sense a common theme throughout Windows Server 2016 with the centralized management of everything?

Dynamic Access Control

In addition to teaching the old dogs new tricks, the Active Directory Administrative Center also brings some new functionality to the table that is not available anywhere in the classic tools. If you once again take a look at the tree to the left, you will see that the next section in the list is Dynamic Access Control (DAC). This is a technology that is all about security and governance of your files, the company data that you need to hold onto tightly and make sure it's not falling into the wrong hands. DAC gives you the ability to tag files, thereby classifying them for particular groups or uses. Then you can create Access Control policies that define who has access to these particularly tagged files. Another powerful feature of Dynamic Access Control is the reporting functionality. Once DAC is established and running in your environment, you can do reporting and forensics on your files, like finding a list of the people who have recently accessed a classified document.

DAC can also be used to modify a user's permissions based on what kind of device they are currently using. If our user Susie logs in with her company desktop on the network, she should have access to those sensitive HR files. On the other hand, if she brings her personal laptop into the office and connects it to the network, even when providing her domain user credentials we might not want to allow access to these same files simply because we do not own the security over that laptop. These kinds of distinctions can be made using the Dynamic Access Control policies.

Read-only domain controllers

We can't wrap up our overview of the important Active Directory tools and components without mentioning Read-only domain controller (RODC). Typically, when installing new domain controllers to your network, you add the role in a way that makes them a regular, writeable, fully functional DC on your network so that it can perform all aspects of that DC role. There are some circumstances in which this is not the best way to go, and that is what the RODC is here to help with. This is not a separate role, but rather a different configuration of the same AD DS role that you will see when spinning through the wizard screens during the configuration of your new domain controller. An RODC is a specialized domain controller to which you cannot write new data. It contains a cached, read-only copy of only certain parts of the directory. You can tell an RODC to keep a copy of all the credentials within your domain, or you can even tell it to only keep a list of selective credentials that are going to be important to that particular RODC. Reasons for using an RODC? Branch offices and DMZs are the most common I see. If you have a smaller branch office with a smaller number of people, it may be beneficial for them to have a local domain controller so that their login processing is fast and efficient, but because you don't have a good handle on security in that little office, you would rather not have a full blown DC which someone might walk away with.

This could be a good utilization for an RODC. Another is within a secure DMZ network. These are perimeter networks typically designed for very limited access, because they are touching the public Internet. Some of your servers and services sitting inside the DMZ network might need access to Active Directory, but you don't want to open a communications channel from the DMZ to a full domain controller in your network. You could stand up an RODC inside the DMZ, have it cache the information that it needs in order to service those particular servers in the DMZ, and make a much more secure domain or subdomain environment within that network.