I’ve been administering 3Par arrays for the past 5 years for my organization, and only recently have we bothered with LDAP authentication.  We are running 3.1.1 MU2 on our primary array, and wanted to start bringing in additional administrators to lighten my workload, so LDAP seemed the best way.

Typically I perform most tasks from the GUI, however for LDAP configuration, save yourself a headache and go to the CLI.  The GUI has problems with some of the fields (such as being obvious about what data they want entered), and the CLI just makes more sense once you start looking at the requirements.

The nice thing about this particular implementation of LDAP is that it’s relatively AD aware, but not what I would call optimal.  Optimal would be specifying the domain, and having the system pull in the domain controller and kerberos server information for you.

Instead, we have to specify a particular domain controller (which leaves you open to failing to authenticate during patching/reboot cycles – hope you don’t mind) and the specific kerberos server (same problems).

I see this a lot with non-MS products (and poorly written .Net products).  I wish someone, somewhere would tell these guys that their coding laziness is pathetic.  You know, like I just did.  Hint, hint.

Anyhow, on to the settings and commands.

Notable commands:

• showauthparam – Used to display the current content of your authentication parameters.  If none are set, this will show up empty.
• setauthparam – Used in conjunction with a parameter name and a value, which will set the parameter.
• checkpassword – Used to test out credentials.  Keep in mind the system will check locally for the user and then check LDAP credentials, so if you’re trying to use an account named the same locally as well as in LDAP, then it will fail out if you’re not using the local password.  It does NOT attempt to authenticate against LDAP if it fails locally.

Settings:

The following are examples of commands that will produce a configuration that worked in my environment.  I run a relatively flat environment with a decent amount of domain controllers, however as it’s not fully AD-aware, it’s going to be pointed towards 1 domain controller.  I’ve cleansed the data, but it should all make sense shortly.

Parameters and example data.

You can see that the parameters ending in “attr” are actually the AD attributes that contain the data that the authentication mechanism is looking for when it performs its queries.  Kerberos realm MUST be in all caps.  Note that the “super-map” value (the DN of the admin group) has no spaces; if your DN includes spaces, enclose the DN in double quotes to insure that it maps properly.

Running those commands on the CLI (adjusted for your environment) will yield a configuration that will allow for checking a username, as shown below:

Though it’s heavily redacted, you can get the gist of the process that it goes through to connect and validate that the user is a member of the appropriate group.  I first displayed the parameter values using showauthparam, then I tested the configuration using checkpassword.

Once this is complete and comes back clean, you’re on your way to logging on with your domain credentials.  And hopefully HP/3Par will one day build in the ability to enable pass-through authentication similar to how the VMWare vSphere Client functions.