Account

The Account pane sets who a Remote Desktop client must sign in as to connect. ProRDP gives you three kinds of account, and each has a real security trade-off.

Sign in

Account type

The Account picker chooses how clients authenticate. The rest of the section changes to match.

Choose a ProRDP account when you want remote access to have its own credential. If the password leaks, the only thing exposed is access to this server. It can’t be used to log in at the Mac, unlock the login keychain, or unlock FileVault.

Choose a macOS account when you want one password to remember, and you want macOS to have a say in every login. With this option, a disabled, locked, or deleted account can’t connect even if its credentials were correct when you set them up.

Choose Entra ID when your organization signs in with Microsoft, and you want remote access to follow the same rules as everything else: multifactor authentication, Conditional Access, passkeys, and accounts your administrators can disable centrally.

Only the single account you configure can sign in. There’s no mode that lets any local user connect. Network accounts from a directory server aren’t offered, so the server keeps working when the directory can’t be reached.

ProRDP account

Username

The name clients enter when they connect. It doesn’t have to match any account on the Mac.

Default: Your macOS short name.

Password

The password clients enter when they connect. It’s saved in your login keychain as you type.

Default: None. The server refuses to start until you set one, rather than accepting anyone who can reach the port. Until then, the caption under the field reads “Required to start the server.”

macOS account

macOS account

The local macOS user that clients sign in as. The list shows the user accounts on this Mac.

Default: The user who is logged in and running ProRDP.

Store password NT hash

Full label: Store password NT hash (required for Network Level Authentication).

Network Level Authentication (NLA) authenticates the client before a session is created, using the NTLMv2 protocol. NTLMv2 needs the password’s NT hash before the client reveals the password itself. macOS doesn’t keep an NT hash for local accounts; it stores only PBKDF2 and SRP verifiers, which can’t be turned into one. So for NLA to work with a macOS account, ProRDP has to keep the NT hash itself.

What the stored hash can and can’t do. For NTLM against this server, an NT hash works like the password. It can’t unlock the Mac, the login keychain, or FileVault, though, so storing it exposes far less than storing the password would.

With the hash turned off, clients need a change. By default, Windows Remote Desktop requires NLA and refuses to connect without it. Add this line to the client’s .rdp file:

enablecredsspsupport:i:0

With NLA off, the client shows a warning each time it connects, and a client that hasn’t authenticated gets further into the connection before it’s turned away.

macOS account password

Shown when Store password NT hash is on. Type the account’s current macOS password, then press Return or click Check with macOS and save.

ProRDP stores the hash only after macOS confirms the password. A typo can’t become a working remote password this way. If macOS rejects what you typed, the reason is shown in orange and nothing is saved. Once a hash is stored, the field shows dots as a placeholder. The password itself is never kept, so it can’t be shown again.

Changed your macOS password? Enter the new one here. The stored hash still matches the old password, so clients using the new one are told their credentials are wrong. ProRDP can’t detect the change in advance, because that would mean keeping the password itself.

Entra ID

Entra ID requires a commercial license. It isn’t included in free home and personal use.

Entra ID is experimental. With it, nobody types a password into their Remote Desktop client. Instead, ProRDP shows Microsoft’s own sign-in page inside the session, before any of the Mac is shown. Only the Microsoft account you sign in with here can get past it.

ProRDP never sees a password or keeps a token. It remembers only which account is allowed, in your login keychain.

Sign in with Microsoft

Click Sign in with Microsoft and sign in with the work or school account that should be able to connect. The sign-in opens in a private browser window, so it doesn’t reuse an account you’re already signed in to in Safari. Personal Microsoft accounts aren’t supported.

The first time anyone in your organization signs in, Microsoft asks them to consent to ProRDP. If your organization only lets administrators consent to apps, ask an administrator to approve ProRDP once for everyone.

Once you’re signed in, the pane shows the account’s name, with Sign Out. To allow a different account instead, sign out and sign in again with that one.

Default: Not signed in. The server refuses to start in Entra ID mode until you sign in.

Bypass certificate verification

Full caption: Allow unverified connections to this Mac without certificate trust (not recommended).

Entra ID requires a certificate your clients trust. This option lets the server start without one, which is useful for trying Entra ID before you have a certificate, but not for everyday use.

Default: Off.

When you turn it on, ProRDP asks you to confirm:

Proceed with caution

Certificate verification ensures you are connecting to a Mac you trust before you enter your Entra ID credentials. If you bypass this check, you could unknowingly connect to a malicious device and leak your Entra ID credentials. Only proceed if you accept this risk.

While a client is connected, you can turn this option off, but not on. ProRDP can’t tell a click at the Mac from one made over Remote Desktop, so a remote session can’t weaken the sign-in for whoever connects next. Only someone at the Mac can turn it on, while nobody is connected.

Certificate

Remote Desktop’s own Network Level Authentication proves your password to the exact server you meant to reach. Signing in to Microsoft inside the session can’t do that. So for Entra ID, the server’s certificate is the only thing that proves to the client it has reached your Mac, and not a device in the middle passing the connection along.

So Entra ID needs a certificate that:

• was issued by a certificate authority (CA), not ProRDP’s self-signed one
• the Mac trusts, which it does once your organization’s CA is installed, usually through MDM
• names the address clients connect with, such as rdp.contoso.com or the Mac’s full host name

Choose one under Security → Certificate. If the chosen certificate won’t do, the Entra ID section says so in orange as soon as you pick Entra ID. If the server can’t start because of it, the reason is shown in red.

What people see when they connect

1. They connect as they normally would. The .rdp file needs enablecredsspsupport:i:0, because there’s no password for Network Level Authentication to check:

   full address:s:rdp.contoso.com
   enablecredsspsupport:i:0
   authentication level:i:1
   

   With a trusted certificate, authentication level:i:1 makes Windows refuse a server it can’t verify, instead of asking.

2. Microsoft’s sign-in page appears, with no account filled in. They sign in as they would anywhere else, including multifactor authentication.

3. If the account is the one this Mac allows, the Mac’s desktop replaces the sign-in page.

A different account is turned away with “That is not the account this Mac is signed in with”, and can Try again. After three failed attempts, or three minutes on the sign-in page, the connection closes.

The sign-in page is shown on the client’s main monitor only. Any other monitors stay black until the person has signed in.

Passkeys and Windows Hello

The sign-in page can use the connecting computer’s own passkeys, Windows Hello, and security keys. When the page asks for one, Windows shows its usual prompt on the client, not on the Mac. Choose Sign-in options on Microsoft’s page, or the passkey option after entering an email address.

Passkeys need the same trusted certificate as Entra ID itself, and a client that supports WebAuthn redirection. The Windows Remote Desktop client does by default (redirectwebauthn:i:1).

How the sign-in page is protected

The sign-in page runs on the Mac before anyone has proved who they are, so it’s locked down:

• It can only go to Microsoft’s sign-in pages and your organization’s own federated sign-in server, if it has one.
• It can only reach the internet, not this Mac or anything else on your network.
• It runs in Lockdown Mode.
• It can’t read or change the Mac’s clipboard.
• Its keyboard and mouse input stays on the sign-in page and never reaches the Mac.
• It keeps no cookies or data after the connection ends.