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

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.