Centrally managed users provides a simpler integration with Microsoft Active Directory to allow centralized authentication and authorization of users.

The minimum version requirement for Active Directory server operating system is Microsoft Windows Server 2008 R2.

This integration enables organizations to use Active Directory to centrally manage users and roles in multiple Oracle databases with a single directory along with other Information Technology services. Active Directory users can authenticate to the Oracle database by using credentials that are stored in Active Directory. Active Directory users can also be associated with database users (schemas) and roles by using Active Directory groups. Microsoft Active Directory users can be mapped to exclusive or shared Oracle Database users (schemas), and be associated with database roles through their group membership in the directory. Active Directory account policies such as password expiration time and lockout after a specified number of failed login attempts are honored by the Oracle Database when users login.

Before Oracle Database 18c release 1 (18.1), database user authentication and authorization could be integrated with Active Directory by configuring Oracle Enterprise User Security and installing and configuring Oracle Internet Directory (or Oracle Universal Directory). This architecture is still available and will continue to be used by users who must use the Oracle enterprise domain and current user database link between trusted databases, complex enterprise roles, and having a single place for auditing database access privileges and roles.

The majority of organizations do not have these complex requirements. Instead, they can use centrally managed users (CMUs) with Active Directory. This integration is designed for organizations who prefer to use Active Directory as their centralized identity management solution. Oracle Net Naming Services continues to work as it did before with directory services.

Organizations can use Kerberos, PKI, or password authentication with CMU with Active Directory. Use of CMU with Active Directory is backward compatible with currently supported Oracle Database clients. This means that LDAP bind operations are not used for password authentication and you will need to add an Oracle filter to Active Directory along with an extension to the Active Directory schema to store password verifiers. Organizations using Kerberos or PKI will not need to add the filter or extend Active Directory schema.

The Oracle Database-Active Directory integration is particularly beneficial for the following types of users:

• Users who are currently using strong authentication such as Kerberos or Public Key Infrastructure (PKI). These users already use a centralized identity management system

• Users who currently use Oracle Enterprise User Security, Oracle Internet Directory, Oracle Unified Directory, Oracle Virtual Directory, and need to integrate with Active Directory.

The integration works by mapping Microsoft Active Directory users and groups directly to Oracle database users and roles.

In order for the Oracle Database CMU with Active Directory integration to work, the Oracle database must be able to login to a service account specifically created for the database in Active Directory. The database uses this service account to query Active Directory for user and group information when a user logs into the database. This Active Directory service account must have all the privileges required to query the user and group information as well as being able to write updates related to the password policies in Active Directory (for example, failed login attempts, clear failed login attempts). Users can authenticate using passwords, Kerberos, or PKI and either be assigned to an exclusive schema or a shared schema. Mapping of an Active Directory user to a shared schema is determined by the association of the user to an Active Directory group that is mapped to the shared schema. Active Directory groups can also be mapped to database global roles. An Active Directory security administrator can assign a user to groups that are mapped to shared database global users (schemas) and/or database global roles, and hence update privileges and roles that are assigned to the Active Directory user in a database.

The CMU with Active Directory architecture enables Oracle Database users and roles to be managed in Active Directory.

The following figure illustrates the Oracle Database CMU feature. In this figure, users, either through applications as non-administrative users or administrative users, connect to the Oracle database with either password, Kerberos, or public key infrastructure (PKI) authentication. The database connection to Active Directory enables these users and roles to be mapped with Active Directory users and groups. If you plan to use password authentication, then you must install an Oracle filter in Active Directory. You can use an Oracle provided utility to install the Oracle filter that will generate Oracle password verifiers for individual users as needed. The utility can also be used to extend the Active Directory schema to hold the Oracle password verifiers. With Oracle Database centrally managed users, an Active Directory administrator can control the authentication, user management, account policies, and group assignments of Active Directory users and groups who have been mapped to Oracle Database users and roles.

Description of the illustration dbseg_pb_001b.eps

The Oracle Database-Microsoft Active Directory integration supports three common authentication methods.

These authentication methods are as follows:

• Password authentication

• Kerberos authentication

• Public key infrastructure (PKI) authentication (certificate-based authentication)

