WebSphere Console LDAP Authentication

Overview

By default, when WebSphere gets installed everybody can access the WebSphere portal because there is no security. This is how the portal looks like:

As you can see, the console can be reached with this url:

http://fqdn-of-server:9060/ibm/console

And as you can see as well, there’s no password field.

Now we want secured access to the console, and we want to centrally administrate the users who will access the console. To do so, we have to follow these steps:

• Enable administrative security
• Configure Federated Repositories
  • Configure the InternalFileRepository
  • Configure a LDAP Repository
• Restart the WebSphere Console
• Set up Administrative Group Roles
• Restart the WebSphere Console

After securing the console will be reachable on this url:

https://fqdn-of-server:9043/ibm/console

Prerequisites

Backup

Enable Administrative Security

Configure Federated Repositories

Configure the InternalFileRepository

Configure a LDAP Repository

In the same page as before click “Manage repositories” to start configuring the LDAP repository:

• Click Add
• Enter a “Repository identifier”. Also a free value, I’ve named it to “AD-LDAP”
• Set the LDAP server “Directory type” to “Microsoft Windows Server 2003 Active Directory”. I’ve found this server also working for Windows Server 2008 Active Directory.
• Set the Primary host name to your primary ldap server: ldap.company.local
• Leave the port at it’s default value of 389
• Set the “Bind distinguished name” to the service account which is a guest domain account: sa_ldap@company.local
• Set the bind password
• leave the “Login properties” to it’s default value of “uid”

The configuration now looks like this:

• Click Apply and “Save directly to the master configuration”

Configure Federated Repositories II

Now go back to the “Federated repositories” page to add the LDAP repository to the realm:

• Click “Add Base entry to realm”
• Select “AD-LDAP” from the Repository dropdown menu.
• Now enter the search base (ou=users,dc=company,dc=local) in both the “Distinguished name of a base entry that uniquely identifies this set of entries in the realm” and the “Distinguished name of a base entry in this repository”.
• Click Apply and “Save directly to the master configuration”.

Now the federated repositories look like this:

• Click Apply and “Save directly to the master configuration”

Set up Administrative Group Roles

Before we can setup Administrative Group Roles we first have to enable WebSphere to access the just created LDAP repository. To do so, we have to restart the WebSphere console. Since the console is part of the deployment manager you can restart the deployment manager. See the WebSphere Management Script for more information on how to do that.

After restart, you can login, but you’ll need to login with the configured local account:

After logging in expand the “Users and Groups” section and click “Administrative Group Roles” to start granting roles:

• Click Add
• Enter the group name you’ve created in Active Directory and select the role according to the overview at the top. You can select multiple roles by clicking while pressing the <CTRL>-key.
• Repeat the last steps for all groups you’ve created

Now the “Administrative Group Roles” look like this:

• Now shut down the application servers, node agent, and the deployment manager.
• Start the deployment manager.
• Resynchronize the nodes like this, and use the local account that you defined when asked for credentials:

root@aix:/opt/sft/${COMP}-${ENV}/WAS_Profiles/${COMP}-${ENV}.AppSrv/bin>syncNode.sh localhost

• Now start the node-agent and the application server.

NOTE: If you come across one of these errors you haven’t synchronized your application servers properly:

SECJ0305I: The role-based authorization check failed for admin-authz operation Server:stop. The user UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: operator, administrator.

[11/5/10 11:44:58:890 GMT+01:00] 00000034 MBeanHelper ...<cut>... ADMN0022E: Access is denied for the stop operation on Server MBean because of insufficient or empty credentials.

Test

ADMN1020I: An attempt is made to stop the Monitoring_server server. (User ID = defaultWIMFileBasedRealm/ldapsjoerd)

Stopping server Front
ADMU0116I: Tool information is being logged in file
           ../logs/Front_Server/stopServer.log
ADMU0128I: Starting tool with the AppSrv profile
ADMU3100I: Reading configuration for server: Front_Server
Realm/Cell Name: <default>
Username: ldapsjoerd
Password:                                                                                                               
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server Front_Server stop completed.

Stopping server JMS
ADMU0116I: Tool information is being logged in file
           ../logs/JMS_Server/stopServer.log
ADMU0128I: Starting tool with the AppSrv profile
ADMU3100I: Reading configuration for server: JMS_Server
Realm/Cell Name: <default>
Username: test
Password:                                                                                                               
ADMU0111E: Program exiting with error: javax.management.JMRuntimeException:
           ADMN0022E: Access is denied for the stop operation on Server MBean
           because of insufficient or empty credentials.
ADMU4113E: Verify that username and password information is correct.  If
           running tool from the command line, pass in the correct -username
           and -password.  Alternatively, update the <conntype>.client.props
           file.
ADMU1211I: To obtain a full trace of the failure, use the -trace option.
ADMU0211I: Error details may be seen in the file:
           ../logs/JMS_Server/stopServer.log

Monitoring

http://ndhost.company.local:9030/wasPerfTool/servlet/perfservlet?connector=SOAP&port=8879&host=ndhost.company.local&username=test&password=xxxxxxxx

Troubleshooting

Logging as defined user works, but not through group membership

If you can login using a user defined in the user roles, but not as a user who is defined a member of a group defined in group roles, select the “ignore case for authorization” in the federated repositories configuration.

This is why:

Optional: Verify that the Ignore case for authorization option is enabled. When you enable this option, the authorization check is case insensitive. Normally, an authorization check involves checking the complete DN of a user, which is unique in the LDAP server and is case sensitive. However, when you use either the IBM Directory Server or the Sun ONE (formerly iPlanet) Directory Server LDAP servers, you must enable this option because the group information that is obtained from the LDAP servers is not consistent in case. This inconsistency affects the authorization check only. Otherwise, this field is optional and can be enabled when a case sensitive authorization check is required. For example, you might select this option when you use certificates and the certificate contents do not match the case of the entry in the LDAP server.