Oracle Access Manager High Availability Training Class

Oracle Access Manager 11g R2: Advanced Administration 3 - 2

High Availability (HA) Goals

Oracle Access Manager controls access to enterprise resources. If Oracle Access Manager

goes down, enterprise users have no access to business applications. Therefore, Oracle

Access Manager is a critical infrastructure component that must be always available under

most circumstances.

One of the primary goals of HA deployments is to minimize down time. Depending on the

amount of permissible down time, different strategies for providing HA are employed. For

example, in some organizations, it might be acceptable for Oracle Access Manager to be

down one day every three months, while in other organizations, it might be acceptable for

Oracle Access Manager to be down only five minutes per year.

User session continuity is another common goal of HA deployments. Without user session

continuity, if the server to which a user authenticated goes down, the user's session no

longer exists, and the user is required to re-authenticate in order to access resources

protected by Oracle Access Manager. With user session continuity, sessions can survive

the failure of an Oracle Access Manager server. If the Oracle Access Manager server fails,

users can continue to use resources protected by Oracle Access Manager without re-

authenticating.


High Availability (HA) Goals (continued)

Data loss or corruption might occur if, for example, a hard drive fails. Deploying redundant

servers can protect a deployment from data loss. Backup and recovery procedures can help

you restore operations to their full capacity.

Finally, the entire data center might fail due to a catastrophic event. For mission-critical

deployments, strategies such as data streaming and standby hardware can be used to bring a

deployment back into operation quickly.

The scope of this lesson is to describe techniques you use to provide HA for Oracle Access

Manager deployments. But keep in mind that planning for HA is rarely limited to providing HA

for Oracle Access Manager alone; rather, for an entire ecosystem in which Oracle Access

Manager is a part.


Potential Points of Failure in an Oracle Access Manager Deployment

The term single point of failure describes a deployment node which, if it fails, renders an

entire deployment unavailable.

The slide identifies single points of failure in an Oracle Access Manager deployment.

Subsequent slides describe strategies to mitigate single points of failure.

Web Tier

A deployment's Web tier consists of agents: 10g WebGates, 11g WebGates, and OHS instances running the mod_osso module. These agents serve as policy decision points for

Oracle Access Manager.

An agent can be a single point of failure for an Oracle Access Manager deployment.

Assume the following conditions are true:

A user requests a resource protected by an agent.

There is only a single agent deployed in an Oracle Access Manager deployment.

The host on which the agent is deployed is down, or the process running OHS is down.

In this scenario, the user's request fails.


Potential Points of Failure in an Oracle Access Manager Deployment (continued)

Application Tier

The WebLogic managed server instance running the Oracle Access Manager application

resides on the application tier, serving as a policy decision point.

A WebLogic managed server instance can be a single point of failure for an Oracle Access

Manager deployment. Assume the following conditions are true:


The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port.

The host on which the server is deployed is down, or the process running the WebLogic managed server instance is down.


Data Tier

Back-end databases accessed by Oracle Access Manager serverthe audit database, policy database, session database, and identity storecomprise the data tier.

A database on the data tier can be a single point of failure for an Oracle Access Manager

deployment. Assume the following conditions are true:


The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port.

Oracle Access Manager server receives the request, and attempts to retrieve the policy that defines the authentication scheme for the resource.

The policy databases host is down, or the process running the database is down.


Other Considerations

Availability of resources served by Web servers and application serversthe resources that Oracle Access Manager protectscan also be single points of failure for a resource request. Providing high availability for resources served by Web servers and application servers is

beyond the scope of this course.


Load Balancing on the Web Tier

To protect against failure of a server running an agent, deploy redundant agents on the Web

tier, and deploy a load balancer to forward requests to the agent. The agents must be of the

same type. For example, you could not have 10g and 11g WebGates deployed behind the

same load balancer.

You can use a hardware or software load balancer in this deployment.

Hardware load balancersfor example, Cisco Local Director or F5 Networks BIG-IPprovide speed, high reliability, and advanced features.

Software load balancersfor example, the reverse proxy plug-in for Oracle HTTP Serverare less expensive and suitable under certain circumstances.

By placing a load balancer in front of redundant agents, the load balancer can detect

whether the agent is available and, if not, will route requests only to agents that are

