VCN Security List Allows Traffic to Restricted Ports – Alert Explanation and Remediation

 

An alert is generated in cloud guard when a Virtual Cloud Network (VCN) security list permits inbound traffic on ports classified as restricted. These ports are defined in the detector’s Restricted Protocol: Ports List within the input settings. Allowing such ports through ingress rules increases the attack surface and may expose workloads to unnecessary security risks.

This alert is raised to ensure that network access remains aligned with Oracle Cloud Infrastructure security best practices.

---

Impact

If restricted ports are allowed in VCN security list ingress rules, unauthorized or unintended access paths may be introduced. This can lead to compliance violations, increased vulnerability to network-based attacks, and deviation from established security baselines.

---

Recommended Resolution

Ensure that all VCN security lists do not allow any ports defined in the Restricted Protocol: Ports List through ingress (inbound) rules.

Specifically:

• Review all security list ingress rules.

• Remove or restrict any ports identified as restricted by the detector rule.

• Validate that only explicitly required ports are permitted.

---

Steps to Update the Detector Rule

1. Sign in to the OCI Console.

2. Navigate to:
   Oracle Cloud Guard → Detector Recipes

3. Open the relevant Detector Recipe.

4. Select Detector Rules.

5. Locate the rule “VCN Security List Allows Traffic to Restricted Port.”

6. Edit the rule and remove port 111 from the Input Settings.

7. Save and apply the changes.

---

Best Practices for Rule Customization

• Controlled Configuration:
  Update the Restricted Protocol: Ports List only when there is a validated business or technical requirement.

• Flexible Input Options:
  Restricted ports can be specified in two ways:

  • Manually entering individual port numbers or port ranges.

  • Referencing one or more predefined security lists by name.

• Periodic Review:
  Regularly review detector rules and security list configurations to ensure continued alignment with organizational security standards.

---

Conclusion

Proactively managing restricted ports within VCN security lists is essential to maintaining a secure OCI networking posture. By refining detector rule input settings and enforcing strict ingress controls, organizations can significantly reduce exposure to unnecessary network risks while remaining compliant with OCI security best practices.

Beyond Allow Policies: How OCI IAM Deny Policies Enhance Access Control and Risk Management

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) traditionally follows an implicit deny model, where access is denied unless explicitly allowed. While this approach is effective, modern cloud governance often requires explicit guardrails to prevent sensitive actions—even when broad permissions exist. To address this need, OCI introduced IAM Deny Policies, enabling administrators to explicitly block specific actions and enforce stronger security controls.

---

What Are IAM Deny Policies?

IAM deny policies allow organizations to explicitly prohibit actions, overriding any existing allow policies. If a deny policy matches a request, the action is blocked regardless of other permissions. This capability is particularly valuable for enforcing governance standards, regulatory compliance, and operational safety in critical environments.

Deny policies are especially useful in large tenancies with multiple teams, compartments, and environments where broad access is necessary but unrestricted permissions could lead to accidental or unauthorized changes.

---

Key Characteristics

Explicit Opt-In

Deny policies are disabled by default and must be explicitly enabled by a tenancy administrator. Once enabled, the feature cannot be disabled, highlighting the need for careful planning before activation.

Administrator Protection

To prevent accidental lockouts, the default Administrators group in the default identity domain is exempt from deny policies. This ensures that core administrative access remains available even if restrictive deny rules are configured.

Policy Evaluation Order

During policy evaluation, deny policies take precedence over allow policies. If both apply to the same request, the deny rule always wins.

---

Policy Syntax Overview

Deny policies use the same structure as standard IAM policies, replacing allow with deny. This consistency makes them easy to understand and manage.

Example:

deny group DevTeam to manage bucket-family in compartment Prod
where request.operation = 'DeleteBucket'

This statement prevents the DevTeam group from deleting buckets in the production compartment, even if they have broader storage permissions.

---

Common Use Cases

Protecting Production Environments

Deny policies are ideal for preventing destructive actions such as deleting VCNs, databases, or object storage in production compartments.

Enforcing Separation of Duties

