Hi, See below. Regards Steven Jones Senior Linux/Unix/San/Vmware System Administrator APG -Technology Integration Team Victoria University of Wellington Phone: +64 4 463 6272 -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Patrick Morris Sent: Tuesday, 11 September 2007 9:01 a.m. To: General discussion list for the Fedora Directory server project. Subject: Re: ssh login fail Hi Steven! On Mon, 10 Sep 2007, Steven Jones wrote: > Is this the correct rpm to use on RHAS4-32bit-U5? > > fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm > > Are there any dependencies on the server and clients not installed by > default? I have everything installed that I can see documented but its > possible I have missed something, or there is an un-documented change as > version upgrade. > > How practical is it to rip out any RHAS4 ldap client modules software > and install Fedora ones? > > Are there different password hash mechanisms between versions? If so how > do I check for these? > > These might seem odd Q's but I'm kinda desperate as to why I cannot get > the system working.... Configuration of EL4 with FDS is normally dirt-simple, if you use authconfig. All I've ever had to do is give it the server address and where to look, and off it went. Thanks, I started by hand and recently re-ran using the authconfig tool and the gtk version... I am pretty much convinced/agree that it should be very simple, I have read so many docs all saying the same thing that I am assuming I have missed read or mis-understood some really easy setting that causes this.....OpenLdap on Debian certainly was easy so it is likely I have either missed something, hit a terminal bug or I am doing the wrong thing. If you're getting an error that the server can't be contacted, it seems that maybe auth isn't correctly configured (or you have more basic network issues). I can do a ldapsearch at the command line on the client which returns info The problem is also in login, so I am pretty sure it is a pam client issue....or encryption.... Eg., ============== [root at vuwunicvfwall02 pam.d]# ldapsearch -x -h 130.195.87.249 -b dc=vuw,dc=ac,dc=nz # extended LDIF # # LDAPv3 # base <dc=vuw,dc=ac,dc=nz> with scope sub # filter: (objectclass=*) # requesting: ALL # # vuw.ac.nz dn: dc=vuw,dc=ac,dc=nz objectClass: top objectClass: domain dc: vuw # Directory Administrators, vuw.ac.nz dn: cn=Directory Administrators, dc=vuw,dc=ac,dc=nz objectClass: top objectClass: groupofuniquenames cn: Directory Administrators # Groups, vuw.ac.nz dn: ou=Groups, dc=vuw,dc=ac,dc=nz objectClass: top objectClass: organizationalunit ou: Groups # People, vuw.ac.nz dn: ou=People, dc=vuw,dc=ac,dc=nz objectClass: top objectClass: organizationalunit ou: People # Special Users, vuw.ac.nz dn: ou=Special Users,dc=vuw,dc=ac,dc=nz objectClass: top objectClass: organizationalUnit ou: Special Users description: Special Administrative Accounts # Accounting Managers, groups, vuw.ac.nz dn: cn=Accounting Managers,ou=groups,dc=vuw,dc=ac,dc=nz objectClass: top objectClass: groupOfUniqueNames cn: Accounting Managers ou: groups description: People who can manage accounting entries # HR Managers, groups, vuw.ac.nz dn: cn=HR Managers,ou=groups,dc=vuw,dc=ac,dc=nz objectClass: top objectClass: groupOfUniqueNames cn: HR Managers ou: groups description: People who can manage HR entries # QA Managers, groups, vuw.ac.nz dn: cn=QA Managers,ou=groups,dc=vuw,dc=ac,dc=nz objectClass: top objectClass: groupOfUniqueNames cn: QA Managers ou: groups description: People who can manage QA entries # PD Managers, groups, vuw.ac.nz dn: cn=PD Managers,ou=groups,dc=vuw,dc=ac,dc=nz objectClass: top objectClass: groupOfUniqueNames cn: PD Managers ou: groups description: People who can manage engineer entries # search result search: 2 result: 0 Success # numResponses: 10 # numEntries: 9 ============== Thanks, I started by hand and recently re-ran using the authconfig tool... The most likely cause, off the top of my head, would be trying to using something like ldaps://ldapserver.yourdomain.com without having configured the server for SSL. As far as I know I am not running ssl but it is possible one end is and the other is not, however FDS is not set to do so in the gui and the client has no setting I can see beyond //etc/ldap.conf saying "ssl no". Hmmm possibly I have my test user in the wrong place in LDAP and hence I get a null return....cant see how to check for this though.... Regards Steven
