ldapsearch -x -b "dc=vuw,dc=ac,dc=nz" |more shows, # People, vuw.ac.nz dn: ou=People, dc=vuw,dc=ac,dc=nz objectClass: top objectClass: organizationalunit ou: People 8><------ # jonesst1, People, vuw.ac.nz dn: uid=jonesst1,ou=People, dc=vuw,dc=ac,dc=nz uid: jonesst1 givenName: steven objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: jones cn: steven jones # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5 And this shows, [root@vuwunicvfwall02 openldap]# ldapsearch -x -b "ou=People,dc=vuw,dc=ac,dc=nz" # extended LDIF # # LDAPv3 # base <ou=People,dc=vuw,dc=ac,dc=nz> with scope sub # filter: (objectclass=*) # requesting: ALL # # People, vuw.ac.nz dn: ou=People, dc=vuw,dc=ac,dc=nz objectClass: top objectClass: organizationalunit ou: People # jonesst1, People, vuw.ac.nz dn: uid=jonesst1,ou=People, dc=vuw,dc=ac,dc=nz uid: jonesst1 givenName: steven objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: jones cn: steven jones # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 ===================== So lets try the password check, [root@vuwunicvfwall02 openldap]# ldapsearch -x -D "uid=jonesst1,ou=People,dc=vuw,dc=ac,dc=nz" -w xxxxxx -s base -b "" # extended LDIF # # LDAPv3 # base <> with scope base # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top namingContexts: dc=vuw,dc=ac,dc=nz namingContexts: o=NetscapeRoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.13 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: LOGIN supportedSASLMechanisms: ANONYMOUS supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: Fedora Project vendorVersion: Fedora-Directory/1.0.4 B2006.312.435 dataversion: 020070910011125020070910011125 netscapemdsuffix: cn=ldap://dc=vuwunicvfdsm001,dc=vuw,dc=ac,dc=nz:389 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@vuwunicvfwall02 openldap]# ======================================================= Is this the expected output from a successful password check? However, Still no ssh or login... and, 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@xxxxxxxxxx [mailto:fedora-directory-users-bounces@xxxxxxxxxx] On Behalf Of Richard Megginson Sent: Tuesday, 11 September 2007 11:59 a.m. To: General discussion list for the Fedora Directory server project. Subject: Re: ssh login fail Steven Jones wrote: > Yes I have run this before, vuw exists (see below), > > By password return I assume the client is querying LDAP to ask if the > user jonesst1 exists and either sends the hash of the password I used to > try and login or asks for the hash to do a comparison if it matches a > login is allowed.... > I hope not. It really should do an LDAP BIND operation, which means it sends the clear text password to the server in the BIND request (for simple username/password auth). So, try ldapsearch -x -D "uid=someuser,ou=People,dc=vuw,dc=ac,dc=nz" -w thepasssword -s base -b "" That will test to see if that user exists and that the password is correct. > I assume pam.d on the client is doing the hash comparison, so if the > hash method on the client is different to FDS its not going to get > anywhere. > > Querying via the FDS gui shows the user so it is in the database > somewhere.... > > So the possible errors are wrong hash or looking in the wrong place, or > some other error. > looking in the wrong place would be my guess, based on the err=32 in the previous logs you posted. > regards > > Steven Jones > Senior Linux/Unix/San/Vmware System Administrator > APG -Technology Integration Team > Victoria University of Wellington > Phone: +64 4 463 6272 > > 8><----- > > [root@vuwunicvfwall02 openldap]# more output > # 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 > > 8><------ > > # 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 > > ================== > > > -- > 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