Now that you have created the virtual network and virtual machines in Microsoft Azure, it’s about time to begin configuring the virtual machines themselves. In this part, we’ll configure server DC1 as an Active Directory Domain Controller (DC). We’ll also configure an Active Directory Certificate Services Certification Authority (CA).

Step 5: Configuring the external DNS records ^

Since we’ve created a cloud service (4sysops.cloudapp.net) earlier in this series, we can now configure our external DNS. For our Bring Your Own Device (BYOD) lab to be fully functional, we’ll need the following DNS records in our external DNS service:

DNS RecordTypePoints toPurpose
adfsCNAME4sysops.cloudapp.net 
wwwCNAME4sysops.cloudapp.netClaims-based apps
workfoldersCNAME4sysops.cloudapp.netWork Folders
CACNAME4sysops.cloudapp.netCertification Authority
enterpriseregistrationCNAMEadfs.demo.4sysops.comWorkPlace Join

As you can see, I’ve chosen to redirect a nice DNS domain name (demo.4sysops.com) to the cloud service (4sysops.cloudapp.net), because it’ll prevent me from making many typos while demoing the BYOD features. However, you can just use the DNS suffixes of the cloud service itself, if you want to.

Step 6: Connect to your servers ^

When you log on to manage.windowsazure.com, you’ll see the all items list on the left. This is a list with everything associated with your subscription.

After you’ve completed steps 1 through 4 in the previous articles of this series, you should see the virtual network, the cloud service, and all five virtual machines: DC1, ADFS, FileServer, WebServer, and Edge.

Note:
You’ll also see a storage account and a “default directory,” but we’re not doing anything special with these in this lab.

To connect to the remote desktop of each of these virtual machines individually, click the type, status, subscription, or license columns and click Connect in the ribbon that appears at the bottom of the webpage.

This is the fastest way to connect, but you won’t be able to integrate these remote desktop connections into your favorite remote desktop manager this way. However, you can do the following. What you need to know is that the remote desktop port for each virtual machine in a cloud service is routed to from the outside via the public virtual IPv4 address (Azure VIP address), on a dynamically assigned TCP port that is assigned to the virtual machine at creation. The TCP port can be found by clicking the name of the virtual machine in the all items list and then clicking the endpoints tab. You’ll find both a remote desktop and a remote management port.

The VIP address is connected to the Cloud Service DNS name, so you can configure your remote desktop client/manager with that information (for example, to 4sysops.cloudapp.net:58008).

Step 7: Configure the Domain Controller ^

With this information, we can connect to the virtual machine DC1. This will become the Domain Controller for our BYOD lab.

Normally, we would change the hostname of a proposed Domain Controller, configure the machine with a static IP address, and activate it. Luckily, Azure has already made sure the hostname inside the virtual machine is correctly configured as DC1, and, in Azure, we’re not supposed to configure static IP addresses to virtual machines. Also, activation is not our concern in Azure.

Good times!

So, all we need to do is check the time zone, install the Active Directory Domain Services Server Role, and promote the server to a Domain Controller. I’ve already detailed how to promote a Windows Server 2012 R2 installation into a Domain Controller, based on dcpromo.exe. This tool is quickly getting deprecated, so let’s instead use PowerShell to promote our Azure virtual machine to a Domain Controller.

After you’ve logged on to DC1, execute these commands in an elevated PowerShell window:

Replace the values for DomainName and DomainNetbiosName with values that are appropriate to your BYOD lab. You will be prompted for a safe mode admin password. After you’ve typed the password, write it down. (You never know when you might need it.)

Let the virtual machine automatically restart after promotion. After the virtual machine reboots, the server will be a fully functional Domain Controller for the Active Directory domain in our lab.

Step 8: Configure the Certification Authority ^

With a Domain Controller in place, we can focus on making all communications for your BYOD lab secure by default: we’ll create a Certification Authority (CA) that will allow us to issue certificates.

Log back on to DC1 after the restart, and execute these commands in a PowerShell window with administrative privileges:

Although many people feel that setting up a CA is hard, we’ve already covered most of it with the above two PowerShell commands. Now, let’s configure certificate revocation, the appropriate certificate templates, and the online responder:

  1. Start the Certificate Authority Microsoft Management Console (MMC).
  2. In the top left column, right-click the CA name and select Properties from the context menu.
  3. In the properties for the CA, select the Extensions tab.
  4. On the Extensions tab, select Authority Information Access (AIA), and then click Add.
  5. In the Add Location dialog, type the location http://<ServerDNSName>/ocsp, and click OK.
  6. Enable the Include in the online certificate status protocol (OCSP) extension option.
  7. Click OK and restart the service when asked.
  8. Back in the Certificate Authority MMC, right-click the Certificate Templates node in the left column, select New, and then select Certificate Template to Issue from the context menu.
  9. Select OCSP Response Signing from the list and then click OK.
    Enable Certificate Templates
  10. Back in the Certificate Authority MMC, right-click Revoked Certificates in the left column, select All Tasks, and then select Publish from the context menu.
    Publish CRL
  11. In the Publish CRL dialog, select New CRL and click OK.
  12. Close the Certificate Authority MMC.

Our CA is now equipped with the settings it needs to issue and revoke certificates, but none of our servers will be able to enroll for certificates from templates when the template ACLs are improperly configured (as they are now). Let’s enable Domain Computers to enroll for WebServer certificates, which is what all the BYOD features rely on:

  1. Start the Active Directory Sites and Services Microsoft Management Console (MMC).
  2. Expand the Services node, and then expand Public Key Services and Certificate Templates.
  3. Right-click the WebServer certificate template and select Properties.
  4. On the Security tab, add the group Domain Computers and allow Read and Enroll.
    WebServer Certificate Template Properties
  5. Click OK when done.
  6. Next, right-click the OCSPResponseSigning template and, again, select Properties.
  7. On the Security tab of this Certificate Template, add the group Domain Controllers and allow Read and Enroll. Click OK when done.
  8. Close the Active Directory Sites and Services MMC.

All we need to do now is configure the Online Responder:

  1. In Server Manager, in the grey action pane, click the tasks icon with the exclamation mark next to it. Click the Configure Active Directory Certificate Services on th… link.
  2. On the Active Directory Certificate Services Configuration window, specify the credentials for the admin account you created when you created the Azure virtual machine. Click Next when done.
  3. On the Role Services screen, enable Online Responder, click Next, and then click Configure.
  4. The Online Responder role will be automatically configured. Click Close when it’s done.
  5. Open the Online Responder Management Microsoft Management Console (MMC).
  6. In the left pane, right-click Revocation Configuration and then select Add Revocation Configuration from the context menu.
  7. Click Next > on the Getting started page.
  8. Enter a meaningful name for the Revocation Configuration and click Next >.
  9. Select Select a certificate for an Existing enterprise CA, and click Next >.
  10. Select Browse CA certificates published in Active Directory, and click Browse…
  11. In the Select Certification Authority dialog, select the Enterprise Root CA, click OK, and then click Next >.
  12. On the Select Signing Certificate page, select Automatically select a signing certificate, enable Auto-Enroll for an OCSP signing certificate, and then click Next >.
  13. Click Finish to end the wizard.

Now restart the DC1 virtual machine.

Concluding ^

You’ve probably done this a couple of times before, as these are steps admins in non-BYOD environments also perform to set up an Active Directory domain with a Certification Authority.

Join me for Part 4, where we extend this typical on-premises setup to the cloud by adding Active Directory Federation Services.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

0
Share
0 Comments

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account