Windows Authentication for Entra ID for SQL MI
Hi Team, I recently come across a use case where we have to use Windows Authentication for Entra ID for SQL MI. My question is based on Microsoft documentation https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-setup?view=azuresql There are two options. Options 1 Modern interactive flow Options 2 Incoming trust-based flow Proceeding with Option 2 (Incoming trust-based flow) the authentication flow works some as the following Step Action From To Network Connection 1 Initiate Connection Client (Windows Server 2016) - - 2 Request Kerberos TGT Client Domain Controller (Windows 2012) On-premises network 3 Issue TGT Domain Controller Client On-premises network 4 Request Service Ticket via Kerberos Proxy Client Microsoft Entra ID (via proxy) ExpressRoute (Microsoft peering) 5 Issue Service Ticket Microsoft Entra ID Client ExpressRoute (Microsoft peering) 6 Submit Service Ticket Client Azure SQL Managed Instance ExpressRoute (private peering) 7 Validate Ticket and Exchange for Token Azure SQL Managed Instance Microsoft Entra ID Azure internal network 8 Authenticate User and Grant Access Azure SQL Managed Instance Client ExpressRoute (private peering) If above is correct. Can anyone confirm we have to synchronize service accounts and users to Entra IS that are used by applications? Does the client (running application ot SQL management studio) require access to Entra ID or it will be requested by on-premises AD on behalf of application server Many Thanks !Join Merill Fernando and other guests for our Identity and Network Practitioner Webinar Series!
This October, we’re hosting a three-part webinar series led by expert Merill Fernando for Identity and Network Access practitioners. Join us as we journey from high-level strategy to hands-on implementation, unifying identity and network access every step of the way. Each session builds on the last, helping you move from understanding why a unified approach matters to what are the foundations to get started, and finally to how to configure in practice. The goal is to equip you with actionable skills, expert insights, and resources to secure your organization in a unified, Zero Trust way. Register below: Identity and Network Security Practitioner Webinar Series | Microsoft Community Hub
How to resolve "AADST55203" error: Multi-factor authentication configuration blocked
{ "error": "access_denied", "error_description": "AADSTS55203: Configuring multi-factor authentication method is blocked. Trace ID: Correlation ID: Timestamp: 2025-09-17 20:48:30Z", "error_codes": [ 55203 ], "timestamp": "2025-09-17 20:48:30Z", "trace_id": "", "correlation_id": "", "suberror": "provider_blocked_by_rep" } SMS authentication method was previously configured in our B2C Entra and was functioning correctly until last week, when it suddenly stopped working. Currently, users can only authenticate via email. Conditional Access policy is also in place that requires Multi-Factor Authentication (MFA).
Microsoft Entra Connect connecting always to old DC
We are planning on demoting old DC server. When doing checkups I noticed that Entra Connect keeps connecting to this specific DC we'ew planning to demote everytime it connect to Active Directory. So now I'm wondering does this need any additional configuration to keep sync working after DC Demote. I found out that there is option to "Only use preferred domain controllers" but I'm not sure if that's what I want do do. There were the red line is is the old DC to be demoted. "Only use preferred domain controllers" setting. If I enable this setting I got this kind of notice. I don't feel like this is the right way to do it so I canceled at this point.
Sign In Error 90072 with On Prem Accounts - How to mitigate?
We receive weekly reports from one of our security vendors regarding login failures across our environment. As of recent, we've noticed a spike in interactive login failures, particularly with Microsoft services. The application that produces many of these logs is Microsoft Office. Upon investigation, we've determined that many of these sign ins procure error code 90072 with the following error message: "User account '{user}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{application}'({appName}) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account" As a disclaimer, I did not edit this message to insert the unfilled variables in brackets - that's how the error message appears in our Entra portal. We currently run a hybrid environment, and all of the users with high volumes of failed sign ins with the given error code and message are on-prem accounts. These logs produce a lot of noise that we would rather not have polluting our reports. Do you have any information we can use to help remediate this issue?Shape the future of our communities! Take this survey to share your practitioner insights. 💡 ✏️ 🔓
This brief survey explores your experiences and preferences in professional identity and network security communities. Your feedback will help shape our team's approach to future community resources and engagement opportunities. Take the survey here! For any questions about this survey, please contact dansantos@microsoft.com. Privacy Statement: https://go.microsoft.com/fwlink/?LinkId=521839
User Identities in EntraID - how to remove?
I have a user that shows up with multiple identities. No other users are like this and we believe its stopping him from logging in with his alias email address. When i run get-entrauser it returns the following under Identities: {@{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=federated; issuer=MicrosoftAccount; issuerAssignedId=}, @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} Every other account just has this @{signInType=userPrincipalName; issuer=OURPRIMARYDOMAIN.onmicrosoft.com; issuerAssignedId=UPN}} How would i go about removing those identies from that user? Struggling to find any info online.
Understanding Sign-In logs - password hash sync from another country?
Gday Had a couple users show up today at risk - failed logins from the US, while we're in Canada. Users are not in the US, not using VPNs, logins are to Microsoft services (Office Home, One Outlook Web). The useragent is the axios client, the auth method is 'password in the cloud' - which as i understand it, means the password is being auth'd directly against Entra. However, one of them is Azure AD sync'd. The auth method on this is 'password hash sync' - as I understood it, this means the password is going to the DC first, then the resulting hash is being passed to the cloud. This is what we have on our Hybrid 1-way tenants. But I don't really understand what's going on when I see a Password Hash Sync attempt, from another country. Is that random person passing a (wrong) password to my closed-off server? Or... is it just that the hash that Entra has to authenticate with, is from the DC? Is the 'password to DC, to Cloud' the 'passthrough' auth method? ThanksPasswordless 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.
