Default password in Websphere Application Server plug-in for Apache expiry

If you are using the key store installed by default on your web server for the Websphere Application Server plug-in and that you have never  changed the key store's password, you will hit the following problem.

[root@server ]# gsk7capicmd_64 -keydb -expiry -db ./plugin-key.kdb -pw WebAS
Validity:  Thursday, 26 April 2012 23:20:31 PM SGT

Do note that default password for the key DB is "WebAS".

To resolve this issue, you can just change the password without setting the expiry date.

Here's the steps that i used. (only CLI since i don't usually access UI.)

Get your LD library path

[root@server ]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/IBM/WebSphere/Plugins/gsk7/gsk7_64/lib64/

Check that the Key DB really expired

 [root@server ]# gsk7capicmd_64 -keydb -expiry -db ./plugin-key.kdb -pw WebAS
Validity:  Thursday, 26 April 2012 23:20:31 PM SGT

Let's change the password. Take note that you must stash the key for the password to be saved.

[root@server ]# gsk7capicmd_64 -keydb -changepw -pw WebAS -new_pw WebAS2 -stash -db plugin-key.kdb

If you really fancy, change the password back. (But i don't recommend this as this pose a big security risk!)

[root@server ]# gsk7capicmd_64 -keydb -changepw -pw WebAS2 -new_pw WebAS -stash -db plugin-key.kdb

Let's verify.

[root@server ]# gsk7capicmd_64 -keydb -expiry -db ./plugin-key.kdb -pw WebAS
Validity:  0


We are now done with the password change.

IBM Reference: http://www-01.ibm.com/support/docview.wss?uid=swg21579757

AIX su restriction using sugroup

In AIX, we can restrict who can access a particular user account using the SUGROUP parameter.

Background

Using the below example to explain.

We have normal user account ‘user1’.

We are going to create the admin account for ‘user1’, this account is ‘admin1’.

We do not want to allow any NON-admin to access ‘admin1’, hence we use SUGROUP to restrict. Here, I used ‘admingrp’ group since all admin are in this group.

Not to worry if another DBA access ‘admin1’ since /var/log/authlog would show who used that account. Below example log showed someone using root accessing ‘user2’ account before using ‘admin1’.

devserver:/:>tail -2 /var/log/authlog

Feb 14 10:12:11 devserver auth|security:notice su: from root to user2 at /dev/pts/0

Feb 14 10:12:15 devserver auth|security:notice su: from user2 to admin1 at /dev/pts/0

Parameters and Procedure

The account creation via smitty in its entirety. Further notes

-          Requirement is ‘admin1’ should be member of the group ‘appgrp’ is in so that he can access files in appgrp.

-          Also ‘admin1’ needs to be member of staff group to access ‘user1’ files.

-          Since this is a privilege account, we set the following

o   No remote login (SSH, telnet, etc)

o   No local login (physical, console)

o   Shorter account expiry

-          SU GROUP set to ‘admingrp’

 If you want to user command line, which I don’t really recommend unless you script.

devserver:/:>mkuser "id=11705" "pgrp=appgrp" "groups=appgrp,staff" "home=/home/admin1" "shell=/usr/bin/bash" "gecos=name name name" "login=false" "su=true" "rlogin=false" "admin=false" "sugroups=admingrp" "maxage=5" admin1

devserver:/:>passwd admin1

devserver:/:>pwdadm -c admin1

Result

Remote login will fail.

me@server [~]

~$ssh admin1@devserver

admin1@devserver's password:

Received disconnect from 10.10.50.10: 2: Remote login for account admin1 is not allowed.

Access to root will fail.

devserver:/:>su -user1

$ su - admin1

admin1's Password:

-bash-3.2$ su -

root's Password:

You are not allowed to su to this account.

Cannot su to "root" : Account is not accessible.

Non admin will not be able to access this account.

me@devserver [~]

~$su - admin1

admin1's Password:

You are not allowed to su to this account.

Cannot su to "admin1" : Account is not accessible.

Another admin can access this account.

devserver:/:>su - user2

$ su - admin1

admin1's Password:

-bash-3.2$ id

uid=11705(admin1) gid=101(appgrp) groups=1(staff)

  

Switching LDAP repository in Websphere Application Server 7

This is to record the steps i used to switch LDAP repository in Websphere Application Server 7 and enabled LDAP over SSL.

Lets Start

Point your browser to the WAS console and login using admin account.

Add in the new LDAP server configurations

As i use a few repositories in my environment, i would be updating the repositories in the "Federated repositories" section.

Click on left column's link: Security -> Global Security -> Configure (the drop down box is pointed to "Federated repositories"

The page refreshed, look for "Manage repositories" -> Add

Fill the following.
- Repository identifier
- Directory type (here, i used IBM TDS)
- Primary hostname (put in IP, if you have the entry in /etc/hosts, can use hostname)
- Port (389 for a start. Later will be updated to 636)
- Bind DN (The account to connect to LDAP server)

Click Apply when you are done. Then Click Save. Wait for sync to finish and click OK.

If there is something wrong, WAS will complain.

i.e.
cannot reach the LDAP server. (ACL/firewall??)
wrong port
Bind DN is wrong
etc

Import LDAP server SSL

 Store the SSL certificate as a flat file in the WAS server. You may need to convert the SSL certificate to "der" format and deposit the certificate to the deployment manager directory.

Create WAS Truststore

We will create the key store in WAS to store keys and certificate for LDAP. Idea is to separate key store for different functions.

By java definition, keystore is an object that holds personal certificate. truststore is a Java object that holds signer certificates. I gather we will only create the truststore since WAS security guide listed this step.

Click Security -> SSL Certificate and key management -> keystores and certificates

Then click New

Fill up the following
- Name (i used LDAPTruststore)
- Management scope (IBM security guide recommended cell level)
- Path (Where you want to store this key store)
- Password

Import the LDAP SSL certiticate into LDAPTruststore

From the breadcrumb of the previous step, Click on "LDAPTruststore" and Signer certificates.


Click Add


Fill up the following
- Alias (i used ldapcert)
- File Name (the path to the LDAP ssl certificate you put in previous step.)


Click Apply when you are done. Then Click Save. Wait for sync to finish and click OK

Creating SSL alias link to the Trust store

We will create Click Security -> SSL certificate and key management -> SSL configuration.

Click New

Fill up the following
- Name (I used LDAPSSLSettings)
- Trust store name (its LDAPTruststore)
- Key store name (its LDAPTruststore)
- Management Scope (Its Cell Level)

Click OK then Save then OK.

We are now ready to enable LDAP over SSL communication to LDAP server

Go back to the repository.

Click Security -> Global Security -> Configure (drop down bar should point to "Federated repositories")

When the page refreshed, Click "Manage repositories"

Fill up the following
- Port (change to 636)

Check the "Require SSL communication"

Choose the radio button "use specific SSL alias" and select LDAPSSLSettings from the drop down menu.

Click Apply when you are done. Then Click Save. Wait for sync to finish and click OK

Add the Base DN

Here, we need to configure from where in LDAP server we should make the queries.

Click Security -> Global Security -> Configure (drop down bar should point to "Federated repositories")

Click the "Add base entry to realm" button

Fill up the following
- Repository (Put in the name you used for "Repository identifier")
- OU (Put in the Base DN here)

Click Apply when you are done. Then Click Save. Wait for sync to finish and click OK 

A little housekeeping

Removethe base DN for the old LDAP server.

Click on the base DN -> remove
Then Click Save. Wait for sync to finish and click OK  

Click on Manage repositories
Check the old repository -> delete
Then Click Save. Wait for sync to finish and click OK  

Restart AppSvr, NodeMgr and Dmgr

To be safe, i would prefer to restart everything and make sure i still can log in as administrator and the application would have no problem working with the new LDAP server.

Check the Dmgr logs, AppSvr logs for signs of errors.

A small test

Click on "users and groups" -> manage users
Search for some valid users and verify that they come from the new LDAP server.
Get the software team to verify too in case the problem is subtle enough not to be caught in the application logs.