Certificate Based Authentication against Azure AD was published GA mode last month. Here is short guide how to configure and test it.
First of all, official documentation about CBA is found links below
Certificate Based Authentication for Exchange Online
Get started with Certificate Based Authentication
CBA is now supported for both iOS and Android and eliminates username+password need for authentication.
Pre-Requirements
- Access to a certification authority (CA) to issue client certificates
- Each CA must have a certificate revocation list (CRL) that can be referenced via an Internet-facing URL
- Client certificates must be provisioned on mobile devices, typically done using MDM
- For EAS clients, the RFC822 Name OR Principal Name value in the certificate’s Subject Alternative Name field must have the user’s email address
Certificate based authentication needs to be enabled from ADFS. Because CBA is basically used only from Internet I enabled it only from extranet
Claims of Issuer and Serial Number needs to be sent to Azure AD
Azure AD – Certificate Authority needs to be published
$cert=Get-Content -Encoding byte “C:\Temp\Root CA.crt”
$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
CBA In Action
After everything is set up is time to test iOS device with certicate based authentication to Exchange Online. As pre-requirement iOS device has been enrolled to corporate Intune to achieve MDM. When enrolment has been successful Intune certificate profiles are deployed to mobile device with correct certificates
Mail Profile – installed by the EAS profile outlook.office365.com
And that’s about it. Benefit configuring Azure AD CBA for Android and iOS devices is that you can have passwordless authentication against Azure AD and Exchange Online. Digital certificate is much more secure authentication mechanism and quite easy to deploy and use from end user point of view.
Sam's Corner 
Hi Sami, how can you actually test that the certificate revocation is working correctly then? What does happen in Azure in detail when we revoke a certificate and publish the CRL?
Hi Matthias,
Excellent question! What happens in the background is the following:
Azure AD fetches the CRL list from URL provided in the certificate which is uploaded to Azure AD. What Azure AD also does is it caches the CRL. Azure AD relies on the last publish timestamp (Effective Date property) in the CRL and makes a decision based on the value is certificate valid or not. If more urgent action is needed then you can revoke the authorization token.
Does this answer to your question?
Thank you for the quick response! Did you test what happens when the certificate is revoked? What do the Azure logs then show? Does azure ad revoke all sessions of a user on all devices or is it really only related to the device he did the user authentication of and where the certificate was bound to?
Best Matthias
Hi Matthias,
Yes, I did but need to double-check my test results. I will post answers to your questions later this week.
Thanks,
Sami
Hello Mathias, when the certificate is revoked user is able to connect to the services as long as CRL’s are in cache and not updated. In a federated identity scenario, Azure AD sign-in logs don’t contain failed sign-ins from the IDP. It’s coming, but at the time of writing this is how it works
Hi thanks again for your answer. Does that mean revocation actually only has effect on ADFS and on the clients itself when CRL is updated with current revocation info? So no effect in the Azure backend at all?
This means on the opposite when the Refresh Token of the user is still valid and the client did not update its CRL or if an attacker forcibly does not update its CRLs you can still use the certificate for access as no Changes on the Refresh Token are made through backend?
Am I right?
This is very interesting stuff.
Hello again, this is quite a long reply but here we go 🙂
Does that mean revocation actually only has an effect on ADFS and on the clients itself when CRL is updated with current revocation info? So no effect in the Azure backend at all?
– It should affect all endpoints (ADFS, clients & Azure AD). All of them have CRL’s (base & delta if both are used) in their cache and they will download new CRL when it expired in the cache. If urgent action is needed then you need to revoke refresh tokens.
This means on the opposite when the Refresh Token of the user is still valid and the client did not update its CRL or if an attacker forcibly does not update its CRLs you can still use the certificate for access as no Changes on the Refresh Token are made through backend? Am I right?
– partially yes, in such case you need to revoke refresh-tokens and when the access token expires access is revoked totally (By default valid for 1 hour).
TESTS in demo environment
– Current CRL valid to 31.1.2020 6:59:34AM
– CRL publish interval changed 6 hours for the base and 3 hours for delta
– revoked user certs
– publish new crl’s
– verify that revoked user certificates are in the revocation list
– configure new service (ODfB) – ADFS auth fails because cert is revoked, got a prompt from that
– after cert was revoked, EAS authentication still works because the client and AAD have old crl in the cache and the auth flow is different than with passive clients (browser). Good picture found from here https://virtuallyaware.wordpress.com/2017/08/01/enable-or-disable-modern-authentication-in-exchange-online/
Regarding MS instructions, revoking the tokens should work but I didn’t lose access to mailbox even refresh token was invalidated. MS guidance says that resetting “StsRefreshTokenValidFrom” field should work as long as the Effective Date of the CRL is configured to a date after the value set by StsRefreshTokenValidFrom and ensure the certificate in question is in the CRL.
The problem in my own environment is that Azure AD has now CRL in the cache whose lifetime is 1 week. Even though, invalidating refresh token should work regarding docs.microsoft.com guidance. Based on my experience from MS cloud ecosystem I would rely on Conditional Access on authentication validations, also in here, Cloud App Security might do the trick because it has capabilities to identify certificates from the machine. The latter one is speculation because I don’t have an MCAS running on in this demo environment.
Feel free to drop me an email (samilamppu@hotmail.com) if you would like to continue the discussion offline 🙂
Just a quick note, access was blocked a couple of hours after tokens were revoked, not immediately.