Configuring Centrally Managed Users with Microsoft Active Directory

5 Configuring Centrally Managed Users with Microsoft Active Directory

Oracle Database can authenticate and authorize Microsoft Active Directory users with the database directly without intermediate directories or Oracle Enterprise User Security.

Introduction to Centrally Managed Users with Microsoft Active Directory

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

About the Oracle Database-Microsoft Active Directory Integration

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

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. Users can authenticate to the Oracle Database using credentials stored in Active Directory and also be associated with Database schemas and roles using Active Directory groups. Microsoft Active Directory users can be mapped to exclusive or shared Oracle Database schemas and associated with database roles in the directory. Active Directory password policies such as password expiration time and lockout after # failed login attempts are honored by the Oracle Database when users login.

Before Oracle Database 18c release 1 (18.1), users integrated user authentication and authorization 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 be used going forward by users who must use trusted database links, complex enterprise roles and having a single place for auditing database access privileges and roles.

The majority of organizations don’t require 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 backwards 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.

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

Users who are currently using strong authentication tools 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.

How Centrally Managed Users with Microsoft Active Directory Works

The integration works by creating a mapping between database users and roles with Microsoft Active Directory users and groups.

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. Active Directory security administrators can assign users to a shared schema and a global role mapped groups to change and update privileges and roles assigned to the Active Directory user in a database.

Centrally Managed User-Microsoft Active Directory Architecture

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. This filter will create Oracle password verifiers and 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 dbseg_pb_001b.eps follows

Description of the illustration dbseg_pb_001b.eps

Supported Authentication Methods

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)

Related Topics

Configuring Authentication for Centrally Managed Users

Users Supported by Centrally Managed Users with Microsoft Active Directory

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 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 oldest shared user mapping takes precedence.
Oracle recommends only having one possible mapping per user so unexpected schema mappings don’t 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, SYSDG, SYSKM, and SYSRAC.

You cannot directly 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.

Related Topics

Configuring Authorization for Centally Managed Users

How the Oracle Multitenant Option Affects Centrally Managed Users

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

An entire multitenant database can authenticate and authorize against a single Active Directory instance. Alternatively, individual pluggable databases (PDBs) can authenticate and authorize against different Active Directory domains.

Configuring the Oracle Database-Microsoft Active Directory Integration

Before you can use Microsoft Active Directory to authenticate and authorize users, you must configure the connection from the Oracle database to Active Directory.

About Configuring the Oracle Database-Microsoft Active Directory Connection

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.

Connecting to Microsoft Active Directory

You can configure a Microsoft Active Directory connection during the Oracle Database installation process or to 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.

In addition to being used for the Oracle Database-to-LDAP directory service interaction, the Oracle service directory user account can be used for Kerberos.

This account is an Active Directory account that Oracle Database uses to log in to Active Directory and query for users and group information from Active Directory, update login and success failures, and if Kerberos is configured, update Kerberos authentication. The minimum permissions required for this account are Read properties (of the Active Directory user), and if database password authentication is to be used by an Active Directory user, the Write lockoutTime (property of the Active Directory user) permission.

Log in to Microsoft Active Directory as a user who has privileges to create accounts and grant them privileges.
Create the Oracle Service Directory user account as an Active Directory user.
Ideally, create the managed service account in the root directory. Depending on the domains that your users will use, you can also create this account in child domains. Follow these guidelines:
- You should create this account at the lowest possible Active Directory location if the users are in multiple domains.
- If all the Active Directory users will be in one domain, then create this account in that domain. Doing so will help performance.
- Create this account in the Windows Active Directory root if:
  - The Active directory users will be in different domains.
  - Active Directory has multiple Windows domains, so that CMU can support these multiple domains.
Grant the Oracle service directory user account the Read properties (of the Active Directory user) and Write Lockout Time (property of the Active Directory user) permissions for the domains that will contain the users and groups.

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.

You do not need to perform this step if your authentication method is Kerberos or SSL. The opwdintg.exe executable installs the Oracle password filter, extends the AD schema, and creates the authorization Active directory groups to allow Oracle Database password authentication with Active Directory. This procedure adds an orclCommonAttribute attribute to the Active Directory schema for user accounts.

