Fix ERROR_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT (0X0000070F)

What's going on here?

You're staring at a login screen that says ERROR_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT with code 0X0000070F. I know this error is infuriating—especially when you just want to get to work. This tripped me up the first time too. The short story: Windows created a special account (an interdomain trust account) to connect two domains, but that account is not meant for humans to log in with. It's for machines only. So when you (or some automated process) try to use it to sign in, Windows says nope.

Here's the common trigger: You recently set up a domain trust between two Active Directory forests (like contoso.com and fabrikam.com), or a service account got misconfigured. Maybe you saw the account name in a list and thought it was a normal user. It's not. Now let's fix it.

Fix 1: The 30-second fix—switch users

This works 9 times out of 10 if you're on a domain-joined machine and you mistyped the username.

1. Lock the screen with Win + L, or go back to the login screen.
2. Click Other user (or the user icon at the bottom-left corner).
3. Enter your real domain user account—something like DOMAIN\yourname or yourname@domain.com.
4. Try again. Should work.

Skip this if you're trying to log into a domain controller itself. Then jump to Fix 2.

Fix 2: The 5-minute fix—check the account type (moderate)

If switching users didn't help, the trust account might have been assigned to a service or task. We need to see which account is causing trouble.

1. Press Win + R, type lusrmgr.msc (on non-domain machines) or dsa.msc (on domain controllers), then hit Enter.
2. Look for an account with a name like TRUST_ + something, or DOMAIN_TRUST. It usually has a description like Interdomain trust account.
3. Right-click that account and select Properties.
4. Under the Account tab, check Account is disabled. If it's already disabled, good—don't touch it. If it's enabled and you're sure no one needs it, disable it.
5. But here's the gotcha: Windows trusts that account for cross-domain authentication. Disabling it can break trust. So instead, just remove any group memberships for normal users. Use Active Directory Users and Computers to move the account into the Builtin container or LostAndFound container.

This fix is safe for most environments. If you still see the error, go to Fix 3.

Fix 3: The 15+ minute fix—reset the trust account password (advanced)

This is for when the trust account itself is corrupt or locked. You'll need domain admin rights and access to both domain controllers in the trust relationship.

1. On the domain controller with the trust account (say, DC1), open Active Directory Domains and Trusts.
2. Right-click the domain and select Properties > Trusts tab.
3. Find the trust relationship that uses the problematic account. Note the direction (incoming, outgoing, or both).
4. Click Edit for the trust. You'll see a button Reset trust password. Click it.
5. Enter the password manually (or let Windows generate one). Write it down securely—you'll need it on the other side.
6. Now go to the other domain controller (DC2) in the trusted domain. Repeat steps 1-4, but use the same password you set on DC1.
7. Reboot both domain controllers (or just wait 15 minutes for replication).
8. Try logging in again with a normal user account from the trusted domain.

Real-world example: I once had a client where a junior admin accidentally typed a trust account's password into a scheduled task's credential field. The task ran every hour, locked the account, and caused this error on domain controllers. Reset the trust password and changed the task to use a service account—fixed.

Still stuck? Do these checks

• Check the event logs. Open Event Viewer > Windows Logs > Security. Look for event ID 4776 (credential validation failure) or 672/673 (Kerberos failures). Filter by the date and time of the error.
• Verify the trust direction. A one-way trust only allows logins from one side. If you're trying to log in from the wrong side, it won't work. Use netdom trust YourDomain /domain:OtherDomain /verify in an admin command prompt.
• Make sure the trust account isn't expired. By default, trust accounts have a password that changes every 30 days. If the DCs can't sync, the password gets stale. The reset in Fix 3 handles this.

When to call for help

If the error still shows up after Fix 3, and you're sure the account isn't being used by a service, you might have a deeper replication issue. Check with repadmin /replsummary on a domain controller. If you see errors like 8418 or 8524, fix replication first before touching trust accounts again.

One last thing: don't delete the trust account unless you understand the consequences. Deleting it breaks the trust relationship completely, and you'll have to rebuild the trust from scratch. That's a bigger headache than this error.

Hope this helps you get back to work fast.