Certificate Based Authentication With Microsoft Cloud PKI – Part 2

Introduction

Welcome to Part 2 of our series on Certificate-Based Authentication (CBA) with Microsoft Cloud PKI, a topic that seems as vast and complex as a black hole. In Part 1, we covered the basics of setting up CBA, including the initial configuration in the Entra Portal, creating security groups, setting up cloud PKI, and assigning certificates. If you missed it, here’s a quick recap:

Recap of Part 1: Certificate-Based Authentication with Microsoft Cloud PKI

• Setting Up CBA: We walked through the steps to configure Certificate-Based Authentication (CBA) in the Entra Portal, including setting up certificate authorities and distributing certificates to users.
• Creating Security Groups: We created security groups to manage users who will use CBA.
• Assigning Certificates: Users were assigned certificates, a crucial step for enabling secure, certificate-based logins.
• Setting Up Cloud PKI: We set up a cloud-based Public Key Infrastructure (PKI) to support certificate issuance and management.

You can find detailed instructions and screenshots in Part 1 here.

What to Expect in Part 2

In this part, we will dive deeper into combining CBA with Authentication Strengths and Conditional Access Policies. Here’s what we’ll cover:

1. Setting Up Authentication Strengths: We’ll configure two types: CBA Single Factor and CBA Multi-Factor. We’ll explore how improper configuration can undermine security.
2. Conditional Access Policies: We’ll create new policies to see how they control access in different scenarios and understand their role in enhancing security.
3. Struggles with CBA MFA Behaviour: We’ll address the “weird” behaviour I encountered with CBA Multi-Factor Authentication,

Coming up next in Part 3

We will cover the use cases and business cases for these configurations, including multi-tenant certificate-based authentication. This will help you understand why these setups are beneficial and how they can solve real-world challenges. first we will focus on how it works on Windows including what to do with autopilot enrolments. In later parts, we will capture the user experience on other platforms.

CBA In combination with Authentication Strengths

In this part, we will experiment with the settings to understand the user experience. It’s important to be cautious, as improper configuration can defeat the purpose of setting this all up.

First, we will set up two Authentication Strengths: CBA Single Factor and CBA Multifactor. For other parts of the demo, we will use the default authentication strengths and see why improper configuration might undermine the intended security measures. Additionally, we will create a new CA Policy to experiment with.

We won’t delve into all the options available in CA policies in this post. Instead, we will set up a basic policy and focus on the authentication strength part of the policy to observe what happens during authentication.

Authentication Strength Policies

Understanding Authentication Strength

Authentication Strength measures how secure an authentication method is, ensuring only authorized users can access a system by requiring different types and numbers of verification factors.

Types of Authentication Strength

1. Single-Factor Authentication (SFA):
   • Uses one type of verification, like a password.
2. Two-Factor Authentication (2FA):
   • Uses two types of verification, like a password and a code sent to your phone.
3. Multi-Factor Authentication (MFA):
   • Uses two or more types of verification, such as a password, a mobile push notification, and a fingerprint scan.
4. Passwordless Authentication:
   • Eliminates the need for passwords entirely.
   • Uses methods like biometrics (fingerprint or facial recognition), security keys, or mobile push notifications for verification.

Authentication Strength in CBA (Certificate-Based Authentication)

1. CBA Single Factor:
   • Uses a digital certificate alone for verification.
2. CBA Multi-Factor:
   • Combines a digital certificate with another verification method, like a password or biometric scan.

Importance

• Enhanced Security: More factors or passwordless methods mean higher security.
• Regulatory Compliance: Meets security standards and regulations.
• User Confidence: Increases trust in the system’s security.

Configuring Authentication Strength

• Go to Entra Portal
  • Fold Open protection Tab
  • Click on Authentication Methods
  • Click on Authentication Strength
  • Creating CBA Multifactor Click on “New Authentication Strength”
    • Fill in Name: CBA (Multifactor)
    • Select Certificated Based Authentication (Multifactor)
    • Click Next
    • Click Create
  • Fill in Name: CBA (Single factor)
  • Select Certificated Based Authentication (Single factor)
  • Click Next
  • Click Create

