SVC and Storwize V7000 Release 6.3: Configuring LDAP

Once your SVC or Storwize V7000 is upgraded to version 6.3 you can start using LDAP for authentication.   This means that when you logon, you authenticate with your domain user-id and password rather than a locally created user-id and password.

So why is this important?

  • It saves you having to configure every user on every SVC or Storwize V7000.   If you have multiple machines this makes it far more efficient to set up authentication.
  • It means that when commands are executed on the SVC or Storwize V7000, the audit log will show the domain username that issued that command, rather than a local username, or worse just superuser (i.e. who mapped that volume?  The superuser did…. who? )
  • It gives you central control over access.   If someone leaves the company you just need to remove access at the domain controller, meaning there won’t be orphan user-ids left on your Storage equipment.

So as an exercise I added my lab Storwize V7000 to our domain to show how it is done. This example also applies to an SVC so don’t be confused if I only refer to Storwize V7000 from now on.

The first task is to negotiate with your Domain administrator to get a new group setup on the domain.   In this example I use a group called IBM_Storage_Admins which lets me use this group for various storage devices (such as an XIV or a SAN Switch).

To create this group we need to logon to the Domain Controller and configure Active Directory.  An easy way to do this from the AD controller is to go to Start → Run and type dsa.msc and hit OK.    The Active Directory Users and Computers Management Console should open.

Select the groups icon to create a new group.

Enter your group name, in my case:  IBM_Storage_Admins and hit OK.

Now right select relevant users who need access to the storage and add them to the IBM_Storage_Admins group.  In this example I have selected Anthony (which uses anthonyv as a username).

In this example we are adding anthony into the IBM_Storage_Admins group:

Now it is time to configure the Storwize V7000 so start the Web GUI and logon as Superuser.

Firstly we go to Settings → Directory Services:

We choose the button to Configure Remote Authentication:

We choose LDAP and hit next.

We choose Microsoft Active Directory with no Transport layer Security.  We then expand the Advanced Settings.   My lab domain is ad.mel.stg.ibm so I use the Administrator ID on the Domain Controller to authenticate access.  You could use any user that has authority to query the LDAP directory.  We then hit Next.

We then add the domain controller which in this example is 10.1.60.50 and the base domain name chopped into pieces (so ad.mel.stg.ibm becomes dc=ad,dc=mel,dc=stg,dc=ibm ) and hit Finish.

Provided the command completes successfully we have defined the domain controller to the Storwize V7000.   Now we need to add a group.  Go to Access → Users.

Select the option to add a New User Group.

In this example we want to add a group for users allowed full admin access to the Storwize V7000.  This matches the group we created on the Domain Controller.  So we call the group IBM_Storage_Admins and we use the Security Administrator role (which is the most powerful role) and tick the box to enable LDAP for this group.

Now to test, I logon to the Storwize V7000 using the domain user-id anthonyv with that users domain password.   Remember this user is not defined on the Storwize V7000 itself and that if it all goes wrong, we can still logon as Superuser.

Now I create a volume and delete it.  Then I check the audit log from Access → Audit log.

Sure enough, we see exactly who did that command.

This is a great outcome for security,auditing and for easy access administration.

If you have issues, from the Settings → Directory Services menu, use the Global Actions dropdown on the right hand side to Test LDAP Connections and Authentication or re-configure LDAP.

Existing users

If you already have existing users (what we call Local users), configuring remote authentication using LDAP does not disable or invalidate those local user-ids.  This means you can either logon with a local user-id or logon with a Domain user-id.   This is handy if the domain controller fails but can confuse you if your local user name and your domain user name are the same name (for example both anthonyv).   The Storwize V7000 will look you up in the local user name list first.    I suggest removing all local users (except superuser) as this will reduce confusion but still leave you a backdoor in case remote authentication stops working.

 

If you see any mistakes or have suggestions to improve the way I described this, please let me know.

About these ads

About Anthony Vandewerdt

