Created attachment 18776 [details] Proposed patch We have a containerized samba file server. It is a domain member using security=domain and the "ad" backend for the domain. Being in a container, NetBIOS broadcasts don't work, and we have no WINS server or lmhosts file. Everything gets looked up over DNS and by contacting the DCs. The container runs a winbindd and an smbd process (no nmbd). This worked fine through samba 4.22.2 but broke with 4.22.3. Users could not connect to the file server, and manually running "wbinfo -i username" would return WBC_ERR_DOMAIN_NOT_FOUND. By contrast, other wbinfo commands would be fine. For example, "wbinfo -t" reports a successful connection to the domain controller, and "wbinfo -u" correctly retrieves the list of all users in the domain. Even more strangely, if the local private krb5.conf.OUR_DOMAIN_NAME file was still around from running a previous winbindd version, everything would be fine. Gowever, when run with a fresh clean /run directory, it would fail to recreate that krb.conf file. I traced the problem down to the commit that shut off DC lookups over the NETLOGON channel. It turns out that was the only mechanism for DC discovery that was working in our environment. Specifically: when winbindd is starting up, before it has created the krb5.conf file, it tries to fetch domain controllers ONLY FOR THE NETBIOS FORM OF THE DOMAIN NAME. It first tries DNS lookups, which fail because there is no domain suffix included, and then falls back to netbios. In our case, however, netbios won't work since we don't support broadcasts. I prepared the following patch, which fixes the problem on our installation as follows: when trying to discover DCs for a domain using DNS, if it fails, but the domain name being tried is the smb.conf workgroup name, retry the lookup with the realm name instead. Only fall back to the netbios mechanism if both of those fail. I'm not sure if this is the correct approach, or if some other configuration change could help in this situation ... somehow, though, the initial search for domain controllers needs to use the full realm name at some point if it's going to have any chance of working in an environment where netbios isn't usable.
You could try setting 'security = ADS' instead and come up to date, the whole world is trying to not use NetBIOS.
THANK YOU! And I feel I good deal of embarrassment at not having realized the significance of the difference between security=domain and security=ads while evolving our smb.conf file over the past several decades. There are so many places where the man pages treat them together that it was not clear to me how much "Security = domain" was trying to interoperate with both netbios and ads. That also explains why I was never able to get "disable netbios = yes" working. Perhaps an addition to the man page would be useful, in the "disable netbios" setting saying something like: "Note that disable netbios = yes is incompatible with security = domain; you must use security = ads to disable netbios on a domain member." You may want to not proceed further with this bug, then, since things do work fine with security = ads. However, if continuing, I apologize that there is an error in the patch I previously submitted (I'd had some additional debugging code that also changed the domain when processing the dcs, and forgot to incorporate it into the patch.) I will attach a revised patch. I have also adjusted the wording to clarify that this is a problem that only occurs with security=domain.
Created attachment 18778 [details] Revised patch