Go to the $ORACLE_HOME/bin directory.
Find the opwdintg.exe (Oracle Password Integration) utility.
Using a secure method of copying (such as sftp), copy opwdintg.exe to a temporary directory (for example, C:\temp) on each Windows domain controller.
Connect to the Windows computer as the Active Directory administrator.
Run the opwdintg.exe utility.
Answer the following prompts:
- Do you want to extend AD schema? [Yes/No]: Enter Yes.
- Schema extension for this domain will be permanent. Continue? [Yes/No]: Enter Yes.
  Note the following:
  - You can only extend the Active Directory schema from a Windows domain controller. If you try to extend the schema again, error messages appear, but you can ignore these errors.
  - This step creates the following three verifier groups. If these groups already exist, then errors will appear, but you can ignore these errors.
    - ORA_VFR_MD5 is required when the Oracle Database WebDAV client is used.
    - ORA_VFR_11G enables the use of the Oracle Database 11G password verifier.
    - ORA_VFR_12C enables the user of the Oracle Database 12C password verifier.
- Found password filter installed already. Do you want to deinstall? [Yes/No]: Enter Yes if you want to deinstall the password filter. Enter No if you do not want to deinstall the password filter.
- Do you want to install Oracle password filter? [Yes/No]: Enter Yes.
- The change requires machine reboot. Do you want to reboot now? [Yes/No]: Enter Yes.

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 database.

Follow the instructions in the Oracle Database Installation Guide for your platform to install the Oracle database.

After you install the Oracle database, you can configure centrally managed users with Active Directory for this database.

Step 4: Create the dsi.ora or ldap.ora File

The dsi.ora file specifies connections for centrally managed users for Active Directory.

The ldap.ora file can also specifies the connection to the Active Directory server. But because ldap.ora may already be used (or may be used in the future) for other services like net naming services, Oracle recommends the use of dsi.ora for centrally managed users.

About Using a dsi.ora File

You use a dsi.ora file to specify an Active Directory service for centrally managed users.

You must manually create the dsi.ora file to identify the Active Directory server. The dsi.ora file provides Active Directory connection information for all containers if it is located in the same places where the ldap.ora file can be placed. A dsi.ora file and a wallet in the $ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet location takes precedence over the main dsi.ora file for that PDB only.

Note:

If you are using ldap.ora for naming services, then do not make any changes to ldap.ora and its wallet for the CMU with Active Directory configuration. Only use dsi.ora to configure CMU-Active Directory.

When you create the dsi.ora file, Oracle Database searches for it in the following order (same locations as the Database would search for the ldap.ora file):

$LDAP_ADMIN environment variable setting
$ORACLE_HOME/ldap/admin directory
$TNS_ADMIN environment variable setting
$ORACLE_HOME/network/admin directory

Oracle recommends the use of directories under $ORACLE_BASE that are not under $ORACLE_HOME. Starting with Oracle Database 18c, there is an option to have read-only $ORACLE_HOME so dsi.ora should be placed in a directory outside of $ORACLE_HOME for future-proofing your architecture.

Oracle recommends only using dsi.ora to identify the Active Directory server for centrally managed users. If both dsi.ora and ldap.ora happen to be configured in the same database for centrally managed users for Active Directory, dsi.ora will take precedence over the ldap.ora file if both are located in the same directory. If they are located in different directories, then the first one that Oracle finds in the location precedence list above will be used to find the Active Directory server.

You can specify dsi.ora files for individual PDBs in a multitenant database. A PDB specific dsi.ora file will override the CMU-Active Directory settings for the general database for that one PDB. Different PDBs can connect to different Active Directory servers for CMU. The dsi.ora files for PDBs are located in the same directory as the wallet for that PDB.

Wallet locations for individual container in a multitenant database should place the wallet files in the $ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet directory. To find the db unique name, connect to the CDB root and execute the following query:

SELECT INSTANCE_NAME FROM V$INSTANCE;

To find the pdb_guid, from the CDB root, execute the following query:

SELECT PDB_ID,PDB_NAME,GUID FROM DBA_PDBS;

