2015-03 Active Directory, Windows Server 2008 R2 & 2012

In these notes, we will build an Active Directory domain, centered around Windows 2012 and Windows 2008 R2 Servers. The starting point will be the virtual machines provided in the classroom laboratory. You may not copy remove those virtual machines from the laboratory, however you can get the installation .isos from the campus MSDNAA / Dreamspark subscription and build your own copies at home for your own use as a student.

To begin, be sure you follow the installation notes provided in 2014-00 System Setup. Remember that the default password is “password1!; you might want to change that.

Note also that both the Windows 2008 R2 and Windows 2012 have a local administrator account. What is the password for those accounts? Log into the accounts, and update the passwords appropriately.

Basic Information

In this example, we are going to start with two systems:

• Windows Server 2012
  • IP Address: 10.0.6.200
  • DNS: 10.0.6.200 (Yes, I know we don’t have a DNS server there (yet)!)
  • Host Name: brakiri.class.tu
  • Domain / Workgroup: Unconfigured (for now; defaults to WORKGROUP)
• Windows Server 2008 R2
  • IP Address: 10.0.6.201
  • DNS: 10.0.6.200 (See above!)
  • Host Name: abbai.class.tu
  • Domain / Workgroup: Unconfigured (for now; defaults to WORKGROUP)
• Network
  • Netmask: 255.255.255.0
  • Gateway: 10.0.6.254

Active Directory Installation, Windows Server 2012

On the Server Manager tool, select Manage, then Add Roles and Features. We will install both our DNS Server and our Domain Controller on the same host. We can put these on separate hosts if we wish. If you do, then be sure the DNS is built first.

We start by install Active Directory Domain Services. Although you have the option to also install the DNS server at the same time, I recommend against it. We will come back to this point a bit later, when we configure the system as a domain controller.

So, select only Active Directory Domain Services for installation. When this is selected, you will be prompted to add a number of other required features, primarily remote server administration tools. Accept the defaults here:

The installation should then proceed without issues.

When the process completes and you return to the Server Manager tool, the first thing you will notice is the new role "AD DS" on the left side. You will also have a notification flag that tells you that you need to continue working to complete the configuration.

Let’s take the next step and promote our system to a domain controller. Since we have not yet built a domain, this system will be the first in a new forest. Following the usual rules for new Windows domains, we do not want the forest root domain name to match our external name, so we select corp.class.tu for our domain name.

There are a number of functional levels available for the forest and root domain, including

• Windows 2003
• Windows 2008
• Windows 2008 R2
• Windows 2012

Later we will be adding a Windows 2008 R2 server to the domain, and we may later wish to add even older systems, so in this example we will select a Windows 2008 functional level.

We do want the domain controller to provide DNS, so we keep that setting in its default state. The Directory Services Restore Mode password will allow logins to the domain controller when Active Directory is not running, so we set this password.

At this point, we will be asked to select additional options for this domain controller; the DNS Server option will be checked. Accept this.

When you advance to the DNS options page, you will receive a warning; clicking on it show the message

Since we are working in our classroom laboratory environment, we will not need to resolve names outside our domain; thus we can accept this warning and proceed. Microsoft has more information about these DNS options.

We will accept the default NetBIOS name for our domain; in this example it is "corp" from our selected forest name.

Next, you will be asked to specify the locations of the AD DS database, the log files, and the SYSVOL; all of these can be retained in their default locations.

You will then have a chance to review your options; and then a check of the prerequisites. The domain administrator password will be the password for the administrator of the computer. Some of the prerequisite warnings include a note about the cryptography used, and the fact that no authoritative parent zone has been found. If you retained your IPv6 address (which is assigned dynamically) you will also be notified of this fact.

If you don’t have a DNS server specified, then you will not pass the prerequisites check. If you kept an IPv6 address assigned automatically, then you would be fine; you are also fine if you have specified the host itself as the DNS server, as I mentioned in the introduction. Oddly, the fact that there is no actual DNS server there matters not to the installation process, so long as you pretend that there is a DNS server at the other end, then things will be fine.

As the installation proceeds, the system will reboot. [It is a Windows system, after all.]

DNS Configuration

After the system reboots, you can log in to the domain; you will have a domain administrator (administrator) and a domain member. The domain member account name is the same as the name of the local account on the system; in my case this is the user "zathras". The passwords for these accounts are the same as they were on the system before it was promoted to a domain controller.

