6.7 Authorization Through PAM

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.

6.7.1 One Host and a Group of Users

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.

6.7.2 One User and a Group of Hosts

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.

Figure 6-6. Schema for the account object class

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.