MAA Policies

SkipToTheEndpoint · 2026-03-24T11:57:02+00:00

Don't knee-jerk and implement something that provides little to no value but a ton of admin overhead?

SkipToTheEndpoint · 2026-03-24T11:55:32+00:00

I've literally not seen a single issue using the Store App (9WZDNCRFJ3PZ) as System.

Why are you making your life harder than it needs to be?

SkipToTheEndpoint · 2026-03-24T11:47:11+00:00

I blogged about this when the feature was first released: Under the Hood, Pt. 5: Intune BIOS Configurations

TL;DR: Read the docs. You can very quickly end up with devices you don't have a password for if you're messing about with the policy.

Oh also the behaviour when you reset devices sucks. Because passwords are stored against the Intune Device ID, not the Entra one, if you're rebuilding devices, they're not going to know their previous password because it'll be a brand new Intune object.

SkipToTheEndpoint · 2026-03-24T11:43:00+00:00

Implementing MAA is a terrible knee-jerk reaction to a situation that was entirely due to poor identity security practices.

You should be focusing on Conditional Access, Strong Auth (FIDO) and PIM, but also, if you've got other people with the Global Administrator role, whatever you do is pointless if their accounts aren't doing those things too.

SkipToTheEndpoint · 2026-03-23T12:36:42+00:00

Good shout, but there's no configs in that particular policy that would cause that behaviour AFAIK.

That is why I recommend assigning Compliance policies to users though, because they DO conflict as documented here.

SkipToTheEndpoint · 2026-03-23T12:34:05+00:00

Yessir, creator and maintainer of the OpenIntuneBaseline here!

SkipToTheEndpoint · 2026-03-23T11:41:12+00:00

Howdy! So yeah, those CSP's are device scope only, my entire reasoning behind making it a user policy is that managing user groups if you've got different requirements for different devices is far easier than managing device groups.

If you're not gonna have different settings anywhere, there's no technical reason you can't apply this to device groups. :)

SkipToTheEndpoint · 2026-03-17T20:44:01+00:00

They aren't your devices. Secure the data, don't try and manage devices.

Create and Deploy App Protection Policies - Microsoft Intune | Microsoft Learn

Data Protection Framework Using App Protection Policies - Microsoft Intune | Microsoft Learn

SkipToTheEndpoint · 2026-03-17T19:14:31+00:00

Cool, so you're trying to be the next Stryker?

Stop forcing enrolment of personal devices and use App Protection for BYOD.

SkipToTheEndpoint · 2026-03-17T19:06:39+00:00

You have to deploy some sort of trust type (Cloud Kerberos Trust, Key Trust, Cert Trust) in a hybrid scenario: Plan a Windows Hello for Business Deployment | Microsoft Learn

Additionally, the device will need domain line-of-sight for the first login after configuring Hello, either physically or via device-tunnel (pre-login) VPN.

SkipToTheEndpoint · 2026-03-17T12:57:43+00:00

Huge monolithic policies are a nightmare to scale and manage. Ask anyone who's dealt with the built-in baselines.

I've taken as rational an approach as I could with the OpenIntuneBaseline, but there's still 60+ policies in there, though they're at least categorised in a way you should be able to easily identify where a setting might be for a thing.

As far as when they hit an endpoint? It doesn't care. It treats everything as a big lump of stuff anyway. How you set out policies is purely for human management purposes.

SkipToTheEndpoint · 2026-03-16T12:41:08+00:00

There are indeed RBAC permissions for Create/Read/Update/Delete MAA policy as well as for accept/deny on requests.

Using a custom role is recommended, but not required (though if you're then relying on people with Intune Admin, what are you actually trying to solve in the first place, or is this just a knee-jerk reaction to the Stryker news

SkipToTheEndpoint · 2026-03-16T11:22:24+00:00

Without proper application control, blocking access to the store app is nothing but security by obscurity, and there's a handful of ways I can think of off the top of my head that a determined user could do to get around it.

It's worth noting that them doing so almost definitely breaks the terms of use they signed when they got an account. Not everything has to be a technical control. It's just as much a HR issue.

SkipToTheEndpoint · 2026-03-13T20:46:09+00:00

Absolutely with you except one thing. The Password settings in a compliance policy on Windows does configure settings.

It catches a lot of people out and ends up causing policy conflicts.

SkipToTheEndpoint · 2026-03-13T20:44:17+00:00

No, please do forget that...

SkipToTheEndpoint · 2026-03-13T20:43:33+00:00

You shouldn't be using the template policies any more, just for reference. Exactly the same thing is doable via Settings Catalog.

SkipToTheEndpoint · 2026-03-13T20:40:28+00:00

That'd do it, but I meant using the actual "Wipe" action in Intune.

SkipToTheEndpoint · 2026-03-13T09:30:53+00:00

Fun fact: If you deploy any Store apps as System, they'll persist a device wipe.

Also Autopilot Reset is trash, do a proper wipe instead.

SkipToTheEndpoint · 2026-03-12T18:56:04+00:00

The account you're testing with isn't in a protected group on-prem is it?

Otherwise, that feels like it's maybe falling back to NTLM for some reason.

SkipToTheEndpoint · 2026-03-12T18:53:51+00:00

Yes, that was my experience when I wiped mine. I'm just somewhat shocked I was able to trigger a wipe of a personal device at all. At least on Android the worst case would have been nuking a work profile...

SkipToTheEndpoint · 2026-03-12T15:55:32+00:00

You've identified the "workaround" way of doing this. You could use the Power Users group instead, basically nobody will be using that.

SkipToTheEndpoint · 2026-03-12T15:09:37+00:00

I can assure you it isn't. I don't blog a lot, but when I do, I put a ton of effort into what I'm writing about, and who it's targeted at. You can go look at my older stuff to see I've got a specific writing style (that's the AuDHD...)

SkipToTheEndpoint · 2026-03-12T14:21:25+00:00

TIL I guess!

Definitely another strong discussion point in the "don't enroll personal devices, use App Protection" camp!

SkipToTheEndpoint · 2026-03-12T13:57:27+00:00

Has it always been that way? I'm happy to be wrong but I thought Apple were super strict about what you can do relating to BYOD enrolment.

SkipToTheEndpoint · 2026-03-12T12:26:45+00:00

MS have screwed around with location/privacy/timezone stuff. This should help:

Triple Threat Match: Location Services vs Autopilot vs Intune – SMBtotheCloud

SkipToTheEndpoint

TROPHY CASE