> On 06/03/2016 03:18 PM, Job Cacka wrote: > Here there are NO entries that match this filter in "dc=domain,dc=com": > (&(objectClass=posixAccount)(uid=test06032016d)) > > We found this entry (nentries=1) > We modify it > We do NOT find any entry matching (nentries=0): > "(&(objectClass=posixAccount)(uidNumber=1761))" > Again no entry > No matching entry again > We do find this group (nentries=1) > No matching entries > No matching entries. > > So, either there are simply no entries in your database, or they are > missing the objectclass "posixAccount/posixGroup" > > Try these ldapsearches: > > ldapsearch -Hldaps://ds1.domain.com -D "cn=directory manager" -w > "pass" -xLLL -b "dc=domain,dc=com" uid=test06032016d > > ldapsearch -Hldaps://ds1.domain.com -D "cn=directory manager" -w > "pass" -xLLL -b "dc=domain,dc=com" uidNumber=1761 > > ldapsearch -Hldaps://ds1.domain.com -D "cn=directory manager" -w > "pass" -xLLL -b "dc=domain,dc=com" gidNumber=513 > Herein lies the problem. No results were returned when gidNumber=513. If I replaced this with "description=Netbios Domain Users" ,which is another unique way to refer to this record, then the record is found and all of the information is displayed. I went into the 389 console and found the record. I deleted the contents of the gidNumber attribute, which showed as 513, and typed in 513. The search now works with the expected results, and my smbldap-tools, 'smbldap-adduser -a', script works with the expected results. So why did this happen? and what other data is 'corrupted'? Why did we only now see this (sometime beginning of February 2016)? It was created in 2013. Finally, how do I keep it from happening again? > > If these searches do not return any results then there are no entries. If they are > returned check for the objectclasses posixAccount and posixGroup (for the gidNumber > search) > > Mark Thanks for all your help, Job -- 389-users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
