Implications of latest Oracle WebLogic Server connection filters for Oracle EBS r12.2 customers



Above screenshot might click many Apps DBAs who have recently applied -
1. April 2019 CPU Patch
2. Upgraded to Latest AD and TXK level (C.11)


Recently I applied Oracle E-Business Suite Technology Stack Delta 11 on an EBS r12.2.7 implementation.
After applying patch we went for sanity checks and when trying to open Weblogic Server console I got this -
The Server is not able to service this request: [Socket:000445]Connection rejected, filter blocked Socket, weblogic.security.net.FilterException: [Security:090220]rule 2

Below are metalink ids ideally Apps DBAs should refer to for resolving this-
Alternative Methods to Allow Access to Oracle WebLogic Server Administration Console from Trusted Hosts for Oracle E-Business Suite Release 12.2 (Doc ID 2542826.1)
ORA-12547 While Client Connecting Via SSH Tunnel (Doc ID 454252.1)

Oracle Community also has few tips for this-
https://community.oracle.com/message/15413970#15413970


Troubleshooting Part -



cd $FMW_HOME/user_projects/domains/EBS_domain_<CONTEXT_NAME>/config/
cat config.xml | grep connection-filte
    <connection-filter>oracle.apps.ad.tools.configuration.wls.filter.EBSConnectionFilterImpl< connection-filter>
    <connection-filter-rule>appsnode * * allow</connection-filter-rule>
    <connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>




We will be exploring all the 3 scenarios with real-time usecases.

Option 1: Adding Specific Trusted Hosts

1. This can be done by using context variable - s_wls_admin_console_access_nodes
A comma seperated set of ips/hostnames(fqdns) can be used like as follows to allow set of system administrators/weblogic administrators
to access console -

<s_wls_admin_console_access_nodes oa_var="s_wls_admin_console_access_nodes">host1.domain.com,host2.domain.com</s_wls_admin_console_access_nodes>

2. Execute autoconfig on run filesystem.
3. Stop and start Oracle Weblogic admin server
 adadminsrvctl.sh stop
 adadminsrvctl.sh start
4. perform fs_clone to synchronize filesystems
 adop phase=fs_clone




Option 2: Allowing an IP Range

This option will be available after applying  Patch 29781255:R12.TXK.C.
There will be requirements where you need to provide IP range and it is important to
first understandd how CIDR works.

According to CIDR ruling, you can have a factor set to 4^n
This implies we can have ip range as
4,16,64,256

Sample example to narrow down IP range -
195.168.1.32/24 ---> 256  IP Hosts
195.168.1.32/26 --->  64  IP Hosts
195.168.1.32/28 --->  16  IP Hosts
195.168.1.32/30 --->  04  IP Hosts


I first checked for patch if already applied as a standard practice.

Query 1-
set lines 1000
col APPLIED_FILE_SYSTEM_BASE for a40
SELECT b.bug_number, asp.adop_session_id, asp.bug_number patch#,
       asp.session_type, asp.applied_file_system_base,
       asp.start_date, asp.end_date
FROM ad_bugs b, ad_patch_run_bugs prb, ad_patch_runs pr,
     ad_patch_drivers pd, ad_adop_session_patches asp
WHERE b.bug_id = prb.bug_id
  AND prb.patch_run_id = pr.patch_run_id
AND pr.patch_driver_id = pd.patch_driver_id
  AND pr.patch_run_id = asp.patchrun_id
  AND prb.applied_flag = 'Y'
  AND b.bug_number = '&bug_num';
Enter value for bug_num: 29781255
old  11:   AND b.bug_number = '&bug_num'
new  11:   AND b.bug_number = '29781255'

no rows selected

Query 2-
SELECT adb.bug_number,ad_patch.is_patch_applied('122', 1045, adb.bug_number)
FROM ad_bugs adb
WHERE adb.bug_number in (29781255);
Query 3-
select ad_patch.is_patch_applied('R12',-1,29781255) from dual;


Once patch was applied, we update CONTEXT file on run fs as follows -

cat $CONTEXT_FILE | grep wls | grep nodes
<s_wls_admin_console_access_nodes oa_var="s_wls_admin_console_access_nodes">195.168.1.32/30</s_wls_admin_console_access_nodes>

This can me below set of 4 ips -
195.168.1.32-to-195.168.1.35

Note: Easy way to calculate range of Ips is using online calculator -
https://www.ipaddressguide.com/cidr

Executed autoconfig and started admin server to reflect changes.



Option 3: Adding Specific Trusted Hosts

SSH tunneling is pre-requisite here and I achieved it using putty.
For lab environment using static ips, this can be simply achieved using below -
1. Ssh -> Logging
Provide Destination IP address and keep port for ssh as 22.

Save it with some name to it can be loaded later for future reference.

2. Connection -> SSH -> Tunnels
Provide Source port, client machine's port which is open and not blocked or used by any other application.
In my case it was 81.

Provide Destination Hostname:Port and click on 'Add'

3. Go back to session and save it.

4. If you are not intending to logon to server, you can use option under 'Ssh' -

5. Login to saved session and monitor Event log for putty Session -

5. Few more settings are required on your web-browser, I used Firefox here -





127.0.0.1 is for Localhost.

Clear browser cache and try console again -


No comments:

Post a Comment