|
Problem |
If you use V4.0.3 or a later release of V4.0 AEs , you can
start WebSphere Application Server only under the root user ID after you
enable security with LocalOS. No alternatives are published. |
|
Cause |
No information is provided for alternatives to running
WebSphere Application Server using a root user ID if security is required
for WebSphere Application Server AEs. |
|
Solution |
Use the custom registry to enable security on AEs and
start WebSphere Application Server using a non-root user ID.
These procedures are for WebSphere Application Server AEs V4.0 (single
server) only, V4.0.3 and later releases.
- Stop the server if it is running.
- Create the com/ibm/ejs/security/registry/wsregistries.properties file.
Cut and paste the following lines in this file:
LDAP=com.ibm.ejs.security.registry.CustomRegistryImpl
Windows=com.ibm.ejs.security.registry.CustomRegistryImpl
Windows_NT=com.ibm.ejs.security.registry.CustomRegistryImpl
Windows_2000=com.ibm.ejs.security.registry.CustomRegistryImpl
OS/400=com.ibm.ejs.security.registry.CustomRegistryImpl
AIX=com.ibm.ejs.security.registry.CustomRegistryImpl
Solaris=com.ibm.ejs.security.registry.CustomRegistryImpl
SunOS=com.ibm.ejs.security.registry.CustomRegistryImpl
NetWare_5.00=com.ibm.ejs.security.registry.CustomRegistryImpl
NetWare=com.ibm.ejs.security.registry.CustomRegistryImpl
HP-UX=com.ibm.ejs.security.registry.CustomRegistryImpl
Linux=com.ibm.ejs.security.registry.CustomRegistryImpl
Custom=com.ibm.ejs.security.registry.CustomRegistryImpl
Copy this file to a directory, which is in front of the class path. For a
normal WebSphere Application Server installation (that did not have its
class path modified)you can use the %WAS_HOME%/classes directory.
For example:
$WAS_HOME/classes/com/ibm/ejs/security/registry/wsregistries.properties).
- The CustomRegistry setup is not supported in the thinClient (Web
console). So, to enable security to use the CustomRegistry setup, modify
the server-cfg.xml file , as described in the following examples. All the
changes are contained in the <userRegistry ...> ....
</userRegistry> stanza.
The examples provided here are from the WebSphere
Application V4.0 Information Center documentation, which uses a
file-based registry (FileRegistrySample.java) as the CustomRegistry,
- Modify the security server ID and password (this ID is in the
CustomRegistry implementation).
For example:
<userRegistry xmi:type="security:LocalOSUserRegistry"
xmi:id="LocalOSUserRegistry_1" serverId="bob" serverPassword="bob1"
name="LOCALOS">
Note that the password is converted from plain text to an encoded string
during server startup.
- Add the CustomRegistry implementation file to the properties. The name
(key) is CustUserRegImplClass.
For example:
<properties xmi:id="UserRegProperty_1" name="CustUserRegImplClass"
value="FileRegistrySample"/>
If the implementation file is com/myCompany/myImpl.class, the value is
com.myCompany.myImpl.
For example:
<properties xmi:id="UserRegProperty_1" name="CustUserRegImplClass"
value="com.myCompany.myImpl"/>
- Add additional properties that are needed for the CustomRegistry
initialization. All these properties have names (keys) that start with
Custom_ . This prefix is used by the WebSphere Application Server internal
implementation to separate the custom registry properties from others.
For example:
<properties xmi:id="UserRegProperty_2" name="Custom_usersFile"
value="c:/temp/users.props"/> <properties xmi:id="UserRegProperty_3"
name="Custom_groupsFile" value="c:/temp/groups.props"/>
When these properties are propagated to the initialize method of the
CustomRegistry implementation file (FileRegistrySample in this case),
Custom_ is removed.
For example, the Custom_usersFile property is propagated as usersFile
(that is Custom_ removed) to the CustomRegistry Implementation file. So in
your Implementation file, look for usersFile and not Custom_usersFile.
- Enable security if it is not already enabled. Set enabled to true as
shown in the following example:
<security xmi:id="Security_1" cacheTimeout="30000" enabled="true"
activeAuthMechanism="LocalOSAuthentication_1">
- Start the server. The custom registry is now in use.
Note that on AE, a custom registry uses the Lightweight Third Party
Authentication (LTPA) authentication mechanism. AEs does not support LTPA,
so the local OS authentication mechanism (but not user registry) is
used. |
|
|
|
|
|
|