Proposal/Idea: Remove support for using rfc2307 attributes for s4 id-mapping?

simo idra at samba.org
Mon Oct 15 09:46:44 MDT 2012


On Mon, 2012-10-15 at 16:51 +0200, Michael Adam wrote:
> Hi Simo,
> 
> On 2012-10-15 at 10:25 -0400, simo wrote:
> > On Mon, 2012-10-15 at 15:17 +0200, Michael Adam wrote:
> > > Hi folks,
> > > 
> > > we have encountered several difficulties with the use
> > > of rfc2307/sfu posix attributes in our (s4) ldap for
> > > id-mapping (s4-winbind id-mapping).
> > > 
> > > I was thinking if it would not be better (meaning
> > > simpler, less error-prone) to remove support for using
> > > these SFU-style posix-attributes for our internal id-mapping.
> > > 
> > > If I understand the code correctly, the current idmapping
> > > code checks whether the sfu posix attributes for a user
> > > are present and uses them in that case, else falls back to
> > > the idmap.ldb mechanism. So from the perspective of the
> > > id mapping code this is read only. This alone seems to be
> > > calling out for trouble. If at a later time, sfu attributes
> > > are added to a user, he would change from his idmap.ldb
> > > identity to the sfu identity, unix-wise.
> > > 
> > > Also, there is no "sfu posix id pool master" fsmo role or
> > > similar, so it would be difficult to correctly handle
> > > these attributes in a multi-dc setup if we wanted to
> > > add them via some tools (like samba-tool user add ...).
> > > 
> > > Hence, I would suggest that we _remove_ the use of the sfu posix
> > > attributes from our internal id mapping on the DC again.
> > > This would re-establish the original very simple id-mapping
> > > scheme, which has its charm.
> > > 
> > > To be clear: I do not suggest to remove the sfu schema extension.
> > > We should of course keep it. And an admin can fill it, e.g. via
> > > the "Active Directory Users and Computers" dialog, but this
> > > should not be used on the DC itself but rather on external
> > > servers (like a samba member).
> > > 
> > > Am I missing something important here?
> > 
> > Sorry Michael, I think this would be a very bad mistake.
> > 
> > I actually would think we should use *only* rfc2307 attributes, as those
> > are the authoritative ones when an admin wants to use them.
> 
> I was thinking the same initially.
> A long and fruitful discussion with Matthieu and Metze
> convinced me of the opposite..
> 
> > What are the exact difficulties here ?
> 
> - We want the users in our AD to be able to acces files in the
>   shares, e.g. the sysvol share, right?

ack

> - Hence they need unix IDs (for their token SIDs).
>   These should be added automatically when users are created
>   or when users are connecting to the file server on the DC.

ack

> - While this would not be problematic in a single-DC setup,
>   we have no reliable and no official way of working with the
>   unix-ID-pool in a multi-DC setup. (There is no concept of
>   unix-ID master (fsmo) as there is for rids.)
> 
>   I know that multi-DC is not the focus for 4.0, but I am convinced
>   this will bite us quite badly later..

why is this a problem ?
if you use algorithmic mapping all you need to do is rid -> uid
and why wouldn't we do algorithmic mapping ? It's the thing that makes
the msiot sense.

> - Windows does not automatically create the posix-IDs
>   when creating users/groups. If we would, how would you
>   ensure consistency when in a multi-DC setup admins are
>   working on multiple DCs simultaneously with the user manager?

When a samba DC gets the replication of a new user it adds the
attributes if they are missing. It would be a quite simple plugin, and
if you use algorithmic mapping it doesn't matter which samba server does
it first or if multiple ones do that, they all add the same data hence
conflict resolution should have no issues when they try to replicate
back.

> - Thinking this through further: In a heterogenious environment,
>   the admin working on a windows-DC (by chance) would create
>   users that would stay locked out of the samba file server, or
>   would get fallback unix-IDs from idmap.ldb if that was still
>   enabled.

No, see above.

> - Addressing one frequent request:
>   There is no good reason I know for requiring a user/group to
>   have the same unix-ID on all DCs for a given domain.

Of course there is, you need sysvol and all shares to be consistent
across the domain for file replication, for rsyncing, for backups and
for exporting stuff via NFS if it is needed.
Allowing to have different UIDs is just begging for huge issues down the
road, we do not have to say yes to every crazy request.

>   All communication between the DCs is done via SIDs not unix-IDs.
>   With the local idmap.ldbs, this just works (tm). No need to
>   publish that extra complexity (id mapping) to the outside,
>   creating an additional DB that needs to be kept in sync.

As long as the mapping is algorithmic it is a non-issue.

> > Andrew pointed out some issues with IDAMP_BOTH as the SDC, but I think
> > we can find a method to handle idmap_both, without too much pain.
> 
> No, that was not the point I was making.
> You are right, these problems will get solved.
> 
> Have I been able to make my thoughts a little clearer?
> Am I making sense?

Sorry I do not see any of the issues you raised relevant unless we want
to keep the madness of dynamic assignment of mappings.

That was needed on member servers because we could get whatever random
SID, but on a DC we have just one domain SID and we can control ranges
and have a very simple algorithmic mapping.
Doing anything else would be a crime.
We have the chance of simplifying and make this stuff rock solid at
least for the DC case.
We have also wanted forever to have a 'standardish' way to publish unix
IDs in the classic samba DC case, we never did the unix info pipe but
always wanted to.
Now we have rfc2307 attributes that give that us for free and you want
to throw it away ? No way.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>



More information about the samba-technical mailing list