Configuring a Centrally Managed User- Users and Basic Security
A centrally managed user is considered to be a user in one place, such as Active Directory or another LDAP service. The user can be managed for authentication and authorizations centrally, such that a user in Active Directory will have authentication managed via password or another type of key and, with the use of security groups, has the authorizations managed. If a user changes security groups, the authorization will change, and if the user is inactive in Active Directory, the user cannot authenticate to other applications or databases.
A user can be created in the database as a global user, which means the database will reach out to Active Directory to get details about the user, first just to authenticate the password and then to verify the groups for authorization. The database is configured with a user to Active Directory, and the ldap.ora file is updated with the information to authenticate against the Active Directory. Once this is configured, a user can be created with the following syntax:
This allows Oracle Database to recognize the user hsolodba, which is in Active Directory, as a user that is allowed to access this database. The password is the same as the one in Active Directory, and the group can be used to map to a database role for permissions.
Identity management is important for an enterprise, and this allows a person to have roles and tasks based on their functions in the enterprise, and as those functions may change or are no longer with the company, the account is then centrally managed instead of in each database. The Oracle Cloud has an Identity Access Management (OCI IAM) that will configure roles and allow for users to be added, and they are managed as part of the Identity Management service and not in each database.
Users can be imported into the OCI IAM so that each individual account does not have to be entered. Even if not importing all of the enterprise users, working in this way will allow for consideration of which users should be migrated, and then you can verify the roles.
Common and Local Users
Each CDB and PDB has a list of valid database users. Common users have access to their various containers and are in the CDB. Local users are specific to a PDB. SYS and SYSTEM accounts are common users that Oracle creates automatically in a pluggable environment and can navigate across the system container. CDB common users can have different privileges in different PDBs.
Common users are created with the C## or c## at the start of the username. The COMMON_USER_PREFIX parameter sets the prefix, and even though you can change the prefix, this might produce name conflicts and should be handled carefully. The example creates a common user in all PDBs from the CDB:
Common users must be granted privileges from within each pluggable database. In other words, if you grant privileges to a common user while connected to the root container, this does not cascade to the PDBs. If you need to grant a common user a privilege that spans PDBs, then create a common role, and assign it to the common user. What use is there for a common user? One situation would be the performance of common DBA maintenance activities across PDBs not requiring SYSDBA-level privileges.
For example, you want to set up a DBA account that has the privileges to create users, grants, and so on, but you don’t want to use an account such as SYS (which has all privileged in all databases). In this scenario, you would create a common DBA user and also create a DBA common role that contains the appropriate privileges. The common role would then be assigned to the common DBA.
A local user is nothing more than a regular user that is created in a PDB. A local user is created as in the previous sections. A local username needs to be unique only for the PDB it was created in. Local users can have administrative privileges, but only for the PDB where the local account was created.
Roles are also common or local. All Oracle supplied roles are common but can be granted to a local user.
