WLS Tips and More

Weblogic LDAP and Active Directory Provider Failover

2012-01-27T11:06:00.001-02:00

One of my customers was trying to implement the LDAP Provider failover capability in WLS 10.3.2 and after a lot of effort he gave up.

I took ownership of the problem and started to investigate what was going on.

According to the official documentation at Configuring Failover for LDAP Authentication Providers,

you can configure the provider to enable failover when one of the LDAP servers is not available.

Unfortunately, we discovered that this functionality only worked when the server was starting up, which is when it creates the connections to the LDAP server.

Well, though it is good to have this capability at start up, the real need was to have server being capable of recover from a LDAP crash or failed connectivity, at runtime.

If during the server operation, the main LDAP server crashed, every LDAP user authentication would fail, since WLS could not failover to the secondary LDAP at runtime.

The documentation didn't mention if the failover was supposed to happen only at startup or runtime.

Since our understanding was that it should failover in both situations, we went ahead and created a SR with a simple test case, asking for a fix for this problem.

The SR and the bug development went through very fast and a patch was provided a few days later.

Now, my customer has implemented this solution and their environments are more stable, thanks to the WLS ability to recover from a bad LDAP server.

If you have a valid Oracle Support License and want to implement this too, log a SR asking for a patch for bug 13064396 - WEBLOGIC 10.3.2 - LDAP AUTHENTICATOR PROVIDER UNABLE TO FAILOVER.

I believe this fix didn't make to the latest WLS release, 12c, but the backport shouldn't be a problem.

Good Luck!

Weblogic and JMS Queue Message Filtering

2011-10-17T17:22:00.000-02:00

Recently, one of my customers presented me the following scenario:

On a JMS Queue he had a Producer and several JMS consumers. The producer sends messages to the Queue that are to be consumed by a specific Client.

My customer wanted to know how to implement their JMS Queue Sender and Receiver to only post/get the messages they are supposed to.

WLS provides a set of predefined message headers that can be set to implement such logic or you can define your own set of message properties:

Setting and Browsing Message Header and Property Fields

Once the producer sets a message property, you can instantiate a consumer with a selector to filter only the messages that matches the filter expression:

Filtering Messages

So, in the above example, client C1 would only receive messages tagged with property "M1" and client C2 would only get messages tagged "M2".

Keep reading to see how the sample classes work....

The Filtering expressions follow a SQL standard similar to the 'WHERE' clause. So, Filters could include expressions like:

"salary > 64000 and dept in ('eng','qa')"

"product like 'WebLogic%' or product like '%T3') and version > 3.0"

"hireyear between 1990 and 1992 or fireyear is not null"

and so on...

I have provided a small example of a QueueSender.java and a QueueReceiver.java that implements filtering

Download Examples Here

To test them, on a WLS domain, create a Connection Factory with JNDI name as "QCF" and a Queue with JNDI name as "TestQ". (Sources are attached in case you want to change anything).

Open a command prompt and run setDomainEnv.cmd(.sh) script provided with WLS.

Go to the place where you extracted the provided classes and run the QueueReceive.class with "java examples.samples.QueueReceive".

Then run the QueueSender with "java examples.samples.QueueSend"

Note that the QueueSend, sends 4 messages: two to CONSUMER_1 and other two to CONSUMER_2, but only messages tagged to CONSUMER_1 are retrieved from the Queue.

You can check this by monitoring the Queue in the WLS Admin Console.

Checking the Message properties we can see that only the ones with property "RECIPIENT_ID = CONSUMER_2" are lef tin the Queue.

Not only the Message Filtering can enable a more sofisticated logic to your JMS applications but it can improve the system performance by only retrieving the messages that are addressed for that specific client.

Reference:

Programing Weblogic JMS
Message API

Weblogic Log Viewer

2011-10-14T16:51:00.002-03:00

This is a small and simple but very helpful tool I developed to visualize WLS logs.

The motivation to write it came with the need to filter WLS logs by columns: it really helps to analyze logs by filtering out what is not relevant and concentrating in what is related to your problem.

It is a WIP, and currently it can only parse WLS logs (not stdouts) that use line start tag as "####".

You can filter by any of the predefined 12 columns: Time Stamp, Severity, Subsystem, Machine, Server, Thread ID, User ID, Transaction ID, Diagnostic Context, Raw Time, Message ID and Message Text.

You can also re-order the columns and resize them. There's a button to conveniently copy the contents of the selected line (only the message) to the clipboard.

Give it a try and let me know what you think. Download the jar at the end of this post and start it with java -jar WLSLogViewerApp.jar.

Download WLS Log Viewer

Weblogic Server Auditing Framework and Custom Audit Provider

2011-09-21T16:20:00.000-03:00

Ever wanted to know who changed what in your WLS domain?

One very helpful tool, specially in environments where the administration is carried on by a team, the Auditing Provider, can log every operating requests made to the domain.

It has a cost though: the auditing logs tend to grow very fast, since the default Auditing Provider logs pretty much every action taken on the domain.

The official docs explain how the Auditing provider works and how to configure the defaul Auditing Provider: Auditing Providers

But to most customers, a simple "who/when/what" combination of configuration changes is enough.

