Ilja Coolen \ ICSS

Well,

It has been quite a while since my last post. I’ve been very busy working on a number of storage proposals. Which I guess is good in this time of financial crisis.

I’ve been working on IBM San Volume Controller for a number of years, and I even had a contract as a Storage Instructor for IBM San Volume Controller.  I have had many questions or remarks as to why the SVC still had no support for role based access and centralized account administration like LDAP or Active Directory. And honestly, it did surprise me how long it took IBM to incorporate it into the code.
Only recently, the SVC code 6.3 has been released sporting AD and LDAP user authentication. I have not yet have any change to test LDAP, but I did get Active Directory working. The IBM documentation isn’t all that detailed as to how to setup AD authentication. Neither has the AD support team on site been very helpful (accept maybe for one guy who seems to know what AD is all about).

There are a couple of things you should be aware of;

• The SVC is an appliance that is not trusted by AD, it is not part of a Active Directory domain. Therefore you might need to provide an AD account that has sufficient credentials to use AD to authenticate.
• The account you will use to query AD with (not the account a user uses to attempt a login) has to be configured with it’s complete AD location path.an example: you are provided an AD account that is privileged  to query AD that is called ‘ibm2145queryad’ and sits in the AD tree at “DOMAIN\Accounts\ReadOnly” (<-fictional).You will need to enter the ldapconfiguration in the SVC console as;

  chldap -username 'CN=ibm2145queryad,ou=ReadOnly,ou=Accounts,dc=DOMAIN,dc=corp' -password 'XXXXXX' -security none -userattribute sAMAccountName -groupattribute memberOf -auditlogattribute name -type ad

• Even if AD authentication fails because the query user is not authorized to query AD, the ‘testldapserver’ will result in a success. If you are testing authentication of a valid user login, this will result in a message that the user is not correct or the password is mismatched. This suggests the user trying to login is invalid, but actually, the account used to query AD is invalid. So this might throw you of a bit.
• Only supply AD servers or LDAP servers, do not mix AD and LDAP servers. This will not work as desired.

Your SVC administrators have to be members of a specific security group in AD, separating them from ordinary users that should not have SVC access. This group name has to be defined in the SVC as a remote group. Only users that are member of that specific security group in AD will have access to the SVC. The user group on the SVC has to be configured with specific access rights on the SVC, like “administrator” or something else that matches your company requirements. This role is also assigned to AD users that are part of that security group at the moment the successfully log in to the SVC.
When using LDAP or AD user authentication, local users still are usable. You will need a local account with the “Security Administrator” privilege to update LDAP/AD settings on the SVC. I guess you do not want to make all authenticated users have the highest privilege on SVC.

Once you know these quirks you will  be able to configure and use LDAP or AD services to authenticate your SVC administrators with. Two things I have to comment about are the fact you cannot enter LDAP or AD servers by their hostnames. You need to enter the IPv4 addresses. This also shows the second annoyance. There is no support for IPv6 yet. I guess it is on it’s way, but who knows how long this will take IBM.