Date: Wed, 06 Nov 2013 16:43:55 +0100
From: Petr Spacek <pspacek(a)redhat.com>
On 6.11.2013 17:34, Jan Tomasek wrote:
> Hello,
>
> please, does anybyody any idea how to implement this with 389?
According to
http://tools.ietf.org/html/rfc4519#section-2.41
the userPassword attribute is multi-valued.
Did you try to add multiple values to the attribute?
I never tried it, so no warranty :-)
That's not a solution - storing multiple values in the userPassword attribute
makes all of them valid for any application. It does not ensure that only one
specific application binds with a particular password.
What are the "fragile" aspects of the scheme Jan described? What are the
specific problems that need to be improved on?
Petr^2 Spacek
> Thanks
>
> Jan
>
> On 11/04/2013 07:40 PM, Jan Tomasek wrote:
>> Hi,
>>
>> my question about PAM, libscript... come from my idea: I would like to
>> implement secondary passwords in very similar way like Google's
>> application specific passwords works. [1]
>>
>> We are using LDAP for centralized user management. Systems providing
>> services to users are verified against this LDAP. Users are saving those
>> passwords within mail clients, in workstation, in tablet, ... we would
>> like to provide option to users to not store their main password within
>> their clients. We would like to offer them alternative passwords working
>> for email, calendar client and so on on specific device. In case of
>> compromising one of devices - user will have only to revoke password for
>> that device.
>>
>> In short. I want to users offer possibility to generate secondary
>> passwords working for email, and so on. I expect them to create multiple
>> passwords marked with some nickname, like:
>> phone-email
>> tablet-email
>> phone-calendar
>> and so on. Those passwords should work with standard LDAP bind but not
>> necessarily on the same suffix and/or where primary LDAP is. We would
>> like to split primary LDAP passwors used for financial and high trust
>> applications from those serving email and calendar.
>>
>> How to do something like this with 389 DS?
>>
>> My idea is this:
>>
>> uid=semik,dc=neco
>> objectClass: inetOrgPerson
>> cn: Jan Tomasek
>> sn: Tomasek
>> uid: semik
>> userPassword: {SSHA}...
>>
>> dc=12345,uid=semik,dc=neco
>> objectClass: appPassword
>> dc: 12345
>> password: some-generated-password1
>> passwordLabel: phone-email
>>
>> dc=12395,uid=semik,dc=neco
>> objectClass: appPassword
>> dc: 12395
>> password: some-generated-password2
>> passwordLabel: tablet-email
>>
>> dc=12399,uid=semik,dc=neco
>> objectClass: appPassword
>> dc: 12399
>> password: some-generated-password3
>> passwordLabel: phone-calendar
>>
>>
>> I tried to implement this as PAM Pass through authentication. It works
>> but it is very fragile.
>>
>> I'm looking for more robust and faster way. I know it is possible to do
>> this with PreOperation Plugin but maybe there is some easier way. Or
>> maybe already someone implemented such plugin.
>>
>> Any comments? Ideas?
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/