Setting Up a DMZ in Oracle E-Business Suite

What is a DMZ and Why Does EBS Need One?

A DMZ (Demilitarized Zone) is a secure buffer network positioned between the public internet and your internal corporate network. In Oracle E-Business Suite (EBS), implementing a DMZ allows you to safely expose selected web-facing services—such as iProcurement or supplier portals—to external users, without granting them direct access to your internal application or database servers.

Without a DMZ, enabling external access would require exposing the entire EBS environment to the internet, which significantly increases security risks. By introducing a DMZ:

• External users connect only to the web tier hosted in the DMZ, not to internal application servers.
• Critical components such as the database and concurrent managers remain securely protected behind internal firewalls.
• Even if the DMZ layer is compromised, the internal network and core systems remain isolated and secure.

Architecture Overview

The three-tier DMZ layout for Oracle EBS R12.2 looks like this:

 

Internet / External Users

→

DMZ Node (Web Tier)

→

Internal App + DB Tier

 

In this guide, the example nodes are:

•        Primary Apps Node: appsserver.test.com

•        DMZ Apps Node:     dmzserver.test.com

Prerequisites

Note :- Complete all three prerequisites on every node before starting the setup steps below. Skipping any of these is a common source of errors during cloning.

1.  Add host entries in all three /etc/hosts files — on the Primary DB node, Primary App node, and the DMZ node — so each node can resolve the others by hostname.

2.  Ensure the APPS and Oracle OS user and group IDs are identical across all nodes. Mismatched IDs cause permission errors when copying file systems.

3.  Enable password less SSH between the application tier nodes.

Step-by-Step Setup

STEP 1    Clean Up and Sync the File System (adop cycle)

Start on the Primary Apps Node. Run a complete adop cleanup cycle to ensure both file systems are in a consistent, clean state before cloning anything across to the DMZ.

$ . /u01/R12_2/APPFS/EBSapps.env run $ adop phase=prepare $ adop phase=finalize $ adop phase=cleanup cleanup_mode=full $ adop phase=fs_clone

 

Note :- Do not skip this step. A dirty or inconsistent file system is the most common reason adcfgclone fails during DMZ setup.

STEP 2    Switch Profile Hierarchy Type to SERVRESP

 

DMZ configuration in EBS R12.2 requires profile options to be managed at the Server-Response (SERVRESP) level. This allows different profile values — like different URLs — to be set per node, which is essential for routing internal vs. external traffic correctly.

 

Run the following SQL script on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env run $ sqlplus apps/'apps_password' \   @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP

You will see confirmation messages for each profile option being updated, for example:

Profile APPS_WEB_AGENT hierarchy type changed to SERVRESP Profile APPS_FRAMEWORK_AGENT hierarchy type changed to SERVRESP Profile APPS_SERVLET_AGENT hierarchy type changed to SERVRESP Profile ICX_FORMS_LAUNCHER hierarchy type changed to SERVRESP

 

STEP 3    Run Preclone on Both File Systems

 

Run adpreclone.pl on both the run and patch file systems on the Primary Apps Node. This prepares the file system metadata for cloning.

Run File System:

$ . /u01/R12_2/APPFS/EBSapps.env run $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 Patch File System:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ cd $ADMIN_SCRIPTS_HOME $ perl adpreclone.pl appsTier

 

STEP 4    Back Up the Run File System and Copy It to the DMZ Node

 

Create a compressed archive of the run file system on the Primary App Node, then transfer it to the DMZ server using scp.

 On the Primary Node — create and copy the backup:

$ cd /u01/R12_2/APPFS/fs1 $ tar -cvzf appnode1backup.tar.gz EBSapps/ $ scp appsbackup.tar.gz \   applmgr@dmzserver.test.com:/u01/R12_2/APPFS/fs1

 On the DMZ Node — extract the backup:

$ cd /u01/R12_2/APPFS/fs1/ $ tar -xvf appsbackup.tar.gz

STEP 5    Run adcfgclone on the DMZ Node to Register It as a New Node

 