Fortunately for us, WLS provides a Security Service Provider Interface which we can implement and a ManagedBean Generator tool to create an MBean to configure our provider in the AdminConsole.

So, if you're interested in develop your custom Audit Provider to log only the information you need, read on...

Note 1: All the required classes and a complete Eclipse project (including an ant build to perform the required tasks: compile, package, deploy, etc) is included to make things easier (yes, I'm lazy).

Note 2: This work was based on the official docs, Auditing Providers, and another blog with great and detailed material that was essencial to get this done: How to Develop Weblogic Custom Audit Provider

1. Download the Eclipse Project (I used Eclipse Indigo with Oracle WebLogic Server Tools plugin installed): Eclipse Project

2. Import the project into your workspace.

You might need to resolve some classpath references and project facets.

You need to have those jars in your build path: WL_HOME/server/lib/weblogic.jar and WL_HOME/server/lib/wls-api.jar

The Project uses Oracle Weblogic Server 11gR1 Patchset 2 as Runtime.

3. Edit the build.xml and set the global properties according to you environment.

The build.xml should have enough comments explaining all the properties and target's utilization.

4. Edit the SimpleSampleAuditor.xml to add/remove properties of your MBean.

This Mbean will initiate and set/get the properties for you Custom Provider.

Some of the MBean properties are required and some is user defined.

Here you can define any property that you might want to use in your Provider Implementation and can be configured at runtime in AdminConsole.

I have already added in this example LogFileName, Enabled, LogSizeLimit and MaxNumberLogFiles.

If you want to remove them and add other properties remember to update the SimpleSampleAuditProviderImpl.java code.

5. Generate the MBean with the definition you created in the SimpleSampleAuditor.xml.

For this purpose, I included a target defined in the build.xml, updateMBean. Use this target everytime you make changes to your MBean definition to update the MBean stub in your project.

6. Implement your Custom Provider login in SimpleSampleAuditProviderImpl.java.

The methods you want to imnplement are initialize(), shutdown() and writeEvent().

The Auditing Process uses Channels, Events and Contexts to audit information of the several WLS subsystems.

In my case, I just want to log configuration changes made to the domain and ignore everything else.

So, I just have to worry about the events related to ConfigurationEvents: AuditCreateConfigurationEvent, AuditDeleteConfigurationEvent and AuditSetAttributeConfigurationEvent, despite of the channel or Context they originated from.

7. Package and deploy

Once you have your MBean and SimpleSampleAuditProviderImpl all set, it's time to package and deploy the Custom Auditor.

Considering you have all the build.xml properties correctly set, run the target createCustomProvider and it will compile and package the required classes into a jar file, defined in your build.xml.

To deploy, just run deploy target.

By deploy, we mean to copy the jar file to BEA_HOME/wlserver_10.3/server/lib/mbeantypes folder.

8. Edit your server's classpath

The last step is to add the jar file to your server's classpath. Edit your server startup script to add the reference to your Auditor jar.

9. Startup the server and Create your new provider.

Go to AdminConsole - Security Realms - myrealm - Providers - Auditing.

Click "New" and give your provider a name.

Select Type: SimpleSampleAuditor

Click OK.

10. Configure your provider

Click on the provider you've just created.

Go to Provider Specific tab.

There you can see the properties you've defined in you SimpleSampleAuditor.xml. You can change the default values there, to anything you like.

Depending on your implementation, you might want to restart the server to meke the changes effective.

11. Check if it works.

Make any configuration change, let's say, create a cluster.

Go to your Auditor log to see the information it captured.

This is a basic starting point to create more complex Auditing providers and you can extend this simple example to your needs.

I hope it helps to keep track of who changed what in your environment.

Cheers!

JRockit remote monitoring behind firewall and SSH Tunnel

2011-08-23T15:27:00.000-03:00

In some situations, where a JRockit JVM is running behind a firewall, remote monitoring could become a hard task to accomplish, specially if a SSH tunnel is required to reach the server running the JVM...

Read on for 2 scenarios where we can enable remote monitoring with JRockit Mission Control.

The problem happens due to the way JMX clients connects to the JMX server:

1 - When the JMX client makes a connection, it first connects to the RMI Registry on the server.

2 - The RMI Registry is listening on the port you define in the -Xmanagement:port=REGISTRY_PORT.

3 - After the client connects to the RMI Registry, they negociate another connection to expose the MBeans data, in the form of jmxhost:jmxport.

4 - This port is not known until the connection is made, making it difficult to set firewall rules to enable traffic between client and server.

Fotunately, JRockit R28 has added some changes that makes it easier to remotely monitor a JVM running behind a firewall.

Quoting the official documentation:

"To allow RMI communication between the JRockit JVM server and a client through a firewall, two ports (RMI Registry and RMI Server) are required to configure the firewall.
In previous releases, the RMI Server port number was generated randomly on the JRockit JVM server; so it was not possible to configure the firewall in advance.
In JRockit JVM R28.0, the JMX agent enables you to select the same port number for the RMI Registry and the RMI Server.
Therefore, you can use the default JMX agent for RMI communication through a firewall."

So, basically all you have to do is to add port and rmiserver_port to your Xmanagement JVM options, something like:

-Xmanagement:port=REGISTRY_PORT,rmiserver_port=RMI_SERVER_PORT

and have both ports open in the firewall rules, like the picture below:

Now, I have faced some situations where, for security reasons, the server where the JVM is running can only be accessed via SSH tunneling, because the Firewall rule can only be set to a known or trusted IP Address, like below scenario:

This breaks our first example, since the connection negotiated to expose the MBeans data uses a jmxhost:jmxport format, defined by the JMX Registry, leading the client to connect directly to jmxhost:jmxport in the machine where the JVM is running.

In such situations, we can make use of yet another -D option to trick the client to connect to the machine where the SSH Tunnel is running.

Just add -Djava.rmi.server.hostname=MachineA (using our example above) to force the client to connect to MachineA, where the SSH tunnel is running.

So, in our JVM startup options, we would have something like:

-Xmanagement:port=REGISTRY_PORT,rmiserver_port=RMI_SERVER_PORT -Djava.rmi.server.hostname=MachineA

and in Mission Control we would use a Custom JMX Service URL, like:

service:jmx:rmi://MachineA:RMI_SERVER_PORT/jndi/rmi://MachineA:REGISTRY_PORT/jmxrmi

References:

Changes in the JMX Agent

JMX Agent-Related –D Options

Mark Feeney Blog

Daniel Fuchs Blog

Happy monitoring!!!

Execute Queue and Thread Dumps

2011-08-03T17:29:00.000-03:00

Once a customer asked me if there is a way to monitor his server execute queue to understand which threads and applications might be causing the contention in the server's requests execution.

I have written a quick and dirty WLST script that monitors remotely this specific server execute queue, and in case it get any higher than a desired value, it takes a thread dump, and saves it to a file on my local machine.

The Server's execute queue may indicate that there are more requests getting to the server than it is capable of serving them, causing incoming request to clog up in the WLS execute queue, waiting for available threads to process its request.

A thread dump is a great way to quickly look at what the server threads are doing at a moment in time, and can give valuable information to help diagnose the bottleneck in your application.

Those kind of situations might be intermittent and may occur in a time spam of a few seconds, making it difficult to take a thread dump, in the right moment it is happening.

Using the script below, one can monitor the execute queue and take thread dumps at exactly the same time the issue is happening.

Download the example here: Monitor Server Execute Queue

You can modify the script to monitor other MBeans Attributes as well, like hogging threads and such.

To use it, just open terminal and run setDomainEnv.sh(cmd) and then "java weblogic.WLST monitorWLSQueue.py".

It will use the variables defined in the .py file to connect to the specified server/port/user/pwd, so it is important to edit the file before running it.

Cheers!

Weblogic on YouTube!!

2011-07-11T11:53:00.001-03:00

Check out the official WLS channel on YouTube:

Oracle WebLogic on YouTube

There we can find great videos on tips and information on WLS.

Enjoy!!

Recover and Reset Weblogic Admin Password

2011-06-28T17:18:00.004-03:00

In this post we will explain how to recover and reset the WLS Admin Password.

If you ever forgot the Admin password, this is a safe and easy way to recover it without decrypting or hacking any WLS file.

For this, we'll just use WLS own tools to log on to Admin Console and reset the Admin Password.

Read on after the jump for the step by step...

For this example we will use a standard WLS 10.3.3 domain, located at: C:\bea\wls\user_projects\domains\base_domain.

This will be referred as DOMAIN_HOME from now on.

1) First of all make sure the Admin Server is stopped.

