Symantec Access Management

Hello,

I am considering risks migrating the user store in siteminder from SUN to CA directories.

I am not sure if it is possible, we may be (MAY BE only) able to engineer a user directory that may not need reconfigure applications, or minimize the effort or reconfiguring. This may need the engineering work in dev to determine if this is possible.

I was standing on the skeptical side that we need to reconfigure, based on the possibilities we may not be able to engineer 100% like to like in terms of ou, groups, response attributes; that would need to reconfigure in multiple places (realms and policies).

Another risk is the breaking applications during migration in production. If we try the not reconfiguring approach, we would do a swap from SUN to CA. All the applications will points to CA directories. If some of the applications are not working and we cannot fix it right away, we have to swap all back to SUN? If there are only 5 or 6 applications I think I can fix it right away. (But they have 30 applications). Some applications may need to be broken for a period of time, waiting to be fixed. (All fixable though)

If we do the reconfiguring approach, we can put from SUN to CA in parallel and we can do it incrementally. Bad side is we need to reconfigure some policies one by one pointing to the new directories (lots of efforts and time). Another point is if both SUN and CA directory is up for a while, the data will be different. (Need another set of strategies to take care of this). And if we cannot re-engineer a 100% like to like, we need reconfiguring effort. 

I have been flip-flopping about which migration approaches I should take, we don’t need to come up with a decision right away. But we need to walk through this at some point during the project. I am going to discuss with teams and communities.

Thanks and regards,

Eric

I think migrating the user store from Sun LDAP to CA Directory is a huge risk.  If your company is anything like ours, applications access the user store directly (for queries, data pulls, etc.).  Changing that interface will likely cause numerous issues.

We are trying CA Directory as a policy store/session store/key store for a new deployment of SSO 12.52.  It's been tough to learn CA Directory as it is considerably different than the LDAP we've been using for these internal SSO stores.

Thank you

Hi,

May be you can try this in a test environment and see how it works out for you.

http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec483208.aspx

If any questions or road blocks, you can always open a support case with CA to troubleshoot further.

Thanks,

Hitesh Patel

I am going to try this very soon.

But even I tried this out and run smoothly.

This logistic issue will come out when we are approach from test to production

I would like see if I can collect some input from you guys first

its a risk but its manageable; many have done it successfully

test ; test ; test is the key

things you want to make sure

a) hardware capacity analysis to ensure all servers in dev / qa / prod can support new s/w platform ( we got burnt by h/w capacity )

b) not sure how your servers are geographically placed ( old sun dir servers VS  new CA Dir servers)  replication may be issue if located in different data centers

c) script based migration can reduce risk

I do not think application will break coz of policy store migration ; ( manual reconfiguration is NOT the idea I wud recommend )

Thanks

I will seek for advice if it is possible I can have a "USER" store migration (SUN to CA) without breaking any application (implies no reconfiguration).???

Thanks and regards<
Eric

I have not done the migration myself, but theoretically it should not be that difficult.

Migrating a policy store should be quite straight forward. Export the policy store using smobjexport or XPSExport depending on your source SiteMinder version and then use smobjimport or XPSImport to import the policy store into the target SiteMinder environment. Run XPSSweeper after the import to check for any errors.

While the administration of CA Directory and SunOne Directory is very different, they both support the LDAP protocol and thus from a programming and data structure perspective they should function the same. You will first need to configure the schema in CA Directory to support any custom object classes and attributes you are using, as well as any special attribute matching rules you may have implemented, but CA Directory should support all the attributes and DIT structures you are using in SunOne. You should be able to export your data from SunOne into .ldif files, and then import those .ldif files into CA Directory. If you replicate the same DIT structure and attribute names and types in CA Directory, which certainly should be possible, then any applications you have that use the LDAP protocl (or java JNDI or other similar APIs) to access the directory should work without modification (except perhaps to modify the IP address/hostname/ports used to access the directory).

The two biggest potential problems I foresee are:

1. If you use some sort of customized attribute value matching rules in SunOne, I don't know how they would map to CA Directory.
2. I do not know off the top of my head if the password hasing algorithms used in SunOne and CA Directory are the same or not, but you can determine that through testing if the documentation isn't clear about it. As a matter of fact, you may want to make use of this transition to deliberately make them different. Your old SunOne environment is probably using SHA1 hashing which is no longer considered secure. In CA Directory, you should select a more modern and secure hashing algorithm for the password attribute.

If the password hashing is not compatible, you can transparently migrate your passwords using a custom SiteMinder authentication scheme. To do this you copy the SunOne password into a custom string type attribute in  CA Directory with a name like SunOnePassword that is not marked as a password attribute, and also create a boolean attribute, with a name like PasswordMigrationFlag. The custom auth scheme would check the migration flag to see if the user's password has been migrated or not. If migrated, it would simply use the standard Authentication API authenticate function to validate the password. If not migrated, the auth scheme would hash the user's password using the same hashing algorithm that SunOne uses, and then compare the hashed value to the value in the SunOnePassword attribute. If they match the user's clear text password would be set in the UserPassword attribute of CA Directory and the PasswordMigrationFlag set. The CA Services Global Deployment team has written many of these password migration auth schemes in the past if you don't have the expertise in house.

Of course as other people have noted, this whole migration would need to undergo extensive testing in order to reduce the risks of having something not work in production.

Thank you very much for your comments.

Yes, you are correct, there may well be dependencies in your applications that rely on Sun’s implementation of ou, groups, responses attributes, schema, etc, that may not be identical in the new CA directory. Depending on our environment you may also have Sun specific or extended attributes and a directory structure that will need to be present in the new directory also. So the risk of just cutting over your applications from your Sun environment to a copy in the new CA environment is high.

I would suggest considering using a virtual directory as a layer of abstraction between the two directories. The right virtual directory will allow you to first capture the structure, schema, users, and groups of the existing Sun directory. By redirecting the applications to this layer of abstraction you can first proxy the exact backend Sun directory to ensure the applications still function. Once application functionality is confirmed you will be able to start to understand the structure and schema of the Sun directory and create in the abstraction layer a representation of that structure in a CA directory schema.  Leveraging the abstraction layer you can extend the CA schema to meet attribute requirements,  remap attribute labels, and create multiple new directory structures to support your current and future application requirements.

Throughout this process you identities still exist in the Sun Directory providing full application functionality. Then when you are ready you can re-path the applications to a new View in the abstraction layer to verify that full application functionality is supported.  Should you need to fail back to the original View you simply re-path the application back to the View that represents the legacy Sun environment. Once all applications have been fully tested against the new Views based on the CA schema you can create the final structure in the new CA directory and then migrate the users and group objects.

At this point you have the ability to directly point the applications to the new CA directory or continue to leverage the abstraction layer to provide additional flexibility and potentially to provide legacy schema, structure, or attributes that are not supported in the new CA directory.

If this process is implemented effectively using a virtual directory capable of proxying, storing, remapping, restructuring, translating, and transforming your legacy Sun environment into your new CA environment you should be able to achieve this migration without reengineering your applications.

This video may provide you with additional information and things to consider.  https://www.youtube.com/watch?v=CksKoqvOU0Q

BTW,

I have another technical consideration here, it may br more opreational, logistics.

If I am allowed to run SUN and CA in parallel for a transition period in a live environment.

I would need to import the data to CA user directory in Feb.

The IdentityMinder and Siteminder is pointing at the user directory. I am going to renable or reengineer the rules and policies based on this set  of user data.

It takes me 2 - 3 months to do reengineering and testing.

It is May or June now.

The data in SUN directory is different. May be the data CA directory is different.

How can I manage the data discrepencies between the CA and SUN user directories?

(best practices?). It can be operational or logistics arrangement ...

ANy suggestions?

Thanks and regards,
Eric

Any more suggestions for Eric?

Thanks