WASServiceMsg.dll is locked when installing Fix Packs and cumulative fixes on Windows

Technote (troubleshooting)

Problem(Abstract)

The WASServiceMsg.dll file is locked by the Microsoft Windows operating system and cannot be updated during the upgrade of WebSphere Application Server.

Symptom

The following error can occur when you have WebSphere Application Server set up to run as a service. It does not matter if the service starts automatically or not.

2006-02-09T12:47:14+01:00 Error 79 -- Unable to open destination file:
C:\Program Files\WebSphere\AppServer\\bin\WASServiceMsg.dll : C:\Program

Files\WebSphere\AppServer\\bin\WASServiceMsg.dll (The requested operation cannot be performed on a file with a user-mapped section open)
2006-02-09T12:47:14+01:00 java.io.FileNotFoundException: C:\Program Files\WebSphere\AppServer\\bin\WASServiceMsg.dll (The requested operation cannot be performed on a file with a user-mapped section open)
at java.io.FileOutputStream.open........


In addition, during uninstalling and reinstalling the WASServiceMsg.dll file could remain locked after the uninstall has completed. This will cause the reinstall to fail.

Resolving the problem

If you have WebSphere Application Server running as a service to start automatically, change this to start manually. Then reboot your machine and retry the installation.

If you do not have WebSphere Application Server set to start automatically and it is already set to start manually, then reboot your machine to free the locked resource. Then retry the installation.

If you are uninstalling and then reinstalling. Reboot your machine after a successful uninstall before reinstalling.

In addition to the steps above, sometimes it is necessary to shut down the Windows Management Instrumentation service after your system has rebooted. Then retry the installation.

Note that this particular can also become locked when the Windows Event Viewer (or third-party tools which provide a similar function) is browsing WebSphere-related entries in the Windows Event Log. If the UpdateInstaller continues to have issues with the WASServiceMsg.dll file, try to shut down the Windows Event Viewer and other services which may be monitoring the Windows Event Log.

If the UpdateInstaller continues to fail when installing or uninstalling maintenance packs due to this DLL file, and all WebSphere processes and third-party utilities which monitor Windows Events have been shut down, then try this alternative solution:

1. Shut down the UpdateInstaller.
2. Locate the WASServiceMsg.dll file, which is in the WAS_HOME\bin directory.
3. Rename WASServiceMsg.dll to a different file name. It is good practice to rename it to a file name which mentions the current WebSphere version. That way, you can easily distinguish this renamed file from other files, and you know that it belongs to a particular version of the product.
   
   For example, if you are using WebSphere Application Server V6.1.0.19, then rename the file to
   WASServiceMsg.dll.61019
   
   Note that, despite the fact that the file is locked, Windows will still allow the file to be renamed.
4. Reboot the system. This will ensure that the file is no longer locked.
5. Using the UpdateInstaller, uninstall and reinstall the maintenance pack. This operation should not conflict with the WASServiceMsg.dll file anymore. (Note that once the Fix Pack is reinstalled, a new copy of the WASServiceMsg.dll file will be created.)
6. Optional: At this point, you can delete the old, renamed copy of WASServiceMsg.dll. (Do not delete the actual WASServiceMsg.dll file; instead, delete the copy of the file which was renamed in step 3.)
   
   Note: Although you can delete the file, there is a reason to keep it: An effect of using this solution is that the old WASServiceMsg.dll file will not be restored if the fix pack is uninstalled in the future. Therefore, in case you will uninstall the fix pack in the future, keep the renamed copy of the WASServiceMsg.dll file. That way, when the fix pack is uninstalled, the old WASServiceMsg.dll file can be renamed to its original name.
7. Done. You may now start the application servers.

Referenced by IBM site:

Message stores in WebSphere Application Server

 Message stores in WebSphere Application Server

MESSAGE STORES

