Once a user has been authenticated, the account management features of the pam_ldap module provide two means of restricting access to a host, independent of any other PAM modules you may have specified in the configuration file (e.g., the pam_nologin module). Which method you choose depends on whether you wish to bind a host to a group of users or bind a user to a group of hosts.
The first
authorization method,
in which you specify a group of users who are allowed to use a
particular host, ties into other information you have already
migrated into the directory. The host entry for a machine (generated
from /etc/hosts by the PADL migration scripts)
can be extended to include a list of DNs for users
(member
) that are authorized to log on using
pam_ldap. The following LDIF example shows how you can use the
extensibleObject
class to associate a group of
users with a host entry:
dn: cn=pogo,ou=hosts,dc=plainjoe,dc=org objectClass: ipHost objectClass: device objectClass: extensibleObject ipHostNumber: 192.168.1.75 cn: pogo.plainjoe.org cn: pogo member: uid=gcarter,ou=people,dc=plainjoe,dc=org member: uid=kristi,ou=people,dc=plainjoe,dc=org member: uid=deryck,ou=people,dc=plainjoe,dc=org
In order to configure pam_ldap to honor this group membership, the following two lines must be added to /etc/ldap.conf:
## Define the DN of the entry to contain the groupOfUniqueNames. pam_groupdn cn=pogo,ou=hosts,dc=plainjoe,dc=org ## Define the attribute type that should be used in the attempt to match the user's ## DN. pam_member_attribute member
For OpenSSH, this configuration means that only those users whose DN
is listed as one of the values for the member
attribute will be allowed ssh access to your
host.
You can also specify
the machines that any given user is allowed to access. To implement
this control mechanism, the structural account
object class listed in the cosine.schema file
must be present in the list of object classes for an entry. This is
done for you by the PADL migration scripts. Figure 6-6 shows that the account
object class requires only one attribute. This attribute,
uid
, is already required by the
posixAccount
object class and is therefore
guaranteed to be present.
While several optional attribute types are available with the
addition of this new object class, only the host
attribute is of use to pam_ldap. The following LDIF listing shows how
the account object class can be used to control access:
dn: uid=gcarter,ou=People,dc=plainjoe,dc=org uid: gcarter cn: Gerald (Jerry) Carter objectClass: account objectClass: posixAccount objectClass: shadowAccount loginShell: /bin/bash uidNumber: 780 gidNumber: 100 homeDirectory: /home/queso/gcarter userPassword: {crypt}GoYLwzMD6cuZE host: queso.plainjoe.org host: pogo.plainjoe.org host: tumnus.plainjoe.org
This listing shows that the user gcarter is
allowed to access the hosts queso,
pogo, and tumnus. To enable
pam_ldap’s host-checking functionality, you must
enable the pam_check_host_attr
parameter in
ldap.conf:
## Enable host attribute lookups. pam_check_host_attr yes
If the list of hosts does not contain the hostname of the system that
the user wants to access, he is denied access. If the host list is
empty (i.e., no host
attribute is present), the
user is denied access by default.