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.
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.
--
Chris Maresca
Olliance Group, LLC
www.olliancegroup.com
