[Samba] BUILTIN\Administrators - failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND

[Rowland Penny]

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