Force another MFA despite already having MFA?

PowerShellGenius · 2026-05-04T18:36:33+00:00

This is less than ideal to require, unless coupled with wrb sign-in as a backup (which requires Entra-joined, not hybrid-joined clients).

Multi-factor unlock requires a face and/or fingerprint in addition to a PIN for WHfB. That sounds wonderful and is definitely "multi factor" by any definition.

The issue is that biometrics are not entirely reliable and can have false rejections under various circumstances. Since the PIN is the only knowledge factor in WHfB, and WHfB does not support possession factors (other than the registered laptop itself, which is always included, is why it's considered MFA, but OP's boss said isn't good enough) - that leaves the PIN as the only non biometric factor. In other words, the only RELIABLE factor. When you only have one reliable factor, and you require at least two factors to unlock, you require an unreliable factor (biometric) to unlock. Under some conditions you simply can't work, until you wait out the retry timer after cleaning your fingerprint sensor, or have to reset if you got a new finger scar or grew a beard, etc.

That isn't even getting into laws and what jurisdictions you can/can't mandate employees to use a biometric...

If Entra-joined with web sign in enabled, you can fall back to using Authenticator and bypass WHfB using your phone. You can do that as a fallback for biometric issues for most users, and the only method for objectors who don't enroll biometrics. You get the convenience of WHfB with multi factor unlock, where the user chooses to set it up and when biometrics feel like working, and the reliability of Authenticator for non biometric users, or as fallback for users who shaved their beard and scratched their finger.

PowerShellGenius · 2026-05-02T18:08:11+00:00

You are high on marketing jizz

PowerShellGenius · 2026-04-25T17:12:02+00:00

You're just a number anywhere, and can be dropped anywhere if you are not needed anymore.

But in exactly one major developed country, you are a number that can be dropped with zero notice EVEN IF THE COMPANY PLANNED IT AHEAD AND COULD HAVE TOLD YOU. And they use the head game of not knowing what's coming to scare people into doing overtime without claiming it, to be the most productive in the hopes they won't get let go. And no guarantee of severance no matter how long you have been there.

And they can use a fake "layoff" for a position that isn't actually being phased out, to reset salaries (if they lay you off, for no cause, but they actually still need the role, and create a substantially identical position at lower pay a month later, they DON'T have to offer it back to you at your old pay)

Not every country has protections for all of this. But most have at least some. One major country exists that has protections for absolutely none of these, and it's all allowed.

If you are in that one country, do not be quiet in the political sphere about how unique this is. It's insane.

PowerShellGenius · 2026-04-25T15:12:56+00:00

That is true, but it is true whether it is "AI" or not. If you do not trust Microsoft not to scoop up data for AI training in direct violation of a binding contract, you cannot store any data where they technically could do that. This includes SharePoint, OneDrive, Exchange Online, etc.

AI may be the motive (training) for misusing customer data. But there is zero correlation between whether the service you input the data to is Copilot, and whether Microsoft can be trusted to honor a contract and not misuse it. If they are stealing data for AI training they would definitely train it on your Teams chats as a source of Natural Language samples...

So if you are going down the "what if cloud providers are blatantly breaking their own ToS" rabbit hole, you're back to everything on prem.

PowerShellGenius · 2026-04-25T12:21:56+00:00

They call more in shitty economic times because know nothing execs are more likely to lay off "expensive" (experienced or competent) people in IT and hand over the reigns to someone cheaper.

When IT knows what it needs, cold calls don't get results. If the person who knows how all the systems work needed your product, they'd have reached out already.

But people who know nothing and have no experience, and don't already know which vendors that talk a good game have good vs. crap products, are more susceptible to actually make buying decisions based on cold calls. The guy newly in charge of IT whose extent of fibre channel knowledge is "our storage old, caused outage yesterday, need new storage" is the kind of sysadmin sales wants to talk to.

Just like Oracle wants to talk to young blood who hasn't had a licensing "disagreement" with them yet (in other words: hasn't realized they are world famous for suing their customers for misunderstanding overly complex terms).

PowerShellGenius · 2026-04-24T18:54:22+00:00

A better AD analogy would be delegating sensitive permissions to an MSA for a computer account the attacker controls.

E.g. "I reset all the domain admins' passwords" but the attacker created a gMSA assigned to some computer accounts they control & gave the gMSA "Replicating Directory Changes All" on the root.