CMU with Active Directory supports exclusively mapped users, users mapped to shared schemas, and administrative users.

These users are as follows:

• Directory users that access an Oracle database using a shared schema.

  This type of directory user can connect to a shared schema in the database by being part of a directory group that is mapped to the shared schema (database user). Using shared schemas allows centralized Active Directory management of database users and is the recommended best practices over using exclusive schemas (described next). Even if there is only one user associated with a schema (for example, an administrator responsible for database backup), it is easier to manage adding another backup administrator or removing the existing administrator by making changes only in Active Directory instead of making changes in all associated databases as well.

  Users will be given additional privileges appropriate to their task using global roles that are mapped to groups in Active Directory. With this design, a user can change his or her tasks within an organization and have new database privileges through a new group in Active Directory.

  Active Directory users could accidentally (or on purpose) be a member of multiple groups in Active Directory that are mapped to different shared schemas on the same database. The user could also have an exclusive mapping to a database schema. In cases where the user has multiple possible schema mappings when they login, the following precedence rules apply:

  • If an exclusive mapping exists for a user, then that mapping takes precedence over any other shared mappings.

  • If multiple shared schema mappings exist for a user, then the shared user mapping with lowest schema ID (USER_ID) takes precedence.

  Oracle recommends only having one possible mapping per user so unexpected schema mappings do not occur.

• Exclusively mapped global users who are regular Oracle Database users in two- and three-tier applications, or users who have direct privilege grants in the database.

  Oracle recommends that you grant privileges to these users through global roles. This type of privilege grant facilitates authorization management by centrally managing privileges and roles for a user instead of having to log in into each database to update privileges and roles for the user.

• Administrative global users, who have the following administrative privileges: SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM, and SYSRAC.

  You cannot grant these administrative privileges through global roles. To authorize an Active Directory user with these administrative privileges, you must map the directory user to a database user (exclusively or with a shared schema) that has the system administrative privilege already granted to the database user account.

Multitenant database users in pluggable databases (PDBs) can connect to a central Microsoft Active Directory or, if required, users in an individual PDB can connect to a different Microsoft Active Directory.

All PDBs and the root container in a multitenant database can have a shared configuration, so that the entire CDB can authenticate and authorize users against a single Active Directory server, mulitple Active Directory servers in one Windows domain, or multiple Active Directory servers in trusted Windows domains, based on the shared configuration. Alternatively, individual PDBs can authenticate and authorize users against different Active Directory servers in the same Windows domain or different (trusted or un-trusted) Windows domains, based on their individual configurations.

Before you configure this connection, you must have Microsoft Active Directory installed and configured.

You must create an Oracle service directory user in Active Directory, configure the Oracle Database connection to Active Directory, and then depending on the authentication type, configure the database and Active Directory for password, Kerberos, or public key infrastructure (PKI) authentication. Before you map Database users and global roles to Active Directory users and groups, you must ensure that the Active Directory users and groups have been created. You will map the database users and global roles to Active Directory users and groups by using the CREATE USER, CREATE ROLE, ALTER USER, ALTER ROLE SQL statements with the GLOBALLY clause. An Active Directory system administrator must also set up new Active Directory groups with Active Directory users to meet your requirements.

The Active Directory system administrator is responsible for setting Active Directory connections with or without SASL bind. The Oracle Database will automatically try the Active Directory connection first with SASL bind and if it fails, it will try it without SASL bind but still secured with TLS. This means that regardless of how the Microsoft Active Directory administrator may have the SASL settings configured on Active Directory, the Oracle database will connect even if the SASL bind is unsuccessful.

You can configure a Microsoft Active Directory connection during the Oracle database creation or with an existing Oracle database.

• Step 1: Create an Oracle Service Directory User Account on Microsoft Active Directory
  The Oracle service directory user account is for the interaction between Oracle Database and the LDAP directory service.
• Step 2: For Password Authentication, Install the Password Filter and Extend the Microsoft Active Directory Schema
  You can use the Oracle opwdintg.exe executable on the Active Directory server to install the password filter and extend the Active Directory schema.
• Step 3: If Necessary, Install the Oracle Database Software
  If you have not done so yet, then use Oracle Universal Installer (OUI) to install the Oracle software.
