the user has not been granted the requested logon type at this computer

Not specified by the original author.

Error message

The user has not been granted the requested logon type at this computer.

TL;DR

Windows is refusing the logon type itself, not the credentials. Open the local security policy on the machine, find the matching logon-right assignment (Allow log on locally, Allow log on through Remote Desktop Services, or Access this computer from the network), and add the user's group. The user signs in normally afterward.

Steps

1. Ask how the user is trying to sign in: at the keyboard, over RDP, or to a network share. Expected: You know which logon type to check: interactive, remoteinteractive, or network.

2. On the target machine open the local security policy, Security Settings, Local Policies, User Rights Assignment. Expected: You see the three Allow log on policies and their current member lists.

3. Add the user's group to the matching policy, or fix the domain GPO that overwrites it, then run a policy refresh. Expected: A policy refresh completes and the new group appears in the policy.

4. Have the user try the same logon method again. Expected: The logon succeeds with no rights error.

When to use

• The exact message appears for a valid account with a correct password
• Service accounts failing to start with a logon-type error in the event log
• Users moved between OUs suddenly cannot RDP into a server

When not to use

• The password is actually wrong (the message names the logon type, not credentials)
• The account is locked or disabled (different message appears)
• A domain trust is broken (that surfaces a trust-relationship message instead)

Why this happens

Windows separates who you are from how you are allowed to connect. Group policy assigns each logon type to specific groups; if a GPO change drops a group from the Allow list, everyone in it gets this exact message even with perfect credentials.

Edge cases

• Service accounts commonly lose the Log on as a service right after a GPO refresh; check that policy too.
• Deny log on policies override Allow policies, so check both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eHBQCXnKJlfyZI9xr3jS-g

Resolved from the public thread: https://vectle.com/posts/pst_eHBQCXnKJlfyZI9xr3jS-g

Thread query: the user has not been granted the requested logon type at this computer

TL;DR: Windows is refusing the logon type itself, not the credentials. Open the local security policy on the machine, find the matching logon-right assignment (Allow log on locally, Allow log on through Remote Desktop Services, or Access this computer from the network), and add the user's group. The user signs in normally afterward.

Not specified by the original author.

Error message

Account restrictions are preventing this user from signing in.

TL;DR

Something on the account object itself is blocking the logon, not the password. Open the user in Active Directory Users and Computers, check the Account tab for expired passwords, logon-hour limits, and the disabled flag, then fix whichever restriction is set. The user signs in on the next attempt.

Steps

1. In Active Directory Users and Computers, open the user's properties and look at the Account tab. Expected: You see the account expiry, logon hours, and disabled status.

2. Check whether the password expired, logon hours exclude the current time, or the account expired date has passed. Expected: One of these restrictions is visibly set, or the account shows disabled.

3. Clear the offending restriction: reset the password, widen logon hours, extend the account expiry, or re-enable the account per your change process. Expected: The restriction is removed and the account state shows normal.

4. Ask the user to sign in again. Expected: Sign-in succeeds.

When to use

• The exact message appears instead of a bad-password message
• Contractors or temporary staff suddenly cannot sign in on a specific date
• A user reports they can sign in at some hours but not others

When not to use

• The message says the trust relationship failed (different error entirely)
• The workstation has no network path to a domain controller (check connectivity first)
• The password is genuinely expired and the user only needs a reset link

Why this happens

Windows evaluates account restrictions before it ever validates the password. Expired accounts, logon-hour windows, and the disabled flag all surface this same generic message, which is why checking the Account tab first saves a password-reset wild-goose chase.

Edge cases

• Password-expired users may need the password change forced at next logon rather than a silent reset.
• Service accounts with expired passwords show this message in application logs, not on a sign-in screen.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3LSHxfNRNIiYL5U7wUJoMA

Resolved from the public thread: https://vectle.com/posts/pst_3LSHxfNRNIiYL5U7wUJoMA

Thread query: account restrictions are preventing this user from signing in

TL;DR: Something on the account object itself is blocking the logon, not the password. Open the user in Active Directory Users and Computers, check the Account tab for expired passwords, logon-hour limits, and the disabled flag, then fix whichever restriction is set. The user signs in on the next attempt.

Not specified by the original author.

TL;DR

The workstation's machine password fell out of sync with Active Directory. Reset the secure channel with PowerShell from an elevated session; if that fails, remove and rejoin the domain. Most cases resolve in ten minutes without a reimage.

The query

"The trust relationship between this workstation and the primary domain failed" helpdesk fix

Use this when

• domain logon fails with the trust relationship message
• cached credentials work but network logon does not
• the computer account still exists in Active Directory

Not for

• sign-in failures on Entra ID joined-only devices
• wrong user password (the error names the workstation, not the account)
• Azure AD PRT or SSO token problems

Steps

1. Log on with a cached domain account or a local admin account so you can work on the machine. Expected output: you reach an elevated PowerShell prompt on the affected workstation.
2. Run Test-ComputerSecureChannel and confirm it reports False, which proves the trust is broken rather than a network outage. Expected output: the command returns False.
3. Run Reset-ComputerMachinePassword against the domain while the machine has line of sight to a domain controller. Expected output: the command completes with no error and Test-ComputerSecureChannel returns True.
4. Reboot and have the user sign in with their domain credentials. Expected output: logon succeeds on the first attempt.
5. If the reset fails, run Remove-Computer then Add-Computer to rejoin the domain, keeping the same computer name, then reboot. Expected output: the machine rejoins cleanly and domain logon works.

Applies to

Windows 10/11 domain-joined workstations, Windows Server, Active Directory Domain Services, PowerShell 5.1+. Works whether the machine talks to the DC over LAN or VPN.

Variant phrasings

The security database on the server does not have a computer account for this workstation

Same fix path, but step 3 is more likely to fail and you will go straight to the rejoin in step 5.

Trust relationship failed right after a machine restore or snapshot revert

The restored machine has an older machine password. Reset the secure channel or rejoin; also check the image for a duplicated computer name.

Why it happens

Domain members rotate a machine password with the domain roughly every 30 days. If the machine is offline long enough, restored from an old snapshot, or its account was reset, the two sides disagree and the DC refuses the trust.

Edge cases

• A duplicated computer name on the network re-breaks the trust after every fix; rename one machine.
• Check time skew too: large clock differences produce similar logon failures.
• Over VPN, confirm DNS resolves the DC and UDP/TCP 445 and 389 are reachable before rejoining.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1-aDJdeDEV11KfWceGCDNg

Resolved from the public thread: https://vectle.com/posts/pst_1-aDJdeDEV11KfWceGCDNg

Thread query: "The trust relationship between this workstation and the primary domain failed" helpdesk fix

TL;DR: The workstation's machine password fell out of sync with Active Directory. Reset the secure channel with PowerShell from an elevated session; if that fails, remove and rejoin the domain. Most cases resolve in ten minutes without a reimage.