[Fedora-directory-users] PAM problem - ldap_search_s No such object

[Christopher Blizzard]

This is an excellent method for diagnosis.  Can we add it to a howto on 
the wiki?

--Chris

Jeff Clowser wrote:
> Look in the access log on the FDS server for connections from that 
> workstation (grep on the IP of that workstations, or one of the user 
> id's that are trying to auth, etc).  When you find it, grep out conn=xxx 
> (where xxx is the connection # from that IP) so you get the complete 
> connection from start to finish.
> 
> - Look at the BIND lines to see what that workstation is binding as.
> - Look at the SRCH lines, to see what basedn and filter is being used.  
> My guess is a typo in the search base configured on your workstation.
> - Look at the result line (right after the SRCH line) to see what the 
> results are (though you'll probably just see err=32, which is no such 
> object).  If there are multiple SRCH lines, check each one.
> - Check the ACI's set on your suffix - in console, click on the 
> Directory tab then right click on the top entry in your tree, and select 
> "set permissions" (something like that - doing this from memory).  Make 
> sure the appropriate access is set for what the Suse box is trying to do 
> (or adjust the Suse box to work with what ACI's you find).  You may have 
> to look throughout your tree for aci's to be sure you find everything. 
> (ldapsearch -D cn=directory manager -w - ... -b "your basedn" "(aci=*)" 
> "aci"  to find 'em all.)
> 
> I think the default anonymous access is pretty generous (anything but 
> password attributes?), so you probably just have the search base wrong.
> 
> - Jeff
> 
> Nalin Dahyabhai wrote:
> 
>> On Fri, Jun 24, 2005 at 04:28:42PM +0100, Billy Allan wrote:
>>  
>>
>>> However.... ;-)   I'm trying to get a Linux client (SuSe 9.2) to
>>> authenticate against the directory, but keep seeing :
>>>
>>> Jun 24 16:35:33 xxxxxxxx sshd[780]: pam_ldap: ldap_search_s No such 
>>> object Jun 24 16:35:33 xxxxxxxx sshd[775]: error: PAM: User not known 
>>> to the
>>>  underlying authentication module for illegal user testeroo from 
>>> xxxxxxxx   
>>
>>
>> A "no such object" error suggests that the base DN for the search is
>> either not there or inaccessible to the client.
>>
>>  
>>
>>> I can search the directory from the client (I can get Thunderbird to 
>>> use it as the addressbook for instance).
>>>   
>>
>>
>> I guess that rules out the "object isn't there" theory.  Are your
>> Thunderbird users authenticating to the directory?
>>
>> The pam_ldap module needs to convert the user name to the distinguished
>> name of an entry in the directory server before it can attempt to bind
>> to that entry with the user's password, so you need to provide the
>> ability to locate an entry using its "uid" attribute in order for things
>> to work.
>>
>> HTH,
>>
>> Nalin
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>  
>>
> 
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users