Tuesday 13 January 2015

AD FS 3.0 and Hardware Load Balancers Compatibility with TLS SSL SNI

For organisations considering the move to Office 365, you will probably have explored the requirement for Active Directory Federation Services (AD FS) to provide Single Sign On (SSO) to your domain users when connecting to Office 365 services. Without AD FS in place to federate and project users domain credentials to Office 365, users would have to maintain a separate set of logins details for both the domain and Office 365.

If you have looked at AD FS and are planning on deploying it on Windows Server 2012 R2, with hardware-load balancers I suggest you read and understand this post in full. Active Directory Federation Services in Windows Server 2012 R2 is currently at version 3.0. This is different to even Windows Server 2012, which was shipped with AD FS 2.1.  You can off course use Windows Network Load Balancing to load balance AD FS but I am sure you will agree for a component as important as AD FS a dedicated appliance would be better. If you decide to deploy AD FS, it is vital the service is highly available, if for whatever reason your AD FS infrastructure goes down on-site users will not be able to access O365 services.

One of the improvements in AD FS 3.0 is built-in compatibility for Server Name Indication (SNI), which is an extension of the TLS element of the SSL protocol. Although AD FS 3.0 supports SNI not all networking equipment and end devices do. SNI allows multiple SSL certificates to be bound to the same IP Address and Port Number, which allows support for multiple SSL (or HTTPS) connections to the same address.

SNI works by providing application server host names during the SSL handshaking phases, thus allowing multiple HTTPS applications to reside behind a single IP Address.

Although AD FS 3.0 supports the SNI feature, not all hardware load balancers do. It is important to consider this when making a purchasing decision for your hardware load balancers.

At the time of writing the following servers do offer support for SNI:

Citrix NetScaler 9.2 or higher
F5 Networks Local Traffic Manager, version 11.1 or higher
KEMP Load Balancers (as of October 2014)
Apache 2.2.12 or higher
Apache Traffic Server 3.2.0 or higher
Apache Tomcat on Java 7 or higher
Microsoft Internet Information Server (IIS) 8

Web browsers also require support for SNI; all of the recent versions of Internet Explorer from 7 onwards support SNI along with Google Chrome and Mozilla Firefox.

Windows Server 2012 "Features on Demand": Configuring Static Path to “WinSxS” Folder via Group Policy

In my lab I tend to spin up loads of Windows Server 2012 R2 servers to test various things. One thing that always causes me frustration is having to manually point the \sources\sxs folder when installing a new Server Role, via Server Manager or PowerShell.  Its frustrating because I normally forget to do it, and the installation fails and I need to start again.

To configure a network based copy of the SXS folder and have it automatically mapped via GPO, first copy the \sources\sxs folder from the DVD media to somewhere you can share the folder from. Then configure the share and NTFS permissions, I have allowed Full Control to Everyone on the share permissions, and Full Control to Domain Computers on the NTFS permissions.



As I want this setting to be global across the domain I am going to put the setting in the Default Domain Policy open the GPMC and edit the GPO you want to host the settings.


Expand Computer Configuration/Policies/Administrative Templates/System and double click on the policy Specify settings for optional component installation and component repair.


Click the Enable button and enter the UNC path to the SXS folder you copied over, if the access permissions are not configured correctly this obviously will not work. Click Apply and OK.


Now when you try to install Server Roles or Features via Server Manager or PowerShell the machine will have a known location for the required binaries.


Thursday 8 January 2015

Active Directory Certificate Services (AD CS): The Revocation Function was Unable to Check Revocation Because the Server was Offline 0x80092013 (-2146885613 CRYTP_E_REVOCATION_OFFLINE)

You are configuring an Active Directory Certificate Services (AD CS) infrastructure, and you are at the point where you are importing the certificate that was generated by your certificate request from the Root CA. When you try to use the Import CA Certificate from the Certificate Authority MMC you receive the following error "The Revocation Function was Unable to Check Revocation Because the Server was Offline 0x80092013 (-2146885613 CRYTP_E_REVOCATION_OFFLINE)."

This was because when I configured the CDP and AIA information when I was configuring the Root CA I added HTTP locations for the Issuing CA.
When I look at the certificate that I am trying to import, under CRL Distribution Points there are two listed. The Offline CA currently has no network connectivity, therefore it cannot resolve that one, even if it could it will be taken offline after the initial configuration of the AD CS infrastructure. Notice how there is a URL pointing to the Issuing CA.

The problem here was I had forgotten to copy the CRL file generated from the Root CA into the IIS Web Server folder on the Issuing CA. 

Once I copied the CRL file over to the Web Server folder that was accessible in the CRL Distribution Points URL I tried starting the AD CS service again.


Implementing a two-tier Active Directory Certificate Services (AD CS) infrastructure on Windows Server 2012 R2