Let’s start working with the domain by adding some entries to the DNS server. From the Dashboard, select Tools then DNS; you can also choose DNS from the (Metro) start menu.

Expand the Host name (in my example, it is called Brakiri), then expand out the tree for Forward Lookup Zones, then the name of your domain (in my example, it is corp.class.tu) to obtain something like the following:

Right-click in the panel on the right, and select “New Host (A or AAAA), and provide both the hostname and the IP address. In this example, we will set centauri.corp.cosc.tu to 10.0.6.202.

We can verify that our entry was added to the DNS server from PowerShell:

Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\Users\zathras> nslookup centauri
Server:  localhost
Address:  127.0.0.1

Name:    centauri.corp.class.tu
Address:  10.0.6.202

Note however, that the reverse lookup fails; if we ask the nameserver for the hostname that corresponds to the IP address 10.0.6.202, it will fail with an error:

PS C:\Users\zathras> nslookup 10.0.6.202
Server:  localhost
Address:  127.0.0.1

*** localhost can't find 10.0.6.202: Non-existent domain

The reason for this is that we have not yet specified the corresponding reverse lookup zone. Return to the server, and click on the Reverse Lookup Zones entry in the navigation panel; you will find that there are no zones present.

Right-click on Reverse Lookup Zones, and select New Zone to launch the New Zone Wizard. You want to create a primary zone, and store the zone in Active Directory. Replication can be as broad as you wish; in this example we will accept the default and replicate to all DNS servers on domain controllers in the domain. Create an IPv4 Reverse Lookup Zone for your network. In this example, we will set up a reverse lookup zone for the 10.0.6.0/24 subnet.

Notice how we did not have to manually specify the ".in-addr.arpa." component of the address, as we simply specified the Network ID.

Continuing the install, we will be asked about dynamic updates. We will not discuss dynamic updates for the DNS server; in fact we ignored the issue completely when we discussed BIND on Linux; feel free to accept the default and allow only secure dynamic updates.

Let the process complete, then open up your new reverse domain; in my example it is named 2.0.10.in-addr.arpa. Right click, and select New Pointer (PTR) and add pointer records for every host you added earlier- and this included the domain controller itself. You can do this by entering the appropriate data in the fields, or searching through the domain controller for the information. To browse, select the host, then the forward lookup zones, then the domain, and then select the host. The information will then be copied directly. Mind you, it is probably much simpler just to type in the data.

Conveniently, once the Reverse Lookup Zone is created, you can add both the address record (A) and the pointer record (PTR) in one step. Simply check the box “Create Associated pointer (PTR) record” when you create the address in the forward lookup zone:

Once this is complete, your nslookup attempts should proceed without error:

PS C:\Users\zathras> nslookup 10.0.6.203
Server:  localhost
Address:  127.0.0.1

Name:    dilgar.corp.class.tu
Address:  10.0.6.203

DNS Forwarding

As was the case with BIND, we need to be able to forward requests for other namepsaces to the correct nameserver(s). We can do so using Conditional Forwarding. From the DNS Manager, select Conditional Forwarders in the navigation tree, then right-click and select New Conditional Forwarder.

In week 2, we set up a BIND server for the domain .cosc.tu on the IP 10.0.2.100. We set the DNS domain as cosc.tu and the IP address to receive the forwarded queries as 10.0.2.100.

Because we have not included the .cosc.tu namespace in our server, and because there is no root nameserver, the Windows system is unable to validate the BIND server’s FQDN; this is expected.

Set up your Windows 2012 server to correctly forward queries to your BIND server from week 2.

The process for forwarding the reverse queries is the same, save now the domain is 2.0.10.in-addr.arpa. One catch though- the numerical address spaces for the zones cannot overlap. Our Windows DNS is serving

• Namespace: *.corp.class.tu
• Address Space: 10.0.6.*

while the Linux server from week 2 is serving

• Namespace: *.cosc.tu
• Address Space: 10.0.2.*

Forwarding will fail (often spectacularly) if the namespaces overlap or if the address spaces overlap.

Test the results! You should update the BIND server to correctly forward requests to the Windows server and vice-versa.

PS C:\Users\zathras> nslookup centauri
Server:  localhost
Address:  127.0.0.1

Name:    centauri.corp.class.tu
Address:  10.0.6.202

