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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20061108/ebe86b0b/attachment.bin
