Sign Up For The Free Newsletter

August 14, 2012

August 14, 2012 CA IdentityMinder - Security Is Off By Default - The User Store

OK, so you have IdentityMinder installed, the user store built and are able to get in and start creating users. Everything is going fine and working. But have you checked your systems with a security hat on? Have you read through the documentation to make sure everything is installed and configured to a production level? Even if you have you may have easily missed a few things that would place your organization in a huge risk. IdentityMinder, by default, has pretty much every critical security feature turned off.

As I uncover them, a post will be generated, because I have been through many training courses and read through the documents and no where, no one (other than the field experienced) tells you this. "Oh by the way, the password field in the user store is wide open."

I only caught it because I was in the database for another reason and just noticed that all my account's passwords were in clear text. Then it took a treasure hunt to find out why and longer to fix it.



Here's how to do it.

Note: In the current bookshelf from CA, which is 12.6 as of Aug. 13, 2012, the documentation is CORRECT. In prior bookshelves the information is NOT 100% correct and consistent across the manuals which could lead to this not working.

In my environment I am using SQL 2008 as my user store and Identity Management database, separate DBs of course. The provisioning server is using the out of the box CA Directory.

I created my user store using the Sample NeteAuto configs which I modified. This saves so much time and hassle over trying to create one myself. I decided against using AD for my userstore for other business and control reasons.

To enable encryption for the password field you need to modify the directory XML file.

From the IdM Management Console, go into the directory you created. In the bottom right click export and save the XML file. You will edit this and then update your directory. DO NOT CHANGE THE FILE NAME.

You be adding a Data Classification to the password entry. However, in the documentation these instructions  are under LDAP User Store Management not Relational User Store, you need to do it anyway.

CA Manual Location
Configuration Guide > LDAP User Store Management > User,Group, and Organization Managed Object Descriptions > Managing Sensitive Attributes

In the XML file locate the Password entry and add/modify the DataClassification tag.
< ImsManagedObjectAttr description="Password" maxlength="0" valuetype="String" displayname="Password" physicalname="tblUsers.password" wellknown="%PASSWORD%"> 

< DataClassification name="AttributeLevelEncrypt"/ >

Now, like I said before this is where older documentation from CA, pre-12.6, is inconsistent and incorrect. The attribute MUST BE AttributeLevelEncrypt - It's case sensitive. In the older docs, must places that reference it are attributlevelencrypt. I spent a while trying to figure out why the day before I did it on one DB it worked and when I rebuilt it and added it failed.

After you add it Restart the environment(s) that use that DB then go change your password. Now RC2 encrypted, if you are using FIPS-140-2 it will use that.

Be diligent in your security reviews, don't trust that the default or simple installation/configuration is locked down. Password is the big one but there will be other pieces you will want to be encrypted, like you security question answers, hints, etc...

Assume everything is the Microsoft approach, wide open until you lock it down.

End of Line.

P.S. ** Tease for the next post ** 
     There is another location where passwords are in clear text and accessible to anyone that has access to a certain section in the main IdM site.

1 comments:

MC said...

Thanks for sharing your concern. Input from our customers, evangelists like you helps us enhance the product further to meet our customers needs. Per our discussion...The fundamental architecture of the CA Identity Manager (IM) is that the customer owns the user schema, the user data and the backend directory server. The customer is therefore in the best position to determine how to configure IM to manage that data. This configuration includes what attributes should/should not be encrypted. For any ldap vendor that defines a password as part of their user schema there is typically built-in LDAP server encryption support based on the attribute’s syntax. CA IdentityMinder products supports LDAP as a user store and thus passwords are always encrypted. Production deployments typically use LDAP in which case the password is encrypted by default by the LDAP server. Relational Database is seldom used as a user store in production environments which explains why this default settings was not considered as a security concern for the OOTB sample. We are committed to making sure the data we manage is always protected and secure . We are therefore fixing the sample as proposed by this post and turning this setting on by default and provide a warning if its turned off by the customers.

Also, would like to encourage your readers to visit the CA community site to get in touch with the broader CA customer base that uses CA IdentityMinder . Here is the link :http://community.ca.com
-CA IdentityMinder Product Management

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Laundry Detergent Coupons