Conditional Access Policies

Conditional Access is like having a smart security guard for your online accounts. It checks where you are, what device you’re using, and how you’re logging in. If something seems unusual, it might ask you for extra proof that it’s really you, like a text message code. This way, it makes sure only the right people get access, especially in risky situations. It’s a flexible and dynamic way to keep your information safe.

We will be using Conditional Access in combination with Certificate-Based Authentication (CBA) to enhance security. See the setup details below.

• Click on “Conditional Access”
• Click on Policys
• Click on New Policy
  • Name : CA – CBA Multifactor
  • assignments
    • Users
      • Include User and groups -> CERTH_AUTH_DEMO (security group that we created in part 1)
      • Exclude User and groups -> Break-glass security groups or users (Its always important to Exclude your break-glass accounts from CA policies If you F up you always have a way back)
    • Target All Cloud Apps
      • Include All Cloud Apps
    • Network -> blank
    • Conditions -> blank
  • Access Control
    • Grant
      • Grant Acces
      • Require authentication strength -> CBA (Multifactor)
    • Session -> Blank
  • Select Off for now
  • Click Create
• Click Duplicate on the CA – CBA Multifactor Policy
  • Rename -> CA – CBA Single factor
  • Grant
    • Require authentication strength -> CBA Single factor
  • Enable policy -> Off For now
  • Click Create

Single factor VS Multifactor Certificate Base authentication

When configuring certificate-based authentication (CBA) with a protection level set to Single Factor Authentication (SFA) and assigning the user to an authentication strength policy that requires CBA Multi-Factor Authentication (MFA), the authentication will be recognized only as SFA and will fail to meet the MFA requirements. To meet the MFA requirement, you must set the Protection Strength to MFA.

Unfortunately, as of now, there is no option to enforce SFA CBA in combination with another authentication method using the authentication strength method. This means that if you want to use a certificate along with another authentication method, you cannot force users to use the certificate. One workaround is to disable all other authentication methods for these users and require MFA in your Conditional Access (CA) policy. This way, users can only choose between a password and a certificate.

For instance, if you require Standard MFA Authentication in your CA policy and configure CBA as Single Factor, users can use a certificate with a password or another method, or even ignore the certificate and log in with a password and an authentication app. When you configure the CBA policy as MFA, users can log in using only the certificate or another MFA-worthy authentication method like a FIDO2 key.

Understanding Certificate-Based Authentication (CBA) as Multi-Factor Authentication (MFA)

To address whether certificate authentication qualifies as multi-factor, the answer depends on how the private key is protected. Certificate-based authentication is highly secure due to its reliance on cryptographic keys that are hard to brute-force. However, the level of protection for the private key determines if CBA is considered MFA.

• The certificate counts as something you have, such as the device where the certificate is stored (e.g., a YubiKey, a computer using Intune SCEP or another MDM, or Windows Hello for Business).
• If the certificate is protected by another factor, such as a PIN (something you know) or a biometric factor like a fingerprint or face ID (something you are), then it is considered MFA.
• If you can use the certificate from, for example, the Windows certificate store without additional factors, it is considered single-factor.

Key Takeaways

• In the CBA policy, define the protection level to determine how it will be counted (SFA or MFA).
• In the Conditional Access/Authentication Strength policy, specify the authentication requirements.

Lets Play Around

Now we have got the bases covered we Configured our CBA authentication method in Part 1, Created 2 custom authentication strength policies and also created our 2 conditional access policies we can start and play around with it and see what the end user experience will be like.

Combinations

Below, I tried some combinations to see what would happen. However, if you deploy this in your environment, please use only matching pairs of authentication methods. Mixing them can lead to errors, as shown below. You can mix methods when using standard MFA in the CA Policy.

