6881
Comment: fix typo
|
6878
|
Deletions are marked like this. | Additions are marked like this. |
Line 102: | Line 102: |
account required pam_access.so | auth required pam_access.so |
Configuring LDAP Authentication
There are basically two ways to configure PAM to use LDAP credentials. The first way uses the pam_ldap module from the libpam-ldap package to try to log into the LDAP server when checking passwords. With the second way password hashes are exposed from the LDAP server to the clients using NSS and use the traditional pam_unix module does authentication. pam_ldap can be used in this situation to change passwords. Both solutions have their pros and cons.
In both cases the users should be exposed through NSS. Only for the second way it is needed for getent shadow to return password hashes when run as root.
The pure pam_ldap solution allows limiting logins by how users are stored in the directory (e.g. only allow logins for users in a certain piece of the directory, require some attribute, etc). It also requires less access rights to the LDAP directory and does not expose password hashes.
The pam_unix solution is possibly more familiar to system administrators.
PAM setup with pam_ldap
In order to globally enable LDAP authentication through PAM, configure /etc/pam_ldap.conf accordingly and edit the /etc/pam.d/common-* files so that they contain something like this:
/etc/pam.d/common-account:
account required pam_unix.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
/etc/pam.d/common-auth:
auth sufficient pam_unix.so nullok_secure auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so
/etc/pam.d/common-password:
password sufficient pam_unix.so md5 obscure min=4 max=8 nullok try_first_pass password sufficient pam_ldap.so password required pam_deny.so
/etc/pam.d/common-session:
session required pam_limits.so session required pam_unix.so session optional pam_ldap.so
Note that there are numerous ways to configure PAM, depending on your particular situation and preference. The above only attempts to use pam_ldap if the userid is not below 1000 (i.e. normal user accounts).
PAM setup with pam_unix
(there have been reports that the following does not work as described, please correct if needed)
It is also possible to use plain old pam_unix by making sure /etc/nsswitch.conf contains something like shadow: files ldap and getent shadow shows password hashes.
If only authentication is needed, no changes to PAM configuration files should be necessary. For changing passwords, login shell and gecos install libpam-ldap, configure /etc/pam_ldap.conf and edit /etc/pam.d/common-password to contain something like this:
password required pam_ldap.so ignore_unknown_user md5 password optional pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass
Note the 'md5' setting. This will ensure passwords are encrypted into MD5 digests when they are changed. You may also need to add pam_password md5 to /etc/pam_ldap.conf for this to work.
Creating home directory on login
Include this in /etc/pam.d/common-session if you want to automatically create home directories when users first login:
session required pam_mkhomedir.so skel=/etc/skel umask=0022
Allowing logins on a per-host basis
The pam_ldap module provides the ability to specify a list of hosts a user is allowed to log into, in the "host" attribute in LDAP. The host attribute can be specified multiple times for each user. If any of the entries match the hostname (of the machine logging in to), login is succesful. Otherwise, login is denied.
This feature is enabled by specifying pam_check_host_attr yes in /etc/pam_ldap.conf. When it is enabled, the account facility of pam_ldap will perform the checks and return an error when no proper host attribute is present.
The hostname in the "host" attribute on the user can be prefixed with "!" to deny access to that host for that user. This is mostly useful in conjunction with the special entry "*", which allows access to all hosts.
To add the "host" attribute to a user, he should have an objectClass that supports this. The "account" objectClass has the attribute, but is not compatible with the "inetOrgPerson" objectClass. To work around this, you can use the "ldapns" schema, supplied with the libpam-ldap package. This schema provides the "hostObject" objectClass, which has the proper "host" attribute.
To enable this schema, add the following line to your slapd.conf:
include /usr/share/doc/libpam-ldap/ldapns.schema
Finally, take care that the hostname of the server is resolvable. pam_ldap will try to resolve the hostname, to find any aliasses (such as listed in /etc/hosts). If the hostname is not resolvable, access is denied.
Allowing logins on a per-group basis
A common task is to restrict logins to a given LDAP group. With NIS, you would do this with careful tweaking of your /etc/passwd file. With LDAP, the easiest way is to use the pam_access module that comes with libpam-modules.
Add the following line to /etc/pam.d/common-auth:
auth required pam_access.so
This will activate /etc/security/access.conf, to which you can tweak as follows:
# disallow all except people in the login group and root -:ALL EXCEPT root login:ALL EXCEPT LOCAL
This assumes you have a posixGroup named login in your LDAP tree with LDAP/NSS set up properly. Be careful about ensuring that you can still allow local users to login in case LDAP fails.
Permissions on the LDAP server
To get 'chsh' and 'chfn' to work for updating LDAP, you have to have the right settings in their /etc/pam.d/ entries, and you have to setup slapd.conf to allow access for users to update their entries. If needed, add something like this to slapd.conf:
access to attrs=loginShell by dn="cn=admin,dc=FOO,dc=BAR" write by self write by * read
access to attrs=gecos by dn="cn=admin,dc=FOO,dc=BAR" write by self write by * read