Greetings, I have been searching webpages for guidance on using a smartcard ( also know as an HSM ) for storing passwords for an ldap database on a linux system. This would include for instance how would the userPassword (attrribute) be specified - i.e. how to specify the userPassword to read the PIN/SO- PIN/PUK{whatever} of the HSM/smart-card etc etc ?? Any guidance would be much appreciated.

On Monday 08 December 2014 09:51:47 Dieter Klünter wrote: > RFC-4513 describes LDAP Authentication Methods. I don't know much about > HSM/smartcards, but if the provided key is a X.509 certificate, than it > would be simple yes I will consider x509 certificates placed within the smart-card

In case of SASL mechanisms which require 'userPassword' value(s) in clear you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it

4. In case of SASL mechanisms which require 'userPassword' value(s) in clear you would have to implement a reversible encryption password storage schema in an OpenLDAP overlay and adapt some other layer/components to correctly use it.

Howard Chu wrote: > Michael Ströder wrote: >> 4. In case of SASL mechanisms which require 'userPassword' value(s) in clear >> you would have to implement a reversible encryption password storage schema in >> an OpenLDAP overlay and adapt some other layer/components to correctly use it. > > The SASL SCRAM mechanism works without a plaintext userPassword. Yes, but AFAIK not the current cyrus-sasl implementation.

Not to speak of lack of support by client implementations...

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> 4. In case of SASL mechanisms which require 'userPassword' value(s) in clear >>>> you would have to implement a reversible encryption password storage >>>> schema in >>>> an OpenLDAP overlay and adapt some other layer/components to correctly use >>>> it. >>> >>> The SASL SCRAM mechanism works without a plaintext userPassword. >> >> Yes, but AFAIK not the current cyrus-sasl implementation. > > Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012. > >> Not to speak of lack of support by client implementations... > > Any client that uses the Cyrus-SASL libraries should have support without any > extra effort. Hmm, some extra effort is needed in clients, especially when they have a UI or complex configuration. At a minimum you have to register a new SASL mech as being a password-based mech. You might have guessed: I've added SCRAM support to web2ldap right after SCRAM support appeared in cyrus-sasl release. > They may need tweaks to support channel binding, but the basic > authentication mech works. Yes, but how many clients provide the input form or configuration for choosing SCRAM?

Howard Chu wrote: > Given that Cyrus-SASL has a listmechs() API, I don't see why a client would > ever have a hardcoded list of supported mechanisms. Please re-read in my posting: "At a minimum you have to register a new SASL mech as being a password-based mech."

Be assured that I really know what I'm talking about: An interactive UI needs some extra effort.

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> 4. In case of SASL mechanisms which require 'userPassword' value(s) in clear >>> you would have to implement a reversible encryption password storage >>> schema in >>> an OpenLDAP overlay and adapt some other layer/components to correctly use >>> it. >> >> The SASL SCRAM mechanism works without a plaintext userPassword. > > Yes, but AFAIK not the current cyrus-sasl implementation. Hm, Cyrus-SASL 2.1.26 with SCRAM was released in 2012.