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.
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.