Your Mac Sends the Wrong Windows Account Over RDP

The tunnel reconnects, the Mac reaches the office network again, and Remote Desktop still answers with a logon failure. That error is not the VPN's. The tunnel gets the Mac onto an approved network; a Windows account signs in to the remote computer, and the connection entry can keep sending an account you stopped using months ago.

Walk the entry before you touch the keychain.

The VPN account and the Windows account are different things

A VPN identity authenticates the device or the person to the tunnel gateway. It says nothing about which Windows account the remote host will accept, and it cannot substitute for one. When the tunnel is healthy and the desktop rejects the logon, the problem has already moved past the network layer. Treat the two authentications as separate events with separate logs. The gateway can show a clean session while the Windows security log records a failed logon for an entirely different reason.

Suppose the administrator told you to use EXAMPLE\alex and the saved entry still selects a bare alex. Those are different accounts. The unqualified name is resolved against the remote computer's local accounts, and on a domain-joined machine it may not resolve to the domain identity at all.

Removing the domain prefix is therefore not a generic repair. It changes which account is being requested, and it can produce a rejection that looks like a password problem while the password was never the issue.

Open the connection entry, not the whole keychain

In the current Windows App for macOS, find the remote PC under Devices, open its Edit action, and look at the account attached to that specific entry. The app exposes saved-credential controls that let you choose another saved account or remove an obsolete one. That is the supported place to fix the selection. Change one property at a time, so you can tell which edit actually mattered. A credential change and a hostname change made together produce a result nobody can attribute.

Do not start by deleting every keychain item whose name contains the server name. Keychain entries are shared across applications, and a broad deletion can remove unrelated access without changing anything on the Windows side. It also destroys the evidence you would want if the real problem turns out to be the hostname, the route, or the RDP service.

If one saved credential is used by several remote PCs, check those dependencies before removing it. Editing the entry for one PC is reversible; deleting a shared credential is a change with a wider blast radius and a worse audit trail.

Use the account form the administrator supplied

Type the account exactly as it was issued, in the form the environment expects: DOMAIN\user for a NetBIOS-style domain, or the user principal name if that is what the directory uses. Then store it against this PC and make one deliberate connection attempt.

Watch which account the sign-in prompt shows. A prompt that already contains a different name means the saved selection was not replaced, and the attempt you just made tested the old credential again.

Keep the password out of notes, tickets, and screenshots. Record the account name and the exact error code instead, because the code distinguishes a bad credential from a policy rejection, an expired password, or a machine that is not accepting RDP at all.

A failed connection before sign-in is a different fault

If the viewer fails before any Windows logon appears, credentials are not the suspect. Check that the hostname resolves, that the route to the host exists over the tunnel, and that the RDP service is listening. A TCP connection that never establishes never reaches the account layer.

Conversely, an explicit account rejection is not evidence that DNS is broken or that certificate validation should be relaxed. Those changes weaken the connection and usually leave the rejection exactly where it was.

Test in the smallest possible steps: confirm the port is reachable, confirm the logon prompt appears, confirm the account shown is the one you intend, then supply the password. Each step has a distinct failure and a distinct fix.

Leave automatic reconnection alone

Automatic reconnection reuses the existing entry, including its saved account. It is a convenience, not a credential repair, so turning it off does not fix a wrong selection and turning it on does not create one. If the entry now holds the right account, reconnection will use it.

Save the corrected entry, connect once by hand, and note the account that worked. That single line is what makes the next person's diagnosis five minutes instead of an afternoon of keychain archaeology.