How to: Enabling MFA for Active Directory Domain Admins with Passwordless Authentication
Administer on premise Active Directory Using Azure Passwordless Authentication removing Domain Admins passwords Hello Guys, I am here just to demonstrate that today is technically possible (Proof of Concept): Configure a modern MFA solution to access on prem Windows 10 PC Use that solution to protect privileged accounts passwords Eradicate from the domain the password presence for those privileged accounts (make impossible to use a password to log on to domain to prevent some king of password attacks) Have the ability to use multiple PAWs (privileged access workstation) with same MFA credential Have only one identity with one strong credential Same credential can be used on prem and in cloud (if needed) Connect to Domain Controller thorough RDP form the PAW using SSO (Single Sign On) Obtain above with a sort of simplicity and costs control I am not here to discuss if this document in any parts adhere to all principles and best practices of a secure administration environment, I just want to show a feature as a proof of concept. It’s up to you to integer this work into your security posture and evaluate impacts. No direct or indirect guarantee is given, and this cannot be considered official documentation. The content is provided “As Is”. Have look more deeply above points: Many customers asked me, after they have used Azure/Office 365 MFA: is it possible to use something like that to log on to the domain/on prem resources. The solution is today present : the use a security key (FIDO2) : https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises. Please have a look also at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-deployment. I wanted to demonstrate that this solution can protect also Domain Admins group to protect high privileged accounts (important notice about is present in this document : (https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-faqs – “FIDO2 security key sign-in isn't working for my Domain Admin or other high privilege accounts. Why?”). After having substituted the password with one MFA credential (private key + primary factor) (here more information : https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-passwordless) we can configure a way to make the password not necessary for domain administration, very long and complex, and disabled: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy With other MFA tool (e.g. Windows Hello for Business), if we want to use different PAWs (secured workstations from which the Administrator connects with privileged accounts https://docs.microsoft.com/en-us/security/compass/privileged-access-devices) we need to configure and enroll the solution machine per machine (create different private keys one for any windows desktop). With the described solution below the enrollment happens only once (the private key is only one per identity and is portable and only present inside the USB FIDO key) and is potentially usable on all secure desktop/PAWs in the domain. The dream is: to have one identity and one strong credential: this credential (private key installed in the FIDO physical key) is protected by a second factor (what you know (PIN) or what you are (biometric), it is portable and usable to consume services and applications on premises and in cloud To connect using RDP to another/third system after this kind of strong authentication is performed on the physical PC a password is needed (but we really want to eradicate the use of a password)….So.. We can use a Windows 10 / Windows 2016 and afterwards feature (Remote Credential Guard https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard) to remove this limitation. If you have a certain hybrid infrastructure already in place (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity, https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains, etc.), the activation of this solution is simple and there are no important added costs (a FIDO key costs around 20 / 30 euros) The solution is based on 3 important features: AzureAD/Fido Keys, Remote Credential Guard and primarily Active Directory SCRIL Feature [ https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/passwordless-strategy#transition-into-a-passwordless-deployment-step-3 : "...SCRIL setting for a user on Active Directory Users and Computers. When you configure a user account for SCRIL, Active Directory changes the affected user's password to a random 128 bits of data. Additionally, domain controllers hosting the user account do not allow the user to sign-in interactively with a password. Also, users will no longer be troubled with needing to change their password when it expires, because passwords for SCRIL users in domains with a Windows Server 2012 R2 or early domain functional level do not expire. The users are effectively passwordless because: the do not know their password. their password is 128 random bits of data and is likely to include non-typable characters. the user is not asked to change their password domain controllers do not allow passwords for interactive authentication ...] Chapter 1 – Enable Passwordless authentication and create your key Enable the use of FIDO Keys for Passwordless authentication. In Azure AD \ Security \ Authentication methods, enable the use of a security key for a specific group and set the keys settings in accordance with the HW provider of the key (in my case Force Attestation and Key Restriction set to off). Confirm Hybrid Device Join. Confirm your Windows 10 2004+ PC are Hybrid Device Joined. Confirm users and all involved groups are hybrid Confirm all involved users or groups are correctly replicated by AD Connect, have Azure Active Directory properly configured and login in cloud works correctly Implement Kerberos Server to foster on prem SSO (Single Sign On) for on prem resources follow this guidance https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises Enroll the key. Please don’t use Incognito Web Mode (sign out already connected users and use “switch to a different account”). If during enrollment errors come up, check if any user is already signed into the browser (in the new Edge use “Browse as Guest” that is different from “Incognito Mode”). Login to Office.com with the user you want to provide the USB KEY and reach My Account page In My Account page open Security Info and initialize the USB Key. https://mysignins.microsoft.com/security-info If not completed before, enable MFA authentication by using a phone (SMS) or Authenticator App (in this case the user was not already provided of MFA , so the systems automatically make you enroll the authenticator app in your phone) Now, because you have an MFA tool, you can create/enroll a security key: add method / USB Key. The browser challenges you to insert a key.. to inject your identity into it Create a new PIN ! Confirm touching the key Name the key Done - security Key is enrolled with your identity Perform an Office365 Passwordless Authentication Verify you are able to sign on to O365 using the Key w/o the use of a password. Please use Microsoft Edge, if already logged click right corner and “browse as a guest” Please remember to click in “Sign in Options” to trigger key authentication : Well done: you are logged in the cloud Passwordless! Chapter 2 – Enable on prem multifactor login Deploy a GPO – Group Policy Object- to enable FIDO2 on prem login with Windows 10 2004+. In your on prem environment we can enable the use of USB key credential provider (Windows has multiple credential providers: password, usb key, smartcard, et.). Enable and link this setting to your Windows 10 2004+ machines. Restart involved machines. Now you will see a new icon to login to the PC. Clicking on sign in option you can use this new credential provides – FIDO security key - . Insert the Usb key, type the PIN… On some FIDO Keys you can avoid PIN with biometric (fingerprint). You can use the same identity/credential in all the PC with the FIDO credential provider enabled. Remember that currently for on prem sign on only one user per key is available (you can’t have multiple identity on the same usb key). Please note that this kind of authentication is recognized by Azure/O365 cloud as one already claimed MFA so when you open your preferred application the connection is in SSO (you don’t have to re-authenticate or perform another strong auth). Please note that with the same key you can login to the cloud applications using MFA from external computers w/o any modifications (like kiosks, byod computers, etc). Please note that you have access to all on prem services because the Kerberos server we installed above is useful to foster the obtention of Kerberos tickets for on prem AD service consumption Chapter 3 – Use FIDO KEYS to protect privileged users (Domain Admins) and De-materialize their password. Now we are going to enable a FIDO key for the Domain Admin or configure FIDO KEYS to work with privileged users. The default security policy doesn't grant Azure AD permission to sign high privilege accounts on to on-premises resources. To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (e.g. CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>). Remove all privileged groups you want to use with FIDO KEYS. Consider one user might be member of different groups, so remove all wanted user is member of. I removed all groups with the exception of Domain Controllers .. Make the test user member of Domain Admins group Wait AD Connect Sync Time (normally at least of 30 min) Now enroll the FIDO Usb Key for the privileged account following Chapter 1 of this guide Now test the Login with the Domain Admin using the FIDO KEY and check the possibility to be authenticated to onprem services (e.g. Fileshares, MMC - ADUC Consoles, etc.). Try the high privilege like creating a new user…. Now that we have one alternative way to Sign In on prem and in cloud (instead of password) we can work on password eradication. Obviously, every application we want to use must not use passwords (work in SSO with AD or Azure AD). This is not a problem for a privileged accounts because these should not have any application access nut only accesses to administrative consoles We will enable SCRIL policy (Smart Card is required for interactive logons) for the privileged user: Smart Card is required for interactive logon = the user password is reset and made random and complex, unknown by humanity, the use of password for interactive login is disabled Test you can’t access with password anymore To complete and strengthen the password eradication we want to prevent the use of the password also for network authentications using the NTLM protocol, so we are going to make the user member of “protected users” group https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group. This because if a bad guy reset that user’s password, he/she might use the NTLM protocol to log on using password, bypassing interactive log on. Protected Users disables the entire usability of NTLM protocol that is not needed to common AD administration. If you don’t want to disable NTLM protocol and If you have Domain Functional Level 2016 you can also enable NTLM rolling to make NTLM password hash to cycle every login and improve the password eradication https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/whats-new-in-credential-protection (Rolling public key only user's NTLM secrets) Probably you want to use that user to log in to privileged systems with Remote Desktop. By default, Remote Desktop Protocol requests the use of passwords … Here we don’t have a password to write because the password is unknown by humanity….. so … how to? The simplest way to solve the above problem is to use Remote Credential Guard feature if you have the needed requirements (..Windows 10, version 1607 or Windows Server 2016.. or above) https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/whats-new-in-credential-protection To enable it on the server we want to connect to, just add this registry key using the example command reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD From the client where we used the FIDO login, just run RDP with the parameter /RemoteGuard Now also the RDP remote authentication performs well without passwords!!! Now we signed in a Domain Controller using a MFA key and is no more possible to use a password for domain administration. Update1: using temporary access password might be possible to never assign even a beginning password to a Domain Admin neither need a phone authentication. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-temporary-access-pass As detailed above, create a Domain Admin on prem, immediately enable SCRIL and Protected Users, wait AD connect sync time, create a temporary password for that admin user (the temporary password can only be used to enable an MFA credential w/o using a Phone and w/o the risk of someone else accessing applications during the configuration phase). We recommend to maintain Azure Global Admins and Active Directory Domain Admins identities separately, so don't make synced Domain Admins member of Azure Global Admins role.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.
