[Samba] domain member idmap wbinfo WBC_ERR_DOMAIN_NOT_FOUND

Tom Robinson tom.robinson at motec.com.au
Wed Jul 12 03:41:38 UTC 2017


On 11/07/17 19:32, Rowland Penny via samba wrote:
> 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):
>>
>> MY.DOM
>> Domain Users,513
>> Domain Guests,514
>> Domain Computers,515
>> Domain Admins,512
>>
>> BUILTIN
>> 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.

I've removed those gidNumbers as you suggested. I wasn't looking at doing a sysvolreset but thanks
for the warning/advice. I did do a samba-tool ntacl sysvolcheck just now which gave errors. Should I
be concerned about the following?

ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL
on GPO directory
/var/lib/samba/sysvol/mrc.motec.com.au/Policies/{31B2F340-016D-11D2-945F-00C04FB984F9}
O:LAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
does not match expected value
O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
from GPO object
  File "/usr/lib64/python2.7/site-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/samba/netcmd/ntacl.py", line 270, in run
    lp)
  File "/usr/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1723, in checksysvolacl
    direct_db_access)
  File "/usr/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1674, in check_gpos_acl
    domainsid, direct_db_access)
  File "/usr/lib64/python2.7/site-packages/samba/provision/__init__.py", line 1621, in check_dir_acl
    raise ProvisioningError('%s ACL on GPO directory %s %s does not match expected value %s from GPO
object' % (acl_type(direct_db_access), path, fsacl_sddl, acl))

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

Ok, this is now making more sense. Thanks for clearing that up.

I took a look in the idmap.ldb on the DC and saw the xidNumber for S-1-5-21-mydomain-513 is indeed
100. I have looked here before but didn't notice the xidNumber for 'Domain Users' before. I was
mainly looking at the xidNumbers for the 'well known' sids which start at 3000000 in my idmap.ldb.
That's why I chose the idmap config * : range = 3000000-3999999 on the DM. It's based on the
xidNumber's I found in the idmap.ldb on the DC.

Actually, those mappings still confuse me as some of them don't resolve on the DM and some do
resolve but have different IDs. I'm guessing I just don't understand the process - or has something
gone wrong (sods law?).

I wrote a little python script to iterate over all the well known sids and call wbinfo for each. On
the DC they all map to an ID (as I now understand from the idmap.ldb) but on the DM the mappings are
completely different and many of them don't map to anything. A couple of examples are:

DC:
Creator Owner,S-1-3-0,user,placeholder : placeholder in iheritable ACE
On the DC it resolves as group as well as a user. Is that something to do with the 'type:
ID_TYPE_BOTH' entry in idmap.ldb?

# wbinfo -S S-1-3-0
3000045
# wbinfo -Y S-1-3-0
3000045

Administrators,S-1-5-32-544,group,builtin
# wbinfo -S S-1-5-32-544
3000072
# wbinfo -Y S-1-5-32-544
3000072


DM:
Creator Owner,S-1-3-0 : Doesn't resolve as user on the DM. It does resolve as a group but with a
different ID to that on the DC:

# wbinfo -S S-1-3-0
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-3-0 to uid
# wbinfo -Y S-1-3-0
3000006

Administrators,S-1-5-32-544,group,builtin
# wbinfo -S S-1-5-32-544
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-32-544 to uid
# wbinfo -Y S-1-5-32-544
3000000

Interestingly if I flush the DM cache (net cache flush) these mappings come back consistently on
(i.e. 'Creator Owner' is again assigned with 3000006 and likewise Administrators=3000000).

I can see the mapping entry in the cache listing and in the various .tdb files using tdbdump but
what determines the mapped number assignment and why is it different on the DM vs DC? Does it matter
at all that they are different?

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

Thanks. This helps considerably with typing ;-)It's also fixed my getent queries:

# getent passwd auser
auser:*:592:513:Adam User:/home/auser:/bin/bash

Although for BUILTIN I still have to add the domain:
# getent group administrators
(nothing to see here - move along)