• Step 4: Create the dsi.ora or ldap.ora File
  The dsi.ora file specifies connections for centrally managed users for Active Directory.
• Step 5: Request an Active Directory Certificate for a Secure Connection
  After you have configured the dsi.ora or ldap.ora file, you are ready to prepare Microsoft Active Directory and Oracle Database certificates for a secure connection.
• Step 6: Create the Wallet for a Secure Connection
  After you have copied the Active Directory certificate, you are ready to add it to the Oracle wallet.
• Step 7: Configure the Microsoft Active Directory Connection
  Next, you are ready to connect the database to Active Directory using the settings you have so far.
• Step 8: Verify the Oracle Wallet
  The orapki utility can verify that the wallet for this database was created successfully.
• Step 9: Test the Integration
  To test the integration, you must set the ORACLE_HOME, ORACLE_BASE, and ORACLE_SID environment variables and then verify the LDAP parameter settings.

Configuring password authentication for centrally managed users entails the use of a password filter with Active Directory to generate and store Oracle Database password verifiers on Active Directory.

• About Configuring Password Authentication for Centrally Managed Users
  To configure password authentication, you must deploy a password filter, extend the Active Directory schema by adding one user attribute, and create groups for generating different versions of password verifiers on Active Directory.
• Configuring Password Authentication for a Centrally Managed User
  You must perform password authentication configuration on Active Directory servers, and also on Oracle databases if it is required that Active Directory users will log in to Oracle databases with administrative privileges.
• Logging in to an Oracle Database Using Password Authentication
  For password authentication, centrally managed users have choices of how to log in to the database.

If you plan to use Kerberos authentication, then you must configure Kerberos in the Oracle database that will be integrated with Microsoft Active Directory.

If you plan to use PKI certificates for the authentication of centrally managed users, then you must configure Secure Sockets Layer in the Oracle database that will be integrated with Microsoft Active Directory.

You can manage user authorization for a database within Active Directory.

Most Oracle Database users will be mapped to a shared database schema (user). This minimizes the work that must be done in each Oracle database when directory users are hired, change jobs within the company, or leave the company. A directory user will be assigned to an Active Directory group that is mapped to an Oracle database global user (schema). When the user logs into the database, the database will query Active Directory to find the groups the user is a member of. If your deployment is using shared schemas, then one of the groups will map to a shared database schema and the user will be assigned to that database schema. The user will have the roles and privileges that granted to the database schema. Because multiple users will be assigned to the same shared database schema, only the minimal set of roles and privileges should be granted to the shared schema. In some cases, no privileges and roles should be granted to the shared schema. Users will be assigned the appropriate set of roles and schemas through database global roles. Global roles are mapped to Active Directory groups. This way, different users can have different roles and privileges even if they are mapped to the same database shared schema. A newly hired user will be assigned to an Active Directory group mapped to a shared schema and then to one or more additional groups mapped to global roles to gain the additional roles and privileges required to complete their tasks. The combination of shared schemas and global roles allows for centralized authorization management with minimal changes to the database operationally. The database must be initially provisioned with the set of shared schemas and global roles mapped to the appropriate Active Directory groups, but then user authorization management can happen within Active Directory.

An Active Directory user can also be exclusively mapped to a database global user. This requires a new user in the database that is mapped directly to the Active Directory user. New users and departing users will require updates to each database they are members of.

Active Directory users requiring administrative privileges such as SYSOPER and SYSBACKUP cannot be granted these through global roles. Administrative privileges can only be granted to a schema and not a role. But even in these cases with administrative privileges, shared schemas can be used to provide ease of user authorization management. Using a shared schema with the SYSOPER privilege will allow new users to be easily added to the Active Directory group mapped to the schema with SYSOPER without having to create a new user schema in the database. Even if only one user is assigned to the shared schema, it can still be managed centrally.

When using global roles to grant privileges and roles to the user, remember that the maximum number of enabled roles in a session is 150.

The following types of global user mappings are supported for authorization:

• Map shared global users, in which directory users are assigned to a shared database schema (user) through the mapping of a directory group to the shared schema. The directory users that are members of the group can connect to the database through this shared schema. Use of shared schemas allows for centralized management of user authorization in Active Directory.