PS C:\Users\zathras> nslookup acheron.cosc.tu
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    acheron.cosc.tu
Address:  10.0.2.100

PS C:\Users\zathras> nslookup 10.0.2.17
Server:  localhost
Address:  127.0.0.1

Name:    hermes.cosc.tu
Address:  10.0.2.17

Notice that when the Windows DNS server was queried about a host on .corp.class.tu it gave an authoritative answer, but when queried about cosc.tu it gave a non-authoritative answer, as it had to forward the query.

Constructing a Windows domain

To add a computer to the domain, we work on the domain member, not the domain controller. The process is similar for each different type of Windows system.

For Windows 7, navigate Computer (Right) / Properties / Change Settings / Change / Member of. As before, be sure that the name of the machine agrees with the DNS entry; you still need an account with privileges on the domain controller, and a reboot is still required.

For Windows 8, Navigate Metro (Right) / All Apps / Computer (Right) / Properties / Change Settings / Change / Member of. As before, be sure that the name of the machine agrees with the DNS entry; you still need an account with privileges on the domain controller, and a reboot is still required.

If the machine does not have a DNS entry, one will be created for it in Active Directory. It will even create both the PTR and the A records, provided the reverse lookup domain already exists. You may see a warning, telling you that a duplicate (potentially shorter NETBIOS) name exists; this generally is not a problem.

Add at least two machines to your domain.

Log in to those machines using a domain account. Remember that you will need to change users from the local system user to the domain user!

Adding Linux Machines to a Domain

Linux systems can be added to a Windows domain. This can be done by directly working with Samba configuration files, though that is somewhat complex. Instead, we will use an open source tool, PowerBroker Identity Services Open 7.5.3. You can get a copy of the required software from Beyond Trust, though they require registration before taking you to the download page.

As the first step, be sure that the Linux system is correctly configured, with functioning networking. Be sure that the system can resolve host names from the domain controller. Next, be sure set up a host record for the system in the DNS server. Unlike the native Windows process, PBIS does not automatically update the DNS records on the server.

Before we join the domain, there is one other change that needs to be made. Once the system is joined to the domain, there will be local users on the Linux system and domain users on the domain controller. If a username appears on both the local system and the domain controller, then hilarity can ensue. (Not the funny, ha-ha kind, but the AARGH! WHY ISN’T THIS WORKING kind.) Since our local users are all named zathras, and since we have a domain user named zathras, this can cause trouble. Thus, on the Linux system the next order of business is to create a new user (valen) that can administer the system, log in as that user, and delete the user zathras. On some systems (e.g. Mint) the zathras user was set to log in automatically; you’ll need to change that as well.

Once that is done, you want to run (as root), the corresponding pbis-open package; use the .rpm on Red Hat / CentOS / OpenSuSE systems, and the .deb on Ubuntu / Mint systems. Be sure to select the 32-bit or 64-bit version as appropriate.

On your CentOS system, you can simply follow the GUI prompts

Be sure to use a domain administrator account, rather than a regular domain user when joining to the domain.

On your Mint system, you can follow the GUI

but it will fail. The catch here is that the system expects to find a functioning SSH server. When it doesn’t find one, it gets a bit grumpy. The solution is to use the command line and manually point out that there is no SSH server to be found:

valen@markab ~ $ sudo domainjoin-cli join --disable ssh corp.class.tu 
administrator

Joining to AD Domain:   corp.class.tu
With Computer DNS Name: markab.corp.class.tu

administrator@CORP.CLASS.TU's password: 
Warning: System restart required
Your system has been configured to authenticate to Active Directory for the
first time.  It is recommended that you restart your system to ensure that all
applications recognize the new settings.

SUCCESS

The situation on Ubuntu is similar, though there I did not even get the GUI to run in the first place.

Once you have your system joined to the domain, you will want to log in to the system as a domain user. On the CentOS system, when given the chance to log in, simply select other, then the name of the domain user. You do not need to prefix it with any information about the name of the domain; just simply enter the domain user name and you are set.

On your Mint system, you have to specify the full domain first, so if you want to log in as the domain user ivanova on the domain corp.class.tu, the user name you enter in the login screen is corp.class.tu\ivanova.

The situation on the Ubuntu systems is the same, with the added fun that the default greeter does not allow you to specify a user name. Update the file /etc/lightdm/lightdm.conf by adding the line

 #greeter-show-manual-login=true

