We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

Hi,

you can have more than LDAP server configured and it will work as long as the names are unique across the LDAPs. If they are not there will be an entry in the CPE error log and one of the users will be selected (probably the first one).

Do not forget that WAS/WLS also plays a role ... authentication happens there!

There ARE reasons for multiple LDAPS, but migrating LDAPs is not one of them.

We have done LDAP migrations in the past but with support of IBM labs, which have the tool  you mentioned, and it works fine. The challenging part is to get the mapping right, then it is no problem.

The way you describe is extremely error prone and complex, I do not recommend taking that route.

Hope this helps,

Gerold

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

Hi Kiran, 

As mentioned you can engage IBM and they will map the users / groups from one LDAP to another. You will need the users in your second directory prior to IBM starting and a mapping of user to new user / group if you intend to make changes. Refining one point you can have the same users or groups in a second directory then use the LDAP filters / base to isolate the systems as you transition.  

As a second option I have an application I wrote for FileNet 'Power Tools' for importing, managing and exporting data in FileNet.  LDAP move is one of the features which relies on the API but also does cleanup a big difference is you can transition using this software versus flipping over and do a system at a time easily. I have had cases where FileNet sites wanted to move to a new LDAP repo, change LDAP types or add a new LDAP type but not impact the other environments. Basically LDAP and ECM tasks that require a slower transition and coordination amongst teams. Consider if you have three tiers of FileNet and an existing LDAP, you have a new LDAP and the company wants to test FileNet DEV, QA then eventually production.  This makes the 1x IBM LDAP change more difficult to do versus a longer transition period you control with this software.  You could set up the new directory, add to the FN GCD, add to your app server and when you are ready do a security export from FileNet per object store. The export includes all ACLs from the object store for everything contained in it (classes not instances).  Edit the file, replace unmatched SIDs if you have any, change to your new groups for the items you want to change also assign default owners which is very important.  Next step import the updated file using the software which will update the class/property templates in the object store.  Last step is adjusting the instances of documents using the same software or if you know you have a set value for all documents you update one document with desired security for that class, grab the security ID then do a dbo.Docversion update set security_id = 'mynewid' where class_id = 'myclassid I just updated'. BAM, done.  IBM tools will update the existing security object instead of assigning a new one in docversion FYI. 

Another use case example I was working with a customer that was using Oracle LDAP and they were changing the LDAP type from one Oracle product to another. So it wasn't one to one where its winAD the same product different versions this was a different product altogether.  The LDAP directory structure changed as part of a security realignment, security certs the whole thing. During this project I replaced the default P8 admin account with a new one, ran both LDAP's side by side for awhile, then removed the original LDAP once other downstream applications were ready. 

If you have in house developers you can certainly write your own code for this. Working with ACL's is rather easy compared to some of the other functions we do with the FileNet API.

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

Jay Thank you so much for your time explaining the details,  based on your response , is it fair to assume that, if we use Power Tools each row in the DocVersion table need to be touched but if the IBM tool is used , it will directly update the security descriptor table and no changes needed on the doc version ? wondering if we can avoid DocVersion updates.

Can you throw some light on the ACL's updating/replacing approach, my concern is the which order we go about it and how do we make sure all the ACL's are updated before shutting down the current directory server A ?

Thanks

Kiran Aithagani

Hi Kiran, 

As mentioned you can engage IBM and they will map the users / groups from one LDAP to another. You will need the users in your second directory prior to IBM starting and a mapping of user to new user / group if you intend to make changes. Refining one point you can have the same users or groups in a second directory then use the LDAP filters / base to isolate the systems as you transition.  

