Windows Server 2019 – Using AD DS to organize your network

How to install and use docker on ubuntu 18.04

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 as we saw in a previous chapter, the easiest way to launch these consoles is 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-hand column. Expand your domain name, and you will 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 pieces to point out here 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. Most of the manila-colored folder icons that you see here are known as Organizational Units (OUs). I say most of because there are a few containers that exist out of the box that are legitimate storage containers for holding objects, but they are not official OUs. The ones we pointed out earlier, Users and Computers, are actually these generic storage containers and are not real Organizational Units. However, any new folders that you create for yourself inside AD are going to be OUs. The difference is depicted in the manila folder icon. You can see in the upcoming screenshots that some of the manila folders have an extra little graphic on top of the folder itself. Only those folders that have the extra little yellow thing are real OUs.

OUs are the structural containers that we use inside Active Directory in order to organize our objects and keep them all in useful 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 folder, I have created some new OUs including subcategories (more officially known as nested OUs) 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 contain 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. Most of the information here is self-explanatory, but if you are new to Active Directory, the one field I will point out is User logon name. Whatever information is put in this field is the user’s official username on the network. Whenever they log into a computer or server, this is the name they will input as their login.

When finished, our new admin will be able to utilize the 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 to distinguish 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. Both Susie and Jim reside inside the same OU, so at that level they will have the same permissions and capabilities, but we clearly need a different way to distinguish between them so that only Susie gets access to payroll information. By creating Security Groups inside Active Directory, we enable users to add and remove 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, and 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

It is very common to utilize Active Directory Users and Computers for creating new user accounts, because without the manual creation of a user account that new person is going to be completely unable to login on your network. It is far less common, however, to think about opening this tool when joining new computers to your domain. This is because most domains are configured so that new computers are allowed to join the domain by actions performed on the computer itself, without any work being done inside Active Directory beforehand. 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 container, so in many networks, if you click on that Computers folder, 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 have recently joined a number of machines to the domain. I did this without ever opening AD Users and Computers, and you can see that my new computer objects are still sitting inside that default  Computers container:

Allowing new computer accounts to place themselves inside the default Computers container 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? The answer is to prestage the domain 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 object 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 that 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.

Prestaging a computer object is extremely fast and simple; let’s do one together. In the future, I plan to build a Windows Server that hosts the Remote Access role in order to connect my roaming users into the network from their homes, coffee shops, and so on. Some components in the Remote Access role are finicky when it comes to network security policies, and so I would rather ensure that my new RA1 server will not receive a whole bunch of lockdown settings as soon as I join it to the domain. I have created an OU called Remote Access Servers, and I will now prestage a computer object inside that OU for my RA1 server.

Right-click on the Remote Access Servers OU, and choose New | Computer. Then simply populate the Computer name field with the name of your server. Even though I have not built this server yet, I plan to name it RA1, so I simply type that into the field:

That’s it! With a couple of simple mouse clicks and typing in one server name, I have now prestaged (pre-created) my computer object for the RA1 server. If you look closely at the previous screenshot, you will notice that you could also adjust which users or groups are allowed to join this particular computer to the domain. If you plan to build a new server and want to make sure that you are the only person allowed to join it to the domain, this field is easily updated to accommodate that requirement.

Once I actually get around to building that server, and I go ahead and walk through the steps of joining it to my domain, Active Directory will associate my new server with this prestaged RA1 object instead of creating a brand new object inside the generic Computers container:

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 as 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 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 to bring 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 relationship 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 following link:

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. As your company grows larger, 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 let’s pretend you then build a new office that is quite large, 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 datacenter’s 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. As you can see, there are multiple sites listed here, and they correspond to network subnet information. This is the way that AD Sites and Services tracks which site is which. When a client computer comes online, it obviously knows what subnet it is part of, based on the IP address it is using. AD Sites and Services then knows, based on that IP address, which site the client now resides in. That site identification then helps Active Directory to steer authentication requests to the proper Domain Controllers, and also helps things like Group Policy (which we will talk about shortly) to be able to process site-specific information. 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 it is critical to understand and be familiar with the tools we have looked at so far in order to manage Active Directory, you can tell that their aesthetics are a bit dated. The Active Directory Administrative Center (ADAC), on the other hand, has a much more streamlined interface that looks and feels like the newer 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 inside AD Users and Computers 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, such as 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 that 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 2019 with the centralized management of everything?

Dynamic Access Control

In addition to teaching the old dogs new tricks, 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, such as finding a list of the people who have recently accessed a classified document.

DAC can also be used to modify users’ 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, we might not want to allow access to these same files, even when providing her domain user credentials, 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 (RODC)

We can’t wrap up our overview of the important Active Directory tools and components without covering Read-Only Domain Controllers (RODC) in a little more detail. 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 the AD DS 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. They contain 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. What are the 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 physical security in that little office, you would rather not have a full-blown DC that someone might pick up and 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 connected to 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 DMZ network.

Comments are closed.