Then you will be able to enter domain names, following the more complex Mint method and log in.

The CentOS system handles domain users better that Ubuntu or Mint; in the latter two cases they don’t really give a proper prompt to your shell. This can be fixed with the command

valen@hyach:~$ sudo /opt/pbis/bin/config LoginShellTemplate /bin/bash

Mind you, cannot (yet) do this as a domain user, because you don’t have sudo permissions either.

You can solve that problem by editing the /etc/sudoers file using the tool visudo and adding the line

%CORP\\domain^admins ALL=(ALL) ALL

This will enable users from the CORP domain in the group "Domain Admins" (space was replaced by ^) to use sudo.

Sure you say, but I am testing this, and I have already logged in as a domain user. Do I need to log out before I make these fixes? Try a bank shot! First su to another user (say valen) then run your commands that need su.

$ sudo ls
[sudo] password for CORP\mcole: 
CORP\mcole is not in the sudoers file.  This incident will be reported.
$ su - valen
Password: 
valen@markab ~ $ sudo /opt/pbis/bin/config LoginShellTemplate /bin/bash
[sudo] password for valen: 
valen@markab ~ $ sudo visudo

You still need to log out and log back in to get the fill bash shell though.

Working with Active Directory

In the discussion of how to connect Linux systems to a Windows domain, we saw how to log in as the user ivanova on the domain. But- how do we add users to the domain in the first place?

To see the default domain users and groups in your domain controller, select Tools from the Server Manager and choose Active Directory Users and Computers; you can get the same information by selecting the icon of the same name from the (Metro) start screen.

Review the default domain users and groups in your domain controller.

• How many users does your DC possess at boot?
• How many are active?
• How many groups does your DC possess at boot?
• How many groups have members?
• Does your initially created user belong to a different set of groups than the administrator?

Add additional users to your DC. Place them in a variety of groups. Verify that these accounts work by using them to log on to client machines.

To create these users, from Active Directory Users and Groups, right-click then select New → User. From the resulting dialog box, you can choose the name and password for that account.

Scripting & Powershell

Suppose that instead of having one or two users to add to our domain we have more- 20 or 50? The solution is to use scripting to automate the process. Fortunately, Windows comes with its own scripting language- Powershell, and its own ISE Editor to help you develop and test your own scripts. Of course, Microsoft being Microsoft, the tools don’t actually do what you want without changing various obscure settings, and yes, one of them will require a reboot. Seriously.

To start, lets run the Powershell ISE, which is the Windows development environment for Powershell scripts. You can do so by right-clicking on the Poweshell button and selecting Poweshell ISE. When complete, you end up with something like the following:

We can create a simple Hello World script as follows

"Hello World"

That’s all- we don’t need a print statement, or an echo statement or the like; just putting a string on a line by itself in Powershell causes it to be printed. Save the result as say "Testing.psl". You can then run it from the editor by pressing F5.

Sort of.

In fact, attempting to run the script will fail with an error:

PS C:\Windows\system32> C:\Users\zathras\Documents\Testing.ps1
File C:\Users\zathras\Documents\Testing.ps1 cannot be loaded because 
running scripts is disabled on this system. For more information, see 
about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : SecurityError: (:) [], 
ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess

As you can see, the system will not allow you to run unsigned scripts, meaning scripts that have not been signed by a trusted publisher, like Microsoft. Even the folks at Microsoft are a bit fazed by this design; on their TechNet Blog they write

Wow; how nice. A new command shell and scripting environment that doesn’t
even let you run scripts. What will those guys at Microsoft think of next?

Listen, don’t panic; believe it or not, everything is fine. You just need to
learn a few little tricks for running Windows PowerShell scripts

Tricks should not be required, but since they are, let’s figure out the tricks.

First, you must open a new Powershell prompt, but this one as an administrator. Go ahead and right-click on the Powershell icon, but now select "Run as Administrator". In the resulting prompt run the following

Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> Set-ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. 
Changing the execution policy might expose you to the security risks 
described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the 
execution policy?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yes

This setting means that any script you write yourself will run, but scripts downloaded from the Internet need to be signed. If you want to allow those to run, then you want

PS C:\Windows\system32> Set-ExecutionPolicy Unrestricted

After this change, you will see that your script will run happily, even from a non-Administrator prompt.

PS C:\Users\zathras\Documents> .\Testing.ps1
Hello World

