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

[Rowland Penny]

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 had my doubts about the sssd way of doing it by using numbers, sooner 
or later, you are going to get the same number.

The way my patch works is to either use the msSFU30MaxUidNumber & 
msSFU30MaxGidNumber (just like ADUC, which by the way, is the suggested 
way to create users), or find the highest uidNumber or gidNumber in AD, 
add 1 to this and use it for the next ID number, or if nothing found, 
use 10000, again just like ADUC, there is nothing 'non-deterministic' 
about any of the values. Once you have created a user or group with my 
patch, the relevant attribute provided by Microsoft will be created and 
will be used in future.

If my patch is used, then the way users & groups are created becomes 
just like ADUC and it doesn't matter where a user (for instance) is 
created, that user will get the next uidNumber, something that may not 
happen at the moment. I personally think that what ever happens, Samba 
is going to have to work around using ADUC to create users & groups and 
this means using the msSFU30MaxUidNumber & msSFU30MaxGidNumber 
attributes, as the first time you use ADUC, they get created.

What I think needs to be understood is, just like user 
'S-1-5-21-2025076216-3455336656-3842161122-1633' isn't the same user as 
'S-1-5-21-3136187327-466447767-4953272233-1633', 'DOMAIN1\rowland' isn't 
the same user as 'DOMAIN2\rowland'

Rowland Penny