[PATCH] Check idmap config with testparm

[Michael Adam]

On 2016-12-08 at 12:14 +0000, Rowland Penny wrote:
> 
> See inline comments:
> 
> On Thu, 8 Dec 2016 12:44:44 +0100
> Michael Adam <obnox at samba.org> wrote:
> 
> > On 2016-12-08 at 10:53 +0000, Rowland Penny wrote:
> 
> > > 
> > > It sort of spun out of it being said that the 'ad' domain ranges can
> > > overlap and if you are altering idmap_ad on a domain member, you are
> > > also altering it on the AD DCs.
> > 
> > I don't think this has been said.
> 
> Not explicitly, but to get idmap_ad working on a domain member
> means adding uidNumber attributes to users in AD and this alters a
> Samba AD DC

Only if the DC is a samba DC...
Look, this whole discussion is meant to be DC-agnostic.
The idmap_ad module is just not aware. (And this is good.)

> > The idmap_ad module is merely a (read-only!) client of AD.
> > Neither does it know nor does it care how the AD admin
> > makes sure the IDs stay the same across the forest, i.e.
> > does not care about ADUC or samba-tool.
> 
> Yes, it is down to the admin, but we are being inconsistent,

How so?

> yes it is okay to use the counters that Microsoft provided in
> AD if you use ADUC, but you cannot do this if you use
> samba-tool.

That is a limitation of the samba-tool?
The idmap_ad code has nothing to do with it.

> > There is a certain situation in AD.
> > The AD admin communicates that to the Samba admin.
> > The samba admin creates a corresponding idmap config.
> > That's it.
> 
> Hang on, Samba provides the AD as well, so the 'AD admin' and the
> 'Samba admin' could be the same person.

Could be, but it is irrelevant for the  idmap_ad module.

I am artificially amplifying these lines here on purpose
so that we can see where the responsibility of one piece
of code ends and the responsibility of the other piece
of code starts.

> > > You have to give users uidNumber
> > > attributes that are inside the range you set on the domain members
> > > and if you do this, it over rides the xidNumbers in idmap.ldb on
> > > the DCs.
> > 
> > Right, when a samba AD/DC comes into play, things are getting
> > a little whacky. But the imap_ad module does not know about
> > idmap.ldb (which has been a mistake in the first place
> > if you ask me). No member should care about idmap.ldb.
> > The id-mapping on the DC itself is completely independent
> > of the id-mapping on the member.
> >
> 
> The id-mapping isn't independent of the id-mapping on a domain member,

Of course it is. 100% independent. Even the different members.
The samba admins can choose a different idmap config on each
samba domain member and dc.

> for one thing it isn't mapping, you explicitly set a UID for a user in
> AD.

Well. That is an attribute of a user object in the AD database.
It is not necessarily the Unix User ID of the corresponding user
in the underlying unix system. In oder to make a unix user of
that, you still need to do some id-mapping. This can be done
by looking at the AD Uid attributes, at an idmap ldb, or
in principle also by an idmap-rid configuration.

It may be convenient to have the mapping on the DC use the
RFC attributes from AD, but it is not necessary from an
engineering or design point of view.

This discussion has also been a continuous source of grief in
the past. Using the unix attributes is posing problems:
Last I looked they were not set automatically. There is the
conceptual problem of sychronizing in a multi-DC environment:
afaik there is no posix-master role in AD (similar to rid
master)... So i'd say better stay away from RFC on the DC.

> Also if you do give a user a uidNumber, it overrides the
> xidNumber the user has in idmap.ldb, this way users have the same ID
> everywhere.

Well, that is part of the above unfortunate historic
design. That override also creates problems, no?
The idmap.ldb is local to the DC while the AD-DB is
global. And if a user first has no AD-UID but later
gets one -- is his ID in the system changed? ... *scary*

All that being said, I am not a AD/DC developer but
a fileserver developer, so just sharing my thoughts
here. Not saying this is what the AD/DC will do
or is doing.

> > We *could* implement an id-mapping for a samba-ad-member
> > that uses certain pieces of knowledge about the samba
> > domain, but this here is not that discussion!
> 
> Totally agree on this
> 
> > 
> > > So my point is, you cannot just look at this from the point of view
> > > of idmap_ad,
> > 
> > No. We *have to* look at it only from the pov of idmap_ad.
> > Simple read-only client. Stupid. Trusting. Period. :-)
> 
> Yes it is read-only, but it affects Samba DCs

Not at all. Unless they forcefully use it.

> > > you have to look at in the round and in the round we are
> > > saying it is okay to use the 'msSFU30MaxUidnumber' &
> > > 'msSFU30MaxGidNumber' attributes if you use ADUC, but you must not
> > > use these if you use samba-tool, this is inconsistent!
> > 
> > Sorry, I don't even know what that means.
> > (Saying "it is ok or not ok to use msSFU30MaxGidNumber" ...)
> 
> If you use ADUC, the next UID & GID are stored in AD, it seems this
> is okay, but this is not allowed if you use samba-tool

Ok. Sorry, I really don't know enough about AD, but
in the explanatory sentence, msSFU30MaxGidNumber does
not appear. So I don't get the connection.

Still... Nice discussion above, but all that is on
how to do ID-mapping on a Samba AD/DC. To my understanding
not at all related to the current discussion about the
implementation of the idmap_ad module which serves its
purpose well just the way it is.

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20161208/0203298a/signature.sig>