Message stores are important in the operation of messaging engines. To host queue-type destinations, a messaging engine includes a message store where, if necessary, it can hold messages until consuming applications are ready to receive them, or preserve messages in case the messaging engine fails. Each messaging engine has one and only one message store. This can either be a file store or a data store.
A message store enables a messaging engine to preserve operating information and to retain those objects that messaging engines need for recovery in the event of a failure.

A messaging engine preserves both volatile and durable data in its message store. Volatile data is lost when a messaging engine stops, in either a controlled or an uncontrolled manner. Durable data is available after the server restarts. A messaging engine stores various types of data, including messages, transaction states, and communication channel states.

When started, a messaging engine obtains configuration information from the WCCM ( WebSphere Application Server Common Configuration Model) repository. A messaging engine retrieves all other data from its own file store or data store.

There are currently no facilities available for migrating from a data store to a file store.
• File stores
• Data stores

File stores

File stores use a file system to preserve operating information and to persist the objects that messaging engines need for recovery in the event of a failure.
A file store is a type of message store that directly uses files in a file system through the operating system. The data storage in a file store is split into three levels:
1. Log file
2. Permanent store file
3. Temporary store file.

Log file :
This file contains information about currently active transactions and data that is not yet written to a store file. It is a circular log and its file size is static while a messaging engine is running, but can be changed if required. A restart of the messaging engine is required for the changes to take effect. The size of the log file limits the maximum size of a message that can be sent.

Permanent store file :
This file contains permanent data that is retained after the restart of the messaging engine, such as persistent messages, queue data, and information about the storage and transmission of persistent messages.
The permanent store file can be configured to have a maximum and minimum size, or to be unlimited in size. The file can grow from the minimum size (or as required in the unlimited case) but will never shrink (even if the maximum size is set lower than its current size). The file sizes can be changed in the administration console, but a restart of the messaging engine is required for the changes to take effect.
Similar to a file system, when data is deleted from the store, the data in the file is not deleted, only the directory information is updated. This means that if a message is consumed, the message data may still be present in the store file, but the directory information that includes this data in the store is updated to reflect the fact that it is deleted.

Temporary store file :
This file contains temporary data that is not retained after the restart of the messaging engine, such as nonpersistent messages that were spilled to the file store to release memory from the JVM heap. The temporary store file contents are truncated when the messaging engine starts.
The temporary store file can be configured to have a maximum and minimum size, or to be unlimited in size. The file can grow from the minimum size (or as required in the unlimited case) but will never shrink (even if the maximum size is set lower than its current size). The file sizes can be changed in the administration console, but a restart of the messaging engine is required for the changes to take effect.
Similar to a file system, when data is deleted from the store, the data in the file is not deleted, only the directory information is updated. This means that if a message is consumed, the message data may still be present in the store file, but the directory information that includes this data in the store is updated to reflect the fact that it is deleted.

You can configure where the file store files must be placed. By default, the file store uses a subdirectory in the following path:${USER_INSTALL_ROOT}/filestores/com.ibm.ws.sib/${ME_NAME}. The file store directory contains two other directories; the log directory that contains the log file and the store directory that contains both the PermanentStore and TemporaryStore files.

Data stores

A data store is a message store that uses a relational database. A messaging engine uses a data store to store operating information in the database, as well as to preserve essential objects that the messaging engine needs for recovery in the event of a failure.

A data store consists of the set of tables that a messaging engine uses to store persistent data in a database. See Data store tables for a list of the tables that comprise a data store. All the tables in a data store are held in the same database schema. You can create multiple data stores in the same database, provided that you use a different schema name for each data store.

The one-to-one relationship between a messaging engine and a data store means that every messaging engine must have its own data store. A messaging engine uses an instance of a JDBC data source to interact with the database that contains the data store for that messaging engine. The relationship between a messaging engine and its data store. illustrates these relationships.

A messaging engine uses a JDBC data source to manage the interaction with a data store, which is held in a database
All the tables in the data store must be stored in the same schema. You can create more than one data store in a database, provided that you use a different schema name for each data store. Although every messaging engine uses the same table names, its relationship with the schema gives each messaging engine exclusive use of its own tables.

