Hi Ben,
You're on the right track.
The design goal of LDAP-UX and most other LDAP/OS integration products is to use the directory server itself as the security policy enforcement point, instead of the OS itself. The shadow schema was defined to support a legacy mechanism (at least it's a legacy when it comes to LDAP integration), which would be used by the OS if the directory server didn't support its own security policy. However, there aren't any other LDAP-enabled applications that support the shadow schema, so there isn't much value in it since it doesn't provide for a uniformly enforced policy.
However, when the LDAP server itself supports the security policy, such as with slapo-policy, then all LDAP-enabled applications that authenticate to the directory server will defer to the centralized policy. LDAP-UX supports the password policy control 1.3.6.1.4.1.42.2.27.8.5.1. This control tells the directory server to return password policy details, such as "password expired". And my understanding is that newer versions of OpenLDAP do support this control. Refer to
http://www.openldap.org/lists/openldap-software/200606/msg00027.html for a short discussion.
So the short answer is, it should just work if you configure pam_ldap in your pam.conf file and configure policy support in OpenLDAP.
To your other point, you're also right at looking into pam_authz. It's not as simple as just using pam_ldap. It does exactly opposite of what I said above. pam_authz enforces the security policy on the OS, instead of the directory server. However it has at least two useful reasons for this. First, it can be used to supplement your current policy with a host-specific policy, such as defining a select set of users that are allowed to login to the host. For example, you can use an LDAP filter in the pam_authz.policy file to write a rule such as, "Only allow users that are active employees and work for the production team to login to this host". Assuming you have information in your directory server that represents that state, it might look something like "allow:ldap_filter:(&(employeeState=active)(team=production))".
The other useful reason for using pam_authz is when you want to manage user account information centrally, but you don't want to use the LDAP server for authentication. A simple example of this might be when you use ssh authentication keys for users. In this case, if a user uses his private key to authentication, sshd will never call the PAM authentication API, which means that pam_ldap will never try to bind (authtenticate) to the directory server. However, sshd does call the PAM account management API, which means that pam_authz can be used to evaluate the security policy in the directory server, even if the authentication process does not occur on the directory server.
Hope that helps!
Regards,
Bob
