Bug 13126 - NTLM authentications using default domain/workgroup stopped working
Summary: NTLM authentications using default domain/workgroup stopped working
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 4.5.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-08 22:38 UTC by Tim Sell
Modified: 2022-05-11 15:35 UTC (History)
3 users (show)

See Also:


Attachments
Patch for master (1.45 KB, patch)
2017-12-11 11:11 UTC, Samuel Cabrero
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Sell 2017-11-08 22:38:47 UTC
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
Comment 1 Samuel Cabrero 2017-12-11 11:11:41 UTC
Created attachment 13854 [details]
Patch for master

Proposed patch for master, also sent to samba-technical including tests.
Comment 2 Björn Jacke 2022-05-11 14:23:15 UTC
is this still an issue or is this solved?
Comment 3 Samuel Cabrero 2022-05-11 15:35:45 UTC
(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