2) Open a command prompt and go to you DOMAIN_HOME/bin directory (C:\bea\wls\user_projects\domains\base_domain\bin)

3) Run setDomainEnv.sh(cmd)

4) Run the following command (without the quotes): "java weblogic.security.utils.AdminAccount NewAdminUser NewAdminPassword ."

Note 1: the dot (".") at the end of the command, is necessary to run the command in the current location.

Note 2: NewAdminUser and NewAdminPassword are the user and password we are using to create a temporary AdminUser to log on to WLS.

In this example we used "TempAdmin" for username and "TempPass123" for password.

5) The command will create a file called "DefaultAuthenticatorInit.ldift" in the current directory.

6) Go to DOMAIN_HOME\security and rename the old "DefaultAuthenticatorInit.ldift", for precaution, to something like "DefaultAuthenticatorInit.ldift.bkp".

7) Copy the recently created "DefaultAuthenticatorInit.ldift" to DOMAIN_HOME\security

8) Edit the boot.properties located at DOMAIN_HOME\servers\AdminServer\security and give the values used for user/password in the step 4.

The original values should be a encrypted string, just enter the values as plain text.

For example:

password=TempAdmin
username=TempPass123

9) Delete the file named "DefaultAuthenticatormyrealmInit.initialized" located in DOMAIN_HOME\servers\AdminServer\data\ldap

10) Go back to your DOMAIN_HOME and start the server with the following command (without the quotes): "java weblogic.Server"

11) Once the server comes in RUNNING state, shut it down again and restart it with startWeblogic.sh(cmd)

12) After the server comes up again, log in to Admin Console with the user/pass created in step 4

13) Go to Security Realms > myrealm > Users and Groups

14) Here you can select your default WLS Admin user (in my case, weblogic) and change his password.

