[Fedora-directory-users] PAM passthru questions and SecureID

[Richard Megginson]

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>