Re: (ITS#3446) ACL val clause ineffective with bind

[ando@sys-net.it]

The only explanation that seems reasonable to me is that one should not
muck with password values.  I understand that while this might be a good
thing, mucking with password hashes could ne useful.  I'd favor doing
something like allowing a special "hash" value style for passwords, and
pass only this portion of the value.  This may require a bit of work, and
some overhead (e.g. creating temporaries for values of passwords that have
a "{[^}]+}" prefix).  We should move the discussion to -devel.

p.


>> I guess what you intend to do is to allow bind based on some hash
>> mechanism only.  I think this possibility should be considered, maybe
>> through a different mechanism
>
> OK. The motivating problem at hand (when I found this didn't work) was
> that we have some users with one-time password cards. We've coded this as
> a "hash" mechanism within OpenLDAP. So an entry might have:
>
> userPassword: {ONETIME}HWTOKEN123
> userPassword: {CLEAR}secret
>
>
> But we have certain services/hosts that should always use OTP, and we
> have certain services/hosts that should never use OTP.
>
>
> If userPassword 'val' worked, I was hoping for something like:
>
> access to userPassword val={CLEAR}*
> 	by peer=secure.server none
> 	by dn="cn=OTPOnly" none
> 	by * auth
>
> to restrict access to non-OTP entries for those with paranoia.
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497