available.

Note: The slide shows a deployment with a single load balancer. To eliminate the load

balancer as a single point of failure, deploy redundant load balancers. The slide also shows

two redundant agents. Deploy as many agents as you need to satisfy reliability and

scalability requirements.


Load Balancing on the Web Tier (continued)

The F5 Networks BIG-IP LTM WebGate

The F5 Networks BIG-IP LTM is a hardware load balancer with built-in WebGate support. By

deploying the BIG-IP LTM on the Web tier of an Oracle Access Manager deployment, you can

provide agent redundancy.

Cookie Stickiness

Oracle Access Manager does not require you to configure cookie stickiness on the load

balancer. Requests can be handled on any of the redundant agent instances.

You can configure cookie stickiness to take advantage of other features, such as Web caches.

Sticky cookies are not required by Oracle Access Manager, but are recommended for optimal

performance.

Configuring Multiple Redundant Agents behind a Load Balancer

You can configure multiple redundant agents that reside behind a load balancer without

registering each agent instance. Instead, perform the following steps:

1. Install WebGate software on every instance deployed behind the load balancer.

2. Register a single agent with Oracle Access Manager. If you use the oamreg remote

registration utility, be sure the agent URL in the input file specifies the host name and

port number of the load balancer.

3. Copy the agent artifact files to the WebGate configuration directory on each agent

instance.


Clustering the Oracle Access Manager Server on the Application Tier

To protect against failure of an Oracle Access Manager server running on the application

tier, deploy a cluster of WebLogic managed server instances, each running the OAM server

and other required applications and libraries.

WebLogic clustering ensures that requests are routed to an available instance.

You can configure the front end of the cluster with a load balancer or a Web proxy server

plug-in. The load balancer or Web proxy server can detect whether a server is available,

and if not, will route requests only to servers that are available.

It is not necessary to configure the front end for cookie stickiness. Requests to the Oracle

Access Manager server can be satisfied by any instance running in the cluster.

The deployment of redundant Oracle Access Manager servers across multiple WebLogic

Server clusters or domains is not supported in Oracle Access Manager 11g Release 1.

Note: The slide shows a deployment with two clustered Oracle Access Manager server

instances. You can deploy as many servers as you need to satisfy reliability and scalability

requirements.


WebLogic Server Cluster

An Oracle WebLogic Server cluster consists of multiple Oracle WebLogic Server instances,

running simultaneously and working together to provide increased scalability and reliability.

A cluster appears to clients as one Oracle WebLogic Server instance. The server instances

that constitute a cluster can run on one machine or on different machines. You can increase

a clusters capacity either by adding server instances to the cluster on an existing machine, or by adding machines to the cluster to host the incremental server instances.

Each server instance in a cluster must run the same version of Oracle WebLogic Server.

A cluster is a group of Oracle WebLogic Servers that coordinate with one another to provide

clients access to the services provided by the entire cluster. Each Oracle WebLogic Server

cluster is managed by a single administration server. These services may be a superset of

the services provided by a single Oracle WebLogic Server instance.


WebLogic Server Cluster (continued)

A cluster can exist on one or more computers as long as there are multiple Oracle WebLogic

Server instances that are executing. The cluster provides an encapsulated interface to the

services of the cluster. The cluster appears as a single instance to clients, whether these

clients are Web-based or Java-based. By replicating the services provided on a single Oracle

WebLogic Server instance, an enterprise system achieves a fail-safe environment and a

scalable one.

High availability is achieved through the replication of services so that when one server fails, a

second server can resume operation where the first left off. Scalability is achieved by

balancing the load of incoming requests across the servers in the cluster. If there are four

Oracle WebLogic Server instances in a cluster and four requests enter the cluster, scalability

can be achieved by balancing the four requests evenly across the cluster instances.

A cluster is part of a particular Oracle WebLogic Server domain. All server instances in a

cluster must reside in the same domain; you cannot split a cluster over multiple domains.

Cluster Configuration Guidelines

Observe the following guidelines when configuring WebLogic Server clusters:

A cluster cannot span domains.

All servers in a cluster must also be in the same domain.

All servers within a cluster must be at the same version level.

Clustered servers can be on the same or different machines with the same or different

operating systems.

