To give and extra layer of security for Office 365, a customer wanted to enforce Certificate Authentication. In summary they did not want anyone to be able to log in to Office 365 from an extranet connection on a device that did not have a certificate issued by their internal PKI. The customer used existing Active Directory Federation Services (ADFS) to authenticate to their live Office 365.

Testing this on their live tenant was more risk that than they were prepared to accept, so the decision was made to stand up a new ADFS test environment and use a spare domain and Office 365 tenant to prove the concept. This blog details the setting up of the test environment and it involved 5 main steps:

• Setting up a test ADFS environment
• Configuring test user and a test O365 tenant
• Federating the test O365 tenant to use the test ADFS
• Configuring and deploying test Certs for Authentication
• Configuring certificate authentication on the test ADFS environment

Build of ADFS components

The following pre-requisites were needed:

• New test ADFS servers residing on the corporate network.
• New test Web Application proxy servers residing on the DMZ.
• Creation and configuration of an internal and an external load balancer.
• A service account for ADFS.
• Setting of Service Principal name on the ADFS service account
• A decision on a Federation services name e.g. adfs.company.com, and appropriate records added to internal and external DNS.
• The Internal Root and Intermediate Certificates from the relevant CAs should reside the appropriate stores on the ADFS and WAP servers.
• A 3^rd party SSL certificate is required containing the name of the Federation service, this should be installed on the ADFS and WAP servers.
• Make sure the ADFS and WAP servers can see the 3^rd party and Internal CA CRLs.
• Ports 443 (SSL) and 49443 (certificate auth) open between ADFS and WAP servers
• Ports 443 (SSL) and 49443 (certificate auth) open between Clients and WAP servers

ADFS Server Install

This meant we were ready to install the test ADFS and WAP servers. The steps for this are readily available by asking your favourite search engine, but some top tips:

• Install one “Primary” ADFS server first and when it is working, install the second.
• The install can be verified by looking for event ID 100 in the AD FS event log.
• Also, the ADFS server should be serving an XML page through its federation name: e.g. https://adfs.company.com/adfs/fs/federationservice.asmx if this displays an XML page it is working as it should.
• I do not always trust load balancers! So, if there are issues, amend the host file of the machine you are trying to connect to the URL from so that the URL is pointing directly at that server. Just remember to change it back.

Installing a second ADFS server is similar to the first; point at the federation service name and go. The install can be verified in the same ways.

Testing the sign on page

In Windows 2016 ADFS, the IDPInitiatedsignon page is disabled by default. This can be enabled by running the following:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

(Perform Get-AdfsProperties to confirm this has worked) Netstat and Netsh commands can also be used to check the servers are listening on the right ports e.g. 443 and 49443.

Navigate to the following URL from the ADFS server itself, a test client on the network and the Web Application proxy servers: https://adfs.company.com/adfs/fs/idpinitiatedsignon.htm they should all be able to access the sign on page. If not, go back and check firewalls or use host file entries to bypass load balancers to work out the issue.

WAP Server Install

Again, the detailed steps for this I shall not go in to, but watch out for:

• Make sure all the 3^rd party SSL, root, intermediate internal CA certificates are installed in the right stores and the CRLs are visible to the WAP server
• As the WAP server is on a DMZ you may need to add a host file entry for the federation name containing the internal load balancer IP address. HOWEVER we found that this caused the WAP server install to have issues. So consider pointing the federation name to the primary ADFS server during the WAP server install, and change back once the install is complete.
• You should be able to verify the WAP server install from the remote access console on the WAP server, and when the 2^nd WAP server is added should show as load balanced.

ADFS backup

Have a look for the ADFS Rapid Restore Tool. It is worth running this as a means of backing up the configuration on a regular basis if required.

Office 365 test setup

As previously mentioned, the customer did not want to use their live Office 365 tenant for testing; they did however have a spare domain name and test Office 365 tenant. Once this was configured with some test users, we could configure it to use the new test ADFS environment.

• We added the spare domain to the test Office 365 tenant.
• We configured a new OU on premises containing test users with the spare domain UPN set. “sparedomain.company.com”
• We configured a new AD connect server to sync only test users in the test OU to the test O365 tenant.
• Eventually, we could see the on premises test users synced in to the new tenant.

