On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 04:28, Daniel Eischen wrote:
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 00:47, Ben Morrow wrote:
Quoth Jan Bramkamp <cr...@rlwinm.de>:
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access
control.
With ldap in nsswitch.conf for users and groups you can lookup a LDAP
user but the user can't log into $service through PAM. This requires
pam_ldap.so in pam.d/$service.
The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable
passwords in its result I think pam_unix can authenticate against those.
This is not the same as authenticating by LDAP bind, but may end up
accepting the same passwords.
If you want every process to read your hashed passwords and you use
non-portable crypt hashes it could work. The correct solution would be
authenticate users by LDAP binds without allowing anyone to read the
password or to use the {SASL} password style and authenticate users
against Kerberos with saslauthd. Just don't let you users play with
passwords. Either your password policy allows dumb users to pick trivial
password or it forces complex password structures on them resulting in
post-it notes with passwords around every second desk.
I think something is lost on me here. getpwent/getpwuid do
not return the password hashes in the returned struct passwd
unless the calling process is root. So you have to be root in
order to see the hashes anyway. Not all users are going to
have access to the hashes, unless your machine's compromised
or otherwise allows root privileges to others.
If the crypted password can be read by an LDAP client with the
information available to every process in (nss_)ldap.conf you're crypted
passwords are easily accessible for offline attacks. Their is no reason
for an attacker to go through the getpwent/getpwuid API.
The root bind password is kept in a separate file that only
root has read rights to. I don't think the password hashes
are available when binding anonymously or through the proxy
agent.
--
DE
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
