Some time ago, the question popped in to my head, could I use a Certificate, say from an Internal PKI as part of the multi factor authentication process in Azure AD. And at the time, the answer was no; the only option available to meet this requirement for Certificate Based Authentication was to use Active Directory Federation Services.
But!! News in this past week or so, the announcement from Microsoft that Azure AD Certificate Based Authentication is in public preview. If you are currently using Certificate based authentication for apps with ADFS, this could potentially be an alternative solution for you, moving away from ADFS and saving cost and on premises infrastructure in the process.
The Microsoft documentation for this is excellent, we can now configure our Azure Tenant to allow users to authenticate with an X509 Certificate from an Enterprise CA, e.g. Internal Public Key Infrastructure. In summary, what is required?
• An Enterprise PKI with internet facing Certificate Revocation Lists (HTTP only is supported, no OCSP responder) in my example, my internal PKI.
• User Certificates from the PKI deployed to users taking note of the subject alternate name format used.
• A copy of the PKI root certificate in .cer format.
We then need to:
• Configure the Azure AD tenant – upload the PKI root certificate and define the revocation list location (I did this via powershell). Uploading the certificate should be tightly controlled, privileged authentication admin role is required – if someone managed to upload a certificate to here maliciously, you would potentially be trusting that Certificate Authority for authentications. Once complete, you can run powershell to confirm.
• In Azure Active Directory authentication settings, configure Certificate based authentication as an authentication method – here seen in preview:
• In Authentication methods, switch Certificate Based Authentication “on” – means all users in the tenant will see it as an option for logon, but for testing we can select a group or groups of users to be able to actually use their certificate for authentication.
• Configure the Certificate Issuer in the CBA settings:
• Also in Authentication settings, set the username bindings to ensure attributes used match fields in the user certificate
If you then try to log in to the Office 365 portal, assuming the correct configuration and the account being allowed to use CBA (e.g. in my pilot group) you should be prompted to sign in with a certificate, taking you to the portal.
This is a massive and exciting leap forward – another good reason to move away from old ADFS infrastructure if the Certificate Based Authentication issue was causing you to stay with this.
