Fedora directory users - Nov 2006 - Re: PAM passthru questions and SecureID

> From: Chris Maresca <ckm@olliancegroup.com>
> Subject: Re: [Fedora-directory-users] PAM passthru questions and
> 	SecureID
> Message-ID: <4552F189.9060001@olliancegroup.com>
> Richard Megginson wrote:
>> > 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
> Yes, but there are a very limited number of SASL plugins, basically 
> NTLM, Kerberos, GSS and SecurID.  Non-plugin auths are done through the 
> ''external'' method, which uses saslauthd, a hack as it
actually requires
> accounts to be created to work properly.  Saslauthd also only handles 
> passwords in plain text, communicates over an unsecure socket, runs as 
> root and is single-threaded....
Rich isn''t recommending the use of saslauthd, and developing a SASL 
plugin for whatever purpose is pretty easy.
> so the chain winds up being:
> 
> LDAP -> SASL -> plaintext sockect connection -> saslauthd ->
sasl-auth
> method -> auth server
> 
> SASL is quite good, but saslauthd is not so great.  It was never 
> actually intended for this, but as a proxy to deal with apps that did 
> not have SASL natively.
Agreed, saslauthd is junk.
>> > 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.  
> 
> I don''t disagree, but none of the vendors are providing this
capability.
>   The real world and the ideal situation are not really lining up....
>> > 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.
> 
> That''s the way it is right now, so yeah, extending PAM passthru
would be
> good.  SASL may be the long term future, but right now, it''s not 
> deployable except for one vendor''s mechanism.
You''ve identified a shortcoming but you''re going about fixing
it the
wrong way. Rich is trying to point you down the proper track; the right 
way is to get the desired SASL plugin written.
>> > Would you be able to write up something for the Fedora DS wiki,
like an
>> > informal software requirements doc?  
> 
> Sure, I can do that.  I''d even offer to look at some code, but
it''s been
> years since I authored anything in C and I know nothing of the Fedora DS 
> code....
<shameless plug>I work with both the OpenLDAP and Cyrus SASL Projects; 
my company Symas Corp. can easily develop what''s needed here and submit
it to Cyrus for you. Once you''ve got the requirements spelled out, come
talk to us.</shameless plug>

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

I have also been researching two-factor token support in LDAP recently.
What I found depressed me : other than RSA with Novell, there is
no, repeat NO support for using centralized LDAP authentication
with these things. The vendors will often mention LDAP, but
when they do it''s as a management database for their own
proprietary authenciation service, not as a way to use
LDAP for the actual authentication itself.

I did see a general obsession with PAM, I suspect because it''s
a handy way to insert these mechanisms underneath Unix for
terminal login. Same deal with RADIUS, presumably because
that allows the vendors to check the ''VPN'' checkbox.

But there seems to be no general purpose ''put my two factor
thing underneath my corporate LDAP authentication service''
solution (other than the aforementioned Novell/RSA product).
Not even for Active Directory.

Because there is some PAM support from the vendors,
providing a PAM proxy/passthrough path under the LDAP
server does turn out to be the most expedient option.

SASL would certainly be better, but I get the impression
that the token vendors haven''t heard of SASL yet.
They don''t seem to think in terms of general purpose
mechanism, but rather along the lines of ''ok how
do we make our token work for application X?''
(and they''ve provided solutions for the top N
popular applications where N is a small positive
integer, and called it good).

David Boreham wrote:
> I have also been researching two-factor token support in LDAP recently.
> What I found depressed me : other than RSA with Novell, there is
> no, repeat NO support for using centralized LDAP authentication
> with these things. 
And the RSA plugin only works on Win2k and Netware, neither of which 
would be my choice for a backend secure server.

http://www.rsasecurity.com/node.asp?id=2569

Never that it has not been updated or supported in about 5 years.

BTW, I have gotten CryptoCard to work with Fedora, and I''m just now 
working on PAM passthru.  Hopefully I''ll be able to write a howto in
the
next few weeks.

Chris.

-- 
Chris Maresca
Founding Partner
Olliance Group, LLC
www.olliancegroup.com
+1.650.331.1770 x201

Chris Maresca wrote:
> BTW, I have gotten CryptoCard to work with Fedora, and I''m just
now
> working on PAM passthru.  Hopefully I''ll be able to write a howto
in
> the next few weeks.
That''d be great. However in my experience it''s SecurID that
everyone
wants support for :(

I''m trying to get an eval copy.  It should be roughly the same and 
perhaps a little easier as they have more flexible LDAP support.

The tricky bit is PAM passthrough that I''m just now getting to (after 
around 2 weeks of fighting with all this...).

BTW, SASL has native SecurID support in it.  Don''t know if it works,
''tho.

Chris.

David Boreham wrote:
> Chris Maresca wrote:
> 
>> BTW, I have gotten CryptoCard to work with Fedora, and I''m
just now
>> working on PAM passthru.  Hopefully I''ll be able to write a
howto in
>> the next few weeks.
> 
> That''d be great. However in my experience it''s SecurID
that everyone
> wants support for :(
> 
-- 
Chris Maresca
Founding Partner
Olliance Group, LLC
www.olliancegroup.com
+1.650.331.1770 x201