samba - Sep 2017 - BUILTIN\Administrators - failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND

To Rowland:
> This was perfectly common, nobody thought this would ever be a
problem,mainly because you had to have a user or group in /etc/passwd>
or /etc/group mapped to a Samba. Now with AD, you do not need a user or
group in /etc/passwd or /etc/group, so any user or group that uses the
RID as a Unix ID is> probably too low and is denying the use of any
local Unix users
Yes, but where is main problem/failure? We had working Samba 3 domain
with LDAP backend. Made by documentation. We migrated to Samba 4 AD, of
course with assistance of documentation/wiki.
So there was no failure in process of migration, but it lead to ID
mapping mess which I can't fix.
> I hope you are not thinking of using GPOs, 'Domain Admins' needs to
own things is 'sysvol' and cannot if they are a group (the gidNumber
makes them a group)Of course I am thinking of using GPOs. Windows are ok
with it, because it uses SIDs. I have problems only in linux, because
bad ID mapping, respectively samba-tool ntacl sysvolcheck, because it's
expecting diferent ID numbers as I have. 
Domain Admins is group. Only deference is that in our (migrated) domain
id has objectClass top; posixgroup; group and in cleanly provisioned AD
it has only top; group.
But in both cases I see group. So I have to apologize, because I
probably don't understand you.
So if I set GID, then ID mapping in linux makes that as group, but if
it's not set, than Samba makes some "magic" and give Domain Admins
ID as
this "goup" act as user?
> If you can change the Unix IDs, then this is the way to goNot problem
there in linux side or AUDC to change it. But it doesn't like it will
help me. Now, I have all BUILTIN groups without GID, cache flushed but
now luck. Even if I removed all bad GIDs and checked possible collision
with UNIX groups. Samba doesn't give me IDs like 30000, bud something
different. Look at my sysvol:
getfacl /var/lib/samba/sysvol/
getfacl: Removing leading '/' from absolute path names
# file: var/lib/samba/sysvol/
# owner: 1037
# group: 544
user::rwx
user:10037:rwx
user:15543:r-x
user:15544:rwx
user:15554:r-x
group::rwx
group:544:rwx
group:BUILTIN\134server\040operators:r-x
group:15544:rwx
group:15554:r-x
mask::rwx
other::---
default:user::rwx
default:user:1037:rwx
default:user:15543:r-x
default:user:15544:rwx
default:user:15554:r-x
default:group::---
default:group:544:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:15544:rwx
default:group:15554:r-x
default:mask::rwx
default:other::---As you can see, there is something with 15000 + RID
pattern. Definitely from old LDAP backend. 544 are
BUILTIN\Administrators, 1037 is old UID of COMPANY\Administrator. Even
if I deleted GIDs and flushed cache it doesn't work:
wbinfo -i Administrator
COMPANY\administrator:*:0:513::/home/COMPANY/administrator:/bin/false
I am afraid that our domain is bad provisioned (upgraded) from
beginning. Is there any tool/advance, how to manually fix/change IDs in
Samba AD? And some kind of list of ID which Samba AD uses in it's "ID
magic"?
I believe that can be fixed by setting the "right" numbers.
Thank you for you help. I really appreciate it.Jiří
>>> Jiří Černý 5.9.2017 10:24 >>>
Thank you both, Rowland and Louis.

I'll try to answer you both and give you more info about our domain.

Generally:
In the past, we have Samba 3.5 NT4 domain on SLES server (designed ages
before, never upgraded). In 2015 I finally decided to migrate to Samba 4
AD. In those day it was 4.2. samba-tool ntacl sysvolcheck was ok, no
errors. AD worked (and working) as expected.
This summer, I managed Samba+ subscription from SerNet, so we upgraded
to 4.6.X. As I said, everything work, but sysvolcheck throws errors that
you discussed in other thread.

Original Samba 3 domain was combination of Samba and LDAP backed. So
domain scheme was populated by smbldap-tools. Users/groups were added by
LAM (so smbldap-tools too). UIDs/GIDs were populated by RIDs. ID map
range was from 500 to 10000, so every group and user in our domain have
UIDs/GIDs same as their RID. NSS was driven by LDAP (passwd, shadow and
group in nsswitch.conf had ldap directive).

