Rowland, Thank you for the quick response. I have just run net cache flush no change in problem. I have dumped the idmap.ldp using ldbsearch -H /var/lib/samba/private/idmap.ldb > idmap.txt and did some sorting, that is how I found the duplicates. On 1/13/2017 11:09 AM, Rowland Penny via samba wrote:> samba-tool ntacl > >sysvolreset
On Fri, 13 Jan 2017 11:36:26 -0500 Bob Thomas via samba <samba at lists.samba.org> wrote:> Rowland, > > Thank you for the quick response. > > I have just run net cache flush no change in problem. I have dumped > the idmap.ldp using ldbsearch -H /var/lib/samba/private/idmap.ldb > > idmap.txt and did some sorting, that is how I found the duplicates. > > > On 1/13/2017 11:09 AM, Rowland Penny via samba wrote: > > samba-tool ntacl > > >sysvolreset > >OK, idmap.ldb contains records like this: dn: CN=S-1-5-21-1768301897-3342589593-1064908849-502 cn: S-1-5-21-1768301897-3342589593-1064908849-502 objectClass: sidMap objectSid: S-1-5-21-1768301897-3342589593-1064908849-502 type: ID_TYPE_BOTH xidNumber: 3000045 distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-502 As you can see, it maps a user/groups SID to an xidNumber. So I see no problem with just using the xidNumber for another SID when you have duplicates, but I would try this instead. Stop Samba, backup idmap.ldb and then delete both duplicates and any other records that don't match the above sample, then restart Samba, this should recreate the records, but with new xidNumbers. Run 'net cache flush' and sysvolreset again. Rowland
Rowland,>> Thank you for the quick response. >> >> I have just run net cache flush no change in problem. I have dumped >> the idmap.ldp using ldbsearch -H /var/lib/samba/private/idmap.ldb > >> idmap.txt and did some sorting, that is how I found the duplicates. >> >> >> On 1/13/2017 11:09 AM, Rowland Penny via samba wrote: >>> samba-tool ntacl >>>> sysvolreset >> > OK, idmap.ldb contains records like this: > > dn: CN=S-1-5-21-1768301897-3342589593-1064908849-502 > cn: S-1-5-21-1768301897-3342589593-1064908849-502 > objectClass: sidMap > objectSid: S-1-5-21-1768301897-3342589593-1064908849-502 > type: ID_TYPE_BOTH > xidNumber: 3000045 > distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-502 > > As you can see, it maps a user/groups SID to an xidNumber. So I see no > problem with just using the xidNumber for another SID when you have > duplicates, but I would try this instead. Stop Samba, backup idmap.ldb > and then delete both duplicates and any other records that don't match > the above sample, then restart Samba, this should recreate the records, > but with new xidNumbers. > > Run 'net cache flush' and sysvolreset again. > > Rowland >I tried two ways but it didn't seem to help, First stopped Samba, backed up idmap.ldp and ldpedit deleted the duplicates. Started Samba and it did recreate the records so I did net cache flush but wbinfo --gid-info failed for the new xids: failed to call wbcGetgrgid: WBC_ERR_DOMAIN_NOT_FOUND No change in sysvolreset also. Second, I stopped samba, restored backup idmap.ldp and just edited: 3000002 dn: CN=S-1-5-21-976934076-1976663741-3168181429-501 to 3000011 3000003 dn: CN=S-1-5-21-976934076-1976663741-3168181429-514 to 3000012 Note all other idmap records are in the correct format, complete and no SIDs are duplicated result wbinfo --gid-info was correct for 3000011 & 3000012 but still fails for 3000002 & 3000003 however wbinfo --sid-to-gid results are good sysvolreset still shows repeated: idmap range not specified for domain '*' Bob
On 1/13/2017 1:45 PM, Rowland Penny wrote:> On Fri, 13 Jan 2017 13:30:14 -0500 > Bob Thomas <bthomas at cybernetics.com> wrote: > >> Rowland, >>>> Thank you for the quick response. >>>> >>>> I have just run net cache flush no change in problem. I have >>>> dumped the idmap.ldp using ldbsearch >>>> -H /var/lib/samba/private/idmap.ldb > idmap.txt and did some >>>> sorting, that is how I found the duplicates. >>>> >>>> >>>> On 1/13/2017 11:09 AM, Rowland Penny via samba wrote: >>>>> samba-tool ntacl >>>>>> sysvolreset >>> OK, idmap.ldb contains records like this: >>> >>> dn: CN=S-1-5-21-1768301897-3342589593-1064908849-502 >>> cn: S-1-5-21-1768301897-3342589593-1064908849-502 >>> objectClass: sidMap >>> objectSid: S-1-5-21-1768301897-3342589593-1064908849-502 >>> type: ID_TYPE_BOTH >>> xidNumber: 3000045 >>> distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-502 >>> >>> As you can see, it maps a user/groups SID to an xidNumber. So I see >>> no problem with just using the xidNumber for another SID when you >>> have duplicates, but I would try this instead. Stop Samba, backup >>> idmap.ldb and then delete both duplicates and any other records >>> that don't match the above sample, then restart Samba, this should >>> recreate the records, but with new xidNumbers. >>> >>> Run 'net cache flush' and sysvolreset again. >>> >>> Rowland >>> >> I tried two ways but it didn't seem to help, >> >> First stopped Samba, backed up idmap.ldp and ldpedit deleted the >> duplicates. Started Samba and it did recreate the records so I did >> net cache flush but wbinfo --gid-info failed for the new xids: >> failed to call wbcGetgrgid: WBC_ERR_DOMAIN_NOT_FOUND >> No change in sysvolreset also. >> >> Second, I stopped samba, restored backup idmap.ldp and just edited: >> 3000002 dn: CN=S-1-5-21-976934076-1976663741-3168181429-501 to >> 3000011 3000003 dn: CN=S-1-5-21-976934076-1976663741-3168181429-514 >> to 3000012 >> >> Note all other idmap records are in the correct format, complete and >> no SIDs are duplicated >> >> result wbinfo --gid-info was correct for 3000011 & 3000012 but still >> fails for 3000002 & 3000003 >> however wbinfo --sid-to-gid results are good >> >> sysvolreset still shows repeated: idmap range not specified for >> domain '*' >> >> Bob >> > Try restarting Samba, perhaps this will help > Have you given any AD group other than Domain Users a gidNumber ? > > RowlandI have assigned gidNumbers to all the groups I created and to Domain Admins, Domain Computers, Enterprise Admins and DNS Admins. Restarting Samba has no effect.