[Fedora-directory-users] ssh login fail

Tue Sep 11 02:44:29 UTC 2007

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?

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 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: [Fedora-directory-users] 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
>   