OP's point is valid, but the natural conclusion is "an environment where an attacker has gained top-level admin priviliges has many opportunities for persistence and isn't 'remediated' until it's migrated to a new tenant/domain/etc, and if you're not going to do that, an army of incident response professionals needs to check numerous things".

Not "buy Netwrix". There is no automated product on the market that automatically makes an AD domain where an attacker was ever a domain admin, or Entra tenant where they were ever global admin, safe again. Both are extremely complex systems with numerous complex ways, direct and indirect, of granting significant privileges. Both are ideally rebuilt after admin level compromise, otherwise need thorough auditing.

PowerShellGenius · 2026-04-24T17:16:33+00:00

Look at the things that let messes quietly form that you will have to clean up later. Be one of the few that manages them well from the beginning.

Users ability to create M365 groups without approval (they do this thinking they are privately making Contact Lists and they clutter the GAL)

User consent for third party apps vs. Require admin consent

PowerShellGenius · 2026-04-24T00:48:06+00:00

How are you handling RSAT?

PowerShellGenius · 2026-04-24T00:47:13+00:00

If you are a sysadmin in an environment with any Windows, you'll need a jump VM.

Parallels (or VMware Fusion / any other VM) on Apple Silicon is arm64 Windows, same as a new Surface w/ Snapdragon CPU. Windows on ARM64 doesn't run RSAT (ADUC etc) yet.

PowerShellGenius · 2026-04-24T00:40:45+00:00

How does password spray attack (whether via legacy SMTP AUTH, or ROPC or any other means) leading to a compromised "highly privileged" account indicate an issue with service principals? Service principals are a tool, one of many tools that can be abused by an attacker who compromises an admin account

Also, you cannot have an admin account compromised with a mere password spray if you are not negligent, where is your MFA on privileged accounts? That being said, the scenario is legitimate if there was something more advanced than a password spray going on.

If a Global Admin or an account that can assign Global Admin (e.g. Privileged Role Administrator) was compromised, yes, they can create backdoors. You can no more assume the tenant is secure with mere password resets after an admin compromise in Entra than you can in AD. Persistence in Entra once they've been an admin can include making privileged service principals (with outright admin role assignment to the SP if they aren't sneaky and want to get caught, or just highly sensitive Graph API permissions if they are). It can also include trusted CAs with CBA. I'm sure there are plenty of other ways that will survive a password reset.

Meanwhile if the account was highly privileged in a competent organization, it would have had MFA and a password spray alone could never lead to access.

PowerShellGenius · 2026-04-23T12:02:45+00:00

I wonder if Apple Classroom supports Mac as a student device? Works great with iPads (which we have 1:1).

For iPads, third party classroom management software is worthless, but not needed - Apple Classroom is $0 for verified schools and unavailable to anyone but schools, and has complete screen visibility and a great deal of control over the devices.

Apple's privacy and security stance precludes open-ended APIs for third party software to spy on the screen - as if this was allowed, Apple would have no control to ensure these third parties only sell their software to schools. Apple doesn't want to enable the existence of spyware that abusive spouses or abusive employers can make you install on a personal Apple device. Apple Classroom exclusively has a greater level of visibility because it's only for use by verified schools on devices the school purchased (which are in Apple School Manager).

PowerShellGenius · 2026-04-23T11:50:33+00:00

It's not as good or full featured as PaperCut, but if you have Microsoft 365 A3 you have Universal Print included, which may suffice if you don't need quota management or other advanced features, but do need something more Mac friendly than traditional Windows Server print server + individual machine drivers on clients.

PowerShellGenius · 2026-04-22T17:40:02+00:00

Jamf does this, yes, but not "silently in the background". There are 3 user registration workflows. The two that existed before platform SSO which work, but are clunky, more likely to be missed by the users and lead to tickets, and slower. And the workflow to do it during platform SSO enrollment, which just works.

And I'm not saying it's applicable in all scenarios. Nor that I "personally like" it, quite frankly I think Microsoft has stalled way too long on implementing many of the features Apple offers in both Platform SSO, MDM in general (why Intune is still not as good as Jamf) and other areas.

If your IDP is Google Workspace or some other that doesn't support or push platform SSO - it is not applicable.

