Verifying and testing administrative security
After your server is restarted in secure mode, you can test that security is
properly enabled. There are basic tests that you can perform:
_ Verify the form login. When using the Web-based Administrative Console, the
Web-based form login page that is displayed forces you to enter a user ID and
password. Only a user ID with administrative roles must be able to log in.
_ Verify that the Java Client Basic Authentication works by executing the
<WebSphere_home>\bin\dumpNameSpace.bat file.
A challenge login window must open. Although you might be able to click
Cancel, you must type any correct user ID and password that is defined in the
user account repository to test the security.
Be aware that the login panel for the Java client only opens if the
com.ibm.CORBA.loginSource property is set to prompt in the
sas.client.props file. Clicking Cancel works only if CosNaming security (see
3.4, “Naming service security: CosNaming roles” on page 64) allows read
access to everyone. These values are the default values when you installed
WebSphere.
Successfully running these basic tests indicates that the administrative security
is working correctly.
Stopping the application server
While the command to start the application server is still the same when
administrative security is enabled, stopping the server requires extra information.
You must specify a user ID with administrator role rights, or the primary
administrative user name specified in the user account repository and its
password, in the stopServer command:
<WebSphere_home>\bin\stopServer.bat <server_name> -username <userID>
-password <password>
For WebSphere Application Server running under a UNIX-based operating
system (OS), the previously mentioned command (the UNIX equivalent) carries a
serious security problem. Anyone who uses the ps -ef command while the
stopServer process is running can see the user ID and the password.
To avoid this problem:
1. If you are using the SOAP connection type (default) to stop the server, edit the
<WebSphere_home>\profiles\<profilePath>\properties\soap.client.propsfile. Then, change the values of the following properties:
com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.loginUserid=<user ID>
com.ibm.SOAP.loginPassword=<password>
Again, the user ID <user ID>, with its password <password>, is the user ID
with administrator role rights or the primary administrative user name defined
in the user account repository.
2. Encode the com.ibm.SOAP.loginPassword property value as follows:
<WebSphere_home>\bin\PropFilePasswordEncoder.bat soap.client.props
com.ibm.SOAP.loginPassword
Examine the result and remove the soap.client.props.bak backup file, that
was created by the previous command. This file contains the unencrypted
password.
3. Make sure that proper file access rights for sensitive WebSphere Application
Server files, such as properties files and executable files, are set. At a
minimum, ensure that permissions prevent general users from accessing
these files. WebSphere administrators must be the only users that are
granted access to these files.
For optimal security, access to the entire
WebSphere directory tree must be removed for general users.
Whether administrative security is enabled or disabled, stop the WebSphere
Application Server as follows:
<WebSphere_home>\bin\stopServer.bat <server_name>
Disabling administrative security
Disable administrative security by using the command line.
To disable administrative security:
1. At the command prompt, type the following command:
<WebSphere_home>\bin\wsadmin.bat -conntype NONE
2. When the system command prompt redisplays, type the following command:
Securityoff
3. Type quit and restart the application server.
OR
You can disable administrative security by directly editing the security.xml file in
After your server is restarted in secure mode, you can test that security is
properly enabled. There are basic tests that you can perform:
_ Verify the form login. When using the Web-based Administrative Console, the
Web-based form login page that is displayed forces you to enter a user ID and
password. Only a user ID with administrative roles must be able to log in.
_ Verify that the Java Client Basic Authentication works by executing the
<WebSphere_home>\bin\dumpNameSpace.bat file.
A challenge login window must open. Although you might be able to click
Cancel, you must type any correct user ID and password that is defined in the
user account repository to test the security.
Be aware that the login panel for the Java client only opens if the
com.ibm.CORBA.loginSource property is set to prompt in the
sas.client.props file. Clicking Cancel works only if CosNaming security (see
3.4, “Naming service security: CosNaming roles” on page 64) allows read
access to everyone. These values are the default values when you installed
WebSphere.
Successfully running these basic tests indicates that the administrative security
is working correctly.
Stopping the application server
While the command to start the application server is still the same when
administrative security is enabled, stopping the server requires extra information.
You must specify a user ID with administrator role rights, or the primary
administrative user name specified in the user account repository and its
password, in the stopServer command:
<WebSphere_home>\bin\stopServer.bat <server_name> -username <userID>
-password <password>
For WebSphere Application Server running under a UNIX-based operating
system (OS), the previously mentioned command (the UNIX equivalent) carries a
serious security problem. Anyone who uses the ps -ef command while the
stopServer process is running can see the user ID and the password.
To avoid this problem:
1. If you are using the SOAP connection type (default) to stop the server, edit the
<WebSphere_home>\profiles\<profilePath>\properties\soap.client.propsfile. Then, change the values of the following properties:
com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.loginUserid=<user ID>
com.ibm.SOAP.loginPassword=<password>
Again, the user ID <user ID>, with its password <password>, is the user ID
with administrator role rights or the primary administrative user name defined
in the user account repository.
2. Encode the com.ibm.SOAP.loginPassword property value as follows:
<WebSphere_home>\bin\PropFilePasswordEncoder.bat soap.client.props
com.ibm.SOAP.loginPassword
Examine the result and remove the soap.client.props.bak backup file, that
was created by the previous command. This file contains the unencrypted
password.
3. Make sure that proper file access rights for sensitive WebSphere Application
Server files, such as properties files and executable files, are set. At a
minimum, ensure that permissions prevent general users from accessing
these files. WebSphere administrators must be the only users that are
granted access to these files.
For optimal security, access to the entire
WebSphere directory tree must be removed for general users.
Whether administrative security is enabled or disabled, stop the WebSphere
Application Server as follows:
<WebSphere_home>\bin\stopServer.bat <server_name>
Disabling administrative security
Disable administrative security by using the command line.
To disable administrative security:
1. At the command prompt, type the following command:
<WebSphere_home>\bin\wsadmin.bat -conntype NONE
2. When the system command prompt redisplays, type the following command:
Securityoff
3. Type quit and restart the application server.
OR
You can disable administrative security by directly editing the security.xml file in
<WebSphere_home>\profiles\<profilePath>\config\cells\<cell_name>\.
Change the security attribute enabled="true" to enabled="false".
#############################################################################################
