Comment 12 for bug 2027716

Revision history for this message
John Edwards (john-cornerstonelinux) wrote :

Thanks very much for the quick provision of those patched packages. Initial results look very positive.

Before installing the patched packages I could only login via RDP using local (non-domain) accounts. The Windows 10 and 11 machines running on real hardware allowed domain logins on the "console", but I suspect that as using cached info. SMB connection to files shares as a domain user also failed with "NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE".

After installing to the 4.15.13+dfsg-0ubuntu0.20.04.3~ppa1 packages from the PPA I could login without any problems via RDP to Windows 10 & 11 machines using a user account on an NT style domain, and via RDP and the VNC console on a Windows 10 virtual machine. I'm not sure if it makes any difference, but the user account used to test the logins does have local Administrator privileges and has logged into these machines before.

I did not need to repair trust relationship or leave/rejoin domain on any of these Windows machines. No problems accessing files but there was no problems before the patch either, only problems with domain trust preventing login via RDP or SMB.

After installing the patched packages there are also no more of the "Bad switch value" errors of the form:
[2023/07/17 16:48:08.936128, 1] ../../librpc/ndr/ndr.c:662(_ndr_push_error)
  ndr_push_netr_Capabilities: ndr_push_error(Bad Switch): Bad switch value 2 at librpc/gen_ndr/ndr_netlogon.c:7604

For background this is a small LAN with a few Windows machines, not all of which are regularly used. Samba is configured to operate as a Windows NT style domain (not Active Directory). User account info is stored in an replicate LDAP backend on slapd using the smbldap tools. The server is running Ubuntu release 22.04 ("focal") on amd64. Happy to provide other info if needed.

Unfortunately at the moment I don't have access to a similar network with a Samba server running on Ubuntu 22.04 or other versions, so can not test those.

I have not yet tested leaving and rejoining the domain (could try tomorrow), although this network may not be a good test as we have a known problem where a small delay in LDAP replication causes the first attempt to join the domain to fail. The machine account is created but not immediately available to for. Second attempt usually works. We only need to do this about once a year so its never been a priority to fix.