ERROR_NOLOGON_SERVER_TRUST_ACCOUNT (0X00000711) Fix

Quick answer

The account you're using is a computer trust account (ends in $), not a user account. You can't log into Windows interactively with it. Switch to a real user account or reset the machine account password.

What's actually happening here

Error 0X00000711 — ERROR_NOLOGON_SERVER_TRUST_ACCOUNT — pops up when you try to log into a Windows machine using an account that's flagged as a server trust account. In Active Directory, every domain-joined computer has a hidden machine account (like DESKTOP-PC$). That account exists so the machine can authenticate with the domain controller, not so a human can sit at the keyboard and type a password.

I've seen this most often in two scenarios:

Someone manually typed DESKTOP-PC$ as the username in the login screen — maybe thinking it was a local admin trick.
A service or scheduled task is configured to run under the SYSTEM account or the machine account, and something's trying to present those credentials to a remote resource interactively.

The domain controller sees the account has the USER_SERVER_TRUST_ACCOUNT bit set (0x200 in userAccountControl), and says "nope, you can't log in from a keyboard."

Fix steps

Step 1: Confirm you're using a machine account

Check the Username field. If it ends with a dollar sign ($), that's your problem. If the system's hostname with $ appears (e.g., PC123$), you're locked out.

Open an administrative command prompt and run:

whoami /groups | findstr "0x00000711"

That won't show the error directly, but you can see your current security context. If you're already logged in as a user and just getting the error when connecting to another machine, run:

net use \\target-server\share /user:DOMAIN\PC123$

You'll get System error 0x00000711 back.

Step 2: Log in with a real user account

Switch to a domain user account that has userAccountControl set to NORMAL_ACCOUNT (0x200). This is any standard employee account, not one ending in $. If you don't have one, use the local administrator account:

Username: .\Administrator
Or: PC123\Administrator

Once logged in, don't try to runas with the machine account — that'll fail the same way.

Step 3: If the local admin is also broken

You might need to reset the machine account password from the domain controller side. On the domain controller, run:

Reset-ComputerMachinePassword -Server DC01 -Credential DOMAIN\AdminUser

Or from the affected machine (if you can still get a command prompt via Safe Mode):

netdom resetpwd /s:DC01 /ud:DOMAIN\AdminUser /pd:*

This forces the domain to re-establish the trust relationship. After that, reboot and try logging in with a normal user.

Alternative fixes if the main one fails

Option A: Unjoin and rejoin the domain

If step 3 doesn't work, the machine account may be orphaned or have a bad password hash. Unjoin from the domain (use a local admin account), reboot, then rejoin. This regenerates the machine account entirely.

I've had to do this on Server 2019 boxes where the secure channel was completely hosed. It's a nuclear option but works every time.

Option B: Check for hardcoded machine account in scheduled tasks

Sometimes a scheduled task is set to run as NT AUTHORITY\SYSTEM but the task is calling a runas command under the machine account. Check schtasks /query /v for any task that uses %COMPUTERNAME%$ as the user. Change those to NT AUTHORITY\SYSTEM or a service account.

Option C: Review group policy

Rare, but I've seen a GPO that sets Deny log on locally for the Everyone group, which inadvertently blocks machine accounts from interactive logon. Check gpresult /h report.html and look under User Rights Assignment for Deny log on locally. Remove the machine account SID from there.

Prevention tip

Never use a machine account (COMPUTERNAME$) for interactive logons. They're designed only for network authentication between the computer and the domain controller. If you need a non-user account for a service, create a dedicated managed service account or group managed service account (gMSA) in Active Directory. Those are built for this and won't trigger 0X00000711.

If you inherit a system, always check Get-ADComputer -Identity COMPUTERNAME for userAccountControl before assuming any account can log on interactively.