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

Rowland Penny repenny241155 at gmail.com
Wed Jun 24 00:42:54 MDT 2015

On 23/06/15 23:29, Andrew Bartlett wrote:
> 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.

This isn't a bug as such, I see it as an enhancement.

> 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.

This would help with creating/adding POSIX IDs.

> 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.

This could happen if only ADUC was used, so what you seem to be 
suggesting is, don't use ADUC either.

> 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.

How about if I could force immediate replication of the object and the 
msSFU30Max*idNumber attribute ?

> Sorry,
> Andrew Bartlett


More information about the samba-technical mailing list