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

[Michael Adam]

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?

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

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

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

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

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

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

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20121015/d15cde74/attachment-0001.pgp>