As a second option I have an application I wrote for FileNet 'Power Tools' for importing, managing and exporting data in FileNet.  LDAP move is one of the features which relies on the API but also does cleanup a big difference is you can transition using this software versus flipping over and do a system at a time easily. I have had cases where FileNet sites wanted to move to a new LDAP repo, change LDAP types or add a new LDAP type but not impact the other environments. Basically LDAP and ECM tasks that require a slower transition and coordination amongst teams. Consider if you have three tiers of FileNet and an existing LDAP, you have a new LDAP and the company wants to test FileNet DEV, QA then eventually production.  This makes the 1x IBM LDAP change more difficult to do versus a longer transition period you control with this software.  You could set up the new directory, add to the FN GCD, add to your app server and when you are ready do a security export from FileNet per object store. The export includes all ACLs from the object store for everything contained in it (classes not instances).  Edit the file, replace unmatched SIDs if you have any, change to your new groups for the items you want to change also assign default owners which is very important.  Next step import the updated file using the software which will update the class/property templates in the object store.  Last step is adjusting the instances of documents using the same software or if you know you have a set value for all documents you update one document with desired security for that class, grab the security ID then do a dbo.Docversion update set security_id = 'mynewid' where class_id = 'myclassid I just updated'. BAM, done.  IBM tools will update the existing security object instead of assigning a new one in docversion FYI. 

Another use case example I was working with a customer that was using Oracle LDAP and they were changing the LDAP type from one Oracle product to another. So it wasn't one to one where its winAD the same product different versions this was a different product altogether.  The LDAP directory structure changed as part of a security realignment, security certs the whole thing. During this project I replaced the default P8 admin account with a new one, ran both LDAP's side by side for awhile, then removed the original LDAP once other downstream applications were ready. 

If you have in house developers you can certainly write your own code for this. Working with ACL's is rather easy compared to some of the other functions we do with the FileNet API.

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

Jay Thank you so much for your time explaining the details,  based on your response , is it fair to assume that, if we use Power Tools each row in the DocVersion table need to be touched but if the IBM tool is used , it will directly update the security descriptor table and no changes needed on the doc version ? wondering if we can avoid DocVersion updates.

Can you throw some light on the ACL's updating/replacing approach, my concern is the which order we go about it and how do we make sure all the ACL's are updated before shutting down the current directory server A ?

Thanks

Kiran Aithagani

Hi Kiran, 

As mentioned you can engage IBM and they will map the users / groups from one LDAP to another. You will need the users in your second directory prior to IBM starting and a mapping of user to new user / group if you intend to make changes. Refining one point you can have the same users or groups in a second directory then use the LDAP filters / base to isolate the systems as you transition.  

As a second option I have an application I wrote for FileNet 'Power Tools' for importing, managing and exporting data in FileNet.  LDAP move is one of the features which relies on the API but also does cleanup a big difference is you can transition using this software versus flipping over and do a system at a time easily. I have had cases where FileNet sites wanted to move to a new LDAP repo, change LDAP types or add a new LDAP type but not impact the other environments. Basically LDAP and ECM tasks that require a slower transition and coordination amongst teams. Consider if you have three tiers of FileNet and an existing LDAP, you have a new LDAP and the company wants to test FileNet DEV, QA then eventually production.  This makes the 1x IBM LDAP change more difficult to do versus a longer transition period you control with this software.  You could set up the new directory, add to the FN GCD, add to your app server and when you are ready do a security export from FileNet per object store. The export includes all ACLs from the object store for everything contained in it (classes not instances).  Edit the file, replace unmatched SIDs if you have any, change to your new groups for the items you want to change also assign default owners which is very important.  Next step import the updated file using the software which will update the class/property templates in the object store.  Last step is adjusting the instances of documents using the same software or if you know you have a set value for all documents you update one document with desired security for that class, grab the security ID then do a dbo.Docversion update set security_id = 'mynewid' where class_id = 'myclassid I just updated'. BAM, done.  IBM tools will update the existing security object instead of assigning a new one in docversion FYI. 

Another use case example I was working with a customer that was using Oracle LDAP and they were changing the LDAP type from one Oracle product to another. So it wasn't one to one where its winAD the same product different versions this was a different product altogether.  The LDAP directory structure changed as part of a security realignment, security certs the whole thing. During this project I replaced the default P8 admin account with a new one, ran both LDAP's side by side for awhile, then removed the original LDAP once other downstream applications were ready. 

If you have in house developers you can certainly write your own code for this. Working with ACL's is rather easy compared to some of the other functions we do with the FileNet API.

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A 

Hi Kiran, 

The security ID in docversion points to the security object SecurityDesc but document instance security change is just one task of several that need to be completed. Answering your question IBM can update the existing security object in that table making whatever user/group changes that are needed they could also pull a report showing any unmatched SIDs before you go live.

