LDAP and PAM--is it really necessary?

[Keith Keller]

This isn't *really* offtopic, since some of the issues I'll bring up
may help Slackware users integrate with an LDAP server. But some of
these issues are sorta OT. At any rate, this is all based on my ad-hoc
research and actually attempting to implement LDAP with Slackware,
so not everything here is necessarily 100% accurate (though I doubt
it's too far off).

Anyway, as you may know, I asked Pat about why he decided to leave out
PAM support in Slackware, and he gave a very thorough answer about how
it's coded fairly poorly and is entirely too complex. I certainly
can't speak to the first point, but PAM definitely is more complex
than perhaps it needs to be. Unfortunately, it's the primary method
for configuring a linux client to authenticate against an LDAP server.

It is possible to configure Slackware to use libnss_ldap (available from
www.padl.com) for LDAP authentication, but it's not ideal, in that you
are required to either a) allow read access to all users' userPassword
attribute at the LDAP server, or b) provide an LDAP DN which has at
least read access to all users' userPassword attribute at the LDAP
server. Option b) is okay if you're the admin of that client, but if
you have people who have root at their client, then to use LDAP without
PAM you basically give those people rights to read others' password.
(It's only the crypted password, but it's still the equivalent of giving
all your users read access to /etc/shadow.)

The one reason PAM is nice in this regard is that PAM alleviates these
problems with using libnss_ldap. With PAM, when a user attempts to log
in, the bind to the LDAP server is attempted as that user, not as an
anonymous or "rootbinddn" user. So a PAM linux client can be configured
to authenticate against an LDAP server without exposing the userPassword
attribute, and without providing a dummy account that can read the
userPassword attribute.

The upshot of all this is, unless you have a compelling need for PAM and
LDAP, you can usually get away with just implementing nss_ldap for LDAP
authentication. It won't be perfect, but it'll be a lot easier than
dealing with PAM.

Keep in mind that this only applies to the LDAP *clients*--if you want
to run an LDAP server on Slackware to let other clients authenticate,
go ahead. If you also want your Slackware LDAP server to authenticate
against itself, then you'd need to deal with libnss_ldap or pam_ldap.

- --keith

- --
kkeller-***@wombat.san-francisco.ca.us
(try just my userid to email me)
alt.os.linux.slackware FAQ: http://wombat.san-francisco.ca.us/cgi-bin/fom

[Blumf]

Post by Keith Keller
This isn't *really* offtopic, since some of the issues I'll bring up
may help Slackware users integrate with an LDAP server.

Is PAM/LDAP the only way for a linux system to manage users across a whole
network (as opposed to the per box user managment a normal linux system
has)?

If it is this screams the question 'why hasn't anybody worked out a better
way?' It all seems to be a messy after thought when it should be at the
core of a network capable OS.

Blumf

[Mark Hill]

On 2003-08-06,

Post by Blumf
Is PAM/LDAP the only way for a linux system to manage users across a whole
network (as opposed to the per box user managment a normal linux system
has)?

I *think* kerberos does this sort of thing also, but I may be completely
wrong.

[C. Newport]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Keith Keller
This isn't *really* offtopic, since some of the issues I'll bring up
may help Slackware users integrate with an LDAP server.

Is PAM/LDAP the only way for a linux system to manage users across a whole
network (as opposed to the per box user managment a normal linux system
has)?
If it is this screams the question 'why hasn't anybody worked out a better
way?' It all seems to be a messy after thought when it should be at the
core of a network capable OS.

You can use NIS or NIS+ , both are supported.
Be prepared to deal with the security issues of NIS and the messy
complexity of NIS+ though.

[Keith Keller]

Post by Blumf
Is PAM/LDAP the only way for a linux system to manage users across a whole
network (as opposed to the per box user managment a normal linux system
has)?

No--some others are NIS, Kerberos, even a Windows PDC can serve as an
authentication server for linux. NIS is not really securable, Kerberos
is quite difficult to configure (moreso than installing PAM on
Slackware), and other options are not native to linux.

Post by Blumf
If it is this screams the question 'why hasn't anybody worked out a better
way?' It all seems to be a messy after thought when it should be at the
core of a network capable OS.

