Scott Duffey has put together some excellent articles (four parts in total) around setting up Azure AD based CBA, and deploying certificates to mobile devices. It’s worked really well as a guideline for me in setting up certificate based authentication in production environments – however, there’s one scenario that isn’t covered in these articles, and if you’re running a two-tier PKI architecture, you’re going to have some headaches.
Part 2 of the series discusses how to configure your Azure AD as a Certification Authority, but it only shows you how to add your root CA as your trusted certificate authority. If you have a Root CA and an Enterprise or Intermediate CA, you need to upload both certificates into Azure AD. Without this step, your CBA won’t work because your certificate trust chains won’t properly build out. Also, make sure that you publish all required CRLs – if you have a Root CA as well as an Intermediate or Enterprise CA, make sure that both CRLs are publicly available, as you’re going to be setting those URLs using the PowerShell script below.
Connect-AzureAD
# Find existing Certification Authority
Get-AzureADTrustedCertificateAuthority | FL
# Install Root CA (AuthorityType=0). CRL Distribution Point should be the CRL of the Root CA
$rootcert=Get-Content -Encoding byte “C:usersusernameDesktopAzureCARootCA.cer”
$new_rootca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_rootca.AuthorityType=0
$new_rootca.TrustedCertificate=$rootcert
$new_rootca.crlDistributionPoint=“http://domain.com/crl/RootCA.crl”
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_rootca
# Install Enterprise CA (AuthorityType=1). CRL Distribution Point should be the CRL of the Enterprise CA
$entcert=Get-Content -Encoding byte “C:usersusernameDesktopAzureCAEntCA.cer”
$new_entca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_entca.AuthorityType=1
$new_entca.TrustedCertificate=$entcert
$new_entca.crlDistributionPoint=“http://domain.com/crl/cmdrEntCA.crl”
$new_entca.DeltaCrlDistributionPoint=“http://domain.com/crl/EntCA+.crl”
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_entca
# Remove existing Certification Authority – [0] for first cert, [1] for second, etc.
$c=Get-AzureADTrustedCertificateAuthority
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[1]
The important key above is using the AuthorityType=0 for your Root CA, and AuthorityType=1 for your Enterprise CA. I also added a section that will allow you to clear out your certificates and start over if you need to – just use [0] to remove your first cert, and [1] to remove your second.
Hope this helps!
Master & CmdR 
This was an excellent post that allowed us to setup CBA for our devices. We have a 2 tiered PKI and was running into issues since the MS document only stated to upload the root.
Our certs are due to expire in 3 months and we want to migrate with the least amount of downtime. One item that I have not seen anything about is having multiple roots and multiple intermediates. it seems possible but I wanted to make sure that this was allowed and that uploading the new root would not cause any issues with the older one. This would break ~651 devices.
Thanks
LikeLike
Hi Craig,
Glad this post helped – it was a very frustrating road until we found the missing pieces!
I tested uploading additional Root and Intermediate CA certificates, and it allowed me to specify multiples, like you’d expect. I basically had two root CAs and two Enterprise CAs configured as trusted authorities – as far as I know (and I might definitely be wrong here), as long as the cert chains can build out when the lookup happens, it should be fine.
For instance:
Cert -> Enterprise 1 -> Root 1 = build success.
Cert -> Enterprise 2 -> Root 2 = build success.
Not sure if you’re simply renewing your Enterprise CA, but I figured I’d check them both. I wasn’t able to test actual authentication using the new certs, but you can at least configure them. I’d recommend renewing your certs asap, uploading them, and then testing authentication against both the old and the new, and make sure it’s all working properly long before your certs actually expire.
Then once those certificates are expired, and you need to remove them, you can use Get-AzureADTrustedCertificateAuthority | FL to identify the TrustedIssuerSki of the certs to remove, and then delete them using something like this:
Get-AzureADTrustedCertificateAuthority | Where {$_.TrustedIssuerSki -match “B618B233AB95599527FA6E51EFE9D93D0C5307D5”} | Remove-AzureADTrustedCertificateAuthority
Obviously at this point you’re using the Ski from the command above, but you get my drift…
Hope this helps – I’m definitely curious to know whether or not the authentication actually works properly, let me know if it does (or doesn’t).
LikeLike
FYI,
I uploaded the 2 new certs this morning. The person that is testing has come back and says that on his IPAD he is able to use the new certs and the old certs without any issues. So the authentication works perfectly. Thanks for the info..
LikeLike
Great to hear – thanks for letting me know… glad this actually works as expected 🙂
LikeLike
Question – I configured CBA in non-prod, where do I find logs for the user auth, specially using CBA with EAS client.
LikeLike
Hey HP, are you using ADFS? If so, the user auth logs would be on either your STS server or your WAP server – depending on where the auth is failing.
LikeLike
Jermy, I’m not using ADFS, direct Azure AD CBA for EXO.
Thanks
LikeLike
I’m sorry, I’ve never tried deploying CBA on a managed domain – if you don’t have an ADFS server to check against, I assume the logs would be kept on the client device itself. However, I haven’t ever seen any documentation to support this scenario – just a sentence on the official documentation stating that EAS is an exception. The only other place I can think of is the user sign-in logs in Azure AD – find and open the user in the Azure AD portal, and then click on Activity, then Sign-ins. That might actually give you some information.
LikeLike
Do you have a script for intermediate certs?
LikeLike