15) To change it, select the user and go to "passwords" tab, provide the new password and save it.

16) After that you can restart your server and edit the boot.properties again to use your new admin user password and then delete the temporary user created for this purpose.

I tested this with WLS 10.3.3 but I have done other times on different WLS versions. It should work with 10.x up to 10.3.5.

Hope it helps, enjoy!

Configuring WLS for SSO using Kerberos protocol

2011-06-08T10:00:00.001-03:00

In this post we will go step-by-step on how to configure WLS and Windows Integrated Authentication using Kerberos protocol.

I will not go over the theory of how Kerberos works and the general idead behind it. There's plenty of documentation in the web that covers it much better than I could do.

I always found it hard to get a detailed guide on how to implement the solution with a real example with details.

So, after struggling with Kerberos in several customer's issues and implementations, I decided to post here my experience with this small tutorial.

I hope it helps people to get started.

I. Required Environment

a. KDC/AD machine
OS: Windows 2003 Server
Domain: kerberossso.com
Machine: win2003
IP: 192.168.0.100

b. Windows Client
OS: Windows XP SP3
Domain: kerberossso.com
Machine: win-xp
Client: IE 7
User: wlsuser3 (this user needs to be created on the AD and will log on to the kerberossso domain)
Pass: Letmein123
IP: 192.168.0.101

c. Weblogic Server 10.3.3
OS: Oracle Enterprise Linux 5
Machine: wlshost
IP: 192.168.0.102
WLS Domain: KerberosDomain (A standard WLS domain with just the AdminServer)

Note: Additional files and test application to complete this step-by-step will be provided at the end of the post.

II. AD Setup for client machine

a. create the following user in AD
b. User: wlsuser3
c. Password: Letmein123

d. Log on in the Windows XP machine (Client) with wlsuser3/Letmein123 in kerberossso.com domain

III. AD Setup for Weblogic Server

a. Create a user in the AD to represent the WLS. When creating the user account, use the simple name of the computer. For example, if the host is named myhost.example.com, create a user in Active Directory called myhost.
b. Create a new user wlshost and set the password to Letmein123
c. The user account's encryption type must be DES and the account must require Kerberos pre-authentication.

d. Reset the password to Letmein123 again (Setting the encryption type may corrupt the password)
e. Create the Service Principal Names (SPNs) for the user account created in step a:

setspn -A HTTP/wlshost wlshost

f. Check if the SPN was created successfully. This is an important step. If the same service is linked to a different account in the Active Directory server, the client will not send a Kerberos ticket to the server.

setspn -L wlshost

g. Create a keytab file:

ktpass -princ HTTP/wlshost@KERBEROSSSO.COM -pass Letmein123 -mapuser wlshost -mapOp set -DesOnly -crypto DES-CBC-CRC -pType KRB5_NT_PRINCIPAL -SetPass -out wlshost.keytab

h. Reset the password for wlshost user again. For some reason, in my tests, I had to reset the password before testing the keytab file, otherwise it fails to authenticate.

IV. Configuring the WLS Machine to access the KDC

a. Test the keytab file
a1. Create a Kerberos Configuration File (krb5.conf). OEL has a sample krb in /etc/krb5.conf
a2. Edit this file and replace it with the following contents:

[logging]
default = FILE=/root/Oracle/Middleware/user_projects/domains/KerberosDomain/krb5libs.log
kdc = FILE=/root/Oracle/Middleware/user_projects/domains/KerberosDomain/krb5kdc.log
admin_server = FILE=/root/Oracle/Middleware/user_projects/domains/KerberosDomain/kadmind.log

[libdefaults]
default_realm = KERBEROSSSO.COM
dns_lookup_realm = false
dns_lookup_kdc = false
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
ticket_lifetime = 600

[realms]
KERBEROSSSO.COM = {
kdc = 192.168.0.100:88
admin_server = win2003
default_domain = KERBEROSSSO.COM
}

[domain_realm]
.kerberossso.com = KERBEROSSSO.COM

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

a3. Save the krb5.conf
a4. Copy the keytab file, wlshost.keytab, (generated on step III) to the WLS domain root folder, KerberosDomain
a5. Run the following command to test the keytab and generate a cache for the kerberos ticket:

kinit -V -k -t /root/Oracle/Middleware/user_projects/domains/KerberosDomain/wlshost.keytab HTTP/wlshost@KERBEROSSSO.COM

a6. You should see a message like:

Authenticated to Kerberos v5

a7. Kerberos keytab and configuration works fine and a ticket was cached in your machine. To see the cached tickets, you can run the following command:

klist

a8. If everything went well, you should see something like:

V. Configuring WLS to access the KDC

a. Move the /etc/krb5.conf to your domain's root folder (/root/Oracle/Middleware/user_projects/domains/KerberosDomain/)
b. Create a JAAS loging file in the Domain's root folder (jaas.login) with the following contents:

com.sun.security.jgss.initiate {

com.sun.security.auth.module.Krb5LoginModule required
principal="HTTP/wlshost@KERBEROSSSO.COM"
useKeyTab=true
keyTab="/root/Oracle/Middleware/user_projects/domains/KerberosDomain/wlshost.keytab"
storeKey=true
useTicketCache=true
doNotPrompt=true
debug=true;
};