When AD CS is deployed in a two tier fashion there is a “Standalone Root” certificate authority that is not part of the domain. This server is used to issue a root certificate to an online issuing CA which is part of the Active Directory domain. The Root CA is usually turned off or disabled once the initial certificate has been issued and imported into the issuing CA, this increases security as the private key for the original Root Certificate is not available, therefore mitigating the risk of the trust chain being breeched.



As the issuing CA uses the Root CA certificate to sign all the subordinate certificates, if the private key for the original Root CA certificate is compromised the entire trust chain would be vulnerable and effectively all certificates would be untrusted. Therefore taking the Root CA offline entirely mitigates against this. The Root CA will only be required again when the CRL requires digital signing, or when the original Root CA certificate needs renewed.

GPO’s will be configured to auto enroll domain joined computers and users with trusted digital certificates. In addition to this any services, such as IIS websites will be able to request SSL certificates from the AD CS infrastructure. The AD CS CRL will be published both internally and externally to allow certificate validity checking automatically, from within the domain or from the public internet. CRL’s are complete, digitally signed lists of revoked certificates that are published to an IIS website to allow clients to check if their certificates are valid before authenticating various services.

Although all certificates are issues with a validity period, in some cases certificates must be revoked immediately for a number of reasons such as a device being lost or compromised. In this case revoked certificates are added to the CRL and when a client looks up the CRL to check its validity if the thumb print of the certificate is listed in the CRL a connection will not be granted to that user or computer. In the case of SSL certificates for Web Services a certificate warning is disabled to users accessing websites or service if the associated certificate has expired or has been revoked.

The Issuing CA will also host the CRL therefore the appropriate external NAT rules will be configured to present the IIS Virtual Directory hosting the CRL to the public internet.

Although setting up a two-tier AD CS infrastructure is fairly straight forward there is 1001 steps to get it working therefore I have decided to write this post so that I can refer back to it when I need to do it next. The scenario is straight forward, there is an offline root CA and an online issuing CA. The Certificate Revocation Lists are published as an IIS website on the issuing CA, in addition to this I have configured the Online Certificate Services Responder (OCSP).

I have provisioned two Windows Server 2012 R2 Standard servers, the first step is to get the Certificate Services role installed on the offline CA. You can use the following PowerShell command;

Add-WindowsFeature ADCS-Cert-Authority –IncludeManagementTools

Alternatively you can use the Server Manager GUI.


Once it is installed there will be a prompt inside Server Manager stating that the AD CS role requires configuring. Click the link. On the Credentials screen click next, as the offline CA should not be part of the Active Directory domain you will notice the credentials are listed as the local Administrators for that server. Click Next.



As this server is only the offline CA, the only role service that is required is the Certificate Authority.



Again as this server is not a member of the domain the only chose here is to configure it as a Standalone CA, click Next.



Select Root CA and click Next.



Ensure that the Create a new Private Key option is selected and click Next.



For maximum security I always change the hashing algorithm to SHA256 and the Key Length to 4096.



Do not alter any of the CA Name fields, the Distinguished name suffix is not populated on purpose, the issuing CA will automatically publish it’s own AD DN in this field, click Next.



The amount of time you configure for the certificate to be valid is entirely up to you, as this is the root CA certificate I have chosen 10 years. Please remember when this certificate expires all of the certificates that use this in the trust chain must be reissued. Do not make this something like 5 days……..



Keep the database locations at their default click Next.



Review the settings and click Configure.



The next step is to configure the CRL and AIA info, open up the Certificate Authority on the offline CA and right click on the OFFLINECA-CA and select Properties. From the Properties window click on the Extensions tab.



Click Add and configure a new location to point to your issuing CA in my example the full path is

http://issuing-ca.company.com/CertData/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

You would change this to the FQDN of your issuing CA in your domain. Please note the /CertData folder is a folder we will create in the wwwroot folder on the issuing CA in a future step. It is important that the extension is .crl



Ensure the Include in CRL’s Client use this to find Delta CRL locations and Include in the CDP extension of issued certificates options are selected and click Apply. Then from the Select Extension drop down select AIA then click Add.



Do the same again for AIA but use the following syntax

http://issuing-ca.company.com/CertData/<ServerDNSName>_<CaName><CertificateName>.crt

It is important to note that the file extension on the AIA configuration is .crt and not .crl like on the CDP configuration screens.



Click Apply.



You will be prompted to restart the Active Directory Certificate Services, click Yes.



Now return to the Certificate Authority console on the root CA and right click on the Revoked Certificates folder and select All Tasks and then Publish.



Select the New CRL option and click OK, this will generate the required .crl and .crt files and drop them into the C:\Windows\System32\CertSrv\CertEnroll folder by default.





Again from the Certificate Authority console right click on the root CA and select Properties.



Click on the General tab and then View Certificate.



On the certificate properties window click on the Details tab and click on Copy to File…



