Created attachment 1896120 [details] summary and debug output from smbget testing Description of problem: Samba-client 4.15.x fails when connecting to DFS path. The debug output shows that it looks to be trying to directly access the DFS path via the domain controller which is not allowed for regular users. Previous samba-client version debug output shows it redirecting to the CIFS server for the connection which is allowed for regular users, and connections work as expected. Version-Release number of selected component (if applicable): 4.15.x How reproducible: Always fails after installing latest samba-client 4.15.x packages Steps to Reproduce: 1. Update to latest samba-client 4.15.x package 2. Try to get file using smbget via DFS path smbget -d 3 -U testuser@ourdomain smb://host-fs1/dept-development\$/filetest-database-20.5.9.zip 3. Actual results: SPNEGO login failed: The attempted logon is invalid. This is either due to a bad username or authentication information. session setup failed: NT_STATUS_LOGON_FAILURE Expected results: smb://ourdomain.com/data/Departments/Development/Files/filetest-database-20.5.9.zip Downloaded 157.77kB in 6 seconds Additional info: Workaround is to downgrade samba-client package to 4.14.x (currently 4.14.5-10).
Created attachment 1896871 [details] Updated summary and debug output from smbget testing Red Hat Support indicated that they did not support AD-joined hosts using BeyondTrust/Likewise, so I re-tested using a standalone host with the same results. The new attachment contains the data from those tests.
Hi Team, I requested Rodney some test and the behavior is the same: smbclient is not working. They reproduce the issue in a fresh and clean system, and it is failing. They can confirm that is working with older versions. As far as I understand, because I couldn't find too much information about smbclient, the command has the "-e" parameter to use kerberos, but I can't understand how to use it against their AD domain. Please, let us know if you need any additional information. Adrian Soliard Technical Support Engineer, RHCE Red Hat, Inc. Knowledgebase: https://access.redhat.com/knowledgebase Contact us: https://access.redhat.com/support/contact/
Hello, Do we have an update on his issue? Thanks, Vincent
Hello, unfortunately it is still on my waiting list. I will work on it as soon as I have time for it (after finishing currently opened task). Best regards, Pavel
This is not a dfs issue. It is an issue of smbget unable to parse UPNs.
Workaround: smbget -W DOMAIN -U user ...
It is not a UPN issue, smbget works fine with a UPN when using a direct share path, it only fails when given a DFS path (which also used to work fine with pre 4.15.x samba-client versions). I also confirmed that the latest samba-client version on RHEL 9 (4.16.4-101) still has the issue as well. Also, there is no '-W' option to smbget. There is a '-w workgroup' option, but supplying that option with smbget still fails when given a DFS path. The only "workaround" is to specify the direct path to the server where shared. As I pointed out in the original submission, the root cause appears to be "The debug output shows that it looks to be trying to directly access the DFS path via the domain controller which is not allowed for regular users. Previous samba-client version debug output shows it redirecting to the CIFS server for the connection which is allowed for regular users, and connections work as expected." I would expect that comparing the 4.14.5-10 source code to the 4.15.5-5 source code would expose what changed to break it. Rodney
This will be fixed with Samba 4.19: https://gitlab.com/samba-team/samba/-/merge_requests/3010