[Technical Inquiry] Restricting Local Interactive Logon to Primary User only via Microsoft Intune

Question

[Technical Inquiry] Restricting Local Interactive Logon to Primary User only via Microsoft Intune

DB K 0

Environment Details:

Tenant Type: Microsoft Entra ID (Joined)

Management Tool: Microsoft Intune (Endpoint Manager)

OS: Windows 10/11 Pro/Enterprise

Project Goal: Strict 1:1 Device-to-User binding for high-security compliance.

Background: We are implementing a security policy for a client requiring a strict 1:1 mapping between employees and Windows devices. The core requirement is that only the assigned Primary User (as defined in Intune) should be able to sign in to their specific PC. All other Entra ID users must be blocked from performing an interactive login on that device.

Current Consideration & Risks: We have evaluated using Intune Remediations or PowerShell scripts to modify local group memberships (e.g., "Users" and "Remote Desktop Users"). However, we have significant concerns regarding:

Lockout Risks: Potential script errors or race conditions that might prevent even the Primary User from logging in.

Recovery Challenges: If the device loses Intune connectivity after an aggressive policy application, it may require a full OS reinstallation.

Technical Questions:

1. Is there a Native/Declarative Method? Beyond imperative PowerShell scripts, are there any native CSP (Configuration Service Provider) policies or Settings Catalog options (e.g., UserRights or SharedPC mode variations) that can dynamically restrict interactive logon to only the assigned Primary User? We prefer a declarative approach to minimize execution reliability issues.

2. Robust Implementation for Dynamic Primary User Mapping If PowerShell/Remediation is the only viable path, does Microsoft provide a certified reference script? Specifically, we need logic that:

Reliably identifies the assigned Primary User UPN from the local device context or Intune management extension logs.

Modifies the local "Users" group while ensuring the Primary User and required System accounts are not excluded.

3. Safeguards & Emergency Access (Break-glass) What are the best practices to prevent a total "Dark-site" scenario (total lockout)? We are looking for guidance on:

Break-glass Accounts: How to ensure a specific Entra ID Global Admin or local admin account remains exempt from the restriction.

Integration with Windows LAPS: Can we rely on Windows LAPS as a fallback mechanism to regain access if the Primary User is accidentally locked out?

Validation Strategy: Recommended pilot testing phases to verify the policy across different hardware profiles.Environment Details:
- Tenant Type: Microsoft Entra ID (Joined)
- Management Tool: Microsoft Intune (Endpoint Manager)
- OS: Windows 10/11 Pro/Enterprise
- Project Goal: Strict 1:1 Device-to-User binding for high-security compliance.
Background: We are implementing a security policy for a client requiring a strict 1:1 mapping between employees and Windows devices. The core requirement is that only the assigned Primary User (as defined in Intune) should be able to sign in to their specific PC. All other Entra ID users must be blocked from performing an interactive login on that device. Current Consideration & Risks: We have evaluated using Intune Remediations or PowerShell scripts to modify local group memberships (e.g., "Users" and "Remote Desktop Users"). However, we have significant concerns regarding:
1. Lockout Risks: Potential script errors or race conditions that might prevent even the Primary User from logging in.
2. Recovery Challenges: If the device loses Intune connectivity after an aggressive policy application, it may require a full OS reinstallation.
Technical Questions: 1. Is there a Native/Declarative Method? Beyond imperative PowerShell scripts, are there any native CSP (Configuration Service Provider) policies or Settings Catalog options (e.g., UserRights or SharedPC mode variations) that can dynamically restrict interactive logon to only the assigned Primary User? We prefer a declarative approach to minimize execution reliability issues. 2. Robust Implementation for Dynamic Primary User Mapping If PowerShell/Remediation is the only viable path, does Microsoft provide a certified reference script? Specifically, we need logic that:
- Reliably identifies the assigned Primary User UPN from the local device context or Intune management extension logs.
- Modifies the local "Users" group while ensuring the Primary User and required System accounts are not excluded.
3. Safeguards & Emergency Access (Break-glass) What are the best practices to prevent a total "Dark-site" scenario (total lockout)? We are looking for guidance on:
- Break-glass Accounts: How to ensure a specific Entra ID Global Admin or local admin account remains exempt from the restriction.
- Integration with Windows LAPS: Can we rely on Windows LAPS as a fallback mechanism to regain access if the Primary User is accidentally locked out?
- Validation Strategy: Recommended pilot testing phases to verify the policy across different hardware profiles.

댓글 0개

답변 2개

답변

Answer 1

Jason Nguyen Tran 27,210 독립 자문가

Hi DB K,

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

댓글 0개

Answer 2

Hi DB K,

To address your first question, there isn’t currently a native Intune CSP or Settings Catalog policy that declaratively restricts interactive logon to only the Primary User. SharedPC mode and UserRights assignments come close, but they don’t dynamically enforce the Primary User mapping from Intune. At present, this remains a gap in native declarative support.

For implementation, most customers rely on Intune Remediations or PowerShell scripts to enforce local group membership changes. Microsoft does not publish a certified reference script for this scenario, but community samples exist that query the Intune Management Extension logs to identify the Primary User UPN and then adjust local group membership accordingly. The key safeguard is to ensure system accounts and break-glass administrators remain exempt.

On safeguards, best practice is to maintain at least one break-glass account, either a local admin or an Entra ID Global Admin, that is explicitly excluded from restrictions. Windows LAPS can indeed serve as a fallback mechanism, giving you a managed local admin credential if the Primary User is accidentally locked out. This provides a recovery path without requiring OS reinstallation.

For validation, I recommend piloting the policy on a small set of devices with varied hardware profiles before broad rollout. This helps catch edge cases and ensures your remediation logic doesn’t inadvertently block legitimate access. Documenting recovery steps and ensuring your helpdesk has access to LAPS credentials is also critical.

In short, there’s no native declarative enforcement today, but with careful scripting, exemptions, and pilot testing, you can achieve the 1:1 binding securely. I hope this guidance helps you move forward.

If you find this answer helpful, please consider clicking Accept Answer so others can benefit too.

Jason.