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

[simo]

On Mon, 2012-10-15 at 11:20 -0700, Matthieu Patou wrote:
> On 10/15/2012 08:48 AM, simo wrote:
> > On Mon, 2012-10-15 at 17:10 +0200, steve wrote:
> >> On 15/10/12 16:51, Michael Adam wrote:
> >>
> >>> - 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.
> >> It is of vital importance for those of us who have Linux clients in the
> >> domain and serve them using NFS, that uidNumber and gidNumber remain the
> >> same no matter which DC is queried. When a user or group is created, we
> >> add the necessary rfc2307 classes and attributes to AD. We bypass
> >> idmap.ldb altogether. idmap_use:rfc2307 = Yes allows us to do this.
> >>
> >> Please do not remove this excellent facility.
> >> -1 to the proposal.
> >> Cheers,
> >> Steve
> > Steve I up the ante, I wouls like to remove idmap.ldb entirely, and use
> > rfc2307 attributes as the only idmap facility (for our own
> > domain/forest).
> What about workstations ? will you also give a posix uid to them ? 
> without it GPO and any file access from the workstation won't work in a 
> pure RFC2307 world.

I don't see why not, they have a RID anyway, and if we need it we need
it.

> What about the groups used owner ? you just have to see how Andrew is 
> struggling with to understand that RFC2307 is not a good answer for this.

I am not sure what's the issue there, there is a primary Group SID, all
you need to do is to make sure the gidNumber is the corresponding GID.

What's the struggle exactly ?

> Is there a lot of persons serving NFS from a DC ?

Is there a lot of people running DCs at all ? With time demand will
come, better to be on the safe side, there isn't just NFS, that was an
example.

> Note that we could easily improve our idmap.ldb code so that when 
> allocating a UID/GID we first check in the user/group for the existence 
> of posixUID/posixGID and write down this value in our idmap.ldb.

Why do you want to duplicate stuff multiple times ?
We already have a caching tdb imdapper due to the file server, why need
more layers that could go out of sync make admin lifes miserable ?

> So it looks like rfc2307 but it's not and allow us not to have a special 
> module, because the idea is that we want to avoid having to much backend 
> for the future winbindd.

Indeed by keeping it in the rfc2307 attrs you can change winbindd at
will and will not be stuck with odious legacy stuff. You have just one
authoritative source for both the DC and the clients.
We were *dreaming* of having something like this in the samba3 NT DC
times, so I do not understand why we want to make it overly complicated
and *broken by design* now.

And if someone says 'legacy', I'll reply that we have only one chance of
cutting the cord with legacy crap, and that is when you release 4.0,
after that it will be almost impossible, so get it simple and right,
even if there are some minor use cases unsupported. It is easier to add
support for corner cases later than to fix a broken system you need to
maintain compatibility with.

Keep in mind that by using RFC2307 by default and authoritative you make
it *easier* to have mixed DCs (Samba/Windows) as clients will see the
same data regardless. If you instead make up special stuff you'll be
back to not having a default mapping that is consistent cross-domain for
*members*. And remember that most samba installs are *member clients*
and *member servers* numerically. DCs is a cool use case, but it is not
the only case and we need to look at the wider picture.

And icing on the cake our legacy samba clients/servers are already
compatible with AD+rfc2307, so you have a double-win right there.

Simo.

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