Powertools approach is API or you have the option of direct DB update. Taking it one step at a time you would first need to add your new LDAP to GCD and app server, define your users and groups same or different, then using the software you will export a security report per object store that retrieves ACLs on all classes/objects. Using notepad++ or other XML editor you can find and replace groups/users or append new. Save the file then you are going to import the XML security file which runs the job against the object store and updates the classes/templates/cvls all the items you see in ACCE.  Your XML security import can be a one time move and replace all old security groups/users or you append your new groups to the XML and import. You can then test all the new groups/users then run the security report again this time removing objects from the previous LDAP. 

Now you still have to update instances of objects- you can use the software to do this which leverages the API or you can do a direct database update. A new instance of each doc class is created to act as a template, the ACL security guid is used to update docversion where class = same class set security ID = my newly obtained ID.

If you know you are apples to apples in LDAP move then the IBM tool makes the most sense. If you need control, testing, move one environment at a time, security cleanup or re-assignment, changing class instance ownership that sort of thing the Power Tools application or your own custom code will allow you to do that.   

Jay Thank you so much for your time explaining the details,  based on your response , is it fair to assume that, if we use Power Tools each row in the DocVersion table need to be touched but if the IBM tool is used , it will directly update the security descriptor table and no changes needed on the doc version ? wondering if we can avoid DocVersion updates.

Can you throw some light on the ACL's updating/replacing approach, my concern is the which order we go about it and how do we make sure all the ACL's are updated before shutting down the current directory server A ?

Thanks

Kiran Aithagani

Hi Kiran, 

As mentioned you can engage IBM and they will map the users / groups from one LDAP to another. You will need the users in your second directory prior to IBM starting and a mapping of user to new user / group if you intend to make changes. Refining one point you can have the same users or groups in a second directory then use the LDAP filters / base to isolate the systems as you transition.  

As a second option I have an application I wrote for FileNet 'Power Tools' for importing, managing and exporting data in FileNet.  LDAP move is one of the features which relies on the API but also does cleanup a big difference is you can transition using this software versus flipping over and do a system at a time easily. I have had cases where FileNet sites wanted to move to a new LDAP repo, change LDAP types or add a new LDAP type but not impact the other environments. Basically LDAP and ECM tasks that require a slower transition and coordination amongst teams. Consider if you have three tiers of FileNet and an existing LDAP, you have a new LDAP and the company wants to test FileNet DEV, QA then eventually production.  This makes the 1x IBM LDAP change more difficult to do versus a longer transition period you control with this software.  You could set up the new directory, add to the FN GCD, add to your app server and when you are ready do a security export from FileNet per object store. The export includes all ACLs from the object store for everything contained in it (classes not instances).  Edit the file, replace unmatched SIDs if you have any, change to your new groups for the items you want to change also assign default owners which is very important.  Next step import the updated file using the software which will update the class/property templates in the object store.  Last step is adjusting the instances of documents using the same software or if you know you have a set value for all documents you update one document with desired security for that class, grab the security ID then do a dbo.Docversion update set security_id = 'mynewid' where class_id = 'myclassid I just updated'. BAM, done.  IBM tools will update the existing security object instead of assigning a new one in docversion FYI. 

Another use case example I was working with a customer that was using Oracle LDAP and they were changing the LDAP type from one Oracle product to another. So it wasn't one to one where its winAD the same product different versions this was a different product altogether.  The LDAP directory structure changed as part of a security realignment, security certs the whole thing. During this project I replaced the default P8 admin account with a new one, ran both LDAP's side by side for awhile, then removed the original LDAP once other downstream applications were ready. 

If you have in house developers you can certainly write your own code for this. Working with ACL's is rather easy compared to some of the other functions we do with the FileNet API.

We have a FileNet system uses Directory server A  for Authentication and Authorization. Can we have another  Directory Server B configured along with that simultaneously ? the long term idea is to migrate the users and groups from A to B, update the FileNet security on the taxonomy objects/classes and then remove A from CPE Directory configuration and shutdown Directory Server A. I would appreciate any directions or documentation specific to this approach 

Also, I believe IBM does this with a Tool, that directly interacts with Database and updates the security descriptors  and points to new Directory server, but I would like to hear from people who had some hands on experience doing one way or the other.

Thank you.

Kiran A