Re: [Samba] idmap config ad
- Date: Mon, 28 Jan 2019 16:16:35 +0000
- From: Rowland Penny via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] idmap config ad
On Mon, 28 Jan 2019 16:46:12 +0100
Viktor Trojanovic via samba <samba@xxxxxxxxxxxxxxx> wrote:
> On 28.01.2019 16:15, Rowland Penny via samba wrote:
> > On Mon, 28 Jan 2019 15:38:41 +0100
> > Viktor Trojanovic via samba <samba@xxxxxxxxxxxxxxx> wrote:
> >> On 28.01.2019 15:27, Rowland Penny via samba wrote:
> >>> On Mon, 28 Jan 2019 09:10:58 -0500
> >>> Sonic via samba <samba@xxxxxxxxxxxxxxx> wrote:
> >>>> Trying to use the idmap config ad on a domain member. The AD is
> >>>> an actual Windows server and when logged in the AD server
> >>>> running ADUC the NIS domain field on the UNIX attributes tab
> >>>> only shows a dash and is cannot be changed.
> >>> Does Domain Users have a gidNumber attribute containing a number
> >>> inside the 10000-99999' range ?
> >>> Do any Active directory groups have such a gidNumber ?
> >>>> Domain member is RHEL 7.6 running Samba 4.8.3.
> >>>> Pertinent part of smb.conf:
> >>>> =====================================
> >>>> [global]
> >>>> security = ADS
> >>>> workgroup = MYDOMAIN
> >>>> realm = MYDOMAIN.LOCAL
> >>>> server string = mydomain
> >>>> kerberos method = secrets and keytab
> >>>> winbind refresh tickets = yes
> >>>> idmap config * : backend = tdb
> >>>> idmap config * : range = 3000-8999
> >>>> idmap config MYDOMAIN : backend = ad
> >>>> idmap config MYDOMAIN : schema_mode = rfc2307
> >>>> idmap config MYDOMAIN : range = 10000-99999
> >>>> idmap config MYDOMAIN : unix_nss_info = yes
> >>>> vfs objects = acl_xattr
> >>>> map acl inherit = yes
> >>>> store dos attributes = yes
> >>>> =====================================
> >>>> The documentation seems to strictly point to using a Samba AD
> >>>> with the RSAT utility and here we're logged right on to the
> >>>> Windows AD using the native ADUC application.
> >>> ADUC is part of RSAT and the Samba 'ad' backend works in the same
> >>> way that the Unix Attributes tab dows.
> >>> Rowland
> >> Hi Rowland,
> >> I read this post and started wondering myself. If the DC is a
> >> Windows one, then I assume uid and gid creation is being handled
> >> automatically by Windows Server. If that's correct, then I assume
> >> the ad backend is the best one to use as the disadvantages
> >> mentioned in the wiki all disappear, leaving only advantages. So,
> >> one only had to make sure that the uids and gids created in the AD
> >> are within the range mentioned in the smb.conf. Which begs the
> >> question, is it possible to influence this?
> > It all depends on what you mean by 'automatic creation' ;-)
> > If you create a user or group on ADUC, the user is created as a
> > Windows user or group, without any rfc2307 attributes, it gets a
> > unique 'RID'. If you want a Windows user or group to be known to
> > Unix, you need to add the relevant rfc2307 attributes and make the
> > Unix aware of them (that's where Samba comes in). On ADUC, you use
> > the Unix Attributes tabs for this, you will also have to install
> > IDMU. If everything is installed correctly, you should be able to
> > add rfc2307 attributes to a user by selecting the user, right
> > clicking on the user and selecting 'Properties', you should then be
> > able to select the 'Unix Attibutes' tab and add the required
> > attributes, but they will not be added unless you set the Primary
> > group.
> > Not very automatic, is it ?
> > Rowland
> No, it's not :) I clearly mixed up a couple of things. I thought that
> the rfc2307 attributes are created by the Windows DC when in fact all
> that is created automatically is the RID.
> I'm still having a bit of a hard time figuring out when to use the
> rid backend over the ad one. Clearly, the big advantage of the ad
> backend is that everything is kept inside the AD. While this means
> you need to figure out a way how to manage the required attributes
> manually, this immensely simplifies a restore should something go
> wrong. And you don't have to worry about growth or granular control
If you use the 'ad' backend you will get the same ID everywhere
(provided smb.conf is set up correctly) and can have users with
different login shells, homedirs etc, but you will need to add the
required rfc2307 attributes to AD.
> So, with the rid backend, I don't need to manage attributes manually
> which makes things easier at the time of setting up the member server
> but apart from that, I only see disadvantages, especially if you want
> room for growth, which is why, in a production environment, I'd
> probably always stick to the ad backend.
Provided you use the same smb.conf on every Unix domain member, you
will get the same ID's, but that's it, you will have to use template
settings for the login shell & homedir and everyone will get the same
ones. You will also have different id's on Samba AD DC's.
> So, a few questions come to mind:
> - Did I miss something important?
Don't think so
> - When would you actually choose the rid backend over the ad one?
I would only use the 'rid' backend on small setup's
> - Can you mix the two, i.e. have rid on one member and ad on the
> other? I assume that, even if possible, it wouldn't make sense since
> you already went through the trouble of creating the rfc2307
> attributes, you may just as well use them on all members!
It is possible, but why bother, for the reasons you have given.
> - If you set up your member and came to the conclusion you needed the
> other backend, most likely from rid to ad, how would you switch?
The only really easy way (unless somebody knows better) would be to set
up another Unix domain using the other backend and then get your
users to 'drag & drop' from one to the other. Once all the data had
been moved, turn off the old Unix domain member.
To unsubscribe from this list go to the following URL and read the