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

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

On Tue, 05 Sep 2017 15:07:33 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:
> 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
> 
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