Setting Up A Small Windows Domain

Hey everyone — I wanted to take some time to set up an environment for us to play in. Instead of assuming that everyone reading this was familiar with how to do it, I thought it would be good to show how to set up a simple Windows domain.

You might be asking what this has to do with information security since this seems more like systems administration. 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
  • DHCP
  • DNS

You might be wondering why we are messing with DHCP and DNS when there is only going to be one client or when we could install those through another VM. I wanted to set this up with a common configuration that you might see in the real world. In the real world, you would probably have separate machines running DHCP and DNS, but I wanted to keep resource allocation as low as possible, and I wanted to keep things simple. Feel free to spin up additional VMs to provide the additional 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. When you first boot your newly installed Windows Server 2012 R2 machine, you will be presented with the Server Manager Dashboard which looks like this:

All of the services we talked about (Active Directory, DHCP, and DNS) are called ‘roles’ in the Windows server world. Before we install those roles on our server, we need to give the server a static IP address. That way, it will always be in the same place on our network. Since we are going to have this server doing DNS, we need a steady IP so that our clients know where to send DNS requests. 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:

Click the link that says Ethernet on the right, which will bring up the Ethernet Status window. In that window, click Properties, then click ‘Internet Protocol Version 4 (TCP/IP v4)’ and click Properties again. That should bring up a window similar to this:

So, right now, our server is trying to use DHCP to get an IP address. That will not work, so we need to set up a static IP address. For our network, we will use 10.15.20.2 as the IP, a subnet mask of 255.255.255.0 (/24) and a default gateway of 10.15.20.1. Since this computer is going to be the DNS server, we will use 127.0.0.1 (local host) as the DNS server (which we will set up later). 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.

Click OK and Close until you are back to the Network and Sharing Center. If you get a popup asking if you want to let this computer access TVs and Printers and such, say Yes. This will designate the network as a private network and will allow easier communication between the server and other computers on the network. If you say no, the network is marked as public and a number of ports are closed off, and you would have to configure the firewall which we are not going to do today. 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 do not have any additional Windows features we want to install right now, so click Next here.

This window tells you more about Active Directory, so simply hit Next here.

This screen tells you about DHCP. Click Next.

This screen tells you about DNS. Click Next.

This screen tells us what we are going to install. Make sure you are installing Active Directory Domain Services, DHCP Server, and DNS server. Then click Install. It will run for a little while, and you should see that the installation succeeded when it is done:

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.

You will see a few warnings. We already know about the DNS one, and we will take care of that later, so do not worry about that one. The other warning is about how weaker crypto for Windows NT4 will not be enabled by default for those older clients. Since we will not have any Windows NT4 clients, we do not need to worry about this. As long as you do not have any red warnings, you should be good to go. When you are ready, hit Install to promote this server to a domain controller. 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.

We 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.’ The DHCP wizard will popup and tell us what we are going to do:

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. If you expand that by clicking the little arrow next to the server name, you see the following:

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.

We may mess with some of these later, but we will focus first on defining a scope. A scope will tell the server which IPs it can give out to clients from the available pool. You can have more than one scope, but for our example, we will define a simple one. So to do this, we first have to right click on IPv4 and then click New Scope. The New Scope Wizard will come up:

The first thing we have to do is name our scope. You can give it whatever name you like, but since this is for clients, I will call it “Clients” Once you have named your scope, click Next:

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:

Here, we can define any IPs we want to exclude from the range we defined before. We do not have any in our simple example. We can also define a delay that will be used to determine how long the server should wait before sending back a DHCPOFFER message. When a client sends a request for an IP to a DHCP server, the DHCP server will send back a DHCPOFFER if it is okay for that client to get an IP from the server. Setting a delay is useful if you have more than one server that is responsible for a chunk of the overall range. You can delay the second server so that if it gets an IP from the first range, the client will refuse the DHCPOFFER from the second server. That will help prevent IPs from getting exhausted from the second server’s part of the overall scope. We do not have anything like that going on here, so the default of zero milliseconds is fine here. Now that we have that, click Next:

Now, we need to define the duration that a client’s lease will be good for. After this time period is up, the client will ask for an IP from the DHCP server again. You might want to set this high if you have a bunch of computers that do not come and go from the network. That way, they are not asking for addresses often. On the flip side, if your network is full of people with laptops that go in and out, you would not want long leases because then your pool of IPs could be exhausted too quickly. If a computer has a lease and the computer leaves, the IP is not available until the lease expires. It is like if you are renting an apartment. Until your lease is up (or you get kicked out), the landlord cannot give your apartment to someone else. The same is true of IPs. For our purposes, eight days is fine because the clients are not going anywhere. Set your duration and click Next:

The wizard will now ask if you want to configure the additional parameters given out when a client gets an IP (like gateway and DNS server) that I mentioned before. We are going to go ahead and do this to make sure clients will be all set up. So, click Next:

Now we have to define a default gateway for the network. In our example, the default gateway of our network is 10.15.20.1, so type that in for IP address and click Add. If you are using a different addressing scheme, fill in the appropriate IP(s). Then click Next.

Now we get to specify the DNS servers. 10.15.20.2 is this server, and we do not have any secondary servers. You could also specify a DNS server by its name and Windows will resolve it if it can and put it in the list. We only have the one server, so click Next:

Next, we can point clients to a WINS server if we want. WINS converts NetBIOS names to IP addresses (it is like DNS for NetBIOS). We do not have WINS set up because we are not going to do anything with NetBIOS at this point, so click Next:

That is it! Awesome! We want to activate this scope because we spent time defining it, so choose Yes and click Next. When it is done, you will see new things in the DHCP Snap-in:

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. Before 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:

Now you need to give the user a password. For this lab, we will not make the user change password at next logon since we are both the administrator and user in this domain, so clear that checkbox. The other checkboxes can stay cleared because we do not need to enable any of those options. For the password, Windows has a default complexity requirement defined here. Basically, it has to have three of the following five things:

  • Uppercase letters
  • Lowercase letters
  • Numbers
  • Special characters (like @, $, %, et cetera)
  • Unicode characters

Once you have chosen your password, click Next, then Finish. Your user is created. The 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:

We need to change the domain, so click domain and type in your domain. In our case, this is windows.local. Then click OK:

Type the user name and password of the Administrator on your domain (which is probably Administrator) and the administrator password then click OK. If successful, you will get a welcome message from the domain:

Click OK. You will get a message about restarting the computer. Click OK, then Close, then Restart Now. When the machine comes back up, you will be asked for your domain credentials. These are the credentials for the user we created previously. You may have to click the back button at the login prompt and click other user:

You can see we are logging into the Windows (windows.local) domain. If you look at the domain controller under Active Directory Users and Computers, you can see our client in the Computers folder:

Computers, like users, can have policies attached to them. Active Directory gives them an account on the domain like a user, but instead of a password, the computer uses a special key. 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:

We 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. So 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!


Originally published at blog.attackzero.net on March 7, 2016.