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

[Rowland Penny]

On 24/06/15 08:20, Stefan (metze) Metzmacher wrote:
> 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
>

So, check if the DC is the PDC, if not find the PDC and connect to it 
via ldap, is this what ADUC does ?

I would like to point out, I tested this by having a ssh running in two 
terminals connected to my two DCs and a VM running Windows with ADUC 
open. I could create a user or group on any of the three and it was 
available on the others, I could create a group on one and then go to 
either of the others and add the RFC2307 attributes, it seems to work.

Here are a couple of group objects, one created with samba-tool and then 
RFC2307 attributes added by my patch, the other was created using ADUC 
and then RFC2307 added by the Unix Attributes tab, can anybody tell 
which is which ?

dn: CN=unixgroup5,CN=Users,DC=example,DC=com
objectClass: top
objectClass: group
cn: unixgroup5
instanceType: 4
whenCreated: 20150621142650.0Z
uSNCreated: 45208
name: unixgroup5
objectGUID: 580af802-72af-4ed9-a3c0-39c6c88cfbdc
objectSid: S-1-5-21-2025076216-3455336656-3842161122-2104
sAMAccountName: unixgroup5
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example,DC=com
whenChanged: 20150621142727.0Z
uSNChanged: 45210
msSFU30Name: unixgroup5
msSFU30NisDomain: home
gidNumber: 10009
distinguishedName: CN=unixgroup5,CN=Users,DC=example,DC=com

dn: CN=unixgroup2,CN=Users,DC=example,DC=com
objectClass: top
objectClass: group
cn: unixgroup2
instanceType: 4
whenCreated: 20150621142225.0Z
uSNCreated: 45204
name: unixgroup2
objectGUID: 47b0a53a-14ad-4d50-85d9-8413b73082e3
objectSid: S-1-5-21-2025076216-3455336656-3842161122-2101
sAMAccountName: unixgroup2
sAMAccountType: 268435456
groupType: -2147483646
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example,DC=com
whenChanged: 20150621143424.0Z
uSNChanged: 45211
msSFU30Name: unixgroup2
msSFU30NisDomain: home
gidNumber: 10010
distinguishedName: CN=unixgroup2,CN=Users,DC=example,DC=com


Rowland