Data store topologies :
You have several options for the relative location of a data store and its messaging engine. The topology also defines the relationship of a data store with other data stores.

The following options affect your choice of data store topology:
1. The data store can either run on the same node as its messaging engine or on a remote node.
2. The data store can either have a dedicated database or it can share a database with other data stores.


Reference: IBM Knowledge Center.

Federated Repository

Federated Repository

The majority of my clients set up their LDAP settings in WebSphere by going to [Security – Global Security – Federated Repositories] and then never look at it again after that. They don’t really understand what the back-end is – well, here is a crash course:

Federated – The definition:

From late Latin foederatus, based on foedus, foeder- ‘league, covenant.’

Adj. 1. federated – united under a central government. Federate / united – characterized by unity; being or joined into a single entity; “presented a united front”

OK, what does this mean? When you installed WebSphere you were asked about an admin account and a password to assign to it – by default that account is called [wasadmin] though you can change it to anything you want. That user name and password is saved in a FILE BASED directory structure in the Deployment manager and replicated out to all federated nodes. When you add an LDAP directory then the Files based (the thing you see defined as [defaultWIMFilesBasedRealm] are federated meaning that now they are BOTH together part of a SINGLE directory entity that all WebSphere applications will utilize as a single unit for the purpose of user account look-ups and authentication.

The Files Involved:

wimconfig.xml

Is located in the [deployment manage profile]\config\cells\[cellname]\wim\config folder. This file contains the federated directory setting definitions. So the files based directory (more details below) and the LDAP directory/directories are all defined and configured in this file. As this file is an XML file, each directory is defined inside the <config:repositories and the </comfig:repositoes> items.

Let’s look at the example from my training WebSphere environment:

<config:repositories xsi:type=”config:FileRepositoryType” adapterClassName=”com.ibm.ws.wim.adapter.file.was.FileAdapter” id=”InternalFileRepository” supportPaging=”false” messageDigestAlgorithm=”SHA-1″>

<config:baseEntries name=”o=defaultWIMFileBasedRealm”/>

</config:repositories>

<config:repositories xsi:type=”config:LdapRepositoryType” adapterClassName=”com.ibm.ws.wim.adapter.ldap.LdapAdapter” id=”TTrainDom01″ isExtIdUnique=”true” supportAsyncMode=”false” supportExternalName=”false” supportPaging=”false” supportSorting=”false” supportTransactions=”false” supportChangeLog=”none”certificateFilter=”” certificateMapMode=”exactdn” ldapServerType=”DOMINO” translateRDN=”false”>

<config:baseEntries name=””/>

<config:loginProperties>uid</config:loginProperties>

<config:loginProperties>mail</config:loginProperties>

<config:loginProperties>cn</config:loginProperties>

<config:ldapServerConfiguration primaryServerQueryTimeInterval=”15″ returnToPrimaryServer=”true” sslConfiguration=””>

<config:ldapServers authentication=”simple” bindDN=”ldapaccess” bindPassword=”{xor}Dz4sLCgwLTtubWx+”

connectionPool=”false” connectTimeout=”20″ derefAliases=”always” referal=”ignore” sslEnabled=”false”>

<config:connections host=”ldap.intranet.toalsys.com” port=”389″/>

</config:ldapServers>

</config:ldapServerConfiguration>

This shows the two entries I have in my environment:

• The default file based repository identified by the ID <id=”InternalFileRepository”>
• My Domino based LDAP repository identified by the ID <id=”TTrainDom01″>

Gotcha #1: User Name and Password is Open

This wimconfig.xml contains the user name and encoded password for the LDAP bind account. Note the choice of words … ENCODED, not ENCRYPTED.

If you want to know the password for my training LDAP account copy the encoded password above and go to this link by Andrew Jones:http://www.poweredbywebsphere.com/decoder.html (thanks Andrew, I send all my clients to your site for further info and learning!)

If his is a production environment I have now gained access to an account in your environment, possibly an account that has update/write rights to the LDAP directory ….. all by looking at one file. If you are like 99.9% of my clients you are compromised:

1. SECURE YOUR SERVER, LOCK DOWN YOUR FILE SYSTEM
2. DON’T USE ADMIN OR PERSONAL ACCOUNTS TO BIND TO LDAP
3. DON’T RE-USE THE SAME PASSWORD FOR ALL YOUR ACCOUNTS

Sound obvious, doesn’t it?

 Gotcha #2: Rogue LDAP entries

If you have ever tried to change an LDAP directory, replace and entry in WebSphere you might have run into the issue that you suddenly can’t log into WebSphere anymore after you made the changes. Why? Well, you need to understand that sometimes when you make changes, those old entries don’t disappear totally – they are left behind and impact you.

Remember the part about FEDERATED above? If not ALL directory entries here (in this file, not what shows in the IBM Console) are accessible and functioning, then the federated directory that you are trying to access will not work and you cannot authenticate. It is the Three Musketeer principle: “All for One, One for All”

Gotcha #3:

Some changes can’t be made in the interface. I had a client that mistakenly entered an LDAP directory as Microsoft AD but it was Domino. They tries to clean it up in this file but it still was not working and they could not log in ….. well, the wimconfig.xml contains allot of directory type specific settings which are set by the type: <ldapServerType=”DOMINO” > .. My advice is to remove the incorrect entry and enter a NEW entry at the same time and then make sure the old incorrect one is gone from the wimconfig.xml. DO NOT manually try to clean this up (other than remove the entry) as you might end up destroying thewimconfig.xml and making your environment unusable.

Remember Dr. Vic’s rule #2 above? Make back-ups before any changes to WebSphere security settings.

HOW TO RECOVER A LOST PASSWORD

WEBSPHERE: WASADMIN – HOW TO RECOVER A LOST PASSWORD

I had the case recently where was working on a WebSphere 7 environment that was being uncooperative and the previous creator had not taken any backups and the documentation was rather thin . . . one of my most favorite scenarios to walk into.

I found myself with three sets of documents that all stated a different wasadmin password and none of them worked and the client had never bothered to set up any secondary WBM console admins. A dilemma I had to solve.

Encoding vs Encrypting

You might know that all sensitive information about security is entered into thesecurity.xml document that can be found at [$WAS_HOME]/profiles/[profile name]/config/cells/[cell name] folder. In Windows this might equate to:

C:\IBM\Websphere\AppServer\profiles\Dmgr01\config\cells\cell01\security.xml

Linux/AIX would likely be something like:

/usr/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/cell01/security.xml

This document contains the name and password information for the primary admin account for the WebSphere cell – in most cases that will be the default account [wasadmin]. The password is, however, not encrypted but rather encoded. Encryption would use an encryption key to hash the password and without that key you would not be able to retrieve it. Encoding however is a whole other deal – the coding/decoding information is integral to WebSphere itself and is the same for any install anywhere in the world. That means if you encode the same password anywhere, the resulting hash will be exactly the same no matter which server you do it on.

Now, this is not great security in and upon itself and I will not go into details on this – other than it is really important to lock down the physical access to to any WebSphere server you are in charge of, all the way down to file rights …. or you might regret it at some later time.

How to Decrypt:

I am not the first blogger out there that is writing about this, but nobody every wrote it out for Windows servers so I am going to concentrate on that OS right now, and most of the blog entries out there are for older versions and the proces has changed since. Here some of the articles that I have read over the last few years Robert Farstad, Robert Maldon,  and a few more . . . . google the conent here and you will find them.

Here some basic details:

• WebSphere Version: 7.0.0.21 (the process is the same for any V 7.x server)
• $WAS_HOME=C:\IBM\WebSphere\AppServer

Step 1: find the wasadmin information

Open the security.xml, find the entry for the encrypted password: it always starts with {xor}, in my case it is:

userId=”wasadmin” password=”{xor}LDo8LTor”

Step 2: Find your WAS Version Specific Java Plug-in Folder:

In my case it was:

C:\IBM\WebSphere\AppServer\deploytool\itp\plugins\com.ibm.websphere.v7_7.0.2.v20110524_2321\

Step 3: Find your java home and open a command prompt

In my case this equates to

C:\IBM\WebSphere\AppServer\java\bin\

Change to this folder in the command prompt you opened.

Step 4: Run the Password Encoder/Decoder:

This is where you need the folder location and the encoded password you looked up in the previous steps.

In C:\IBM\WebSphere\AppServer\java\bin\ run the following command

java –java.ext.dirs=C:\IBM\WebSphere\AppServer\deploytool\itp\plugins\com.ibm.websphere.v7_7.0.2.v20110524_2321\wasJars\ -cpsecurityimpl.jar:iwsorb.jar com.ibm.ws.security.util.PasswordDecoder{xor}LDo8LTor

This above command is one long command string (it might wrap depending on your screen) and it will create the following output in the command prompt:

encoded password == “{xor}LDo8LTor”, decoded password == “secret”

The process for Linux/AIX is basically the same, however the folder structure will be different. The commands are about the same but depending on which version of Linux you are running the Java switches might need some fidlding – though the base does not change.

Security!

Next to being helpful to retrieve lost passwords, this article hopefully also shows you just how important good physical security for your WebSphere servers is – don’t think that just because you have a log-on or locked down root that you are safe.

How to Delete Websphere Application Server Profile

Here we are going to discuss how to delete the profile in Websphere Application server environment. I used the following to remove application server profile.

Note: Before deleting profile we need to stop all services associate with it.

e.g. Stop the Application server and webServer if configured.

Procedure:

1. First list all profiles on a server:
   List the profile using one of these commands
   Windows: was_install_dir\bin\manageprofiles.bat –listProfiles
   UNIX/Linux: was_install_dir/bin/manageprofiles.sh –listProfiles
2. Remove a WebSphere Application Server profile:
   Delete the profile using one of these commands:
   On Windows: was_install_dir\bin\manageprofiles.bat –delete –profileName profile
   On UNIX/Linux: was_install_dir/bin/manageprofiles.sh –delete –profileName profile
3. Ensure that references to the deleted profile are removed from the profile registry by running the following command:
   On Windows: was_install_dir\bin\manageprofiles.bat –validateAndUpdateRegistry
   On UNIX/Linux: was_install_dir/bin/manageprofiles.sh –validateAndUpdateRegistry
4. Delete the profile directory tree (if it was not deleted by the previous action).
   Delete the profile Directory using one of these commands:
   On Windows: was_install_dir\profiles\rmdir /s profileDirectory
   On UNIX/Linux: was_install_dir\profiles\rm -R profileDirectory

Hope this will help you to delete the profile in your environment and for more option of manageprofile run the command manageprofiles.bat –help

LDAP in-detailed

Configuring Lightweight Directory Access Protocol user registries

To access a user registry using the Lightweight Directory Access Protocol (LDAP), you must know a valid user name (ID) and password, the server host and port of the registry server, the base distinguished name (DN) and, if necessary, the bind DN and the bind password. You can choose any valid user in the user registry that is searchable. You can use any user ID that has the administrative role to log in.

Before you begin

In some LDAP servers, administrative users cannot be searched and thus cannot be used, for example, when cn=root in Tivoli Access Manager. The user is referred to as a WebSphere Application Server security server ID, server ID, or server user ID in the documentation. A server ID user has special privileges when calling some protected internal methods.
Normally, the server ID and password are used to log into the administrative console after you turn on security.
When security is enabled in the product, the primary administrative user name and password are authenticated with the registry during the product startup. If authentication fails, the server does not start. It is important to choose an ID and password that do not expire or change often. If the product server user ID or password need to change in the registry, make sure that the changes are performed when all the product servers are up and running. When changes are to be made in the registry, review the article on Lightweight Directory Access Protocol user registries (LDAP) before beginning this task.

Procedure

1. In the administrative console, click Security > Global security.
2. Under User registries, click LDAP.
3. Enter a valid user name in the Server user ID field. You can either enter the complete distinguished name (DN) of the user or the short name of the user, as defined by the user filter in the Advanced LDAP settings panel. For example, enter the user ID for Netscape browsers. This ID is the security server ID, which is only used for WebSphere Application Server security and is not associated with the system process that runs the server. The server calls the local OS registry to authenticate and obtain privilege information about users by calling the native application programming interfaces (API) in that particular registry.
4. Enter the password of the user in the Server user password field.
5. Select the type of LDAP server to use from the Type list. The type of LDAP server determines the default filters that are used by WebSphere Application Server. These default filters change the Typefield to Custom, which indicates that custom filters are used. This action occurs after you click OK orApply in the Advanced LDAP settings panel. Choose the Custom type from the list and modify the user and group filters to use other LDAP servers, if required.IBM Tivoli Directory Server users can choose IBM Tivoli Directory Server as the directory type. Use the IBM Tivoli Directory Server directory type for better performance. For a list of supported LDAP servers, see the Supported hardware, software, and APIs Web site.
6. Enter the fully qualified host name of the LDAP server in the Host field. You can enter either the IP address or domain name system (DNS) name.
7. Enter the LDAP server port number in the Port field. The host name and the port number represent the realm for this LDAP server in the WebSphere Application Server cell. So, if servers in different cells are communicating with each other using Lightweight Third Party Authentication (LTPA) tokens, these realms must match exactly in all the cells.The default value is 389. If multiple WebSphere Application Servers are installed and configured to run in the same single sign-on domain, or if the WebSphere Application Server interoperates with a previous version of the WebSphere Application Server, then it is important that the port number match all configurations. For example, if the LDAP port is explicitly specified as 389 in a version 5.xconfiguration, and a WebSphere Application Server at version 6.0.x is going to interoperate with the version 5.x server, then verify that port 389 is specified explicitly for the version 6.0.x server.
8. Enter the base distinguished name (DN) in the Base distinguished name field. The base DN indicates the starting point for searches in this LDAP directory server. For example, for a user with a DN of cn=John Doe, ou=Rochester, o=IBM, c=US, specify the base DN as any of the following options assuming a suffix of c=us): ou=Rochester, o=IBM, c=us or o=IBM c=us or c=us. For authorization purposes, this field is case sensitive by default. Match the case in your directory server. If a token is received (for example, from another cell or Lotus Domino) the base DN in the server must match exactly the base DN from the other cell or Domino. If case sensitivity is not a consideration for authorization, enable the Ignore case for authorization option.In WebSphere Application Server, the distinguished name is normalized according to the Lightweight Directory Access Protocol (LDAP) specification. Normalization consists of removing spaces in the base distinguished name before or after commas and equal symbols. An example of a non-normalized base distinguished name is o = ibm, c = us or o=ibm, c=us. An example of a normalized base distinguished name is o=ibm,c=us.
   To interoperate between WebSphere Application Server Version 5 and later versions, you must enter a normalized base distinguished name in the Base Distinguished Name field. In WebSphere Application Server, Version 5.0.1 or later, the normalization occurs automatically during runtime.
   This field is required for all LDAP directories except the Lotus Domino Directory. The Base Distinguished Name field is optional for the Domino server.
