I have been working with ADDS (AD) & ADCS (PKI) almost whole of my IT career and still love to do stuff with these technologies, even my focus has been in the cloud for almost a decade now. Back to one of my favorite ones, certificate-based authentication where certificates to devices are deployed from internal Certification Authority.
I wrote a couple years ago a blog about this topic when was implementing CBA to the production environment. I have to say that this is one of the most complex solutions I have built-in many years and there are quite many steps that can go in the wrong direction.
In this blog post, I’m not going to cover how to configure the solution. There are multiple extremely valuable blogs/docs already available for that purpose (links below). This blog post covers notes from the field, issues that I have faced during deployments to both, production and demo environments.
- Microsoft Support guidance – How to configure NDES for SCEP with Intune
- Configure SCEP infrastructure
- Microsoft Support instructions
- Requirements, among ADFS, are mentioned in here.
Architecture in my demo environment looks like in the picture below. Nowadays, I encourage to use of Azure AD Application proxy instead of Web Application Proxy for publishing NDES, CRL’s and CRT.
Both works, but Azure AD App Proxy integration gives you more flexibility and most probably you are already consuming other cloud resources which makes it natural selection. Take into account, that ADFS is a kind of sunset mode, even it still has its place in many enterprises. Read this blog about Mitsui corp changes in ADFS infrastructure.
Notes From The Field
Then to actual beef in this blog, notes from the field. Keep in mind that this is not the full list of all requirements, rather a list of issues I faced during the last implementation.
Verify that there aren’t any Conditional Access Policies preventing component registration. If there are you might face similar error than I had during Intune NDES Connector registration. The same rule applies to all registration performed in on-premises, verify CA policies.
Certificate Revocation List (CRL)
When working with PKI, CRL’s plays a critical role in there, always. In this scenario devices needs to be able to verify whole certification chain from outside corporate network which means, CRL’s needs to be published to the Internet in a way or other.
I used Web Application Proxy for this purpose but it really doesn’t matter which technology you are using as long as publishing new CRL’s and Delta CRL’s works and those are reachable from devices that are using the service.
Just for refreshing the memory, here is a picture of how Windows CryptoAPI system checks certificate validity and builds a trusted chain. Picture from Infrastructure Planning series published around 2012, still valid in terms of ADCS 🙂
As seen from here, devices need to have the Root CA certificate to be able to build a certificate trust but that’s handled via Intune SCEP policy during enrollment.
Verify Azure AD Configuration – Internal CA Trusted
One of the needed pre-requirements is to add organization internal CA as trusted in Azure AD. Double-check that you have the correct public Root CA certificate to import. In my case, I had an old Root CA cert imported back in 2017 to Azure AD.
Removed the old Root CA certificate
New Root CA certificate added with the following commands
$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]" ' $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation ' $new_ca.AuthorityType=0 ' $new_ca.TrustedCertificate=$cert ' $new_ca.crlDistributionPoint="<CRL Distribution URL>" ' New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca '
Verify that your mobile devices trust the internal Root CA’s and CRL’s are reachable. Otherwise, you might see this kind of error. This might not be the case in production because everybody is using trusted certificates from trusted publishers. If you are running demo environment self-signed certs might cause issues. Strong encouragement -> use LetsEncrypt in demo environments.
Publish Nework Device Enrollment Services (NDES)
This is an obvious one, but double, or tripe check publishing configuration to avoid yourself banging your head to the wall like me. Remember to pay attention to the certificates.
Network Device Enrollment Service (NDES)
NDES needs the following certificates which cannot be changed or reconfigured. Publish these ones before the implementation of internal CA.
- Enrollment Agent
Template For Mobile Devices
Pay attention to the NDES registry configuration and template settings. A certificate name is needed here, not the display name.
There are so many things which can fail in here. If authentication doesn’t work go through this checklist. Troubleshooting certificate authentication is found from the same link.
Blocking The Access
Last, but not least. If a device is stolen, or client certificate needs to be revoked following actions needs to be done (instructions from docs.microsoft.com):
- Revoke client certificate
- Publish new Certification Revocation List (CRL)
Take into account that Azure Active Directory fetches the certificate revocation list (CRL) from the URLs uploaded as part of certificate authority information and caches it. The last publish timestamp (Effective Date property) in the CRL is used to ensure the CRL is still valid. The CRL is periodically referenced to revoke access to certificates that are a part of the list.
In case of a stolen device authorization token can be invalidated by modifying StsRefreshTokenValidFrom field for this particular user using Windows PowerShell.
To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by StsRefreshTokenValidFrom and ensure the certificate in question is in the CRL.
If everything has been correctly configured in place it should work as follows (picture from docs.microsoft.com):
And your internal CA has issued certificate to the user
What’s found from Azure AD logs when certificate is revoked in federated scenario?
- Nothing. At this time failed logins are only seen in IDP side
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?
- When revoking tokens, refresh-token is revoked and the user needs to sign-in again when the access token expires. If revoking certificate it affects only to device and profiles which uses the certificate.
What needs to take into account here is CRL and how the system store it in the cache. For that reason, if immediate action is needed recommendation is to revoke tokens. In my demo environment, I was able to block access via browser certificate by revoking the cert but EAS didn’t get blocked. I also revoked tokens but access wasn’t blocked immediately, it took a couple of hours before phone mail client stopped working due to invalid certificate. Most probably, the reason was CRL cached in Azure AD which validity period is 1 week even though I did configuration based on Microsoft instructions.