You can also place dsi.ora in the wallet directory for the CDB root container, but that will only connect the CDB root container to the Active Directory – not the entire database.

Creating the dsi.ora File

The dsi.ora configuration file sets the information to find the Active Directory server for centrally managed users.

To use the dsi.ora configuration file:

Log in to the server where the Oracle database is located.
Go to the directory where you want to create the dsi.ora file.
Add the following parameters to the dsi.ora file:
- DSI_DIRECTORY_SERVERS, which sets the Active Directory server host and port name, and alternate directory servers. The directory server name must be a fully qualified name. For example:
```
DSI_DIRECTORY_SERVERS = (ldap-server.us.example.com:389:636, sparky.us.example.com:389:636)
```
- DSI_DEFAULT_ADMIN_CONTEXT, which sets the names of the Active Server domains in which the Active Server directory users are located. For example:
```
DSI_DEFAULT_ADMIN_CONTEXT = "o=Example,c=US"
```
- DSI_DIRECTORY_SERVER_TYPE, which determines the Active Directory server access. You must set it to AD for Active Directory. Enter this value in upper case.
```
DSI_DIRECTORY_SERVER_TYPE = AD
```

About Using an ldap.ora File

You can use an ldap.ora file to specify an Active Directory server for centrally managed services.

If you are already using an ldap.ora file for another purpose such as net naming services, then you must use the dsi.ora file to configure centrally managed users to connect with Active Directory for user authentication and authorization. Even if Active Directory is already being used for net naming services, you must create and use a dsi.ora file to identify the Active Directory server for centrally managed users. Even if the database currently isn’t using ldap.ora for another service, Oracle recommends using dsi.ora in case ldap.ora will be used at a future time for net naming services..

The benefit of using ldap.ora is that you can use the DBCA graphical interface or the DBCA silent mode to complete the connection to the Active Directory server. When using dsi.ora, the steps to complete the connection to Active Directory must be done separately.

If ldap.ora is being used for naming services, then do not make any changes to ldap.ora and its wallet for the CMU with Active Directory configuration. Only use dsi.ora to configure CMU-Active Directory.

Typically, the ldap.ora file is stored in the $ORACLE_HOME/network/admin directory. Usually, the ldap.ora file cannot be in the same directory as the WALLET_LOCATION that is specified in the sqlnet.ora file, unless the WALLET_LOCATION is set to $ORACLE_HOME/network/admin.

After you create the ldap.ora file, Oracle Database searches for it in the following order:

$LDAP_ADMIN environment variable setting
$ORACLE_HOME/ldap/admin directory
$TNS_ADMIN environment variable setting
$ORACLE_HOME/network/admin directory

Creating the ldap.ora File

These steps assume that ldap.ora is not being used for net naming services and can be used to set up the connection with Active Directory for centrally managed users.

Log in to the server where the Oracle database is located.
Go to the directory where you want to create the ldap.ora file.
If the ldap.ora file does not exist, then create it by using a text editor.
If the ldap.ora file does exist, create a back-up of this file, and then open ldap.ora.
Add the following parameters to the ldap.ora file:
- DIRECTORY_SERVERS, which sets the directory server host and port name, and alternate directory servers. The directory server name must be a fully qualified name. For example:
```
DIRECTORY_SERVERS = (ldap-server.us.example.com:389:636, sparky.us.example.com:389:636)
```
- DEFAULT_ADMIN_CONTEXT, which sets the names of the Active Server domains in which the Active Server directory users are located. For example:
```
DEFAULT_ADMIN_CONTEXT = "o=Example,c=US"
```
- DIRECTORY_SERVER_TYPE, which determines the LDAP server access. You must set it to AD for Active Directory. Enter this value in upper case.
```
DIRECTORY_SERVER_TYPE = AD
```

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.

Request the Active Directory certificate from an Active Directory administrator.

Related Topics

Management of Certificate Revocation Lists (CRLs) with orapki Utility

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.

