- Turn the tables on your organization with Adaxes 2018.1's Web Interface and reporting capabilities - Thu, Sep 20 2018
- Review: Softerra Adaxes - Automating Active Directory management - Thu, Jun 4 2015
- Azure Multi-Factor Authentication - Part 8: Delegating Administration - Tue, Apr 28 2015
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 Record||Type||Points to||Purpose|
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.
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.
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:
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSForest -DomainName "demo.4sysops.com" -ForestMode 5 -DomainMode 5 -DomainNetbiosName "4sysops"
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:
Install-WindowsFeature ADCS-Cert-Authority,ADCS-Online-Cert –IncludeManagementTools Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CACommonName 4SysopsCA -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -KeyLength 2048 -HashAlgorithmName SHA1 -ValidityPeriod Years -ValidityPeriodUnits 5
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:
- Start the Certificate Authority Microsoft Management Console (MMC).
- In the top left column, right-click the CA name and select Properties from the context menu.
- In the properties for the CA, select the Extensions tab.
- On the Extensions tab, select Authority Information Access (AIA), and then click Add.
- In the Add Location dialog, type the location http://<ServerDNSName>/ocsp, and click OK.
- Enable the Include in the online certificate status protocol (OCSP) extension option.
- Click OK and restart the service when asked.
- 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.
- Select OCSP Response Signing from the list and then click OK.
- 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.
- In the Publish CRL dialog, select New CRL and click OK.
- 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:
- Start the Active Directory Sites and Services Microsoft Management Console (MMC).
- Expand the Services node, and then expand Public Key Services and Certificate Templates.
- Right-click the WebServer certificate template and select Properties.
- On the Security tab, add the group Domain Computers and allow Read and Enroll.
- Click OK when done.
- Next, right-click the OCSPResponseSigning template and, again, select Properties.
- On the Security tab of this Certificate Template, add the group Domain Controllers and allow Read and Enroll. Click OK when done.
- Close the Active Directory Sites and Services MMC.
All we need to do now is configure the Online Responder:
- 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.
- 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.
- On the Role Services screen, enable Online Responder, click Next, and then click Configure.
- The Online Responder role will be automatically configured. Click Close when it’s done.
- Open the Online Responder Management Microsoft Management Console (MMC).
- In the left pane, right-click Revocation Configuration and then select Add Revocation Configuration from the context menu.
- Click Next > on the Getting started page.
- Enter a meaningful name for the Revocation Configuration and click Next >.
- Select Select a certificate for an Existing enterprise CA, and click Next >.
- Select Browse CA certificates published in Active Directory, and click Browse…
- In the Select Certification Authority dialog, select the Enterprise Root CA, click OK, and then click Next >.
- On the Select Signing Certificate page, select Automatically select a signing certificate, enable Auto-Enroll for an OCSP signing certificate, and then click Next >.
- Click Finish to end the wizard.
Now restart the DC1 virtual machine.
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.
Subscribe to 4sysops newsletter!
Join me for Part 4, where we extend this typical on-premises setup to the cloud by adding Active Directory Federation Services.