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

Rowland Penny repenny241155 at gmail.com
Thu Jun 25 02:00:40 MDT 2015

On 25/06/15 00:37, Alexander Bokovoy wrote:
> On Wed, Jun 24, 2015 at 10:33:15PM +0100, Rowland Penny wrote:
>> On 24/06/15 22:01, Alexander Bokovoy wrote:
>>> On Wed, Jun 24, 2015 at 08:40:00PM +0100, Rowland Penny wrote:
>>>> On 24/06/15 20:20, Andrew Bartlett wrote:
>>>>> On Wed, 2015-06-24 at 08:21 +0100, Rowland Penny wrote:
>>>>>>   I feel if it is a
>>>>>> problem with my patch, then it must be a problem with ADUC as well.
>>>>> It is.  That doesn't make the situation any better however.
>>>> In that case, why are you objecting to this patch ? I personally think you
>>>> are being a bit hypocritical here, if my patch shouldn't be used, you should
>>>> also be saying 'We shouldn't advise people to use ADUC.'
>>>>> As I said, we haven't left this issue in such a difficult spot because
>>>>> there were easy answers, but because there are no easy, safe, answers.
>>>> Again, if, in the long term, there are not going to be major changes in this
>>>> area, why are you objecting to this patch ? This patch would make it easier
>>>> to add users & groups, just like ADUC, but on the command line. If or when
>>>> major changes are made (and I assume these will have to be accepted by
>>>> Microsoft), the way users & groups are added will have to be changed and a
>>>> new python script will be required, but until then, we have to work with
>>>> what we have got and do it the easiest way.
>>> Let me give you some perspective. At SambaXP we discussed with Andrew on
>>> how to ease this aspect of maintaining POSIX attributes in a Samba AD
>>> domain. In general, we agreed we want to do better than Windows in this
>>> particular area.
>>> In FreeIPA realm we have practical solution to this problem with
>>> Active Directory users, based on two features:
>>>   - FreeIPA supports ID ranges which are used to assign IDs to users and
>>>     groups, there are different types of ranges available, namely
>>>     algorithmic and manually assigned
>> This sounds very like the winbind 'rid' & 'ad' backends
> No, there is substantial difference.
> idmap_rid:
>         The Unix ID for a RID is calculated this way:
>            ID = RID - BASE_RID + LOW_RANGE_ID.
> idmap_ad:
>         The Unix ID is taken from uidNumber/gidNumber values directly and
>         filtered by the range.
> sssd-ad:
>         The ID space for the forest is split into equal slices, each for
>         the separate domain.
>         The Unix ID for a <SID,RID> pair is calculated by taking a murmurhash3 value
>         of the domain SID (32-bit integer) and then taking a modulus of
>         this value to determine a slice and final value is calculated
>         similar to idmap_rid based on the slice.
>         In case of a single domain (current Samba AD case) the slice
>         ordering will be the same on all Samba AD DCs. In case of
>         centralized allocation of the IDs (and slices) in the forest,
>         the slice ordering will stay the same too, this is why we are
>         looking at the extended LDAP control.
>>>   - FreeIPA server exposes a custom LDAP control that allows SSSD running
>>>     on a FreeIPA client to ask "what are POSIX attributes for this AD
>>>     user, addressed by name or SID?" type of questions. The answers to
>>>     this question are given by SSSD running on the FreeIPA master.
>> Hmm, 'custom control' , this probably means extending the AD
>> schema and will add something that ADUC will not be able to add.
> Existence of the LDAP control is not related to extension of the schema,
> these are orthogonal to each other.
> ADUC is not going to have support for POSIX attributes -- RSAT is already
> deprecated from Windows Server 2012R2 and will be removed in the next
> version (next year, I heard).

This is sort of what I am getting at, samba4 only supports upto windows 
2008R2, you cannot join a 2012 DC to a samba domain and next year there 
might me another version that cannot be joined.

> http://blogs.technet.com/b/activedirectoryua/archive/2015/01/25/identity-management-for-unix-idmu-is-deprecated-in-windows-server.aspx
> We'll need to add our own support for managing POSIX attributes, yes,
> but it is not required to be done in the same way as ADUC does.