9. Optional: Enter the bind DN name in the Bind distinguished name field. The bind DN is required if anonymous binds are not possible on the LDAP server to obtain user and group information. If the LDAP server is set up to use anonymous binds, leave this field blank. If a name is not specified, the application server binds anonymously. See the Base Distinguished Name field description for examples of distinguished names.
10. Optional: Enter the password corresponding to the bind DN in the Bind password field.
11. Optional: Modify the Search time out value. This timeout value is the maximum amount of time that the LDAP server waits to send a response to the product client before stopping the request. The default is 120 seconds.
12. Ensure that the Reuse connection option is selected. This option specifies that the server should reuse the LDAP connection. Clear this option only in rare situations where a router is used to send requests to multiple LDAP servers and when the router does not support affinity. Leave this option selected for all other situations.
13. 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.You can also enable the Ignore case for authorization option when you are using single sign-on (SSO) between the product and Lotus Domino. The default is enabled.
14. Optional: Select the SSL enabled option if you want to use Secure Sockets Layer communications with the LDAP server.If you select the SSL enabled option, select the appropriate SSL alias configuration from the list in the SSL configuration field. For more information on setting up LDAP for SSL, see Configuring Secure Sockets Layer for the Lightweight Directory Access Protocol client .
15. Optional: In the SSL configuration field, select the Secure Sockets Layer configuration to use for the LDAP connection. This configuration is used only when SSL is enabled for LDAP. The default isDefaultSSLSettings. To modify or create a new SSL configuration, click Security > SSL.
16. Click OK. The validation of the user, password, and the setup do not take place in this panel. Validation is only done when you click OK or Apply in the Global Security panel.
    • If you are enabling security for the first time, complete the remaining steps and go to the Global Security panel. Select LDAP as the active user registry.
    • If security is already enabled, but information on this panel changes, go to the Global Security panel and click OK or Apply to validate your changes. If your changes are not validated, the server might not start.