Organizations can restrict sensitive operations to specific teams by explicitly denying them to others, reinforcing clear responsibility boundaries.

---

Best Practices

• Enable deny policies only after governance review and testing.

• Keep deny statements narrow and condition-based to avoid unintended impact.

• Regularly review deny policies as environments and teams evolve.

• Document deny policies clearly to support audits and operational transparency.

---

Conclusion

OCI IAM Deny Policies add a powerful layer of control to cloud access management. When used thoughtfully, they help organizations protect critical resources, reduce operational risk, and enforce governance without sacrificing flexibility. As OCI environments grow in scale and complexity, deny policies become an essential tool for secure and disciplined cloud operations.

Creating Online-Patching-Compliant Table in Oracle E-Business Suite R12.2

Online patching introduced in Oracle E-Business Suite R12.2 fundamentally changed the way custom objects must be created and maintained. To ensure zero-downtime patching, every custom table must support Edition-Based Redefinition (EBR). This requires a base table, an editioning view, and an APPS synonym—created in a specific sequence using Oracle’s AD_ZD utilities.

This article provides a clear, step-by-step guide to creating an online-patching-compliant table along with its editioning view (EV) in R12.2. It also outlines how to manage future structural changes through XDF metadata or AD_ZD utilities.

---

1. Create the Base Table in the Owning Schema

Begin in the Run edition, logged in as the appropriate product schema (for example, APPLSYS or a custom application schema).
At this stage, only the base database objects are created.

Typical actions include:

• Creating the table using standard DDL.

• Defining supporting indexes.

• Using APPS_TS_* tablespaces depending on the object type.

• Preferring unique indexes instead of primary key constraints, in line with R12.2 object standards.

At this point, no editioning view exists. The table is still non-compliant with online patching.

---

2. Upgrade the Table to Create the Editioning View and APPS Synonym

Once the base table is ready, convert it into an online-patching-aware object using Oracle’s AD_ZD package:

EXEC AD_ZD_TABLE.UPGRADE('<OWNER_SCHEMA>', '<TABLE_NAME>');

This action generates two critical components:

• Editioning View (EV):
  Created in the owning schema with the name <TABLE_NAME>#.
  This view becomes the layer through which the application interacts with the table.

• APPS Synonym:
  A synonym named <TABLE_NAME> is created in the APPS schema, pointing to the EV.

From this point forward, all application components—Forms, OAF, PL/SQL APIs, reports—must reference the APPS synonym. This ensures that future table changes are transparently managed through the EV without breaking online patching rules.

---

3. Generate and Deploy the XDF Metadata

To package this custom table for deployment across environments, Oracle requires an XDF (XML Definition File) representation.

Steps:

1. Insert at least one row into the new table (mandatory for XDF generation).

2. Run xdfgen.pl from the Run edition to produce the .xdf file containing the metadata for the table, indexes, and associated objects.

3. Include this .xdf in your custom application patch.

4. During patch application, xdfcmp.pl automatically creates the base table and invokes AD_ZD_TABLE.UPGRADE, ensuring that the EV and APPS synonym are generated in all target instances.

This makes your object fully compliant with the R12.2 adoption and deployment model.

---

4. Managing Future Structural Changes

When enhancements or structural modifications are required—such as adding new columns—you must preserve online patching compliance.

Two methods are supported:

a. Preferred Method: Update via XDF

Modify the XDF file and apply it using xdfcmp.pl.
This ensures consistent behavior across environments and adheres to Oracle's standards.

b. Direct DDL in Development

If a table is altered manually in a development instance:

EXEC AD_ZD_TABLE.PATCH('<OWNER_SCHEMA>', '<TABLE_NAME>');

This regenerates the EV mapping to align it with the updated table structure.

---

Conclusion

Building online-patching-compliant objects is essential for long-term maintainability in Oracle E-Business Suite R12.2. By creating the base table, generating the editioning view through AD_ZD utilities, and managing future changes via XDF or AD_ZD_TABLE.PATCH, you ensure seamless behavior during both Run and Patch editions.

