Hi Rowland, list, On 20-6-2016 20:04, Rowland penny wrote:> If you are using Sernet 4.4.4 packages, you must have a Sernet > subscription, you may get quicker help there.Well I'm not sure this kind of support is included, but even if it were, then others would not benefit from the dialogue with their support. :-)> I was wrong, if you are using 4.2.0 or later, you do not need to sync > idmap.ldb, winbindd should report the correct user/groupname.It does do that on all DCs, yes.> try running getfacl on the sysvol dir, you should get something like this: > > root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol...snip> default:mask::rwx > default:other::--- > > You should have two mapped users/groups and two unmapped ones. > Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit > and check that the unmapped ones are mapped to the same windows RIDs, > which should be CN=S-1-5-18 and CN=S-1-5-11So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3) Also getfacl /var/lib/samba/sysvol looks very different on DC4:> root at dc4:~# getfacl /var/lib/samba/sysvol/ > getfacl: Removing leading '/' from absolute path names > # file: var/lib/samba/sysvol/ > # owner: root > # group: BUILTIN\134administrators > user::rwx > user:root:rwx > user:BUILTIN\134administrators:rwx > user:3000009:r-x > user:OURDOMAIN\134proxmox$:rwx > group::rwx > group:BUILTIN\134server\040operators:r-x > group:BUILTIN\134administrators:rwx > group:3000009:r-x > group:OURDOMAIN\134proxmox$:rwx > mask::rwx > other::--- > default:user::rwx > default:user:root:rwx > default:user:BUILTIN\134administrators:rwx > default:user:3000009:r-x > default:user:OURDOMAIN\134proxmox$:rwx > default:group::--- > default:group:BUILTIN\134server\040operators:r-x > default:group:BUILTIN\134administrators:rwx > default:group:3000009:r-x > default:group:OURDOMAIN\134proxmox$:rwx > default:mask::rwx > default:other::---So the 'unmapped group' 3000300 has become a domain group. I'm guessing that we need to solve this. Could you tell me how?> If they are all the same, no problem, if not, then we will come to that > if we have to :-)Well, then if you would be so kind...? ;-) Thanks very much Rowland! MJ
On 20/06/16 19:35, lists wrote:> Hi Rowland, list, > > On 20-6-2016 20:04, Rowland penny wrote: >> If you are using Sernet 4.4.4 packages, you must have a Sernet >> subscription, you may get quicker help there. > Well I'm not sure this kind of support is included, but even if it > were, then others would not benefit from the dialogue with their > support. :-)Fair enough, but I would want something for my money :-D> >> I was wrong, if you are using 4.2.0 or later, you do not need to sync >> idmap.ldb, winbindd should report the correct user/groupname. > It does do that on all DCs, yes. > >> try running getfacl on the sysvol dir, you should get something like >> this: >> >> root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol > ...snip >> default:mask::rwx >> default:other::--- >> >> You should have two mapped users/groups and two unmapped ones. >> Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit >> and check that the unmapped ones are mapped to the same windows RIDs, >> which should be CN=S-1-5-18 and CN=S-1-5-11 > So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is > different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3) > > Also getfacl /var/lib/samba/sysvol looks very different on DC4: >> root at dc4:~# getfacl /var/lib/samba/sysvol/ >> getfacl: Removing leading '/' from absolute path names >> # file: var/lib/samba/sysvol/ >> # owner: root >> # group: BUILTIN\134administrators >> user::rwx >> user:root:rwx >> user:BUILTIN\134administrators:rwx >> user:3000009:r-x >> user:OURDOMAIN\134proxmox$:rwx >> group::rwx >> group:BUILTIN\134server\040operators:r-x >> group:BUILTIN\134administrators:rwx >> group:3000009:r-x >> group:OURDOMAIN\134proxmox$:rwx >> mask::rwx >> other::--- >> default:user::rwx >> default:user:root:rwx >> default:user:BUILTIN\134administrators:rwx >> default:user:3000009:r-x >> default:user:OURDOMAIN\134proxmox$:rwx >> default:group::--- >> default:group:BUILTIN\134server\040operators:r-x >> default:group:BUILTIN\134administrators:rwx >> default:group:3000009:r-x >> default:group:OURDOMAIN\134proxmox$:rwx >> default:mask::rwx >> default:other::--- > > So the 'unmapped group' 3000300 has become a domain group. > > I'm guessing that we need to solve this. Could you tell me how? > >> If they are all the same, no problem, if not, then we will come to that >> if we have to :-) > Well, then if you would be so kind...? ;-) > > Thanks very much Rowland! > > MJ >OK, I take it that 3000009 points to CN=S-1-5-11 and it is just CN=S-1-5-18 that is wrong by pointing at proxmox$ (which incidentally, is one of your computers) Try backing up idmap.ldb, then open idmap.ldb in ldbedit, find and delete the stanza that holds CN=S-1-5-18, it will look like this: dn: CN=S-1-5-18 cn: S-1-5-18 objectClass: sidMap objectSid: S-1-5-18 type: ID_TYPE_BOTH xidNumber: 3000002 # NOTE: your number will be different! distinguishedName: CN=S-1-5-18 Just delete it and then close & save your editor, run 'net cache flush' and then let Samba recreate the record. Rowland
Hi,> OK, I take it that 3000009 points to CN=S-1-5-11 and it is just > CN=S-1-5-18 that is wrong by pointing at proxmox$ (which incidentally, > is one of your computers) > Try backing up idmap.ldb, then open idmap.ldb in ldbedit, find and > delete the stanza that holds CN=S-1-5-18, it will look like this: > > dn: CN=S-1-5-18 > cn: S-1-5-18 > objectClass: sidMap > objectSid: S-1-5-18 > type: ID_TYPE_BOTH > xidNumber: 3000002 # NOTE: your number will be different! > distinguishedName: CN=S-1-5-18 > > Just delete it and then close & save your editor, run 'net cache flush' > and then let Samba recreate the record.So, I did that, and output is still the same...? I re-checked idmap.ldb on dc4, and a new entry was generated for CN=S-1-5-18, but not with the expected xidNumber 3000300 (like on dc2/dc3) but 3000306. Then i searched idmap.ldb on dc4 for xidNumber 3000300, and it already exists for a record:> # record 295 > dn: CN=S-1-5-21-90123450-981238634-861235949-133256 > cn: S-1-5-21-90123450-981238634-861235949-133256 > objectClass: sidMap > objectSid: S-1-5-21-90123450-981238634-861235949-133256 > type: ID_TYPE_BOTH > xidNumber: 3000300 > distinguishedName: CN=S-1-5-21-90123450-981238634-861235949-133256My guess is that this is the proxmox test machine we saw in the getfacl output on ./sysvol. Should I simply delete that record as well..? (or am I being far too optimistic now?) MJ
Am 20.06.2016 um 21:03 schrieb Rowland penny:> On 20/06/16 19:35, lists wrote: >> Hi Rowland, list, >> >> On 20-6-2016 20:04, Rowland penny wrote: >>> If you are using Sernet 4.4.4 packages, you must have a Sernet >>> subscription, you may get quicker help there. >> Well I'm not sure this kind of support is included, but even if it >> were, then others would not benefit from the dialogue with their >> support. :-) > > Fair enough, but I would want something for my money :-D > >> >>> I was wrong, if you are using 4.2.0 or later, you do not need to sync >>> idmap.ldb, winbindd should report the correct user/groupname. >> It does do that on all DCs, yes. >> >>> try running getfacl on the sysvol dir, you should get something like >>> this: >>> >>> root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol >> ...snip >>> default:mask::rwx >>> default:other::--- >>> >>> You should have two mapped users/groups and two unmapped ones. >>> Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit >>> and check that the unmapped ones are mapped to the same windows RIDs, >>> which should be CN=S-1-5-18 and CN=S-1-5-11 >> So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is >> different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3) >> >> Also getfacl /var/lib/samba/sysvol looks very different on DC4: >>> root at dc4:~# getfacl /var/lib/samba/sysvol/ >>> getfacl: Removing leading '/' from absolute path names >>> # file: var/lib/samba/sysvol/ >>> # owner: root >>> # group: BUILTIN\134administrators >>> user::rwx >>> user:root:rwx >>> user:BUILTIN\134administrators:rwx >>> user:3000009:r-x >>> user:OURDOMAIN\134proxmox$:rwx >>> group::rwx >>> group:BUILTIN\134server\040operators:r-x >>> group:BUILTIN\134administrators:rwx >>> group:3000009:r-x >>> group:OURDOMAIN\134proxmox$:rwx >>> mask::rwx >>> other::--- >>> default:user::rwx >>> default:user:root:rwx >>> default:user:BUILTIN\134administrators:rwx >>> default:user:3000009:r-x >>> default:user:OURDOMAIN\134proxmox$:rwx >>> default:group::--- >>> default:group:BUILTIN\134server\040operators:r-x >>> default:group:BUILTIN\134administrators:rwx >>> default:group:3000009:r-x >>> default:group:OURDOMAIN\134proxmox$:rwx >>> default:mask::rwx >>> default:other::--- >> >> So the 'unmapped group' 3000300 has become a domain group. >> >> I'm guessing that we need to solve this. Could you tell me how? >> >>> If they are all the same, no problem, if not, then we will come to that >>> if we have to :-) >> Well, then if you would be so kind...? ;-) >> >> Thanks very much Rowland! >> >> MJ >> > > OK, I take it that 3000009 points to CN=S-1-5-11 and it is just > CN=S-1-5-18 that is wrong by pointing at proxmox$ (which incidentally, > is one of your computers) > Try backing up idmap.ldb, then open idmap.ldb in ldbedit, find and > delete the stanza that holds CN=S-1-5-18, it will look like this: > > dn: CN=S-1-5-18 > cn: S-1-5-18 > objectClass: sidMap > objectSid: S-1-5-18 > type: ID_TYPE_BOTH > xidNumber: 3000002 # NOTE: your number will be different! > distinguishedName: CN=S-1-5-18 > > Just delete it and then close & save your editor, run 'net cache > flush' and then let Samba recreate the record. > > Rowland > >Hi MJ and Rowland, I did abit of testing last week (two debian jesie servers with sernet 4.2 samba packages). Seems when rsync is run against rsyncd or involved via xinet as it is described in the wiki the user and group mapping does not work and uid and gid numbers are used. If I used rsync via ssh the mapping works and there is no need for idmap.ldb to be in sync. achim~