Since the upgrade of our AD scheme i can't connect to our Windows 2019+ servers anymore. I only receive this error in the logs. Other clients like Remmina work totally fine with the same settings for login.
15.05.26 07:20 remotedesktopmanager [07:20:40:275] [327199:00051091] [ERROR][com.freerdp.core] - [nla_recv_pdu]: ERRCONNECT_ACCOUNT_RESTRICTION [0x00020017] 15.05.26 07:20 remotedesktopmanager [07:20:40:275] [327199:00051091] [ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int][0x780bf85c9d60]: CONNECTION_STATE_NLA - nla_recv_pdu() fail 15.05.26 07:20 remotedesktopmanager [07:20:40:275] [327199:00051091] [ERROR][com.freerdp.core.rdp] - [rdp_recv_callback_int][0x780bf85c9d60]: CONNECTION_STATE_NLA status STATE_RUN_FAILED [-1] 15.05.26 07:20 remotedesktopmanager [07:20:40:275] [327199:00051091] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
FreeRDP with console also works without any issues.
xfreerdp /v:SERVER /u:USER /d:DOMAIN.DE /sec:nla /cert:ignore
Only the RDP via the RDM doesn't work.
DISTRIB_ID=Ubuntu DISTRIB_RELEASE=26.04 DISTRIB_CODENAME=resolute DISTRIB_DESCRIPTION="Ubuntu 26.04 LTS"
Hello
The error normally means that the server is enforcing Kerberos authentication for your account, but RDM is only attempting NTLM.
Can you check the settings in the "Authentication" tab of your RDP session? SSPI Module should be set to "Portable" (this is the default for 2026.1) and the authentication package should be either "Negotiate" (preferable) or "Kerberos".
If it's still not working after checking that, can you please launch RDM with the environment variable "WLOG_LEVEL" set to "DEBUG", reproduce the issue and then send me the complete terminal output by direct message?
export WLOG_LEVEL=DEBUG remotedesktopmanager
Please, let me know if something isn't clear and sorry for the inconvenience
Kind regards,
Richard Markievicz
Hi Richard,
The settings for the host look like this:
I did fiddle around with the SSPI and Authentication Package sections so i tried every combiniation thats possible, but no luck.
Also sent you the debug log via direct message.
bb04ae63-23c6-4f7f-9267-6e10e2303c74.png
Hi
Thanks for the logs, I'm replying here for visibility.
The settings you want in the authentication tab are "Portable" for SSPI module and either "Negotiate" or "Kerberos" for the authentication package.
From your log, we're not able to find the Kerberos KDC (typically the domain controller). It's provided either by direct configuration (environment variable or explicitly specified in RDM), via an existing krb5.conf file (typically in /etc/krb5.conf or /usr/local/etc/krb5.conf) or found by DNS. So it's surprising that e.g. Remmina seems able to find it but we do not.
The first thing I'd check is if it is indeed resolvable by DNS:
dig +short SRV _kerberos._tcp.DOMAIN.DE dig +short SRV _kerberos._udp.DOMAIN.DE
(Obviously replacing "DOMAIN" with the domain you are authenticating against)
Otherwise if you have a krb5.conf in one of the locations written above, can you share the content with me by direct message? Feel free to obfuscate anything you don't want me to see.
Thanks and kind regards,
Richard Markievicz
Hello
I've been talking with @s2 offline and posting back here with the resolution in case it's helpful for other users in the future.
The KDC was being resolved from the krb5.conf file (as opposed to by DNS or an explicit reference in RDM). However, the krb5.conf had a formatting issue and put all the KDC entries on one line, like this
kdc = dc1.domain.de dc2.domain.de
Whereas a properly formatted realm places them on separate lines like this
[realms]
DOMAIN.DE = {
kdc = dc1.domain.de
kdc = dc2.domain.de
admin_server = dc1.domain.de
}
What's not clear to me currently is why this was working with other clients, and it's possible that the main krb5.conf is being merged with another config file in the drop-in directory. I'll wait for @s2 to get back to me with confirmation, and that being the case we will need to make improvements on our side to match the MIT Kerberos behaviour.
Thanks and kind regards,
Richard Markievicz