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