[PATCH] samba-tool: make 'samba-tool user create' work like ADUC

Andrew Bartlett abartlet at samba.org
Tue Jun 23 16:29:44 MDT 2015


On Sun, 2015-06-21 at 09:13 +0100, Rowland Penny wrote:
> On 21/06/15 07:53, Andrew Bartlett wrote:
> > On Sat, 2015-06-20 at 15:36 +0100, Rowland Penny wrote:
> >> Hi, The basis behind this patch is to make creating a NIS user or group
> >> with samba-tool work more like ADUC
> >>
> >> With ADUC, you create the user or group and then add NIS attributes via
> >> the Unix Attributes tab.
> >> The user or group objects ID number is obtained from msSFU30MaxUidNumber
> >> or msSFU30MaxGidNumber, or the start number '10000' is used.
> > I'm sorry, but I don't agree with the assignment of non-deterministic
> > values to these attributes unless it is done on a FSMO role owner, as
> > otherwise we could see conflicts when create operations are performed on
> > a split-brain network, or simply due to replication delay.
> >
> > The reason these 'simple' approaches haven't been taken is that in a
> > multi-master replication environment, simple things are exceedingly
> > complex.
> >
> > The issue is that every option has drawbacks:
> >   - using trustPosixOffset doesn't cope with inter-forest trusts
> >   - using idmap_rid has the issue of selecting which domain is 'first'
> >   - using idmap_autorid has the issue of possible conflicts in the SID
> > portion mappings
> >   - using the sssd algorithm has similar risks (should be observable with
> > about 10 trusts on average, if I did the maths right)
> >
> > It is really hard (impossible) to compress a 128 bit (or larger) number
> > (the SID) into a 32 bit number without compromises or collisions.
> >
> > Sadly the paralysis of choice has also had a part to play - there are so
> > many different choices, all with drawbacks, that we have left our users
> > with the least useful option, but the only 'safe' one, being a local
> > counter on each DC.
> >
> > Sorry,
> >
> > Andrew Bartlett
> >
> 
> Sorry, you have lost me there, I could understand the problems if I was 
> suggesting 'mapping' the users & groups, but my patch makes samba-tool 
> work exactly like ADUC, so I suggest if you have a problem with that, 
> take it up with Microsoft!

I'm really sorry, but while we to generally go 'bug for bug' on the
server, I'm not inclined to do so in our client tools.

I'm also quite happy for us to go our own way in the UID management
department, as long as when we run with Windows DCs it doesn't actively
conflict, because Samba Domains and our users need POSIX IDs much more
than pure Windows domains.

The non-determinism is because if two users are created at the same time
on different DCs, both increments to the UID counter will conflict, one
will be overriden after replication, and two users will have uid.  That
isn't a good failure mode.  

Further, the difference between the risks here and the risks in the GUI
are that it is much more likely that a script will run concurrently
(within the replication window of 5 mins) than administrator at a GUI.

Sorry,

Andrew Bartlett


-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




More information about the samba-technical mailing list