Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community

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):


  1. Configure a modern MFA solution to access on prem Windows 10 PC
  2. Use that solution to protect privileged accounts passwords
  3. 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)
  4. Have the ability to use multiple PAWs (privileged access workstation) with same MFA credential
  5. Have only one identity with one strong credential
  6. Same credential can be used on prem and in cloud (if needed)
  7. Connect to Domain Controller thorough RDP form the PAW using SSO (Single Sign On)
  8. 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:



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

Passwordless security key sign-in to on-premises resources - Azure Active Directory | Microsoft Docs

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 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.





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

Protected Users Security Group | Microsoft Docs. 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

What's new in Credential Protection | Microsoft Docs (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)

What's new in Credential Protection | Microsoft Docs

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.


Configure a Temporary Access Pass in Azure AD to register Passwordless authentication methods | Micr...


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.



















18 Replies
Thank you for the detailed article. This is a very good starting point for us to start working on the topic.
Excellent article!
We are looking to do something similar for a customer.

Excellent article!


If anyone reading this is looking for step-by-step guidance on how to enable multi-factor authorization (MFA), be sure to review the MFA setup guide in the Microsoft 365 admin center.


The setup guide is used to efficiently identify which MFA option is best for the organization as well as set up the application. This integration provides an additional layer of security and accounts are 99.9% less likely to be compromised.


Note: If you don't have Microsoft 365 admin permissions, open the guide in a test or POC tenant to get instructions.

Hello ,
trying to implement the gpo as suggested but the policy "turn on security sign-in key" is not present on a windows 2016 domain controller
Hello, thanks for the reply.
I wonder is it would be possible to use the microsoft authenticator instead of the Fido2 key to authorize users and more over Admins account
I've followed the steps provided but I've some problems.
After creating the GPO to enable the security key login and applied to the Test PC it doesn't show up additional login providers, only the classic username and password.
Thee same on a windows 2016 test server.
Am I missing anything?

@StefanoC66 currently authenticator app passwordless can be used only for cloud/azure login , not onprem 

Confirm Hybrid Device Join is working properly. Confirm your Windows 10 version 2004+ PC are Hybrid Device Joined : dsregcmd /status must report AzurePRT ON. Review other requirements :
A part from being able to authenticate my issue is that the option of selecting the usb key does not appear at all on the client, and I supposed this should be enabled by the GPO.
The client is showing as joined into the azure portal.
The test server, however, is not joining the hybrid configuration even if I configured AD connect to do it
after updating the W10 client to the latest feature now I have the option to select the Sign-in via USB.
Still having issue with the windows 2016 server tough which is not joining Azure AD
Hello please, for the FIDO sign on, review requirements here and here , after, enable the GPO turn on security key sign on. Check windows 10 version at least 2004. Currently FIDO sign in is not supported on servers but you can use FIDO to SSO to services after physically signed to a Windows machines . To test don't use RDP/virtualization .. FIDO keys must be used physically.


hello as per the windows 10 client, after updating it, I see the option.

Right now I have a fido key registered for the test user, I'm able to login to O365 with it, but when I'm tryin to use it on the PC I got the error  below .

I should say I'm using a virtual PC, as I cannot do it differently right now.
Screenshot 2022-03-25 113539.jpg


So is not possible to use fido keys to RDP to windows servers as we use normal USB Token with certificate ?

Hello, FIDO2 keys logins are physical way to access the PC. Today is not possible to use FIDO directly with RDP from another client. If you are using virtualization, check your hypervisor if it is capable of : 1) presenting a USB stick to the VM (usb passthrough) 2) emulate Keyborad / Mouse / Monitor (KVM) access (no RDP - legacy console access) . HyperV can do the number 2 (disabling enhanced session in view menu) but not the number 1 (only storage is possible to be presented via usb, non other types of peripherals .. there are third parties products to work around using the network to present an usb device -- like "USB redirector" but must be purchased ). I think vmware or virtual box might do the trick please check their documentation. Take care.

Smart job and very detailed article! I have recognized your footprint...
Very prone to try it in a lab.
Thank you for sharing.

Very good article and I am interested in testing this out. I do have a question regarding the Kerberos Server Object. Do I need to change the Password Replication Policy to make this work. My concern is possibly exposing Active Directory to attacks from Entra ID.

See this article

Microsoft will literally do anything except give us a simple universal TOTP method (or using the Authenticator app) for on-prem second-factor authentication.  I just don't understand this.  Passwordless is controversial.  I know Microsoft prefers it, and there is data to support it being better than passwords.  But it is not the industry standard.  Password + TOTP is the standard.  Why we can have this in Azure but not on-prem is the biggest mystery of all.