idmap backends, clean slates and the AD DC

[Andrew Bartlett]

On Tue, 2015-03-03 at 13:54 +0100, Stefan (metze) Metzmacher wrote:
> Am 22.02.2015 um 02:18 schrieb Andrew Bartlett:
> > On Sat, 2015-02-21 at 20:05 +0000, Miguel Medalha wrote:
> >> I just came to the conclusion that the rid backend has been very much
> >> underappreciated. Too much mental inertia about how things used to be
> >> made?
> >>
> >> After strugling for two days to configure a member server against a
> >> Samba Active Directory  with the ad/RFC2307 backend, I turned to the
> >> rid backend and voil! all my problems are gone. Having to manually
> >> edit uids/gids in UNIX Attributes under RSAT does really suck! The
> >> Administrator account is never correctly mapped and setting
> >> permissions on the member server becomes a PITA. All kinds of glitches
> >> become apparent.
> >>
> >> Deterministic conversion from SID to UID rocks! Simple and elegant.
> >> Everything is working in just a few minutes. Great! More people should
> >> know about this.
> >> Just use the same ranges in all your servers and you will have
> >> consistent IDs in all machines.
> >>
> >> And for really large installations theres the autorid backend!
> >>
> >> How come this is not more widely known? Even the Samba Wiki page about
> >> the RID backend is empty! 
> > 
> > What I would like to do, if I ever get the time, energy or someone else
> > does it for me, is to have a rid backend that uses the trustPosixOffset
> > attribute, and calculates ID values just like AD claims to do for the
> > never-used POSIX subsystems. 
> 
> The sad thing is that this can't work, because it doesn't handle
> transitive trusts.

Can you describe this concern more fully?  Are you worried about
inter-forest trusts?

> What we really need are autorid backends with a global storage, one for AD
> and one for LDAP.
> 
> > If we could detect new installs, then clients and the AD DC would use
> > this new autorid_trustPosixOffset by default, but clients using rfc2307
> > would also 'just work' (minus the benefits of ID_TYPE_BOTH) as we filled
> > that in anyway.
> > 
> > Then, have an optional mode in Samba that when we create users, we fill
> > in the uidNumber value and gidNumber values with whatever the supported
> > mode on the RID master or PDC emulator AD DC would create (using the
> > FSMO master so there is only one allocator). 
> > 
> > The big challenge we have in this area is that we have existing
> > installations that we can't just change the defaults on, and so our
> > ideal solution isn't the same one we could do if we started from a blank
> > slate (cue sssd comments here). 
> > 
> > All that said, I do regret that we didn't make the rfc2307 mode the
> > default in the AD DC prior to 4.0. 
> 
> I'd really like to avoid spreading rfc2307 as much as possible...

Why is that?  

One of the things that makes idmap hard is that there is no perfect
solutions, but I'm really quite concerned that we have in the meantime
decided that simple users with simple networks can't have a good
solution out of the box either. 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150304/eead25ec/attachment.pgp>