• Exclusive global user mappings, in which a dedicated database user is exclusively mapped to a directory user. Not as common as the shared database schema, this user is created for direct database access by using either SQL*Plus or the schema user for two-tier or three-tier applications. Oracle recommends that you grant database privileges to these users through global roles, which facilitates authorization management. However, these users can also have direct privilege grants in the Oracle database, although this is not recommended. This is because two-tier and three-tier applications can use the global user as the database schema, so the global user has the full database privileges on the schema objects as the owner.

It is common for a directory user to be a member of multiple groups. However, only one of these groups should be mapped to a shared schema.

Most users of the database will be mapped to a shared global database user (schema) through membership in a directory group.

1. Log in to the database instance as a user who has been granted the CREATE USER or ALTER USER system privilege.
2. Execute the CREATE USER or ALTER USER statement with the IDENTIFIED GLOBALLY AS clause specifying the DN of an Active Directory group.
   For example, to map a directory group named widget_sales_group in the sales organization unit of the production.examplecorp.com domain to a shared database global user named WIDGET_SALES:

   CREATE USER widget_sales IDENTIFIED GLOBALLY AS
   'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com';

   All members of the widget_sales_group will be assigned to the widget_sales shared schema when they log in to the database.

Database global roles mapped to directory groups give member users additional privileges and roles above what they have been granted through their login schemas.

1. Log in to the database instance as a user who has been granted the CREATE ROLE or ALTER ROLE system privilege.
2. Execute the CREATE ROLE or ALTER ROLE statement with the IDENTIFIED GLOBALLY AS clause specifying the DN of an Active Directory group.
   For example, to map a directory user group named widget_sales_group in the sales organization unit of the production.examplecorp.com domain to a database global role WIDGET_SALES_ROLE:

   CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
   'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com';

   In a multitenant environment, to create a common role called C##WIDGET_SALES_ROLE:

   CREATE ROLE c##widget_sales_role IDENTIFIED GLOBALLY AS
   'CN=widget_sales_group,OU=sales,DC=production,DC=examplecorp,DC=com'  
   CONTAINER = ALL;

   All members of the widget_sales_group will be authorized with the database role widget_sales_role when they log in to the database.

You can map a Microsoft Active Directory user exclusively to an Oracle Database global user.

1. Log in to the database instance as a user who has been granted the CREATE USER or ALTER USER system privilege.
2. Execute the CREATE USER or ALTER USER statement with the IDENTIFIED GLOBALLY AS clause specifying the DN of an Active Directory user.
   For example, to map an existing Active Directory user named Peter Fitch (whose samAccountName is pfitch) in the sales organization unit of the production.examplecorp.com domain to a database global user named PETER_FITCH:

   CREATE USER peter_fitch IDENTIFIED GLOBALLY AS
   'CN=Peter Fitch,OU=sales,DC=production,DC=examplecorp,DC=com';

You can update an Active Directory user to a Database global user mapping by using the ALTER USER statement.

1. Log in to the database instance as a user who has been granted the ALTER USER system privilege.
2. Execute the ALTER USER statement with the IDENTIFIED GLOBALLY AS clause.
   For example:

   ALTER USER peter_fitch IDENTIFIED GLOBALLY AS
   'CN=Peter Fitch,OU=sales,DC=production,DC=examplecorp,DC=com';

Administrative users can work as they have in the past, but with CMUs, they can be controlled with centralized authentication and authorization if they are using shared schemas.

• Configuring Database Administrative Users with Shared Access Accounts
  Using shared accounts simplifies the management of database administrators for multiple databases as they join, move, and leave the organization.
• Configuring Database Administrative Users Using Exclusive Mapping
  Database administrators can also be mapped to exclusive schemas in databases.

After you configure and authorize a centrally managed user, you can verify the user logon information by executing a set of SQL queries on the Oracle database side.

1. Log in to the database as a centrally managed user from Active Directory that you have just configured and authorized.
   For example, to log in to the database instance inst1 as the enterprise user pfitch, who is on the Windows domain production:

   sqlplus /nolog
   connect "production\pfitch"@inst1
   Enter password: password

