samba - Apr 2021 - Sysvol permission issue - how to repair permanently?

On Sun, 04 Apr, Rowland penny via samba wrote:
> I wish I had a time machine, I could go back in time and tell you
> that using mapped ID's in this way was a bad idea.
As soon as you have "apt install real-life-timemachine" ready,
I'll
volunteer for a beta test. ;-)
> Using nslcd at that time wasn't a bad idea, though unnecessary. You 
> could easily change to Unix domain members, except for the ill
> advised group ID's and you could probably work around them.
Yes, it looks like if we did it "the proper way" back in time, we
would
not be in this mess right now.
> Do you have this line in the Samba DC's smb.conf : idmap_ldb:use 
> rfc2307? = yes
> 
> If you do, comment it out (using a ';' or '#') and see if
that helps,
> it will make the DC's only use idmap.ldb and ignore any uidNumber &
> gidNumber attributes in AD.
Oh, wow, you are referring to

https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD#RFC2307_on_AD_Domain_Controllers

correct?

Wow, I could have sworn that I read somewhere to put

  idmap_ldb:use rfc2307 = yes

into /etc/samba/smb.conf, but (of course) you are right, the wiki
mentions that it is not important for DCs and even more so, that it's
less error prone without.

So, basically, "idmap_ldb:use rfc2307 = yes" puts special
uidNumber/gidNumber handling with higher priority into the mapping and
without that setting, just the idmap.ldb is being used? Removing that
setting will not have any writing effect on the databases?

Then I'll try it tomorrow or the day after. Thanks a lot so far!

Greetings,
Stefan

-- 
Stefan Bellon

On Sun, 04 Apr, Stefan Bellon via samba wrote:
> Then I'll try it tomorrow or the day after. Thanks a lot so far!
Ok, sadly, removing "idmap_ldb:use rfc2307 = yes" did not help.

I dug a bit deeper ... let's try whether I understood the problem right:

root at dc1:~# ldbsearch -H /var/lib/samba/private/idmap.ldb
'(xidNumber=100)'
# record 1
dn: CN=S-1-5-21-37643267-2172530850-1818422998-513
cn: S-1-5-21-37643267-2172530850-1818422998-513
objectClass: sidMap
objectSid: S-1-5-21-37643267-2172530850-1818422998-513
type: ID_TYPE_GID
xidNumber: 100
distinguishedName: CN=S-1-5-21-37643267-2172530850-1818422998-513

# returned 1 records
# 1 entries
# 0 referrals

root at dc1:~# wbinfo --sid-to-name=S-1-5-21-37643267-2172530850-1818422998-513
DS\Domain Users 2

root at dc1:~# grep :100: /etc/group
users:x:100:

root at dc1:~# ldbsearch -H /var/lib/samba/private/sam.ldb
'(cn=developers)' cn gidNumber
# record 1
dn: CN=developers,CN=Users,DC=xxx
cn: developers
gidNumber: 100

# Referral
ref: ldap://ds.axivion.com/CN=Configuration,DC=xxx

# Referral
ref: ldap://ds.axivion.com/DC=DomainDnsZones,DC=xxx

# Referral
ref: ldap://ds.axivion.com/DC=ForestDnsZones,DC=xxx

# returned 4 records
# 1 entries
# 3 referrals


So, SID S-1-5-21-37643267-2172530850-1818422998-513 is "Domain Users"
and has the xidNumber 100 attribute attached (via idmap.ldb).

On the other hand, AD group "developers" also maps to gidNumber 100
(via sam.ldb).

And this is the conflict here?

If that is a correct understanding ... wouldn't one of the following
two ways help to remove the conflict?

1) I could remove the attribute gidNumber from our AD group
"developers"
(via sam.ldb). the individual users would still have the gidNumber
attribute set to 100 and nslcd would assign those users gid 100 and
group "users" on the Linux side while in AD the group
"developers"
would not be connected to GID 100 any more?

2) Or, a second way to break the conflict: Change (via idmap.ldb) the
xidNumber of "Domain Users" from 100 to something like 3000100?

Does this sound reasonable? And - would it work? ;-)

Greetings,
Stefan

-- 
Stefan Bellon