LDAP is the better way--other unices do not necessarily require PAM.
(IRIX, IIRC, does not require PAM to do LDAP authentication, though I
haven't tried it yet.) The frustration stems from the fact that, since
almost all linux distros *do* support PAM, there has not been a push to
decouple LDAP authentication from linux-PAM. (Sounds a little like
embrace-and-extend to me....) I'm sure the push will come, either for
Slackware to adopt PAM (if it ever gets less messy) or for linux-LDAP to
stop requiring PAM (if more people push for it). I'm hoping for the
latter, but I don't think either will be coming any time soon.

That being said, keep in mind that PAM is only beneficial in the
following scenario:

- --you use LDAP for network-wide authentication
- --you have linux clients who want to authenticate against the LDAP
server
- --''untrusted'' users have the root password on those clients
- --you want user passwords to be effectively shadowed

If, for example, you have linux clients where the users have root on
a client, but don't care if they can read the crypted passwords of
others, using libnss_ldap is sufficient. This is comparable to almost
any NIS network where using shadow maps is complicated and inconsistent.
Or, if you and the admins are the only folks with root passwords on your
network, libnss_ldap is also sufficient, as nonroot users can not access
the rootbinddn password in ldap.secret (providing you chmod it 600,
which you should). I'm using this strategy on the boxes where only I
have root, and it works just fine, so there are ways of using Slackware
with LDAP.

Anyway, LDAP is a relatively new protocol, so as it gets better I think
support will become more universal. We hope. :)

- --keith

- --
kkeller-***@wombat.san-francisco.ca.us
(try just my userid to email me)
alt.os.linux.slackware FAQ: http://wombat.san-francisco.ca.us/cgi-bin/fom

[Realto Margarino]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

killfile all pgp-trash trolls.

[Keith Keller]

Post by Keith Keller
That being said, keep in mind that PAM is only beneficial in the
- --you use LDAP for network-wide authentication
- --you have linux clients who want to authenticate against the LDAP
server
- --''untrusted'' users have the root password on those clients
- --you want user passwords to be effectively shadowed

PAM can be beneficial (if not needed) if you want to have a certain
application authenticate using some other exotic protocol. it's not
just LDAP.
this however will only require this application to be recompiled with
PAM support, and nothing else on the system needs to be touched.
maybe you didn't want to cover other scenarios using PAM, but the
line above (that starts with "That being said") doesn't mention LDAP :)
maybe i'm just nitpicking, or maybe i just read that line wrong. but
i just felt like adding this info :)

No, I wrote the line wrong. :) Jurgen's correct, of course--it's
even more nontrivial to authenticate against a Windows PDC (pre-AD)
without PAM, for example, and I'm sure there are 20 other ways to
do authorization for which PAM is helpful. (Of course, few are as
prevalent in un*x-like shops like NIS and LDAP are.)

- --keith

- --
kkeller-***@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

[Menno Duursma]

Post by Blumf

Post by Keith Keller
This isn't *really* offtopic, since some of the issues I'll bring up
may help Slackware users integrate with an LDAP server.

Is PAM/LDAP the only way for a linux system to manage users across a whole
network (as opposed to the per box user managment a normal linux system
has)?

Normally Sun NIS/NIS+ (formally YP) is used.
For NT domains that would be NTLM - which SAMBA and SASL can work with.
For just autenticating users Radius or Kerberos might be used.

Post by Blumf
If it is this screams the question 'why hasn't anybody worked out a better
way?'

Well, though options might not be all that easy or secure - they do work...
And you'll have to transfer the password over the network some how - be it
over IPSec, SSH, SSL/TLS or whatever - not fantastic.
Kerberos uses encripted ticets to avoid this. That does however mean the
"server" box (KDC) needs to be _realy_ secure.

Post by Blumf
It all seems to be a messy after thought when it should be at the
core of a network capable OS.

Some RFCs define this:
rfc2078 - GSSAPI (is Kerberos v5), rfc2222 - SASL, rfc2251 - LDAPv3

You can freely use MIT (or Heinal) Kerberos, CyrusSASL and OpenLDAP.
<http://www.bayour.com/LDAPv3-HOWTO.html>

At least Sun and Novell have (GUI) tools to support this stuff.
Though RFC incompatible (who would have thought) M$ AD works the same way.

[Bilbo]

Post by Menno Duursma
For just autenticating users Radius or Kerberos might be used.

