this is because winbind expand groups is set to 0 now. This is intentionally and not a bug.

See WHATSNEW.txt or - as you use an unreleased version - you might also have a look at commit 98426ad467fa64975bd9e6aa32530a2dde719035.

I guess this bug report will get a lot of duplicates. Couldn't you wait for a nicer bug number than 10835 ? ;-)

Thanks for quickly following up on that.  I have confirmed that setting winbind expand groups = 1 resolves the issue.

I do have a question, though.  In the commit message 98426ad467fa64975bd9e6aa32530a2dde719035 it states:

    Only some broken applications calculate the group memberships of
    users by traversing groups, such applications will require
    "winbind expand groups = 1".

It would seem, on the face of it, that at least on FreeBSD, getent group is one of those broken applications.  The reason this came to our attention is that a user attempted to rename a file which they did not own, but that was owned by a group they are a member of.

So my question:  Is this an indication that FreeBSD is broken in this respect, or is it just that we have failed to configure it and samba correctly?

Regards, and thanks again for the help.

Tristram

(In reply to comment #2)
> Thanks for quickly following up on that.  I have confirmed that setting winbind
> expand groups = 1 resolves the issue.
> 
> I do have a question, though.  In the commit message
> 98426ad467fa64975bd9e6aa32530a2dde719035 it states:
> 
>     Only some broken applications calculate the group memberships of
>     users by traversing groups, such applications will require
>     "winbind expand groups = 1".
> 
> It would seem, on the face of it, that at least on FreeBSD, getent group is one
> of those broken applications.  The reason this came to our attention is that a
> user attempted to rename a file which they did not own, but that was owned by a
> group they are a member of.
> 
> So my question:  Is this an indication that FreeBSD is broken in this respect,
> or is it just that we have failed to configure it and samba correctly?

What is the exact problem that you have?
Is it only the 'wbinfo --group-info' (getent group) output?
Or do you have more problems?

The problem is that the underlying operating system does not see that users are in groups which are defined for our Windows domain.   For example, we have a user, hej23, who is a member of dept-specialcollections-digitalcontent.  In a folder which is owned by that group, with group rwx, it should be possible to create a file:

$ id
uid=14203(hej23) gid=10513(domain users) groups=10513(domain users)
$ ls -la
total 43
drwxrwxr-x  5 root   dept-specialcollections-digital  5 Sep 29 14:58 .
drwxr-xr-x  3 root   wheel                            3 Sep  5 13:49 ..
drwxrwxr-x  2 ts551  dept-specialcollections-digital  2 Sep  5 13:52 t1
drwxrwxr-x+ 3 ts551  dept-specialcollections-digital  3 Sep  5 13:55 t2
drwxrwxr-x  2 hej23  dept-specialcollections-digital  2 Sep 29 14:58 t3
$ getfacl .
# file: .
# owner: root
# group: dept-specialcollections-digitalcontent
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
         everyone@:r-x---a-R-c--s:------:allow
$ touch f1
touch: f1: Permission denied

I then set winbind expand groups = 2, grab a new shell, and the file creation works.

$ testparm | grep expand
Load smb config files from /opt/samba4/etc/smb.conf
Processing section "[testshare]"
Loaded services file OK.
'winbind separator = +' might cause problems with group membership.

Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

	winbind expand groups = 2
root@stor-pri-01:/samba/testshare # su hej23
$ touch f1
$ id
uid=14203(hej23) gid=10513(domain users) groups=10513(domain users),12861(dept-specialcollections-digitalcontent),14745(dept-specialcollections-digitallibrary),14755(dept-cdd-journals),14775(dept-cdd),14777(dept-specialcollections),14835(project-voyagerreports)
$ ls -la f1
-rw-r--r--  1 hej23  dept-specialcollections-digital  0 Sep 29 15:06 f1
$ 

So, with winbind expand groups = 0, group membership really does not work for us at all.

We understand that we can (and should) set winbind expand groups = 1 or higher, but was it really your expectation that the above operations would fail?

I guess you did not authenicate but you su'ed to the user instead, right? Users that authenticate get the group memberships. Doing "su - someuser" as root is not legit. This is working for local passwd users/groups but not for users that come from external, where the local system root is not a priviledged authority. Without authentication there is no way to fully impersonate a domain user.

(In reply to comment #5)
> I guess you did not authenicate but you su'ed to the user instead, right? Users
> that authenticate get the group memberships. Doing "su - someuser" as root is
> not legit. This is working for local passwd users/groups but not for users that
> come from external, where the local system root is not a priviledged authority.
> Without authentication there is no way to fully impersonate a domain user.

Okay, I take that.  Yes, for hej23, I did su.  However, this time I have logged in as myself, and I see the same problem:

stoat:~ ts551$ ssh stor-pri-01 
Password: 
X11 forwarding request failed on channel 0
Last login: Mon Sep 29 14:53:58 2014 from 10.10.254.254
FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun  3 13:14:57 UTC 2014


$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel),10512(domain admins),10572(denied rodc password replication group),11104(dnsadmins),11107(dept-digitalservices),11108(dept-digitalservices-operations),11116(dhcp administrators),14780(local desktop administrators),14887(_ops_sudoers),14888(joke_sudoers)
$ cd /samba/testshare/t4
$ ls -la
total 17
drwxrwxr-x  2 hej23  dept-digitalservices-operations  2 Sep 29 15:43 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
$ getfacl .
# file: .
# owner: hej23
# group: dept-digitalservices-operations
            owner@:rwxp--aARWcCos:------:allow
            group@:rwxp--a-R-c--s:------:allow
         everyone@:r-x---a-R-c--s:------:allow
$ touch f1
$ ls -la f1
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ ^DConnection to stor-pri-01 closed.

Then, with winbind expand groups = 0:

stoat:~ ts551$ ssh stor-pri-01 
Password: 
X11 forwarding request failed on channel 0
Last login: Mon Sep 29 15:46:09 2014 from 10.10.254.254
FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun  3 13:14:57 UTC 2014


$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ cd /samba/testshare/t4/
$ ls -la
total 18
drwxrwxr-x  2 hej23  dept-digitalservices-operations  3 Sep 29 15:45 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ touch f2
touch: f2: Permission denied
$ 

My account on this box is not local, it comes via AD.

Regards,

Tristram

great that you can confirm that with authentication it worked there. for that other server well, you use the highly deprecated winbind use default domain option obviously, otherwise your domains users could not be in the group 0(wheel). I don't know what other config flaws there might be. I fear analyzing the configuration issues of several servers is beyond of this bug report.

Hi Bjorn,

no, I have not confirmed it working with authentication.

What I confirmed is the same mode of failure when using an authenticating user (ts551) as when I did an su to hej23.  

All of these tests have been against the same machine.  

Regards,

Tristram

(In reply to comment #8)
> Hi Bjorn,
> 
> no, I have not confirmed it working with authentication.
> 
> What I confirmed is the same mode of failure when using an authenticating user
> (ts551) as when I did an su to hej23.  
> 
> All of these tests have been against the same machine.  
> 
> Regards,
> 
> Tristram

What kind of auth do you use? The way to make it work is to use something like pam_winbind. To simulate it, you should do a

wbinfo -a <username>

and successfully log in. After that, a fresh login/su should work.

Hi Volker,

we are using pam_winbind for authentiaction on this box.  The sshd config is below.  The system one is below that.


$ cat /etc/pam.d/sshd | grep -v '#'

auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth            sufficient      pam_winbind.so          try_first_pass require_membership_of=S-1-5-21-2841595342-2583126837-4265527824-4887 debug 
auth		requisite	pam_opieaccess.so	no_warn allow_local
auth		required	pam_unix.so		no_warn try_first_pass


account		sufficient	pam_winbind.so		try_first_pass debug 
account		required	pam_nologin.so
account		required	pam_login_access.so
account		required	pam_unix.so


session         required        pam_winbind.so          debug 
session		required	pam_permit.so
session		required	/usr/local/lib/pam_mkhomedir.so	umask=0077


password	sufficient	pam_winbind.so		debug 
password	required	pam_unix.so		no_warn try_first_pass
$ cat /etc/pam.d/system | grep -v '#'

auth		sufficient	pam_opie.so		no_warn no_fake_prompts
auth		sufficient	pam_winbind.so		try_first_pass debug 
auth		requisite	pam_opieaccess.so	no_warn allow_local
auth		required	pam_unix.so		no_warn try_first_pass nullok

account		sufficient	pam_winbind.so		try_first_pass debug 
account		required	pam_login_access.so
account		required	pam_unix.so

session		required	pam_winbind.so		debug 
session		required	pam_lastlog.so		no_fail
session		required	/usr/local/lib/pam_mkhomedir.so	umask=0022

password	sufficient	pam_winbind.so		debug 
password	required	pam_unix.so		no_warn try_first_pass
$ 
 
I have done the wbinfo -a here, but I am not sure what we learn from it.  My understanding is that the pam_winbind is achieving the same thing.  By the way, without the pam_winbind entries above, I am not able to log in to this machine, so it certainly does seem to be using it.

$ wbinfo -a ts551
Enter ts551's password: 
plaintext password authentication succeeded
Enter ts551's password: 
challenge/response password authentication succeeded
$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ su ts551
$ id
uid=14632(ts551) gid=10513(domain users) groups=10513(domain users),0(wheel)
$ cd /samba/testshare/t4/
$ ls -la
total 18
drwxrwxr-x  2 hej23  dept-digitalservices-operations  3 Sep 29 15:45 .
drwxrwxr-x  6 root   dept-specialcollections-digital  7 Sep 29 15:43 ..
-rw-r--r--  1 ts551  dept-digitalservices-operations  0 Sep 29 15:45 f1
$ touch f2
touch: f2: Permission denied
$

Thanks for the retry!

Reopening, we need to implement the "getgroupmembership" nss function in winbind_nss_freebsd.c to make this work under FreeBSD.

(In reply to comment #11)
> Thanks for the retry!
> 
> Reopening, we need to implement the "getgroupmembership" nss function in
> winbind_nss_freebsd.c to make this work under FreeBSD.

Can we just copy and paste it from nsswitch/winbind_nss_netbsd.c ?

wouldn't it be better if the freebsd/netbsd code would be merged instead of doing more code copying in between those modules?

(In reply to comment #13)
> wouldn't it be better if the freebsd/netbsd code would be merged instead of
> doing more code copying in between those modules?

Not sure, what are you guys trying to reimplement, for ages I couldn't get audit of the FreeBSD ports code by any of the Samba developers. As for this function, it was added to samba 3.6 port few years ago and current samba 4.1 port has it as well:

http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup

(In reply to comment #14)
> (In reply to comment #13)
> > wouldn't it be better if the freebsd/netbsd code would be merged instead of
> > doing more code copying in between those modules?
> 
> Not sure, what are you guys trying to reimplement, for ages I couldn't get
> audit of the FreeBSD ports code by any of the Samba developers. As for this
> function, it was added to samba 3.6 port few years ago and current samba 4.1
> port has it as well:
> 
> http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup

Perfect :-)

Problem solved...

(In reply to comment #14)
> (In reply to comment #13)
> > wouldn't it be better if the freebsd/netbsd code would be merged instead of
> > doing more code copying in between those modules?
> 
> Not sure, what are you guys trying to reimplement, for ages I couldn't get
> audit of the FreeBSD ports code by any of the Samba developers. As for this
> function, it was added to samba 3.6 port few years ago and current samba 4.1
> port has it as well:
> 
> http://svnweb.freebsd.org/ports/head/net/samba41/files/patch-nsswitch__winbind_nss_freebsd.c?revision=339645&view=markup

We're not ignoring you Timur, it's just that you need to propose each change as a patch on samba-technical to get them upstream.

Apologies if you already did this *and* got ignored :-).

Please post them (or post them again), and we'll try and do better.

Cheers,

Jeremy.

Created attachment 10360 [details]
0001-nss_winbind-add-getgroupmembership-for-FreeBSD.patch

this patch is for the 4.1 and 4.2 branch

Pushed to autobuild-v4-[1|2]-test.

Pushed to both branches.
Closing out bug report.

Thanks!

*** Bug 4850 has been marked as a duplicate of this bug. ***

*** Bug 9715 has been marked as a duplicate of this bug. ***