[Samba] domain member idmap wbinfo WBC_ERR_DOMAIN_NOT_FOUND

Rowland Penny rpenny at samba.org
Tue Jul 11 09:32:33 UTC 2017

On Tue, 11 Jul 2017 09:41:17 +1000
Tom Robinson via samba <samba at lists.samba.org> wrote:

> >>
> >> [global]
> >>         security = ADS
> >>         workgroup = MY.DOM
> >>         realm = DOM.MOTEC.COM.AU
> >>
> >>         log level = 1 winbind:1 idmap:1
> >>
> >>         idmap config * : backend = tdb
> >>         idmap config * : range = 3000000-3999999
> >>         idmap config MY.DOM : backend = ad
> >>         idmap config MY.DOM : schema_mode = rfc2307
> >>         idmap config MY.DOM : range = 500-10000
> >>         idmap config MY.DOM : unix_nss_info = yes
> >>

> Hi Rowland,
> Thanks for that detailed explanation. On the samba 3.6 NT Domain we
> have been using 'Domain Users' as the default group for all users. I
> checked all my 'Well Known' users via ADSIEdit on the DC and
> discovered that some of them do in fact have 'gidNumber's assigned
> (sorry for that previously misleading statement):
> Domain Users,513
> Domain Guests,514
> Domain Computers,515
> Domain Admins,512
> Administrators,544
> Account Operators,548
> Print Operators,550
> Backup Operators,551
> Replicator,552

I would remove all the gidNumbers from the above except for Domain
Users. There is also the Domain Admins problem, are you planning on
using GPOs ? If you are, can I suggest you create a new group ('Unix
Admins' ?), add this group to Domain Admins and then give your new
group a gidNumber, then use your new group instead of Domain Admins
when connecting to the Samba AD DC from Windows. The reasoning behind
this is fairly simple, Domain Admins needs to own directories in sysvol
as a user, but, if you give Domain Admins a gidNumber, it just becomes
a group and cannot do this.
One further thing, NEVER run sysvolreset, do everyting to do with
sysvol from Windows.

> This is confusing though... wbinfo reports the gidNumber for 'Domain
> Users' on the DC as 100 but on the DM as 513 (see also wbinfo -i
> output in my original post for the 'default group' assigned to users
> and below for the group query).
> DC:
> # wbinfo --group-info Domain\ Users
> MY.DOM\domain users:x:100:
> DM:
> # wbinfo --group-info Domain\ Users <--still give an error unless I
> provide the 'domain' failed to call wbcGetgrnam:
> WBC_ERR_DOMAIN_NOT_FOUND Could not get info for group Domain Users
> # wbinfo --group-info MY.DOM\\Domain\ Users
> MY.DOM\domain users:x:513:
> Why is the gidNumber 100 on the DC and 513 on the DM?

This is because 'wbinfo' goes direct to winbind and idmap works
differently on a DC compared to a Unix domain member. On a DC,
idmapping is done with idmap.ldb, this is where '100' comes from.

You can examine the contents of idmap.ldb fairly easy. Make sure that
ldb-tools is installed, then run something like this in a terminal:

ldbedit -e nano -H /your/path/to/idmap.ldb

On a Unix domain member, wbinfo will use the backend you set in
smb.conf. If you use the 'rid' backend the ID is calculated from the
RID using the lower range you set. The 'ad' backend will obtain the
uidNumber and gidNumber attributes from AD, provided they are inside
the range you set in smb.conf.

> So, given that I have a gidNumber already set on 'Domain Users' and
> that shows up on the DM side (but only if I put the domain component
> in my query),

You can add 'winbind use default domain = yes' to the smb.conf and you
will not have to use the DOMAIN.

> whey do I get the WBC_ERR_DOMAIN_NOT_FOUND error? Why
> is that happening and should I be concerned? Is that something to do
> with the gidNumber mismatch on DC/DM?

If everything else is working, I would tend to just ignore it and no it
has nothing to do with the mismatch.

> > The problem with using low ID numbers with Samba, isn't a problem
> > for Samba, up until something goes wrong. At this point, the only
> > user that will be able to login would be root, this is because you
> > will not be able to have ANY local Unix users (or groups).
> What do you mean by 'something goes wrong'? Can I expect that
> something?

Probably not, but there is always sods law. 
If something can go wrong, it will if you wait long enough ;-)

> > I hope that 'MY.DOM' is just a placeholder for your Netbios domain
> > name and your real one is just one word without dots.
> On Samba4 my actual REALM is MRC.MOTEC.COM.AU; the workgroup is set
> to MY.DOM. On samba 3.6, MY.DOM was the 'NT Domain' (workgroup
> setting in samba 3.6 smb.conf). 

This is another of of those 'seems like a good idea' things.
I think you are going to have to ignore it, unless you have any win10
clients, there have been reports that they wont join a domain with a
dot in it.

> During the classicupgrade I tried
> but couldn't change it (or did it wrong). If I can change that during
> the classicupgrade and can get some pointers on how to do that, I
> will do the classicupgrade again. I would actually prefer it to be
> something simpler like MRC.

The problem is, if you change the Netbios domain name (MY.DOM), it
becomes a new domain (as far as understand it) and you will have to
re-join all the computers and if you are going down that path, you
might as well start with a new AD domain.

> On that topic, when I joined a Windows computer to the domain I had
> to put in MY.DOM to join but now that it's joined it shows
> MRC.MOTEC.COM.AU as the domain. Which one is the real domain?

MY.DOM is the Netbios domain
MRC.MOTEC.COM.AU is the realm

They are a bit interchangeable.

> > Why do you have sssd installed, I hope you are not using it for
> > authentication in any way.
> >
> A really good question. No, I'm not using sssd and I don't even have
> it installed. The entry comes from an 'updated' nsswitch.conf
> provided through an updated package for CentOS7. It installed on the
> system as /etc/nsswitch.conf.rpmnew and I moved it into place. I will
> remove the sss entries as I don't see them as providing anything at
> this stage.

sssd has its own version of a winbind lib and could interfere with


More information about the samba mailing list