Samba4 patch for manipulating Unix attributes via ADUC

[Andrew Bartlett]

On Sun, 2012-07-15 at 16:01 +1000, Robert Colquhoun wrote:
> On Sat, Jul 14, 2012 at 10:05 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> > The issue is doing this in a distributed way that is safe on a mix of AD
> > implementations including Samba and Microsoft.
> >
> > So far, the only safe allocation mechanism is the RID allocation
> > mechanism.
> 
> Oh so need to stay 100% compatible with the microsoft implementation?
> That does make adding custom functionality needed for unix clients
> much more difficult.

We can have Samba-only behaviours, configured by options, but were
possible they should not break down totally if a Microsoft DC is
present.

> Guessing RID allocation works as their is a single master to allocate
> RIDs for the domain...its not really distributed as such is it?  

The RID master gives out pools to the other DCs to allocate from.  

> Maybe
> i have misunderstood but if you implement this is there any point
> adding uidNumber and gidNumber entries, shouldn't these values be
> calculated direct from from the user/groups sid?

That's the approach we have used so far.  On domain members,
administrators are free to configure idmap_rid for example.  That's why
I've not need a priority in allocating uidNumber values.

Of course, one of the major issues is that the DC itself can't do
idmap_rid, but that will probably be solved for the next 4.x release. 

However, sites upgrading from Samba 3.x have UID values that are not
based on the RID, so in the interim we need to have a way to store that
across the whole domain, just as the LDAP backend was shared before. 

> With RID allocaton scheme imagine there will be problems migrating
> existing samba 3 or unix users that already have a uid/gid allocated
> that could easily fall outside the RID allocated range.  Also
> sometimes unix users are created with identical uid/gid combination to
> another unix user(a sort of alias) i don't imagine AD will like that
> very much.

Indeed. 

> (Sorry if above questions are a bit ignorant, am new to this)

This area is hard - very hard, and we have made it harder for ourselves
by not being able to deploy the solutions based on the winbindd from the
Samba 3.x series.  Sadly the effort required to finish that work is on
the same order as the effort required to make the s3fs solution work (eg
looks practical, but the details need to be worked out), so it has to be
a 4.1 thing.  We just need to work out what is best in the meantime.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org