Use Cloud Control to View Database Users and Roles

Oracle Enterprise Manager Cloud Control provides a modern web-based interface for viewing and administering database security information. In older Oracle Enterprise Manager environments, DBAs used a tool known as Security Manager to inspect users, roles, privileges, and related database security objects. That older interface is now legacy. In a modern Oracle Database administration workflow, the equivalent security review is performed through the Cloud Control security management interface.

The purpose of this lesson is to explain how a DBA uses Cloud Control to view information about database users and roles. The lesson focuses on modern Oracle Enterprise Manager usage rather than the deprecated Security Manager simulation that appeared in older course material. The goal is not to memorize a legacy screen sequence. The goal is to understand how users, roles, profiles, privileges, and account status fit into modern Oracle Database security administration.

Enterprise Manager 24ai is the management platform. Oracle Database 23ai is a managed database target. When the database target is discovered and available in Cloud Control, a DBA can inspect security-related information from the console and then validate important findings with SQL data dictionary views when needed.

From Security Manager to Cloud Control

The older Security Manager interface was designed around a simpler graphical administration model. It allowed DBAs to create users, grant privileges, grant roles, and inspect role definitions. For its time, that was useful because it placed common security administration tasks inside a graphical tool.

Modern Oracle security administration is broader. A DBA may need to review users across many databases, understand role grants, inspect administrative privileges, evaluate account status, enforce password profile rules, support least privilege, and interpret security configuration in multitenant environments. A single legacy screen is not enough for that responsibility.

Cloud Control provides a centralized interface for managing database targets and reviewing security metadata. It does not eliminate the need for SQL, SQLcl, SQL*Plus, auditing, or data dictionary views. Instead, it gives the DBA a visual management layer that can expose users, roles, profiles, privileges, account status, and related security information in a structured way.

What the Security Management Interface Shows

The Cloud Control security management interface helps the DBA inspect the security state of a database target. Depending on version, privileges, target type, licensing, and configuration, the interface may provide access to pages for users, roles, profiles, privileges, administrative users, and related security settings.

At a practical level, the DBA is usually trying to answer questions such as:

• Which database users exist?
• Which accounts are open, locked, expired, or expired and locked?
• Which users have high-privilege roles?
• Which roles exist in the database?
• Which users have been granted a specific role?
• Which system privileges are granted directly to a user or role?
• Which object privileges are granted on tables, views, procedures, or other schema objects?
• Which profile controls a user's password and resource policy?
• Which accounts should be reviewed for least privilege?

This type of review is part of routine database administration. User and role information is not only relevant when creating a new account. It is also relevant during audits, application onboarding, privilege reviews, compliance checks, troubleshooting, and security hardening.

Database Users

A database user is a security principal inside Oracle Database. A user may represent a human account, an application schema, a service account, an administrative account, or an internally managed account. A user can own schema objects, connect to the database if permitted, and receive privileges or roles.

When viewing users in Cloud Control, the DBA should look beyond the username. Important user information may include account status, default tablespace, temporary tablespace, assigned profile, authentication-related information, direct system privileges, granted roles, and object privileges.

Account status is especially important. An account may be open, locked, expired, or expired and locked. A locked account cannot be used for normal login. An expired account may require a password change before it can be used. These status values help the DBA distinguish active accounts from restricted or inactive accounts.

Users should also be interpreted by purpose. A schema owner account should not always be treated the same way as a human login account. A service account should be reviewed differently from an administrative account. An application schema that owns tables and packages may require object ownership but should not necessarily be used for interactive login. This separation supports a safer security design.

Database Roles

A role is a named collection of privileges. Roles simplify security administration because the DBA can grant a group of privileges to a role and then grant the role to one or more users. Without roles, privilege administration can become repetitive and difficult to audit.

For example, an application reporting role might include SELECT privileges on a set of reporting views. A maintenance role might include privileges required for controlled maintenance tasks. An administrative role might contain powerful privileges and therefore require stricter review.

When viewing roles in Cloud Control, the DBA should inspect more than the role name. Important role information may include:

• users granted the role
• roles granted to the role
• system privileges granted to the role
• object privileges granted to the role
• whether the role is a default role for users
• whether the role is common or local in a multitenant environment
• whether the role contains powerful administrative privileges

Roles are useful, but they must be governed carefully. A role that contains too many privileges can become a hidden security risk. A user may appear harmless until the DBA inspects the roles granted to that user and the privileges inside those roles.