I understand this, but in the meantime the only thing that exists is 
RSAT,SFU,IDMU call it what you will.

>>> In case of the algorithmic ID range assigned to AD domain, SSSD on the
>>> FreeIPA master will use a predetermined algorithm to derive uidNumber
>>> and gidNumber for AD users belonging to that domain.
>> Winbind (on a member server) already has something like this, it is called
>> idmap_rid.
> Yep, for the case of a single domain it is close to what SSSD does in
> its mapping.
>>> In case the range has been set up to provide manual assignments to each
>>> individual AD user/group, SSSD on the FreeIPA master will pick that
>>> information up from AD LDAP.
>> Not everybody wants to use sssd and is not all that long ago I
>> got told that sssd has nothing to do with Samba
> That is something that people decide for their own cases. What we'd like
> to do is to be able to interoperate rather than fragment the ID space.
>>> There is also a mechanism to override these manual assignments in
>>> FreeIPA LDAP store to allow assigning own IDs to AD users in case you
>>> cannot modify AD to support POSIX attributes or you are dealing with
>>> older ('legacy') clients which can't use SSSD. See my talk at SambaXP'15
>>> on day 3 about this specific aspect.
>>> So what this approach gives us when applied to Samba AD?
>>> Samba AD could have implementation of the same LDAP control that FreeIPA
>>> does. SSSD on clients will then be able to retrieve IDs from Samba AD
>>> LDAP for any user or group, if uidNumber/gidNumber values miss in the
>>> Samba AD LDAP for them. This retrieval attempt can be used by Samba AD
>>> LDAP to actually allocate the values automatically, using winbindd and a
>>> the same algorithm with ID ranges. The algorithm is predictive, depends
>>> on RID and domain SID, thus always producing the same ID regardless of
>>> the order of ID allocation.
>> As I said, this will probably mean extending the AD schema and
>> what if you don't want to use sssd ? This all sounds very much like
>> the winbind 'rid' backend and having
>> 'winbind use default domain = no' in smb.conf
> Not really. As I said, I don't share your opinion of sticking to AD
> schema only, neither Andrew does, at least from our discussion during
> SambaXP. We are fine to use AD schema where it is required but it
> shouldn't prevent us from improving support for POSIX clients.

Better POSIX support would be great.

> Besides that, there are reasons for not running winbindd on every
> enrolled client. I'm not going to go into details right now (it is
> 2.30am my time) but you've been here long time to notice discussions
> about that.
>>> samba-tool then could be used to allow setting up ranges and
>>> uidNumber/gidNumber with similar approach -- asking Samba AD LDAP with
>>> the same LDAP control or setting the values directly if they were
>>> specified manually.
>> Just when is this all going to happen ? samba 4 was released at
>> the end of 2012, I understand what you are talking about, but
>> winbind still doesn't work fully on the DC. I personally think there
>> are probably other things that need fixing before all of what you
>> are proposing is put into place. In the mean time, the best that
>> Samba can do is advise users to use the Windows tools because
>> their own tools aren't up to it!
> The fact that winbindd is complex is precisely one thing why we are
> talking about refactoring for long time. With reduction to a single
> winbind version in 4.2, next steps are in making possible to split up
> schannel and topology related operations from ID management so that they
> could be developed independently.
> This is what makes working on winbindd hard -- there is a body of
> knowledge about edge cases for trust-related operations that is not
> really documented other than as a code.
> Adding samba-tool support for ADUC-like functionality isn't going to
> solve it. It would create a heritage we would need to deal with later.

And that last statement says it all, you *are* going to have deal with 
the heritage domains, or are you proposing that Samba does what 
Microsoft did with NT-4 and declare every version of Samba that works as 
it does now obsolete and tell everybody they will have to use a new version.

Adding ADUC-like functionality to samba-tool isn't going to do anything 
but make it easier to create users and groups, it isn't adding *any* 
functionality above what is available on ADUC or what samba-tool already 
has (provided you have a pen & paper to keep track of last ID number used).

I am sorry, but I really think Samba is being hypocritical here by 
saying on one hand 'use ADUC to create users & groups' but on the other 
'sorry, you cannot add ADUC functionality to samba-tool'.

Rowland Penny


More information about the samba-technical mailing list