com.sun.security.jgss.krb5.accept {

com.sun.security.auth.module.Krb5LoginModule required
principal="HTTP/wlshost@KERBEROSSSO.COM"
useKeyTab=true
keyTab="/root/Oracle/Middleware/user_projects/domains/KerberosDomain/wlshost.keytab"
storeKey=true
useTicketCache=true
doNotPrompt=true
debug=true;

};

c. Note: Available options for jaas.login:

Debug: true/false
storeKey: true/false
useTicketCache: true/false
useKeyTab: true/false
doNotPrompt: true/false
isInitiator: true/false
KeyTab: <PATH_TO_KEYTAB>
refreshKrb5Config: true/false
principal: <SPN>
tryFirstPass: true/false
useFirstPass: true/false
storePass: true/false
clearPass: true/false

d. Your domain root folder (/root/Oracle/Middleware/user_projects/domains/KerberosDomain/) should now contain:
c1. wlshost.keytab
c2. jaas.login
c3. krb5.conf

e. Edit your startWeblogic.sh script to add the following parameters to your JAVA_OPTION variable:

-Dsun.security.krb5.debug=true
-Dweblogic.security.enableNegotiate=true
-Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.auth.login.config=/root/Oracle/Middleware/user_projects/domains/KerberosDomain/jaas.login
-Djava.security.krb5.conf=/root/Oracle/Middleware/user_projects/domains/KerberosDomain/krb5.conf

f. Startup WLS and go to Security Realm / myrealm / Providers / Authentication
g. Create a new "Negotiate Identity Asserter" provider, and give it a name.
h. Click on the recently created Negotiate Identity Assertion provider and go to Configuration / Provider Specific and uncheck "Form Based Negotiation Enabled"
i. Restart WLS

VI. Configuring Application and User to access protected resources

(If your WLS has users and groups imported from an AD Provider, skip next step)
a. In WLS Admin Console, go to Security Realm / myrealm / Users and Groups and create a user called wlsuser3. Set a password.
b. Check/edit the web.xml and weblogic.xml from the provided application (check the end of this post)

web.xml:

<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<welcome-file-list>
<welcome-file>welcome.html</welcome-file>
</welcome-file-list>
<security-constraint>
<display-name>Constraint-0</display-name>
<web-resource-collection>
<web-resource-name>BasicSecureApp</web-resource-name>
<url-pattern>/secured/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>SSOrole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
<role-name>SSOrole</role-name>
</security-role>
</web-app>

weblogic.xml:

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<security-role-assignment>
<role-name>SSOrole</role-name>
<principal-name>wlsuser3</principal-name>
</security-role-assignment>
</weblogic-web-app>

c. Update the web.xml and weblogic.xml to the provided war (you can use winzip, 7zip or winrar to open, edit and update the files to the WAR).

d. Deploy the provided application to WLS.

VII. Configuring the IE for Integrated Windows Authentication

a. In Internet Explorer, select Tools Internet Options.
a1. Select the Security tab.
a2. Select Local intranet and click Sites.
a3. In the Local intranet popup, ensure that the "Include all sites that bypass the proxy server" and "Include all local (intranet) sites not listed in other zones" options are checked.
a4. Click Advanced.
a5. In the Local intranet (Advanced) dialog box, add all relative domain names that will be used for WebLogic Server instances participating in the SSO configuration (for example, wlshost) and click OK.

b. Configure Intranet Authentication
b1. Select Tools Internet Options.
b2. Select the Security tab.
b3. Select Local intranet and click Custom Level....
b4. In the Security Settings dialog box, scroll to the User Authentication section.
b5. Select "Automatic logon only in Intranet zone". This option prevents users from having to re-enter logon credentials, which is a key piece to this solution.
b6. Click OK.

c. Verify the Proxy Settings

c1. If you have a proxy server enabled:
c2. Select Tools Internet Options.
c3. Select the Connections tab and click LAN Settings.
c4. Verify that the proxy server address and port number are correct.
c5. Click Advanced.
c6. In the Proxy Settings dialog box, ensure that all desired domain names are entered in the Exceptions field.
c7. Click OK to close the Proxy Settings dialog box.

VIII. Does it work?

With the application deployed and IE configurations done, go to http://wlshost:7001/BasicSecureApp/index.jsp or whatever name you have to your host/port.

IX. Things to check

a. Check the KDC, client and WLS clocks. They must be synchronized in order to KDC grants a ticket.

b. If you're using Windows 2008 Server, by default, it does not support DES encryption. Check http://technet.microsoft.com/en-us/library/dd560670%28WS.10%29.aspx

c. Check the Kerberos debug information, it should be printed to the WLS sdtout if you set debug true in the jaas.login file.

X. Files

BasicSecureApp

jaas.login

krb5.conf

XI. Reference and Documentation

a. kinit reference
http://linux.die.net/man/1/kinit

b. klist reference
http://linux.die.net/man/1/klist

c. kdestroy reference
http://linux.die.net/man/1/kdestroy

d. Configuring SSO with Microsoft Clients
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/sso.html

e. krb5.config Options
http://linux.die.net/man/5/krb5.conf

