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
