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.
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.
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.
--
Chris Maresca
Olliance Group, LLC
www.olliancegroup.com
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