Now suppose that we have a large number of accounts we want to add to our domain, say a list like the following

David Corwin
William Edgars
Lise Hampton
William Hague
Jason Ironheart
Susanna Luchenko
Catherine Sakai
Anna Sheridan
Lyta Alexander
Alfred Bester
Marcus Cole
Warren Keffer
John Matheson
Dureena Nafeel
Laurel Takashima

As a first step, lets save this list in a text file, say C:\Users\zathras\Documents\users.txt. Then, let’s create a simple Powershell script to extract out the information we might need; we’ll call this script AddUsers.psl

$nameslist = Get-Content C:\Users\zathras\Documents\users.txt

ForEach ($name in $nameslist) {
  $first = $name.Split(' ')[0]
  $last = $name.Split(' ')[1]

  $username = $first.ToLower()[0] + $last.ToLower()
  $displayname = $last + ", " + $first

  "Display Name = " + $displayname + "`tUsername = " + $username
  }

As you can see, the syntax and structure of the language are typical of many scripting languages; probably the biggest difference is the use of the backtick "`" as an escape character.

When run, the code will quite happily print out the names of the users in the file.

PS C:\Windows\system32> C:\Users\zathras\Documents\AddUsers.ps1
Display Name = Corwin, David	Username = dcorwin
Display Name = Edgars, William	Username = wedgars
Display Name = Hampton, Lise	Username = lhampton
Display Name = Hague, William	Username = whague
Display Name = Ironheart, Jason	Username = jironheart
Display Name = Luchenko, Susanna	Username = sluchenko
Display Name = Sakai, Catherine	Username = csakai
Display Name = Sheridan, Anna	Username = asheridan
Display Name = Alexander, Lyta	Username = lalexander
Display Name = Bester, Alfred	Username = abester
Display Name = Cole, Marcus	Username = mcole
Display Name = Keffer, Warren	Username = wkeffer
Display Name = Matheson, John	Username = jmatheson
Display Name = Nafeel, Dureena	Username = dnafeel
Display Name = Takashima, Laurel	Username = ltakashima

To actually do something useful, we need to invoke what is called a cmdlet to actually add the users to the domain. The cmdlet of interest to us is called NewADUser which is reasonably documented on TechNet. Thus, we modify our script so it now reads

$nameslist = Get-Content C:\Users\zathras\Documents\users2.txt

