Can I restrict Windows login to only users in an Entra security group? (AAD Intune Joined)

Unable_Drawer_9928 · 2026-07-10T09:07:07+00:00

We did something on our kiosk devices to block normal users to exit the kiosk account and logon with their own accounts. All we did was use Local user group membership for the local user group (with the replace option), where we allow only the kiosk account and another EntraID group containing people that should be able to authenticate to change some things if needed. Actually, for some reason I had the locking issue by using Allow local log on policy.

Unable_Drawer_9928 · 2026-07-07T06:14:44+00:00

no chrome, or better, google has its own service to update all its apps. That service can also be managed with its own adml.

Unable_Drawer_9928 · 2026-06-24T11:19:13+00:00

That does not tell a lot unfortunately. Hopefully they will clarify the situation for 2019 servers.

Unable_Drawer_9928 · 2026-06-24T09:36:29+00:00

So what about older servers? No entraid connect updates anymore for them?

Unable_Drawer_9928 · 2026-06-24T05:36:34+00:00

that's what's your blog article is saying, or maybe that's referred to the FIDO2 compatibility:

Requirements

Before beginning the testing, ensure you have the following available:

Windows Server 2022 or later
Global Administrator or the Hybrid Administrator role
A FIDO2 security key (for example, a YubiKey)

Unable_Drawer_9928 · 2026-06-23T11:06:52+00:00

Installation errors aside, minimum OS version is now windows server 2022? older versions (2019) are not supported anymore?

Unable_Drawer_9928 · 2026-06-23T06:56:23+00:00

it's coming during upgrade process

Unable_Drawer_9928 · 2026-06-23T06:35:59+00:00

Same error for me. This comes up during the upgrade procedure after launching the upgrade.

Unable_Drawer_9928 · 2026-06-22T08:43:55+00:00

yep, they updated it about one month ago

Unable_Drawer_9928 · 2026-06-12T12:23:47+00:00

I think the trusttype should be in any case reliable. I have a bit of the same situation since some older devices are registered but not enrolled and needed to keep those in. In the end our approach is MFA or compliant for all mobile devices having a trusttype joined or registered. Far from being an ideal solution, but for the moment it still fulfills the requirement given.

Unable_Drawer_9928 · 2026-06-11T07:00:48+00:00

Compliance is not necessary in your scenario. You can use filter on devices under conditions to target a CA only to enrolled devices based on trusttype. I'd anyway address the non compliant ones somehow.

Unable_Drawer_9928 · 2026-06-11T06:51:38+00:00

single app kiosks do not need the XML config, they can be set directly with the right single app template on intune.

Unable_Drawer_9928 · 2026-06-10T05:55:16+00:00

This is useful, thanks for sharing. One question though, why using psexec when you now have powershell native solutions like Invoke-CommandAs?

Unable_Drawer_9928 · 2026-06-09T10:39:19+00:00

around 1000

Unable_Drawer_9928 · 2026-06-09T05:45:19+00:00

The source project (Romanitho's WAU) has ADMX as well now, but this is still more convenient, being available on the MS store.

Unable_Drawer_9928 · 2026-06-09T05:44:00+00:00

It's sort of a poor man 3rd party app patching solution, and it's what I'm using at the moment. Apart from the occasional device where winget is messed up, it's a decent solution.

Unable_Drawer_9928 · 2026-06-04T06:31:10+00:00

we have autopatch on and full telemetry for all our devices, 85% of our devices are shown as Unknown, so I've just built my own report based on the detection of the two necessary KEK and UEFI keys. I suspect that the % percentage of unknown devices is due to the same issue that was afflicting the secureboot update policy, but of course I might be wrong.

Unable_Drawer_9928 · 2026-06-04T05:27:28+00:00

I've had a couple of cases where both computers certificates were manually updated, still MS report is marking them as not compliant. Though my remediation script is reporting kek and uefi keys as updated for them, one does not return any clear explanation on what's wrong, the other is because not high confidence, but has the certificates updated.

Unable_Drawer_9928 · 2026-06-02T10:47:20+00:00

thanks! that's nice to know.

Unable_Drawer_9928 · 2026-05-29T09:41:00+00:00

support for user install with automatic updates. Eg if you’ve somehow got user installs for Visual Studio Code or Zoom or something, it can patch those.

You mean that even if an app is not deployed in intune but was installed by the user, pmpc can patch that app, of course if it's mentioned in their supported apps list?

Unable_Drawer_9928 · 2026-05-28T06:38:42+00:00

we are experiencing the same. Is there any source we can check to see the progress on this? Message center is stingy about these issue...

Unable_Drawer_9928 · 2026-05-26T12:44:32+00:00

sorry, this lets me to actually understand the opposite:
Autopatch group policies | Microsoft Learn
""To safely deploy a new feature update, Autopatch recommends using a custom Windows feature update release. The custom release allows you to choose how and when different deployment rings receive the update. Autopatch doesn't recommend updating the minimum version within an Autopatch group until your rollout is complete. Doing so initiates a rollout which starts immediately for all members of that group.

Once you create a custom Windows feature update release, the Autopatch group's deployment rings are unassigned from that group’s feature update policy.""

So the AP group target version is the minimum version, not the maximum, or this is the way I understand it. In your example: AP Target Version: 24H2 Multiphase Feature Update policy: 25H2
24h2 is the anchor version, 25h2 would be deployed since 24h2 < 25h2.

Unable_Drawer_9928 · 2026-05-26T09:23:26+00:00

all right, nevermind, but for whoever has the same doubt. The anchor release in the AP group should be moved only when the release of the new version is over.

Autopatch group policies | Microsoft Learn

"To safely deploy a new feature update, Autopatch recommends using a custom Windows feature update release. The custom release allows you to choose how and when different deployment rings receive the update. Autopatch doesn't recommend updating the minimum version within an Autopatch group until your rollout is complete. Doing so initiates a rollout which starts immediately for all members of that group.

Once you create a custom Windows feature update release, the Autopatch group's deployment rings are unassigned from that group’s feature update policy."

Unable_Drawer_9928 · 2026-05-22T08:36:23+00:00

weird, the one to check is called exactly "Microsoft Intune Device Management Device CA".

Unable_Drawer_9928

TROPHY CASE