Results

This set of steps is required to set up the LDAP user registry. This step is required as part of enabling security in the WebSphere Application Server.

Bind Distinguished : it means these are the credentials to login to the LDAP server.

Base distinguished: it is a directory, where the search has to start

The BaseDN describes one level of an LDAP container that an object (such a as a user) belongs to.

The Bind DN is the user object (account) that WebSphere uses in order to connect to the repository.

Source : from IBM site.

Replace the certificates

Question

This document describes the steps necessary to replace the certificates in IBM WebSphere Application Server V6.1 when the certificates have expired or if the nodes are out of sync.

Answer

This is meant to be used ONLY for V6.1. Do NOT try to follow these instructions on any newer versions of WebSphere.

NOTE: This document assumes that you are using a default configuration. If you have made modifications to your SSL configurations you will need to take these changes into account. For example, additional steps will be required if you have enabled client authentication on the application servers.

1. Run backupConfig on the Deployment Manager.

2. This step is optional. It only needs to be performed if you are running at level previous to 6.1.0.23 and the nodes are still in sync. You do not need to stop the nodeagent(s) and appserver(s) if you are at or above this level and the nodes are in sync.

Stop all of the nodeagents and application servers in the cell. Stop the Web server(s). Start the Deployment Manager.

3. Replace the Deployment Manager certificate.

