Chris Maresca wrote:
Richard Megginson wrote:
> You mean like "every person who is a member of group A has to use
> {PAM}uid:groupAAuth"?
Yes, exactly.
> I suppose we could use Class of Service to
> implement that.
That would be the best, architecturally and from a maintenance
standpoint. It would a lot easier to change authentication
sub-systems for a whole class of people rather than 1 by 1... I'm not
sure how Class of Service works, but I'll look into it. Still learning
a lot of the LDAP internals, it's been a pretty steep learning curve
so far.
> 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.
I agree, it's somewhat of a hack, but it would seem to the quick way
to get to more flexibility in handling authentication externally.
Given the myriad of potential external auths, more flexibility would
be better. Perhaps instead you could have {LOOKUP}(some filter that
points elsewhere)? I don't know if that's possible at all.
>> 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.
PAM has built in fallback when an auth method fails. However, if the
alternative auth method was a password in LDAP, how would LDAP know
that the first auth had failed? You could easily do it with an
alternative password store (like unix passwords), but it might be
difficult to do if you wanted to contain everything in LDAP.
>> 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.
No. Most of them have their own proprietary auth protocols. Most
provide RADIUS auth and some have PAM modules. When I was looking at
using OpenLDAP, I worked out this crazy chained auth scheme involving
LDAP -> SASL -> saslauthd -> pam_radius -> auth server. It gave me
the willies as each piece of the chain represents yet another thing
that can fail and another security hole. FedoraDS's PAM passthrough
does away with a lot of that (well SASL mostly), which, IMHO, is a
good thing.
But this is what SASL was designed to do - isolate applications from
the
authentication implementation details. Ideally, it would go like this:
LDAP -> SASL -> sasl auth server plugin -> auth server
Then you could just to an LDAP SASL BIND with a mechanism like
"SASL-SECURID" or something like that, and pass in whatever credentials
are required by the auth server in the sasl credentials field. You
could even do multi stage and interactive steps with SASL e.g. if you
wanted to first ask for the user name and password, then ask for the
securid token in a separate step. Additionally, this authentication
would be available to every other service that can use SASL for
authentication.
However, if it is more difficult to take the SASL plugin approach, or
the vendors are just not going to make this happen, then we should
figure out how to extend the PAM passthru plugin to handle cases like this.
Would you be able to write up something for the Fedora DS wiki, like an
informal software requirements doc? Or your own publicly accessible
website or blog if you would prefer. This is a good idea and you should
capture your ideas while they are still fresh.
The other main issue is that most token vendors only support account
lookup in a limited set of LDAP servers (usually AD and one other).
I'm running into this now with CryptoCard, as their auth server can
lookup accounts in AD, OpenLDAP and Mac OpenDirectory, but not Fedora
(they have schemas in their configs for Sun and Novell as well, but
they are 'not supported'). The alternative is to clone each account
to the auth server and not have it do LDAP lookups, which is kinda
stupid, but a usable workaround.
All that said, I think that Fedora DS having pam passthrough makes it
the open source LDAP server of choice (and potentially the only one on
Linux that could do external auth against a token system) since
OpenLDAP doesn't support this except through an complex/fragile SASL
chain.
The only other LDAP server that I know of that directly supports
tokens is Novell's eDirectory + RSA tokens, but the auth module for
RSA only runs on WinX and Netware.... Even on WinX, there are issues
with AD integration, particularly at the desktop login level.
Right now, I've got a copy of CryptoCard's (CC) server running on the
same box as LDAP. It sees all the LDAP accounts fine, but CC's
mappings don't recognize that the accounts are user accounts and I'm
try to fix that. CC is being less than cooperative in explaining what
is what (sigh). Supposedly RSA's server is a bit more flexible in
account configuration and I might install that next.
All I know is that I'd love to get this working. Right now, pam
passthrough seems the fastest way to get there, if I can figure out
the right incantations to get a token auth server to lookup LDAP
accounts.
(Sorry for the rant)
Chris.