Kerberos/CredSSP/NTLM issue

Hello

Claude is correct that RDP will not even try Kerberos if you connect with an IP address, but it is wrong about this being a setting you can toggle on the RDP client (at least - using Microsoft's first party clients, which is what RDM does by default - embedded RDP is the Microsoft RDP ActiveX control).

We do expose this option if you switch to the FreeRDP backend, but it doesn't have first class support on RDM Windows so it feels a bit heavy handed.

The expectation is that if Kerberos can't be used for some reason, the MS RDP client should failover to using NTLM.

You can't really disable Kerberos just for Microsoft RDP, you have to disable it generally via a group policy or similar. I wouldn't recommend it.

Can you explain exactly what the problem or error is when you try to connect by FQDN?

Thanks and kind regards,

This is what we did and the consequences are a little bit strange:

1. First we connected via a port forward in our router, the credentials are saved in RDM. It's worked without flaw.
2. Then we switched to Tailscale and now tried to connect via IP. Here, the first login failed with wrong credentials. When I then entered the password manually it connected.
3. 3. Then we added split DNS to Tailscale and we can now address the servers by FQDN. now we get this error when using our RDM entry

Remote Desktop Connection

An authentication error has occurred. The token supplied to the function is invalid

Remote computer: srv003.ad.domain.com

^ Hide details OK

Error code: 0x0 Extended error code: 0x0 Timestamp (UTC): 03/09/26 05:16:13 PM Activity ID: 56faf5ba-9430-4510-b12c-cefee05f0000

Press Ctrl+C to copy. e

But when we use quick connect with the IP or FQDN and enter the credentials manually we can login..

Hello

It sounds to me like a credential / authentication context mismatch, possibly being caused by cached credentials.

If you pick one RDP session to test with, can you verify:

• The server address (host) is the FQDN (i.e. srv003.ad.domain.loc not just srv003)
• You provide both the username and domain in the credentials in RDM
  • Preferably you would give the username in UPN format (user@ad.domain.loc) and leave the domain field empty
• In the "Advanced" tab of the RDP session, check the "Public mode" option
  • This is just for testing, it should prevent the RDP ActiveX from using cached Windows credentials
• Can you connect over Tailscale?

In the above workflow, did you use the same user account each time? Is it an actual user account, or "Administrator" (which is a key difference when we consider that account can have the same name in both local and domain contexts)?

Please, let me know if something isn't clear

Kind regards

Yes, it looks a little bit like a caching issue because another server in the same network with the same FQDN suddenly connects successfully when using the linked credentials. the one with the credentials set in the session did not, but when i switch it to the linked creds as well it works again. so, thanks, everything is fine now! :)

btw, please remove the real-life domain names from your post, just for privacy reasons. I thought I cleaned it up in my post but obviously did not..

Hello

Ok, first I did edit my post. Sorry about that.

I'm glad things seem to be working better. Without a broader understanding of how you have things set up, it's hard to say precisely "this is what the problem was" but I can give some pointers moving forward.

• RDM shouldn't cache credentials itself, but if you have the session "open" (and that can even be disconnected, but with the tab open), when you reconnect it, it won't usually pick up changes made to the credentials on the session. You do need to close the session fully and reopen it, I think.
• Windows maintains its own credential cache; the GUI is in "Credential Manager". If you look in the "Windows Credentials" section, RDP server credentials are ones with the prefix TERMSRV. You can avoid hitting this cache if you use the "Public Mode" option which normally shouldn't be necessary, but it can be useful for testing.
• As I said, it's important to specific the FQDN for the server host but also you want to be sure that you're properly specifying the domain portion of the username (and I do recommend generally using a UPN format, i.e. user@domain.loc and leaving the Domain field blank)
• It's conceivable that if you're been trying different credentials in different formats against different forms of address for the same server, you got an invalid Keberos ticket locally somehow. The command line `klist` will show cached Kerberos tickets; it can also be useful for troubleshooting as it will show the exact hostname used (and can therefore be useful for detecting hostname mismatches). You can also purge cached Kerberos tickets with `klist purge`. Note that this applies to the currently logged in user, so if you are using other user accounts for your RDP sessions YMMV. I recommend checking the documentation for klist in that case.

As always, if you're still getting issues, or have other questions or comments; don't hesitate to post back

Kind regards,