I am led to believe that kerberos - and sasl for that matter - are
needed by a LDAP server to secure it.
Am I wrong? Sure hope so, kerberos complicates the issue a lot.

[Menno Duursma]

Post by Bilbo

Post by Menno Duursma
For just autenticating users Radius or Kerberos might be used.

I am led to believe that kerberos - and sasl for that matter - are
needed by a LDAP server to secure it.

No, not "needed by a LDAP server to secure it" is is however the most
secure sinle-sign-on method i know of.
The complexity of it all even makes config/coding errors more likely.
(On paper) it should be more secure than without though.

Post by Bilbo
Am I wrong? Sure hope so, kerberos complicates the issue a lot.

You could store encripted passwords in LDAP derectly and use SSL/TLS to
comunicate with the DB - if the server gets cracked, hashes in wrong hands.
<http://www.ameritech.net/users/mhwood/ldap-sec-setup.html>
Morever SSL (even v3 and TLS 1.0) are vulnerable to MIM atack -
thus maybe allowing to retrieve the password hash.
<http://www.counterpane.com/ssl.html>

The Plan9 method (called "Factotum") seems better:
<http://plan9.bell-labs.com/plan9dist/factotum.html>
There was talk about a port to Linux (by Sun) - i have not seen that jet.
Though the Inverno system might be word a look.
<http://www.vitanuova.com/inferno/4thedoverview.html>

[gh]

Post by Keith Keller
Anyway, as you may know, I asked Pat about why he decided to leave out
PAM support in Slackware, and he gave a very thorough answer about how
it's coded fairly poorly and is entirely too complex. I certainly
can't speak to the first point, but PAM definitely is more complex
than perhaps it needs to be. Unfortunately, it's the primary method
for configuring a linux client to authenticate against an LDAP server.

Isn't PAM part of dropline gnome for Slackware? Won't this work for
your app?

gh

[Keith Keller]

Post by gh
Isn't PAM part of dropline gnome for Slackware? Won't this work for
your app?

Why the hell would I install GNOME just to get PAM?!? On a server
that doesn't even run X, no less. Sure, it'll work, but that don't
make it right.

- --keith

- --
kkeller-***@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

[Realto Margarino]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

killfile all pgp trash trolls.

[дамјан г.]

Post by Keith Keller

Post by gh
Isn't PAM part of dropline gnome for Slackware? Won't this work for
your app?

Why the hell would I install GNOME just to get PAM?!? On a server
that doesn't even run X, no less. Sure, it'll work, but that don't
make it right.

You dont need GNOME to use the PAM Slackware package from Dropline.
But then again you ussually don't need PAM on a server (where the added
complexity may be a security problem)...

In my view PAM is best used in corporate workstations, where the enterprise
would need central authentication etc..

[anthony]

дамјан г. wrote:
|>>Isn't PAM part of dropline gnome for Slackware? Won't this work for
|>>your app?
|>
|>Why the hell would I install GNOME just to get PAM?!? On a server
|>that doesn't even run X, no less. Sure, it'll work, but that don't
|>make it right.
|
|
| You dont need GNOME to use the PAM Slackware package from Dropline.
| But then again you ussually don't need PAM on a server (where the added
| complexity may be a security problem)...
|
| In my view PAM is best used in corporate workstations, where the
enterprise
| would need central authentication etc..
|
|
Unless on your server you want to have:
old passwords remembered and restricted to re-use

which I like.

acqant

[Realto Margarino]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pgp trash is best killfiled

[дамјан г.]

Post by anthony
| You dont need GNOME to use the PAM Slackware package from Dropline.
| But then again you ussually don't need PAM on a server (where the added
| complexity may be a security problem)...
|
| In my view PAM is best used in corporate workstations, where the
enterprise
| would need central authentication etc..
|
|
old passwords remembered and restricted to re-use
which I like.

The point that I wanted to make (but I failed to deliver) is that on a
server (except a terminal server) you dont have people loging to get a
shell access where PAM would be most usefull.

The servers are ussually accessed trough its HTTP daemon, POP3 daemon, FTP
daemon etc... where it may be more practical and flexible to implement
your own authetication scheme using the daemon functioality itself.

[Realto Margarino]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Killfile all pgp trash trolls.