samba - Nov 2022 - samba crashes windows explorer (while trying to view file permissions)

On 19/11/2022 14:16, Michael Tokarev via samba wrote:
> ...
> 
> So, this boils down to, so far:
> 
> This (problematic, fresh) domain:
> 
> # wbinfo -s S-1-5-21-880456541-1649917288-23935232-513
> PZ\Domain Users 2
> # wbinfo -Y S-1-5-21-880456541-1649917288-23935232-513
> failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-21-880456541-1649917288-23935232-513 to gid
> 
> On another, working, domain:
> 
> # wbinfo -s S-1-5-21-411424318-379842365-2075518510-513
> TLS\Domain Users 2
> # wbinfo -Y S-1-5-21-411424318-379842365-2075518510-513
> 100
> 
> idmap.ldb seems to be having similar information (besides
> the domain sid ofcourse)
> 
> 
> and now.. after quite some time, without me doing anything,
> it shows (on the bad domain):
> 
> # wbinfo -Y S-1-5-21-880456541-1649917288-23935232-513
> 3004
> 
> I think this comes from my attempts to add something in
> there:
> 
> #?????? idmap config * : backend = tdb
> #?????? idmap config * : range = 3000-3099
> 
> which I commented out quite some time ago. Or not - I recreated
> the domain with these commented out, so it is again unclear
> where it got the 3000 number from.
Neither have I, the 'idmap config' lines, up until now, have never 
worked on a DC, but something could have changed and I suppose they 
could have started working, but if they have, it will be a
bug.
> 
> But still (different id, 512 instead of 513):
> 
> # wbinfo -Y S-1-5-21-880456541-1649917288-23935232-512
> failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-21-880456541-1649917288-23935232-512 to gid
Ah, '512' is Domain Admins and you definitely do not want that group to 
have a 'GID'. It needs to 'own' things in Sysvol and to do this,
it is
mapped to 'ID_TYPE_BOTH' in idmap.ldb (that is,it is both a group and a 
user) and if you give it a gidNumber attribute, it becomes just a group 
and you break Sysvol.
> 
> What Is Going On?
> 
> Does anyone know if this beast *ever* work? This is a
> *fresh* domain, just created...
> 
> /mjt
> 
I do not know if your 'beast' has ever worked correctly, but it should
do.

I suggest you compare your working DC with your non working DC and see 
if something is different.

Rowland

19.11.2022 18:35, Rowland Penny via samba wrote:
...
>> and now.. after quite some time, without me doing anything,
>> it shows (on the bad domain):
>>
>> # wbinfo -Y S-1-5-21-880456541-1649917288-23935232-513
>> 3004
>>
>> I think this comes from my attempts to add something in
>> there:
>>
>> #?????? idmap config * : backend = tdb
>> #?????? idmap config * : range = 3000-3099
>>
>> which I commented out quite some time ago. Or not - I recreated
>> the domain with these commented out, so it is again unclear
>> where it got the 3000 number from.
> 
> Neither have I, the 'idmap config' lines, up until now, have never
worked on a DC, but something could have changed and I suppose they could have
> started working, but if they have, it will be a bug.
These lines has been commented out at the time when I re-created
the domain.

I can't find where this 3004 number comes from.  I can't find it
neither in winbindd_cahe.tdb nor in idmap.ldb.

I checked a few other SIDs:

# wbinfo -Y S-1-5-21-880456541-1649917288-23935232-512
failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-880456541-1649917288-23935232-512 to gid
# wbinfo -Y S-1-5-21-880456541-1649917288-23935232-513
3004
# wbinfo -Y S-1-5-21-880456541-1649917288-23935232-514
3000013
# wbinfo -Y S-1-5-21-880456541-1649917288-23935232-515
failed to call wbcSidToGid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-880456541-1649917288-23935232-515 to gid

The same question arises: WHAT IS GOING ON? Where it is getting
these numbers from?  Once again: it is a freshly created domain!

Okay.

# fgrep -r 3000013 /var/lib/samba/
grep: /var/lib/samba/private/idmap.ldb: binary file matches

# record 10
dn: CN=S-1-5-21-880456541-1649917288-23935232-514
cn: S-1-5-21-880456541-1649917288-23935232-514
objectClass: sidMap
objectSid: S-1-5-21-880456541-1649917288-23935232-514
type: ID_TYPE_BOTH
xidNumber: 3000013
distinguishedName: CN=S-1-5-21-880456541-1649917288-23935232-514

So it *did* configure this one automatically.  But why not the others?

# fgrep -r 3004 /var/lib/samba/
grep: /var/lib/samba/private/sam.ldb.d/DC=PZ,DC=CORPIT,DC=RU.ldb: binary file
matches
grep:
/var/lib/samba/private/sam.ldb.d/CN=CONFIGURATION,DC=PZ,DC=CORPIT,DC=RU.ldb:
binary file matches

Okay, it was actually my experiment to add uidNumber for "Domain
Users" group.
After some time (and multiple net cache flush runs) it finally get this info.

...
> Ah, '512' is Domain Admins and you definitely do not want that
group to have a 'GID'. It needs to 'own' things in Sysvol and to
do this, it is mapped
> to 'ID_TYPE_BOTH' in idmap.ldb (that is,it is both a group and a
user) and if you give it a gidNumber attribute, it becomes just a group and you
break
> Sysvol.
To me it looks like I *have* to assign a gidNumber, or else it doesn't work
-
see above.  For Domain Users group, to which I assigned 3004 uidNumber,
wbinfo -Y return this uidNumber.  But for other domain groups, it can't
find the gid.  For all but the -514 one, for which it did assign a xidNumber
in idmap.db.

Okay.

I *think* this is "winbind nss info = rfc2307" setting.   With this
one,
I *have* to configure gidNumbers for every group in the AD.  But these
groups are *not* propagated into winbindd even after multiple reload-config and
net cache flush, some *time* have to pass...

hwell.. let's see...

/mjt