- Copy the helper file appropriate to your ldap server from <wp_profile>/ConfigEngine/config/helpers directory and set values to match your LDAP configuration for the properties
- Execute the ConfigEngine.bat validate-standalone-ldap configuration task that will validate the values of the LDAP that you set in helper file
- Next execute the ConfigEngine.bat wp-modify-ldap-security task to make the actual changes in the portal security
- Restart the DMGR, All Node Agents and all cluster members.
- Copy the helper file that you changed on primary portal node to the secondary portal node.
- Copy the content of helper file into the main wkplc.properties by running the following command
ConfigEngine.bat
-DparentProperties=/ConfigEngine/config/helpers/wp_security_ids.p
roperties -DsaveParentProperties=true
Important Note: Did you notice that we did not mention any config task name here. Instead just specified parentProperties and savenParentProperties parameter. This will only change the wkplc.properties file. - Update the Portal security information on the secondary node by executing the following ConfigEngine script from the
/ConfigEngine directory on your secondary node:
ConfigEngine.bat wp-change-portal-admin-user -DnewAdminId=admin ID> -DnewAdminPwd= -DnewAdminGroupId= Admin Group ID> -Dskip.ldap.validation=true
Note: The -Dskip.ldap.validation=true flag can be used if the script fails during ldap validation. - Restart the secondary node's WebSphere Portal server
Showing posts with label securityincluster. Show all posts
Showing posts with label securityincluster. Show all posts
Enabling security in clustered environment
Enabling security in clustered environment is little different from enabling security in the standalone environment. Follow these steps to enable security in clustered environment
Using External security manager in cluster
If you are configuring security for IBM WebSphere Portal with an external security manager, review the additional considerations described in this section, depending on the external security manager that you are using. Perform any configuration for an external security manager after you have completed all other setup, including ensuring that the WebSphere Portal cluster is functional.
The following considerations apply to all external security managers:
The following considerations apply to all external security managers:
When setting up security in a cluster to use an external security manager, ensure that you configure either TAM or Siteminder on each of the portal nodes.- If you make any changes to the external security manager configuration after initially setting it up, ensure that any changes you make to the wkplc.properties file are propagated to the other nodes in the cluster. Changes to the wkplc.properties file are not included as part of the cluster resynchronization process.
- If you are using an external Web server, additional configuration is required before running any task to configure an external security manager with a WebSphere Portal cluster. Edit the wkplc.properties file on each node, and ensure that the values for the wp.ac.impl.JunctionHost and wp.ac.impl.JunctionPort properties are set to the backend server host name and port number you are using for your Web server.
Considerations for security during cluster installation and fedrations
When setting up a cluster, there are two scenarios that must be considered. The first scenario is when the default VMM file-based repository security is used at both the WebSphere Portal nodes and the deployment manager until after the WebSphere Portal cluster is completely set up. Prior to federating the first WebSphere Portal node into the cell, the required group for WebSphere Portal administrators must be defined in the deployment manager’s security repository. Once the cluster has been set up, you can modify the security settings of the cell. Although it is possible to modify security in the cell using the WebSphere Application Server administrative interfaces, you should use the WebSphere Portal security tasks to change cell security in order to ensure that the security configuration settings for WebSphere Application Server and WebSphere Portal are identical.
The second scenario is when the existing deployment manager cell has already modified its default security setting prior to the first WebSphere Portal node joining the cell. WebSphere Portal supports the capability of using two different sets of administrative user ID and password credentials when federating a WebSphere Portal node into a cell – one set for the WebSphere Portal node authentication and one set for deployment manager authentication. This means that it is not necessary to define a common administrative user ID before WebSphere Portal joins the cell. If the deployment manager cell is using federated VMM with additional repositories, WebSphere Portal will pick up this configuration dynamically from the deployment manager when it joins the cell. If the deployment manager cell is using standalone LDAP security, however, then it is necessary to configure the LDAP values into the WebSphere Portal property files before federation to enable WebSphere Portal to dynamically adapt to the existing standalone LDAP security settings of the cell. As with the first scenario, once the cluster has been set up then security changes to the deployment manager cell security settings can be made using the WebSphere Portal security tasks, and additional WebSphere Portal nodes may be added to the cell following the same procedures.
The tasks under Setting up a clustered production environment recommend configuring security before configuring your additional nodes but if you configure your security after configuring your additional nodes or if you need to update your security configuration after you have created your clustered environment, you will need to run an additional task to update the security settings on the secondary nodes; see Configuring security after cluster creation for information.
The second scenario is when the existing deployment manager cell has already modified its default security setting prior to the first WebSphere Portal node joining the cell. WebSphere Portal supports the capability of using two different sets of administrative user ID and password credentials when federating a WebSphere Portal node into a cell – one set for the WebSphere Portal node authentication and one set for deployment manager authentication. This means that it is not necessary to define a common administrative user ID before WebSphere Portal joins the cell. If the deployment manager cell is using federated VMM with additional repositories, WebSphere Portal will pick up this configuration dynamically from the deployment manager when it joins the cell. If the deployment manager cell is using standalone LDAP security, however, then it is necessary to configure the LDAP values into the WebSphere Portal property files before federation to enable WebSphere Portal to dynamically adapt to the existing standalone LDAP security settings of the cell. As with the first scenario, once the cluster has been set up then security changes to the deployment manager cell security settings can be made using the WebSphere Portal security tasks, and additional WebSphere Portal nodes may be added to the cell following the same procedures.
The tasks under Setting up a clustered production environment recommend configuring security before configuring your additional nodes but if you configure your security after configuring your additional nodes or if you need to update your security configuration after you have created your clustered environment, you will need to run an additional task to update the security settings on the secondary nodes; see Configuring security after cluster creation for information.
Cluster security options
There are many security options that can be used in a cluster. All of the VMM federated security options, including multiple LDAP repositories, database repositories, and the default file-based repository can be used. Additionally there is an option to use standalone LDAP security instead of the VMM federated security approach.
Note: It is not recommended to use the file-based repository in a production environment. The reason is that updates are only possible through the WebSphere Application Server administrative console, not through portal user management. These updates are sent to each node in the cell using deployment manager file synchronization. This can be time consuming for large volumes of users and groups. Also, synchronization does not occur at the same time for all nodes in a cell, so there will be time windows when the nodes in the cell have differing security definitions.
Note: It is not recommended to use the file-based repository in a production environment. The reason is that updates are only possible through the WebSphere Application Server administrative console, not through portal user management. These updates are sent to each node in the cell using deployment manager file synchronization. This can be time consuming for large volumes of users and groups. Also, synchronization does not occur at the same time for all nodes in a cell, so there will be time windows when the nodes in the cell have differing security definitions.
Cluster Security
WebSphere Portal 6.1 depends on Virtual Member Manager (VMM) for security. The VMM configurations are applied at the cell level and maintained at the Deployment manager level. When you federate a node into the Deployment manager it wont change any of the deployment manager security settings instead any changes that you made at the portal level will get lost and portal will inherit the security settings at the Deployment manager level.
Note: If administrative security is deselected during installation of the deployment manager or is disabled after the deployment manager is installed, it must be enabled prior to executing the security configuration tasks on the WebSphere Portal cluster members.
WebSphere Portal provides a number of security tasks, which can be used to modify the WebSphere Application Server security settings and make the required updates to the WebSphere Portal configuration in a single step. As soon as a WebSphere Portal node is federated into a deployment manager cell, all WebSphere Portal security tasks will execute on the deployment manager. Run security tasks after federating the WebSphere Portal node because the Deployment Manager cell does not contain the configuration resources required to run the security tasks.
Note: If administrative security is deselected during installation of the deployment manager or is disabled after the deployment manager is installed, it must be enabled prior to executing the security configuration tasks on the WebSphere Portal cluster members.
WebSphere Portal provides a number of security tasks, which can be used to modify the WebSphere Application Server security settings and make the required updates to the WebSphere Portal configuration in a single step. As soon as a WebSphere Portal node is federated into a deployment manager cell, all WebSphere Portal security tasks will execute on the deployment manager. Run security tasks after federating the WebSphere Portal node because the Deployment Manager cell does not contain the configuration resources required to run the security tasks.
Subscribe to:
Posts (Atom)