Samba4: ID mapping is hard

[steve]

On 24/03/12 01:20, Andrew Bartlett wrote:
> On Fri, 2012-03-23 at 23:54 +0100, steve wrote:
>
>> What is working well for us in tests is giving Domain Users a uid, gid,
>> setting their primaryGroupID to that of a posix-ified security group and
>> storing these attributes in their entry in sam.ldb. The only problem I
>> have with this is that adding the posixGroup objectClass to a security
>> group removes the ability to be able to list its members in ADUC and it
>> is really unfortunate that I can't test this against a windows server.
>> Because I don't have one.
> Trial copies of Windows are available for download:
>
> https://www.microsoft.com/en-us/server-cloud/windows-server/2008-r2-trial.aspx
>
>> This is merely an inconvenience as the
>> posix-ified security group behaves exactly as if it were a normal domain
>> group. If we want point and click we can use phpldapadmin.
>>
>> So, uid gid mapping and the interoperability of domain and posix groups
>> like this is really simple. What we fear may happen is that when an
>> official s4 mapping method comes along, it will make changes to either
>> the schema or sam.ldb which will disallow our storing our attributes in
>> the directory.
> Any valid schema modification that is supported in windows will continue
> to be supported.  The schema as shipped is the official AD schema, and
> it and the implementation of the mayContains rules associated are both
> highly unlikely to change.
>
>> Are we wasting time proceding with this or does it make at least a
>> little sense? Our aim is simply to have a single sign on linux/windows.
>> As s4 does not provide an official mechanism for this at the moment we
>> invented this.
> For Linux clients, the supported solution is using Samba3's winbindd.
> Patches to modify Samba4's id mapping to internally honour the same id
> mapping behaviour of the Samba3 winbindd you deploy on clients would be
> welcome and appreciated.
>
> Binding nss_ldap directly against any AD implementation has always been
> a bad idea.  We built winbindd for this reason, and recommend it's use
> against Samba4.
Winbind with samba4 does not work (or please tell me how to do it). If I 
replace my ldap with winbind in nsswitch.conf, mappings are no longer 
under our control. We use nss-ldapd to extract the posix attributes 
directly from the s4 ldap. It's simple, 100% reliable and fast. The 
posix attributes need no manipulation as they are stored alongside the 
windows stuff under the user dn. Our fileserver on the Linux side is 
kerberized nfs which is also rock solid. nss-pam-ldapd/nslcd (not the 
old nss-ldap) just works. Why is this a bad idea? winbind seems overly 
complicated when Linux tools are already in place to do what we need. 
I'm sure I'm missing the obvious here though. Please let us not forget 
that Linux workstations are just as important on a lan as those with 
windows. Le'ts serve them equally well.

Our concern is that this method will not work for future releases of 
Samba4. Your note about the mayContain is most welcome however.

Thanks so much for taking time to explain this for us. It really does 
help put an understandable slant on s4 from an ordinary user pov.

Steve