After migration (in 2015) I changed this at least for new users and
groups. I know, that's not the best solution, but it worked I hadn't to
reset all ACLs on our fileservers.

Rowland:
Yes, our are right. There were UIDs and GIDs set on "system" users and
groups. I removed all (is removing in AUDC enough? I newer worked with
ldb tools) except Domain Users and Domain Admins (we use this group as
owner group on many shares on our fileservers).

Louis:
I thing that the "bad" numbers in my domain are legacy pro Samba 3 +
LDAP. AD service restart and net cache flush were executed many times as
we run this domain 2 years.

So what's next?
Do you think that I have to rearrange UIDs and GIDs in our domain to
match numeric pattern as in cleanly provisioned domain?


Thanks for you time. Have a nice day.


Yours sincerely
 
Jiří Černý
System administrator
 
+420 775 860 300
cerny at svmetal.cz
helpdesk at svmetal.cz
 
SV metal spol. s r.o.
Divec 99
500 03 Hradec Králové
Czech republic
 
www.svmetal.cz 

>>> Jiří Černý 4.9.2017 13:53 >>>
Hello everyone.
I'm trying to fix sysvol rights, because i see errors in output of
/usr/bin/samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception
- ProvisioningError: DB ACL on GPO directory
/var/lib/samba/sysvol/samdom.svmetal.cz/Policies/{6AC1786C-016F-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.6/site-packages/samba/netcmd/__init__.py",
line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/samba/netcmd/ntacl.py",
line
270, in run
    lp)
  File
"/usr/lib64/python2.6/site-packages/samba/provision/__init__.py", line
1723, in checksysvolacl
    direct_db_access)
  File
"/usr/lib64/python2.6/site-packages/samba/provision/__init__.py", line
1674, in check_gpos_acl
    domainsid, direct_db_access)
  File
"/usr/lib64/python2.6/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))

That's nothing new, this was disused here many times.

