That is a good question. I believe that in order to adequately protect (or break into) a system, you need to understand how it works. If you go through the steps to set up a domain, I think you will get a better appreciation for how the components fit together. If you already know how to set up a domain or have one set up, feel free to skip this post.
We will use this little domain for examples going forward, so if you want to follow along, it would be a good idea to have a setup similar to this.
For those of you that are interested, we will talk about what we are going to set up then we will walk through it after the jump.
We are going to set up a very simple domain. Initially, it will contain one domain controller and one client. For those unaware, a domain controller is the central machine on the network that takes care of authentication and security policy in a Windows network. It allows an administrator to control who gets access to what and when they have access to it.
For our set up, we will use a copy of Windows Server 2012 R2 Standard for the domain controller and Windows 8.1 Enterprise for the client. Whatever mix of server and client you have on hand will probably work, but Windows Server 2008 R2 is probably the oldest I would use and Windows 7 would be the oldest client. Windows Server 2003 is 'end of life', Windows Server 2008 mainstream support ended earlier this year, and mainstream support for Vista ended a while ago. Windows Server 2012 R2 is available as an evaluation copy from Microsoft here. If you need a Windows client, Windows 10 Enterprise evaluation is also available from there. You need at least the Professional version of whatever client you want to add (7 Professional or higher, 8 Professional or higher, 8.1 Professional or higher, or Windows 10 Pro or higher). Home versions cannot join domains.
I have installed copies of both in virtual machines so that if they get messed up, we can just reinstall them. Also, we do not need two separate physical machines. Whatever you have will work though. Since we do not have to support a ton of users, we do not need a ton of resources to make this mini-domain work. The Windows Server 2012 R2 VM has 2 CPU cores, 3GB of RAM, and 20GB of disk space, and the Windows 8.1 client has 2 cores, 2GB of RAM, and 20GB of disk space. I think that will be sufficient for our needs, but feel free to allocate more if you like.
I have set these VMs up in their own isolated virtual network. They do not need access to any other VMs or the Internet, so there is no need to get fancy with the network configuration. We will put these VMs in the 10.15.20.0/24 IP address space. The domain controller will be at 10.15.20.2, and the client will be assigned an IP through DHCP. I do not have a DHCP or DNS server running in the network because the Windows Server VM will provide those services. More on that in a bit.
If you need help getting the VMs set up with the hypervisor you are using, feel free to drop me a note, and I will help. This guide assumes you have freshly installed VMs ready to go.
For our first foray into learning about domains, we are going install the following services onto the Windows 2012 R2 VM:
- Active Directory Domain Services
The reason we need to install DHCP and DNS at all is because of how tightly integrated these services are into the Active Directory ecosystem. DHCP integrated into Active Directory allows Active Directory to keep track of computers it handles leases out to and will update the DNS entries for these computers if the domain controller can talk to a Windows server running DNS.
DNS in an Active Directory environment is very important. It allows clients to locate the domain controller. On the server side, DNS integrated into Active Directory allows you to have more control over who can use the DNS server and it allows the server to keep track of clients a bit easier. This is not to say you could not use a Linux DNS server like bind to make this work. We are keeping things simple here, so we will let the Windows server take care of DNS as well.
Now that we have talked through what we are going to do, let's make it happen. We will work on the server first because that will be providing the underpinnings of our infrastructure.
To do that, we will open the Network and Sharing Center. Hit the Windows button down in the bottom left (or hit the Windows key) and type network. Network and Sharing Center should show up in the list. You can also right click the computer icon in the bottom right (the one to the left of the speaker in my screenshot) and choose 'Open Network and Sharing Center.'
You will get a window that looks like this:
After you have typed all of that in, your window should look something like this. If you want to use a different IP addressing scheme, that is fine.
You can close the Network and Sharing Center because we are done with that for now. You should be back at the Server Manager Dashboard. We are going to install our first role: Active Directory Domain Services. To begin, click Add Roles and Features (number 2 in the window) and you should see the Add Roles and Features Wizard:
This is an introduction to the Add Roles and Features wizard, so click Next to continue.
We will choose 'Role-based or feature-based installation' because we are not doing VDI or configuring this server for serving remote sessions to users. Click Next.
Our server is already chosen for us because it is the only one we have available. Click Next.
Now, we get to choose our roles. Click the checkbox next to 'Active Directory Domain Services.'
You will get a popup that looks like this telling you what is going to be installed. Click Add Features.
Do the same for DHCP and DNS. Once you have those selected, click Next.
We have to take care of two more things as the wizard tells us. First, we will take care of promoting this server to a domain controller. This involves configuring the computer so that it has everything necessary to be our domain controller. Click the link that says 'Promote this server to a domain controller.'
The first screen will look something like this. We will choose 'Add a New Forest' because we do not have an existing domain or existing forest to add this domain to. You might be wondering why we are messing with trees when we are supposed to be working with domains. In Active Directory terminology, a forest is a group of domains. That group can be as small as one or as many as you want. So we are going to make a forest with one domain which will be served by one domain controller (for now).
For the domain name, I am using windows.local. You can use whatever you want since this setup is isolated. The domain name needs to be fully qualified (something.domain).
When you have your domain typed in, hit Next.
Next, you will have to choose a Functional Level for your domain. Microsoft is big on backwards compatibility (so much so that it sometimes introduces vulnerabilities into newer operating systems), so you can choose a functional level for older Windows servers. Typically, you would choose a Functional Level equal to the oldest server you have running in your domain. Since we will only be using Windows Server 2012 R2, we will choose that as our Functional Level for both the forest and the domain. If your domain was all 2012 R2 servers but your forest was running 2008 R2, you could choose 2012 R2 for your domain functional level and 2008 R2 for your forest functional level. We are going to stick with 2012 R2 for both. Type in a strong Directory Services Restore Mode password. DSRM is like safe mode for your domain controller. If you accidentally mess something up on your domain controller, you might be able to use DSRM to fix it. Once you type in your password, click Next.
Ignore the warning about the delegation for the DNS server. We have not set up our DNS server yet, so there will be no authoritative server for our domain windows.local yet. We will fix that later, so for now, click Next.
From our domain name windows.local, Windows derived the NetBIOS domain name of 'WINDOWS.' This is more useful for older clients that rely on NetBIOS to find resources on the network. The maximum size for a NetBIOS name has to be under 15 characters. You can choose whatever you want as long as it is below 15 characters, but the one it chose is fine, so click Next.
Active Directory is a database of objects that represent various entities on your network like users, groups, and computers. Active Directory needs a place to store that database, so the wizard is asking us. SYSVOL is used by Active Directory to store publically available information that computers that join the domain need to join the domain. The defaults are fine, so click Next.
This window gives us a review of what we are going to do. This looks good, so we will click Next.
It will take a few minutes, and the server will reboot to complete the installation and configuration.
When it comes back and the Server Wizard opens, you should see that the server is domain controller and that DHCP and DNS are installed.
DHCPWe need to take care of configuring the DHCP and DNS servers now. If you have DHCP running in the network somewhere else, turn it off. It could conflict with what we are going to set up and it will cause problems.
We will start with DHCP. Click the little flag with the yellow warning icon (as in the picture) and click 'Complete DHCP Configuration.'
This sounds good, so click Next:
Now, the server wants to know whose credentials to use to authorize the DHCP server in Active Directory. This means that if you want to use the DHCP server as part of the domain and all of the features that comes with, you will need to authorize it. Whoever authorizes it has to have administrative privileges in the domain. Since we only have one domain admin right now (Administrator), those credentials will have to be used. Make sure the user name is of an administrator and click Commit.
If everything goes well, you will have a screen that looks like this:
Click Close. We are not quite done yet. We still need to set the parameters of the DHCP server.
You should be back at Server Manager at this point. From there, in the Tools menu in the upper right, choose DHCP:
This is the Microsoft Management Console (MMC). There are various snap-ins (think plugins or modules) that allow you to control various aspects of the computer. This is the DHCP snap-in which is available because we installed DHCP server on this machine. You see the name of the server on the left.
There are options for IPv4 and IPv6. We are not going to mess with IPv6 for this example (I have disabled IPv6 on the virtual switch since we are not using it). The three options we have allow us to do advanced things on the server like:
- Blacklist and whitelist MAC addresses that are allowed to get IPs from our DHCP server under Filters
- Give IPs based on device type or MAC address (for example, you could give all of the mobile devices made by a certain manufacturer IPs in a certain range for easier administration) under Policies
- Configure Options allows you to give additional parameters (like DNS servers or the default gateway) through DHCP to clients that request an IP.
Next, we need to define the range of IPs that this DHCP server will distribute for this scope. Our network is a /24, which means we have 256 possible addresses (10.15.20.0 - 10.15.20.255). We have already used .1 for the gateway, .2 is this server, .255 is for broadcast, so we need to choose a range that is not being used. We will choose 10.15.20.150 to 10.15.20.200. The subnet mask length is 24 since we decided that before. If you want something different, you can use that. The subnet mask itself is filled in automatically when you specify the length (for a /24, it should be 255.255.255.0).
Once you have everything filled in, click Next:
You will see the pool, options, and other things that we configured. You can also see the leases that are currently in use (we have none right now). You can come back later and tweak things if you like. That is done, so we will move onto DNS now. Close the DHCP window, and you should be back at the Server Manager.
There is not much we actually have to configure here. I just want to show you some things. From Server Manager, choose Tools then DNS. DNS Manager should pop up. If you click on your server, you will see some things in the right pane:
We can take a look at the records in our DNS server by double clicking Forward Lookup Zones. A forward lookup zone is when you want to look up the IP for a name (a typical DNS query). It holds a mapping of hostnames to IPs. A reverse lookup zone is the opposite: it holds a map of IPs to hostnames. If you click Forward Lookup Zones and then our domain (windows.local), you will see the records we have so far:
The records with underscores are records added in for Active Directory. You can see that we have one host right now which is our server. There are also Start of Authority Records and Name Server records. Start of Authority tells clients that ask for hostnames in the windows.local domain which server is the authoritative source for information about the windows.local domain. Authoritative sources are the primary source for information about a domain. Name Server records tell clients what name servers they can use in the windows.local domain. If you right click the domain (windows.local), you can manually input various kinds of records. For now, we do not need to do anything since the records should be automatically updated by the DHCP server.
That is all I wanted to talk about right now with respect to DNS, so close the DNS Manager window.
Adding a Client
Adding a User AccountBefore we actually join the computer to the domain, we will add a user account for the user on the domain. There is a wizard we can use that guides us through all of this, but I wanted to show how to add a user account to the domain since that comes in handy.
On the server we just set up, from Server Manager, choose the Tools menu then choose Active Directory Users and Computers. Something like this should pop up:
We are going to configure windows.local, so click the arrow next to windows.local and click the Users folder. You should see the default users populate the right pane:
Right click somewhere in the right pane and click New then User:
Type in a name for your user and a user name. I am not going to be creative, and the user's name will be user and his logon name will be user as well. You can be more creative if you like. When you are done, click Next:
here. Basically, it has to have three of the following five things:
- Uppercase letters
- Lowercase letters
- Special characters (like @, $, %, et cetera)
- Unicode characters
Add the Client to the DomainThe last thing we need to do with the machines is add (or join) a client to the domain. So, we need to switch over to the client that we set up. I am using 8.1 Enterprise, but the same steps are similar on Windows 7, Windows 8, and Windows 10. We will be doing these steps from the client. If your client has not picked up an IP from the domain controller yet, launch a command prompt (right click the Windows key and choose Command Prompt). In the window, type ipconfig /release then enter. When that is done, type ipconfig /renew. This will force the computer to ask for a new IP from any DHCP servers on the network. You should then get an IP:
You can see that we got the IP 10.15.20.150 which we defined as the start of our range before. If you get a question about making the computer visible on the network to see TVs and Printers, choose Yes like we did before.
Now, let's join the computer to the domain. Right click the Start Menu button and choose System:
You should see something like this. We will join this computer to the domain. We can see that this computer is part of a workgroup. We need to change that, so click the Change Settings button:
Click the Change button. A window like this should pop up:
If you look at the domain controller under Active Directory Users and Computers, you can see our client in the Computers folder:
To manage this computer using Group Policy (a means of centrally managing policies in a domain), we will move this computer to a new organizational unit (OU). An organizational unit is a container for group policy objects (like users and computers) that allow you to logically partition your domain. To create a new OU, right click your domain in this window and choose New > Organizational Unit. You can name it whatever you like. Since we are going to put computers in here, I named it "Workstations" Click OK. Then move the computer (User-PC in this case) to the new OU by clicking and dragging hit, right clicking it and hitting Move, or Cut and Paste using keyboard shortcuts. Any of those will work. This is what the OU looks like after creation:
A Distribution Point for SoftwareWe might want to deploy software in our domain through Group Policy. To do this, I created a Linux box in the network running Samba that all of the computers can access. I then added it to the domain. You can also set up another Windows box to do file sharing, share files from the Domain Controller, or share files from your host machine into the VMs.
Conclusion and Final ThoughtsSo we are all set up to move forward with any Windows domain based things we want to look at. I think it was important to understand (even at a high level) how domains are administered so that they are not a black box when you are thinking about how to defend them or attack them as a penetration tester. If you have any questions, please let me know.
Thanks for reading!