i. In the Administrative Console, go to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates > Create a self-signed certificate

 

ii. Enter the required attributes.

Alias : cell_default
Common name : <hostname>
Validity period : <number of days> <-- this can be set greater than 365
Organization : <company>

Click OK and Save the changes.

iii. Return to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal certificates

iv. Select the old certificate and click Replace.

v. On the next screen, you are able to choose which certificate will replace the old certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers. Accept your new certificate and any browser prompts.

vi. On the next screen, select the old certificate and click Delete. Click OK and Save the changes.

At this point the Deployment Manager has its certificate replaced.

4. Add the Deployment Manager signer certificate to the CellDefaultTruststore.

i. Go to SSL certificate and key management > Key stores and certificates.

ii. Select CellDefaultKeyStore and CellDefaultTrustStore and click Exchange signers.



iii. Select the certificate in CellDefaultKeyStore personal certificates created in previous step and click Add.



Click OK and Save the changes. 

5. Replace the certificate on the node(s).

This step will need to be done for each node in the cell.

i. Go to Security > SSL certificate and key management > Manage endpoint security configurations.

ii. Under Inbound, click the link for the node, node_name (NodeDefaultSSLSettings,null).

iii. Click the Manage certificates button.



iv. Click Create a self-signed certificate.

v. Enter the required attributes.

