Thoughts on Portal from Level 2 Support
After creating or modifying a URL mapping in a virtual portal, users may no longer be able to access the virtual portal via browser, and administrators may no longer be able to successfully administer the virtual portal via XMLAccess. Such issue has been confirmed by IBM Support as a defect and reported via APAR PM47138. If you are using virtual portals in your environment, Support highly recommends installing cumulative fix (CF) 9 for WebSphere Portal 18.104.22.168 in order to prevent this problem scenario. For those users who already experience such an issue, there are two options for recovery:
1) Restore the Portal database from backup.
2) Open a PMR with IBM Support to request assistance in remapping the URL context to the virtual portal. Upon opening such PMR, the following database tables from database domain "release" should be provided for review by Support:
Note 1: The defect can manifest itself such that when you log into a virtual portal and navigate to the URL mapping portlet, you are unable to see the context root for your virtual portal. Thus, you are unable to create any URL mappings for the virtual portal via the UI since they need to be created as children of the context root. Any URL mappings you do try to create in this case get created as additional context roots and cause undesired results (e.g. redirecting to base portal) if you attempt to utilize them.
Note 2: A flash technote will be published today communicating this same information.
twcornwe 0600025RJ4 Tags:  federate file-based security fileregistry.xml repository 6,093 Views
WebSphere Portal 6.1 and later out of the box utilize a file repository in a Virtual Member Manager (VMM) federated repositories. During installation of WebSphere Portal, a prompt is given to create a new username and password. The username and password are created in the file repository and utilized by WebSphere Portal during runtime, and during installation/configuration tasks. When the system is ready to be configured to an enterprise LDAP, with a standalone LDAP configuration, the file repository no longer is available and only a single LDAP is available for use. With a federated repositories configuration, a file repository and one or more LDAP may exist simultaneously. A decision should be made as to whether to keep the file repository, or, remove it. In general, the recommendation is to remove the file repository.
Why Keep the File Repository?
The most common reason to keep the file repository is to have a location other than the LDAP to store the administrative users. In the event of an LDAP outage, the file repository would still be available and allow login to the WebSphere Application Server and/or Portal server. For these scenarios, we instead strongly recommend customers setup a database user registry with their Portals. The database user registries do not have nearly the number of limitations as do the file repositories, allow for a more flexible configuration of the system, and do not have nearly the performance penalty as do file repositories. More information on database user registries are available here:
Why Remove the File Repository?
In general, WebSphere Portal v6.1-8.0 recommends to remove the file repository in production systems:
"Note: It is not recommended to use the file-based repository in a production environment".
WebSphere Portal v8.5 and later require its removal in production systems:
"Only the database entry mapping repositories support the creation of a group with members that exist in repositories outside the database repository. If you use a Lightweight Directory Access Protocol (LDAP) registry, you can assign a member to a group within that same LDAP registry. Similarly, if you use a file repository, you can assign a member to a group within that same file repository. "
End Result: You may not have an administrative user in the file repository which belongs to an administrators group in the LDAP, and vice-versa.
"Client certificate login is not supported in a realm that includes a single built-in, file-based repository or a single built-in, file-based repository with other repositories."
Addendum: This is now supported with WAS 70023, WAS 8004 and WAS 8550 and later. More details available at this link:
End Result: This is a rare, but valid security configuration not available with the file repository.
"Changes to built-in, file-based repositories are not automatically replicated to managed nodes in a federated repositories configuration. You need to use the administrative console to replicate the changes you make to a built-in, file-based repository."
"If the WebSphere Application Server is installed in a clustered environment, then these files are distributed to all the cluster members based on the standard WebSphere Application Server configuration distribution mechanism. All the write functions occur only at the Network Deployment Manager (NDM) server, but the read functions are performed using the local file repositories."
End Result: You may not use "Edit my Profile" to modify users or their passwords in a File Repository. It must be done via the Deployment Manager console.
"The registry used by WebSphere is not the Active Directory domain LDAP, or Global Catalogue, but is some other virtual registry (for example, a file-based custom user registry)."
End Result: Administrative users in the file repository will not be able to use SPENGO if configured.
"You can configure only one LDAP repository under federated repositories, and that LDAP repository configuration must match the LDAP server configuration under Tivoli Access Manager."
End Result: Administrative users in the file repository will need to access the Portal server, rather than through TAM. Note, the same is likely true for other External Security Managers (such as Siteminder), as those ESMs typically do not have access to the users in the file repository.
"Note: Application groups only apply to WebSphere Portal; it does not apply to external security managers. Also, application groups is not supported when using the default federated repository with a built-in file repository."
End Result: If an administrative user exists in the file repository, it is not supported to make that user a member of one or more application groups. This is a WebSphere Portal specific limitation.
"The VMM file-based repository does not support search queries with multiple wildcards"
End Result: If searching for users in the Portal with multiple wildcard, e.g. searching for John Doe via Jo* Do*, such searches will fail. Both the file repository and LDAP will be searched with this query, and the query will fail on the file repository, causing the entire search operation to fail and have no results return to the end user.
RHEL bug could be problematic for Quickr 8.5 for Portal installations with a non-localized /home directory
As many of you are aware, Quickr 8.5 has the option to install DB2 along with server itself. Unfortunately if the /home directory is not local errors may appear after DB2 is being installed. They indicates that the 'qkradmin' user cannot run any db2 commands:
-bash: db2start: command not found
The only recourse is to install to a local /home directory until these duplicate RHEL bugs are fixed:
I will post more updates on resolving this issue as I get them
A frequent question asked is "WebSphere Portal ships with a lot of applications. But, I don't need all of those applications. Each of the applications takes time to start when the Portal server starts, and, consumes memory/CPU during runtime. How do I know which applications are required for the Portal server to function, and which are optional and can be safely disabled?".
For Portal 6.1.x, please see the following Technote: "How to disable unused applications in WebSphere Portal V6.1.x"
For Portal 70x, please see the following Technote: "How to disable unused applications in WebSphere Portal 7.0.x"
JMW98 2000000MY6 3,943 Views
Many login performance issues turn out to be delays in resolving group membership. WebSphere Portal attempts to resolve group membership at each login. There are a few things a Portal administrator can do to make the process of resolving group membership as efficient as possible. Reducing the load on the LDAP is a bonus.
1. If your LDAP supports it, implement a membership attribute. Set the scope as broadly as your LDAP supports. Hopefully, the LDAP's membership attribute lists all of a user's group memberships (direct, nested, and dynamic).
Note: Be sure that any groups returned by the membership attribute can be resolved within the realm defined in VMM. Failures will occur if the membership attribute returns a group DN that VMM cannot look up.
2. Unless your application requires them, avoid using dynamic groups since resolving their membership exacts a high cost. If you need dynamic groups in your application, consider keeping them locally with this alternative.
3. If the membership attribute resolves nested groups, disable nested groups in Portal.
4. Configure a federated repository so that VMM resolves group membership during the WAS login process. Then configure Portal to reuse WAS group information (user management only, to maximize performance).
Note: You can reuse WAS group information even in a standalone LDAP configuration - I just like the VMM functionality for resolving group membership better.
There are some additional tweaks you can make with PAC caches, VMM caches, and context pooling, but these four items should help a great deal in resolving any performance delays in resolving group membership during Portal login.