LDAP-UX with Openldap and Shadow attribs

I've got a great setup of an openldap directory that I can authenticate posixaccounts to running on HP-UX 11.31.

I have added the shadowaccount objectclass and the shadow attributes (shadowLastChange, shadowWarning, etc) to the posixaccount entries.What changes do I need to make to have the OS/LDAP-UX read and enforce these attributes?

Re: LDAP-UX with Openldap and Shadow attribs

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.

Re: LDAP-UX with Openldap and Shadow attribs

Bob - Thank you very much!

This whole experience has been an adventure to say the least...

You input clarifies this greatly and confirms some of what I have been hoping to be true all along.

Unfortunately I have been working with the OpenLDAP as distributed with the Internet Express which was not compiled with the ppolicy module (go figure)! I have been attempting to recompile from source (the README.hp file in /opt/iexpress/openldap/) however this is terribly annoying and I don't think I have the patience to see it through.

What I may do is end up running the directory on linux as my time for this project is pretty much up. It was pretty cool though, I had a nice ServiceGuard package rigged up with TLS and everything...

Re: LDAP-UX with Openldap and Shadow attribs

Hi again Ben,

I'll notify our IE team of the issue with OpenLDAP. But I do have a quick question...

Have you considering using the Red Hat Directory server provided with HP-UX? It's an enterprise-class and fully supported directory server, that's similar to the Sun Java DS (came from the original Netscape/iPlanet alliance). RHDS version 8.0 released in Nov08. It should be easy to install and do a quick prototype. Licensing is no charge for internal use (suites OS management very well) and competitive pricing for extranet use.

Re: LDAP-UX with Openldap and Shadow attribs

Bob,

I have initially thought of using RHDS, however to be honest all of the requirements scared me off a little. I am looking to use this directory in a clustered environment and openldap (on the surface!) seemed to be simpler to setup as I could make it highly available and avoid worrying about replication.

If I use RHDS, then I would want to setup an additional cluster member as a replication partner. Is that difficult to do? However, now that I think about it it may be a better idea because I could throw my printers in there too... Hmm...

Regardless, at this point if I can't get any solution working in the next day or two I'll be sticking with local users for this project.

I appreciate all of your help with this. I'll return to RHDS this afternoon and load it on a test box to see if it will be easy enough to configure.

Re: LDAP-UX with Openldap and Shadow attribs

I finally decided to keep the openldap dir that I configured in serviceguard and rig up a few scripts for some artificial pw aging. Not super great (or fool proof), but it will work for my current needs. (They're basically just wrappers for the ldapuglist and ldapugmod commands that came with ldapux.)

I did try out RHDS and while it has everything I need, I don't have time to learn how to implement it as well as I would like right now.

Re: LDAP-UX with Openldap and Shadow attribs

So the solution is to implement the password policy overlay in openldap, however to do this in HP-UX you need to compile from source as the Internet Express version does not appear to be configured with this module. pam_authz policies can also be used to enforce account lockouts.

Obviously the more complete and recommended solution is to use RHDS or AD.

0
Kudos

The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.