f. setspn
http://technet.microsoft.com/en-us/library/cc773257(WS.10).aspx

g. ktpass
http://technet.microsoft.com/en-us/library/cc753771(WS.10).aspx

h. JAAS login file configuration options
http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/tutorials/LoginConfigFile.html

i. WLs 10.3.4
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13707/sso.htm#i1106670

http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html

Exporting Weblogic Embedded LDAP Server

2011-05-20T10:38:00.003-03:00

The embedded LDAP server is the default security provider database for the WebLogic Authentication, Authorization, Credential Mapping and Role Mapping providers.

It contains user, group, group membership, security role, security policy, and credential map information.

Oftentimes, users need to migrate a whole WLS domain to another machine or to make a mirror copy of the domain in another environment, or to just make a backup copy of your Security Realm.

For this purpose there is the pack and unpack domain or the Domain Template Builder, but they don't migrate the Embedded LDAP data.

If you have created users, groups, roles, etc in your embedded LDAP, you'd have to recreate them manually, after the domain is brought up the the new machine.

Fortunately, WLS comes with a tool to export the whole content of your WLS security Ream, read after the jump on how to migrate the whole content of the WLS security ream.

Migrating the contents of your Security Realm is simple, you only need access to the Admin Console.

1 - Go to "Security Realms", "myrealm".

2 - Select "Migration" and "Export" tab

3 - Enter a folder where it should generate the exported files and click "Save".

4 - 5 Files should be created in the designated folder:

DefaultAuthenticator.dat, DefaultCredentialMapper.dat, exportIndex.dat, XACMLAuthorizer.dat and XACMLRoleMapper.dat.

5 - To import them to the target domain, just to the same as before, but this time choose the "Import" tab.

6 - Enter the folder where you have the files stored and click "Save".

There you go, all your users, groups, roles, security policies, etc are now available in the new domain!

Manually tuning Weblogic Socket Readers (Muxer Threads)

2011-04-29T10:34:00.002-03:00

Weblogic uses special threads, called Muxers, to read incoming requests on the servers.

Those threads' main responsability is to read the request and pass the work to the correspondent Execute Thread.

WLS allocates a percentage of execute threads from the self-tuning thread pool to be Muxer Threads.

By default this value is 33% of the thread pool and cannot exceed 50%.

If you need to manually tune the number of socket reader threads, keep reading after the jump:

This configuration is made in the Administration Console:

a. In the left pane of the Console, expand Environment > Servers.
b. On the Summary of Servers page, select the server instance for which you will configure the number of available socket readers.
c. Select Configuration > Tuning and update Socket Readers.

Sometimes people feel they need to fine tune the number of available socket readers and manually assign a arbitrary number to the Muxer Threads, instead on a percentage.

It is as simple as pass this argument to the JAVA_OPTIONS:

-Dweblogic.SocketReaders=NUMBER_OF_THREADS

If you want to have, let's say, 10 MuxerThreads, -Dweblogic.SocketReaders=10, and take a thread dump on your running WLS process, you should see ten of those:

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=25 idx=0x58 tid=4820 prio=5 alive, in native, daemon
   at weblogic/socket/NTSocketMuxer.getIoCompletionResult(Lweblogic/socket/NTSocketMuxer$IoCompletionData;)Z(Native Method)
   at weblogic/socket/NTSocketMuxer.processSockets(NTSocketMuxer.java:81)
   at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)
   at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)
   at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)
   at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)
   at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
   -- end of trace

This should work with WLS 8.1.x up to 10.3.4.

Remember to use this with caution.

Links:

WLS Tuning
Tuning Socket Readers

JAX-RPC Webservices with 2-way SSL in Weblogic 10.3.3

2011-04-18T16:30:00.002-03:00

In this article we will configure 2 weblogic domains, one hosting a webservice working as a "consumer" WS, that we will call ClientDomain.

The other domain, the ServiceDomain, will host a webservice working as a "service" WS. Both webservices are going to exchange information in 2-way SSL.

Keep reading the step by step instructions after the jump:

1. Before we begin

we assume we have 2 physical machines with a vanilla WLS 10.3.3 installation.

We need to create 2 standard Weblogic domains as following:

MachineA: ClientDomain
AdminServer
http listen port: 7001
https listen port: 7002

MachineB: ServiceDomain
AdminServer
http listen port: 7001
https listen port: 7002

2. Configuring Server’s Identity and Trust

Reference: WLS Identity and Trust

In our example, we will use Self Signed Certificates (generated with keytool) for our server’s identity. In a real world example, one would use certificates provided by one on the truested CA.

2.1 Generating the key pair for ClientDomain (Machine A):

a) Go to your domain home, "bin" folder and open a command prompt
b) Run setDomainEnv.cmd(sh)
c) Run the following command:

keytool -genkey -alias client_cert -keyalg RSA -keysize 1024 -keypass keypass123 -keystore ClientIdentity.jks -storepass storepass123

d) Provide the information required by the keytool.
e) A file should be created in your domain home: ClientIdentity.jks

2.2 Generating the key pair for Service Domain (Machine B):

a) Go to your domain home, "bin" folder and open a command prompt
b) Run setDomainEnv.cmd(sh)
c) Run the following command:

