Bug 10886 - Winbindd does not pull unixhomedirectory & loginshell from AD
Winbindd does not pull unixhomedirectory & loginshell from AD
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind
4.2.0rc2
All All
: P5 major
: ---
Assigned To: Samba QA Contact
Samba QA Contact
:
Depends on: 10852
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-20 13:59 UTC by Rowland Penny
Modified: 2016-08-10 03:14 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rowland Penny 2014-10-20 13:59:06 UTC
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.
Comment 1 Andrew Bartlett 2014-10-20 21:04:09 UTC
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.
Comment 2 Rowland Penny 2014-10-20 21:28:37 UTC
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.
Comment 3 Rowland Penny 2014-10-21 08:47:36 UTC
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 ??
Comment 4 Michael Adam 2014-10-21 09:05:49 UTC
(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
Comment 5 Rowland Penny 2014-10-21 09:10:45 UTC
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 ??
Comment 6 Michael Adam 2014-10-21 09:17:55 UTC
(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 ??
Comment 7 Rowland Penny 2014-10-21 09:37:40 UTC
(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.
Comment 8 Peter 2015-07-07 21:41:34 UTC
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.
Comment 9 Mike E. 2016-07-28 16:43:03 UTC
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.
Comment 10 Dewayne 2016-08-10 03:14:40 UTC
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.