Certificate-based authentication is generally available!
Microsoft announced today at Ignite 2022 that Certificate-Based Authentication is officially out of preview and ready to use!
Why CBA was created?
"In May of 2021, the President issued Executive Order 14028, Improving the Nation’s Cybersecurity calling for the Federal Government to modernize and adopt a Zero Trust architecture including phish resistant multi-factor authentication (MFA) for employees, business partners, and vendors."
Executive Order on Improving the Nation’s Cybersecurity | The White House
Read more from Alex Simons announcement
Azure AD Certificate-Based Authentication now in Public Preview
But certificate-based authentication helps us all, let's see how.
What is CBA?
- Facilitates on-boarding to Azure quickly without being delayed by additional on-premises infrastructure to support certificate-based authentication in public and United States Government clouds.
- Provides support for unphishable multi-factor authentication.
- Supports user sign-in against cloud Azure AD using X.509 certificates into all web browser-based applications and into Microsoft Office client applications that use modern authentication.
- The feature works seamlessly with Conditional Access features such as MFA to help secure your users.
- It's a free feature, and you don't need any paid editions of Azure AD to use it.
- Eliminates the need for federated AD FS and reduces the cost and on-premises footprint.
How the authentication works?
Enabling CBA
Open your Entra admin center and enable CBA
And then
Or with PowerShell and Graph
Import-Module Microsoft.Graph.Identity.SignIns $params = @{ "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration" Id = "X509Certificate" CertificateUserBindings = @( ) IncludeTargets = @( ) ExcludeTargets = @( ) State = "enabled" } Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -AuthenticationMethodConfigurationId $authenticationMethodConfigurationId -BodyParameter $paramsOr just graph
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
How to setup?
If You just open the CBA page and select Add rule, You will get a warning.
And this is because You have to first add the Certification Authority's CRL distribution point with PowerShell.
In my example I used my own PKI which I published with Application Proxy.
Here's an excellent article from Michael Niehaus on publishing Certificate Revocation Lists with Application proxy.
Publish Certificate Services CRL and OCSP sites to the internet using Azure App Proxy
I will just make couple of additions. You can use Your own custom domain by adding the FQDN to custom domains. If You already have the suffix just add the prefix and don't have to even verify it.
And here the PowerShell One-liner Michael is using.
New-AzureADApplicationProxyApplication -DisplayName "MyApplicationName" -ExternalUrl "http://YourPreferredFQDN/certenroll/" -InternalUrl "http://YourCAName/certenroll/" -ExternalAuthenticationType Passthru
And last but not least, You can now add HTTP redirection also.
So Finally You will have these inside Your CA-Root extensions.
Continuing the setup
You will find the CRL point from the certificate that was generated under CRL Distribution Points field.
And for AIA also
Trusted CA's
PowerShell
Adding the you root-ca with PowerShell
$cert=Get-Content -Encoding byte "YourPath\YourCA-root.cer" $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert $new_ca.crlDistributionPoint="http://mycrl.cloudpartnerdemo.fi/CertEnroll/myca.crl" New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
When You run the commands.
Or with GUI
Previously we didn't have a possibility to add certificates with GUI but not there is.
First you have export your ca-root cert as .cer (x.509) and upload it to Azure and select the CRL URL's + CRL filename
Yes, I will show my CRL's here, not to worry, the certificates have already been revoked.
Once done, it will look like this.
When You have Certificate and CRL published, You can go and select the certificate.
Once You add the rule You will see the selected certificate.
You can select default protection level between Single or Multi-factor.
Understanding the username binding policy
The username binding policy helps locate the user in the tenant. By default, Subject Alternate Name (SAN) Principal Name in the certificate is mapped to onPremisesUserPrincipalName attribute of the user object to determine the user.
An administrator can override the default and create a custom mapping. Currently, we support two certificate fields SAN Principal Name and SAN RFC822Name to map against the user object attribute userPrincipalName and onPremisesUserPrincipalName.
Rules applied for user bindings:
Use the highest priority (lowest number) binding.
- If the X.509 certificate field is on the presented certificate, try to look up the user by using the value in the specified field.
- If a unique user is found, authenticate the user.
- If a unique user is not found, authentication fails.
- If the X.509 certificate field is not on the presented certificate, move to the next priority binding.
- If the specified X.509 certificate field is found on the certificate, but Azure AD does not find a user object in the directory matching that value, the authentication fails. Azure AD does not attempt to use the next binding in the list in this case.
To flat the explanation out, You will sign in with the user having an account inside Azure AD and requesting a certificate for that user, When you have the users UserPrincipalName inside the certificate, You can logon with it.
Supported scenarios
The following scenarios are supported:
- User sign-ins to web browser-based applications on all platforms.
- User sign-ins on mobile native browsers.
- Support for granular authentication rules for multifactor authentication by using the certificate issuer Subject and policy OIDs.
- Configuring certificate-to-user account bindings by using the certificate Subject Alternate Name (SAN) principal name and SAN RFC822 name.
Unsupported scenarios
The following scenarios aren't supported:
- Public Key Infrastructure for creating client certificates. Customers need to configure their own Public Key Infrastructure (PKI) and provision certificates to their users and devices.
- Certificate Authority hints aren't supported, so the list of certificates that appears for users in the UI isn't scoped.
- Windows login using smart cards on Windows devices.
- Only one CRL Distribution Point (CDP) for a trusted CA is supported.
- The CDP can be only HTTP URLs. We don't support Online Certificate Status Protocol (OCSP), or Lightweight Directory Access Protocol (LDAP) URLs.
- Configuring other certificate-to-user account bindings, such as using the subject field, or keyid and issuer, aren’t available in this release.
- Currently, password can't be disabled when CBA is enabled and the option to sign in using a password is displayed.
Troubleshooting
If you are trying out the new feature, you can disable the revocation list verification (Only for test, please don't do this in production as it will make your certificates validation useless)
$root=Get-AzureADTrustedCertificateAuthority $root. crlDistributionPoint =”” Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $root
Some notes from the feature:
- Certificate-based authentication is a free feature. Every edition of Azure AD includes Azure AD CBA.
- UserPrincipalName is the only attribute that can be used.
- Only one CDP is supported per CA.
- Once enabled, it may take up to an hour for the changes to be effective.
- You can disable Revocation list check, although it’s not preferred by any means and should be only considered for debugging scenarios.
Troubleshoot Azure AD certificate-based authentication without federation (Preview) - Azure Active Directory - Microsoft Entra
Revocation of certificates
Azure Active Directory downloads and caches the certificate revocation list (CRL) from the URLs uploaded with the certificate authority information in order to cancel a client certificate. The CRL's effective date (latest publish timestamp) is used to determine whether the CRL is still in effect. Access to certificates that are included in the list is periodically revoked by referring to the CRL.
The user's authorization token can be invalidated if a more immediate revocation is necessary (for instance, if a user loses a device). Set the StsRefreshTokenValidFrom field for this specific user in Windows PowerShell to nullify the authorization token. The StsRefreshTokenValidFrom field needs to be updated for each user whose access you want to remove.
You must make sure the certificate in question is in the CRL and set the Effective Date of the CRL to a date that comes after the value specified by StsRefreshTokenValidFrom in order to guarantee that the revocation remains in effect.
Graph PowerShell
Revoking user certificates with Graph PowerShell modules
Import-Module Microsoft.Graph.Users.Actions # A UPN can also be used as -UserId. Invoke-MgInvalidateUserRefreshToken -UserId UserPrincipalName
Graph query
And directly with a Graph query
V1.0 POST https://graph.microsoft.com/v1.0/users/alexw@cloudpartnerdemo.fi/revokeSignInSessions Beta https://graph.microsoft.com/beta/users/alexw@cloudpartnerdemo.fi/invalidateAllRefreshTokens GET https://graph.microsoft.com/beta/users/alexw@cloudpartnerdemo.fi/refreshTokensValidFromDateTime
The get command will display user refresh token valid from date and time.
Azure AD PowerShell
or with
Revoke-AzureADUserAllRefreshToken -ObjectId firstname.lastname@domain.com
Azure Portal
or from Azure portal
Monitoring your Certificate services
Last but not least, read this from Kaido Järvemets to understand what you should monitor when having certificate services.
Audit Active Directory Certificate Services using Microsoft Sentinel
