On 12/08/14 13:59 -0600, Dan White wrote:

On 12/08/14 20:41 +0100, Dieter Klünter wrote:

...

Hi, RFC 5802 describe a Salted Challenge Response Authentication Mechanism and RFC 5803 describes a schema for storing salted challenge response mechanism secrets, which recommend a authPassword attribute type and a salted hash and a hashing scheme as attribute value. It seems, that OpenLDAP doesn't know authPassword

ldapmodify -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=dieter kluenter,ou=partner,o=avci,c=de changetype: modify add: authPassword authPassword: xxxxxxx

modifying entry "cn=dieter kluenter,ou=partner,o=avci,c=de" ldap_modify: Undefined attribute type (17) additional info: authPassword: attribute type undefined

Although the SASL Mechanism is provided and known, but the attribute userPassword maintains a plaintext value.

ldapwhoami -Y SCRAM-SHA-1 -U dieter -w xxxx-H ldapi:/// SASL/SCRAM-SHA-1 authentication started SASL username: dieter SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de

It seems that SASl authentication only supports scram Mechanisms as plaintext value. Is there any intention to fully implement RFC 5802 and RFC 5803?

You could adapt this:

https://github.com/bindle/canned-openldap/blob/master/schema-custom/cmusasl....

Also, it's cyrus sasl that is likely deciding which attribute to use. You'll need to check it's source to verify if it supports authPassword.

Dan White wrote:

On 12/08/14 13:59 -0600, Dan White wrote:

...

On 12/08/14 20:41 +0100, Dieter Klünter wrote:

...

Hi, RFC 5802 describe a Salted Challenge Response Authentication Mechanism and RFC 5803 describes a schema for storing salted challenge response mechanism secrets, which recommend a authPassword attribute type and a salted hash and a hashing scheme as attribute value. It seems, that OpenLDAP doesn't know authPassword

ldapmodify -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=dieter kluenter,ou=partner,o=avci,c=de changetype: modify add: authPassword authPassword: xxxxxxx

modifying entry "cn=dieter kluenter,ou=partner,o=avci,c=de" ldap_modify: Undefined attribute type (17) additional info: authPassword: attribute type undefined

Although the SASL Mechanism is provided and known, but the attribute userPassword maintains a plaintext value.

ldapwhoami -Y SCRAM-SHA-1 -U dieter -w xxxx-H ldapi:/// SASL/SCRAM-SHA-1 authentication started SASL username: dieter SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de

It seems that SASl authentication only supports scram Mechanisms as plaintext value. Is there any intention to fully implement RFC 5802 and RFC 5803?

You could adapt this:

https://github.com/bindle/canned-openldap/blob/master/schema-custom/cmusasl....

There's no attribute for SCRAM in this schema, so it's not really relevant.

Also, it's cyrus sasl that is likely deciding which attribute to use. You'll need to check it's source to verify if it supports authPassword.

The Cyrus SCRAM module checks for both userPassword and authPassword.