Bug 8598 - force user fails for active directory users
force user fails for active directory users
Status: ASSIGNED
Product: Samba 3.6
Classification: Unclassified
Component: User & Group Accounts
3.6.1
All All
: P5 normal
: ---
Assigned To: Andreas Schneider
Samba QA Contact
:
Depends on:
Blocks: 8595
  Show dependency treegraph
 
Reported: 2011-11-10 14:20 UTC by David Disseldorp
Modified: 2014-10-28 15:02 UTC (History)
6 users (show)

See Also:


Attachments
proposed patch addressing local user assumptions (1.81 KB, patch)
2011-11-10 14:32 UTC, David Disseldorp
no flags Details
proposed patch (2.48 KB, patch)
2011-11-11 15:34 UTC, David Disseldorp
no flags Details
Level 10 log showing the problem (34.08 KB, application/octet-stream)
2012-05-10 07:39 UTC, Christian Perrier
no flags Details
smb.conf for the server with the problem (1.48 KB, application/octet-stream)
2012-05-10 07:42 UTC, Christian Perrier
no flags Details
Logfile of smbd starting with David's patch (30.08 KB, text/plain)
2012-05-10 11:42 UTC, Debian samba package maintainers (PUBLIC MAILING LIST)
no flags Details
Patch for master (2.18 KB, patch)
2013-11-22 17:33 UTC, Andreas Schneider
asn: review? (vl)
asn: review? (abartlet)
Details
v4-1-test patch (39.84 KB, patch)
2014-02-05 10:00 UTC, Andreas Schneider
ddiss: review+
Details
v4-0-test patch (39.84 KB, application/octet-stream)
2014-02-05 10:08 UTC, Andreas Schneider
no flags Details
v4-0-test patch (39.56 KB, patch)
2014-02-05 10:12 UTC, Andreas Schneider
ddiss: review+
Details
v4-1-test patch (56.97 KB, patch)
2014-02-19 13:17 UTC, Andreas Schneider
no flags Details
v4-0-test patch (56.97 KB, application/octet-stream)
2014-02-19 13:19 UTC, Andreas Schneider
no flags Details
v4-1-test patch (57.02 KB, patch)
2014-02-20 10:17 UTC, Andreas Schneider
asn: review? (gd)
asn: review? (ddiss)
jra: review+
Details
v4-0-test patch (57.02 KB, patch)
2014-02-20 10:17 UTC, Andreas Schneider
asn: review? (gd)
asn: review? (ddiss)
jra: review-
Details
Full level 10 log of connection attempt (602.97 KB, text/plain)
2014-04-24 23:47 UTC, Brian Campbell
no flags Details
smb.conf from my setup (967 bytes, text/plain)
2014-04-24 23:48 UTC, Brian Campbell
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Disseldorp 2011-11-10 14:20:07 UTC
If smb.conf is configured with "force user" set to an active directory user, any attempt to connect to the share fails with:

[2011/11/07 16:25:47.071201,  3]
passdb/lookup_sid.c:1737(get_primary_group_sid)
  Forcing Primary Group to 'Domain Users' for CINDER\administrator
[2011/11/07 16:25:47.071245,  1] auth/server_info.c:391(samu_to_SamInfo3)
  The primary group domain sid(S-1-5-21-2089716213-3334164741-1685414606-513)
does not match the domain sid(S-1-5-21-1556222852-1544685173-53101980) for
CINDER\administrator(S-1-5-21-1556222852-1544685173-53101980-500)
[2011/11/07 16:25:47.071278, 10] auth/auth_util.c:636(make_server_info_pw)
  Failed to convert samu to info3: NT_STATUS_UNSUCCESSFUL
[2011/11/07 16:25:47.071307,  3] smbd/error.c:81(error_packet_set)
  error packet at smbd/reply.c(803) cmd=117 (SMBtconX) NT_STATUS_UNSUCCESSFUL

This is a regression from previous behaviour, where "force user" could be set to an active directory user.

The current force_user make_server_info_pw() code path assumes the target user
is a local user:

