Following article describes how
to configure portal cluster with federated LDAP repository manually (using configengine tasks) , you can do the same from WAS Console
also (Click here for how to configure from WAS Console)
- Installed TDS succesfully and installed Softerra LDAP browser (or Admin) to browser LDAP users
- Prior to configuring security, you should use the IBM WebSphere® Application Server backupConfig task to create and store a backup of the IBM WebSphere Portal configuration; see backupConfig command for information.
Backup
Command
- Make sure to start DMGR, Node Agent and Portal servers.
- From the primary node, Modify the following properties in wp_add_federated_ids.properties (in the <wp_profile>/ConfigEngine/config/helpers directory).
federated.ldap.id=PortalLdap
federated.ldap.host=sivapc.sivavaka.com
federated.ldap.port=389
federated.ldap.bindDN=cn=root
federated.ldap.bindPassword=Passw0rd
federated.ldap.ldapServerType=IDS
federated.ldap.baseDN=dc=sivavaka,dc=com
- Execute the following ConfigEngine script to validate the properties:
./ConfigEngine.sh
validate-federated-ldap
-DparentProperties=<wp_profile>/ConfigEngine/config/helpers/wp_add_federated_ids.properties
-DsaveParentProperties=true
-DWasPassword=wasadmin
NOTE:
By using the
-DparentProperties=<wp_profile>/ConfigEngine/config/helpers/wp_add_federated_ids.properties
-DsaveParentProperties=true flags, ConfigEngine will automatically save the
properties from the helper file into the wkplc.properties file
- Execute the following ConfigEngine script to add the federated LDAP to the cluster securityconfiguration
./ConfigEngine.sh
wp-create-ldap -DWasPassword=<current password>
C:\IBM\WP72\WebSphere\wp_profile\ConfigEngine>ConfigEngine.bat
wp-create-ldap -DWasPassword=wasadmin
NOTE: This script does not remove or replace the out-of-the-box file user registry. Instead, it adds the ldap to the security configuration, so that both federated repository and the file based user registry are in use. Your Portal Administrator User ID, Portal Administrator Group ID and WAS User ID are still in the default out-of-the-box file user registry.
- Restart the DMGR, the nodeagent on the primary node, and the WebSphere_Portal server on the primary node (Need stop in this order to populate the security information properly and start DMGR, nodeagent & websphere_portal).
- IMPORTANT: If you happen to have a user in your ldap that shares the same shortname as your current Portal/WAS Administrator from the out-of-the-box-file registry, you will need to execute the following ConfigEngine script before proceding with the remaining steps:
./ConfigEngine.sh
wp-modify-realm-enable-dn-login -DWasPassword=<password>
Failure
to run this script now can cause authentication problems for the remainder of
these steps. Again this is only needed if you have duplicated shortname IDs.
For example, your original ID is:
uid=wpadmin,o=defaultWIMFileBasedRealm
and if you have another 'wpadmin' ID in your LDAP:
uid=wpadmin,o=users,dc=mycompany,dc=com
If
you try to login to Portal, you will be unable to login to Portal using the
shortname. This will only be temporary and will be corrected at the end of
these steps
- Execute the following ConfigEngine script to verify that all defined attributes are available in your newly added ldap:
./ConfigEngine.sh
wp-validate-federated-ldap-attribute-config -DWasPassword=<current
password>
ConfigEngine.bat
wp-validate-federated-ldap-attribute-config
-DWasUserId=uid=wasadmin,o=defaultWIMFileBasedRealm -DWasPassword=wasadmin
- Mapping Attributes
ConfigEngine.bat
wp-query-attribute-config -DWasUserId=uid=wasadmin,o=defaultWIMFileBasedRealm
-DWasPassword=wasadmin
Overview of the currently available attributes
Attributes for PersonAccount
|
PortalLdap
|
InternalFileRepository
|
businessAddress
|
not
supported
|
✔
|
businessCategory
|
✔
|
✔
|
c
|
✔
|
✔
|
carLicense
|
✔
|
✔
|
certificate
|
✔
|
✔
|
changeType
|
✔
|
✔
|
children
|
✔
|
✔
|
cn
|
✔
|
✔
|
countryName
|
✔
|
✔
|
createTimestamp
|
✔
|
✔
|
departmentNumber
|
✔
|
✔
|
description
|
✔
|
✔
|
displayName
|
✔
|
✔
|
employeeNumber
|
✔
|
✔
|
entitlementInfo
|
✔
|
✔
|
facsimileTelephoneNumber
|
✔
|
✔
|
givenName
|
✔
|
✔
|
groups
|
✔
|
✔
|
homeAddress
|
not
supported
|
✔
|
homePostalAddress
|
✔
|
✔
|
ibm-jobTitle
|
✔
|
✔
|
ibm-primaryEmail
|
✔
|
✔
|
identifier
|
✔
|
✔
|
initials
|
✔
|
✔
|
jpegPhoto
|
✔
|
✔
|
kerberosId
|
krbPrincipalName
|
✔
|
l
|
✔
|
✔
|
labeledURI
|
✔
|
✔
|
localityName
|
✔
|
✔
|
mail
|
✔
|
✔
|
manager
|
✔
|
✔
|
mobile
|
✔
|
✔
|
modifyTimestamp
|
✔
|
✔
|
pager
|
✔
|
✔
|
parent
|
✔
|
✔
|
partyRoles
|
✔
|
✔
|
password
|
userPassword
|
✔
|
postalAddress
|
✔
|
✔
|
postalCode
|
✔
|
✔
|
preferredLanguage
|
✔
|
✔
|
principalName
|
✔
|
✔
|
realm
|
✔
|
✔
|
roomNumber
|
✔
|
✔
|
secretary
|
✔
|
✔
|
seeAlso
|
✔
|
✔
|
sn
|
✔
|
✔
|
st
|
✔
|
✔
|
stateOrProvinceName
|
✔
|
✔
|
street
|
✔
|
✔
|
telephoneNumber
|
✔
|
✔
|
title
|
✔
|
✔
|
uid
|
✔
|
✔
|
viewIdentifiers
|
✔
|
✔
|
Attributes for Group
|
PortalLdap
|
InternalFileRepository
|
businessCategory
|
✔
|
✔
|
changeType
|
✔
|
✔
|
children
|
✔
|
✔
|
cn
|
✔
|
✔
|
createTimestamp
|
✔
|
✔
|
description
|
✔
|
✔
|
displayName
|
✔
|
✔
|
entitlementInfo
|
✔
|
✔
|
groups
|
✔
|
✔
|
identifier
|
✔
|
✔
|
members
|
✔
|
✔
|
modifyTimestamp
|
✔
|
✔
|
parent
|
✔
|
✔
|
partyRoles
|
✔
|
✔
|
seeAlso
|
✔
|
✔
|
viewIdentifiers
|
✔
|
✔
|
Optionally
you can map the LDAP attributes to portal attributes like below , I just
ignored this mapping for now.
federated.ldap.attributes.mapping.ldapName=mail,
title
federated.ldap.attributes.mapping.portalName=ibm-primaryEmail,
ibm-jobTitle
NOTE: For creating the portal admin users in the LDAP better import the portaluser.ldif (Click here for ldap configuration) or make sure you are using right objectClasses, objectClass for the person account should be "Internet Organization Person " this will make sure RDN for the person account will be "uid" instead of "cn".
- At this stage, your WebSphere Portal environment is using two user repositories: the out-ofthe-box file registry, and the newly configured LDAP user registry. The WebSphere Application Server Administartor ID, the Portal Administrator User ID, and the Portal Administrator Group ID, are all configured for the file registry.
- Execute the following ConfigEngine script to reassign the WebSphere Application Server ID as a user within your LDAP:
./ConfigEngine.sh
wp-change-was-admin-user -DWasPassword=<current password>
-DnewAdminId=<full distinguished name from ldap> -DnewAdminPw=<ldap ID
password>
For
example, this is the exact command I executed:
ConfigEngine.bat
wp-change-was-admin-user -DWasPassword=wasadmin
-DnewAdminId=uid=wasadmin,cn=users,dc=sivavaka,dc=com -DnewAdminPw=wasadmin
NOTE:
- Make sure you have portal admin user id is LDAP repository (import the portalusers.ldif file)
- If the full distinguished name of your user has a space in it, then add the 'newAdminId' and 'newAdminPw' values to your wkplc.properties file instead of passing them through the command line.
- After running this script, the WasUserid value in wkplc.properties will be updated to reflect the new Was User ID you specified for “newAdminId”.
- Restart the DMGR, NodeAgent and WebSphere_Portal server for the change to take effect.
NOTE:
- When you stop these servers, you will need to pass in the user ID/pwd of the original WAS admin user. The new user will not take effect until the servers have been restarted.
- If you ran the 'wp-modify-realm-enable-dn-login' script, then you will be required to pass in the full distinguished name of the WAS admin user (since the servers are now using it) in order for authentication to succeed. For example:
./stopManager.sh
-user uid=wpadmin,o=defaultWIMFileBasedRealm -password <password>
After
the servers are restarted, the WasUserId and WasPassword will be the ldap user.
NOTE
a
. For me I have to execute the following to stop the DMGR even though I didn't
run the "wp-modify-realm-enable-dn-login" as described above
stopManager.bat
-user uid=wasadmin,o=defaultWIMFileBasedRealm -password wasadmin
stopNode.bat
-user uid=wasadmin,o=defaultWIMFileBasedRealm -password wasadmin
stopServer.bat
WebSphere_Portal -user uid=wasadmin,o=defaultWIMFileBasedRealm -password
wasadmin
- Execute the following ConfigEngine script to reassign the WebSphere Portal Administrator ID and Group ID to a user and group within your LDAP:
./ConfigEngine.sh
wp-change-portal-admin-user -DWasPassword=<password>
-DnewAdminId=<full distinguished name from ldap> -DnewAdminPw=<ldap ID
password>
-DnewAdminGroupId=<full distinguished name from ldap>
For
example, this is the exact command I executed:
ConfigEngine.bat
wp-change-portal-admin-user -DWasPassword=wasadmin
-DnewAdminId=uid=wasadmin,cn=users,dc=sivavaka,dc=com -DnewAdminPw=wasadmin
-DnewAdminGroupId=cn=wpadmins,cn=groups,dc=sivavaka,dc=com
NOTE:
- If the full distinguished name of your user has a space in it, then add the 'newAdminId', 'newAdminPw', and 'newAdminGroupId' values to your wkplc.properties file instead of passing them through the command line.
- After running this script, the PortalAdminId value in wkplc.properties will be automatically updated to reflect the ID value specified for 'newAdminId' and the PortalAdminGroupId value will be automatically updated to reflect the 'newAdminGroupId'.
In
the current state, it is not possible to stop the servers cleanly via the
command line. You must kill the Java processes for the respective servers via
your operating system administrative utilities (in a standalone environment:
WebSphere_Portal and server1; in a clustered environment: Deployment Manager,
node agent, and cluster members such as WebSphere_Portal.)
Start
the servers. In a clustered environment, restart the Deployment Manager, the
node agent, and WebSphere_Portal servers. In a standalone environment, restart
the server1 and WebSphere_Portal servers. Confirm you can now log into the ISC
by using the full DN for your administrative user.
- Remove the file registry from the federated repository by doing the following:
-- Ensure the following properties are
specified in wkplc.properties:
federated.delete.baseentry=o=defaultWIMFileBasedRealm
federated.delete.id=InternalFileRepository
-- Run the following ConfigEngine task:
ConfigEngine.sh wp-delete-repository
Restart
the servers. In a clustered environment, restart the Deployment Manager, the
node agent, and WebSphere_Portal servers. In a standalone environment, restart
the server1 and WebSphere_Portal servers. Confirm that login with the login
attribute succeeds to the ISC.
Referernces
No comments:
Post a Comment