I am an IT Professional who lives and works in Melbourne Australia. This blog is totally my own work. It does not represent the views of any corporation. Constructive and useful comments are very very welcome.
This entry was posted in IBM Storage, Storwize V7000, SVC and tagged , , , , , , . Bookmark the permalink.

28 Responses to SVC and Storwize V7000 Release 6.3: Configuring LDAP

  1. Robert says:

    Local users still work after LDAP config? (Fallback if AD is dead).

  2. Pingback: SVC and Storwize V7000 Release 6.3: Configuring LDAP « Storage CH Blog

  3. I like the user interface. Thanks for the article.

  4. Pingback: SVC and Storwize V7000 Release 6.3: Performance Monitor Panel | Aussie Storage Blog

  5. Pingback: SVC and Storwize V7000 Release 6.3: Performance Monitor Panel « Storage CH Blog

  6. Morris Newman says:

    Hi Anthony,

    I used to work with you many years ago and Darryl put me onto this blog when he heard about the problem I was having finding information on how to set up AD. The interface is very good under 6.3 and I almost had it set up the right way, but was thinking that I would need to create an ldap user rather than by creating the group instead. I even looked in AD to see if the V7000 had created some pre-canned groups that related to each of the roles. Silly me for not looking for the simple answer.

    Anyway, the procedure was perfect and it worked first time after creating the AD group and linking it from the V7000. I vote for this to be added to the redbook, at the very least. The latest revision is still in draft, so please, please, please ask them to include this procedure.

    Thanks

  7. Rainer Schmider says:

    Hi @all,

    did anybody of you also receive the error “NULL” when trying to test the LDAP connection ?
    There’s no additional info, just error: “NULL”

    Best Regards and thanks in advance

    Rainer

  8. Chris Moore says:

    Hi Anthony
    Tried this tonight and the ldap service credentials – this only needs to be an AD user account as standard user accounts have read permissions?
    Is this account only used once or every time on an authentication cache refresh?
    Just uncomfortable using / creating a domain admin account just to perform an ldap lookup.

    Thanks
    Chris

    • Great question. I will confirm this. I am writing a follow up post on LDAP so this is good info to add.

    • Hi Chris.

      The user you use to collect the remote authentication details does not have to be a member of Domain Admins. It can be a regular user.

      As for cache, the Storwize V7000 or SVC will cache the LDAP credentials for 10 minutes to avoid the overhead of going back and forth to authenticate every single command. You can change the behaviour of the caching with the chldap command using ‘authcacheminute’.

      -authcacheminutes auth_cache_minutes
      (Optional) Specifies the period for which to cache authentication
      details.

      IBM_2076:STG_V7000:anthonyv>lsldap
      type ad
      enabled yes
      error_sequence_number
      username anthonyv@ad.mel.stg.ibm
      security none
      user_attribute sAMAccountName
      group_attribute memberOf
      audit_log_attribute userPrincipalName
      auth_cache_minutes 10
      nested_group_search off
      IBM_2076:STG_V7000:anthonyv>chldap
      CMMVC5733E Enter at least one parameter.

      IBM_2076:STG_V7000:anthonyv>chldap -authcacheminutes 30

      IBM_2076:STG_V7000:anthonyv>lsldap
      type ad
      enabled yes
      error_sequence_number
      username anthonyv@ad.mel.stg.ibm
      security none
      user_attribute sAMAccountName
      group_attribute memberOf
      audit_log_attribute userPrincipalName
      auth_cache_minutes 30
      nested_group_search off
      IBM_2076:STG_V7000:anthonyv>

      • Chris Moore says:

        Hi Anthony
        Thanks for that. All set up and working with one notable exception! One user has special characters in his password and every time he tries to log in and type a comma a back space happens.
        The other thing I found was the service IP’s need to be set up correctly before ldap and mail notifications will work.

      • Interesting. On my second lab machine, the service IP addresses are still defaults (192.168.70.121 and 122) and LDAP and notifications are both working correctly. I wonder if there was an IP address claash (perhaps those IPs were already in use on your network?).

        As for the comma causing back space, that certainly is easy to reproduce! I suspect that ‘feature’ has been there a while and is not an ldap issue in itself (since it occurs before you can even hit enter). Whats a little annoying is I can find a clear statement in the InfoCenter that a comma is not allowed in the userid, but no mention about rules in the password. In fact I can successfully create a local user with a comma in the password, that I can then not logon as. I will follow this one up. Either it should work or be clearly stated as not allowed.

      • Actually the comma in password issue only affects Web GUI. You can logon with CLI without an issue.
        Am chatting to support about it right now.

      • The issue with a password not working in the GUI if it contains a comma (you instead get a backspace) is fixed in 6.3.0.1 code which is now available for download. I just updated my machine and tested it to confirm the fix.

  9. Chris Moore says:

    I too had the service IP’s unconfigured. LDAP and mail notifications wouldn’t work (couldn’t find an LDAP server) until I configured the service ports, ironically with ip addresses on the same vLAN as my management IP’s. LDAP and mail the worked first time.
    The network switch ports are configured as access ports for my management vLAN, with management ip’s in that vLAN. I could ping the management IP’s externally, but from the v7000 couldn’t even ping the default gateway until the service IP’s were configured.

    • So the good news on the password issue (with commas) is that my problem record has been recognized as a defect and APAR IC80253 has been opened to resolve it. The fix should be in the next maintenance release of 6.3 code (e..g. 6.3.0.1 or whatever they call it). The apar number I quoted should appear in the release notes.

      As for your Service IP requirement, this is a mystery. I cannot reproduce the issue (in that I don’t get the same problem) so I cannot report it on your behalf. You could place a service call if you are truly keen. The good news is that we WANT you to set service IP addrs.. so there is some benefit in what you saw.

  10. CHEKHINA says:

    Hello Anthony,

    I test your howto but it doesn’t work for me. When I launch Test LDAP Connections it’s work but when i test LDAP Authentication and use administrator account or other I have always this error message “CMMVC7063E User authentication failed because one or more LDAP servers report an incorrect user name or password” but user/password it’s good. Can you help me please ?

    storwize version 6.3.0.2

    thanks in advance

  11. Are you sure you have the message right?

    CMMVC7063E
    The task cannot be initiated because the Distinguished Name that you have specified is not valid.

  12. CHEKHINA says:

    excuse me it’s CMMVC7069E
    User authentication failed because one or more LDAP servers report an incorrect user name or password.

    • Bjärn Steiner says:

      I had the exactly same error in our lab as well as at customer-installations. The problem solved as follow:
      The User for Administrating the AD is located direcly in the BASE-AD (as in Anthony’s example).
      My Group is not placed directly in the base of the AD (as it is at most of the AD’s in the world) but in a OU.
      First I have selected the BASE-AD as the searchpath (CN=Users,dc=domain,dc=com)
      If I wanted then to check my “Bind User” (which is in the Base) I get the error “CMMVC6518E The task has failed because no roles are defined for the current user on the cluster” (which is correct) and when checking a User out of the “Storage_Admin”-Group (which is not located in the Base-AD I get the error: CMMVC7069E User authentication failed because one or more LDAP servers report an incorrect user name or password.
      After changing the Serch Base to OU=StoargeGroups, CN=Users,dc=domain,dc=com the issue was solved. Now the login works with the Group-Users but no check for the Admin user is possible anymore (which I don’t care).
      Another solution could be the flag in the chldap -nestedgroupsearch. This I couldn’t test due my AD didn’t allow it.

  13. WTS says:

    What if the “IBM_Storage_Admins” group is not under the default “Users” directory in AD? What if my group is located at “Users\Admins\Storage” for example….

    Then what would I name the User Group on the SVC?

  14. Farida Acevedo says:

    Hi Anthony, great blog!
    I need to view the access log when Active Directory (SFU) users enter in my V7000 Unified system, do you know how can I do this?
    I only see commands in the audit log using the GUI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s