Re: OpenLDAP as a SASL backend
On Monday 05 November 2007 13:20:04 Zohar Lev Shani wrote: > I understand now why I cannot put hashed userPassword when I use SASL. But, > does it mean that the ONLY place where I can use hashed passwords for > authentication is the rootpw directive in slapd.conf, or, there are more > sensible use cases where it can be used? 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
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > I understand now why I cannot put hashed userPassword when I use SASL. But, > does it mean that the ONLY place where I can use hashed passwords for > authentication is the rootpw directive in slapd.conf, or, there are more > sensible use cases where it can be used? > > On 11/5/07, Howard Chu <[EMAIL PROTECTED]> wrote: > Dieter Kluenter wrote: > > "Zohar Lev Shani" < [EMAIL PROTECTED] > writes: [...] You may use hashed passwords as userPassword attribute value for simple binds. Why do you want hashed passwords at all? I think this is just security by obscurity. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
I understand now why I cannot put hashed userPassword when I use SASL. But, does it mean that the ONLY place where I can use hashed passwords for authentication is the rootpw directive in slapd.conf, or, there are more sensible use cases where it can be used? On 11/5/07, Howard Chu <[EMAIL PROTECTED]> wrote: > > Dieter Kluenter wrote: > > "Zohar Lev Shani" <[EMAIL PROTECTED] > writes: > > > >> 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: > > SASL/LOGIN was deprecated long ago and should never be used. > > >>> ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b > 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 > > >> 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. > > > Any sasl mechanism, except external, requires cleartext password. > > 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 Sunhttp://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >
Re: OpenLDAP as a SASL backend
Dieter Kluenter wrote: "Zohar Lev Shani" <[EMAIL PROTECTED]> writes: 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: SASL/LOGIN was deprecated long ago and should never be used. ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b 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 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. Any sasl mechanism, except external, requires cleartext password. 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 Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > 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: > >>ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b 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 > >>ldapsearch -h localhost: -Y LOGIN -w pass1 -U user1 -b 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. Any sasl mechanism, except external, requires cleartext password. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
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: >ldapsearch -h localhost: -Y PLAIN -w pass1 -U user1 -b 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 >ldapsearch -h localhost: -Y LOGIN -w pass1 -U user1 -b 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 <[EMAIL PROTECTED]> wrote: > > "Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > > > OK, got that. > > > > Now I am trying a different SASL configuration, and I have these > > mechanisms available: > > > >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base > -LLL > > dn: > > supportedSASLMechanisms: LOGIN > > supportedSASLMechanisms: PLAIN > > > > With the same data, I tried running ldapsearch with SASL and got that > > there are no SASL mechanisms available. > > > >> ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b > cn=user1,cn=users,dc=my-domain,dc=com > > 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? > > OpenLDAP only supports PLAIN and LOGIN if data transport is secured > that is either by TLS or local pipe. Install sasl libdigestmd5 and > libcrammd5 to provide shared secret security. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://www.dkluenter.de > GPG Key ID:8EF7B6C6 >
Re: OpenLDAP as a SASL backend
"Zohar Lev Shani" <[EMAIL PROTECTED]> writes: > OK, got that. > > Now I am trying a different SASL configuration, and I have these > mechanisms available: > >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL > dn: > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: PLAIN > > With the same data, I tried running ldapsearch with SASL and got that > there are no SASL mechanisms available. > >> ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b >> cn=user1,cn=users,dc=my-domain,dc=com > 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? OpenLDAP only supports PLAIN and LOGIN if data transport is secured that is either by TLS or local pipe. Install sasl libdigestmd5 and libcrammd5 to provide shared secret security. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Re: OpenLDAP as a SASL backend
OK, got that. Now I am trying a different SASL configuration, and I have these mechanisms available: > ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL dn: supportedSASLMechanisms: LOGIN supportedSASLMechanisms: PLAIN With the same data, I tried running ldapsearch with SASL and got that there are no SASL mechanisms available. > ldapsearch -h localhost: -Y PLAIN -U user1 -w pass1 -LLL -b > cn=user1,cn=users,dc=my-domain,dc=com 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 <[EMAIL PROTECTED]> 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: 1>& slapd.log 2>&1 & > > > > Available SASL mechanism > >> ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL > > 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: -x -w secret -D cn=Manager,dc=my-domain,dc=com > >> -f ./new_user.ldif > > > >> ldapsearch -h localhost: -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: -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: -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= > >
Re: OpenLDAP as a SASL backend
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: 1>& slapd.log 2>&1 & Available SASL mechanism ldapsearch -h localhost: -x -b '' supportedSASLMechanisms -s base -LLL 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: -x -w secret -D cn=Manager,dc=my-domain,dc=com -f ./new_user.ldif ldapsearch -h localhost: -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: -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: -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=