Follow the Certificate Export Wizard remembering to choose DER Encoded Binary x.509 (.CER).



You must specify a location to export the certificate I always use the same path as the CRL’s as all of these files need copied to the issuing CA.



The Root CA certificate will have been exported into the chosen output folder.



Now move across to the Active Directory joined issuing CA and copy the all three of the files from the offline CA to somewhere accessible on your network, they should be like shown below. 



Now open the Group Policy Management console from a Domain Controller, expand domains and right click on your domain and select Create New GPO and Link it Here. Obviously if you have other GPO’s in place you can just add these settings to one of them. When you have selected the GPO you are going to use Edit it.



In the GPO Editor, expand Computer Configuration/Windows Settings/Security Settings/Public Key Policies right click on Trusted Root Certification Authorities and select Import.



From the this window you must point to the Root CA certificate, this is the file we just exported and not the .crl or .crt files.



Click OK and the Root CA certificate should be configured to be deployed via that GPO. This is required because the offline CA is not a member of the domain therefore cannot self-publish information about itself.



The offline CA is now configured the next phases is to install the AD CS role on to the issuing CA and then configure the role.



Click Certificate Authority.



As this is the issuing CA select Enterprise CA. In AD CS for a server to become an Enterprise CA it must be part of a domain.



Most issuing CA’s are Subordinate CA’s as there is a certificate authority server above them in the trust chain.



Create a New Private Key.



Set the algorithm and key length to SHA256 and 4096.



The values in the CA Name fields should auto-populate, you will notice the DN field has a domain value where the offline CA did not.



Select Save a Certificate Request File on Target Machine.



Leave the CA Database locations at their defaults.



Click Configure.



You will receive the following warning, this is because the issuing CA has not be issued a valid certificate from the Root CA after the certificate request was generated. This is soon to be resolved.



A certificate REQ file will then appear in the folder in which you configured using Browse. You must copy this file to your offline CA so that it can generate a certificate based on the request file.



When you have the REQ file on the offline CA open the Certification Authority console and right click on the sever and select All Tasks and Submit new request…



Browse to the REQ file you have just copied from the issuing CA.



Then from the Certification Authority on the offline CA click on Pending Requests, at this stage there should only be one request pending. Right click on it and select All Tasks then Issue.



All going well the CA should issue the certificate and you should be able to see it under Issued Certificates.



We must then export this certificate from the Root CA and import it into the issuing CA, you do this by double clicking on the certificate from the Issued Certificates pane. From the Details tab you can then use the Copy to File… option.



When you export the certificate ensure you change the Export File Format to Cryptographic Message Syntax Standard – PKCS 7 Certificate (.P7B)



Point it to a suitable location to generate the file.





Now copy that newly generate file onto the issuing CA.



You must now install the IIS (Web Server) role on the issuing CA to host the CRL’s, you can do this from Server Manager.



Once IIS is installed on the root of C:\ there will be a folder called inetpub, from inside that folder go into the wwwroot folder. From inside here right click and create a New Folder, if you copied the syntax when configuring the CRL info, ensure the folder is called CertData. Copy both the .crl and .crt files that were generated by the offline CA into this folder.



Now open the Certificate Authority console on the issuing CA and right click on the server object and select All Tasks and Install CA Certificate…



Browse to the Cert file that was generated by the offline CA from the REQ file and click Open.



You will receive the following error, this is normal therefore click OK.



Right click on the issuing CA once more and select All Tasks and then Start Service.



Provided you have configured everything correctly the issuing CA should report no further errors and it should become operational.



One more set of step is optional, but recommended. Return to Server Manager on the issuing CA and install the Online Responder role service.



Return to the CA console and click Certificate Templates right click inside the pane and select Manage.



Scroll down and find the OCSP Response Signing template, right click on it and select Properties.



Click on the Security tab and select Authenticated Users and ensure they have Full Control, you would perhaps give this more thought in your production environment. Click OK and Apply.



Return back to the Certificate Template pane and right click, select New and then Certificate Template to Issue.



Choose the OCSP Response Signing from the list and click OK.



Once you have installed the OCSP role service you should see an icon to launch the MMC console, when you do right click on Revocation Configuration and select Add Revocation Configuration.





The name is not important here.



Ensure Select a Certificate for an Existing Enterprise CA is select and click Next.



Click Browse CA certificates published in Active Directory, click double click on the issuing CA from the list.



If you have configured the permissions on the OCSP template correctly it should auto-detect you want to auto-enroll using that certificate.



Click Provider...



Then click Add and input the FQDN to your CRL if you have followed this guide from the beginning it will be at the same path as mine, simply change the FQDN of your issuing CA.


http://issuing-ca.company.com/CertData/OFFLINECA-CA.crl

   



Click OK.



If you have configured everything correctly the Online Responder Configuration should report a state of Working.