• Combination 1
  • CBA Setting Authentication Strength: Single Factor
  • Conditional Access Policy: Single Factor CBA
  • Conclusion
    • User can sign on with a certificate only

• Combination 2
  • CBA Setting Authentication Strength: Single Factor
  • Conditional Access Policy: Multifactor CBA
  • Conclusion
    • Does not work you will get an error that the certificate does not meet the criteria

• Combination 3
  • CBA Setting Authentication Strength: Multifactor
  • Conditional Access Policy: Single Factor CBA
  • Conclusion
    • Does not work you will get an error that the certificate does not meet the criteria

• Combination 4
  • CBA Setting Authentication Strength: Multifactor
  • Conditional Access Policy: Multifactor CBA
  • Conclusion
    • User can sign on with a certificate only

• Combination 5
  • CBA Setting Authentication Strength: Single Factor
  • Conditional Access Policy: Standard Multifactor
  • Conclusion
    • User can sign on with a certificate and an other factor of authentication

• Combination 6
  • CBA Setting Authentication Strength: Multifactor
  • Conditional Access Policy: Standard Multifactor
  • Conclusion
    • User can sign on with a certificate only

The Struggle

The Problem

I was testing the MFA strength in the Certificate-Based Authentication (CBA) policy and the MFA CBA Conditional Access (CA) policy we created, and I encountered some unexpected behavior. When logging in with a certificate, I received an error stating that my certificate did not meet the criteria to sign in.

I then attempted to authenticate using a password followed by the certificate, and this time, I signed in successfully. To further test, I logged out, closed the private window, and logged back in again. By choosing the certificate first, I was able to sign in without needing a second authentication method. This was expected since certificate authentication in this case should count as MFA, eliminating the need for a second method. So this had me in a pickle and so it began.

Trouble shooting step

• Trying in other browsers -> problem persisted
• Have you tried turning it of and on again 😉 -> problem persisted
• Revoking User SCEP Certificate -> problem persisted
• Sign In with a new user and get a new scep certificate for that user -> problem persisted
• Clearing TPM Chip and revoking certificate’s -> issue persisted.
• Deploying a new PC -> No issues 😉 great now we know its a problem on the endpoint.
• Windows 11 Build-in Reset -> Problem persisted
• Windows 11 USB Reset + Clearing TPM chip -> Fixed the issue

Conclusion

Spent hours trouble shooting trying to figure out why this was happening. And all it took to fix it in the end was Clearing TPM Chip and taking a USB stick put Windows 11 on it and done 😉

Singing in with Certificate First (attempt one)

Signing in with PW and Certificate

Singing in with Certificate First (attempt Two)

Conclusion

In this part, we delved deeper into the nuances of Certificate-Based Authentication (CBA) and its integration with Authentication Strengths and Conditional Access (CA) Policies. We explored:

• Setting Up Authentication Strengths: We configured both CBA Single Factor and CBA Multi-Factor Authentication. We discussed how improper configuration can undermine security.
• Conditional Access Policies: We created new policies to control access in different scenarios, enhancing security by enforcing specific authentication strengths.
• Struggles with CBA MFA Behaviour: We investigated the unexpected behaviours encountered during testing.

Key Takeaways

• Proper configuration of Authentication Strengths and CA Policies is crucial for effective CBA implementation.
• Using matching pairs of authentication methods is essential to avoid errors.

Looking Ahead to Part 3

Next up, we will cover the use cases and business cases for these configurations, including multi-tenant certificate-based authentication. This will help you understand why these setups are beneficial and how they can solve challenges.

We will continue to focus on how it works on Windows including what to do with autopilot enrolments, and later, we will capture the user experience and challenges on other platforms.

Stay tuned for more insights and detailed instructions in the upcoming parts of our series. Thank you for following along, and we look forward to exploring more advanced topics with you in Part 3!