ldap vs pam auth

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ldap vs pam auth

Andrei-Florian Staicu
Hi,

In your (anyone's) opinion, is it better to do auth directly against
AD (LDAP, no SSO), or to use PAM + SSSD?
The upside to LDAP is that there are some guides, but for PAM I
couldn't find anything. On the other hand, SSSD is very easy to setup.

Thanks.

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Foswiki-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/foswiki-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ldap vs pam auth

Colas Nahaboo
I guess then that it will be better for the community for you to try PAM + SSSD so that you can write a quick guide for it too :-)

Colas.

PS: If you do not manage to use PAM, know that there should not be issues going with LDAP, other than LDAPS not being usable on some Debian versions due to bugs in library.

On 12 April 2014 09:04, Andrei-Florian Staicu <[hidden email]> wrote:
Hi,

In your (anyone's) opinion, is it better to do auth directly against
AD (LDAP, no SSO), or to use PAM + SSSD?
The upside to LDAP is that there are some guides, but for PAM I
couldn't find anything. On the other hand, SSSD is very easy to setup.

Thanks.

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Foswiki-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/foswiki-discuss



--
Colas Nahaboo - http://colas.nahaboo.net

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Foswiki-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/foswiki-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ldap vs pam auth

Chris Hoefler
In reply to this post by Andrei-Florian Staicu
The direct ldap approach is nice because it is easy and well-supported. I have a few external applications, including Foswiki, that authenticate to AD this way. There is a fair amount of flexibility in group mapping, user attributes, and authentication schemes. For Foswiki specifically, you can use the template auth, which is customizable and pretty, and user authorization roles can be flexibly mapped to ldap attributes. There are some disadvantages, though. A few that come to mind,
  - You will need a bind user on your AD. There is no Kerberos or keytab binding support. There was a patch posted about a week ago by Alan to provide GSSAPI methods, so it might be worth looking at. I've found the bind user to not be a serious problem, but it can be a potential security hole and your directory policy may not allow it.
  - Since AD (and LDAP) are just directories, applications need to know specifically how to use the user and group attributes to meet their needs. That is, they need to effectively be able to map these attributes. Foswiki is more flexible than most at this, I've noticed, so I doubt you will have any problems...
  - ...but there are different schemas for different directories. The schema for AD is very different from rfc2307, which is a basic ldap user directory. In AD, for example, there is no uid attribute. Fortunately, Foswiki is flexible enough to accommodate different schemas, but not all applications are. One problem in Foswiki is primary group mapping. Foswiki knows how to do this with an rfc2307 schema, but AD does this differently, and last time I checked Foswiki couldn't map AD primary groups. One workaround is to extend the AD schema to use unix attributes, but this is not always possible or desirable.

Passing off authentication to the web server is the other method you were asking about. This might be more useful in some situations, where you want multiple applications to use the same auth scheme, for example, but I don't think you gain much from it generally.
Some possible advantages,
  - Authentication is handled by the web server using one of the _auth modules. This allows for direct support of things like kerberos (personally, I wouldn't use pam as system login policies are mostly meaningless to a web server, which is the major strength of pam).
  - Low level authorization (do you have access to this page?) is also handled by the web server.
  - Real kerberos will be more secure than storing session information in cookies.

Some disadvantages,
  - Login screens are handled by the web browser and not easily customizable.
  - Login caching and persistent sessions become a feature of the web browser that the web server cannot easily control.
  - Expiration of the kerberos ticket becomes an additional consideration when handling session information.

Some things that would benefit a shell or ftp user, but don't really help a Foswiki user,
  - SSSD will mostly be useless because its strengths, offline credential caching and uid mapping, will not be used by the web server.
  - Fine-grained authorization and roles will have to be implemented by the application anyway, so you don't gain much from the low-level authorization provided by the _auth module (ie: you will still need to setup and configure ldap mapping).
  - System policies such as tty restrictions or mandatory environment variables (provided by pam) won't be used by the web server.

Not sure if any of this really answers your question. Bottom line: in the absence of a special need or use case, go with the direct ldap approach. This is what we use and it works well.


> On Apr 12, 2014, at 2:04 AM, Andrei-Florian Staicu <[hidden email]> wrote:
>
> Hi,
>
> In your (anyone's) opinion, is it better to do auth directly against
> AD (LDAP, no SSO), or to use PAM + SSSD?
> The upside to LDAP is that there are some guides, but for PAM I
> couldn't find anything. On the other hand, SSSD is very easy to setup.
>
> Thanks.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Foswiki-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/foswiki-discuss

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Foswiki-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/foswiki-discuss