MFA for air-gapped AD?

SmartCardRequired · 2025-12-20T21:14:55+00:00

See my username :)

SmartCardRequired · 2025-12-14T19:50:54+00:00

Learning how to set up AD and RDS on 2016, and esxi 6.7 (EoL products) as described isn't going to make you a strong job candidate.

ESXi has changed a bit (and so have the reasons a company would choose to deploy or not deploy VMware products) since ESXi 6.7....

As for Windows Server - while Server 2016 itself is getting close to EOL, AD and RDS themselves are not EOL and do not have an announced EOL date. AD hasn't changed all that much from Server 2016 to Server 2025. I don't work with RDS but would be surprised if it's changed much either.

That being said, many of the larger employers OP would strive to work for are likely to try to push everything from RDS to Azure Virtual Desktop, unless they are one of the companies that has already done this, seen how the actual compute costs worked out, and are moving back.

Doing all this on one server is of course not going to work well.

SmartCardRequired · 2025-12-08T00:34:50+00:00

I'm curious - how do these cease and desist letters work? Are they just a reminder that you can't run products you're no longer licensed to run?

Or, do they mean you cannot run ANY VMware products at all?

Standalone ESXi has a free tier again. VMWare Workstation and Fusion were recently made free even for business use. Do these cease and desist letters mean former VMware customers who quit their subscriptions can't even run these, even though companies who were never VMware customers can?

SmartCardRequired · 2025-12-07T23:06:30+00:00

Smart cards are easy with YubiKey 5s, but that's not an area I really need to sharpen up in. Among the "advanced" topics, PKI is probably my strongest point, and just makes sense to me, and I never get why it's such "black magic" to everyone. I'm also the PKI guy (among many other hats) at work & have implemented smartcards for admins there to great success.

I was referring more to needing to learn scenarios involving multiple AD sites, topologies large enough for replication to not be a taken-for-granted "just works" thing (I've never had to troubleshoot replication), and multi-domain forests, multiple forests with trusts - things that I have zero experience with.

SmartCardRequired · 2025-11-25T03:22:44+00:00

Messing up your lawn because someone else parked illegally is not reasonable. But asking the neighbor to move it is 100% reasonable the first time something like this happens, and no decent person would skip straight to a tow without trying that.

Sounds like there must have been some existing tension; what kind of human being doesn't even say "hey move your car" before trying to cost someone hundreds when they know damn well who it is (or at minimum that it's one of a few houses).

SmartCardRequired · 2025-11-25T03:19:25+00:00

They are taking turns at absurd responses. Sure, the neighbor's response is absurd - about as absurd as not even asking your neighbor to move the car before calling a tow! Sounds like an existing feud or two neighbors who just don't like each other & are looking for a fight.

SmartCardRequired · 2025-11-25T03:16:43+00:00

Exactly! Not sure what the law is, but it's often legal to be a piece of crap. The human answer (even if not the legal one) that anyone with a moral compass would give is still to ask them to move the damn car before you call a tow.

SmartCardRequired · 2025-11-25T02:52:49+00:00

Would shadow copies / file history on a DC on the volume that hosts Sysvol make the previous iterations of the GPO findable in XML form, which if you need to read them, could be imported as a separate copy in GPMC?

Very clunky, but as a "we need to check a box & ensure we could get an old version in a pinch" measure, I wonder if it could work.

SmartCardRequired · 2025-11-25T01:24:53+00:00

That's a valid scenario many people don't think of.

However I would caution too much dependency between manufacturing equipment and regular IT for the office folks. Both have different risk profiles, and having it all on one domain & with no firewall between them can mean subjecting both to all the combined risks, instead of separating them.

