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

Wed Sep 6 08:24:08 UTC 2017

>When you provision a new domain, it is set 3000000, but, seemingly,
when you run the classicupgrade it gets sets to a lower number (never
actually run a classicupgrade) based on what is in your old domain.
> Not sure what to suggest here, do you feel up to sending me (offlist)
a copy of your idmap.ldb ? 
>
>Rowland

Thank you again, Rowland, for your time.
I think that different ID ranges in my domain is ok, at lest we will
survive it, Is it desired behavior, as I assume, that getent group
cannot list Domain Admins (and other groups) without setting UNIX GID.
GPO processing is now ok, at least there is no errors of sysvolcheck
and sysvolreset.
So there is one thing I'd like to solve. Problem with
BUILTIN\Administrators, which is motive I started this discussion.
Probably there are problems also with other BUILTIN groups except
BUILTIN\Server Operators, which is mapped right.

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 cannot use samba-check-set-sysvol.sh for example.

I'm sending you idmap.ldb for inspection.

Interesting is, that in my lab domain (provisioned from scratch) was
set UNIX GID on Domain Computers and Controllers. I didn't have the
reason to set this manually...

Jiří
>>> Jiří Černý 5.9.2017 15:07 >>>
Well, we are getting somewere...;)

>It is probably 'greyed' out because no Windows tools use it or will
add it. You will probably need to use Unix tools (ldb or ldap) to
remove>them, but you can if you so wish ignore them. What you should
never do is to rely on them being there, because they may or may not be
there.Ok, I'll let it be there> You need to remove the gidNumber from
Domain Admins. If you add any GPOs to 'sysvol' (other than the two
default ones), they will be
> created in 'sysvol\DOMAIN.LOCAL\Policies\{GUID}'
> And the Sddl will be:
> 
>
O:DAG:DAD:PAI(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;ED)(A;OICI;0x1200a9;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;DA)(A;OICI;FA;;;S-1-5-21-2695348288-4157658249-429813502-519)
> 
> The important bit (as far as the Unix OS is concerned) is
'O:DAG:DA',
> which if we expand it becomes 'O:DA G:DA' 
> O = Owner
> G = Group
> DA = Domain Admins
> 
> So we can see that Domain Admins is both the owner and group of the
directory. If Domain Admins has a gidNumber it is just a group and
> 'O:DAG:DA' becomes 'O:??G:DA'Deleted. Now, I can do samba-tool ntacl
sysvolreset and samba-tool ntacl sysvolcheck without errors.Domain
Admins ID is now:getent group 'Domain Admins'
SVMETAL\domain admins:x:15655:
> It is perfectly safe to edit, in fact if you add another DC, you have
to edit it on the second DC by overwriting it with the idmap.ldb from>
the first.> > Let me have a look at the classicupgrade code and get back
to you, it shouldn't create xidNumbers like that. Speaking of which, can
you check> in idmap.ldb for the DN 'dn: CN=CONFIG'. What are
'lowerBound' and 'upperBound' set to ?
You're right, I remember dumping of that file and copying to second DC.
Interesting is, that on Samba 4.2 there was no problem about
sysvolcheck/reset:
UIDs/GIDs were absolutely same, I didn't do any changes on
them.ldbsearch -H /var/lib/samba/private/idmap.ldb | grep "dn:
CN=CONFIG" -A6 -B1
# record 8
dn: CN=CONFIG
cn: CONFIG
upperBound: 4000000
lowerBound: 15543
xidNumber: 15655
distinguishedName: CN=CONFIG
Which is very interesting, because is has same xidNumber as Domain
Admins

Jiří

On Tue, 05 Sep 2017 14:01:37 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:

> 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).
> 
> It is probably 'greyed' out because no Windows tools use it or will
add
> it. You will probably need to use Unix tools (ldb or ldap) to remove
> them, but you can if you so wish ignore them. What you should never
do
> is to rely on them being there, because they may or may not be
there.
> 
> 
> > 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.
> 
> You need to remove the gidNumber from Domain Admins. If you add any
> GPOs to 'sysvol' (other than the two default ones), they will be
> created in 'sysvol\DOMAIN.LOCAL\Policies\{GUID}'
> And the Sddl will be:
> 
>
O:DAG:DAD:PAI(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;ED)(A;OICI;0x1200a9;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;DA)(A;OICI;FA;;;S-1-5-21-2695348288-4157658249-429813502-519)
> 
> The important bit (as far as the Unix OS is concerned) is
'O:DAG:DA',
> which if we expand it becomes 'O:DA G:DA' 
> O = Owner
> G = Group
> DA = Domain Admins
> 
> So we can see that Domain Admins is both the owner and group of the
> directory. If Domain Admins has a gidNumber it is just a group and
> 'O:DAG:DA' becomes 'O:??G:DA'
> 
> 
> 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
> 
> and mine is:
> 
> 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: 3000000
> 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?
> 
> 
> 
> It is perfectly safe to edit, in fact if you add another DC, you
have
> to edit it on the second DC by overwriting it with the idmap.ldb
from
> the first.
> 
> Let me have a look at the classicupgrade code and get back to you,
it
> shouldn't create xidNumbers like that. Speaking of which, can you
check
> in idmap.ldb for the DN 'dn: CN=CONFIG'. What are 'lowerBound' and
> 'upperBound' set to ?
> 
> Rowland