Alias : nodeX_default <-- where X is the node number
Common name : <hostname>
Validity period : <number of days> <-- this can be set greater than 365
Organization : <company>

Click OK and Save the changes.

vi. Return to Security > SSL certificate and key management > Manage endpoint security configuration s, click node_name (NodeDefaultSSLSettings,null), clickManage certificates.

vii. Select the old certificate and click Replace.

viii. On the next screen, you are able to choose which certificate will replace the old
certificate. Accept your new certificate. Do not select either Delete old certificate after replacement or Delete old signers.

ix. On the next screen, select the old certificate and click Delete. Click OK and save the changes.

6. Add the Node signer certificate to the CellDefaultTruststore.

This step will need to be done for each node in the cell.

i. Go to Security > SSL certificate and key management > Manage endpoint security configurations.

ii. Under Inbound, click the link for the node, node_name (NodeDefaultSSLSettings,null)and select Key stores and certificates.

iii. Select NodeDefaultKeyStore and CellDefaultTrustStore and then Click Exchange signers.

iv. Select the certificate in NodeDefaultKeyStore personal certificates created in previous step and click Add.



Click OK and Save the changes.

7. Repeat steps 5 and 6 for each node in the cell.


8. Delete the old signer certificates and extract the new ones.

i. Go to SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates

