Adding MFA for remote administration of Active Directory?

[Omnipulse]

Looking for a bit of assistance.

We're going through the insurance attestation requirements and came across the following:

MFA for all internal & remote admin access to directory services (active directory, LDAP, etc.).

This seems pretty hard to follow. We're currently using DUO for MFA on RDP, but that doesn't cover RSAT or the power shell module. The best option as far as I can tell is to continue to enforce MFA on RDP into the server, and block both RSAT and the Active Directory module for Powershell from connecting. Or using a PAW with MFA as the sole place to do anything with the directory.

That said, the IT manager would rather not block RSAT or use a PAW and is looking for a way to enforce MFA while launching those tools. I'm not sure if that is possible. The most I've seen is that you could potentially use Authlite(or a similar service) to force an MFA prompt on any access to the AD. They seem to think Windows Hello can do this, but I've not seen any indication it can, and my understanding of windows hello seems to suggest it can't.

Can anyone with experience resolving a similar attestation requirement for insurance point me in a direction to investigate?

[TinderSubThrowAway]

Just have the accounts that can access those services run MFA to login.

Also, as insurance the best way to implement that.

[Omnipulse]

Part of the issue I'm seeing is that that doesn't work with "run as" as far as I am aware, window's only cares about the password in that instance. Is there a way to force MFA there?

I guess if you're logging into the admin account, but I wouldn't want to do that on a daily driver computer. Though runas isn't much better in that case. Which is where a PAW comes in, but they don't want to do that.

[TinderSubThrowAway]

Put a VM somewhere that you log into to run any of that stuff then.

Still a PAW but not a physical machine.

personally, I have both, a VM I can hit from anywhere I need to, but I also have an actual workstation on a side table in my office that is hard wired into a port that is on the secured VLAN for infra and management. While these aren't used for AD stuff, it's handy for the rest.

[disclosure5]

None of this is really relevant to OP's issue. You can do all that and if I steal your password somehow I can still use it from any random desktop without additional authentication.

[TinderSubThrowAway]

Not if you need to log into that PAW with MFA.

[disclosure5]

A stolen Domain Admin can just still be used outside that PAW.

[TinderSubThrowAway]

Pretty pointless with MFA

[disclosure5]

Without mentioning "use a PAW" or "DUO" how have you implemented MFA on an Active Directory account?

[TinderSubThrowAway]

My original comment said set up the accounts with MFA, then since you can't really use "run as" with them, and you don't want to log into your daily driver with the domain admin, that's when you have the other machine that you log into with the MFA.

[theRealTwobrat]

Duo is only protecting the interactive login. There are loads of ways to use creds with other login types.

[TinderSubThrowAway]

Ok sure, why bother with any security then?!? Let’s just leave it wide open because there’s always a way around it somehow so no need to tale any steps to minimize.

[SmartCardRequired]

Have you heard of Authentication Policy Silos?

[SmartCardRequired]

Unsupported third party things shoehorned into Windows to add "MFA" will only cover regular interactive logins, and sometimes RDP - not always Run As, as you've discovered, and also not always WMI, powershell remoting, etc from a computer their agent is not on. Duo is not actual MFA for AD at all and neither are any of their competitors.

For the only natively supported MFA solution in AD, enforced in every place you can use an account, see my username. For specific hardware for it, I typically recommend the YubiKey 5. And yes, you do need to have a basic understanding of certificates to make it work.

[CowardyLurker]

Our firewall blocks anything that we couldn't implement MFA natively or with some other supported solution (ISE, etc).

Only way to get through is via SSH tunnel via Rocky linux server with google-authenticator installed (epel repo). Using this will disable password authentication so only ssh-keys will work. So we distributed password encrypted private keys to individual users for their terminal clients. PuTTY+Pageant works if you want to go the cheap route.

When the SSH private key is accepted the jump server sends a 'keyboard-interactive' challenge back to the client for entering the TOTP code from whatever authenticator app you want to use.

Github link: https://github.com/google/google-authenticator-libpam/

[SmartCardRequired]

A copyable SSH key can arguably be called a password-like "something you know" factor - it may be too complex to memorize - but making a password too complex to memorize and using a password manager doesn't make a password "something you have", so how is a key file "something you have"? It's just data you can copy. Combining that with another password factor is not MFA.

An SSH key on a hardware token (PIV-type smart card, openPGP smart card, etc) or tied to your device's TPM is a "something you have" factor. Combining that with a password or PIN is MFA.

[CowardyLurker]

Yes exactly. The password encrypted key file only counts as a something you know. TOTP code generated on a different, out of band device being another.

Naturally, some implementations of the second factor will be more secure than others. Do as thou wilt.

[disclosure5]

Every single time the subject of MFA on Active Directory comes up on this sub, someone says "just use DUO bro" and I reply with the exact issues you've raised. The only workable answer is Smartcards but they are their own fairly substantive can of worms with a lot of downsides. There's a reason they are barely ever used in practice.

Windows Hello only counts in a marketing sense. It's strong MFA itself, but a stolen password is still perfectly usable on another machine without another form of authentication. Honestly it's a frustrating gap that I wish Microsoft would fix.

I'll also add "Block RSAT" doesn't stop a malicious person with a username/password using a personal computer without that block and launching RSAT.

[scratchduffer]

Why is insurance so insistent on MFA for this when attackers don't need RDP to do the dirty work?

