Samba 4 and winbind

[Alexander Bokovoy]

On Mon, Apr 15, 2013 at 10:14 PM, Rowland Penny <repenny at f2s.com> wrote:

>  On 15/04/13 19:39, Alexander Bokovoy wrote:
>
>
>
>
> On Mon, Apr 15, 2013 at 9:11 PM, Rowland Penny <repenny at f2s.com> wrote:
>
>>   On 15/04/13 18:55, Alexander Bokovoy wrote:
>>
>>
>>
>>
>> On Mon, Apr 15, 2013 at 8:47 PM, Rowland Penny <repenny at f2s.com> wrote:
>>
>>>  On 15/04/13 18:23, Alexander Bokovoy wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Apr 15, 2013 at 7:12 PM, Rowland Penny <repenny at f2s.com> wrote:
>>>
>>>>  On 15/04/13 16:47, Jeremy Allison wrote:
>>>>
>>>>> On Mon, Apr 15, 2013 at 04:42:50PM +0100, Rowland Penny wrote:
>>>>>
>>>>>> Again, this I understand, but if Winbind was a stand alone daemon,
>>>>>> like it is with S3, then you could choose to use it or not. I
>>>>>> actually think that if there was a choice then most people would
>>>>>> choose not to use winbind due to its complexity  and inconsistency.
>>>>>>
>>>>> Oh, bitching on winbindd again. Very popular on this list it
>>>>> seems :-).
>>>>>
>>>>> If you have specific problems, please log bugs. Don't just
>>>>> try and make some specific code into the boogyman, we've
>>>>> had enough of proprietarty vendors doing that against the
>>>>> whole of Samba thanks very much, we don't need our own users
>>>>> to join in.
>>>>>
>>>>> Jeremy.
>>>>>
>>>>>
>>>>>   OK, do you really want me to log a bug that basically says that
>>>> because S3 & S4 winbinds are different and the fact that you cannot get the
>>>> same uidNumber on the server as on the clients that winbind is broken!!
>>>>
>>> Yes, I do want you to log this bug. There is no reason why winbind
>>> implementation in Samba AD DC should use unpredictable and dependent on the
>>> order of allocations high watermark algorithm.
>>>
>>>
>>>  Could you please write this again in English, specifically the last
>>> part.
>>>
>> Please file a bug about ID mapping in Samba AD DC winbind being different
>> from ID mapping in previous Samba versions.
>>
>>
>>  OK, I will file a bug, but could you please advise me what 'the order
>> of allocations high watermark algorithm' means in English, I do understand
>> it at all.
>>
>
>  If RFC2307 support is enabled, Samba AD DC will first look at uidNumber
> attribute and return that. This gives you "easy" way to get the same
> uidNumber values as in previous install -- when migrating users remember
> all UID/GIDs and assign them manually using ldb tools, for example.
>
> However, if no uidNumber attribute is available in the entry, in order to
> allocate UID/GID for a SID, Samba AD DC winbind uses an algorithm that
> remembers the last highest allocated UID/GID and increments it each time
> new request for allocating UID or GID comes. This value is global, its
> increase is independent of an order in which requests come.
>
> It has some configurable starting value A and if ID is asked for two SIDs,
> SID S-X-Y-Z-1024 first and for S-X-Y-Z-512 afterwards, the watermark would
> be A+2. If requests would come in different order, say, S-X-Y-Z-512 and
> then S-X-Y-Z-1024, the watermark will be still A+2 but IDs allocated for
> those two SIDs will be different from the first case.
>
> Thank you for explaining that, this seems to be very different from the
> way that S3 winbind works. Also have you seen how sssd are doing the
> mapping, no rfc2307 involved, they take the SID, hash the domain sid to get
> a constant number and add the rid to the end of that i.e. from your
> examples, hash S-X-Y-Z to get a number like 120140 to which is added 1024,
> you end up with 1201401024, provided you use the same sssd.conf file on the
> server & client you get the same uidNumber, but you cannot use sssd in this
> mode on the server because of the built in winbind, cifs tries to use the
> uidnumber that S4 comes up with.
>
I know how sssd does it (I'm wearing several hats, FreeIPA and Samba being
few of them).

Thanks for filing the bug, we'll see what to do with it. It is larger
problem than it looks like and requires a lot of care when fixing.

-- 
/ Alexander Bokovoy