[389-users] Re: ldapsearch and 389ds

On 06/03/2016 06:08 PM, Job Cacka wrote:
>> 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.
No idea.
>
> Finally, how do I keep it from happening again?
We don't really know what happened. Perhaps there was a trailing space
on the original value: "513 ". Do you have the ldapsearch result from
this entry before you modified it? If not, we might not have the data
we need to further troubleshoot this. It's possible something(some
client) modified this value incorrectly. Without an audit log going
back to February we will probably never know if the value was changed,
but if the problem appears again then get the ldapsearch result of the
entry so we can see what the value is really set to.

Regards,
Mark
>> 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@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org