If you install an AD DC with Certificate Server and then just join a domain member, samba-gpupdate doesn't work. It fails to find the site name. [root@ip-10-0-192-159 ~]# /usr/sbin/samba-gpupdate --rsop ... Traceback (most recent call last): File "/usr/lib64/python3.9/site-packages/samba/gp/gpclass.py", line 764, in site_dn_for_machine site_name = c.netr_DsRGetSiteName(hostname) samba.WERRORError: (1210, 'WERR_INVALID_COMPUTERNAME') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/samba-gpupdate", line 131, in <module> rsop(lp, creds, store, gp_extensions, username, opts.target) File "/usr/lib64/python3.9/site-packages/samba/gp/gpclass.py", line 1041, in rsop gpos = get_gpo_list(dc_hostname, creds, lp, username) File "/usr/lib64/python3.9/site-packages/samba/gp/gpclass.py", line 869, in get_gpo_list site_dn = site_dn_for_machine(samdb, dc_hostname, lp, creds, username) File "/usr/lib64/python3.9/site-packages/samba/gp/gpclass.py", line 772, in site_dn_for_machine raise ldb.LdbError(ldb.ERR_NO_SUCH_OBJECT, _ldb.LdbError: (32, 'site_dn_for_machine: no result') signed SMB2 message (sign_algo_id=1) Do you need to manually add it? Should the code fall back to the default in this case? The current situation is bad for a user, he will probably be clueless what the issue is and what to do.
Isn't this fixed by 4486d686f5c9404acc6fff7bc67432f14cac5800? I think you just need to backport it.
Oh, I see. It's failing in the fallback case.
Check the traceback from the description, the fallback code also fails! I created a ldbsearch query from the filter of the fallback code: ldbsearch -H ldap://ad.smb.com '(cn=ip10159)' --scope=sub -b 'cn=configuration,dc=smb,dc=com' dn It doesn't return anything. If I change cn=ip10159 to cn=ad (the name of the DC) it works.
Aren't only DCs in the Site? I can only see the DC in the Default-First-Site-Name and nothing else. Why would a machine be added there. Normally it is ip address base. If you are in range you get directed to that DC.
(In reply to Andreas Schneider from comment #4) Ah, I see I missed a step in the spec. [MS-GPOL] 3.2.5.1.4 Site Search says: "This procedure is skipped if Machine Role is equal to DsRole_RoleStandaloneWorkstation or DsRole_RoleStandaloneServer". So we shouldn't make this call unless it's called from a DC, IIUC.
(In reply to David Mulder from comment #5) What exactly does 'RoleStandalone' mean in this case?
(In reply to David Mulder from comment #6) Well, this tidbit is also important: "If the method returns ERROR_NO_SITENAME, the remainder of this message MUST be skipped and the protocol sequence MUST continue at GPO Search (section 3.2.5.1.5) ." So, if we fail here, we should just skip linking GPOs by site.
Workstation could mean it is a Windows 10 workstation as a domain member, and server could mean it is a Windows Server as a domain member providing SMB. But I don't really now. You would need to ask dochelp for a clarification.
Funny thing is that it returns WERR_INVALID_COMPUTERNAME which isn't documented :-)
(In reply to Andreas Schneider from comment #9) I'm writing to dochelp now (CC'ing you and cifs-protocol). Also I'm testing a potential fix, and will upload here. We'll need to more clarification from MS to fix this properly, I think.
(In reply to Andreas Schneider from comment #9) Is this a Samba server, or Windows? I don't want to ask them why we're getting the wrong error if it isn't even coming from a Windows server ;)
(In reply to David Mulder from comment #11) David, It's a Windows Server 2022
Created attachment 18219 [details] potential fix
Windows Server 2002 root@samba1:~# rpcclient ncacn_np:earth.milkyway.site -UAdministrator rpcclient $> dsr_getsitename samba1 rpccli_netlogon_dsr_gesitename returned NT_STATUS_INVALID_COMPUTER_NAME result was WERR_INVALID_COMPUTERNAME It obviously returns a different error than documented ...
This bug was referenced in samba master: f05b61b4991e7f51bd184d76a79f8b50114a0ff3
Created attachment 18234 [details] patch for 4.19
Jule, please apply the patch to 4.19. Thanks!
Pushed to autobuild-v4-19-test.
This bug was referenced in samba v4-19-test: 445637d0f4c9aeff4f62075ea19cc2bfa5ae4fb6
Closing out bug report. Thanks!
This bug was referenced in samba v4-19-stable (Release samba-4.19.5): 445637d0f4c9aeff4f62075ea19cc2bfa5ae4fb6