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

Tue Sep 5 12:01:37 UTC 2017

Thank you very much for clarifying the ID mapping "magic";)

> You do not need 'posixgroup', it is an auxiliary objectclass of
group, you can add any of the rfc2307 attributes without it.
Well, is there any option to remove it? Because "posixgroup" is on
every group that was migrated from Samba 3.
And I cannot edit this attribute in ADUC (delete button is grayed).

> Try restarting Samba and then run 'getent group Domain\ Admins'
getent group Domain\ Admins
COMPANY\domain admins:x:512:

Which is expected, because it has set NIS domain and GID in ADUC. But
when I look to sysvol, I don't see Domain admins but
BUILTIN\Administrators (Domain Admins are members of this group). So I
am confused by behavior of BUILTIN groups.
I made some investigations about BUILTIN\Administrators.

Production domain (migrated from Samba 3):
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

ldbsearch -H /var/lib/samba/private/idmap.ldb | grep S-1-5-32-544 -A2
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_GID
xidNumber: 15538
distinguishedName: CN=S-1-5-32-544

Testing lab domain (provisioned from scratch):
wbinfo --sid-to-uid=S-1-5-32-544
3000003

ldbsearch -H /usr/local/samba/private/idmap.ldb | grep S-1-5-32-544
-A2
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_BOTH
xidNumber: 3000003
distinguishedName: CN=S-1-5-32-544

Almost every (except 0, 99 and 100) BUILTIN xidNumber on my migrated
domain starts with 15000. On provisioned domain it starts with 3000000.
Is that the way to fix my errors? Correct idmap.ldb to match cleanly
provisioned Samba AD? Is save to edit this file?

Jiří

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