Practices Overview
In this practice, you set up the auditing provider and enable domain configuration auditing.
Oracle University and In Motion Servicios S.A. use only
Practice 11-1: Troubleshooting Changes by Using Auditing
Scenario
Someone is making changes to the domain configuration in production. These changes are causing problems. All administrators claim that they did not make the changes. You need to discover who is making these changes.
Overview
In this practice, you configure the default auditing provider and configure auditing of domain configuration changes.
Assumptions
You completed “Practice 7-1: Investigating Application Problems.” All instances of WebLogic Server are running.
Tasks
1. Access host01 and run the setup script.
a. Access host01 and open a Terminal window.
b. Navigate to the current practice directory and run the setup script.
$> cd /practices/tshoot/practice11-01 $> ./setup.sh
Note: This script creates two new users and adds them to the Administrators
group.
2. Set up the auditing provider.
a. Access the admin console. Lock the configuration. b. Navigate to and select the security realm, myrealm. c. Click the Providers > Auditing tabs.
d. Click the New button.
e. Enter the name change_auditor and click OK.
Note: The Type of DefaultAuditor is already selected. f. Select the new auditing provider.
g. Click the Provider Specific tab.
h. Move the following Active Context Handler Entries from Available to Chosen: − com.bea.contextelement.jmx.AuditProtectedArgInfo − com.bea.contextelement.jmx.ObjectName − com.bea.contextelement.jmx.OldAttributeValue − com.bea.contextelement.jmx.Parameters − com.bea.contextelement.jmx.ShortName − com.bea.contextelement.jmx.Signature
Tip: Hover over an entry for a “tool tip” pop-up that displays the full name of the entry.
All of the JMX elements are together.
i. Choose Custom from the Severity drop-down list.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
Practices for Lesson 11: Troubleshooting Security
Chapter 11 - Page 4
Note: With custom chosen, the check boxes determine which severity levels are
audited.
j. Select each of the check boxes to enable all severity levels. k. Save and activate your changes.
Note: Notice that servers must be restarted.
l. Use the admin console to force shut down the managed servers. m. Now use the admin console to force shut down the admin server. n. Close the web browser.
o. Access host01. In a Terminal window, navigate to the practice utility scripts. Run the script to start the admin server.
$> cd /practices/tshoot/utilities $> ./startadmin.sh
p. After the admin server is running, access the admin console again and use it to start the managed servers.
Note: Wait for the managed servers to be running before continuing.
3. Set up domain configuration auditing.
a. Use the admin console to lock the configuration. b. Select the domain, wlsadmin.
c. Click the Configuration > General tabs.
d. Click Advanced.
e. Use the Configuration Audit Type drop-down list to select Change Log and Audit.
Note: This writes domain configuration audit messages to both the admin server log
and the audit provider log. f. Save and activate your changes.
Note: Notice this change does not require any server restarts.
4. Make some domain configuration changes. a. Log out of the admin console.
b. Log in to the admin console as Fred. The username is fred and the password is Welcome1.
c. Lock the configuration, make some innocuous domain configuration change, and activate your changes.
Tip: For example, add a new server. Make the server name something unique, such as
fredserver1, which will be easy to find in the logs. Set the Server Listen Address to either host01.example.com or host02.example.com. Use a port not already in use (like 7015).
d. Log out of the admin console.
e. Log in to the admin console as Wilma. The username is wilma and the password is Welcome1.
f. Lock the configuration and make some other innocuous change. g. Log out of the admin console.
5. View the audit information. a. Access host01.
Oracle University and In Motion Servicios S.A. use only
b. Use the File Browser or a Terminal window to navigate to the directory where the admin server keeps its log files.
$> cd /u01/domains/tshoot/wlsadmin/servers/AdminServer/logs
c. Use the gedit editor to open the admin server’s server log, and the audit log.
$> gedit AdminServer.log DefaultAuditRecorder.log
d. In the AdminServer.log file, use the Find tool to search for the name of the domain resource that you created (or modified) earlier as one of the other administrators. In this example, the user fred created a new managed server called fredserver1. You should find some audit records of the resource being created and modified. For example:
####<Nov 14, 2013 2:04:16 PM UTC> <Info> <Configuration Audit> <host01.example.com> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <fred> <> <> <1384437856692> <BEA-159900>
<USER fred CREATED wlsadmin:Name=fredserver1,Type=Server> ####<Nov 14, 2013 2:04:16 PM UTC> <Info> <Configuration Audit> <host01.example.com> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <fred> <> <> <1384437856705> <BEA-159904>
<USER fred MODIFIED com.bea:Name=fredserver1,Type=Server
ATTRIBUTE ListenAddress FROM TO host01.example.com>
e. Search for the same resource in the audit log, DefaultAuditRecorder.log. The format is different, but the information is basically the same. In this example, it shows the user fred creating and modifying the server fredserver1. Here is the audit record of the server’s creation:
#### Audit Record Begin <Nov 14, 2013 2:04:16 PM> <Severity =SUCCESS>
<<<Event Type = Create Configuration Audit Event> <Subject = Subject: 2
Principal = class
weblogic.security.principal.WLSUserImpl("fred") Principal = class
weblogic.security.principal.WLSGroupImpl("Administrators")> <Object = wlsadmin:Name=fredserver1,Type=Server>>> Audit Record End ####
Note: By using domain configuration auditing, you will be able to tell which
administrative user makes the next configuration change that causes a problem. f. <OPTIONAL> Use the editor to find the audit records of the resource the other user,
wilma, created or modified. g. Exit the editor.
6. Clean up.
a. Access host01. In a Terminal window, navigate to the current practice directory and run the cleanup script.
$> cd /practices/tshoot/practice11-01 $> ./cleanup.sh
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.
Practices for Lesson 11: Troubleshooting Security
Chapter 11 - Page 6
Note: This script disables domain configuration auditing and sets the auditing provider
severity level to ERROR, so less activity is audited.
b. If you want to, you can use the admin console to delete any unneeded domain resources you created to test configuration auditing.