ii. Select all of the old signer certificates and click Delete. If you are not sure, you can compare the Fingerprint and/or the Expiration dates with the personal certificate in the keystores.

iii. Select one of the new certificates. Click Extract.

iv. Enter a File Name that corresponds to the certificate. For example, node1.arm. ClickOk.

v. Repeat iii. and iv. for each of the new certificates making sure you have done this for thecell signer and all of the node signers. These files are saved to the profile_root/Dmgr/ directory.

9. Manually copy the trust store to each of the /etc directories.

i. Backup the trust.p12 in profile_root \Dmgr\etc

ii. Copy the profile_root \Dmgr\config\cells\ cell-name \trust.p12 to profile_root\Dmgr\etc

iii. Backup the trust.p12 on each of the nodes profile_root \Appsrv\etc directories.

iv. Copy the profile_root \Dmgr\config\cells\ cell-name \trust.p12 to profile_root\Appsrv\etc

v. Repeat the previous step for each node in the cell.

10. This step is optional. It only needs to be performed if you are running at a level previous to 6.1.0.23. You do not need to stop the nodeagent(s) and appserver(s) if you are at or above this level.

i. Restart the Deployment Manager.

ii. Run a command line syncNode from each of the nodes.

iii. Start the nodeagents and application servers. They should now be fully synchronized with the new certificates in place. 

11. Propagate the signer certificate(s) to plug-in(s).

i. Go to Servers > Web servers. Click webserver_name, then under Additional Properties click Plug-in properties.

IMPORTANT NOTE : Depending on your configuration you may or may not be able to perform the next 3 steps with the console. If the fields are greyed out and you are unable to manage your plugin-key.kdb from the console you will need to use IKEYMAN to manually add the certificates from step 8. iv. to the Web server plugin-key.kdb file and then continue at step 11 v.

ii. Click Manage keys and certificates under Additional Properties, click Signer certificates and then click Add.


iii. Enter a unique Alias Name and then specify the File Name that you created in step 8. iv.

iv. Repeat this for each of the new certificates making sure you have done this for the cell signer and all of the node signers.

v. Manually copy the plugin-key.kdb from the local configuration to the Web server.

Default local configuration location:
profile_root \Dmgr\config\cells\ cell-name \nodes\ node-name \servers\ web-server-name \plugin-key.kdb

Default Web server location:
Web-server-root \Plugins\config\ web-server-name \plugin-key.kdb

Note: You can also determine the location from the Plug-in properties page in step i.

vi. Repeat steps i. to v. for each Web server if you have more than one.

vii. Start the Web server(s).