Understanding Oracle Unified Auditing: Quick Checks for DBAs

Oracle Unified Auditing consolidates all audit records into a single, unified framework, simplifying how auditing is configured, managed, and reviewed. As more environments move toward stricter compliance and security standards, DBAs increasingly rely on Unified Auditing to track database activity efficiently.

This short guide highlights how to quickly check whether Unified Auditing is enabled and how to review the audit policies configured in your database.

---

✅ How to Check if Unified Auditing Is Enabled

Unified Auditing can run in two modes:

• Mixed Mode (default)

• Pure Unified Auditing Mode

To verify the status, check the database options:

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

• TRUE → Unified Auditing is enabled

• FALSE → Unified Auditing is disabled

If the database is running in pure mode, it was enabled during installation or via relinking.

---

View Enabled Unified Audit Policies

To see which audit policies are currently active:

SELECT DISTINCT policy_name 
FROM audit_unified_enabled_policies;

This lists all enabled policies, including Oracle-supplied and user-defined ones.

---

View All Available Unified Audit Policies

To list every policy defined in the system:

SELECT DISTINCT policy_name 
FROM audit_unified_policies;

This helps you understand what policies exist, even if they’re not currently enabled.

---

Check Audit Options Associated with Each Policy

To see which audit options belong to each policy:

SELECT audit_option, policy_name 
FROM audit_unified_policies 
GROUP BY policy_name, audit_option;

This provides insight into what actions are being audited under each policy.

---

Summary

Oracle Unified Auditing centralizes and simplifies auditing. With just a few queries, DBAs can quickly validate:

• Whether Unified Auditing is active

• Which policies are enabled

• What audit actions are tied to each policy

These checks are essential for maintaining security, ensuring compliance, and understanding the audit footprint of your Oracle environment.

Validating an Oracle TDE Wallet Password Safely with mkstore

When managing Oracle Transparent Data Encryption (TDE), it’s often necessary to verify whether a wallet password is correct—especially before performing operations such as opening the wallet, rotating keys, or restoring backups. The safest way to do this is by using the mkstore utility outside the database environment, without requiring any database open/close actions.

Below is a simple and secure method to validate your TDE wallet password.

---

Why Use mkstore for Validation?

mkstore allows you to test the wallet password independently of the database.
This approach ensures:

• No impact on the running database

• No wallet state changes

• A direct and reliable password validation method

---

 Steps to Validate a TDE Wallet Password

1. Copy Only the ewallet.p12 File

Copy the wallet file (ewallet.p12) to a temporary directory:

• Do not copy cwallet.sso
  The .sso file enables auto-login, which bypasses the password prompt.
  Excluding it ensures that mkstore must ask for the password.

Example:

cp /path/to/original/ewallet.p12 /tmp/wallet_validation/

---

2. Run the mkstore Command

From the Oracle home bin directory, execute:

mkstore -wrl <wallet_directory> -list

Replace <wallet_directory> with the path to your copied wallet (e.g., /tmp/wallet_validation/).

mkstore will prompt you to enter the wallet password.

---

3. Interpret the Result

• Valid Password:
  The command displays wallet contents (aliases/entries).

• Invalid Password:
  You will see an error indicating that the password is incorrect.

This method confirms the correctness of your TDE wallet password without any risk to the running database or the original wallet.

---

Why Avoid Copying cwallet.sso?

cwallet.sso enables auto-login mode.
If present, the wallet opens automatically and no password check occurs, defeating the purpose of validation.
By copying only ewallet.p12, you ensure that mkstore enforces password authentication.

---

Example Commands

cp /u01/app/oracle/admin/db_wallet/ewallet.p12 /tmp/wallet_validation/
mkstore -wrl /tmp/wallet_validation/ -list

---

🟩 Summary

Validating a TDE wallet password using mkstore is:

• Safe

• Non-intrusive

• Independent of database state

• Ideal before sensitive operations like wallet open, key changes, or backup restores

This simple check can help prevent downtime and errors related to incorrect wallet passwords.

Edition-Based Redefinition (EBR) in Action: Resolving Synonym Translation Errors

