Ilja Coolen \ ICSS

I just read StorageBod‘s post on “Your Data, Your Responsibility” and I totally agree with him. You should really be very aware of the risks you are potentially facing when deciding to store all or most of your data in a cloud, no matter who’s cloud it is.

The remark on storing it in two different places triggered me to rethink something else in this context.

When you have decided you will not be open for the risk of storing the data with one cloud provider only, you might even consider having a different cloud provider for holding the second copy. Because if you store two copies at the same provider, you do not mitigate the risk of this single provider having a massive outage and possibly losing your data or even going “belly up”.

Selecting two cloud providers is most likely even more difficult than just one. You have to negotiate two Service Level Agreements, pricing models and such. If you consider all this effort and risk mitigation you are doing, is storing your stuff in the cloud still a lot cheaper or more convenient than providing for your own storage? Is the cloud still providing what you are looking for, such as reducing administrative labor, footprint, cost? I could only be sure about reducing footprint, the rest is dependent on a lot of other things.

I myself am very paranoid about losing data, so I always store all data I consider valuable in two different places.

I don’t have all the current prices for cloud storage services, so I cannot make a good comparison, but I am surely curious.

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.