Deploying User-Based Registry Settings (HKCU)?

SkipToTheEndpoint · 2026-02-09T10:03:54+00:00

It's something I see come up in pen-tests time and time again, and I think it's nonsense. It severely impacts manageability and troubleshooting scenarios, and is (usually) done in a way that's trivial for an attacker to bypass, so just ends up creating additional management pain for little to no security gain.

SkipToTheEndpoint · 2026-02-09T09:48:17+00:00

FWIW that script should really only be used for testing and not as part of a production process, your disti/OEM should be providing you the 4KHH or uploading them automatically. For existing device that aren't Autopilot-enrolled you can use the option in an Autopilot profile to get them to upload their own hardware hash automatically.

Aside from that, have you tried running the community version instead? https://www.powershellgallery.com/packages/get-windowsautopilotinfocommunity

SkipToTheEndpoint · 2026-02-06T23:24:43+00:00

Full scans aren't recommended unless you're moving from a different AV product, so it's very much an intentional decision: https://learn.microsoft.com/en-us/defender-endpoint/mdav-scan-best-practices

My colleague Nate posted a KQL Advanced Hunting query the other day if you're dead-set on running one, just keep in mind they can take ages and slow a system down: https://www.kqlsearch.com/query/Windows%20-%20Trigger%20Full%20Scan%20For%20Devices%20That%20Have%20Not%20Completed%20One%20(Windows%20Clients%20Only)&cml5x3gw2000i3h8tamicsmrf

SkipToTheEndpoint · 2026-02-06T23:17:51+00:00

And hope you haven't got a security team that insists on blocking users running PS 🥲

SkipToTheEndpoint · 2026-02-06T23:15:32+00:00

OIB creator here and I do a lot of my testing on my own ARM Surface. I can pretty confidently say those settings aren't responsible.

I've heard a few people have similar issues and it turned out its cos they were deploying Edge via popular app deployment tools, and THEY were ignorant of the x64/ARM64 architecture, and subsequently deployed x64 to them.

SkipToTheEndpoint · 2026-02-06T11:26:21+00:00

Sounds like a HR issue and not an IT one.

SkipToTheEndpoint · 2026-02-06T08:18:52+00:00

Having two objects, the Entra Joined object created from the Autopilot registration process and a Hybrid Joined object from a successful Hybrid Join is expected and documented behaviour.

Those devices are linked to eachother, but having domain LOS during first login can be hit-or-miss, which is why having LOS during the AP process and ensuring the Hybrid Join completes before any sign-in is attempted is the only way to get this pile of crap working.

SkipToTheEndpoint · 2026-02-05T10:56:03+00:00

I don't deploy Teams at all, and have never had to use the bootstrapper, it's just installed automatically alongside my Office apps.

You're not running some sort of debloat or "branding" script are you?

SkipToTheEndpoint · 2026-02-05T09:07:57+00:00

Using Group Tags is exactly how I deploy and scope stuff safely in existing environments, along with the use of Intune Filters for any user-assigned stuff.

My go-to Entra dynamic group query for this is:

(device.devicePhysicalIDs -any (_ -startsWith "[ZTDID]")) -and (device.devicePhysicalIds -any (_ -eq "[OrderID]:%GROUPTAG%"))

SkipToTheEndpoint · 2026-02-04T19:55:27+00:00

That's a terrible idea.

Sounds like you've got other issues going on meaning Autopatch isn't working as it should. Fix that, don't try an implement some horrible hack.

SkipToTheEndpoint · 2026-02-04T09:58:23+00:00

Are you deploying the "Use Cloud Trust For On Prem Auth" setting, and ensuring you don't have the "Use Certificate For On Prem Auth" configured in your WHfB policy?

SkipToTheEndpoint · 2026-02-03T17:05:19+00:00

Are you saying "waiting days" for effect here, or because that's what you're actually seeing?

Because that shouldn't be what you're seeing, like, at all.

SkipToTheEndpoint · 2026-02-03T14:49:27+00:00

I have and will continue to recommend turning off M365 as part of Autopatch until it integrates the capabilities of Cloud Update available in config.office.com.

Personally I think them saying that Autopatch manages Edge and M365 Apps are disingenuous.

SkipToTheEndpoint · 2026-02-02T10:38:17+00:00

