Windows Server 2022 Standard (VM in Proxmox), RDP Server using the DC for authentication.
Windows 10 Clients
I have a strange issue when connecting an Windows 10 Client to a Windows 2022 Server via RDP. The client fails with the error message “Authentication failed. Element not found”.
The issue is very strange, because other clients can connect without problems. I could already exclude problems related to the network. Since Google doesn’t know the error message it seems to me that there is a very specific problem with the authentication.
I did already update all nethserver packages and rebooted it.
Do you guys have any idea?
Is there a way to get logging information from the Domain Controller in NS about (failed) authentication attempts?
Does both windows machines (client, server) use AD container as primary DNS?
Are both part of the AD?
Windows 2022 server has been already correctly configure to allow RDP connections?
Last but not least: RDP licensing is managed by which device?
Just to be clear: I have several clients that work without problems. Just two of them show the error. At one of them it seems that the problem is related to the user account used.
The server does, for the clients it depends whether they are local or remote via VPN (I have working clients in both settings)
The server is, I have working clients inside and outside the AD. The clients with problems are outside the AD.
Yes. Other clients work well.
Licensing is managed by a license server running on the same host as the RDP server. The issue is not license-related: The same happens with “simple” (license-free) remote desktop on the Server without using the Windows Server Remote Desktop Services
I got the feeling that the issue is related to the AD authentication performed by the DC container. Therefore, I would like to see more debug/log information about authentication attempts.
IVMHO, the clients that cannot authenticated should be audited if the client can reach the AD container or not.
I’d start with the local ones, for excluding that if it’s a matter of nethserver or AD structure configuration (groups and so on)
Update: I traced the communication RDS-Server <-> AD DC Container using Wireshark.
I can see the communication flows RPC_NETLOGON between them for both cases (connection working and the error case). Therefore, the network setup should be fine.
Additionally, I created a local user on the RDS-Server. Using that account, I can connect - even from a client, where all AD accounts seem to fail.
So, for me it seems clear that the authentication in AD DC fails. I tried to re-create the user or change the password. But that didn’t help.
This brings me back to my initial thought: it may be helpful to increase the log level of the AD DC container’s samba instance to see failed authentication/authorization attempts. Is that possible?
I can access a bash shell in the DC container. I would like to increase samba’s log level there. But there seems to be very limited functionality inside the container. I could not find an editor or a way to copy files between nethserver and DC container.
Thank you so much. This was exactly, what I’ve been looking for!
So I could trace down the problem. I have logs for a successful and unsuccessful authentication attempt. Both clients (Host1 and Host2) are in the same network and use the same user account (test1) in the domain (kt), both are Windows 10 with all updates
Host1 is successful:
Aug 01 11:13:33 : auth_check_password_send: Checking password for unmapped user [(null)]\[test1@kt]@[Host1]
Aug 01 11:13:33 : auth_check_password_send: user is: [(null)]\[test1@kt]@[Host1]
Aug 01 11:13:33 : auth_get_challenge: returning previous challenge by module netr_LogonSamLogonWithFlags (normal)
Aug 01 11:13:33 : auth_check_password_send: auth_context challenge created by netr_LogonSamLogonWithFlags
Aug 01 11:13:33 : auth_check_password_send: challenge is:
Aug 01 11:13:33 : authsam_account_ok: Checking SMB password for user test1@kt
Aug 01 11:13:33 : logon_hours_ok: No hours restrictions for user test1@kt
Aug 01 11:13:33 : lastLogonTimestamp is 133036999320376810
Aug 01 11:13:33 : sync interval is 14
Aug 01 11:13:33 : randomised sync interval is 9 (-5)
Aug 01 11:13:33 : old timestamp is 133036999320376810, threshold 133030412135764960, diff 6587184611850
Aug 01 11:13:33 : auth_check_password_recv: sam authentication for user [KT\test1] succeeded
Host2 is not
Aug 01 11:13:03 : auth_check_password_send: Checking password for unmapped user [(null)]\[test1@kt]@[Host2]
Aug 01 11:13:03 : auth_check_password_send: user is: [(null)]\[test1@kt]@[Host2]
Aug 01 11:13:03 : auth_get_challenge: returning previous challenge by module netr_LogonSamLogonWithFlags (normal)
Aug 01 11:13:03 : auth_check_password_send: auth_context challenge created by netr_LogonSamLogonWithFlags
Aug 01 11:13:03 : auth_check_password_send: challenge is:
Aug 01 11:13:03 : auth_check_password_recv: sam authentication for user [(null)\test1@kt] FAILED with error NT_STATUS_NOT_FOUND, authoritative=1
Any idea? Maybe a bug in Samba? It looks to me as if some internal lookup table doesn’t work properly.
Just to finish the topic: I am very confident that this a bug in the deprecated Samba version used in the AD DC container. Let’s hope that it gets fixed in the next major release of nethserver.
In case someone has the same problem: the easiest workaround seems to be to not use AD domain accounts to authenticate the RDP users but local user accounts on the RDP server. Not very elegant, but works.