- unix_users_domain_name() is unconditionally added as a prefix to the username
prior to looking up the user SID.
- get_primary_group_sid() composes a group sid using get_global_sam_sid() and
DOMAIN_RID_USERS rather than the winbind mapped value, causing the domain SID
mismatch error blocking login.
Comment 1 David Disseldorp 2011-11-10 14:32:13 UTC
Created attachment 7078 [details]
proposed patch addressing local user assumptions
Comment 2 David Disseldorp 2011-11-10 16:21:38 UTC
(In reply to comment #1)
> Created attachment 7078 [details]
> proposed patch addressing local user assumptions

This patch does not fix the case where "winbind use default domain = yes" is configured, as unix_users_domain_name() prefix is still added prior to lookup.
Comment 3 David Disseldorp 2011-11-11 15:34:13 UTC
Created attachment 7090 [details]
proposed patch

The following changes since commit 17f1a97a614db4ed8292544988cb6a6cf56621d8:

  libcli/cldap: fix a crash bug in cldap_socket_recv_dgram() (bug #8593) (2011-11-10 16:31:59 +0100)

are available in the git repository at:
  git://git.samba.org/ddiss/samba.git bso8598_ad_force_user_rb1

David Disseldorp (1):
      s3-auth: fix force user for AD user

 source3/auth/auth_util.c    |   18 ++++++++----------
 source3/passdb/lookup_sid.c |    3 +--
 2 files changed, 9 insertions(+), 12 deletions(-)
Comment 4 Christian Perrier 2012-05-10 06:16:32 UTC
I've just been hit by this bug (or one of its incarnation) on one server of mine.

It was, up to now, running 3.5.8 (a backported package of mine, on Debian squeeze).

We updated it last week-end to 3.6.5 as a way to cope with latest security issue and also moved to a version that is maintained (by me) in Debian.

However, this server has users coming from two domains named "ATLAS" and "IDF", and is a member of one of the two (IDF). Users have the same logins in both domains and we use "force user" the following way in smb.conf, for their home directories:

[homes]
        comment        = Home Directories
        create mask    = 0700
        browseable     = No
        writable       = Yes
        # Permet d'arriver depuis un compte IDF ou ATLAS et que ca marche
        valid users    = IDF+%S,ATLAS+%S,%S
        force user     = IDF+%S
        force group    = IDF+dota-gg
        path           = /home/IDF/%S

Since the upgrade to 3.6.5, users couldn't reach their homes anymore, because whatever domain they were coming from, "force user" was forcing to local accounts, not to IDF+<login>. And their homes do belong to IDF+<login> not to <login> (we're using winbind  on that machine).

I tried to build 3.6.5 packages with the proposed patch but that didn't help. As this is a production server, I can have hard times reproducing that and get meaningful logs (maybe at night..:-)).

The only difference with what David reports is that domains, in my case, are NT4 domains (yes, I'm still using those beasts!).
Comment 5 Christian Perrier 2012-05-10 07:39:38 UTC
Created attachment 7542 [details]
Level 10 log showing the problem
Comment 6 Christian Perrier 2012-05-10 07:42:04 UTC
Created attachment 7543 [details]
smb.conf for the server with the problem
Comment 7 Christian Perrier 2012-05-10 07:51:18 UTC
My test case on this server:
It is member of the IDF domain. This domain trusts other domains, among these one named "ATLAS". User logins are identical in both domains.

The server runs winbind and the home for "IDF+cperrier" is /home/IDF/cperrier.

I want user "cperrier" of domain ATLAS to use //<server>/cperrier and end up in the same place than "cperrier" of domain IDF when using //<server>/cperrier

Hence the setting I have for [homes].

It works just fine in 3.5 and is plain broken in 3.6 as soon as "force user" is used. Neither IDF\cperrier not atlas\cperrier can login...

Commenting the "force user" statement allows idf\cperrier to login but, of course, atlas\cperrier just can't.

I have a full test setup ready for testing patches. A first try on David's patch wasn't successful but I did that in a hurry on a production server and will do that more quietly on my test server.

In any case, I consider this a serious enough regression for being mandatory in 3.6...:-)
Comment 8 Debian samba package maintainers (PUBLIC MAILING LIST) 2012-05-10 11:40:35 UTC
(In reply to comment #3)
> Created attachment 7090 [details]
> proposed patch

Tried this one. 

I added this patch to the 3.6.5 Debian package I use (and maintain), rebuilt, installed on my test server and, well, smbd doesn't even start..:-)
Comment 9 Debian samba package maintainers (PUBLIC MAILING LIST) 2012-05-10 11:42:40 UTC
Created attachment 7548 [details]
Logfile of smbd starting with David's patch

(send with the pkg-samba-maint account but that's still Christian Perrier speaking)
Comment 10 Karolin Seeger 2012-07-11 17:31:08 UTC
Is there a chance to get this one fixed until July 30?
Comment 11 Andreas Schneider 2013-11-21 13:03:26 UTC
The patch has been rejected cause of:

https://lists.samba.org/archive/samba-technical/2011-November/080405.html
Comment 12 Andreas Schneider 2013-11-22 11:41:35 UTC
I've bisected the 3.6 tree from current v3-6-test to the commit of 3.5.8 at I'm the 3.5.8 now. So this seems to be broken in 3.5.8 already. 

The provided information seem to be incorrect.
Comment 13 Andreas Schneider 2013-11-22 17:33:58 UTC
Created attachment 9469 [details]
Patch for master
Comment 14 Andreas Schneider 2013-11-22 17:37:50 UTC
Here is a new patch which should fix the "Here be dragons" part.

See also create_token_from_username introduced by Andrew with 1c3c5e2156d9096f60bd53a96b88c2f1001d898a
Comment 15 Andreas Schneider 2013-11-22 17:54:37 UTC
gd and I are confident that the first hunk is correct. The second hunk is probably the 'here be dragons' hunk. So we need your comment on that and if you see problem your input how to correctly fix this.
Comment 16 David Disseldorp 2013-12-05 11:16:45 UTC
For the record, commit f62683956a3b182f6a61cc7a2b4ada2e74cde243 (fail authentication for single group name which cannot be converted to sid) incorrectly refers to this bug ID.

It should instead refer to bug 10300. My mistake.
Comment 17 Andreas Schneider 2014-02-05 10:00:58 UTC
Created attachment 9642 [details]
v4-1-test patch
Comment 18 Andreas Schneider 2014-02-05 10:08:19 UTC
Created attachment 9643 [details]
v4-0-test patch
Comment 19 Andreas Schneider 2014-02-05 10:12:50 UTC
Created attachment 9644 [details]
v4-0-test patch
Comment 20 David Disseldorp 2014-02-05 18:56:20 UTC
Comment on attachment 9642 [details]
v4-1-test patch

LGTM
Comment 21 Andreas Schneider 2014-02-06 13:38:57 UTC
Karolin, please add the patches to the relevant branches. Thanks!
Comment 22 Andreas Schneider 2014-02-14 12:59:27 UTC
The patchset has a bug. I will fix it and upload a new one.
Comment 23 Andreas Schneider 2014-02-19 13:17:26 UTC
Created attachment 9696 [details]
v4-1-test patch
Comment 24 Andreas Schneider 2014-02-19 13:19:07 UTC
Created attachment 9697 [details]
v4-0-test patch
Comment 25 Andreas Schneider 2014-02-20 10:17:18 UTC
Created attachment 9699 [details]
v4-1-test patch
Comment 26 Andreas Schneider 2014-02-20 10:17:40 UTC
Created attachment 9700 [details]
v4-0-test patch
Comment 27 Jeremy Allison 2014-04-09 21:09:53 UTC
Comment on attachment 9699 [details]
v4-1-test patch

LGTM.
Comment 28 Jeremy Allison 2014-04-09 23:21:52 UTC
Comment on attachment 9700 [details]
v4-0-test patch

LGTM
Comment 29 Jeremy Allison 2014-04-09 23:22:17 UTC
Re-assigning to Karolin for inclusion in 4.0.next, 4.1.next.

Jeremy.
Comment 30 Jeremy Allison 2014-04-09 23:53:32 UTC
Comment on attachment 9700 [details]
v4-0-test patch

Ah - NAK on this one. Looks like you erroneously changed the signature for pdb_create_builtin_alias in source3/passdb/ABI/pdb-0.1.0.sigs

It should be:
source3/passdb/ABI/pdb-0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t)

not:

source3/passdb/ABI/pdb-0.1.0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t, gid_t)

So this still needs fixing up.

Jeremy.
Comment 31 Jeremy Allison 2014-04-09 23:53:54 UTC
Moving back to Andreas to fix up the 4.0.x patch.
Comment 32 Michael Adam 2014-04-22 15:14:26 UTC
(In reply to comment #30)
> Comment on attachment 9700 [details]
> v4-0-test patch
> 
> Ah - NAK on this one. Looks like you erroneously changed the signature for
> pdb_create_builtin_alias in source3/passdb/ABI/pdb-0.1.0.sigs
> 
> It should be:
> source3/passdb/ABI/pdb-0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t)
> 
> not:
> 
> source3/passdb/ABI/pdb-0.1.0.sigs:pdb_create_builtin_alias: NTSTATUS (uint32_t,
> gid_t)
> 
> So this still needs fixing up.

Well spotted!
The problem seems to be that we have the same ABI version
in 4.0 and 4.1 but different signature for 
pdb_create_builtin_alias().

Therefore, the patch from 4.1 does not work, and we need to
recreate the signatures file for 4.0.

But the question is: do we need to do anything
regarding the brokenness of the versions between
master/4.1 and 4.0 ?

Cheers - Michael
Comment 33 Brian Campbell 2014-04-24 23:45:02 UTC
I need to be able to map local users to AD users, so we can have certain services impersonate the AD users for purposes of file ownership and permissions on the server. Based on the bug description, this patch looked like what I would need, but when I tried applying the latest v4-1-test patch to 4.1.7, I get the same behavior described in the original report; the connection fails with an error about mismatched groups. In this particular test case, I have a local user "andy" with "force user = andy.liebman", an AD user.

[2014/04/24 19:41:13.675568, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name)
  lookup_name: Unix User\andy.liebman => domain=[Unix User], name=[andy.liebman]
[2014/04/24 19:41:13.675600, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name)
  lookup_name: flags = 0x073
[2014/04/24 19:41:13.676043,  5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc)
  Finding user andy.liebman
[2014/04/24 19:41:13.676089,  5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals)
  Trying _Get_Pwnam(), username as lowercase is andy.liebman
[2014/04/24 19:41:13.676124,  5, pid=3230, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals)
  Get_Pwnam_internals did find user [andy.liebman]!
[2014/04/24 19:41:13.676238, 10, pid=3230, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:1220(gid_to_sid)
  gid 16777222 -> sid S-1-5-21-832283782-3302318743-1924928875-513
[2014/04/24 19:41:13.676285,  1, pid=3230, effective(0, 0), real(0, 0), class=auth] ../source3/auth/server_info.c:550(passwd_to_SamInfo3)
  The primary group domain sid(S-1-5-21-832283782-3302318743-1924928875-513) does not match the domain sid(S-1-22-1) for andy.liebman(S-1-22-1-16777217)
[2014/04/24 19:41:13.676342,  5, pid=3230, effective(0, 0), real(0, 0)] ../lib/dbwrap/dbwrap.c:187(dbwrap_check_lock_order)
  check lock order 1 for /var/run/samba/smbXsrv_tcon_global.tdb

editshare@lmbd-ad-mstr:~$ getent passwd andy.liebman
andy.liebman:*:16777217:16777222::/home/andy.liebman:/sbin/nologin

editshare@lmbd-ad-mstr:~$ getent group mxfsamba4
mxfsamba4:x:502:editshare,_flow,brian.p.campbell,andy.liebman,brian,andy

editshare@lmbd-ad-mstr:~$ wbinfo -U 16777217
S-1-5-21-832283782-3302318743-1924928875-1133

editshare@lmbd-ad-mstr:~$ wbinfo -G 16777222
S-1-5-21-832283782-3302318743-1924928875-513

It looks like for some reason it's mapping the primary group to the user's AD primary group SID, but only mapping the user to the Unix User SID, not the AD SID.
Comment 34 Brian Campbell 2014-04-24 23:47:50 UTC
Created attachment 9869 [details]
Full level 10 log of connection attempt
Comment 35 Brian Campbell 2014-04-24 23:48:38 UTC
Created attachment 9870 [details]
smb.conf from my setup
Comment 36 Volker Lendecke 2014-04-25 14:40:15 UTC
(In reply to comment #35)
> Created attachment 9870 [details]
> smb.conf from my setup

Can you try with

force user = MYDOMAIN\andy.liebman

?

This might be one of the places where "winbind use default domain = yes" has negative effects.
Comment 37 Brian Campbell 2014-04-25 17:17:53 UTC
Adding the domain explicitly to the "force user" option had the same effect; it still tried looking up the user in the local domain, lmbd-ad-mstr, not the AD domain:

[2014/04/25 11:55:44.715034, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/share_access.c:237(user_ok_token)
  user_ok_token: share mxfsamba4_1 is ok for unix user andy
[2014/04/25 11:55:44.715108,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc)
  Finding user MYDOMAIN\andy.liebman
[2014/04/25 11:55:44.715143,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals)
  Trying _Get_Pwnam(), username as lowercase is mydomain\andy.liebman
[2014/04/25 11:55:44.971290,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals)
  Get_Pwnam_internals did find user [MYDOMAIN\andy.liebman]!
[2014/04/25 11:55:44.971368, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name)
  lookup_name: LMBD-AD-MSTR\andy.liebman => domain=[LMBD-AD-MSTR], name=[andy.liebman]
[2014/04/25 11:55:44.971400, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name)
  lookup_name: flags = 0x073
[2014/04/25 11:55:44.971431,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2014/04/25 11:55:44.971460,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/uid.c:485(push_conn_ctx)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2014/04/25 11:55:44.971486,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2014/04/25 11:55:44.971513,  5, pid=9454, effective(0, 0), real(0, 0)] ../libcli/security/security_token.c:53(security_token_debug)
  Security token: (NULL)
[2014/04/25 11:55:44.971534,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:629(debug_unix_user_token)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2014/04/25 11:55:44.971534, 10, pid=9454, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_smbpasswd.c:1293(smbpasswd_getsampwnam)
  getsampwnam (smbpasswd): search by name: andy.liebman
[2014/04/25 11:55:44.971534, 10, pid=9454, effective(0, 0), real(0, 0), class=passdb] ../source3/passdb/pdb_smbpasswd.c:238(startsmbfilepwent)

... snip failed search in smbpasswd ...

[2014/04/25 11:55:44.971829,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2014/04/25 11:55:44.971857,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:216(push_sec_ctx)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2014/04/25 11:55:44.971883,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/uid.c:485(push_conn_ctx)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2014/04/25 11:55:44.971908,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:316(set_sec_ctx)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2014/04/25 11:55:44.971933,  5, pid=9454, effective(0, 0), real(0, 0)] ../libcli/security/security_token.c:53(security_token_debug)
  Security token: (NULL)
[2014/04/25 11:55:44.971957,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/auth/token_util.c:629(debug_unix_user_token)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2014/04/25 11:55:44.972014, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/groupdb/mapping_tdb.c:272(find_map)
  failed to unpack map
[2014/04/25 11:55:44.972048, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/groupdb/mapping_tdb.c:272(find_map)
  failed to unpack map
[2014/04/25 11:55:44.972092,  4, pid=9454, effective(0, 0), real(0, 0)] ../source3/smbd/sec_ctx.c:424(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2014/04/25 11:55:44.972123, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:77(lookup_name)
  lookup_name: Unix User\andy.liebman => domain=[Unix User], name=[andy.liebman]
[2014/04/25 11:55:44.972149, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:78(lookup_name)
  lookup_name: flags = 0x073
[2014/04/25 11:55:44.973496,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:181(Get_Pwnam_alloc)
  Finding user andy.liebman
[2014/04/25 11:55:44.973578,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:120(Get_Pwnam_internals)
  Trying _Get_Pwnam(), username as lowercase is andy.liebman
[2014/04/25 11:55:44.973810,  5, pid=9454, effective(0, 0), real(0, 0)] ../source3/lib/username.c:159(Get_Pwnam_internals)
  Get_Pwnam_internals did find user [andy.liebman]!
[2014/04/25 11:55:44.973923, 10, pid=9454, effective(0, 0), real(0, 0)] ../source3/passdb/lookup_sid.c:1220(gid_to_sid)
  gid 16777222 -> sid S-1-5-21-832283782-3302318743-1924928875-513
[2014/04/25 11:55:44.973963,  1, pid=9454, effective(0, 0), real(0, 0), class=auth] ../source3/auth/server_info.c:550(passwd_to_SamInfo3)
  The primary group domain sid(S-1-5-21-832283782-3302318743-1924928875-513) does not match the domain sid(S-1-22-1) for andy.liebman(S-1-22-1-16777217)


However, per Volker's suggestion about "winbind use default domain = yes" I tried turning that off, and was able to successfully connect to the share, and got the correct SID so that ACLs now work properly. In order for it to work, I need to turn off "winbind use default domain" and provide the explicit domain in the "force user" option.

Now I need to figure out if we can work around the lack of "winbind use default domain = yes" or if we will need to find a way to get that to work, but that looks like more of a bug in "winbind use default domain" than in this patch.