[Samba] domain member idmap wbinfo WBC_ERR_DOMAIN_NOT_FOUND

Wed Jul 12 07:11:59 UTC 2017

On Wed, 12 Jul 2017 13:41:38 +1000
Tom Robinson via samba <samba at lists.samba.org> wrote:

> 
> 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 one of the reasons why you shouldn't run
sysvolcheck/sysvolreset. If you look very closely, you will see that
there is just one letter different i.e. 'O:LAG:DAD' instead of
'O:DAG:DAD'
If you where to now run sysvolreset, you may get this fixed, but if you
have added any other GPOs, you would screw up the ACLs on these,
especially if you have given Domain Admins a gidNumber.
You can just ignore the above error.

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

Yes, quite a lot of people do, but if you are using uidNumber and
gidNumber attributes, you can use whatever range you like and these
numbers take precedence over the xidNumbers.

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

If you are going to do this, can I suggest '10000' as a starting
number, this is where ADUC (using the Unix Attributes tab) starts, I
would also renumber the groups as well.

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

In which case, you probably don't need to do a classicupgrade, you are
going to have to join the computers to the domain, so you might as well
create a new domain. You could then correct a lot of the 'old' errors,
such as 'MY.DOM'

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

I personally would dump the users and groups to a csv list, remove any
thing that shouldn't be there. Create a new AD, create the required
groups from the csv, re-create the users from the csv using a
temporary password and set the password to be changed at next login.
You could then go around the computers, joining them to the domain.