There can be multiple clusters in a domain.

There can only be a single cluster of Oracle Access Manager servers per domain.


Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple

Hosts

You typically configure a clustered, highly available Oracle Access Manager deployment on

multiple hosts. Use the following procedure to configure Oracle Access Manager in a

clustered configuration on multiple hosts.

Installation and Configuration

Install WebLogic Server on each host. All installations must use the same version of

WebLogic Server software. It is not required that the hosts run the same operating system.

Install Oracle Access Manager on each host.

Then configure Oracle Access Manager on the host on which you want to deploy the

domain's administration server. During the Customize Server and Cluster Configuration

step, identify all the servers and the cluster on which Oracle Access Manager will run.

On the host that runs the administration server, start the node manager and the

administration server.


Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple

Hosts (continued)

Domain Configuration Propagation

Next, propagate the domain configuration from the first host to all other hosts on which

managed server instances participating in the cluster reside.

To propagate the domain configuration, use the pack.sh and unpack.sh utilities. Run the

pack.sh utility on the first host to package the domain configuration, and unpack.sh on

all other hosts to install the domain configuration.

Start node managers on all the hosts to which you are propagating the domain

configuration. Then start the other managed server instances running Oracle Access

Manager by using the command line or the WebLogic console.

Changing the Request Cache Type from the BASIC Type to the COOKIE Type

Next, you can change the cookie request type from the BASIC type to the COOKIE type.

This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should

make this change if your users' browsers enforce small size limits on the length of the URL

string; this option enables you to decrease the URL size.

Use the following WLST command to change the cache request type:

configRequestCacheType(type="COOKIE")

After changing the cache request type, you must restart all the managed server instances in

the WebLogic cluster.

Installing and Configuring the Load Balancer

Next, you place a hardware load balancer, software load balancer, or Web proxy in front of

managed server instances in the WebLogic cluster. The steps you follow depend on the

type of load balancer you choose.

You must configure the Oracle Access Manager server to be aware of the load balancer. In

the console, change the host name and port number in the SSO engine configuration to the

load balancer's host name and port.

After changing the SSO engine host name and port number, you must restart all the

managed server instances in the WebLogic cluster.

Reconfiguring Agents

Agents that previously communicated directly with the Oracle Access Manager server must

be reconfigured to communicate with the load balancer. To reconfigure agents:

Modify the agent configuration parameters to contain the cluster members' hosts and

OAP port numbers. Note that agent HA is based on a primary/secondary failover

model.

Reregister the agent.

Copy the agent artifacts to the agent configuration.

Restart the agent.


Converting a Single OAM Server on a Single Host to a Clustered Configuration

When working in a development environment with a single host, you might want to convert

an environment with a single Oracle Access Manager server to a clustered environment

with multiple managed server instances, each running Oracle Access Manager server.

You use this technique in the practices for this lesson.

Cluster Configuration

Stop the managed server instance running Oracle Access Manager server.

Use the WebLogic administration console to create a cluster and add the managed server

instance running Oracle Access Manager server to the cluster.


Converting a Single OAM Server to a Clustered Configuration (continued)

Application and Data Source Retargeting

Review all applications targeted to the managed server instance in the WebLogic

administration console. Retarget applications and libraries that comprise Oracle Access

Manager server. It is not necessary to retarget administrative applications, such as Oracle

Access Manager administration console.

Next, review JDBC data sources, and retarget any data sources used by Oracle Access

Manager to the cluster.

Cloning New Servers

Clone as many new WebLogic managed server instances as you need, and add them to the

cluster.

Restart all the managed server instances in the cluster.

Changing the Request Cache Type from the BASIC Type to the COOKIE Type

Next, you can change the cookie request type from the BASIC type to the COOKIE type.

This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should

make this change if your users' browsers enforce small size limits on the length of the URL

string. This option enables you to decrease the URL size.

Use the following WLST command to change the cache request type:

configRequestCacheType(type="COOKIE")

After changing the cache request type, you must restart all the managed server instances in

the WebLogic cluster.

Installing and Configuring the Load Balancer

Next, you place a hardware load balancer, software load balancer, or Web proxy in front of

managed server instances in the WebLogic cluster. The steps you follow depend on the

type of load balancer you choose.

