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.