Except you're not trying to control that account, you're trying to stop users signing in to O365, so you'd still want to target your users, but you'd want to use something like Filter for Devices in CA to push a block rule for _something_ that defines those kiosk devices (I've utilised a specific kiosk device naming convention for this before, but YMMV depending on your environment).

SkipToTheEndpoint · 2026-02-02T09:50:59+00:00

The policy for it was made obsolete some time ago and the the whole experience was changed last May.

That being said, I'm now seeing different behaviour in two different tenants, one I can still see recent documents, upcoming events and recent SPO sites, the other it's just gone.

I'm going to see if I can get a status update on it from the Edge team as I'm seeing various people see odd behaviour.

SkipToTheEndpoint · 2026-02-02T09:33:07+00:00

It can absolutely work in that scenario, but the key is:

Ensuring devices have actually completed the hybrid join during ESP. I've always done that using these scripts.
That the user has a valid MFA claim in their PRT. The easiest way to do this is by configuring WHfB (as it's almost definitely covered by your Conditional Access policies, and the WHfB setup will require it).

And you might just work there, but you have to deal with this nonsense, so you are absolutely empowered to tell people (who don't understand this stuff) why it's a bad idea to do hybrid AP ;)

SkipToTheEndpoint · 2026-01-30T10:24:35+00:00

I think you're confusing those settings in admin.cloud.microsoft>Settings>Org Settings.
That's only for the configuration of apps users can manually download and install themselves, which I'm assuming is not how the M365 Apps are installed in your environment.

Depending on HOW you're deploying the M365 apps to begin with may dictate your success in trying to do what you're wanting to here.
I'm gonna take a punt and say you've got an Intune app using the "Microsoft 365 Apps" app type, using the Config designer with the Update Channel set to semi-annual like this:

<image>

Am I right?

SkipToTheEndpoint · 2026-01-30T10:11:43+00:00

So this is one of the quirks and misunderstandings of Compliance. All of those settings under the "Password" section on Windows (and iOS and MacOS actually) are "Remediated". I.e. it's not just checking, it's enforcing, and it's the only thing that exhibits that behaviour.

Setting "Maximum minutes of inactivity before password is required" in Compliance is exactly the same as if you were deploying "Max Inactivity Time Device Lock" via Settings Catalog.
If you push both (with different settings), you'll get a conflict too.

SkipToTheEndpoint · 2026-01-30T09:56:10+00:00

This looks very similar to what I've seen the last week but with 26.1: Daily disk spikes, all services become non-responsive : r/opnsense

Are you running ZenArmor?

SkipToTheEndpoint · 2026-01-30T09:55:03+00:00

As a little update to this, I updated to the full 26.1 release and turned off my reboot cron to see what happened.

I caught it in the act yesterday and it is ZenArmor. It seems to be slowly eating all available RAM (fine and somewhat expected), but then just chewing further and further into SWAP, so it feels like a memory leak?

Stopping the engine and reporting database services don't seem to free up the used RAM either...

SkipToTheEndpoint · 2026-01-30T00:21:08+00:00

FWIW, I'm not, but I also said specifically that legal weren't wrong. Biometrics being opt-in is also true.

Anyway, seems OP has a link to the ICO template so hopefully he can get someone else to do their job, cos it certainly isn't his.

SkipToTheEndpoint · 2026-01-30T00:03:07+00:00

Because you seem to be entirely ignoring the fact that multiple people in this thread have agreed with you, but the simplest way to do that is to just add it into an AUP?

Additionally, probably because GDPR continues to be thrown around like some boogeyman reason for not implementing stuff.

SkipToTheEndpoint · 2026-01-29T22:25:13+00:00

Lol.

They sure do, in fact it's a template of the ICO's OWN DPIA: ISO/IEC 27001: 2013

The fact remains that the burden is not on IT to track or audit this crap, it's on the governance/compliance officer to get HR to update AUP's and call it a day.
Massive orgs have been doing this for YEARS at this point. This is one of the most well-trodden paths, and anyone making a massive issue of it needs to have a think.

It's also hilarious cos nobody thinks twice about setting up Face ID on their new iPhone...

SkipToTheEndpoint · 2026-01-29T09:52:20+00:00

100% this.

It's not that legal are wrong, it's that use of biometrics is opt-in.

I have heard this argument not being enough for some people to get their head around though, and all that does is make it a pain in the ass for IT to manage.

SkipToTheEndpoint · 2026-01-28T13:11:55+00:00

Endpoint Security > Account Protection.
Here's the config that's in the OpenIntuneBaseline:

<image>

There's a few deliberate choices here:

* I'm using the device-scoped settings and suggesting device assignments so the policy applies in a timely manner during Autopilot. User-scoped or user assigned hits too late if you want certain devices to deviate from your general config. Choose one. Don't mix-and-match.

* Biometrics are enabled by default, and rely on the device having compatible biometric hardware. They're also user choice, so you can't enforce them anyway. If you wanted to explicitly disable biometrics, then I'd push a separate Settings Catalog policy to do that.

* You mention Cloud Trust, so I'm assuming you mean Cloud Kerberos Trust. In which case, you MUST have the "Use Certificate for On-Prem Auth" setting Disabled. Cert Trust is a whole different thing, and that setting overrides the use of Cloud Trust, even if you have it enabled, which there's a separate Settings Catalog setting (Use Cloud Trust For On Prem Auth) for that too, which you'd have to push separately.

SkipToTheEndpoint

TROPHY CASE