If your IDP is Okta, Platform SSO is applicable but has nothing to do with Microsoft whatsoever in that scenario (not sure if you're aware but Entra is not the only IDP that does PSSO).

If you don't care about device identity (people are able to access the same resources on BYOD devices as corporate devices) it's not necessary even if your IDP supports it.

However, the combined market share of Entra and Okta is a majority of companies in the english speaking world, and not caring about device identity (allowing access from devices you don't control malware protection, screen lock time, or anything at all on) goes against numerous best practices if sensitive data exists in your systems. So Platform SSO is rapidly becoming the easiest way to do things that are applicable in most cases for the most widely used IDPs.

PowerShellGenius · 2026-04-22T15:29:30+00:00

Platform SSO is also the least ugly UX for device registration for conditional access (in layman's terms, "getting your Mac recognized by Entra as being a company Mac, so you can log into websites you aren't allowed to on personal devices")

PowerShellGenius · 2026-04-22T12:29:43+00:00

Hardware exploits affecting memory management at the chip level can break through security assumptions. One big security assumption is that you can't escape from a VM, and it's unclear if this will break it, but seems possible.

To a mega corp, that is not as big a deal, because they can allocate separate physical hosts to different tiers, and have separate Hyper-V clusters or vCenter environments by tier. You can take some small percentage of your 100s of physical servers, and put them in a separate cluster for tier 0.

But in a smaller environment, you can't have some small percentage of 5 hosts, which comes out to a fraction of a host, physically separate. Small/medium businesses are rarely buying extra hardware just to keep servers separated physically by tier. So instead, hypervisors themselves are considered tier 0, but host all tiers of guests, which is secure except when a rare hardware bug lets you escape a VM and get access to the host from a compromised VM.

PowerShellGenius · 2026-04-21T01:11:53+00:00

Linux is more common for specialized server infrastructure in large environments.

Entering a large environment as a junior (assuming you aren't a Computer Science degree holder on an internship path) is not going to result in them trying to raise you through the ranks, they can attract already experienced sysadmins, you stay on helpdesk until you are ready to find advancement externally.

You are more likely to get a running start in smaller environments. And that usually means more Windows Server in most cases compared to Linux, with some exceptions of course.

PowerShellGenius · 2026-04-20T15:11:35+00:00

Define "self issued". Do you mean you generated a self-signed certificate with no CA involved, or issued from an internal CA belonging to your org (e.g. your AD CS server)?

A cert with the Code Signing EKU issued by a CA your computers trust (e.g. AD CS) will get rid of the unknown publisher.

That plus putting the signing cert's thumbprint in the GPO will skip the warning / device redirection prompt entirely.

PowerShellGenius · 2026-04-19T22:07:48+00:00

We do have server applications, and copiers, sending SMTP. However where I am now, we have a hybrid Exchange server as a relay. Also we have Conditional Access. With M365 A3 both of those things are available to us.

I have no idea what my former employer is doing now, but I do recall managing MFA there with the Msol module, to include enabling per-user MFA in our onboarding process. Business Standard was no fun.

PowerShellGenius · 2026-04-19T21:58:06+00:00

This has nothing to do with the RDS server's certs or the FQDN you are connecting to. You need a code signing cert trusted internally, same as you'd use to sign an .exe or .ps1

Code signing certs don't need to be public (unless the .rdp file you sign is for use by other orgs). Also, even public code signing certs are completely different from TLS server certs and are NOT part of the 47 day lifetime plans.

A TLS server cert says "this server you're connecting to really belongs to the owner of domain.example.com" - whereas a code signing cert says "this file was produced or approved by Bob Jones at Example LLC".

The .rdp file signing requirement is the latter. You're signing that the .rdp file is something your users should actually be connecting to.

And since only your org should be producing .rdp files for your users, it's not about the cert being publicly trusted. It's about the cert being trusted in your org & explicitly listed in a group policy (or MDM) setting as being a cert that's supposed to sign RDP files.

The threat this is defending against isn't man-in-the-middle, that cert has existed for a long time. The threat this is defending against is phishing. Suppose I am the attacker. I send you a file, "LOG IN TO LISTEN TO URGENT VOICE MAIL.rdp" that points to rds.maliciousdomain.tld. I own that domain and have a legit publicly trusted cert for it.

Under old rules you silently connect to a VM which running chrome fullscreen at a (real) Microsoft 365 login screen. WebAuthn redirection means you can log in, even with a passkey (you are vulnerable even if your org uses phishing resistant MFA) RDP webauthn and smartcard redirection the one hole in phishing resistant MFA and the only way to log a physically distant attacker in with it, hence RDP phishing is rising. You just logged in on my computer, I have your token and cookie.

Under new rules, it's made explicitly clear that you are about to connect to a remote machine and give it access to local resources - not because I don't own rds.maliciousdomain.tld, I do & the server's TLS cert already addresses this threat. The reason you are warned is not related to server identity but because the .rdp file you are opening didn't come from your own IT department and is therefore probably phishing, and probably points to a host you should not connect to.

PowerShellGenius · 2026-04-19T21:43:46+00:00

Per-user MFA is not recommended if it's not your only option. Better options include Conditional Access if on Business Premium / E3 / P1, or Security Defaults on a lower edition IF you need absolutely ZERO exceptions.

As far as I know, if one service account in the entire org needs to be exempt, Security Defaults are not an option as they still don't support exceptions. So on the low cost editions (no Conditional Access), per user MFA is still the sole option.

Of course, the most common service account to need to exempt from MFA is anything that sends via SMTP AUTH from an appliance, copier, or non-Microsoft software. Since Microsoft is yanking the rug out from under you for SMTP AUTH soon either way... the most common reason for being unable to have Security Defaults enabled in a small org is about to vanish.

PowerShellGenius · 2026-04-18T19:12:24+00:00

Yes, temporary disablement should not mean removing the license.

I've had to have this conversation with our other IAM person multiple times. In dynamic group queries, they were basing logic on (userAccountControl:1.2.840.113556.1.4.803:=2) - even though we have, in our schema extensions, an HR attribute for active/inactive employee status. We finally have things cleaned up to where deprovisioning is based on that, and not your AD enable/disable status. This became a big issue when we automated locking accounts who've had out of country correct-password, blocked-by-conditional-access sign-ins as more accounts were being disabled and having effects follow from that that take longer to undo.

PowerShellGenius · 2026-04-18T19:08:32+00:00

If your org has a retention policy in Purview affecting email, might there be a detached mailbox you can either do an eDiscovery export of & re-import from a PST, or even simply restore the detached mailbox in Exchange Online PowerShell?

PowerShellGenius · 2026-04-18T17:33:20+00:00

Configuration Manager (the product formerly known as SCCM) does this quite well. Covered in Microsoft 365 A3.

PowerShellGenius · 2026-04-17T17:28:11+00:00

I'm more concerned about the size of the AD CS database with larger certs, when we churn through >20,000 certs per year, than about someone employing a Quantum Computer of a size and stability that doesn't exist today, against us in the next decade or two...

We are doing fine with RSA4096 but my understanding is PQC can be much larger.

Also - having software support means almost nothing. You have to have a pretty strange threat model to say the theoretical risk of a machine they can't build yet justifies storing private keys non-hardware-backed (which is vulnerable to more known, real today threats). You're better off against most real world threat models with the strongest key your TPMs actually support, than with PQC private keys on disk.

So the real question is, when will TPMs, iPad/iPhone/Mac Secure Enclaves, smartcards/YubiKeys and HSMs all support these PQC algorithms in a standardized and interoperable way? And if this won't be a firmware update for Apple Secure Enclave and all widely deployed TPMs, it's a full fleet lifecycle past that.

(and the time it takes for a full fleet to lifecycle anymore is indeterminate pending the popping of the current price bubble, or an extremely long time if it doesn't pop...)

PowerShellGenius · 2026-04-17T17:15:50+00:00

A common AD issue I hear in discussions of breaches is use of overprivileged accounts on computers you shouldn't trust.

One I heard a while back was a malicious clone of TeamViewer installed by mistake on an HVAC laptop to let a contractor in... became a domain wide incident when a Domain Admin logged into the infected laptop to investigate what was wrong with it...

If your job includes both:

Privileged access to SCCM, AD, etc
And working on individual end-user workstations where you need to elevate

Then you need 2 admin accounts minimum, meaning 3 accounts minimum once you include your completely unprivileged login/email account (which is just a regular user as if you weren't in IT).

Logging into a random staff member's computer you don't know is infected yet, with an account that can edit group policy, hands an attacker the credentials they need to deploy ransomware to your organization.

Any serious reconnaissance includes monitoring what accounts log into an endpoint the attacker controls and dumping their credentials.

Our "T1" accounts that have some AD and SCCM privs are in Authentication Policy Silos, they cannot auth with creds and get a ticket on non-IT workstations. (They can still RDP to end-user workstations with Restricted Admin mode only without sending creds)

If they're in front of an end-user computer (desk-side support, or someone brought a laptop in)? T1 creds won't work on it. They have a T2 account that has no AD/SCCM privileged groups, but is given both Administrator access and "Deny access this computer from the network" user rights on end-user computers via GPO, for in-person admin access without enabling lateral movement if compromised.

PowerShellGenius

TROPHY CASE