RBM–Administrative Access & Security for DataPower

I generally recommend to clients that DataPower RBM (Role-Based Management) be configured to perform authentication and authorization of DataPower administrators and developers with LDAP.  In particular, whatever respository serves as the central repository of user information should be used (of course, it has to be able to understand the LDAP protocol (v2 or v3).  In my experience, this is typically Microsoft Active Directory(AD), but not always.

By tying DataPower administrative access into a user repository that  is already used throughout the enterprise, you are trying user provisioning of DataPower users (which is probably a small community) into existing user and role provisioning processes and auditing.  This is generally required for large organizations (most small organizations as well).  This is typically an easy sell to the information security department.

In order to be flexible, the configuration of DataPower RBM has numerous properties that need to be filled correctly.  I had originally envisioned a detailed, step-by-step configuration guide for setting up RBM with DataPower; however, someone beat me to itSmile.  And, I see little point in being redundant.  So, for detailed step-by-step instructions for configuring DataPower RBM to do authentication and authorization against LDAP/AD, look here.  I’ve referred to this link myself on several occasions.  It’s a lot of stuff to come up with from scratch.

For your environment, a number of details will be different.  Before you begin, you will need to know:

  • An LDAP bind user and password(you will need the full DN, passwords are case sensative).
  • The bind user must be able to read all users and groups in the LDAP tree (or at least the branch that DataPower will be looking at).
  • The Base DN of the tree node where DP should begin searching for Users.
  • The Base DN of the tree node where DP should begin searching for Groups (Roles).
  • The IP/host and Port of LDAP server (typically 389 or 636).
  • The SSL Server cert or issuing CA cert (for the creation of a Validation Credential Object).
  • Names of the group that will map to the roles being used on your appliances.
  • RBM role definitions.  Note, this can become quite complex.  It will map to your organizations definition of this.

If a users password or group membership information has changed recently and the user is having trouble logging in, flush the RBM cache (it’s a link on the RBM screen)

To avoid being locked out of the web console completely if a mistake is made, make sure that the “Local Login As Fallback” option is set to “specific users”.  Then, add the admin user to the list.  If the “Enforce RBM on CLI” option is selected, failure to do this will also effect SSH logins.  In that case, you’d have no choice, but to access the serial console and fix the RBM configuration-a moment when you’ll be glad you took the time to setup your terminal server.

It is also a good idea to create a second local user that had admin privileges equivalent to the admin user. 

Note, that there are some things that ONLY the admin user can do.  For example, only the admin user can log into the serial console.  So, if RBM becomes broken and you have lost the admin password, you will not be able to log into the serial console.  At this point, please refer to this.

Make sure that the secondary local admin account’s password is not lost.

Periodically, I’ll update this page as I come across relevant items.

Refer to the RBM documentation for more information.

This link also describes how to configure DataPower RBM for LDAP authentication and authorization.

This IBM Technote provides additional information for using RBM with AD.

Whenever one is working with LDAP, it is very useful to have access to an LDAP Browser.  In fact, I’d say it is beyond counterproductive to not be able to query the data in LDAP to see what is actually in there.  I tend use this one.