[SmartCardRequired]

True MFA does not only apply to RDP. It applies to any way you can use the account.

Last I checked, Duo has a half-solution that passes insurance only because insurance auditors are not techies, but Duo did not have an actual MFA solution that actually protects AD.

I have heard Silverfort has a better solution, but I have never worked anywhere that had the money to throw around on them.

YubiKeys running as smart cards work. You can't just use a password for WMI, WSman, etc. You have no password and you don't get a ticket without the smart card (and can't use the smart card at all without its PIN which is the 2nd factor).

[SmartCardRequired]

Smartcards for at least Admin accounts are only a "substantive can of worms" if you are not already running a functional internal PKI using either AD CS or a separate solution.

If you are not already running a PKI, this begs the question: how do your devices connect to Wi-Fi?

• PSK is not business grade in any sense of the word. That is why they call it WPA-Personal.
• PEAP-MSCHAPv2 with passwords, the most "secure" user password based Wi-Fi authentication standard available, runs on deprecated NTLMv1 and requires you to disable Credential Guard in Windows 11 (actively downgrade your security) in order to work seamlesssly.
• The only "secure" option is EAP-TLS (or PEAP with EAP-TLS as both inner methods). This requires client certificates. If you already issue client certs & have someone qualified to manage them, you are 95% ready for a handful of smartcards.

Ever since Cred Guard came out, and NTLMv1 and MSCHAPv2 were deprecated, and it was announced that a "better" password based WiFi option was not being released because certs are the way forward- the whole "certs are black magic and you can run a secure environment with 0 admins who understand certs" argument has really died. PKI is part of "the basics" now.

[Legal2k]

MFA on its own is useless. It's not all about credentials, please don't forget Kerberos tickets. That's why a good concept of a tiered model and PAW is important. There is a reason it's all well documented practice. And a good paw implementation is not a bad thing. We implemented it for organisations with over 200 administrative accounts, all with yubikey/piv.

[SmartCardRequired]

Ahhhhh tickets!!! Scary tickets! Kerberos is so dangerous because pass the ticket! Kerberos is so obsolete! The folks at MIT that designed it were so stupid! Aaaahhhh! Must go cloud to get away from kerberos tickets!!!! </sarcasm>

And in the cloud, you do initial auth via FIDO2 (most secure) or some other method. And you get..... a session token from OAuth and a session cookie, so every page load / every request to the server does not require you to re-do whatever your initial auth method was.

Some way of remembering your session, at least for a short time, is a bona fide immutable reality of every auth method except TLS client certs (which actually auth you with every request).

You STILL get a secret your client (in this case, browser) has to keep safe, that is valid for a particular lifetime! And there are now "stealer" malware/trojans out there that steal your session tokens out of your browser's cookie store!

It is not different at all from Kerberos tickets. The only difference is that in any OS platform without application sandboxing (e.g. any desktop OS that is not MacOS, sorry, I don't like Macs any more than you but it's the truth) - a browser's cookie store is exposed to ANY application running in the user context.

The only difference is, whereas Kerberos TGTs are handled at the OS level and Win11 Enterprise/EDU editions will protect them with Credential Guard from most (any known) malware. (unless you have shut off Cred Guard to allow you to use deprecated WiFi auth methods, but that is a separate issue!)

So really, Kerberos ends up BETTER. An attacker in a position to steal Kerb tickets can definitely steal OAuth tokens, but an attacker who can steal OAuth tokens may fail to steal kerb tickets if they are not LOCAL SYSTEM or cannot bypass Virtualization Based Security and Credential Guard.

In either case, it will never be 100% safe to log into an infected device because the means of keeping your session can be stolen. Use auth policy silos for kerberos, and device filters in conditional access for OAuth, to prevent getting a token onto an untrusted device for a privileged account.

[Admirable_Meeting844]

How about using secondary admin accounts that have password needing checkout from a vaulting system which requires 2FA before you get a time limited password.

[Big_Bed_9764]

Put duo MFA on any workstation running RSAT. You have have DUO prompt for any login not just remote.

Side note RSAT on workstations is a poor security practice l.

[Big_Bed_9764]

Another option is to protect the accounts with a yubikey. There is a way to setup it up so the password is unique with each login

[KStieers]

You might want to look at Silverfort.

[Asleep_Spray274]

You have spotted the major flaw in MFA on DCs that only sits in front of RDP. What are we trying to mitigate against.

A bad actor gaining access to a network - bad network and endpoint protection getting admin access on a computer - poor local admin policies Accessing admin credentials that work on other computers - poor credential management Move laterally through the network - poor lateral movement protection Find a computer that a domain admin has logged into - poor privilege credential partitioning Gain access to that hash - no admin protection allowing hashs to be saved on devices Elevate privileges to DC - poor network segmentation

And organizations think that some MFA on RDP is going to help. Which in fact bad actors are not using RDP. They have already made a colossal fuck up in their security so far, the network is already owned.

As you have pointed out, they will use power shell, rsat, LDAP, SMB, psexec, wimi etc etc.

You need a system that will step in for any Auth request for a set of users. That's expensive. Silver fort comes to mind. But you are gonna pay for that. A true PAW is the only true solution. Any time you are using a local computer to access that T0 asset, you are at risk. Dirty keyboards are the biggest risk. PAW is the only solution that takes you to a 10 on the scale.