# getent group builtin\\administrators
BUILTIN\administrators:x:3000000:


>>> 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 ;-)

Well perhaps there's already something. Did you note the error above from samba-tool ntacl
sysvolcheck? I've now entertained the idea of changing the UIDs on the Samba3 NT Domain (involves a
bit of work changing POSIX ownerships but is possible to do without much disruption - most of our
permissions are grouped and GIDs start at 1000+). I could then redo the classic upgrade having the
UIDs start at 1500+.

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

So some background first and then some current info. With the samba3 NT Domain we never joined any
clients to it. At the time we set that up we had a mix of XP, Vista and  Windows 7. We couldn't deal
with the pain of so many different systems joining so we just ran all the clients in workgroup mode.
Everyone could still get their files as long as their local client password matched the samba
password. Since the passwords were in LDAP we used SSP (Self Service Password
https://ltb-project.org/documentation/self-service-password) to allow password changes. That and a
local client password change was all that was need.

So, long and short is that, apart from a couple of test joins, we didn't join any computers to the
original NT Domain. Our goal was to centralise authentication in LDAP and we achieved that for the
most part and it was better than sync'ing /etc/passwd files about the place.

With my samba4 AD DC, I have successfully joined one Windows 10 client to the domain using MY.DOM.
It's not to say that other Windows 10 clients won't give issues but the first one worked. Sods law
may play a part down the track. I have seen that before where one will work and another won't.

If I can change something to get a NetBios Domain without a 'dot' I would rather do it now than have
the pain later. Even if that means redoing the classic upgrade. We are not too far down the track at
this point.

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

One reason for doing the classicupgrade was that it will bring over all the accounts and passwords
in one hit. If there's a simple way to bring accounts and passwords into a new domain then I could
do that. See above comments regarding joining again as for us it's not really an issue.

BTW, my attempts at changing the NetBIOS domain consisted of changing the workgroup setting in the
samba3 smb.conf during the classicupgrade process. Is that the way to do it? It did create a new
domain and as I remember I got a lot of warnings:

The DOMAIN SIDs are different:
Classicupgrade using the same NetBIOS domain as samba3 NT Domain. This worked and it's what I'm
currently using:

NetBIOS Domain:        MY.DOM
DNS Domain:            mrc.motec.com.au
DOMAIN SID:            S-1-5-21-2252255531-4061614174-2474224977

Classicupgrade using a new NetBOIS Domain. This 'mostly' worked although I couldn't find any of the
exported users or groups having been imported to the new domain.

NetBIOS Domain:        MRC
DNS Domain:            mrc.motec.com.au
DOMAIN SID:            S-1-5-21-1223480024-4169635720-1150635073

During this latter upgrade I got a lot of these errors:
---8<---
Exporting groups
ldapsam_setsamgrent: 38 entries in the base!
init_group_from_ldap: Entry found for group: 512
---8<---
Inconsistent SAM -- group member uid not in our domain
Ignoring group 'Domain Admins' S-1-5-21-2252255531-4061614174-2474224977-512 listed but then not
found: Unable to enumerate group members, (-1073741596,This error indicates that the requested
operation cannot be completed due to a catastrophic media failure or an on-disk data structure
corruption.)
Severe DB error, sambaSamAccount can't miss the samba SIDattribute
---8<---
Exporting users
---8<---
sid S-1-5-21-2252255531-4061614174-2474224977-2184 does not belong to our domain
Skipping entry uid=auser,ou=Users,dc=my,dc=dom
---8<---
Exporting posix attributes
sid S-1-5-21-2252255531-4061614174-2474224977-2184 does not belong to our domain
Skipping entry uid=auser,ou=Users,dc=my,dc=dom

I noted that in all these errors the DOMAIN SID referenced is the old NT Domain as it tries to
export them and import them later to the new 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.

But not 'changeable' ;-)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba/attachments/20170712/0cb23c81/signature.sig>


More information about the samba mailing list