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

Stefan (metze) Metzmacher metze at samba.org
Wed Jun 24 01:20:04 MDT 2015


Am 24.06.2015 um 08:42 schrieb Rowland Penny:
> 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 ?

I think we should just always work on the PDC role onwer (or rid master).

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150624/044fda0e/attachment.pgp>


More information about the samba-technical mailing list