System Privileges and Object Privileges

Oracle security distinguishes between system privileges and object privileges. A system privilege allows a user or role to perform a database-level operation. Examples include the ability to create a session, create tables, create users, alter system settings, or perform other database-wide actions.

An object privilege applies to a specific schema object. Examples include SELECT, INSERT, UPDATE, DELETE, EXECUTE, and REFERENCES on a table, view, procedure, package, or other object. Object privileges are usually more targeted than system privileges.

Cloud Control can help the DBA review how these privileges are assigned. The DBA should pay particular attention to direct grants and role-based grants. A privilege granted directly to a user may be intentional, but it may also indicate a privilege that should be moved into a managed role. A privilege granted through a role may simplify administration, but the role itself must be reviewed for scope and risk.

Profiles and Account Policy

A profile is a database object that can control password-related settings and resource limits. Profiles can affect password lifetime, password reuse, failed login behavior, session limits, and other account-related policies depending on the database configuration.

When viewing user information, the assigned profile is important because it helps explain account behavior. For example, an account may expire because of profile rules. Another account may lock after repeated failed login attempts. A DBA reviewing users in Cloud Control should treat the profile as part of the account's security context.

Profiles are also useful for separating account types. Human users, application schemas, service accounts, and administrative accounts may require different password and resource policies. A single profile for every account may be simple, but it is not always the best security design.

Least Privilege

The principle of least privilege means that a user or role should have only the privileges required to perform its intended function. This principle is central to database security. Excess privileges increase the damage that can occur if an account is misused, compromised, or configured incorrectly.

Cloud Control helps support least privilege by making user and role information easier to review. A DBA can inspect which accounts have powerful roles, which users have direct system privileges, and which roles contain sensitive object privileges.

Common review questions include:

• Does this user need the DBA role?
• Does this application account need direct system privileges?
• Should this privilege be granted through a role instead of directly?
• Does this role contain privileges from multiple unrelated applications?
• Is this service account being used interactively?
• Are schema owner accounts being used as login accounts?

These questions move the DBA beyond simple account listing and into security analysis.

Administrative Privileges

Modern Oracle Database uses specialized administrative privileges to separate duties. Instead of treating all administration as one broad authority, Oracle supports privileges such as SYSDBA, SYSOPER, SYSBACKUP, SYSDG, and SYSKM for different administrative responsibilities.

Cloud Control security pages can help the DBA identify accounts and roles that require review. High-privilege accounts should be limited, documented, and monitored. Administrative access should not be granted casually. In production environments, privileged accounts are often subject to additional controls, auditing, change management, and separation of duties.

Unified Auditing and Security Visibility

Unified Auditing is part of the modern Oracle security model. It consolidates audit-related information into a more unified framework than older traditional auditing mechanisms. Although this lesson is focused on viewing users and roles, auditing belongs in the broader security context because it helps DBAs and security teams understand who performed security-relevant actions.

Examples of security-relevant actions include account creation, role grants, privilege grants, failed login attempts, administrative connections, object access, and configuration changes. Cloud Control may provide visibility into some audit-related and compliance-related information depending on configuration, privileges, and licensing.

The important lesson is that user and role review should not be isolated from auditing. If a user has powerful privileges, the organization should also consider how usage of those privileges is monitored.

Multitenant Security Considerations

Oracle Database 23ai uses the multitenant architecture. In a multitenant environment, the DBA must understand the difference between CDB-level and PDB-level security context. A common user can exist across containers, while a local user exists within a specific pluggable database. Common roles and local roles must also be interpreted carefully.

This matters when reviewing users and roles in Cloud Control. The DBA should know whether the selected target represents a CDB, a PDB, or another database target type. A privilege that appears at the CDB level may have a different scope than a privilege inside a single PDB. A local application user in one PDB should not be confused with a common administrative user across the container database.

When performing security review, always ask: "Which container context am I viewing?" That question is essential for accurate interpretation of users, roles, and privileges.

Requirements Before Viewing Users and Roles

Several requirements must be satisfied before Cloud Control can be used effectively for security review.

1. Enterprise Manager must be available.
   Use Enterprise Manager 24ai where available. Some organizations may still operate patched Enterprise Manager 13c Release 5 environments, but modern course material should describe the current Cloud Control direction.