Configuring Office 365

Office 365 can be configured to use on premises Active Directory for Authentication via ADFS. To do this the Office 365 domain needs to be configured. It is important to note that if the on premises ADFS infrastructure is unavailable, Office 365 sign in will not be able to complete….

So, we configured the Office 365 test subscription to use the adfs.company.com ADFS as follows

• Connect to the test O365 tenant from PowerShell (I’m assuming you’ve installed the MSonline powershell modules from where you are doing this?)
• Did a get-msoldomain and check the domain list that the spare domain is Verified and Managed e.g. sparedomain.company.com
• Did a get-msolfederationproperty -domainname sparedomain.company.com. This should return that this domain is not part of any ADFS configuration.
• Once confirmed run Convert-MsolDomainToFederated -DomainName sparedomain.company.com.
• Run the same get commands as previous to confirm the domain has been federated and is showing the additional details in the msolfedarationproperty command.
• You can see in the ADFS console that performing those commands has added an Office 365 Platform Relying Party Trust.

At this point we did a little test. Going to the Office 365 portal and logging in as the synced user in the test tenant, I was able to see that I was being authenticated via the test ADFS URL. So it’s working with the defaults, now for the certificate bit.

Phew!

Right then nearly there. We have the test ADFS servers and the O365 tenant, and we’ve federated and tested. The point of this though is we don’t want people using their corporate Office 365 unless they have an appropriate certificate on their device.

Certificate for authentication

Based on Microsoft Guidance, a duplicate of the user certificate template was made and configured as follows. It can be deployed to windows devices via a group policy autoenrollment policy and other devices via mobile device management mechanism is used. The template you are creating can be left mostly as default apart from:

• Change the validity period to an agreed value for the organisation on the general tab
• On the request handling tab, deselect allow private key to be exported
• On the extensions tab, application polices extension, remove EFS and Secure email just leaving “client authentication”
• On the security group, add in the group(s) that require permission to get this template – read, enrol and Autoenroll.
• Publish the template on all required CAs
• Make sure the client you are pulling the cert down to also has the relevant root and issuing CA certificates present, and that clients can see the relevant CRLS.

If an autoenrollment policy is configured via GPO then the cert should appear in the user personal store (Certificates MMC > User > Personal) or the certificate can be manually requested from the Certificates MMC. Either way it needs to be in that user personal store.

Configure ADFS to require Certificates to authenticate

We now want to switch ADFS to require users coming in from extranet to have a valid certificate to authenticate. This can be done from the ADFS console

• In Authentication Methods, choose to Edit “Primary Authentication Methods” to show the Primary tab. Select Certificate Authentication from the Intranet / Extranet box, and clear all other methods.
• From Authentication Methods, choose to Edit “Multi Factor Authentication Methods” to show the Multi Factor Tab. Select Certificate Authentication only.

Ta dah!

At this point ADFS and Office 365 are configured, and the laptop the test user is using has a certificate. Some basic tests:

You’re not coming in….

• On an extranet connection, no authentication cert present, logged on to a corporate device with the test user and going to the Office 365 portal, we could see the test ADFS URL being used but received an error saying there was no valid certificate.
• On an extranet connection and a 3^rd party device with no authentication cert, going to the Office 365 portal and attempting to log in with the test user O365 credentials we could see the test ADFS URL being used but received an error saying there was no valid certificate.
• Tried to export an authentication certificate from a corporate machine and install on the 3^rd party device, but it did not have the right certificate chain nor was the private key exportable from the template, so on an extranet connection attempting to log in with the test user O365 credentials we could see the test ADFS URL being used but received an error saying there was no valid certificate.

YES!!

• On an extranet connection, logged on to corporate device with the authentication cert in place as the test user and going to the Office 365 portal, we could see the test ADFS URL being used when the certificate was present and going straight through to the portal page.

Finally

This is just a basic bit of testing having set up a test environment. Obviously there needs to be lot more testing, as well as considerations regarding getting certificates out there especially to nonstandard devices, also a great deal more testing of applications and so on needs to be done before the switch can be flicked to use in live. But it’s a starter!