I have seen a samba 3.4 member server failing to authenticate users. The setup is this: Samba Domain controller (samba 3.4) with ldap backend, nssldap. Samba 3.4 Member server, security = domain, allow trusted domains = no, nssldap, no winbindd running. Then a client attempt to auth on the member with domain creds fails. It can be seen that in auth/auth_util.c:make_user_info_map(), the check in line 220 for is_trusted_domain(domain) or strequal(domain, get_global_sam_name() fails and the domain is mapped to get_global_sam_name(), i.e. the machine's netbios name. This same check succeeds when samba 3.2 is used instead. (The behaviour can be circumvented by using the new (in 3.4) switch "map untrusted to domain = yes" in smb.conf, but this is just a band aid.) I have not yet reproduced this locally in order to debug this further, but the situation is worse, in that when I start winbindd, it does not recognize the workgroup as its own domain, does not list it with "wbinfo -m". wbinfo -t fails and no log.wb-DOMAIN log file is created. The strange thing is that "TESTS=member make selftest" succeeds in my current checkout. I'll mark this bug as a blocker for 3.4.1 until I can see more clearly what is going wrong. Michael
OK, I have reproduced it and found the fix. Here is the config of the member: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [global] workgroup = SAMBA security = DOMAIN netbios name = MEMBER [share] path = /data/samba/shares/share read only = No ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a very basic setup, winbindd is _not_ running. (You can either use nssldap if the dc uses the ldap passdb backend, or add all the domain users to your local passwd manually...) The join is ok.(net rpc testjoin) When I try to authenticate with domain creds, e.g. with smbclient //member/share -Uuser%pass (or smbclient -L member -Uuser%pass, or accessing the member from a joined windows box), then I get NT_STATUS_LOGON_FAILURE. It succeeds when winbindd is started though. This is different from what I wrote in the inital bug report. But in that situation I may have been too impatient. Or something else was wrong. The bug was introduced (or rather uncovered) by the addition of the new parameter "map untrusted to domain". I initially misread the patch: it _did_ change the defaul behaviour from mapping to the own domain to mapping to the host name. The check that was there since a long time was actually wrong for the member case, but when the domain was silently mapped to the workgroup name this was a no-op in this case. I'll attach the minimal patch next. Michael
Created attachment 4582 [details] Patch for master and v3-4-test. This fixes the bug.
Comment on attachment 4582 [details] Patch for master and v3-4-test. Please put it into both master and 3.4 :-) Thanks, Volker
Pushed to master. Re-assigning to Karolin for inclusion in 3.4.1. Jeremy.
Pushed, will be included in 3.4.1. Closing out bug report. Thanks!