This is the core configuration step. First, start the Patch FS Admin Server on the Primary Node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

 Then, on the DMZ Node, run adcfgclone:

$ cd /u01/R12_2/APPFS/fs1/EBSapps/comn/clone/bin $ perl adcfgclone.pl appsTier dualfs

 

When prompted, respond as follows:

•        Enter APPS password and WebLogic AdminServer password when asked.

•        Answer yes to 'Do you want to add a node?'

•        Confirm the hostname as: dmzserver

•        Accept default paths for all file system directories.

•        Keep same port values as the source system: y

•        When asked to start application services: answer n (do not start yet)

 

Note :- adcfgclone script will display all target directory paths for confirmation before proceeding. Verify the DMZ hostname and paths are correct before continuing.

STEP 6    Stop Primary Patch Admin Server, Run AutoConfig, and Start Services

 

On the Primary Node — stop the patch FS admin server:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $INST_TOP/admin/scripts/adadminsrvctl.sh stop

 On the DMZ Node — sync context file, run AutoConfig, start services:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh $ sh adstrtal.sh apps/apps

 Upload the patch context file from DMZ node:

$ . /u01/R12_2/APPFS/EBSapps.env patch $ $ADJVAPRG oracle.apps.ad.autoconfig.oam.CtxSynchronizer \    action=upload contextfile=$CONTEXT_FILE \   logfile=/tmp/patchctxupload.log

 On the Primary Node — sync context and run AutoConfig:

$ . /u01/R12_2/APPFS/EBSapps.env run $ perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh

 

Finally, bounce the services on the Primary Node to complete the configuration sync.

STEP 7    Set Profile Options to Mark the DMZ Node as External

 

Log in to EBS using the internal URL as SYSADMIN. Navigate to System Administrator > Profile > System.

Node Trust Level:

Query for the profile option Node Trust Level. At the server level, set it to External for the DMZ server (dmzserver.test.com). Leave the site-level value as Normal.

 Responsibility Trust Level:

For each responsibility you want to expose externally, set the Responsibility Trust Level profile option to External at the responsibility level. Common externally accessible responsibilities include:

 

Product	Responsibility	Additional Profile
iSupplier Portal	iSupplier Portal	POS: External URL, POS: Internal URL
Oracle Sourcing	Sourcing Supplier	PON: External Applications Framework Agent
Oracle iProcurement	Self Registered Employee Default Responsibility	ICX_FORMS_LAUNCHER

 

Note:- Only expose responsibilities that are explicitly needed for external access. Exposing unnecessary responsibilities increases your attack surface.

Managing Services Across All Nodes

Once the DMZ is configured, use these commands from the Primary Node to manage services on all nodes simultaneously:

Start all nodes (including DMZ):

$ sh adstrtal.sh apps/apps_password -mode=allnodes

Stop all nodes:

$ sh adstpall.sh apps/apps_password -mode=allnodes

Firewall Ports to Open

Ensure the following ports are open between your DMZ and internal network zones:

Port	Protocol	Purpose
1571	TCP	Oracle DB listener (DMZ to DB tier)
22	TCP	SSH between app tier nodes
7051 / 7052	TCP	WebLogic Admin Server (HTTP/HTTPS)
8001 / 4443	TCP	OHS Web Entry Point (HTTP/HTTPS)
6701 / 6702	TCP	WebLogic Node Manager

Summary

You have now configured a DMZ for Oracle EBS R12.2. The DMZ node acts as a secure external web entry point. Your internal application and database tiers remain safely behind the firewall. External users access only the responsibilities you have explicitly marked as External via the Node Trust Level and Responsibility Trust Level profile options.

 

Key reference documents:

•        MOS KA1036 — Oracle E-Business Suite R12 Configuration in a DMZ

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=11172164

•        MOS KB503850 — External Access URLs Redirecting to Internal Servers

https://support.oracle.com/ic/builder/rt/customer_portal/live/webApps/customer-portal/?kmContentId=2135366

Caution: Your use of any information or materials on this Blog is entirely at your own risk. It is provided for educational purposes only.