Hi, we have a problem where it seems that winbind is not reporting group members. Here, with Version 4.2.0pre1-GIT-f27d8b8, it works: [root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# smbd -V Version 4.2.0pre1-GIT-f27d8b8 [root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# wbinfo --group-info dept-specialcollections-digitallibrary dept-specialcollections-digitallibrary:x:14745:mmp28,gy219,hej23,jlf44,acc60,cms93 [root@stor-pri-01 /opt/src/samba42-gcc-f27d8b8]# Here, with Version 4.2.0pre1-GIT-5d22bcf it does not work: root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # smbd -V Version 4.2.0pre1-GIT-5d22bcf root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # wbinfo --group-info dept-specialcollections-digitallibrary dept-specialcollections-digitallibrary:x:14745: root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # wbinfo -r hej23 14203 10513 14755 11109 14745 14835 11107 14775 50001 root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # Notice that it does not report the group members, but it does actually know that the user is a member of the group in question. The system if FreeBSD 10.0: root@stor-pri-01:/opt/src/samba42-gcc-5d22bcf # uname -a FreeBSD stor-pri-01.ds.lib.cam.ac.uk 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun 3 13:14:57 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 The problem also presents itself with 8c3e0f8. The above is all on the exact same machine with the same smb.conf. We see the same behaviour across three different FreeBSD boxes. The same result comes out of using getent group, but then, I think that is expected to exactly match what wbinfo states. This is the nsswitch file: root@stor-pri-01:/ # cat /etc/nsswitch.conf # # nsswitch.conf(5) - name service switch configuration file # $FreeBSD: release/10.0.0/etc/nsswitch.conf 224765 2011-08-10 20:52:02Z dougb $ # group: files winbind group_compat: nis hosts: files dns networks: files passwd: files winbind passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files root@stor-pri-01:/ # This is the smb.conf [root@stor-pri-01 /]# cat /opt/samba4/etc/smb.conf [global] workgroup = CUL server string = Samba Server Version %v security = ads realm = AD.LIB.CAM.AC.UK domain master = no local master = no preferred master = no idmap config * : backend = tdb idmap config * : range = 50000-99999 idmap config CUL : backend = rid idmap config CUL : range = 10000-49999 kernel change notify = no winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind trusted domains only = no winbind nss info = rfc2307 winbind refresh tickets = yes template homedir = /home/%U template shell = /bin/sh nsupdate command = /usr/local/bin/samba-nsupdate -g client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes restrict anonymous = 2 log file = /var/log/samba4/log.%m max log size = 500 # log level = 3 unix extensions = no nt acl support = yes inherit acls = no map acl inherit = yes printing = bsd printcap name = /dev/null #============================ Share Definitions ============================== [testshare] comment = Test share path = /samba/testshare browseable = yes read only = no valid users = @"CUL+Domain Users" vfs objects = zfsacl shadow_copy2 map acl inherit = Yes store dos attributes = Yes shadow: snapdir = .zfs/snapshot shadow: sort = desc shadow: localtime = yes shadow: format = %Y%m%d [root@stor-pri-01 /]#
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. ***