You must configure the Oracle Access Manager server to be aware of the load balancer. In

the console, change the host name and port number in the SSO engine configuration to the

load balancer's host name and port.

After changing the SSO engine host name and port number, you must restart all the

managed server instances in the WebLogic cluster.


Converting a Single OAM Server to a Clustered Configuration (continued)

Reconfiguring Agents

Agents that previously communicated directly with the Oracle Access Manager server must

be reconfigured to communicate with the load balancer. To reconfigure agents:

Modify the agent configuration parameters to contain the cluster members' hosts and

OAP port numbers. Note that agent HA is based on a primary/secondary failover

model.

Re-register the agent.

Copy the agent artifacts to the agent configuration.

Restart the agent.


Handling Administration Server Failure in a Cluster of Oracle Access Manager

Instances

If the WebLogic administration server goes down, the managed servers running Oracle

Access Manager server remain active. But the administrative UIsthe Oracle Access Manager console and the WLST commandare no longer available, and you cannot change the WebLogic Server or Oracle Access Manager configuration.

If the domain contains clustered server instances, the load balancing and failover

capabilities supported by the domain configuration remain available, even if the

administration server fails.

You can start a managed server even if the administration server is not running. In this

case, the managed server uses a local copy of the domains configuration files for its starting configuration and then periodically attempts to connect with the administration

server. When it connects, it synchronizes its configuration state with that of the

administration server.


Handling Administration Server Failure in a Cluster of Oracle Access Manager

Instances (continued)

Starting a Standby Administration Server After an Administration Server Failure

The reference architecture provides for a standby administration server on each host running

redundant Oracle Access Manager servers. When you propagate the WebLogic domain to

multiple hosts running clustered managed server instances, a copy of the administration

server is also propagated. The slide shows the presence of two administration servers in the

deployment, with one administration server active and the other administration server

available as a standby.

In normal operation, all the managed server instances run, while only a single administration

server runs. In the event of an administration server failure, one of the standby instances can

be brought up to service requests for configuration changes.


Data Tier

Oracle Access Manager uses the following types of data, which reside on the data tier:

Audit data

Oracle Access Manager policies

Oracle Access Manager sessions

Identity data

For Oracle Access Manager 11g R1, audit data, policies, and sessions are always stored in

an Oracle Database. A typical strategy for Oracle Database HA is Oracle Real Application

Clusters (Oracle RAC).

Refer to the following URL for more information about Oracle Database high availability,

including Oracle RAC: http://www.oracle.com/technetwork/database/features/availability/

index.html.

If you use Oracle Internet Directory for your identity store, then identity data is stored in an

Oracle Database instance. Use Oracle RAC or another Oracle Database HA strategy.

If you use a non-Oracle product for your identity store, refer to your vendor's documentation

for information about making the identity store highly available.


Other Issues to Be Aware of in HA Deployments

When deploying Oracle Access Manager in an HA environment, a number of issuessuch as the issues listed on the slidethat are beyond the scope of this course come into play. Although these issues are not covered in this course, you should be aware of them and be

prepared to handle them, depending on your organization's needs.


Session and Configuration Replication

Oracle Access Manager server uses Oracle Coherence to replicate user sessions and the

Oracle Access Manager configuration.

The eCO Grid

The eCO Grid (embedded Coherence grid) is a high-performance distributed caching

system that enables Oracle Access Manager to propagate creation and modifications to

user sessions across multiple distributed servers. The nature of the distributed cache

system implicitly supports site affinity such that any run-time servers have access to the

same set of sessions when serving access requests that may have bounced through

multiple servers.

Making session stores persistent further empowers eCO Grid. With persistent session

stores, it is possible to recover from mass failures in the security environment and maintain

the same user sessions once the failures are resolved.


Session and Configuration Replication (continued)

Session Replication

Oracle Access Manager user sessions are created on the server on which a user

authenticates. The number of sessions that can be stored concurrently varies, depending on

the following factors:

The amount of memory available for session storage on the host

The size of user sessions

In addition to being stored in-memory on the host, sessions are also written to the Oracle

database when they are created or updated.

When Oracle Access Manager is running in a clustered environment, with multiple servers

running on different hosts, sessions are also replicated to the other hosts on which Oracle

