Samba 4 and winbind

Rowland Penny repenny at f2s.com
Mon Apr 15 13:47:45 MDT 2013


On 15/04/13 20:23, Alexander Bokovoy wrote:
>
>
>
> On Mon, Apr 15, 2013 at 10:14 PM, Rowland Penny <repenny at f2s.com 
> <mailto: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
>>     <mailto: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 <mailto: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 <mailto: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
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 
Thanks Alexander, what seems to have been missed is, that whilst the 
winbind from S3 worked in an AT pdc domain because they were all S3 
machines, it is not really up for the job against a Samba 4 AD domain, 
it is just too complex and has too many variations.
What I was trying to get across is that it would probably be better to 
put the S3 winbind to rest and come up with something better (and before 
anybody suggests, 'well you write it', can I just say 'do you want your 
lawnmower fixing'  :-) ) and remove the builtin winbind from S4.

Rowland


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the samba-technical mailing list