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 > >