keytool -genkey -alias server_cert -keyalg RSA -keysize 1024 -keypass keypass123 -keystore ServerIdentity.jks -storepass storepass123

d) Provide the information required by the keytool.
e) A file should be created in your domain home: ServerIdentity.jks

Both files created are keystores which contains the server’s key pair (a public key and associated private key). The public key is wrapped as a self-signed certificate, which is stored as a single-element certificate chain.

3. Exporting the certificate to a certificate file

3.1 For the ClientDomain:

a) Run the following command: keytool -export -rfc -alias client_cert -file ClientCert.cer -keystore ClientIdentity.jks -storepass storepass123
b) A file should be created on your domain home, ClientCert.cer

3.2 For the ServiceDomain:

a) Run the following command: keytool -export -rfc -alias server_cert -file ServerCert.cer -keystore ServerIdentity.jks -storepass storepass123
b) A file should be created on your domain home, ServerCert.cer

Both files are the exported certificate, created with a printable encoding format, as defined by the Internet RFC 1421 standard, since the -rfc option was specified.

4. Importing the server’s certificate to the trust store

a) Copy the ClientCert.cer from MachineA to MachineB
b) Copy the ServerCert.cer from MachineB to MachineA
c) Save both files to your server’s "BEA_HOME\wlserver_10.3\server\lib" folder, in both MachineA and MachineB.
d) In Machine A, in the same command prompt used in the previous steps, change to "BEA_HOME\wlserver_10.3\server\lib" folder and run the following command:

keytool -import -v -trustcacerts -alias server_cert -file ServerCert.cer -keystore cacerts -storepass changeit

e) In Machine B, in the same command prompt used in the previous steps, change to "BEA_HOME\wlserver_10.3\server\lib" folder and run the following command:

keytool -import -v -trustcacerts -alias client_cert -file ClientCert.cer -keystore cacerts -storepass changeit

Now, both servers are configured to trust each other certificates.

5. Configuring keystores

a) Start Both ClientDomain and ServiceDomain AdminServer’s
b) Go back to you domain home, "bin" folder and run "startWebLogic.cmd(sh)"
c) Do this for ClientDomain and ServiceDomain
d) Once both servers are running, open the admin console by going to:

http://MachineA:7001/console
http://MachineB:7001/console

e) For both domain, go to "Environment > Servers > AdminServer"
f) Click on "Configuration > Keystore" tab
g) Click on the "Change" button for the server keystore

h) Select "Custom Identity and Custom Trust" and click "Save"

i) Fill the information for each domain according to the table bellow (you might need to adjust it to your own paths):

Keystore Settings for ClientDomain
----------------------------------
Custom Identity Keystore: D:\bea\wls1033\user_projects\domains\ClientDomain\ClientIdentity.jks

Custom Identity Keystore Type: JKS

Custom Identity Keystore Passphrase: storepass123

Custom Trust Keystore: D:\bea\wls1033\wlserver_10.3\server\lib\cacerts

Custom Trust Keystore Type: JKS

Custom Trust Keystore Passphrase: changeit

Keystore Settings for ServiceDomain
-----------------------------------
Custom Identity Keystore: C:\bea\wls1033\user_projects\domains\ServiceDomain\ServerIdentity.jks

Custom Identity Keystore Type: JKS

Custom Identity Keystore Passphrase: storepass123

Custom Trust Keystore: C:\bea\wls1033\wlserver_10.3\server\lib\cacerts

Custom Trust Keystore Type: JKS

Custom Trust Keystore Passphrase: changeit

6. Configuring SSL for both servers

a) Go to "Configuration > SSL" tab
b) Provide the following information according to the table below:

SSL Settings for ClientDomain
----------------------------------
Private Key Alias: client_cert
Private Key Passphrase: keypass123
Advanced:
Hostname Verification: None (the certificates we created are not bound to a host name, so host name verification would fail. In a real world example certificates are bound to a server's hostname)
Use Server Certs: checked
Two Way Client Cert Behavior: Client Certs Requested and Enforced
SSLRejection Logging Enabled: checked
Leave the other options as default values.

SSL Settings for ServiceDomain
----------------------------------
Private Key Alias: server_cert
Private Key Passphrase: keypass123
Advanced:
Hostname Verification: None (the certificates we created are not bound to a host name, so host name verification would fail. In a real world example certificates are bound to a server's hostname)
Use Server Certs: checked
Two Way Client Cert Behavior: Client Certs Requested and Enforced
SSLRejection Logging Enabled: checked
Leave the other options as default values.

7. Enable SSL logging

This is not really required but is useful for SSL debugging and to understand how the SSL handshake happens on both sides. Do it for both ClientDomain and ServerDomain.

a) Go to Logging > General
b) Rotation Type: None
c) Minimum severity to log: Debug
d) Redirect stdout logging enabled: checked
e) Log file : Severity level: Debug
f) Standard out : Severity level: Debug
g) Click "Save"
h) Go to "Debug" tab, expand "weblogic > security > SSL".
i) Check SSL and click "Enable"
j) Restart both Servers

8. The webservices

