Samba4.2rc2 compiled on Debian 7.5 and provisioned as a DC Alter smb.conf to use winbindd as on a client and restart samba create a user, give the user a uidNumber and the unixhomedirectory & loginshell attributes. give Domain users a gidNumber 'getent passwd rowland' displays this: rowland:*:10000:10000:Rowland Penny:/home/%D/%U:/bin/false on a client, compiled exactly the same, the same command returns this: rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash it would seem that winbindd on the server is either ignoring the unixHomeDirectory & loginShell attributes or not asking for them.
Correct, just as the old internal winbind did not ask for these attributes, nothing has changed with Samba 4.2. The %U and %D bug is 10852.
Thanks for confirming what I thought was the problem, actually was the problem. Can I ask what was the reasoning for not getting winbindd to pull the unixHomeDirectory & loginShell attributes, this seemed to be the biggest complaint with winbind.
OK, changed the one word in 'source3/winbindd/wb_fill_pwent.c' and recompiled, this seems to get us back to before 4.2rc2: root@debDC:~/samba-4.2.0rc2# getent passwd rowland rowland:*:10000:10000:Rowland Penny:/home/EXAMPLE/rowland:/bin/false Can I ask again, why go to all of the trouble of getting 'winbindd' to work with samba instead of 'winbind' if you haven't fixed the main problem with using 'winbind' i.e. the lack of using the rfc2307 unixHomeDirectory & loginShell attributes ??
(In reply to Rowland Penny from comment #3) > Can I ask again, why go to all of the trouble of getting 'winbindd' > to work with samba instead of 'winbind' if you haven't fixed the > main problem with using 'winbind' i.e. the lack of using the > rfc2307 unixHomeDirectory & loginShell attributes ?? That is only your perception. :-) The main problem of the s4-internal winbind is really that it does not support trusted domains and hence was the blocker for adding trust-support to s4. This blocker is removed by using winbindd. Cheers - Michael
Hi, OK I can accept the reasoning for the change use of winbind daemons, but would it have taken a lot more work to get the rfc2307 attributes to work ?? Also is there any indication when the rfc2307 attributes will be used ??
(In reply to Rowland Penny from comment #5) > Hi, OK I can accept the reasoning for the change use of > winbind daemons, but would it have taken a lot more work > to get the rfc2307 attributes to work ?? I am not certain. One major point in winbindd as of now is that the nss info can only be retrieved from AD/SFU if the id mapping is also taken from SFU. And SFU ID mapping is afaiao not suitable for the use on the dc, because it associates independent user ids and group ids to user sids and group sids respectively. Hence it can not be used with ID_TYPE_BOTH id mapping. Hence the DC can't set proper acls on the sysvol share. And one more problem with the SFU attributes: We need to set them automatically when creating a user or a group. Otherwise the user will not be able to log in, because he can't access the sysvol/netlogon shares. But automatic creation of the unix IDs is racy: There is no SFU master role in the domain, so if we have DCs, what do we do to avoid collisions? We can at least not do this in fashion that works in heterogenious domains. Just my 2 ¢. Maybe I am missing something here. Cheers - Michael > Also is there any indication when the rfc2307 attributes will be used ??
(In reply to Michael Adam from comment #6) > I am not certain. > One major point in winbindd as of now is that the > nss info can only be retrieved from AD/SFU if the > id mapping is also taken from SFU. A bit lost here, it seems to me that id mapping is being retrieved from AD/SFU > And SFU ID mapping is afaiao not suitable for the use on the dc, because > it associates independent user ids and group ids to > user sids and group sids respectively. Hence it can not > be used with ID_TYPE_BOTH id mapping. Hence the DC can't > set proper acls on the sysvol share. Never really understood how an object could be both a user and group at the same time, after all you cannot create an object in AD as both a user and a group. > And one more problem with the SFU attributes: > We need to set them automatically when creating a user > or a group. Otherwise the user will not be able to log > in, because he can't access the sysvol/netlogon shares. Can you explain your reasoning behind this, if you create a user in ADUC, it doesn't get the SFU attributes unless you go to the UNIX Attributes and add them. > But automatic creation of the unix IDs is racy: > There is no SFU master role in the domain, What about 'msSFU30MasterServerName' isn't this the SFU master ? > so if we have DCs, what do we do to avoid collisions? We can at least > not do this in fashion that works in heterogenious domains.
Is this supposed to work now that 4.2.2 is out? I'm on sernet-samba 4.2.2 as DC on Debian Jessie and it doesn't work (on said DC). Formerly, with 4.1, I used sssd on this box which was able to pull unix-home and unix-shell from the Samba AD, but the combination sssd, Debian Jessie and sernet-samba doesn't work currently because of packaging issues, unfortunately.
This bug has caused me some major headaches. Considering that this bug hasn't had any activity for over a year, I wanted to bring it to someone's attention. Please fix this. Winbind on a domain controller should act the same as it does on a member server.
It really is peculiar that winbindd behaves differently on a Samba4 DC to a Samba4 Member. For those of us that provide services on one physical machine to be required to install additional hardware or fiddle around and create a virtual machine just to install samba4 and its dependencies (121 shared libraries) to have a working file-server is contrary to the UNIX philosophy of simplicity and efficiency. Microsofts SBS is an example of responding to "consumers" needs.
the winbind is unified since some years already, this bug should be closed.