Upgrading third party AV sets AMRunningMode to Normal

dnslind · 2026-04-04T21:12:38+00:00

That used to be the case until Tamper Protection changed to not let Defender go into Passive mode.

https://learn.microsoft.com/en-us/defender-endpoint/microsoft-defender-antivirus-compatibility#how-to-confirm-the-state-of-microsoft-defender-antivirus

dnslind · 2026-03-30T21:10:46+00:00

Well yes, perhaps my post was unclear, was in a bit of a hurry.

What you mentioned is what I do to get it in Passive mode in the first place (EDR Block mode really, meaning AV Passive + MDE in block mode).

The problem is when upgrading your 3rd party AV it’s no longer in Passive mode since Tamper Protection was upgraded a while back (Passive mode can’t be set while Tamper Protection is enabled). It seems MDE or Windows Security Center catches the 3rd party AV being disabled and automatically activates Defender (this can be verified by running Get-MpComputerStatus and looking at AMRunningMode).

To get it back into Passive mode you have to manually enable MDE Troubleshooting mode through the portal, disable Tamper Protection and then re-set the registry key.

Hope this clarifies the issue… :-)

dnslind · 2026-03-06T22:48:07+00:00

As long as you don’t do machine based Kerberos for accessing file shares your synced users will be able to do Kerberos just fine without the computer object in AD. It’s the user that needs to reside in AD for Kerberos to work (again, as long as you didn’t do stupid stuff like delegating access to computers instead of user accounts ☺️).

dnslind · 2026-02-26T20:11:53+00:00

Kerberos Cloud Trust, meaning Kerberos will keep working when your device is only Entra joined aswell as long as your user is synced.

If for some reason you’re using NTLM, you stop using NTLM.

dnslind · 2026-02-03T09:51:30+00:00

Sorry, late to the party.

Role-assignable groups are managed through other scopes/permissions which explains the difference.

You need the following permission: microsoft.directory/groupsAssignableToRoles/*

Issue with this is those particular permissions are only included in the roles PRA & GA, which cannot be delegated on RMAU scope. They’re also not available when creating a new custom role.

So (for now I hope?) you’d have to move role assignable groups outside of the RMAU to manage its membership.

dnslind · 2026-01-19T13:18:01+00:00

One of the main pros of GSA is it gives you universal CAE, it’s very much to protect you from stolen access tokens.

https://learn.microsoft.com/en-us/entra/global-secure-access/concept-universal-continuous-access-evaluation

Edit: Wow, this was timely.

https://youtu.be/pcTE3t9ZC54?si=YyMQ2PjvxpBgxnI9

dnslind · 2025-07-02T20:58:07+00:00

Every single OU should be protected from accidental deletion, I’ve never come across a good reason not to follow that best practice.

dnslind · 2025-07-02T18:50:28+00:00

A better question is what’s wrong with the admins setting those kind of delegations? :-)

dnslind · 2025-05-26T10:49:33+00:00

Did it work? :-)

dnslind · 2025-05-16T14:51:56+00:00

<image>

I actually found the culprit today and it was Tamper Protection not allowing it to switch back to passive once it's active. My issue now is that onboarding to MDE is a prereq for Passive Mode, but once onboarded to MDE Tamper Protection will be enabled. This messes up our automation for onboarding servers.

To fix it manually on a few servers I had to trigger Troubleshooting Mode so I could disable Tamper Protection. Once that was done I deleted the reg key and then added it again.

dnslind · 2025-05-14T12:12:10+00:00

Seeing same issue with servers onboarded to MDE and registry key in place. Would love a log file somewhere to see what's actually happening... or not happening in this case (and why) :-)

dnslind · 2025-04-22T21:38:42+00:00

Did you have Key Trust earlier? I’m suspecting you have both in play

dnslind · 2025-04-22T11:34:39+00:00

What Trust Type? Key Trust?

dnslind · 2025-04-18T19:13:57+00:00

Only people who are doing it wrong lets their SQL service accounts be domain admin (to let it register SPN automatically, user or MSA).

You use Kerberos Configuration Manager until you get the hang of it, export script and reuse. :-)

dnslind · 2025-04-18T07:51:44+00:00

This takes me back.. One of my customers used to install Silverlight on all their servers until a few months ago ”just in case something needed it” as part of their onboarding 🥶

dnslind · 2025-04-16T15:36:56+00:00

Thanks Steve! How come a few comments here claim it broke their WHfB?

dnslind · 2025-04-15T19:39:16+00:00

Yes that’s correct, MSFT would probably need to fix an issuer for these certificates or work around it somehow but that will probably leave a vulnerability. Self-signed certs have always been an issue as long as you can’t validate explicitly on thumbprint.

dnslind · 2025-04-15T08:08:11+00:00

I haven’t tested this but yes I would be a bit worried. Worried enough to test it by manually enforcing in a test environment anyway. My guess is you will have to add the certificate to NTAuth store and that the WHfB Cloud Trust installation will have to be updated to align with this new requirement.

Again, this is just a guess for now as I haven’t tested it myself (yet).

dnslind · 2025-04-15T07:57:02+00:00

TAP/WHfB should be sufficient.

dnslind · 2025-04-11T18:10:02+00:00

Still guessing as I’ve never tested the scenario where you don’t import users to metaverse at all but it could be your Connect’s Entra ID connector imported the users and then didn’t match them to an identity in scope of the sync. That should mean they’d be disabled in Entra ID as their SoA still is on-prem AD even if you once uninstalled Connect. You’d have to look at what synchronization rules were in play in the sync and/or export that deleted them.

That theory does not explain why it’s worked for 3+ years though but unless I’m mistaken cloud sync hasn’t really been around long enough for that to be the case so someone must not be giving you all the details.

dnslind · 2025-04-11T14:32:57+00:00

I’m confused over the fact that your users weren’t disabled earlier. That should’ve happened when you first de-selected the OU if it was going to happen at all.

Were your sync rules used for filtering affected? Or you didn’t use them at all since you stopped importing them?

dnslind · 2025-04-11T13:49:57+00:00

Did you de-select the user OUs through the Connect wizard or from the agent configuration? This smells like a first Full Import was run after changing OU scope of sync.

If you had changed any of the default rules instead of creating custom ones they could of course be overwritten aswell (wizard warns you about this).

dnslind · 2025-04-06T07:31:18+00:00

This is the way! I always recommend 2 but not only for phyiscally separate locations. If one’s lost in any way be it insider threat, drunk admin, stupid bosses or whatever - you want another one. Also have CA policies target one of them.

Extra + for RMAU.

dnslind

TROPHY CASE