Steven Jones wrote: > 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 at 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 at 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 at vuwunicvfwall02 openldap]# > ======================================================= > > > Is this the expected output from a successful password check? > Yes. You can also use the ldapwhoami command. > However, > > Still no ssh or login... > In your nss configuration, you were using a different suffix than dc=vuw,dc=ac,dc=nz. Did you change that? I don't know much about pam or nss configuration. I am trying to verify that Fedora DS is behaving correctly. > 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 at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] 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 at 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 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070911/d07f5268/attachment.bin