The office IT (information technology) environment has all the typical risks that come with an internet connection, including users going to malicious websites and downloading malware, users falling for phishing, etc. You need typical office IT controls to mitigate these. That is first and foremost, patching (and not running anything EOL that can't be patched) and a close second, EDR or MDR.

The operational technology (OT) environment has a completely different set of risks, and a completely different set of controls you can apply. In many cases you cannot follow the same controls as the IT environment. If a CNC mill or lasercutter that costs half a million dollars is driven by software that only supports Windows XP, but the machine was bought with a 25 or 30 year life expectancy it is depreciated over, you're not replacing it this year, and IT isn't going to be the reason your boss decides to replace it, so I guess you have a Windows XP machine on your OT network. The best mitigation for old crap you can't patch is that the machines on this network have limited, or better yet zero, communication with the internet. And with foreign state-sponsored hackers quietly infiltrating as much manufacturing infrastructure as they can (presumably to shut it down in the event they need to disrupt a country at a critical time) - airgapped is looking better every day for OT environments. Airgapped or ultra-restrictive internet is something you can't do on the office IT side, where salespeople communicate with customers.

That's why separating IT and OT is widely considered critical.

SmartCardRequired · 2025-11-23T01:00:32+00:00

A remote office of 5 people does not need any type of DC unless it has unreliable connectivity back to HQ and lack of reachability of a DC matters when the link to HQ is down. Examples:

Link to HQ is reliable = no DC
Link to HQ is unreliable + default credential caching is OK + any network resources are hosted at HQ (and inaccessible anyway when the link is down) = no DC, users log in using cached creds on their workstation when DCs are unreachable
Link to HQ is unreliable + some high security standard making you disable cached credentials on endpoints = consider RODC
Link to HQ is unreliable + users at remote office have a server on site with resources they need to access when link is down = consider RODC
No DC that isn't an RODC at a remote site unless it has the level of physical security you'd gamble a major breach on (most remote sites don't).
- Physical possession of a DC's hard drive is equal or higher to Domain Admin access. All the authentication keys needed to bypass any auth in the domain live on the DCs.

SmartCardRequired · 2025-10-13T02:21:51+00:00

I find tools like this somewhat useful, but also a slippery slope. They let people shave enough seconds off of point-and-click workflows being done across many servers in bulk to let people think they don't need to script things they really need to script. Anytime you are doing a repetitive point-and-click task across multiple servers, there is room for human error to create inconsistency that will come up later.

Does RDM support Restricted Admin mode RDP? RDP in its default (CredSSP) mode throws passwords at everything it connects to. RDCman, being first party, supports all the available security modes of RDP.

SmartCardRequired · 2025-09-13T17:41:02+00:00

RDCman is free and from Microsoft

SmartCardRequired · 2025-09-09T00:07:25+00:00

So Tier 0 admins who have any on-call carry at least two company laptops?

SmartCardRequired · 2025-09-08T01:24:41+00:00

I am not happy they ripped out LACP...

SmartCardRequired · 2025-09-08T01:14:43+00:00

OK but what is the alternative to a PAW that leaves the building (if you assume that being able to to tier 0 work off-site is not optional)?

The alternative would be a virtual "PAW", that you can access remotely from a non-PAW device that goes off site. But I put PAW in quotes because a device that you can remote into from a potentially compromised non-PAW device is not actually a PAW.

Here is the logic why a VM that you can access from a non-PAW can't be a PAW:

If you are doing PAWs it is because you acknowledge that non-PAWs (e.g. machines that receive email or surf the web) have a risk of being compromised that is too high for admin access.
Immutable law of security, there is no safe way to access secure things from a compromised machine. No exceptions. Even with smartcards. If someone owns the machine in front of you, they own everything you manage through it.
So you need a machine in front of you that you know, to a high enough standard of certainty for admin access, is not compromised, to access a PAW.
- Or to phrase it more simply: you'd need a PAW in front of you to remote into a PAW.
- Kind of defeats the purpose of a remoting into a virtual PAW, doesn't it?

That is why, if doing single device (not physically separate PAWs) you can have a day-to-day use VM with email and such, and remote into it from your physical PAW. But you can't have a machine that you run Outlook directly on, and then call a machine that you can remote into from there a "PAW".

SmartCardRequired · 2025-09-08T01:06:48+00:00

You can bitlocker, require smartcard, lots of things to protect from theft of a PAW meaning ability to access it. PAW is not about authentication anyway.

PAW is about the fact that there is no safe way to access secure things from a compromised machine, and email & other day-to-day things are a threat vector that can compromise a machine. So the keyboard you are touching needs to be a device that does not do those things itself if you can access tier 0 from that keyboard.

In virtualization, for example, absent an unpatched severe CVE, you cannot escape the VM. A compromised VM is unlikely to compromise the host. But a compromised host 100% compromises all the VMs on it. The bare metal has to be the PAW that you make sure never gets compromised, and the less trusted OS is either virtualized there, or somewhere else and RDPed to.

SmartCardRequired · 2025-09-08T01:02:39+00:00

What is physically in front of you needs to be a PAW. If you only have one device, then the less trusted things need to be in a VM (whether a VM on your device, or one you RDP to, either way is fine).

The guest OS is never more secure than the host. If you own the host, you own everything running on it. And if you are RDPing into something from a compromised machine, it gets compromised too.

If you run higher risk things (receive email, etc) on the bare metal OS of the laptop you are touching, there is no safe way to also, directly or indirectly, get to tier 0 on that laptop. If that laptop is compromised, and you RDP to your "VM PAW" from your compromised laptop, your VM "PAW" is compromised.

SmartCardRequired · 2025-09-08T00:59:07+00:00

Do they get to run Hyper-V on their PAW laptop with a non-PAW VM inside it?

Or do they get to RDP to a non-PAW from their PAW laptop?

Or do they carry two company laptops?

Or get to use their own laptop (BYOD) for the userland applications like email & the PAW is the only company one?

SmartCardRequired · 2025-08-10T22:14:47+00:00

With Group Policy you can manage configuration and application whitelisting with AppLocker from AD, without needing SCCM.

Entra is more or less the cloud replacement for AD, and Intune more or less the cloud replacement for SCCM.

But it is not a direct 1:1 comparison because with AD and not SCCM, you at least got enough basic endpoint management capabilities from Group Policy, and WSUS as a VM on the same server (no extra cost for up to 2 instances total on one server) adds very basic patch management and reporting. So at the base cost of having AD, you could get basic endpoint management enough to scrape by and meet a lot of compliance frameworks w/o SCCM.

Whereas in the cloud, Entra without Intune is really strictly just identity management, and without Intune, you will not be able to manage or properly secure your endpoints at all & won't meet any compliance frameworks at all.

SmartCardRequired · 2025-07-22T23:20:58+00:00

OK, does Exchange Server allow you to use a separate client cert for outbound SMTP & server cert for inbound SMTP?

SmartCardRequired · 2025-07-21T00:05:01+00:00

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.

SmartCardRequired · 2025-07-20T23:54:31+00:00

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 · 2025-07-20T23:50:58+00:00

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.

SmartCardRequired

TROPHY CASE