2. The database target must be discovered.
   The Oracle database must be discovered and promoted as a managed target before its security information can be viewed in Cloud Control.
3. The Management Agent or supported Remote Agent must be functioning.
   Agent communication is required for target status and configuration information. If agent communication is broken, security pages may be unavailable or incomplete.
4. The user must have appropriate Enterprise Manager privileges.
   Viewing users and roles requires target access. Creating users, modifying accounts, granting roles, revoking privileges, or changing profiles requires stronger privileges.
5. Licensing and product boundaries must be respected.
   Basic user and role visibility is different from advanced security products, advanced compliance features, or separately licensed options.

How to View Users in Cloud Control

The exact menu path may vary by Enterprise Manager release, target type, and configuration. However, the conceptual workflow is consistent.

A common conceptual path is:

Targets > Databases > [database target] > Security > Users

From this area, the DBA can review users and drill into details for a specific account. The purpose is not merely to confirm that a username exists. The purpose is to understand the account's security state.

How to View Roles in Cloud Control

Viewing roles follows a similar workflow. The DBA selects the database target, opens the security or administration area, and navigates to the role management page.

A common conceptual path is:

Targets > Databases > [database target] > Security > Roles

From the roles page, the DBA can review role names and drill into role definitions. A role definition may include system privileges, object privileges, nested roles, and users granted the role. High-privilege roles such as DBA or custom administrative roles should receive special attention.

When reviewing roles, the DBA should ask whether the role is clear, limited, and aligned with a job function or application function. A role with unrelated privileges may be difficult to audit and may violate least privilege.

Validation with Data Dictionary Views

Cloud Control is useful for visual review, but SQL remains essential for validation, scripting, and deeper investigation. A DBA may confirm Cloud Control findings by querying data dictionary views.

Useful views include:

• DBA_USERS - database users and account status.
• DBA_ROLES - database roles.
• DBA_ROLE_PRIVS - roles granted to users or roles.
• DBA_SYS_PRIVS - system privileges granted to users or roles.
• DBA_TAB_PRIVS - object privileges.
• DBA_PROFILES - profile settings.
• CDB_USERS - users across containers in a multitenant database.
• CDB_ROLE_PRIVS - role grants across containers.
• CDB_SYS_PRIVS - system privileges across containers.
• CDB_TAB_PRIVS - object privileges across containers.

Cloud Control gives the DBA a management interface. Data dictionary views give the DBA a precise queryable source for verification and reporting. A strong DBA should be comfortable using both.

Administrative Actions and Caution

Cloud Control may allow authorized DBAs to perform security management actions. These actions can include creating users, modifying users, locking or unlocking accounts, expiring passwords, assigning profiles, granting roles, revoking roles, granting privileges, revoking privileges, and creating or modifying roles.

These actions must be handled carefully. Viewing users and roles is a review activity. Changing users, roles, or privileges is a security administration activity. A privilege change can affect application behavior, compliance posture, audit findings, and separation of duties.

Before modifying security settings, the DBA should understand the reason for the change, the affected application or user, the approval process, and the rollback plan. In many organizations, privilege changes require formal change control or security approval.

Example Security Review

As a simple example, suppose a DBA opens the users page for an Oracle Database 23ai target and notices several accounts with open status and powerful roles. The DBA should not immediately revoke privileges without investigation. Instead, the DBA should identify the account purpose, review role grants, check whether the account is a human user, service account, or schema owner, and validate the grants with data dictionary views.

If an account has the DBA role unnecessarily, that condition should be reviewed. If a service account has interactive login access, that may also require review. If a schema owner is used directly by application users, the security design may need improvement. Cloud Control helps the DBA identify these conditions so they can be evaluated properly.

Summary

The Cloud Control security management interface provides a modern way to view database users, roles, privileges, profiles, and account status. It replaces the old Security Manager training model with a centralized web-based workflow suitable for modern Oracle Database administration.

The key lesson is that user and role review is not simply a navigation exercise. A DBA must interpret account status, privilege grants, role design, profile assignment, administrative access, and multitenant context. Enterprise Manager 24ai provides a management layer for that review, while SQL data dictionary views provide validation and deeper investigation.

Used correctly, Cloud Control helps the DBA support least privilege, account lifecycle management, role-based access control, and security visibility across Oracle Database 23ai environments.

Module Functionality - Quiz