Access Manager servers run.

Therefore, in the clustered environment, there are three possibilities for session retrieval:

Sessions can be retrieved from the same host.

Sessions can be retrieved from another host in the cluster.

If all the Oracle Access Manager servers in a cluster go down, sessions are recovered

from the database as needed after one or more Oracle Access Manager servers are

restarted.

Session Management

Sessions are deleted by Oracle Access Manager as follows:

When a user logs out

When an administrator deletes the session by using the Oracle Access Manager

console

After the session lifetime timeout interval has been exceeded

An asynchronous process periodically purges expired sessions from the in-memory caches

and the database.

Session Cache Size

The Coherence session cache must be sized so that it never runs out of memory. Use the

following property in the oam-config.xml file to specify the maximum cache size:

DeployedComponent/Server/NGAMServer/Profile/Sme/SessionManagers

/ServerSessionManager/DistributedCacheMaxSize

You express the DistributedCacheMaxSize propertys value as a value of type memorySize. For example, 100 MB.

Note: You cannot use the Oracle Access Manager console or the WLST utility to change the DistributedCacheMaxSize propertys value.


Session and Configuration Replication (continued)

Distribution of Configuration Changes

Oracle Access Manager also uses the eCO Grid to distribute changes in the Oracle Access

Manager configuration to multiple hosts running Oracle Access Manager server.

When an administrator changes the Oracle Access Manager configuration, the changes are written to the oam-config.xml file, then pushed through the eCO Grid to all hosts running

Oracle Access Manager server.

Note: Unlike user sessions, the Oracle Access Manager configuration is not written to the

database.

Oracle Coherence Instance Used by the eCO Grid

The eCO Grid uses a separate instance of Oracle Coherence software that is automatically

installed with Oracle Access Manager. The eCO Grid Coherence instance is not the same

Coherence instance that you can optionally install when you install WebLogic Server.


User Session Continuity in a Single Oracle Access Manager Server

Environment

Session replication supports Oracle Access Manager's user session continuity capability.

With user session continuity, when an Oracle Access Manager server fails, it is possible for

the user to continue to access protected applications without re-authenticating to the server.

The slide shows how, in an environment with a single Oracle Access Manager server,

sessions can fail over after a server restart because the eCO Grid stores sessions in a

database as they are created. The eCO Grid can retrieve sessions from the database if it

cannot locate sessions in its memory cache.

If sessions resided only in-memory, they would be lost after a server process or host went

down, forcing users to re-authenticate after a server restart.


User Session Continuity in a Clustered Oracle Access Manager Server

Environment

In an environment with a cluster of Oracle Access Manager servers, sessions can fail over

without a server restart. If a single Oracle Access Manager server remains up and running,

that server can obtain sessions for any user from the eCO Grid.

The eCO Grid might retrieve a user's session from any of the following locations:

The memory cache on the local host

A memory cache on another host

The session store in the database, if retrieval from memory caches fails

Sticky cookies are not required for user session continuity.

The slide shows an environment with two Oracle Access Manager servers. When both

servers were up, three users logged in to Oracle Access Manager. Two users' sessions

were distributed to other hosts in the eCO Grid, and all the sessions were written to the

session store in the database.

After one of the servers failed, two users' sessions continued to be available in the eCO

Grid. The third session, if needed, could be fetched from the session store.


Backing up an Oracle Fusion Middleware Deployment

The slide provides an overview of Oracle Fusion Middleware backup.

Backing up the Oracle Fusion Middleware Environment

It is important to consider your entire Oracle Fusion Middleware environment when

performing backup and recovery. The installations of an Oracle Fusion Middleware

environment are interdependent in that they contain configuration information, applications,

and data that are kept in synchronization. For example, when you perform a configuration

change, information in configuration files is updated. When you deploy an application, you

might deploy it to all managed servers in a domain or cluster.

You should back up your entire Oracle Fusion Middleware environment after installation,

then regularly. If a loss occurs, you can restore your environment to a consistent state.

The backup strategy proposed in the Oracle Fusion Middleware Administrator's Guide is to

perform full backups when the system is downafter installation, upgrading, and patchingand backups of run-time artifacts regularly.


Backing up an Oracle Fusion Middleware Deployment (continued)