Today, I decided to try script
(https://github.com/thctlo/samba4/blob/master/samba-check-set-sysvol.sh)
by mr. van Belle and I ended with this error:
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-32-544 to uid

Confirmed:
wbinfo --sid-to-uid=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

So I have problem with builtin group Administrators, other groups look
good:
wbinfo --sid-to-uid=S-1-5-32-549
15543
wbinfo --sid-to-uid=S-1-5-11
15549

DB seems to be ok:
samba-tool dbcheck --cross-ncs --fix
Checking 5227 objects
Checked 5227 objects (0 errors)

Is there any way to fix my domain?

I have AD migrated from Samba 3 NT (migrated to SerNet Samba 4.2).
Running now on 2 CentOS6 DCs, SerNet Samba 4.6.7.
Here is my DS's smb.conf:
# Global parameters
[global]
 workgroup = COMPANY
 realm = samdom.company.cz
 netbios name = DC01
 server role = active directory domain controller
 idmap_ldb:use rfc2307 = yes
 dns forwarder = 192.168.1.34
 allow dns updates = nonsecure
 log level = 1
 load printers = no
 printing = bsd
 printcap name = /dev/null
 disable spoolss = yes

[netlogon]
 path = /var/lib/samba/sysvol/samdom.company.cz/scripts
 read only = No
 acl_xattr:ignore system acls = yes

[sysvol]
 path = /var/lib/samba/sysvol
 read only = No
 acl_xattr:ignore system acls = yes




Yours sincerely
 
Jiří Černý
System administrator
 
+420 775 860 300
cerny at svmetal.cz
helpdesk at svmetal.cz
 
SV metal spol. s r.o.
Divec 99
500 03 Hradec Králové
Czech republic
 
www.svmetal.cz

On Tue, 05 Sep 2017 12:22:47 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:
> To Rowland:
> > This was perfectly common, nobody thought this would ever be a
>> problem,mainly because you had to have a user or group
>> in /etc/passwd>
>> or /etc/group mapped to a Samba. Now with AD, you do not need a user
>> or group in /etc/passwd or /etc/group, so any user or group that uses
>> the RID as a Unix ID is> probably too low and is denying the use of
>> any local Unix users
> Yes, but where is main problem/failure? We had working Samba 3 domain
> with LDAP backend. Made by documentation. We migrated to Samba 4 AD,
> of course with assistance of documentation/wiki.
> So there was no failure in process of migration, but it lead to ID
> mapping mess which I can't fix.
The problem lies way back when the domain was set up. As I said,
everybody thought that using the RID as a Unix ID was an acceptable
thing to do. Hindsight has proven this wasn't such a good idea, a lot
of the RIDs are in the 500 range (including Domain Users). This means
that if you use the winbind 'ad' backend, you need to set the lower
Domain range to '500' to get any of your users known to Unix, this
means you cannot have ANY local Unix users.
 
> 
> > I hope you are not thinking of using GPOs, 'Domain Admins'
needs to
>> own things is 'sysvol' and cannot if they are a group (the
gidNumber
>> makes them a group)
> Of course I am thinking of using GPOs. Windows
> are ok with it, because it uses SIDs. I have problems only in linux,
> because bad ID mapping, respectively samba-tool ntacl sysvolcheck,
> because it's expecting diferent ID numbers as I have. 
> Domain Admins is group. Only deference is that in our (migrated)
> domain id has objectClass top; posixgroup; group and in cleanly
> provisioned AD it has only top; group.
You do not need 'posixgroup', it is an auxiliary objectclass of group,
you can add any of the rfc2307 attributes without it.
 
> But in both cases I see group. So I have to apologize, because I
> probably don't understand you.
> So if I set GID, then ID mapping in linux makes that as group, but if
> it's not set, than Samba makes some "magic" and give Domain
Admins ID
> as this "goup" act as user?
It isn't really magic, idmap on a DC works two ways, the first is when
a user or group first contacts the DC, it is given an xidNumber, this
is stored in idmap.ldb on the DC, it also set to a 'type'. This can be
'ID_TYPE_UID', 'ID_TYPE_GID' or 'ID_TYPE_BOTH', the
later means that a
group is also a user. The second way is if you give a user a uidNumber
or give a group a gidNumber, this turns off what is in idmap.ldb and
makes the user or group become just a user or group, in the case of
Domain Admins, this stops the group owning anything in 'sysvol'
> > If you can change the Unix IDs, then this is the way to goNot
> > problem
> there in linux side or AUDC to change it. But it doesn't like it will
> help me. Now, I have all BUILTIN groups without GID, cache flushed but
> now luck. Even if I removed all bad GIDs and checked possible
> collision with UNIX groups. Samba doesn't give me IDs like 30000, bud
> something different. Look at my sysvol:
> getfacl /var/lib/samba/sysvol/
> getfacl: Removing leading '/' from absolute path names
> # file: var/lib/samba/sysvol/
> # owner: 1037
> # group: 544
> user::rwx
> user:10037:rwx
> user:15543:r-x
> user:15544:rwx
> user:15554:r-x
> group::rwx
> group:544:rwx
> group:BUILTIN\134server\040operators:r-x
> group:15544:rwx
> group:15554:r-x
> mask::rwx
> other::---
> default:user::rwx
> default:user:1037:rwx
> default:user:15543:r-x
> default:user:15544:rwx
> default:user:15554:r-x
> default:group::---
> default:group:544:rwx
> default:group:BUILTIN\134server\040operators:r-x
> default:group:15544:rwx
> default:group:15554:r-x
> default:mask::rwx
> default:other::---As you can see, there is something with 15000 + RID
> pattern. Definitely from old LDAP backend. 544 are
> BUILTIN\Administrators, 1037 is old UID of COMPANY\Administrator. Even
> if I deleted GIDs and flushed cache it doesn't work:
> wbinfo -i Administrator
> COMPANY\administrator:*:0:513::/home/COMPANY/administrator:/bin/false
> I am afraid that our domain is bad provisioned (upgraded) from
> beginning. Is there any tool/advance, how to manually fix/change IDs
> in Samba AD? And some kind of list of ID which Samba AD uses in it's
> "ID magic"?
> I believe that can be fixed by setting the "right" numbers.
> Thank you for you help. I really appreciate it.Jiří
> 
Try restarting Sambaand then run 'getent group Domain\ Admins'

Rowland