NLA issues after AD scheme update

NLA issues after AD scheme update

avatar

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"

All Comments (4)

avatar

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

avatar

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

avatar

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

avatar

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