Chris Maresca wrote:
>
>
> Richard Megginson wrote:
>
>>> 1. Is it possible to specify PAM as the authentication on a
>>> per-account basis?
>> No.
>>> 2. Is it possible to specify authentication escalation on failure on
>>> a per account basis?
>> No.
>
> Bummer.
>
>> But these do seem like very interesting features - how would this
>> work? via a special attribute in the user's entry?
>
> Yes, that's the idea. At least for authentication, you could just
> have another method in userPassword, like there is now (e.g. {crypt}
> {SSHA}), perhaps {PAM}uid:ldapauthentication, where uid is the userid
> attribute to be passed (could also be 'binddn' or something else like
> 'mail') and where ldapauthentication is your entry in pam.d.
>
> As we are planning on having different account profiles basically
> controlling access to different services/systems, it would be more
> useful to define this on the group level, but I don't know how that
> would work and it seems like it would be a lot more work than just
> adding another method to userPassword.
You mean like "every person who is a member of group A has to use
{PAM}uid:groupAAuth"? I suppose we could use Class of Service to
implement that.
I just don't like overloading the userPassword {foo} syntax, but
openldap has a history of doing something similar with {kerberos} and
{sasl}, so there is precedent.
>
> The driving motivator for this is trying to deploy token-based
> two-factor authentication, where some profiles would require
> authentication through a token, while uid/password would be enough for
> others. That avoids deploying tokens to everyone, without splintering
> management into a lot of different LDAP trees.
>
> The other thing is that some accounts would need access no matter what
> (hence ques. 2) , although that would seem to defeat the purpose of
> tokens... I don't have an answer as to how to deal with that, but in
> the worst case, you could handle it at the PAM level.
Yeah, I'm not sure what that would look like.
>
>> We used to do this at AOL. We had a proprietary plugin for this
>> purpose. The password was passed as "password/securidtoken". The
>> plug-in parsed out the password and the token and passed them off to
>> our proprietary auth thingy.
>
> Ugh, I was afraid of that. I'm trying to avoid 'custom', 'proprietary'
> e.g. unsupport, unupdated stuff. I'm also very much hating all of the
> two-factor vendors out there as they seem very narrow minded. They
> have a single use-case and basically you're on your own (see 'custom'
> & 'proprietary') if you don't fit into it.
This sounds like a worthwhile project to work on. Have the token
vendors provided SASL mechanisms for their products? That seems like
the best way to enable authentication via their devices to a wide range
of applications.
>
> Thanks for the info.
>
> Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20061108/9f4675ef/attachment.bin