ForEach ($name in $nameslist) {
  $first = $name.Split(' ')[0]
  $last = $name.Split(' ')[1]

  $username = $first.ToLower()[0] + $last.ToLower()
  $displayname = $last + ", " + $first
  
  New-ADUser -Name $name `
   -AccountPassword (ConvertTo-SecureString “password1!” -AsPlainText -Force) `
   -ChangePasswordAtLogon $false `
   -City "Towson" `
   -DisplayName $displayname `
   -Enabled $true `
   -SamAccountName $username `
   -Title "User" `
   -givenname $first `
   -surname $last `
   -userprincipalname ($username + “@corp.class.tu”) `
  }

Note the use of the backticks to allow for a multi-line command.

Now if you try to run this command, it will fail, but with a new error; you will see a number of lines like the following, one for each user:

PS C:\Windows\system32> C:\Users\zathras\Documents\AddUsers.ps1
New-ADUser : Access is denied
At C:\Users\zathras\Documents\AddUsers.ps1:10 char:3
+   New-ADUser -Name $name `
+   ~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo          : PermissionDenied: (CN=David Corwin...,DC=class,
DC=tu:String) [New-ADUser], UnauthorizedAccessException
 + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.UnauthorizedAccess
Exception,Microsoft.ActiveDirectory.Management.Commands.NewADUser

The catch here is that Powershell is trying to do something that requires privileges, but it does not know how to ask for them, so it simply dies. The solution? From the Server Manager, select Tools, then Local Security Policy. Navigate through Local Policies, then Security Options. Change the value of the option User Account Control: Run all administators in Admin Approval Mode to disabled; then restart the system.

At this point, your script will run happily, and you can add any number of users in one command.

OUs

In Active Directory, an organizational unit (OU) is a container for users, groups, and computers. OUs can be created around roles, around geography, around the structure of the company/organization, or around any other convenient set of distinctions.

Imagine that you are in charge of the IT staff for a small company, with a main office and three branch offices. Your company has a sales staff, a production staff, a research & development team, and an IT team. Construct three different potential OU hierarchies. What are the advantages and disadvantages of each?

To illustrate these ideas, we will create two OUs, one for the sales staff and one for the production staff. We can do the same for computers as well.

To create the OUs, from the Active Directory Users and Computers tool, right-click on the domain name and select New &rarr Organizational Unit.

For each OU you create, you need to specify the name. If you leave the check box “Protect container from accidental deletion” checked, well, then deleting the OU becomes a bit of a pain.

What? You created an OU with that box checked and now you want to delete it?

• Log on to an account that is a domain admin.
• Return to Active Directory Users and Computers
• Right-click on “Active Directory Users and Computers”
• Select View -> Advanced Features
• Navigate the tree (which is now larger), right-click on the OU and select properties.
• From the Security tab, select Advanced.
• The (usually first) entry is a Deny Everyone permission; Remove it.
• Go back to the OU name in the Active Directory Users and Computers tree; right-click and select Delete.
• Uncheck the Advanced Features in the View sub-menu if you wish.

Create at least one user in the Sales OU and one user in the Production OU.

Test the result.

Note that a user / group / computer can only be in one OU.

Note that the collection of domain controllers (seen in Active Directory Users and Computers) is also an OU- note the folder icon is the same as for the other OUs you have created.

Delegating and OUs

We can use groups within an OU as a way to delegate privileges. Suppose that our sales group has three users, Zach Allen, Lou Welch, and Michael Garibaldi. We want to enable the Michael Garibaldi user to be able to handle passwords, password resets and do simple user management, but only in the sales OU. How do we do this?

Create a group inside the OU; I am going to call it Sales Admins. The group scope can remain global; the group type should be Security. Add the Michael Garibaldi user to the Sales Admins group inside the OU. Note that, despite the name, this is still just a simple unprivileged user.

To give users inside the Sales Admins groups some privileges, right-click on the Sales OU, and select Delegate Control. A Wizard starts, called the delegation of control wizard. Select the Sales Admins group (Select Add, and type the name). Delegate some common tasks- say Create, delete and manage user accounts and Reset user passwords and force password change at next logon.

Though now the members of the Sales Admins group have these privileges, how can they be used? We did not grant these admins the right to log on to the domain controller, did we? And would that be a good thing?

What happens next depends if we are in Windows 7, or Windows 8.

In Windows 7, we must install the Remote Server Administration Tools. This is available online and on the lab share. Once the program is installed, the different components must be enabled; open Control Panel, click Programs, and then click Turn Windows features on or off under Programs and Features. If you are prompted to provide permission by User Account Control, click Continue. In the Windows Features dialog box, select the remote administration snap-ins and tools that you want to install, and then click OK.

If you wish, you may configure the Start menu to display the Administration Tools shortcut. [This is done on a per-user basis- so setting this up for one user does not set it up for all users.] Right click Start, and then click Properties. On the Start Menu tab, click Customize. In the Customize Start Menu dialog box, scroll down to System Administrative Tools, and then select Display on the All Programs menu and the Start menu. Click OK. Shortcuts for snap-ins installed by RSAT are added to the Administrative Tools list on the Start menu.

Log into your Windows 7 system as the Sales Admin user. From administrative tools, open Active Directories Users and Computers. From here, you are now able to e.g. enable and disable the account of the users from the Sales OU.

In Windows 8, the process is also similar, though you do not have to modify any Windows Features. You end up with two programs on your Start Menu- Server Manager and Administrative Tools. It is possible to use Server Manager on the client to remotely manage the domain server, but we won’t be discussing that option. The set of Administrative tools is essentially the same as what you observed on your Windows 7 system.

Group policy

Group policies are used to create and enforce different policies, including security related policies. Group policies are either local to the machine, or are based on Active Directory.

To modify the local GPO for the domain controller, from the Tools menu on Server Manager, select Group Policy Management. On a Windows 7 or a Windows 8 machine, you can run the command gpedit.msc either from the run box or from the command line.

Start by looking at the local GPO for a machine that it not connected to your domain, say a Windows 7 system. Consider the following questions

• What software settings are present by default?
• Are there any startup or shutdown scripts?
• What are the default password policies?
• What are the default account policies?
• What is the default audit policy?
• What is the significance of this from the point of view of the security of your system?
• Which users can change the system time?
• Modify this setting and test it.
• Can you rename the administrator account?
• Do it. [Hmm. I guess this probably tells you the answer to the above question. Shrug.]
• How is the Windows Firewall configured?
• What information does the Network List Manager provide?
• What software restriction policies are set by default?
• Can you set disk quotas in Windows? If so, how?

Because Group Policies can be set at different levels, it is important to know the order of precedence. It is:

• Local GPOs apply first
• Site-linked GPOs apply next
• Domain-linked GPOs apply next
• OU-linked GPOs apply last.

Note also that the “last writer wins”.

To modify domain and OU level policies, run the Group Policy Management Tool on the domain controller. Take a look at the Default Domain Policy, and check out the Settings tab. [You may receive a warning from Internet Explorer that you are viewing potentially unsafe websites; if that isn’t a metaphor for Microsoft, then I don’t know what is]

The entry we clicked above is actually a link to a Group Policy Object that can be found farther in the tree, under Group Policy Objects → Default Domain Policy.

GPOs can be filtered via security filters and via WMI filters; we will not cover these.

What are the settings in the default domain policy?

Who can modify the default domain policy? What can others do?

Creating our own GPOs

As an example, let us create a GPO that disables the screen saver controls for a user. From the collection of Group Policy Objects, select “New”. Name the policy whatever you wish; in the example I will call it “ScrenSaver”. We will not use a Source Starter GPO.

Select the policy, and view the settings. Note that initially no settings have been made. Right-click in the settings window to bring up the Group Policy Management Editor The resulting editor is very similar to the editor we saw for local policy.

Navigate through User Configuration → Policies → Administrative Templates → Control Panel → Personalization → Prevent changing screen saver. Set that value to “Disabled”.

Be sure to read the Explain Tab

Exit the Group Policy Management Editor [No, you don’t have a “Save” button.]

From the Group Policy Management console, note that apparently no changes have been made. Right click on the settings window and select “Refresh”; at ths point the changes you have already made in the GPO will become visible.

To apply this policy to a group, select an OU, (say the sales OU) and right-click; select Link an Existing GPO, then select the GPO you developed and select OK.

GPOs are pulled by the client from the server. This happens on a regular basis, but it is not immediate. The client will update their GPO settings on login, so you can refresh the set by logging off and back on. The client can also update their policy set manually by running the command gpupdate from either the command line or from the Run box.

C:\Users\salesadmin>gpupdate
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Verify that your settings have been applied to the client- you should no longer be allowed to modify the settings for the screensaver.

GPOs can also be applied to a domain, a forest, or an entire site (a collection of forests, which are collections of domains).

Adding a second domain controller

A fully functioning domain should not rely on a single domain controller. You can and should add another system as a domain controller. Moreover, to gain some experience, that second system should be a Windows 2008 R2 system. The process of setting up the 2008 R2 server is essentially the same as the 2012 server, though the GUI is a bit different. You can follow the settings discussed in these notes, but if the GUI trips you up, let me suggest looking at last year’s notes, which featured Windows 2008 R2.

Set up a static IP address and name for the backup; use the primary DNS server for DNS. Set up the name of the new server. Join the new machine to the old domain; this will add the name information to the DNS server.

Use the Add Roles Wizard to install Active Directory Domain Services on the controller. When the wizard completes, run dcpromo.exe (e.g. from the link). Select Add a domain controller to an existing domain (from Existing forest.) Select the domain; since we have only created one domain use that as the domain.

For the site, we use the default, which has the clever name “Default-First-Site-Name”.

Under additional domain controller options, be sure that both DNS server and Global catalog are checked.

Note that the setup will then tell you that an authoritative parent zone cannot be found- not surprisingly, since we are creating our own top-level domain without a parent. We do want to continue at this point…

The remaining questions can be answered in the same way we answered them for the first DC.

Take a look at the DNS settings. Note that the forward and reverse zones from the primary will have been duplicated, but not the conditional forwaders; these need to be added manually.

The settings for DNS servers on domain members are not automatically updated with the location of your new DNS server; this must be done manually on each client.

Test your new DC by shutting down the original DC; be sure that your services (AD, DNS) are still available.

Common Services

When fully configured, a Windows server will be running a number of services that will listen on a wide range of ports. Fortunately, Microsoft has provided a guide to the ports used by various services running on a Windows 2008 server.