While working with Oracle Applications schemas, you may encounter the error ORA-00980: synonym translation is no longer valid when accessing editioning views or objects through a synonym. This article explains a practical example of how this issue arises and how to resolve it.

---

Scenario

A user TEST tried to access the APPS schema object FND_USER_RESP_GROUPS_DIRECT using a synonym.

SQL> SHOW USER
USER is "TEST"

The user then connected and created a synonym for the editioning view:

SQL> CONN test/***
Connected.

SQL> CREATE OR REPLACE SYNONYM "FND_USER_RESP_GROUPS_DIRECT" FOR APPS.FND_USER_RESP_GROUPS_DIRECT;

Synonym created.

However, when querying the synonym, the following error occurred:

SQL> SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT;
SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT
                     *
ERROR at line 1:
ORA-00980: synonym translation is no longer valid

---

Root Cause

This issue happens because the TEST user is not edition-enabled, while the target object in the APPS schema is an editioning view.
Edition-based redefinition (EBR) in Oracle allows for multiple versions of application objects (like packages and views) across different editions.
When a non-editioned user tries to access editioned objects, Oracle cannot resolve the synonym, leading to this error.

To verify the editioning status of the user:

SQL> SELECT EDITIONS_ENABLED FROM DBA_USERS WHERE USERNAME='TEST';

E
-
N

The result N indicates the user is not edition-enabled.

---

Resolution

Enable editions for the user to allow access to editioned objects:

SQL> ALTER USER test ENABLE EDITIONS;

User altered.

Confirm the change:

SQL> SELECT EDITIONS_ENABLED FROM DBA_USERS WHERE USERNAME='TEST';

E
-
Y

Reconnect as the user and retry the query:

SQL> CONN test/***
Connected.

SQL> SELECT COUNT(1) FROM FND_USER_RESP_GROUPS_DIRECT;

  COUNT(1)
----------
     18916

The query now executes successfully.

---

Key Takeaway

When creating synonyms for editioning views in Oracle E-Business Suite or any EBR-enabled schema, ensure that the referencing user has editioning enabled.
Otherwise, Oracle will fail to translate the synonym, resulting in the ORA-00980 error.

Oracle AI Database 26ai – What It Means for Oracle E-Business Suite

At Oracle AI World 2025 in Las Vegas, Larry Ellison announced the launch of Oracle AI Database 26ai (26ai) — the next evolution of Oracle Database, bringing AI-driven capabilities into the core database engine. This announcement marks a key milestone for both the Oracle Database and Oracle E-Business Suite (EBS) communities.

---

🔑 Key Highlights from the Announcement

• New Naming Convention: Oracle Database is now officially referred to as the Oracle AI Database.

• 26ai Replaces 23ai: Oracle AI Database 26ai supersedes Oracle Database 23ai, becoming the latest long-term release.

• No Architectural Changes: DB 26ai builds on 23ai with no changes to the internal architecture or APIs.

• Smooth Transition:

  • If you’re on Oracle Database 23ai, simply apply the October 2025 Database Release Update (DBRU).

  • If you’re on 19c or earlier, a standard upgrade is required to move to 26ai.

• Updated Documentation: Oracle’s database documentation and release materials now reference DB 26ai instead of DB 23ai.

• New Release Numbering: Oracle has updated its database release numbering with the introduction of 26ai.

For detailed platform availability, refer to:
📘 Release Schedule of Current Database Releases (Doc ID 742060.1)

---

💡 Impact on Oracle E-Business Suite

For Oracle E-Business Suite (EBS) customers:

• All EBS documentation will be updated to replace mentions of “Oracle Database 23ai” with “Oracle AI Database 26ai.”

• During this transition, you may see references to both names in parallel, but once updates are complete, only Oracle AI Database 26ai will appear across official documentation.

---

Oracle AI Database 26ai represents the next step in integrating AI-driven performance, automation, and insight into Oracle’s enterprise database platform—ensuring that EBS customers can continue to innovate with a future-ready, AI-enhanced foundation.

---