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

Chris Maresca wrote:
> All,
>
> I''ve been looking longingly at the PAM pass-through module as it
would
> give us access to capabilities we''ve wanted for a while. 
I''ve looked
> at the README, but I still have a few questions.
>
> 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.

But these do seem like very interesting features - how would this work?  
via a special attribute in the user''s entry?
>
> 3. Has anyone deployed it in a production environment?
>     If so, what type(s) of PAM auth did you use?
Yes.  We developed this and use this internally at Red Hat (dogfood, 
yum).  We use it because we use Kerberos for internal authentication, 
but some older LDAP clients can''t do SASL, so they do simple auth, and 
pass the credentials through to Kerberos via PAM.
>
> Also, if anyone has any successful examples of using two-factor 
> authentication tokens (specifically either SecureID or CryptoCard, but 
> also others), I would love to hear about them.  It seems that none of 
> the vendors providing token-based support LDAP as a primary user info 
> repository directly, which is odd, to say the least.
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.
> I''d like to add that compared to OpenLDAP, Fedora DS is a breath
of
> fresh air.  Thanks for making it available.
>
> Chris.

All,

I''ve been looking longingly at the PAM pass-through module as it would 
give us access to capabilities we''ve wanted for a while.  I''ve
looked at
the README, but I still have a few questions.

1. Is it possible to specify PAM as the authentication on a per-account 
basis?
2. Is it possible to specify authentication escalation on failure on a 
per account basis?
3. Has anyone deployed it in a production environment?
	If so, what type(s) of PAM auth did you use?

Also, if anyone has any successful examples of using two-factor 
authentication tokens (specifically either SecureID or CryptoCard, but 
also others), I would love to hear about them.  It seems that none of 
the vendors providing token-based support LDAP as a primary user info 
repository directly, which is odd, to say the least.

I''d like to add that compared to OpenLDAP, Fedora DS is a breath of 
fresh air.  Thanks for making it available.

Chris.
-- 
Chris Maresca
Olliance Group, LLC
www.olliancegroup.com

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.

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.
> 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.

Thanks for the info.

Chris.
-- 
Chris Maresca
Olliance Group, LLC
www.olliancegroup.com

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.

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

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.

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....

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.
> 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.
> 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....

Chris.

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