[SOLVED] Re: OpenSSH public key problem with Solaris 10 and LDAP users?

[Alexander Skwar]

Douglas E. Engert <deengert at anl.gov> wrote:

> Since you are using Solaris, and the problem is with old users, added with
> the PADL MigrationTools, vs new users, this might be a userPassword
> attribute issue in LDAP.
> 
> The PADL will add the old password to LDAP using the string:
> {crypt}crypted-password where crypted-password was copied from /etc/shadow
> or NIS.

Correct assessment. BUT: I did a slapcat to dump the database. Then
I copied my working user from this dump, modified it a bit (uid, etc.pp.)
and ldapadd'ed that back to the LDAP database. I did not modify the 
password field.

Result: Login not possible without a password.

Another BUT: I'm beginning to wonder, why passwordless entry works
in the first place. According to the documentation at 
<http://docs.sun.com/app/docs/doc/816-4556/6maort2te?a=view>, passwordless
entry should not work. And seeing that it does not work for new users,
I should be "happy", as it works as described - for new users. Question
is, why does it work for the old user?

> If you used some other tool to add new users to ldap with a userPassword
> (or no userPasswrod) it might be adding a value which the Solaris pam
> considers to be a locked account. So look at how you added the
> new users to ldap.

Described above. I also chose this route to make sure that the newly
created account is as identical to the old account as possible.

> 
> Test as *root* with:
> 
>   ldaplist -l username
>
> It should have a line with
>   userPassword: {crypt}crypted-password

It doesn't.

,----[ LC_ALL=C sudo -H -u root ldaplist -l passwd askwar  ]
| dn: uid=askwar,ou=People,ou=RACE,o=Example
|         uid: askwar
|         cn: Alexander Skwar
|         roomNumber: alexander.skwar at Exampleauto.com
|         givenName: Alexander
|         sn: Skwar
|         mail: askwar at win.ch.da.rtr
|         mailRoutingAddress: askwar at mail1.Exampleauto.com
|         mailHost: mail1.Exampleauto.com
|         objectClass: inetLocalMailRecipient
|         objectClass: person
|         objectClass: organizationalPerson
|         objectClass: inetOrgPerson
|         objectClass: posixAccount
|         objectClass: top
|         objectClass: shadowAccount
|         objectClass: hostObject
|         shadowLastChange: 13503
|         loginShell: /opt/csw/bin/bash
|         gidNumber: 10
|         homeDirectory: /export/home/askwar
|         gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
|         host: winnb000488
|         host: winnb000488.win.ch.da.rtr
|         host: winds06
|         host: winds06.win.ch.da.rtr
|         uidNumber: 10001
`----

I use phpLdapAdmin to manage the LDAP database. In there, I can
easily dump an entry. Doing so, I see that the password is indeed
{crypt} encoded.

,----[ ldif dump of a non-working user ]
| version: 1
| 
| dn: uid=testing,ou=People,ou=RACE,o=Example
| uid: testing
| cn: Testing User
| roomNumber: alexander.skwar at Exampleauto.com
| givenName: Testing
| sn: User
| mail: askwar at win.ch.da.rtr
| mailRoutingAddress: askwar at mail1.Exampleauto.com
| mailHost: mail1.Exampleauto.com
| objectClass: inetLocalMailRecipient
| objectClass: person
| objectClass: organizationalPerson
| objectClass: inetOrgPerson
| objectClass: posixAccount
| objectClass: top
| objectClass: shadowAccount
| objectClass: hostObject
| userPassword: {crypt}cd.......
| shadowLastChange: 13503
| loginShell: /opt/csw/bin/bash
| gidNumber: 10
| gecos: Alexander Skwar,alexander.skwar at Exampleauto.com
| host: winnb000488
| host: winnb000488.win.ch.da.rtr
| host: winds06
| host: winds06.win.ch.da.rtr
| uidNumber: 54321
| homeDirectory: /export/home/testing
`----

(I modified the userPassword in this mail.)


> If its not{crypt}something
> then try changing it to use {crypt}

It is crypt. :(

> the getpw.c program I sent yesterday should return (assuming the username
> is not also in the local /etc/passwd file):
> useranme:x:...
> username:crypted-password:...

Ah!

--($:~/Source/pamtest)-- sudo ./getpw askwar 
STDC = __STDC__
askwar:x:10001:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/askwar:/opt/csw/bin/bash
askwar:cd9--------psA:13503:-1:-1-1:-1:-1:0

--($:~/Source/pamtest)-- sudo ./getpw testing 
STDC = __STDC__
testing:x:54321:10:Alexander Skwar,alexander.skwar at Exampleauto.com:/export/home/testing:/opt/csw/bin/bash
testing:*NP*:-1:-1:-1-1:-1:-1:0

*NP* for testing? Why's that? Why's there a difference?

Hmm....

--($:~/Source/pamtest)-- sudo grep test /etc/shadow

--($:~/Source/pamtest)-- sudo grep askwar /etc/shadow
askwar:cd,,,,,,QkpsA:13503::::::

Ah. askwar is in shadow. 

Now I removed askwar from /etc/shadow. And, lo and behold, I'm no longer
able to do a password-less login to the system. Great! Just the way it
is documented! Excellent! Also good to see, that it really didn't have
anything to do with LDAP. :)

Now I just got to curse at Sun for requiring a password. I guess I need
to have a look at lpk, OpenSSH LDAP Public Key.

Douglas, and others, thanks a million for bearing with me and helping
me to finally find the difference! I very much appreciate it!

Alexander Skwar