a) There are 2 WS provided with this article: HelloServiceEAR.ear and HelloClientEAR.ear
b) Deploy HelloServiceEAR.ear to the ServiceDomain
c) Open "HelloClientEAR.ear/HelloClient.war/WEB-INF/classes/servlets/messages.properties" and edit the file to point to the HelloServiceEAR endpoint address.
d) Save the messages.properties back to the EAR file.

9. The "Service" webservice

a) HelloServiceEAR.ear is a simple webservice that has just one method that returns a String:

@WebService
public class HelloWS {
@WebMethod
public String sayHello() {
return "Greetings from Remote Service !";
}
}

10. The "Client" webservice

a) Deploy HelloClientEAR.ear to ClientDomain.

HelloClientEAR.ear was built using WLS ant task ClientGen.

Reference: WLS Ant Tasks

The ant task is very simple and takes a WSDL URL as parameter:

With the generated stubs, all we need to do is call "Service" webservice inside a Servlet, so we can test our scenario:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
HelloWSService sample = new HelloWSService_Impl();
HelloWS port = sample.getHelloWSSoapPort();
((Stub)port)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, Messages.getString("ClientTest.0")); //$NON-NLS-1$
String res = port.sayHello();
PrintWriter pw = response.getWriter();
pw.print("Remote Server says: "+res); //$NON-NLS-1$
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}

Note that we set the end point address, in order to point to the correct server / https port of the "Service" webservice.

The String is externalized, but it should be something like:

https://MachineB:7002/HelloService/HelloWS

11. Testing

a) Once both webservices are deployed, go to you ClientDomain testing page. It should look something like:

http://MachineA:7001/HelloClient/ClientTest

b) If everything was properly configured, you should see a message:

Remote Server says: Greetings from Remote Service !

12. Checking the SSL hand shake.

a) If we look at the ClientDomain server logs, we should see the handshake information:

b) If we look at the ServiceDomain server logs, we can see the handshake taking place:

13. Files

HelloServiceEAR.ear

HelloClientEAR

Enjoy!

How to Install Node Manager as Windows Service and Monitor MServers State

2009-09-25T12:45:00.001-03:00

Hello, in this first post I will go step by step on how to install WLS 10.3.1 Node Manager as a Windows Service and configure it to monitor Managed Servers state, that is, to keep them running in case of a crash.

For this we assume that WLS 10.3.1 is installed with the default options and the domains folder follow the standard installation path.
In this example I have created a domain with a AdminServer:7001 and two Managed Servers: ms1:7003 and ms2:7005. Both ms1, ms2 and the AdminServer are configured under machine1, this is a requisite for our configuration.

Step 1 - Configure Node Manager Properties File:
Go to BEA_HOME/WL_HOME/common/nodemanager and open nodemanager.properties. Change the following properties to:
CrashRecoveryEnabled=true
StartScriptEnabled=true

Step 2 - Install Node Manager as Windows Service:
Execute the following script: BEA_HOME/WL_HOME/server/bin/installNodeMgrSvc.cmd.
This should create a Windows Service called "Oracle WebLogic NodeManager (PATH_TO_DOMAIN)". Go to Windows Services and double click it. On the Log On tab, check the option "This Account" and provide the user/password you plan to use to run the WLS under windows. Click OK and start the service.

Step 3 - Starting the AdminServer:
Open a command prompt at BEA_HOME/user_projects/DOMAIN_NAME/bin and run the following script setDomainEnv.cmd. In the same command prompt window type: startWebLogic.cmd. The AdminServer should start now.

Step 4 - Starting the ManagedServers:
Open a browser and go to http://HOST:PORT/console. On the "Domain Structure" panel (upper left), click on Servers. On the Summary of Servers (middle right), go to the Control tab and select ms1 and ms2 and click on Start. The ms1 and ms2 should start.

Step 5 - Testing the work:
Let's go to the Windows Task Manager and check if our servers are there running.
Open the Task Manager (right-click on the windows clock and select the Task Manager option from the contextual menu) and sort the column Image Name. Now let's look for our Java processes....

There we can see our three Java processes, one for AdminServer, one for ms1 and ms2 respectively. You can also find there the Node Manager process, it's something like beasvc.exe. Now, let's simulate a server crash, let's kill our servers processes: select the java processes and click on End Process button. This way the server is abruptly shut-down and to the Node Manager this means a server crash. The Node Manager will restart the processes, and they will appear again on the Task Manager just a few seconds after you've killed it. To simulate a complete OS crash, lets kill the Node Manager process first (beasvc.exe) and then kill the java processes. Now, the java processes won't come back because the Node Manager is not running. Now after rebooting Windows and we can see that the Node Manager starts automatically, and just after that the java processes begins to show up on the Task Manager.

Final Considerations:
If you shutdown a Managed Server normally, be it through the Admin Console (with the provided stop scripts that comes with WLS installation), through WLST or even shutting down windows normally (Start button, Shutdown), the Node Manager will not monitor it anymore, it will consider that the server really should be down.
If you want to keep the AdminServer monitored by the Node Manager as well, you should start it through the WLST: on Step 3 don't use the startWebLogic.cmd. Instead, after setting the domain environments, type: java weblogic.WLST.
Then: nmConnect(domainName='DOMAIN_NAME').
Then nmStart('AdminServer').
This way the Node Manager is aware that it should also monitor the Admin Server state.