Chris Maresca wrote:
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.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.
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.
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.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.
Thanks for the info. Chris.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