Copy the certificate text file (for example, AD_CA_Root_cert.txt) from the Active Directory server to the current directory.
If wallet location is not specified in the sqlnet.ora file, then the database will search the following locations in order for the wallet. The directory location may need to be created.
1. $ORACLE_BASE/admin/db unique name/wallet
2. $ORACLE_HOME/admin/db unique name/wallet
Wallet locations for individual container in a multitenant database should place the wallet files in the $ORACLE_BASE/admin/db unique name/pdb_guid/wallet/ directory. To find the db unique name, connect to the CDB root and execute the following query:
```
SELECT INSTANCE_NAME FROM V$INSTANCE;
```
To find the pdb_guid, from the CDB root, execute the following query:
```
SELECT PDB_ID,PDB_NAME,GUID FROM DBA_PDBS;
```
If sqlnet.ora is used to specify the wallet location, then individual PDB dsi.ora and wallets will not be recognized. Only the database-wide dsi.ora or ldap.ora located in one of the four default locations will be recognized. When the wallet location is specified then all containers must use the same Active Directory server.
Create a new wallet.
The following command creates an ewallet.p12 wallet in the current directory.
```
orapki wallet create -wallet .
Enter password: password
```
Create the Oracle directory service account name for performing searches in Active Directory (created in the first step).
For example:
```
mkstore -wrl . -createEntry ORACLE.SECURITY.USERNAME oracle
```

Specify the DN of the Oracle directory service account name.

For example:

mkstore -wrl . -createEntry ORACLE.SECURITY.DN cn=oracle,cn=users,dc=adintg,dc=examplecorp,dc=com

Create the user password credential for the Oracle directory service account name..
For example:
```
mkstore -wrl . -createEntry ORACLE.SECURITY.DN cn=Users,dc=test5,dc=dbsec18,dc=com
```
Add the certificate to the wallet. Use the Active Directory certificate you received from the Active Directory administrator and put it in the same directory.
For example:
```
orapki wallet add -wallet . -cert AD_CA_Root_cert.txt -trusted_cert
```

Verify the credentials.

For example:

orapki wallet display -wallet .

The output should be similar to the following:

Requested Certificates: 
User Certificates: 
Oracle Secret Store entries: 
ORACLE.SECURITY.DN 
ORACLE.SECURITY.PASSWORD 
ORACLE.SECURITY.USERNAME 
Trusted Certificates: 
Subject: CN=ADSVR,DC=production,DC=examplecorp,DC=com

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.

About Configuring the Microsoft Active Directory Connection

To configure the Microsoft Active Directory connection, you can set the parameters in the database or use DBCA.

DBCA creates the wallet so you do not need to create it separately. DBCA only recognizes ldap.ora that is configured for centrally managed users. If you are using dsi.ora then you must use the manual configuration methods.

Note:

Oracle recommends using dsi.ora for CMU-Active Directory.

Related Topics

Configuring the Access Manually Using Database System Parameters

Configuring the Access Manually Using Database System Parameters

You can configure the Active Directory services connection manually by using LDAP-specific Oracle Database system parameters.

Ensure that you have created the dsi.ora file or the ldap.ora file, and that you have created the wallet.
Log in to the database instance as a user who has the ALTER SYSTEM system privilege.
In a multitenant environment, you can log in to the CDB root or to a PDB.
For example, to log in to the CDB root:
```
sqlplus c##sec_admin
Enter password: password
```
Modify the LDAP_DIRECTORY_ACCESS parameter, which determines the type of LDAP directory access.
Valid values are PASSWORD and NONE (to disable the connection). PASSWORD requires an Active Directory server certificate and when you create the wallet, you must include the credentials for the Active Directory server account for Oracle.
For example:
```
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';
```
Set the LDAP_DIRECTORY_SYSAUTH parameter to YES, so that grants by Microsoft Active Directory administrative users to SYSDBA, SYSOPER, SYSDG, SYSKM, and SYSRAC are enabled.
If you set this parameter to NO, then only locally authenticated users (not users authenticated through centrally managed users) can log in with these privileges.
```
ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES SCOPE=SPFILE ;
```
Restart the database instance.
- If you are in a non-multitenant environment, or if you are in a multitenant environment and in the CDB root, shut down and then restart the instance:
```
SHUTDOWN IMMEDIATE
STARTUP
```
- If you are in a multitenant environment in a PDB, then close and re-open the PDB:
```
ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE pdb_name OPEN;
```

