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

Alexander Bokovoy ab at samba.org
Wed Jun 24 17:37:21 MDT 2015


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).

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.

 
> >
> >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.

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.


-- 
/ Alexander Bokovoy


More information about the samba-technical mailing list