Static Files and Directories: Backed up During Full Backups Only

Static files and directories change rarely. The Oracle Fusion Middleware Administrator's

Guide recommends backing up the following files only when the environment is fully shut

down:

The Middleware home directory

The OraInventory directory

The OraInst.loc and oratab files

The beahomelist file

For Windows installations, the following registry nodes:

HKEY_LOCAL_MACHINE\Software\oracle

HKEY_LOCAL_MACHINE\System\ControlSet001\Services

HKEY_LOCAL_MACHINE\System\ControlSet002\Services

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Run-Time Artifacts: Backed up During Full Backups and Regular Backups

Run-time artifacts can change often. The Oracle Fusion Middleware Administrator's Guide

recommends backing up the following files on a regular basis, typically nightly:

Domain directories

Oracle instance homes

Applications artifacts, such as .ear and .war files, that reside outside of the domain

Database artifacts, such as the policy and audit data store

The identity store, which might or might not reside in an Oracle database

When performing the backup of run-time artifacts, do not back up local audit files if your

Oracle Access Manager deployment is configured to write audit records to the database.

Duplicate records might be uploaded to the audit database after a restore.

Backup Utilities

Oracle Fusion Middleware does not provide users with any special backup utilities or tools.

You use tools provided with operating systems or other software:

For file backup, use tools such as the tar utility on Linux and UNIX, and the xcopy

command on Windows.

For database backup, use Oracle Recovery Manager. For more information about Oracle Recovery Manager, refer to the Oracle Database Backup and Recovery User's

Guide.

For registry key backup, use the regedit utility or any other registry backup tool.

For identity store backup, use Oracle Recover Manager for Oracle Internet Directory. If you use a different identity data store, refer to the documentation for the backup

procedure for the identity store.


Recovering Your Environment

The slide provides a list of different types of failures and outages that might occur during

operation of an Oracle Access Manager deployment. The notes provide brief overviews of

the steps you take to recover from the failures and outages.

For complete information about recovery procedures, refer to the Oracle Fusion Middleware

Administrator's Guide.

Recovering a Middleware Home

1. Stop all processes related to the domain, such as the administration server, managed

servers, and node managers.

2. Recover the Middleware from backup.

3. Restart domain processes.


Recovering Your Environment (continued)

Recovering a Domain



2. Recover the domain directory from backup.

3. Restart domain processes.

Recovering Oracle Homes

1. Recover the Oracle home to its original directory from backup.

2. Restart managed servers to which the applications are deployed.

Recovering Instance Homes

Perform the following procedure if the instance home was deleted from the file system:

1. Stop any processes related to the instance.

2. Recover the instance directory from backup.

3. Restart instance processes.

Perform the following procedure if the instance was deregistered from the domain:

1. Recover the instance directory from backup.

2. Register the instance and all of its components with the administration server by using the opmnctl registerinstance command.

Recovering the Administration Server Configuration



2. Restore the domain home backup to a temporary location.

3. Restore the config directory to the DOMAIN_HOME/config directory.

4. Restart the administration server and verify that it is accessible.

5. Restart other domain processes.

Recovering Managed Servers

Procedures for recovering managed servers vary, depending on the failure. Refer to the

Oracle Fusion Middleware Administrator's Guide for managed server recovery scenarios.

Recovering Data in the Data Tier

To recover audit data, policy data, and identity store data for Oracle Internet Directory, use

Oracle Database Recovery Manager. For more information about Oracle Recovery

Manager, refer to the Oracle Database Backup and Recovery User's Guide. For other

identity stores, refer to the documentation for the identity store.


HA Topology Review

The diagram on the slide provides a reference topology for high availability Oracle Access

Manager deployments. While your specific deployment might differ in some areas, the

reference topology is a good starting point for complex Oracle Access Manager

deployments.

Some deployment elements on the slide have been covered earlier in this lesson. For

example:

Redundancy on the Web, application, and data tiers

Usage of load balancers

Other deployment elements on the slide are not in the scope of this lesson but are important

to consider when configuring a high availability deployment. For example:

Placement of firewalls

Port numbers to be opened in firewalls

Redundancy of the directory service


Answer: b


Documents

Oracle Access Manager High Availability Training Class