After you restart the database, you can check the LDAP settings as follows:

show parameter ldap

Configuring the Access Using the Database Configuration Assistant GUI

Oracle Database Configuration Assistant (DBCA) completes the LDAP connection configuration and automatically creates the wallet and stores the Active Directory certificate for use. DBCA only works when ldap.ora is configured for CMU-Active Directory.

These instructions assume that you have already installed the Oracle database and that you are using an ldap.ora file (not dsi.ora) to identify the Active Directory server for the centrally managed users. If you have not installed the database yet, then you can install the software using Oracle Universal Installer (OUI) and then use DBCA to create the database at the same time as it configures the Active Directory centrally managed user connection.

Log in to the database server where the Oracle database is installed as a user who has administrative privileges.
Start DBCA.
By default, the DBCA utility is located in the $ORACLE_HOME/bin directory.
For example:
```
./dbca
```
Select the Network Configuration option (or when you get to the network configuration option when creating the database).
The Specify Network Configuration Details window appears. If the Directory service integration area is not visible, then the ldap.ora file was not configured correctly. Check the ldap.ora configuration that you did earlier, and after you have corrected the file, rerun DBCA.
In the Directory service integration area, do the following:
- In the Service username field, enter the name of the Oracle service directory user account, and then provide this user's password in the Password field.
- In the Service user DN field, enter the DN for the Oracle service directory user account. The DN can be retrieved directly from the Active Directory server or from an Active Directory system administrator.
- For Access Type, select the type of authentication from the list (for example, PASSWORD). (This setting sets the LDAP_DIRECTORY_ACCESS parameter.) If necessary, select the Allow admin privileges authentication checkbox, which allows Active Directory users to authenticate and use database schemas with administrative privileges (that is, SYSOPER and SYSBACKUP). Otherwise, only locally authenticated users can login and use administrative privileges. (This setting corresponds to the LDAP_DIRECTORY_SYSAUTH parameter.
- Provide the path to the Active Directory certificate in the Certificate file location field. In a multitentant environment, DBCA recognizes and sets up Active Directory connections for the database instance connection. You must manually configure PDB connections if you want to connect a different Active Directory server to a PDB.
- In the Wallet password and Confirm password fields, enter and confirm the password for the Oracle wallet that will store the Oracle service user credentials and authentication. Afterwards, DBCA automatically creates the wallet and insert the certificate.
Click Next until you reach the Finish page.
Click Finish.

Related Topics

Configuring the Access Using Database Configuration Assistant Silent Mode

DBCA silent mode can create a new database or alter an existing database for the Microsoft Active Directory Services-Oracle Database integration.

Run Database Configuration Assistant (DBCA) in silent mode.

For example:

./dbca -silent -configureDatabase -sourceDB ad 
-registerWithDirService true -dirServiceUserName 
cn=example,cn=users,dc=adintg,dc=examplecorp,dc=com 
-dirServiceUser oracle -dirServicePassword password 
-ldapDirectoryAccessType PASSWORD -walletPassword password

Step 8: Verify the Oracle Wallet

The orapki utility can verify that the wallet for this database was created successfully.

Log in to the database instance that was used in the integration.
Go to the directory that contains the wallet.

In a non-multitenant environment, the wallet directory is in the $ORACLE_BASE/admin/db_unique_name directory.

In a multitenant environment, it is in $ORACLE_BASE/admin/db_unique_name/PDB_GUID.
At the command line, enter the following commands:
ls l wallet (to check that the wallet directory contains wallet files)

orapki wallet display -wallet wallet (to find the Oracle Secret Store entries)

The output should contain the following entries:
```
Requested Certificates: 
User Certificates: 
Oracle Secret Store entries: 
ORACLE.SECURITY.DN 
ORACLE.SECURITY.PASSWORD 
ORACLE.SECURITY.USERNAME 
Trusted Certificates: 
Subject: CN=ADSVR,DC=production,DC=examplecorp,DC=com
```

Step 9: Test the Integration

To test the integration, you must set the ORACLE_HOME, ORACLE_BASE, and ORACLE_SID variables and then verify the LDAP parameter settings.

Set the ORACLE_HOME, ORACLE_BASE, and ORACLE_SID variables.

For example:

export ORACLE_HOME=/app/product/18.1/dbhome_1
export ORACLE_BASE=/app
export ORACLE_SID=sales_db

Log in to the database instance as a user who has the SYSDBA administrative privilege.
For example:
```
sqlplus sec_admin as sysdba
Enter password: password
```

Check the LDAP parameter settings:

show parameter ldap

The output should be similar to the following:

NAME                          TYPE       VALUE
---------------------------   ---------  -----------------
ldap_directory_access         string     PASSWORD 
ldap_directory_sysauth        string     yes

Configuring Authentication for Centrally Managed Users

You can configure password authentication, Kerberos authentication, or public key infrastructure (PKI) authentication.

Configuring Password Authentication for Centrally Managed Users

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

About Configuring Password Authentication for Centrally Managed Users

To configure password authentication, you must deploy a password filter, set a password file, extend the Active Directory schema, and create groups for password verifiers.

For password authentication, because Oracle Database does not use ldapbind command to connect with Active Directory, you must install an Oracle filter and extend the Active Directory schema. The Oracle filter that you install in Active Directory creates Oracle-specific password verifiers when Active Directory users update their passwords. The Oracle filter does not generate all required Oracle password verifiers when it is first installed; the Oracle filter only generates the Oracle password verifier for a user when the user changes their Active Directory password.

To maintain backwards compatibility (if your site requires it), the Oracle filter can generate password verifiers to work with Oracle Database clients for releases 11g, 12c, and 18c. The Oracle password filter uses Active Directory groups named ORA_VFR_MD5 (for WebDAV), ORA_VFR_11G (for release 11g) and ORA_VFR_12C (for releases 12c and 18c) to determine which Oracle Database password verifiers to generate. These groups must be created in Active Directory for the Oracle password verifiers to be generated for group member users. These are separate groups that dictate which specific verifiers should be generated for the Active Directory users. For example, if ten directory users need to log in to a newly created Oracle Database release 18c database that only communicated with Oracle Database release 18c and 12c clients, then an Active Directory group ORA_VFR_12C will have ten Active Directory users as members. The Oracle filter will only generate 12C verifiers for these ten Active Directory users when they change passwords with Active Directory (18c verifiers are the same as 12c verifiers)

Configuring Password Authentication for a Centrally Managed User

You must perform the password authentication configuration in both the Active Directory server and the Oracle database.

Deploy the Oracle Database password filter and extend the Active Directory schema.
The utility tool for performing this task, opwdintg.exe, is located in $ORACLE_HOME/bin. This utility installs the password filter in Active Directory, extends the Active Directory schema to hold the Oracle password verifiers , and creates the Active Directory password filter groups. The password filter will enable the Microsoft Active Directory user accounts to be authenticated by the Oracle database when connected to clients using WebDAV, 11G, and 12C password verifiers.
1. To deploy the opwdintg.exe executable, copy this file to the Active Directory server and then have the Active Directory administrator run the opwdintg.exe utility tool.
2. Log in to Microsoft Active Directory as a user who has privileges to create and manage user groups.
3. Check for the following password filter user groups: ORA_VFR_MD5, ORA_VFR_11G, and ORA_VFR_12C. If these groups do not exist, then rerun the opwdintg.exe utility tool.
4. Add the Microsoft Active Directory users who will use Oracle Database to these groups, following these guidelines:
  - If either the client or the server only permits Oracle Database release 12c authentication, then add the user to the ORA_VFR_12C group. (Oracle Database release 18c uses the same verifier as Oracle Database release 12c.)
  - If both the client and the server only permit authentication lower than Oracle Database release 12c (that is, they have Oracle Database releases 11g, or 12.1.0.1 clients), then add the user to the ORA_VFR_11G group.
  - If a user must authenticate through an Oracle Database WebDAV client, then the user must be a member of the ORA_VFR_MD5 group.
  This configuration enables fine-grained control over the generation of the Oracle Database password verifiers. Only the required verifiers for the required users are generated. For example, if Microsoft Active Directory user pfitch is added to the ORA_VFR_12C and ORA_VFR_11G groups, then both the 12C and 11G verifiers will be generated for pfitch. This ensures that when applicable, the most secure and strongest verifier is chosen, while in other cases, the 11G verifier is chosen for the Oracle Database release 11g clients.
Update the database password file to version 12.2.
1. As a user with administrative privileges, log in to the server where the database that is to be used for the Microsoft Access Directory connection resides.
2. Go to the $ORACLE_HOME/dbs directory.
3. Run the ORAPWD utility to set the format to 12.2.
  For example:
```
orapwd FILE='/app/oracle/product/18.1/db_1/dbs/orapwdb181' FORMAT=12.2
```
  This setting ensures that you can grant the various administrative privileges such as SYSOPOER and SYSBACKUP to the global user.
4. Log in to the database instance as a user who has the ALTER SYSTEM privilege.
5. Set the REMOTE_LOGIN_PASSWORDFILE to shared:
```
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE = shared;
```
6. Restart the database instance.
```
SHUTDOWN IMMEDIATE
STARTUP
```

Related Topics

Step 2: For Password Authentication, Install the Password Filter and Extend the Microsoft Active Directory Schema

Logging in to an Oracle Database Using Password Authentication

For password authentication, centrally managed users users have two choices of how to log in to the database.

To log in to the database that is configured to connect to Active Directory, an Active Directory user can use the following logon user name syntax if he or she is using password authentication:

sqlplus / nolog 
connect "Windows_domain\Active_Directory_user_name"@tnsname_of_database 
Password: password

Alternatively, the user can use their Active Directory Windows user logon name with the DNS domain name. For example:

connect "Active_Directory_user_name@domain.example.com"@tnsname_of_database 
Password: password

Configuring Kerberos Authentication for Centrally Managed Users

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

CMU-Active Directory only supports the Microsoft Active Services Kerberos server. Other non-Active Directory Kerberos servers are not supported with CMU-Active Directory.

Related Topics

Enabling Kerberos Authentication

Configuring Authentication Using PKI Certificates for Centrally Managed Users

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.

Related Topics

Configuring Authorization for Centally Managed Users

With centrally managed users, you can manage the authorization of Oracle Database users.

Users can be added, modified, or dropped from an organization by using Active Directory without your having to add, modify, or drop the user from every database in your organization.

About Configuring Authorization for Centrally Managed Users

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.

Users can also be exclusively mapped to the 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.

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 also can 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.

Mapping a Directory Group to a Shared Database Global User

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

The Active Directory group must be created before the database global user can be mapped to it. You can add Active Directory users to the group at any time before the user needs to log in to the database. On the database side, you must have the CREATE USER and ALTER USER privileges to perform these mappings. This configuration can be used for users who have the password authentication, Kerberos authentication, and public key infrastructure (PKI) authentication methods.

You can assign users who share the same database schema for an application into an Active Directory group. A shared Oracle Database global user (that is, a shared schema) is mapped to an Active Directory group. This way, any Active Directory user of this group can log in to the database through that shared global user account. Although the database global user account is shared by group members, the Active Directory user's enterprise identity (DN) is tracked and audited inside the database.

Log in to the database instance as a user who has been granted the CREATE USER system privilege.
Execute the CREATE USER statement with the IDENTIFIED GLOBALLY clause.
For example, to map a directory group named widget_sales_group in the Sales organization unit of the 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=examplecorp,dc=com';
```
All members of the widget_sales_group will be assigned to the widget_sales shared schema when they login to the database.

Mapping a Directory Group to a Global Role

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

Log in to the database instance as a user who has been granted the CREATE ROLE system privilege.
Execute the CREATE ROLE statement with the IDENTIFIED GLOBALLY clause.
For example, to map a directory user group named widget_sales_reporting in the Sales organization unit of the examplecorp.com domain to a database global role widget_sales_role:
```
CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
'cn=widget_sales_reporting,ou=sales,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_reporting,ou=sales,dc=examplecorp,dc=com' 
CONTAINER = ALL;
```

Exclusively Mapping a Directory User to a Database Global User

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

You perform the configuration on the Oracle Database side only, not the Active Directory side. You must have the CREATE USER and ALTER USER privileges to perform these mappings. This configuration can be used for users who have the password authentication, Kerberos authentication, and public key infrastructure (PKI) authentication methods.

Log in to the database instance as a user who has been granted the CREATE USER system privilege.
Execute the CREATE USER statement with the IDENTIFIED GLOBALLY clause.
For example, to map an existing Active Directory user named Peter Fitch in the sales organization of the examplecorp.com domain to use a database global user named peter_global:
```
CREATE USER peter_fitch IDENTIFIED GLOBALLY AS
'cn=peter fitch,ou=sales,dc=examplecorp,dc=com';
```

Altering or Migrating a User Mapping Definition

You can update a Directory User-to-global-user mapping by using the ALTER USER statement.

You can update users whose accounts were created using any of the CREATE USER statement clauses: IDENTIFIED BY password, IDENTIFIED EXTERNALLY, or IDENTIFIED GLOBALLY. This is useful when migrating users to using CMU. For example, a database user that is externally authenticated to Kerberos will be identified by their user principal name (UPN). To migrate the user to use CMU with Kerberos authentication, you would need to run the ALTER USER statement to declare a global user and identify the user with their Active Directory domain name.

Execute the ALTER USER statement with the IDENTIFIED GLOBALLY clause.

For example:

ALTER USER peter_fitch IDENTIFIED GLOBALLY AS
'cn=peter fitch,ou=widget_sales,dc=examplecorp,dc=com';

Configuring Administrative Users

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.

You can assign new database administrators to shared accounts in multiple databases using Active Directory groups without having to create new Oracle database accounts.

Ensure that the password file for the current database instance is in the 12.2 format.
```
orapwd file=pwd_file FORMAT=12.2
Enter password for SYS: password
```
In Active Directory, create an Active Directory group (for example, for a database administrator backup users group called ad_dba_backup_users).
In Oracle Database, create a global user (shared schema) (for example, db_dba_backup_global_user) and map this user to the Active Directory ad_dba_backup_users group.
Grant the SYSBACKUP administrative privilege to the global group db_dba_backup_global_user.
Now, any Active Directory user that is put into the new Active Directory group will be assigned the SYSBACKUP administrative privilege.

At this stage, any Active Directory user who is added to the ad_dba_backup_users Active Directory group will be assigned to the new database shared schema with the SYSBACKUP administrative privilege.

Configuring Database Administrative Users Using Exclusive Mapping

Database administrators can also be mapped in exclusive schemas in databases, which requires a separate global user to be created in each database for each exclusively mapped DBA.

Ensure that the password file for the current database instance is in the 12.2 format.
```
orapwd file=pwd_file FORMAT=12.2
Enter password for SYS: password
```
Log in to the database instance as a user who can create users and grant administrative privileges to other users.

Create this user as a global user.

For example:

CREATE USER peter_fitch IDENTIFIED GLOBALLY AS
'cn=peter fitch,ou=sales,dc=examplecorp,dc=com';

Grant this user the administrative privilege.
For example, to grant a user the SYSKM administrative privilege:.
```
GRANT SYSKM TO peter_fitch;
```

Due to the amount of work to maintain accounts and the mapping in both the database and Active Directory, a more centralized approach would be to use shared schemas for these administrative accounts as well, even if only one Active Directory user is assigned to the shared database account in some cases.

Integration of Oracle Database with Microsoft Active Directory Password Policies

As part of the Oracle Database-Microsoft Active Directory integration, Oracle Database enforces the Active Directory password policies when Active Directory users log into the Oracle database.

As part of the Oracle Database-CMU-Active Directory integration, the Oracle Database enforces the Active Directory password policies when Active Directory users try to log into the Oracle Database. Preventing users with expired passwords and locking accounts after a specified number of failed login attempts are examples of Active Directory password policies that the Oracle database will enforce.