idmap discussion was Re: [PATCH] Check idmap config with testparm

Rowland Penny repenny241155 at gmail.com
Thu Dec 8 15:54:59 UTC 2016


On Thu, 8 Dec 2016 16:35:11 +0100
Michael Adam <obnox at samba.org> wrote:

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

I did say 'a Samba AD DC'

> Look, this whole discussion is meant to be DC-agnostic.

I know this

> The idmap_ad module is just not aware. (And this is good.)

Again I know this 

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

Because if you use ADUC, you get to use msSFU30MaxUidNumber &
msSFU30MaxGidNumber, if you use samba-tool you don't.

It cannot be right to tell users to use ADUC and then tell them they
can also use samba-tool but they have to keep track of any uidNumbers &
gidNumbers themselves because Samba has not and will not add the
required code to samba-tool.
 
> 
> > 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?

Most definitely 

> The idmap_ad code has nothing to do with it.

Okay, I understand that

This all started by a remark about overlapping ranges and probably
should have been moved to a separate post earlier, for this I apologise.

Rowland



More information about the samba-technical mailing list