Richard Megginson
2006-Nov-08 19:38 UTC
Re: [Fedora-directory-users] 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.
Chris Maresca
2006-Nov-08 20:24 UTC
[Fedora-directory-users] PAM passthru questions and SecureID
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
Chris Maresca
2006-Nov-08 21:12 UTC
Re: [Fedora-directory-users] PAM passthru questions and SecureID
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
Richard Megginson
2006-Nov-08 21:21 UTC
Re: [Fedora-directory-users] PAM passthru questions and SecureID
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.
Chris Maresca
2006-Nov-08 23:08 UTC
Re: [Fedora-directory-users] PAM passthru questions and SecureID
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
Richard Megginson
2006-Nov-09 02:20 UTC
Re: [Fedora-directory-users] PAM passthru questions and SecureID
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.
Chris Maresca
2006-Nov-09 09:14 UTC
Re: [Fedora-directory-users] PAM passthru questions and SecureID
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 serverYes, 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