Fedora directory users - Jun 2005 - PAM problem - ldap_search_s No such object

Hi,

First of all can I just say a quick thanks to Red Hat and the people
who''ve worked on this?  It looks _wonderful_.


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 


I was assuming this was a problem with anonymous access.  I set the
access control in the Directory (Enable Anonymous Access -> Edit ->
Targets -> UserPassword) but it didn''t seem to make any difference.
(The user has the posix stuff filled out ok too).

I can search the directory from the client (I can get Thunderbird to use 
it as the addressbook for instance).


Am I missing something else?




Billy.

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

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@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

>
>
>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 
>
Are you using a proxy DN (binddn) in /etc/ldap.conf (pam_ldap config 
file)?  If so, does this DN exist in the directory?



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@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>  
>

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@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>  
>>
> 
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Hi, 

Thanks for all the suggestions.  It seems to be working ok now after I
put in a specific entry for my dns hosts in the aci''s.  


Thanks again for the suggestions :-)




Billy.