2. Verify the mapped global user.
   The mapped global user is the database user account that has the centrally managed user authorization. User PETER_FITCH is considered a global user with exclusive mapping for the Active Directory user pfitch, while user WIDGET_SALES is considered a global user with shared mapping for Active Directory group widget_sales_group of which pfitch is a member. A global user account has its own schema.

   SHOW USER;

   Output similar to the following appears, depending on if it is an exclusive mapping or a shared mapping:

   USER is "PETER_FITCH"

   Or

   USER is "WIDGET_SALES"

3. Find the roles that have been granted to the centrally managed user.

   SELECT ROLE FROM SESSION_ROLES ORDER BY ROLE;

   Output similar to the following appears:

   ROLE
   ----------------------------------------------------------------------
   WIDGET_SALES_ROLE
   ...

4. Execute the following queries to check the SYS_CONTEXT namespace values for the current schema being used in this database session, current user name, session user name, authentication method, authenticated identity, enterprise identity, identification type, and LDAP server type.
   • Verify the current schema that is being used in this database session. A database schema is an object container that identifies the objects it contains. The current schema is the default container for objects name resolution in this database session.

     SELECT SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA') FROM DUAL;

     Output similar to the following appears, depending on if it is an exclusive mapping or a shared mapping:

     SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
     ----------------------------------------------------------------------
     PETER_FITCH

     Or

     SYS_CONTEXT('USERENV','CURRENT_SCHEMA')
     ----------------------------------------------------------------------
     WIDGET_SALES

   • Verify the current user. In this case, the current user is the same as the current schema.

     SELECT SYS_CONTEXT('USERENV', 'CURRENT_USER') FROM DUAL;

     Output similar to the following appears, depending on if it is an exclusive mapping or a shared mapping:

     SYS_CONTEXT('USERENV','CURRENT_USER')
     ----------------------------------------------------------------------
     PETER_FITCH

     Or

     SYS_CONTEXT('USERENV','CURRENT_USER')
     ----------------------------------------------------------------------
     WIDGET_SALES

   • Verify the session user.

     SELECT SYS_CONTEXT('USERENV', 'SESSION_USER') FROM DUAL;

     Output similar to the following appears, depending on if it is an exclusive mapping or a shared mapping:

     SYS_CONTEXT('USERENV','SESSION_USER')
     ----------------------------------------------------------------------
     PETER_FITCH

     Or

     SYS_CONTEXT('USERENV','SESSION_USER')
     ----------------------------------------------------------------------
     WIDGET_SALES

   • Verify the authentication method.

     SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATION_METHOD') FROM DUAL;

     Output similar to the following appears:

     SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD')
     ----------------------------------------------------------------------
     PASSWORD_GLOBAL
     

   • Verify the authenticated identity for the enterprise user. The Active Directory authenticated user identity is captured and audited when this user logs on to the database.

     SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') FROM DUAL;

     Output similar to the following appears:

     SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY')
     ----------------------------------------------------------------------
     production\pfitch
     

   • Verify the centrally managed user's enterprise identity.

     SELECT SYS_CONTEXT('USERENV', 'ENTERPRISE_IDENTITY') FROM DUAL;

     Output similar to the following appears:

     SYS_CONTEXT('USERENV','ENTERPRISE_IDENTITY')
     ----------------------------------------------------------------------
     cn=Peter Fitch,ou=sales,dc=production,dc=examplecorp,dc=com

   • Verify the identification type.

     SELECT SYS_CONTEXT('USERENV', 'IDENTIFICATION_TYPE') FROM DUAL

     Output similar to the following appears, depending on if it is an exclusive mapping or a shared mapping:

     SYS_CONTEXT('USERENV','IDENTIFICATION_TYPE')
     ----------------------------------------------------------------------
     GLOBAL EXCLUSIVE

     Or

     SYS_CONTEXT('USERENV','IDENTIFICATION_TYPE')
     ----------------------------------------------------------------------
     GLOBAL SHARED

   • Verify the LDAP server type.

     SELECT SYS_CONTEXT('USERENV', 'LDAP_SERVER_TYPE') FROM DUAL;

     Output similar to the following appears. In this case, the LDAP server type is Active Directory.

     SYS_CONTEXT('USERENV','LDAP_SERVER_TYPE')
     ----------------------------------------------------------------------
     AD