Passwordless Authentication with FIDO2 Security Key for Remote Desktop Connection
Passwordless Authentication with FIDO2 Security Key for Remote Desktop Connection Hello Everyone, in this blog, we will explore how to use a FIDO2 security key to access a device using Remote Desktop Connection (RDP)—a Zero Trust approach where passwordless authentication is enforced. Recently, a customer asked me whether they could secure their device and enforce passwordless authentication for RDP access. While some FIDO2 security keys can also be used as smart cards with Certificate-Based Authentication (CBA), I will cover that topic in my next blog. In this post, let's focus on how we can use Windows 10/11, the RDPAAD (Remote Desktop Protocol Azure AD Protocol), and WebAuthn to connect to Entra ID-joined or Hybrid-joined devices using a FIDO2 security key. If a user has never used or registered a FIDO2 security key, they should register it by visiting My Sign-Ins, clicking on Security Info, and selecting Add sign-in method. Once the FIDO2 security key is registered, complete the sign-in process and ensure the user can successfully authenticate to web applications using the security key. Configuring RDP for Entra ID-Joined Devices: For Entra ID-joined devices, follow these steps to enable RDP access using a FIDO2 security key: Ensure the user is a member of the local Remote Desktop Users group on the remote device. o Open PowerShell as Administrator and load the Microsoft Graph PowerShell module to connect to Entra ID (if needed). o Run the following command to add the user to the Remote Desktop Users group: o net localgroup "Remote Desktop Users" /add "AzureAD\user200@farooquetech.in" We can validate the configuration by opening Computer Management and checking the Local Users and Groups settings: Open Computer Management (compmgmt.msc). Navigate to Local Users and Groups → Groups. Locate and open the Remote Desktop Users group. Check if the Entra ID user we added appears in the list. This confirms that the user has been successfully added and can sign-in to remote machine using RDP. At this point, we can open Remote Desktop Connection (mstsc.exe) and attempt to connect to the remote device. Open Remote Desktop Connection (mstsc.exe). Click on the Advanced tab. Under User Authentication, ensure we select "Use a web account to sign in to the remote computer." This ensures that the RDP session leverages passwordless authentication with FIDO2 and WebAuthn for secure access. Enter the NetBIOS name of the remote computer in Remote Desktop Connection (mstsc.exe) and click Connect. On the sign-in page, enter the Entra ID account for which FIDO2 Security Key authentication is enabled. When prompted to choose a passwordless authentication method, select Security Key. Insert your FIDO2 security key, follow the prompts, and complete the authentication process. This ensures a secure, passwordless RDP connection to the remote device. Put the PIN and also touch your finger on Security Key to complete authentication. A consent is prompt to allow RDP Connection, select Yes. Post Authentication, we will see the desktop successfully loads. Remote Desktop Connection Access to Hybrid Entra ID-Joined Devices: Now, let's discuss how to establish RDP access for Hybrid Entra ID-joined devices. The process for Hybrid-joined devices differs slightly because these devices are joined to both Active Directory (AD) and Entra ID. This means authentication must be validated in both directories. To achieve this, we need to register an Active Directory Read-Only Domain Controller (RODC) object in Entra ID. This RODC object helps issue a partial Kerberos Ticket Granting Ticket (TGT) to the user after authentication with Entra ID. Note: This RODC object is not linked to any on-premises AD domain controller—it is simply an empty object in Entra ID used to enable Kerberos authentication. Enabling Entra ID Kerberos Authentication: To enable Entra ID Kerberos authentication, follow these steps: Open PowerShell as Administrator. Install the AzureADKerberos module (if not already installed): Execute below powershell commands Import-module “Import-module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1" $domain = $env:USERDNSDOMAIN $userPrincipalName = admin@mngenvmcapXXX.onmicrosoft.com $domainCred = Get-Credential (Enter the Active Directory credentials) Once the command executes successfully, we can verify that the AzureADKerberos account has been created in Active Directory. Open Active Directory Users and Computer and under Domain Controller, check AzureADKerberos RODC object is created. This completes the AzureADKerberos configuration, enabling the use of FIDO2 Security Keys for authentication. Now, to establish an RDP connection, follow the same steps outlined earlier for Entra ID-joined devices. Enforcing Phishing-Resistant Passwordless Authentication for RDP: To ensure that Remote Desktop Protocol (RDP) always uses phishing-resistant passwordless authentication, we can enforce this through Conditional Access Policies in Entra ID. Sign in to the Entra ID portal. Go to Security → Conditional Access and create a new policy. Under Assignments, select the users or groups that require secure RDP access. In the Cloud apps or actions section, select “Microsoft Remote Desktop” with Application ID “a4a365df-50f1-4397-bc59-1a1564b8bb9c”. Under Grant Controls, choose Require authentication strength. Select Phishing-resistant authentication, which includes FIDO2 Security Keys Save and enable the policy. Note: For Hybrid Entra Joined machine, please ensure we do not use domain admin or any other AD high privileged account to logon else partial TGT will not be issued by Entra ID. I hope you found this blog helpful! In my next blog, I will cover how FIDO2 Security Keys can also be used for on-premises Active Directory domain-joined servers. Stay tuned!Passwordless RDP Authentication for On-Prem Servers with Smart Cards (FIDO2 Security Key)
Hello Everyone, in my previous blog, I discussed how to use FIDO2 Security Key Passwordless Authentication with Entra or Hybrid Joined devices for Remote Desktop Connection. In this blog, we will discuss how a FIDO2 Security Key can be used as a smart card for Remote Desktop Connection Protocol on on-prem Active Directory domain-joined servers. If you have not gone through my last article, you can click here. Many people have written several articles and blogs on similar topics, so I apologize if you find it duplicate. Recently, a customer asked me whether it was possible to authenticate using a FIDO2 security key to connect to a remote on-prem domain joined server via RDP. I successfully enabled it for them and decided to write a blog on the topic. This is a great use case for administrators who frequently use high-privileged groups like Domain Admins and Enterprise Admins, as they should adopt passwordless authentication for secure day-to-day server management using smart card-based authentication. Basically, what I will be demonstrating here is Kerberos PKINIT (Public Key Cryptography for Initial Authentication in Kerberos), which is an extension of the Kerberos Authentication protocol that allows users to authenticate using certificates. There are some vendors who facilitate PIV (Personal Identification Verification) in security keys for strong authentication. With PIV, we can use the security key to store certificates for authentication. So, let’s discuss how we can use this feature to go passwordless by accessing the remote desktop of servers. First of all, we need a PKI infrastructure or a Certificate Server, which we can deploy on Windows Server by adding the Certificate Services role or using an existing one. Once we have a certificate server, we can configure the certificate templates for users and domain controllers. In order to use RDP for servers, both the client and domain controller (DC) need to have a valid certificate as they use mutual authentication. We can issue a “User or Smart Card Logon” certificate to users and a “Kerberos Authentication” certificate to DCs. Before we get into settings and configuration, let’s understand how Kerberos PKINIT works at a high level, which will further help us understand the entire process of this activity. Kerberos Public Key Cryptography for Initial Authentication (PKINIT) in the Kerberos protocol enables the use of public key cryptography in the initial authentication exchange. It uses X.509 certificates (Smart Card) in place of a password to authenticate against the authentication server. The key components involved here are: The Domain Client running Windows 10/11, who wants to access a remote server over RDP. The Domain Controller (KDC) running on at least Windows Server 2016, which authenticates users in Active Directory. The Domain Member Server running on at least Windows Server 2016, which is the target system the client wants to connect to. A Certificate Authority (CA) running on at least Windows Server 2016, which issues Kerberos Authentication and User or Smart Card Logon certificates. Authentication Flow: The Client selects a smart card during authentication, which sends an AS-REQ (Authentication Service Request) to the Domain Controller (KDC) containing the user’s X.509 certificate. It essentially signs the current time with its private key. The Domain Controller validates the request by checking the times using the user’s public key. Once the Domain Controller completes the validation, it issues a TGT (Ticket Granting Ticket) signed by the KDC certificate using its private key as an AS-REP (Authentication Service Reply) response. The Client validates the TGT by verifying the KDC’s certificate. Once the Client has the TGT, it can proceed to request a service ticket to connect to the target server. It is important to note that if we have an Enterprise or AD-integrated Certificate Authority, the Root CA or Issuing CA's certificate will be automatically added to the Trusted Root Certification Authorities store in domain-joined systems. In case we use a standalone CA, we must manually add its certificate to the client machine’s Trusted Root Certification Authorities store. Now, let’s go through the whole process step by step. We will first start by creating a template for the Domain Controller (DC) certificate and later for User certificates. We will also see how to configure Group Policy for certificate auto-enrollment to issue certificates to users and DCs. Issue Kerberos Authentication Certificate to Domain Controller: Go to the Certificate Server and open the Certificate Authority console. Click on Templates and then click on Manage. The Domain Controller (DC) requires the KDC Authentication certificate (1.3.6.1.5.2.3.5) EKU and Server Authentication (1.3.6.1.5.5.7.3.1) EKU. Select the Kerberos Authentication template. Select the Kerberos Authentication template and create a duplicate template. Next, do not make any changes to the certificate template except for assigning a name under the General tab. Go to the Security tab and ensure that only the Domain Controllers group is added with Read, Enroll, and Autoenroll permissions selected. Under the Subject Name tab, ensure the DNS checkbox is selected. Next, we need to issue the Kerberos Authentication certificate template to make it available for Domain Controllers (DCs) to request certificates. Group Policy Configuration: Next, we need to create a Group Policy for certificate auto-enrollment and link it to the Domain Controllers OU. Open the GPO and go to Computer Configuration\Windows Settings\Security Settings\Public Key Policies. Edit Certificate Service Client – Auto Enrollment Properties and select Renew Expired Certificate and update Certificate options as shown in picture below. Go to Computer Configuration\Windows Settings\Security Settings\Public Key Policies and set "Certificate Services Client – Certificate Enrollment Policy" to Enabled. We also need to create another Group Policy Object (GPO) and link it to the domain to enable additional policies for the Client & Server to accept smart card authentication for RDP connections. This policy will determine how the system should behave when the smart card is removed. In this case, it will be set to disconnect the session. Go to Computer Configuration\Windows Settings\Security Settings\Security Options and enable "Define this policy setting" and select option "Disconnect if a Remote Desktop Services Session" Next, we will enable the use of smart cards by setting the policy "Allow ECC certificates to be used for logon and authentication" under: Computer Configuration\Administrative Templates\Windows Components\Smart Card Create Smart Card Logon Certificate Template for Client: Now, go back to the Certificate Server, open the Certificate Authority console, and open the Manage console by right-clicking on Certificate Templates. Select the Smart Card Logon template, right-click, and choose Duplicate Template. Under the Compatibility tab, set: Certificate Authority to Windows Server 2016 Certificate Recipients to Windows 10/Windows Server 2016 Next, go to the General tab and assign a name of your choice. This is the same certificate that the user will see when they issue a smart card certificate to be stored in the FIDO2 Security Key. Go to the Request Handling tab and: Under Purpose, select "Include symmetric algorithms allowed by the subject." Enable "For automatic renewal of smart card certificates, use existing key if a new key cannot be created." To ensure the certificate is saved in the FIDO2 Security Key during the request, select "Prompt the user during enrollment and require user input when the private key is used." Note: I tested the "Prompt the user during enrollment" option, but it did not work. Next, go to the Cryptography tab and: Under Provider Category, select "Key Storage Provider." In Algorithm Name, choose "ECDH_P384" (assuming you meant P384, as P383 is not a standard option). Under Cryptographic Provider, select "Request must be one of the following providers" and choose "Microsoft Smart Card Key Storage Provider." Change Request Hash to "SHA256." Next, go to the Security tab and: Ensure the group containing Admins is added with Read and Enroll permissions. Optionally, enable Autoenroll if needed. Finally Click on OK to save the new template. Let the Group Policy refresh automatically or manually force it by running gpupdate /force. Once refreshed, the Domain Controller (DC) should receive a new Kerberos Authentication Certificate. Enroll Client Smart Card Certificate: On a Windows 10/11 device, Open Command Prompt and run “certreq -enroll "<SmartCard Certificate Template Name>" Ensure the appropriate Smart Card certificate is selected, then click Next to proceed with the certificate issuance. Insert the FIDO2 Security Key. Once the system detects the security key, it will prompt you to enter the PIN to store the certificate The process of storing certificate in FIDO2 Security key completes and now we can test accessing server using RDP with security key Testing: Open mstsc.exe and enter the target server’s FQDN. If the security key is detected by the system, it will prompt you to use the smart card for login. Enter the PIN, and it should allow you to sign in successfully Once authentication is successfully completed, RDP should load the desktop. Troubleshooting: During my research and extensive testing in my lab, I encountered few errors when enrolling certificates on the FIDO2 Security Key PIV. One of the issues I faced was the smart card showing as locked. After troubleshooting, I found that sometimes the FIDO2 security key device driver provided by the vendor is not installed properly. Ensure that you follow the security key provider’s installation guide and install the latest driver on both the client and target server. Another common error I encountered was: "The requested key container does not exist in smart card." This issue typically occurs when the FIDO2 Security Key driver is not installed properly on the target server. Again, refer to the FIDO2 security vendor’s documentation to install the correct driver. . Note: Ensure that when you attempt RDP to the target server, the user for whom you issued the smart card certificate is added to the "Remote Desktop Users" group on the target server. If you are looking to use RDP from the internet, we have the option of KDC Proxy to use. You can refer this article here for more details. I hope you found this blog useful in achieving passwordless authentication even for on-prem Active Directory domain-joined critical servers and I would like to thank you for reading this blog. Hopefully I will be back soon with some more interesting blogs.
23H2 Passkeys: default to security key instead of mobile devices
Microsoft invested time & money to introduce Passkeys in Windows 11 23H2, as it should. Unfortunately, it defaults to a mobile device (iPhone, iPad or Android device) everytime you try to log on. This is very annoying for everybody that is using a Security Key (FIDO2). Before we just needed to enter our PIN but now we need multiple clicks to log on. I'm not aware of a solution to manage these options (manually or through Intune). Is anyone aware of a solution? I'm quite amazed Microsoft didn't think of this.Hacking Made Easy, Patching Made Optional: A Modern Cyber Tragedy
In today’s cyber threat landscape, the tools and techniques required to compromise enterprise environments are no longer confined to highly skilled adversaries or state-sponsored actors. While artificial intelligence is increasingly being used to enhance the sophistication of attacks, the majority of breaches still rely on simple, publicly accessible tools and well-established social engineering tactics. Another major issue is the persistent failure of enterprises to patch common vulnerabilities in a timely manner—despite the availability of fixes and public warnings. This negligence continues to be a key enabler of large-scale breaches, as demonstrated in several recent incidents. The Rise of AI-Enhanced Attacks Attackers are now leveraging AI to increase the credibility and effectiveness of their campaigns. One notable example is the use of deepfake technology—synthetic media generated using AI—to impersonate individuals in video or voice calls. North Korean threat actors, for instance, have been observed using deepfake videos and AI-generated personas to conduct fraudulent job interviews with HR departments at Western technology companies. These scams are designed to gain insider access to corporate systems or to exfiltrate sensitive intellectual property under the guise of legitimate employment. Social Engineering: Still the Most Effective Entry Point And yet, many recent breaches have begun with classic social engineering techniques. In the cases of Coinbase and Marks & Spencer, attackers impersonated employees through phishing or fraudulent communications. Once they had gathered sufficient personal information, they contacted support desks or mobile carriers, convincingly posing as the victims to request password resets or SIM swaps. This impersonation enabled attackers to bypass authentication controls and gain initial access to sensitive systems, which they then leveraged to escalate privileges and move laterally within the network. Threat groups such as Scattered Spider have demonstrated mastery of these techniques, often combining phishing with SIM swap attacks and MFA bypass to infiltrate telecom and cloud infrastructure. Similarly, Solt Thypoon (formerly DEV-0343), linked to North Korean operations, has used AI-generated personas and deepfake content to conduct fraudulent job interviews—gaining insider access under the guise of legitimate employment. These examples underscore the evolving sophistication of social engineering and the need for robust identity verification protocols. Built for Defense, Used for Breach Despite the emergence of AI-driven threats, many of the most successful attacks continue to rely on simple, freely available tools that require minimal technical expertise. These tools are widely used by security professionals for legitimate purposes such as penetration testing, red teaming, and vulnerability assessments. However, they are also routinely abused by attackers to compromise systems Case studies for tools like Nmap, Metasploit, Mimikatz, BloodHound, Cobalt Strike, etc. The dual-use nature of these tools underscores the importance of not only detecting their presence but also understanding the context in which they are being used. From CVE to Compromise While social engineering remains a common entry point, many breaches are ultimately enabled by known vulnerabilities that remain unpatched for extended periods. For example, the MOVEit Transfer vulnerability (CVE-2023-34362) was exploited by the Cl0p ransomware group to compromise hundreds of organizations, despite a patch being available. Similarly, the OpenMetadata vulnerability (CVE-2024-28255, CVE-2024-28847) allowed attackers to gain access to Kubernetes workloads and leverage them for cryptomining activity days after a fix had been issued. Advanced persistent threat groups such as APT29 (also known as Cozy Bear) have historically exploited unpatched systems to maintain long-term access and conduct stealthy operations. Their use of credential harvesting tools like Mimikatz and lateral movement frameworks such as Cobalt Strike highlights the critical importance of timely patch management—not just for ransomware defense, but also for countering nation-state actors. Recommendations To reduce the risk of enterprise breaches stemming from tool misuse, social engineering, and unpatched vulnerabilities, organizations should adopt the following practices: 1. Patch Promptly and Systematically Ensure that software updates and security patches are applied in a timely and consistent manner. This involves automating patch management processes to reduce human error and delay, while prioritizing vulnerabilities based on their exploitability and exposure. Microsoft Intune can be used to enforce update policies across devices, while Windows Autopatch simplifies the deployment of updates for Windows and Microsoft 365 applications. To identify and rank vulnerabilities, Microsoft Defender Vulnerability Management offers risk-based insights that help focus remediation efforts where they matter most. 2. Implement Multi-Factor Authentication (MFA) To mitigate credential-based attacks, MFA should be enforced across all user accounts. Conditional access policies should be configured to adapt authentication requirements based on contextual risk factors such as user behavior, device health, and location. Microsoft Entra Conditional Access allows for dynamic policy enforcement, while Microsoft Entra ID Protection identifies and responds to risky sign-ins. Organizations should also adopt phishing-resistant MFA methods, including FIDO2 security keys and certificate-based authentication, to further reduce exposure. 3. Identity Protection Access Reviews and Least Privilege Enforcement Conducting regular access reviews ensures that users retain only the permissions necessary for their roles. Applying least privilege principles and adopting Microsoft Zero Trust Architecture limits the potential for lateral movement in the event of a compromise. Microsoft Entra Access Reviews automates these processes, while Privileged Identity Management (PIM) provides just-in-time access and approval workflows for elevated roles. Just-in-Time Access and Risk-Based Controls Standing privileges should be minimized to reduce the attack surface. Risk-based conditional access policies can block high-risk sign-ins and enforce additional verification steps. Microsoft Entra ID Protection identifies risky behaviors and applies automated controls, while Conditional Access ensures access decisions are based on real-time risk assessments to block or challenge high-risk authentication attempts. Password Hygiene and Secure Authentication Promoting strong password practices and transitioning to passwordless authentication enhances security and user experience. Microsoft Authenticator supports multi-factor and passwordless sign-ins, while Windows Hello for Business enables biometric authentication using secure hardware-backed credentials. 4. Deploy SIEM and XDR for Detection and Response A robust detection and response capability is vital for identifying and mitigating threats across endpoints, identities, and cloud environments. Microsoft Sentinel serves as a cloud-native SIEM that aggregates and analyses security data, while Microsoft Defender XDR integrates signals from multiple sources to provide a unified view of threats and automate response actions. 5. Map and Harden Attack Paths Organizations should regularly assess their environments for attack paths such as privilege escalation and lateral movement. Tools like Microsoft Defender for Identity help uncover Lateral Movement Paths, while Microsoft Identity Threat Detection and Response (ITDR) integrates identity signals with threat intelligence to automate response. These capabilities are accessible via the Microsoft Defender portal, which includes an attack path analysis feature for prioritizing multicloud risks. 6. Stay Current with Threat Actor TTPs Monitor the evolving tactics, techniques, and procedures (TTPs) employed by sophisticated threat actors. Understanding these behaviours enables organizations to anticipate attacks and strengthen defenses proactively. Microsoft Defender Threat Intelligence provides detailed profiles of threat actors and maps their activities to the MITRE ATT&CK framework. Complementing this, Microsoft Sentinel allows security teams to hunt for these TTPs across enterprise telemetry and correlate signals to detect emerging threats. 7. Build Organizational Awareness Organizations should train staff to identify phishing, impersonation, and deepfake threats. Simulated attacks help improve response readiness and reduce human error. Use Attack Simulation Training, in Microsoft Defender for Office 365 to run realistic phishing scenarios and assess user vulnerability. Additionally, educate users about consent phishing, where attackers trick individuals into granting access to malicious apps. Conclusion The democratization of offensive security tooling, combined with the persistent failure to patch known vulnerabilities, has significantly lowered the barrier to entry for cyber attackers. Organizations must recognize that the tools used against them are often the same ones available to their own security teams. The key to resilience lies not in avoiding these tools, but in mastering them—using them to simulate attacks, identify weaknesses, and build a proactive defense. Cybersecurity is no longer a matter of if, but when. The question is: will you detect the attacker before they achieve their objective? Will you be able to stop them before reaching your most sensitive data? Additional read: Gartner Predicts 30% of Enterprises Will Consider Identity Verification and Authentication Solutions Unreliable in Isolation Due to AI-Generated Deepfakes by 2026 Cyber security breaches survey 2025 - GOV.UK Jasper Sleet: North Korean remote IT workers’ evolving tactics to infiltrate organizations | Microsoft Security Blog MOVEit Transfer vulnerability Solt Thypoon Scattered Spider SIM swaps Attackers exploiting new critical OpenMetadata vulnerabilities on Kubernetes clusters | Microsoft Security Blog Microsoft Defender Vulnerability Management - Microsoft Defender Vulnerability Management | Microsoft Learn Zero Trust Architecture | NIST tactics, techniques, and procedures (TTP) - Glossary | CSRC https://learn.microsoft.com/en-us/security/zero-trust/deploy/overview
FIDO2 Key Audit Logs
Hi, Does anyone have any KQL Queries that will give me a list of users that have used FIDO2 Keys as their method of authentication, or any audit logs that I can look up for all users to validate that these keys are being used as opposed to being available to be used. We have FIDO2 Keys set as available to users in the estate and I know that they are being used where required, but in the users Sign-in logs, it isn't very clear as to where it proves that the user used FIDO2 as the authentication method. When looking at a user that is using FIDO2 Key for their authentication, it doesn't show in the Basic Info tab in Entra Sign-in logs that FIDO Key use was used specifically? I have a Conditional Access Policy set as Report Only to also help test this which enforces Authentication Strength for Phishing Resistant MFA, and the users I am looking at that I know use FIDO2 for authentication, would have successfully passed that CAP should it be enabled; so I know that it's working fine. I just need to be able to prove this in the audit logs for multiple users.Achieve higher security with certificate bindings - How it works!
Dear Microsoft Entra friends, In this article I would like to take a closer look at the subject of certificate affinity binding. So that even more security can be applied during authentication. Let's start with a few links to the Microsoft documentation pages. Overview of Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication How to configure Microsoft Entra certificate-based authentication: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication Microsoft Entra certificate-based authentication technical deep dive: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive What does it mean "Achieve higher security with certificate bindings"? Microsoft Entra ID, formerly known as Azure Active Directory, is a cloud identity and access management solution that controls application access and protects identities. The term “Achieve higher security with certificate bindings” refers to a feature of Microsoft Entra ID that enhances user authentication security. This feature is part of the certificate-based authentication (CBA) process. Certificate bindings refer to the methods used to bind a certificate to a user’s identity, enhancing the security of the authentication process. There are seven supported methods for certificate bindings. These methods are considered high-affinity if they’re based on identifiers that can’t be reused, such as Subject Key Identifiers or SHA1 Public Key. This way, Microsoft Entra ID provides a secure and efficient way for users to authenticate and access applications. Let's examine achieve higher security with certificate bindings. Object Identifiers (OID): First we look at the certificate template on the certificate server (sorry some print screens are in German). Here we see the details of the Object Identifiers (OID). Add a new rule: Configure an additional rule in the Entra ID Admin Center and use the same Object Identifiers (OID) value here as in the certificate template. Subject Key Identifier (SKID): The certificate was issued on the user's system. We obtain the subject key identifier (SKID) from this certificate. We need this value in the Entra ID Admin Center to assign it to a person. The same person for whom the certificate was issued on the system (in my case it is Tina Fluenza). Authorization info: In the Entra ID Admin Center, we now set the value of the Subject Key Identifier (SKID) for the user in the properties. Note: Please pay attention to the syntax (X509:\<SKI\>a8052e8485eb17d865ba5d5ff0f7b326234f2860) Entra ID Sign-In Logs: "Tina Fluenza" has now registered on the portal https://myapps.microsoft.com and selected the certificate during the application process. This information can be found in the Entra ID Admin Center in the sign-in logs. With the confirmation of MFA by the claim in the token. HAPPY BINDING! I hope this information was helpful to you. I would like to thank you for your interest and for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on GitHub! https://github.com/tomwechsler
Disable Windows Hello AND Remove Existing PIN
Previously, after setting up Windows for an Azure AD user, it would give me a prompt saying that my organization requires a PIN for Windows Hello. I would hit next, then close the dialog asking for the PIN, and it would say there was an error or something, I'd hit OK and I'd be in Windows with no further Windows Hello harassment until I restarted. Once I got the device enrolled in Intune, it would apply the policy I have a policy that disables Windows Hello. However, a recent update to Windows seems to have made it impossible to bypass setting up a PIN. Because I can't enroll the device in Intune during the Windows Setup, the disable policy doesn't apply until after the PIN is established on the account. Once the PIN is set up on a Windows Account, it is not removed when Windows Hello is disabled via Intune/GPO, and it is seemingly impossible to remove manually. The only lead I've been able to find is to delete this folder: C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC\. However, Windows simply is not letting that happen, even after taking full ownership of the folder as a local admin. My only workaround is to first setup the device authenticating with my own account which will have the PIN. Then enroll in Intune with the user's account to their policies applied and Hello disabled. Then create the local admin account. Then add the users account. Then log into the local admin account and delete my account. Finally, log into the users account to create shortcuts and do QA. We use Bitlocker with a PIN that effectively does the same thing as Windows Hello with a PIN, except it also encrypts the disk. So I really don't see what it brings to the table besides a redundant password for users to memorize and extra help desk work when they forget it? How do I get devices configured without adding a bunch of work to get around Windows Hello?On-prem access from an aad joined device with Windows Hello for Business
Recently one of my clients asked me to setup Windows Hello for Business as part of our Modern IT Management PoC. So currently they are using convenience pin and the use case was that on their Modern IT managed AAD joined devices the users should be able leverage Windows Hello for Business being able to also access on-prem resources when on corpnet. As the client wants to benefit from Azure Identity Protection feature to detect leaked credentials and automatically take action on it (force pw change and MFA) he’s using AAD Connect with Password hash sync enabled. So he’s not using ADFS and already had some Server 2016 DCs inplace. Based on this great Decision Matrix: we decided to go for Windows Hello for Business Hybrid Key Trust. So there are already a couple of great guides on how to set that up here so I won’t to that again: https://blogs.technet.microsoft.com/chadcox/2018/03/19/my-notes-on-setting-up-a-poc-windows-hello-for-business-lab-using-hybrid-key-trust/ https://blogs.technet.microsoft.com/microscott/setting-up-windows-hello-for-business-with-intune/ https://gallery.technet.microsoft.com/Windows-Server-2016-Active-165e88d1/file/182710/1/W2K16%20Active%20Directory%20Certificate%20Services%20Lab%20Build.pdf My client however was a little bit scared as Michael Niehaus wrote on his blog the following: https://blogs.technet.microsoft.com/mniehaus/2018/02/21/afraid-of-windows-10-with-azure-ad-join-try-it-out-part-2/ Ok so we decided to do a quick lab repro to check if we also experience any issues regarding the CRL and guess what…sure we did – so let’s have a look if we can beat Michael working on it for several days 😉 If the user was logging in on his aad joined with his “legacy credentials” (username/pw) he could access on-prem resources and everything was ok, if he was logging in with Windows Hello for Business then the user was not able to connect to the on-prem share and the following error message appeared: So looking at the CAPI2 log in the eventviewer we saw that the client was not able to do the revocation check as the CRL was not reachable. Hmm strange as the CRL was published already externally via Azure Application Proxy (you can find a cool step by step guide over here https://blogs.technet.microsoft.com/microscott/how-to-set-up-azure-ad-certificate-based-authentication-for-office-apps-on-mobile-devices-ios-and-android-part-1/ ). At this point I was involving my PKI colleague Dagmar Heidecker who is an PKI expert as I didn’t want to spend several days 😊 We added the CRL via certutil directly to the client but somehow the client still always tried to access LDAP and internal web server and ran in a timeout. So we changed the CDP/AIP extension on the root and sub ca and removed the LDAP path. Next step was to request and install a new subca certificate and publish the crls. After that I checked that the DC already had the new certificate without the CDP pointing to LDAP. Then I restarted the KDC service on the DC, cleared the cryptocache (C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content and Metadata) on the client and…..whoohoo. On-prem access was working successfully when signed in via Windows Hello for Business! Kudos to my colleague Dagmar Heidecker!
Issues with Passkey Login Hanging on "Connecting to Your Device"
Hi everyone, I'm currently working on enabling passkey login for some users. I have a test account where I enabled the passkey and enrolled it in Microsoft Authenticator. However, when I try to log in and scan the key, it hangs on "connecting to your device." Has anyone encountered this issue before? How can I find the root cause, and which log would show what might be blocking me? Thanks in advance for your help!
