Authentication problems with DS6 / Solaris 9 / SASL
Hello all
I have a DS6 installed on top of one of ours Solaris 9 boxes.
From a client Solareis 9 I can execute commands like ldapsearch, ldapaddent etc but I'm having problems to login using SSH.
====================================
From the client /var/adm/messages I have:
====================================
Jul 19 17:38:52 wgls02 sshd[703]: libsldap: Status: 49 Mesg: openConnection: sasl/DIGEST-MD5 bind failed - Invalid credentials
Jul 19 17:38:52 wgls02 sshd[701]: error: PAM: Authentication failed for p642929 from wgls02.nz.thenational.com
Jul 19 17:38:52 wgls02 sshd[703]: [ID 293258 auth.error] libsldap: Status: 49 Mesg: openConnection: sasl/DIGEST-MD5 bind failed - Invalid credentials
Jul 19 17:38:52 wgls02 sshd[701]: [ID 800047 auth.error] error: PAM: Authentication failed for p642929 from wgls02.nz.thenational.com
=====================================
From the server erros logf file:
=====================================
[19/Jul/2007:17:44:28 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - cos_cache_vattr_types: failed to get class of service reference
...
[19/Jul/2007:17:44:28 +1200] - INFORMATION - conn=-1 op=-1 msgId=-1 - normalize_ava_cb: invalid attribute type: dn: uid
...
[19/Jul/2007:17:44:28 +1200] - INFORMATION - passthru-plugin - conn=-1 op=-1 msgId=-1 - <= not handled (not simple bind or NULL dn/credentials)
[19/Jul/2007:17:44:28 +1200] - INFORMATION - conn=-1 op=-1 msgId=-1 - normalize_ava_cb: invalid attribute type: dn: uid
[19/Jul/2007:17:44:28 +1200] - WARNING<4154> - DN - conn=-1 op=-1 msgId=-1 - DN Normalize Lazy normalization of dn: uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
Any ideas?
# 1
I've just been aware of this issue, and it is due to the way the clients are responding to the server during the SASL exchanges.
PAM does not specify the digest-uri in the 2nd round of exchange with DS, whereas the ldap tools do.
The sasl library should not fail if the digest-uri parameter is not specified.
It seems that there has been a regression in the SASL library used by Directory Server 6.
This bug was fixed in the SASL library used 5.2patch4, and is now reappearing.
We are currently investigating the reason for this regression. Feel free to open a support call to get a hot fix to this issue.
Regards,
Ludovic.
# 2
Ludovic,
I found the problem. The authentication method should be, at least, SIMPLE.
option 1) dapclient manual ${verboseFlag} \
-a serviceAuthenticationMethod='passwd-cmd:simple' \
-a authenticationMethod="none" \
-a credentialLevel=anonymous \
option 2) dapclient manual ${verboseFlag} \
-a authenticationMethod="simple" \
-a credentialLevel=anonymous
Now I can connect from my client :D
# 3
Thanks for reporting the explanation. It might help us to figure out the other problem reported in the same area.
And I'm glad that ldapclient works for you now.
Regards,
Ludovic.
# 4
Hi Ludovic
Bad news. I can connect (ldapsearch) and authenticate (ssh, telnet) when using simple in Solaris 8 and Solaris 9. Solaris 10 is not working with simple and I have no clues why.
However, whe using sasl/digest-md5 the result is...no authentication in general for all platforms. I'm using as guide to this que4st two sources: Sun BluePrint LDAP in the Solaris OS... and the DSEE6.0 (not 6.1) Administration/Configuration manuals.
For those documents, I have to
1) turn off SASL encryption -- DONE
2) set the password scheme to CLEAR -- DONE
3) Configure the SASL Digest-MD5 mechanism -- DONE
4) Create/update the default identity mapping -- DONE
5) Set the client configuration to use sasl only -- DONE
...but nothing is working.
What information and configuration do you need to help me to trace this problem?
Cheers,
Andreas
# 5
There are already some engineers from the support organization working on investigating the issue.
The root cause is unknown at this stage.
There are 2 things you could do to help us.
- Change Directory Server log level to 1 (dsconf set-log-prop error level:err-function-calls)
- Snoop the complete exchange of PDU between the client and the server.
Reproduce the problem and post the error string returned by the server to the client, as well as the few error logs around the SASL failure (it should be sasl_server_step2 failiing with an error 13 BAD_AUTH).
If the output is too big, you can mail it to me directly (exceptionally).
My email address is FirstName DOT LastName AT Sun DOT COM
Regards,
Ludovic Poitou.
# 6
Hello Ludovic
An extract from the errors log file:
25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - => send_ldap_search_entry (uid=p642929,ou=people,dc=nz,dc=thenational,dc=com)
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - <= send_ldap_search_entry
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - => send_ldap_result 0::
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - <= send_ldap_result
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ldap_explode
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ids_sasl_canon_user returns 0
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ids_sasl_getopt: plugin= option=canon_user_plugin
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - ids_sasl_getopt: plugin= option=auxprop_plugin
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - sasl(2): no secret in database[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - => send_ldap_result 49::
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - <= send_ldap_result
[25/Jul/2007:08:45:04 +1200] - DEBUG - conn=-1 op=-1 msgId=-1 - Calling plugin 'Multimaster replication postoperation plugin' type 501
And from snoop:
LDAP: -- Lightweight Directory Access Protocol Header --
LDAP:*[LDAPMessage]
LDAP:[Message ID]
LDAP:Operation *[APPL 1: Bind Response]
LDAP: [Result Code]
LDAP:SASL Bind In Progress
LDAP: [Matched DN]
LDAP: [Error Message]
LDAP: SASL Credentials [7]
LDAP: nonce="qkwUpTeIYD+9TvCtVe2Xy2Ny1
LDAP: 8clKLFPrapaSM7GAGU=",realm="wgts
LDAP: inf01",qop="auth",maxbuf=65535,c
LDAP: harset=utf-8,algorithm=md5-sess
LDAP:
...
DAP: -- Lightweight Directory Access Protocol Header --
LDAP:*[LDAPMessage]
LDAP:[Message ID]
LDAP:Operation *[APPL 1: Bind Response]
LDAP: [Result Code]
LDAP: 1
LDAP:Invalid Credentials
LDAP: [Matched DN]
LDAP: [Error Message]
LDAP:
# 7
" no secret in database" means that the server was not able to find or use the userPassword attribute for this user.
When using Digest-MD5 for authentication, the password must be available as cleartext. If the userPassword attribute contains a hashed value (with {CRYPT} {SHA1} or {SSHA}) there is no way to compute the MD5 hash and compare it with the one sent by the client application.
Note that this is clearly documented in Directory Server, in the Authentication section.
Regards,
Ludovic.
# 8
This entry is only to keep this thread up-to-date.
Hi Ludovic
I guess what happended.
1) The Password Scheme is set to CLEAR.
[SunOS 5.9/bash] root@wgtsinf01:/root
# ./LdapGetPasswordStorageScheme
cn=Password Policy,cn=config
passwordStorageScheme=CLEAR
2) I have a script which forces the password to be clear for each user account.
[SunOS 5.9/bash] root@wgtsinf01:/root
# ./LdapClearPasswordAllUsers
...
== ldapmodify
modifying entry uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
== ldapsearch using Directory Manager
uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
userPassword={CLEAR}****
cn=p642929
uidNumber=642929
gidNumber=1
gecos=Andrew Hume - Unix Admin
homeDirectory=/export/home/p642929
loginShell=/bin/bash
objectClass=posixAccount
objectClass=shadowAccount
objectClass=account
objectClass=top
uid=p642929
shadowLastChange=13711
shadowFlag=0
== ldapsearch using user account with new password
uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
cn=p642929
uidNumber=642929
gidNumber=1
gecos=Andrew Hume - Unix Admin
homeDirectory=/export/home/p642929
loginShell=/bin/bash
objectClass=posixAccount
objectClass=shadowAccount
objectClass=account
objectClass=top
uid=p642929
shadowLastChange=13711
shadowFlag=0
...
3) I'm able to login using sasl/digest-md5 and typing the password
# /store/bnz/BNZ_enableLdap --only-configure
. . . . . . . . . . .
.Enabling LDAP.
. . . . . . . . . . .
...
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=nz,dc=thenational,dc=com
NS_LDAP_BINDPASSWD= {NS1}41fa88f3a945c411
NS_LDAP_SERVERS= 10.64.47.50:389, 10.64.6.40:389, 10.64.138.40:389
NS_LDAP_SEARCH_BASEDN= dc=nz,dc=thenational,dc=com
NS_LDAP_AUTH= sasl/DIGEST-MD5
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SERVER_PREF= 10.64.47.50:389
NS_LDAP_CREDENTIAL_LEVEL= anonymous
NS_LDAP_BIND_TIME= 30
NS_LDAP_HOST_CERTPATH= /var/ldap
[SunOS 5.9/bash] root@wgls02:/root
# ssh p642929@localhost
...
Password: *****
Last login: Thu Jul 26 07:37:14 2007 from localhost
...
Logging on to wgls02
uid=642929(p642929) gid=1(other) groups=2503(tsrootsu)
...
[SunOS 5.9/bash] root@wgls02:/root
$
4) I'm not able to change the user password, when authenticated with the user account.
[SunOS 5.9/bash] p642929@wgls02:/export/home/p642929
$ passwd
passwd: Changing password for p642929
Enter existing login password: ******
passwd: Sorry, wrong passwd
Permission denied
[SunOS 5.9/bash] p642929@wgls02:/export/home/p642929
$ ldapsearch -h wgtsinf01 -p 389 -b "dc=nz,dc=thenational,dc=com" -D "cn=Directory Manager" -w **** uid=p642929
uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
userPassword={CLEAR}****
cn=p642929
uidNumber=642929
gidNumber=1
gecos=Andrew Hume - Unix Admin
homeDirectory=/export/home/p642929
loginShell=/bin/bash
objectClass=posixAccount
objectClass=shadowAccount
objectClass=account
objectClass=top
uid=p642929
shadowLastChange=13711
shadowFlag=0
[SunOS 5.9/bash] p642929@wgls02:/export/home/p642929
$
5) After changing the user password, from the command-line, as user root, the user password was replaced by {CRYPT}
[SunOS 5.9/bash] p642929@wgls02:/export/home/p642929
$ exit
logout
Connection to localhost closed.
[SunOS 5.9/bash] root@wgls02:/root
# passwd -r ldap p642929
Enter p642929's password:
New Password: *****
Re-enter new Password: ******
passwd: password successfully changed for p642929
[SunOS 5.9/bash] root@wgls02:/root
# ldapsearch -h wgtsinf01 -p 389 -b "dc=nz,dc=thenational,dc=com" -D "cn=Directory Manager" -w ***** uid=p642929
uid=p642929,ou=people,dc=nz,dc=thenational,dc=com
userPassword={crypt}*****
cn=p642929
uidNumber=642929
gidNumber=1
gecos=Andrew Hume - Unix Admin
homeDirectory=/export/home/p642929
loginShell=/bin/bash
objectClass=posixAccount
objectClass=shadowAccount
objectClass=account
objectClass=top
uid=p642929
shadowLastChange=13711
shadowFlag=0
[SunOS 5.9/bash] root@wgls02:/root
# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=nz,dc=thenational,dc=com
NS_LDAP_BINDPASSWD= {NS1}41fa88f3a945c411
NS_LDAP_SERVERS= 10.64.47.50:389, 10.64.6.40:389, 10.64.138.40:389
NS_LDAP_SEARCH_BASEDN= dc=nz,dc=thenational,dc=com
NS_LDAP_AUTH= sasl/DIGEST-MD5
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SERVER_PREF= 10.64.47.50:389
NS_LDAP_CREDENTIAL_LEVEL= anonymous
NS_LDAP_BIND_TIME= 30
NS_LDAP_HOST_CERTPATH= /var/ldap
[SunOS 5.9/bash] root@wgls02:/root
#
If the authentication process (ssh, telenet etc) is looking for a {clear} password, why the passwd program is changing it back to {crypt}? Is there any more configuration that I'm missing?
# 9
Partially fixed....
At /etc/pam.conf, the entry
passwd auth bindingpam_passwd_auth.so.1
has been changed to
passwd auth bindingpam_passwd_auth.so.1 server_policy
Now I can change the user password using passwd and the password is stored as clear (w/o the {CLEAR}) but...see below
[SunOS 5.9/bash] p642929@wgls02:/export/home/p642929
$ passwd -r ldap
passwd: Changing password for p642929
Enter existing login password:
New Password:
Re-enter new Password:
passwd: password successfully changed for p642929
Enter existing login(LDAP) password:
passwd(LDAP): Sorry, wrong passwd
Permission denied
This second Enter existing login(LDAP) password:
prompt does not accept the old or new password.
# 10
Problem fixed.
At /etc/pam.conf, changed
otherpassword requisitepam_authtok_store.so.1 server_policy
to
otherpassword sufficientpam_authtok_store.so.1 server_policy
