How to Setup Active Directory Certificate Services 2016 in Azure (AD CS) IaaS

How to Setup Active Directory Certificate Services 2016 in Azure (AD CS) IaaS

To setup Active Directory Certificate Services in Azure IaaS use our virtual machine template solution to get up and running quickly.  This virtual machine offering will allow you to build a new Root CA or a Subordinate CA to establish a PKI hierarchy within Azure.

PKI Planning

When designing your PKI solution you will have to determine the hierarchy that you will use. There are generally three types of hierarchies, and they are denoted by the number of tiers.

Single/One Tier Hierarchy

Setup Active Directory Certificate Services in Azure

A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility. 

Two Tier Hierarchy

Two Tier Hierarchy

A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical locations (Azure regions or Subscriptions or Vnets etc), as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s. 

Three Tier Hierarchy

Three Tier Hierarchy

Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.

 

The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.

 

Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage.

 

Setup

 

Once you’ve deployed the AD CS 2016 from the Azure marketplace, login to the VM and open up “Server Manager”.

 

First task is to decide if this will be an Enterprise CA or Standalone CA.  If it will be an Enterprise CA then you will need to add this VM to your Active Directory domain otherwise you can leave as a member server and run as a Standalone CA.

 

Next is to run the setup wizard from the notification alert in Server Manager

server-manager-adcssetup

  1. On the Credentials page, you can see Administrator is displayed in the Credentials box. Click Next.
    credentials.png
  2. On the Role Services page, select the Certification Authority check box Click Nextcertificate-authority
  3. On the Setup Type page, select Enterprise CA as the CA type to allow integration with your AD Or Standalone CA if your want to run this as a member server in a workgroup.
    Setup_type.png
  4. On the CA Type page, Select Root CA if this is the first CA in your environment or Subordinate CA if you have an established PKI already, Click Next.
    CA_type.png
  5. On the Private Key page, choose between Create a new private key or Use existing private key. Click Next.
    Private_key.png
  6. On the Cryptography for CA page,
    1. Select the default cryptographic provider as RSA#Microsoft Software Key Storage Provider.
    2. Select Key length as 2048 or above.
    3. Select SHA1 as the hash algorithm and click Next.

    Cryptography_for_CA.png

  7. On the CA Name page, specify the name of your CA in the Common name for this CA text box.
    CA_name.png
  8. On the Validity Period page, select the number of years for the certificate to be valid.
    Validity_period.png
  9. On the CA Database page, specify the locations for the database and database log files. Click Next.
    CA_database.png
  10. On the Confirmation page, click Configure. Results screen appears after configuration is complete.
    Confirmation.png

 

Firewall Rules

 

If you have a network security group or firewall appliance in front of your new AD CS virtual machine you’ll need to check you have the following firewall ports open:

 

Below is a list of ports that need to be opened on Active Directory Certificate Services servers to enable HTTP and DCOM based enrollment

 

Protocol

Port

From

To

Action

Comments

Kerberos

464

Certificate Enrollment Web Services

Domain Controllers (DC)

Allow

Source Certificate Enrollment Web Services

Destination: DC

Service: Kerberos (network port tcp/464)

LDAP

389

Certificate Enrollment Web Services

Domain Controllers (DC)

Allow

Source Certificate Enrollment Web Services

Destination: DC

Service: LDAP (network port tcp/389)

LDAP

636

Certificate Enrollment Web Services

Domain Controllers (DC)

Allow

Source Certificate Enrollment Web Services

Destination: DC

Service: LDAP (network port tcp/636)

DCOM/RPC

Random port above port 1023

·       Certificate Enrollment Web Services

·        All XP clients requesting certs

CA

Allow

Please see for details on RPC/DCOM configuration:http://support.microsoft.com/kb/154596/en-us

HTTPS

443

All clients requesting certs

Certificate Enrollment Web Services

Allow

Source: Windows 7 client

Destination:

Service: https (network port tcp/443)

Certificate Enrollment Web Services

 

Deploy Certificates

 

Once you have your CA setup, you’re now ready to start deploying certificates. The following article has a great tutorial on this:

https://blogs.technet.microsoft.com/askds/2010/05/27/designing-and-implementing-a-pki-part-iii-certificate-templates/

Support

 

If you have any questions about this Active Directory Certificate Services deployment or are experiencing any issues with your deployment leave your comments below and i will answer them for you within 24 hours.

 

If you would like to hire us to setup your AD CS PKI environment for you, get in touch and we can get you up and running 

Andrew Fitzgerald

Cloud Solution Architect. Helping customers transform their business to the cloud. 20 years experience working in complex infrastructure environments and a Microsoft Certified Solutions Expert on everything Cloud

No Comments

Post a Comment

Comment
Name
Email
Website