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!Windows Hello for Business prompt after Hybrid Azure AD Joining Win 10 Device | WHFB disabled
Hello, I'm looking for some clarification on the behaviour around Windows Hello for Business after Hybrid Azure AD joining Windows 10 devices. I recently enabled HAADJ in AAD Connect. As expected first of all, the devices acquire a userCertificate attribute as part of the WorkplaceJoin schedule task, sync to AzureAD as part on the next AADConnect sync cycle and show up in the Azure AD tenant as a HAAD device. The issue I encounter is with the Windows Hello for Business prompt. When a synced user logs in, they're prompted to setup a Windows Hello for Business PIN. You can skip the process and continue but every subsequent login ask you to set-up a PIN which you can sync. The devices are HAADJ but not enrolled into Intune for MDM. In the AzureAD Portal under Microsoft Intune\Device Enrollment\Windows Enrollment\Windows Hello for Business, it was set as Not Configured. I also changed this to Disabled, but the users still get the prompt. I only way forward I'm finding to deal with this is by setting the settings “Use Windows Hello for Business” under "User Configuration\Administrative Templates\Windows Components\Windows Hello for Business” to Disabled. It was previously set to Not Configured. This stops the setup PIN prompt coming up after login, however, notifications still appear in the notification area after login saying that The system is configured to use Windows Hello for Business, Click here to setup you PIN. I do not get this behaviour in other environments where I have HAADJ configured, with seemingly the same settings. End goal is wanting to retain HAADJ but disable all the prompts for setting up Windows Hello for Business. Any ideas?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.Windows Hello - Which method is being used?
Could somebody please direct me on how to verify the method of Windows Hello being used? We have Windows 10 machines enrolled and managed in Intune and hybrid azure ad joined as part of a hybrid identity model with Password Hash Sync configured. I have a portion of Surface devices which have recently received an update from 1909 to 20H2. After the update, at the next login, a toast notification is displayed to encourage the use of Windows Hello (see screenshot). Note, we have not enable the settings for Windows Hello for Business yet. The user can setup the camera recognition and PIN and it works and continues to work after several reboots. This is curious, as our work on prerequisites for getting Windows Hello for Business working in the hybrid environment hasn't started yet. The experience for configured Windows Hello appeared to be slightly different to what I had seen before. For example, when controlling elsewhere, I have been used to the initial full blue screen enrolment for WHFB. To remove the Windows Hello functionality for the user, I ran certutil.exe -deleteHelloContainer as the logged in user, this remove the associated biometric and PIN after a logoff/reboot. I enabled WHFB on that same device using local policy editor under the 'User Configuration\Windows Components\Windows Hello for Business\Use Windows Hello for Business' and rebooted. On next login, I get a full blue screen WHFB prompt, which I would normally expect, an MFA prompt from Azure AD and I can then setup camera biometric PIN for log in. After attempting to lock, logoff or reboot, I cannot login use the camera or PIN as it returns as error saying 'Your credentials could not be verified'. I would expect this error, because the prerequisite work to enable WHFB in a hybrid environment hasn't been done. So my question is, when user configured the Windows Hello option (advertised in the toast notification after the 20H2 update) how can I check which method of of Windows Hello is being used and how is that functioning. Is this somehow using Windows Hello as opposed to Windows Hello for Business?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
Disabling Synchronization Rule - Out to AD – User NGCKey in AzureAD Connect.
I have an on-premise deployment of Windows Hello for business [Certificate Trust] using ADFS 4.0 DRS. I also have an O365 Apps for Enterprise (Pro-plus) subscription. The identities (users only) are synced from on-premise to Azure AD. Only 8 attributes (Required for O365 Pro-plus is synced), [App Filtering in used] accountEnabled cn displayName objectSID pwdLastSet samAccountName sourceAnchor usageLocation userPrincipalName No device/group write-back is enabled, no other O365 applications are used. I am seeing plenty of errors like ones mentioned in blog below (Q4) in Synchronization Service , where the service is trying to overwrite/remove the msds-keycredentialLink attribute [Populated to due WH4B provisoning] for insufficient permissions. https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-mailbag-windows-hello-for-business/ba-p/445349 They should be triggered by the synchronization rules listed below . IN from AAD - User NGCKey (to DeviceKey in mv) Out to AD – User NGCKey (from DeviceKey in mv to msds-keycredentialLink in AD) My questions, 1. Why does it need to writeback the NGCkey ? 2. Why the errors still persists even if the below rules are disabled ?
