OK, got that. Now I am trying a different SASL configuration, and I have these mechanisms available: dn: supportedSASLMechanisms: LOGIN supportedSASLMechanisms: PLAIN With the same data, I tried running ldapsearch with SASL and got that there are no SASL mechanisms available. ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found Same goes for '-Y LOGIN'. What am I missing here? Thanks in advance Zohar On 10/11/07, Dan White <dwhite(a)olp.net&gt; wrote: > Zohar, > > See: > > http://www.openldap.org/doc/admin23/sasl.html > > Specifically section 11.2.3 for a discussion of DIGEST-MD5. > > If using DIGEST-MD5, your password will be treated as a shared > secret and will not be transmitted over the wire. Also, if > configured correctly (data security layer), the remaining portion > of your connection will be encrypted. > > - Dan White > > Zohar Lev Shani wrote: > > Hello list > > > > I am trying to use OpenLDAP also as a repository of the user and > > password to the SASL mechanism. > > The problem I am facing is that it only works if the userPassword is > > kept in clear text and not in a hashed form. I would like to use the > > hashed form because my application has a proprietary backend where the > > data goes over the wire and for that I need userPassword attribute to > > be not in clear text. > > > > Below is what I tried to do, based on OpenLDAP 2.3.24 running on RH4 > > U3 (Nahant). > > > > Any help will be appreciated. > > > > Zohar > > > > > >> ./configure --prefix=`pwd` > > > > I added to the default slapd.conf with this entry > > authz-regexp "uid=([^,]*)" "cn=$1,cn=users,dc=my-domain,dc=com" > > > > The run command > >> ./slapd -f slapd.conf -d -1 -h ldap://localhost:9999 1>& slapd.log 2>&1 & > > > > Available SASL mechanism > >> > dn: > > supportedSASLMechanisms: DIGEST-MD5 > > supportedSASLMechanisms: CRAM-MD5 > > supportedSASLMechanisms: GSSAPI > > supportedSASLMechanisms: NTLM > > > > Data I am going to add > >> cat ./new_user.ldif > > dn: dc=my-domain,dc=com > > objectclass: dcObject > > objectclass: organization > > o: my-org > > dc: my-domain > > > > dn: cn=Manager,dc=my-domain,dc=com > > objectclass: organizationalRole > > cn: Manager > > > > dn: cn=users,dc=my-domain,dc=com > > objectclass: organizationalRole > > cn: users > > > > dn: cn=user1,cn=users,dc=my-domain,dc=com > > objectclass: organizationalRole > > objectclass: simpleSecurityObject > > cn: user1 > > userPassword: {MD5}pyLGPbjshiWvbPccuMLZOQ== > > #password: pass1 > > > > dn: cn=user3,cn=users,dc=my-domain,dc=com > > objectclass: organizationalRole > > objectclass: simpleSecurityObject > > cn: user3 > > userPassword: {CLEARTEXT}pass3 > > > >> ldapadd -h localhost:9999 -x -w secret -D cn=Manager,dc=my-domain,dc=com -f ./new_user.ldif > > > >> ldapsearch -h localhost:9999 -x -LLL -b cn=user1,cn=users,dc=my-domain,dc=com > > dn: cn=user1,cn=users,dc=my-domain,dc=com > > objectClass: organizationalRole > > objectClass: simpleSecurityObject > > cn: user1 > > userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0= > > > >> ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user1 -w pass1 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com > > SASL/DIGEST-MD5 authentication started > > ldap_sasl_interactive_bind_s: Invalid credentials (49) > > additional info: SASL(-13): user not found: no secret in database > > > >> ldapsearch -h localhost:9999 -Y DIGEST-MD5 -U user3 -w pass3 -LLL -b cn=user1,cn=users,dc=my-domain,dc=com > > SASL/DIGEST-MD5 authentication started > > SASL username: user3 > > SASL SSF: 128 > > SASL installing layers > > dn: cn=user1,cn=users,dc=my-domain,dc=com > > objectClass: organizationalRole > > objectClass: simpleSecurityObject > > cn: user1 > > userPassword:: e01ENX1weUxHUGJqc2hpV3ZiUGNjdU1MWk9RPT0= > >

I had set up a secured TLS with all the certificates and keys needed. But still, I cannot login using SASL and PLAIN/LOGIN mechanisms over TLS. The user in the example has the userPassword hashed in MD5. See errors below: dc=my-domain,dc=com -s base -ZZ SASL/PLAIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: Password verification failed dc=my-domain,dc=com -s base -ZZ SASL/LOGIN authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: checkpass failed Using cleartext password solves the problem but this is not what I am trying to do. Just a reminder of what I am trying to achieve: In the database I want the userPassword field to be hashed and the bind authentication will be against it using the authz-regexp directive in slapd.conf. Using DIGEST-MD5 SASL doesn't help here because the userPassword needs to be in cleartext in the database. Yet again, any help will be appreciated. Zohar On 10/23/07, Dieter Kluenter <dieter(a)dkluenter.de&gt; wrote:

Dieter Kluenter wrote: SASL/LOGIN was deprecated long ago and should never be used. SASL mechanisms that use a simple secret anyway. GSSAPI doesn't. You really have to think about what you're trying to secure. It's fair to say that you can't allow cleartext passwords in the database for one policy or another, but none of these shared-secret authentication mechanisms will work without the password or a plaintext-equivalent. (E.g., DIGEST-MD5 can also work with a pre-hashed password stored in the cmusaslsecretDIGEST-MD5 attribute.) If your goal is simply keeping human-readable passwords out of the database, this will work for you. If your goal is preventing any usable secrets from being stored in the database, then you're out of luck. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

On Monday 05 November 2007 13:20:04 Zohar Lev Shani wrote: Uh, well, if you want to use SASL mechanisms that require a shared secret, obviously: no. If you want to use simple binds, then you can use a hashed userPassword. If you want to use other SASL mechanisms that support encrypted keys, mutual 3rd-party authentication - then you're not going to use userPassword at all ... Regards, Buchan