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

For more information about the WebSphere Roles see the resources below.

• Login to the console and expand “Security”.
• Go to “Secure administration, applications and infrastructure”
• Select the checkbox for “Enable administrative security”
• Select the checkbox for “Enable application security”
• Unselect the checkbox for “Use Java 2 security to restrict application access to local resources”
• Click Apply and “Save directly to the master configuration”.

• Select from the “Available realm definitions” dropdown menu the “Federated repositories” option.
• First click “Set as current”, Apply and “Save directly to the master configuration”, and then click “Configure”.

Now configure the repositories, starting with the InternalFileRepository and than AD-LDAP.

• Leave the realm name at it's default (defaultWIMFileBasedRealm)
• Enter the “Primary administrative user name”. This value is free to choose, but to prevent confusion, do not enter an existing local account or an account already in LDAP. I've set it to sjoerd. This account will be your fallback when LDAP is down.
• Then check the “Automatically generated server identity” radio button.
• Select the “Ignore case for authorization” checkbox.
• Click Apply you'll be prompted to enter a password for the “Primary administrative user name” which you've just set. Click OK, and than click “Save directly to the master configuration”.

• 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”

• 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”

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.

Then I added myself to the WebSphereAdministrators group and it worked:

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

Then I tried to stop the application servers from the commandline, and also here was authentication required. I gave incorrect credentials when stopping the last application server. As you can see, the stopping of all application servers was successful, except for the last one:

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

NOTE: The dmgr can only be stopped with the local account (sjoerd).

• Display Name: WebSphere_Monitoring_9030
• WebSphere Version: 6.x
• Deployment Mode: Network Deployment
• Port: 9030
• User Name: same as configured for the InternalFileRepository (sjoerd)
• SOAP Connector Port: 8882
• Network Deployer Host: ndhost.copany.local
• Network Deployer SOAP Port: 8879
• Advanced Options
  • App Servers to Monitor: node:JMS,Front,Monitoring;

You can check the service by going to this url:

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

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.

And here is the source