Symptom

After a machine has been successfully migrated from Active Directory to Entra ID (Azure AD joined), standard Entra users are unable to log on to the workstation interactively. The machine appears correctly joined to Entra, but the Windows login screen rejects Entra user credentials.

"The local policy of this system does not permit you to logon interactively."

“The sign-in method you're trying to use isn't allowed. For more info, contact your network administrator.”

• Entra user receives an error or is prevented from signing in at the login screen after migration.
• The machine is confirmed Entra-joined but local sign-in fails for standard Entra accounts.
• Entra accounts with local administrator rights can sign in successfully — this can make the issue appear user-specific when it is policy-wide.
• secpol.msc → User Rights Assignment → Allow log on locally shows legacy AD domain SID entries alongside or in place of well-known local groups.
• A combination of the above symptoms.

Cause

During the migration from Active Directory to Entra ID, the local security policy on the endpoint retains the original AD group entries under User Rights Assignment → Allow log on locally (SeInteractiveLogonRight). These stale AD SIDs do not resolve on an Entra-joined machine, effectively blocking interactive logon for standard Entra users.

In some cases the BUILTIN\Administrators group remains intact alongside the stale entries. This means local admins and Entra accounts with administrator rights can still sign in, while standard Entra users cannot. This behavior can cause the issue to go undetected initially, or be misdiagnosed as a per-user account problem rather than a policy problem.

Additionally, explicit deny entries may remain under SeDenyInteractiveLogonRight, which can compound the issue.

Entra-joined user accounts are added to the local Users group (S-1-5-32-545) during the Entra join process. Granting this well-known SID interactive logon rights is what restores access for standard users.

Example: Affected Policy State

The screenshot below shows a real-world example of the Allow log on locally policy after a migration where this issue occurred. Three stale S-1-5-21-… AD SIDs are present alongside Administrators. Standard Entra users were blocked from signing in; Entra admin accounts were unaffected because the Administrators group remained.

Solution

The SeInteractiveLogonRight and SeDenyInteractiveLogonRight policies can be corrected manually via secpol.msc, or a script can be used to remediate both in a single automated pass.

Script Solution

Download FixLogonRights.ps1 from the PowerSyncPro GitHub repository.

https://github.com/PowerSyncPro/MigrationAgent/tree/main/login-rights-fix

Run the script as a local administrator from an elevated PowerShell prompt:

.\FixLogonRights.ps1

The script will automatically:

• Export the current local security policy using secedit
• Replace SeInteractiveLogonRight with the correct well-known local SIDs
• Clear SeDenyInteractiveLogonRight to remove any explicit deny entries
• Re-import the corrected policy scoped to USER_RIGHTS only — no other policy areas are modified
• Verify the changes were applied and log any mismatches
• Run gpupdate /target:computer /force to refresh computer policy

Logon rights granted after the script runs:

A log is written to C:\Temp\Fix-SeInteractiveLogonRight.log on each run. Check this file to confirm the original values, whether the import succeeded, whether verification passed, and the gpupdate exit status.

Reboot the machine after the script completes before testing Entra user sign-in.

Manual Solution

Perform the following steps from a local administrator account to correct the policy manually.

Allow Log On Locally

• Open Local Security Policy (secpol.msc)
• Navigate to Security Settings → Local Policies → User Rights Assignment
• Open Allow log on locally
• Remove all existing entries, including any S-1-5-21-… AD SIDs
• Add the following:
  • Administrators (or BUILTIN\Administrators)
  • Users (or BUILTIN\Users)
  • Backup Operators (or BUILTIN\Backup Operators)
  • Guest

Deny Log On Locally

• In the same User Rights Assignment section, open Deny log on locally
• Remove all entries so the policy is empty

Reboot the workstation and test Entra user sign-in.