Bottom line: * We started to experience winbindd authentication problems in Samba 4.5.2. * We proved the root cause to be commit 8e88b56e (winbindd: do not modify credentials in NTLM passthrough - https://git.samba.org/?p=samba.git;a=commitdiff;h=8e88b56ebc314a5e3a722d63ca23b4a49b7ac2dc;hp=6e4c66e339d2eb11c5cb981aac2e20fcff464025). * We would like to revert that patch. Explanation follows. We are using AcceptSecurityContext() (https://msdn.microsoft.com/en-us/library/windows/desktop/aa374703(v=vs.85).aspx) in a program running in Linux under wine (https://www.winehq.org/). wine implements AcceptSecurityContext() using Samba's /usr/bin/ntlm_auth and /usr/sbin/winbindd, which of course authenticates using Samba's password database ("pdbedit -L"). Note that we have reproduced this problem both with a very old version of wine (1.5.28) and a very new version of wine (2.20). Until Samba 4.5.2, this worked perfectly. But beginning with Samba 4.5.2, our authentications stopped working, due to the behavior changed by commit 8e88b56e. Here are the new errors reported by winbindd with log level = 4: log.winbindd: [2017/11/07 16:01:21.392288, 3] ../source3/winbindd/winbindd_pam_auth_crap.c:74(winbindd_pam_auth_crap_send) [26426]: pam auth crap domain: [] user: Administrator log.wb-WORKGROUP [2017/11/07 16:01:21.392426, 3] ../source3/winbindd/winbindd_pam.c:2083(winbindd_dual_pam_auth_crap) [23995]: pam auth crap domain: user: Administrator [2017/11/07 16:01:21.394196, 3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect) ldb_wrap open of secrets.ldb [2017/11/07 16:01:21.394377, 1] ../auth/credentials/credentials_secrets.c:410(cli_credentials_set_machine_account_db_ctx) Could not find machine account in secrets database: Failed to fetch machine account password for WORKGROUP from both secrets.ldb (Could not find entry to match filter: '(&(flatname=WORKGROUP)(objectclass=primaryDomain))' base: 'cn=Primary Domains': No such object: dsdb_search at ../source4/dsdb/common/util.c:4576) and from /var/lib/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO [2017/11/07 16:01:21.394432, 3] ../source3/winbindd/winbindd_pam.c:1342(winbind_samlogon_retry_loop) Could not open handle to NETLOGON pipe (error: NT_STATUS_CANT_ACCESS_DOMAIN_INFO, attempts: 0) [2017/11/07 16:01:21.394459, 3] ../source3/winbindd/winbindd_pam.c:1372(winbind_samlogon_retry_loop) The connection to netlogon failed, retrying In a successful scenario, the first entry above under log.wb-WORKGROUP would include "WORKGROUP" as the domain, i.e.: [2017/11/07 16:01:21.392426, 3] ../source3/winbindd/winbindd_pam.c:2083(winbindd_dual_pam_auth_crap) [23995]: pam auth crap domain: WORKGROUP user: Administrator Nothing was changed in our Samba configuration; only moving from Samba 4.5.1 to Samba 4.5.2 was necessary to cause our authentications via AcceptSecurityContext() to stop working. We verified that if we reverted the commit 8e88b56e and rebuilt Samba 4.5.2 /usr/sbin/winbindd from the Samba 4.5.2 source code, that the problem was corrected. Looking at commit 8e88b56e, it appears as if we go awry in the authentication process because that patch prevents the domain name from being copied into request->data.auth_crap.domain, because the: fstrcpy(request->data.auth_crap.domain, lp_workgroup()) is no longer being done. As a result of that missing fstrcpy(), by the time we get to winbindd_dual_pam_auth_crap() in winbindd_pam.c, name_domain points to an empty string. ----- begin code snippet ----- enum winbindd_result winbindd_dual_pam_auth_crap(struct winbindd_domain *domain, struct winbindd_cli_state *state) { NTSTATUS result; struct netr_SamInfo3 *info3 = NULL; const char *name_user = NULL; const char *name_domain = NULL; const char *workstation; DATA_BLOB lm_resp, nt_resp; /* This is child-only, so no check for privileged access is needed anymore */ /* Ensure null termination */ state->request->data.auth_crap.user[sizeof(state->request->data.auth_crap.user)-1]=0; state->request->data.auth_crap.domain[sizeof(state->request->data.auth_crap.domain)-1]=0; name_user = state->request->data.auth_crap.user; name_domain = state->request->data.auth_crap.domain; workstation = state->request->data.auth_crap.workstation; DEBUG(3, ("[%5lu]: pam auth crap domain: %s user: %s\n", (unsigned long)state->pid, name_domain, name_user)); ----- end code snippet ----- winbindd_dual_pam_auth_crap() calls winbind_dual_SamLogon(). With name_domain no longer set properly, this sends into winbind_samlogon_retry_loop() instead of into winbindd_dual_auth_passdb() (which is where we ended up to do the successful username/password validation prior to commit 8e88b56e). The log entries from log.wb-WORKGROUP above show us failing in winbind_samlogon_retry_loop(). FYI, our smb.conf includes: [global] workgroup = WORKGROUP passdb backend = tdbsam log level = 4 printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User include = /etc/samba/dhcp.conf logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = Yes os level = 65 encrypt passwords = yes domain logons = yes domain master = yes wins server = wins support = no local master = yes preferred master = yes winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind trusted domains only = no nt pipe support = no
Created attachment 13854 [details] Patch for master Proposed patch for master, also sent to samba-technical including tests.
is this still an issue or is this solved?
(In reply to Björn Jacke from comment #2) Hi, AFAIK it is still an issue and the patch was wrong. It was discussed in the mailing list: https://lists.samba.org/archive/samba-technical/2017-November/123880.html