6 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 (CMU) provides a simpler integration with Microsoft Active Directory to allow centralized authentication and authorization of users. - 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. - Configuring Authentication for Centrally Managed Users
You can configure password authentication, Kerberos authentication, or public key infrastructure (PKI) authentication. - Configuring Authorization for Centrally Managed Users
With centrally managed users, you can manage the authorization for Active Directory users to access Oracle databases. - Integration of Oracle Database with Microsoft Active Directory Account Policies
As part of the Oracle Database-Microsoft Active Directory integration, Oracle Database enforces the Active Directory account policies when Active Directory users log into the Oracle database. - Configuring Centrally Managed Users with Oracle Autonomous Database
You can deploy centrally managed users (CMU) on Oracle Autonomous Database. - Troubleshooting Centrally Managed Users
You can find troubleshooting information about the configuration of centrally managed users (CMU) on My Oracle Support.
Parent topic: Managing User Authentication and Authorization
6.1 Introduction to Centrally Managed Users with Microsoft Active Directory
Centrally managed users (CMU) provides 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 a simpler integration with Microsoft Active Directory to allow centralized authentication and authorization of users. - How Centrally Managed Users with Microsoft Active Directory Works
The integration works by mapping Microsoft Active Directory users and groups directly to Oracle database users and roles. - 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. - Supported Authentication Methods
The Oracle Database-Microsoft Active Directory integration supports three common authentication methods. - 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. - How the Oracle Multitenant Option Affects Centrally Managed Users
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.
6.1.1 About the Oracle Database-Microsoft Active Directory Integration
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.
6.1.2 How Centrally Managed Users with Microsoft Active Directory Works
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.
6.1.3 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. 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.
6.1.4 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)
6.1.5 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 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
, andSYSRAC
.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.
6.1.6 How the Oracle Multitenant Option Affects Centrally Managed Users
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.
6.2 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. - Connecting to Microsoft Active Directory
You can configure a Microsoft Active Directory connection during the Oracle database creation or with an existing Oracle database.
6.2.1 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.
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.
6.2.2 Connecting to Microsoft Active Directory
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 and Grant Permissions
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 Oracleopwdintg.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
Thedsi.ora
andldap.ora
files specify connections for centrally managed users for Active Directory. - Step 5: Request an Active Directory Certificate for a Secure Connection
After you have configured thedsi.ora
orldap.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
Theorapki
utility can verify that the wallet for this database was created successfully. - Step 9: Test the Integration
To test the integration, you must set theORACLE_HOME
,ORACLE_BASE,
andORACLE_SID
environment variables and then verify the LDAP parameter settings.
6.2.2.1 Step 1: Create an Oracle Service Directory User Account on Microsoft Active Directory and Grant Permissions
The Oracle service directory user account is for the interaction between Oracle Database and the LDAP directory service.
Read properties
(of Active Directory users who will log in to a database) permission, and if database password authentication is to be used by Active Directory users, the Write lockoutTime
(property of the Active Directory users) permission, and Control Access
(of the orclCommonAttribute
property of the Active Directory users) permission.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.2 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.
opwdintg.exe
executable installs the Oracle password filter, extends the Active Directory schema, and creates Active Directory groups to allow Oracle Database password authentication with Active Directory. This procedure adds an orclCommonAttribute
property to the Active Directory schema for user accounts.
Note:
You must install the Oracle password filter on every Windows domain controller in a domain, to ensure that Oracle password verifiers will be generated for Active Directory users in this domain if they need to use password authentication to log in Oracle database.Note also that orclCommonAttribute
stores Oracle password verifier for the Active Directory user. This attribute is also used for password authentication by other Oracle products or features such as Enterprise User Security. For security consideration, you should deny everyone except the Oracle service directory user from accessing the orclCommonAttribute
property.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.3 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.
- Follow the instructions in the Oracle Database Installation Guide for your platform to install the Oracle software.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.4 Step 4: Create the dsi.ora or ldap.ora File
The dsi.ora
and ldap.ora
files specify connections for centrally managed users for Active Directory.
- Comparison of the dsi.ora and ldap.ora Files
How you use thedsi.ora
andldap.ora
depends on howldap.ora
is used with other services. - About Using a dsi.ora File
You use adsi.ora
file to specify Active Directory servers for centrally managed users. - Creating the dsi.ora File
Thedsi.ora
configuration file sets the information to find the Active Directory servers for centrally managed users. - About Using an ldap.ora File
You can use anldap.ora
file to specify Active Directory servers for centrally managed users. - Creating the ldap.ora File
These steps assume thatldap.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.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.4.1 Comparison of the dsi.ora and ldap.ora Files
How you use the dsi.ora
and ldap.ora
depends on how ldap.ora
is used with other services.
The dsi.ora
file specifies connections for centrally managed users for Active Directory. The ldap.ora
file can also specify the connection to the Active Directory server. However, because each individual PDB cannot have its own ldap.ora
, and also 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.
Parent topic: Step 4: Create the dsi.ora or ldap.ora File
6.2.2.4.2 About Using a dsi.ora File
You use a dsi.ora
file to specify Active Directory servers for centrally managed users.
You must manually create the dsi.ora
file to identify the Active Directory servers. The dsi.ora
file provides Active Directory connection information for all pluggable databases if it is located in the same places where the ldap.ora
file can be placed. A dsi.ora
file in a PDB-specific wallet location takes precedence over the main dsi.ora
file for that PDB only.
Note:
If you are usingldap.ora
for naming services, then do not make any changes to ldap.ora
for the CMU with Active Directory configuration. Only use dsi.ora
to configure CMU-Active Directory.
Placement of dsi.ora
Oracle recommends that you use directories for writable files under $ORACLE_BASE
, not under $ORACLE_HOME
. Starting with Oracle Database 18c, you can optionally set the $ORACLE_HOME
directory to be read-only. Hence, you should place the dsi.ora
file in a directory that is outside of $ORACLE_HOME
to accommodate the dsi.ora
configuration for future releases.
Search Order for dsi.ora
When you create the dsi.ora
file, Oracle Database searches for it in the following order:
- If the
WALLET_LOCATION
setting is included in thesqlnet.ora
file, then for a non-multitenant database or the root container of a multitenant database, Oracle searches for it in the location that is specified insqlnet.ora
. For a PDB of a multitenant database, Oracle searches for it in the per-PDB wallet location that is in theWALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid
directory. - If the
WALLET_LOCATION
setting is not included in thesqlnet.ora
file, then Oracle Database searches for it in the default wallet location. - If Oracle Database cannot find
dsi.ora
in the wallet location, then Oracle Database searches for it in the following order. These are the same locations that Oracle Database searches for theldap.ora
file.$LDAP_ADMIN
environment variable setting$ORACLE_HOME/ldap/admin
directory$TNS_ADMIN
environment variable setting$ORACLE_HOME/network/admin
directory
When to Use dsi.ora
Oracle recommends that you use only dsi.ora
to identify the Active Directory servers for centrally managed users. If both dsi.ora
and ldap.ora
are configured in the same database for centrally managed users for Active Directory and are both located in the same directory, then dsi.ora
takes precedence over the ldap.ora
file. If they are in different directories, then Oracle uses the first one that it finds in the location precedence list above to find the Active Directory server. If the directory server type in the first found dsi.ora
or ldap.ora
is not Active Directory, then centrally managed users will not be enabled.
Using dsi.ora in a Multitenant Environment
You can specify dsi.ora
files for individual PDBs in a multitenant database. A PDB-specific dsi.ora
will override the common settings in the shared dsi.ora
or ldap.ora
for that one PDB. Different PDBs can connect to different Active Directory servers for CMU. The dsi.ora
file for an individual PDB is located in the same directory as the wallet for that PDB.
When the WALLET_LOCATION
parameter in the sqlnet.ora
file is set, then the dsi.ora
file for an individual PDB will be in the per-PDB wallet in the WALLET_LOCATION_specified_in_sqlnet.ora/pdb_guid/
directory.
When the WALLET_LOCATION
parameter in the sqlnet.ora
file is not set, then the default wallet location for an individual container in a multitenant database is the $ORACLE_BASE/admin/db_unique_name/pdb_guid/wallet/
directory. For each PDB to use the default wallet location, you must not set WALLET_LOCATION
in sqlnet.ora
.
To find the db_unique_name
, connect to the CDB root and execute the following query:
SELECT DB_UNIQUE_NAME FROM V$DATABASE;
To find the pdb_guid
, from the CDB root, execute the following query:
SELECT PDB_NAME,GUID FROM DBA_PDBS;
How the WALLET_LOCATION Parameter in sqlnet.ora Affects dsi.ora
Setting or not setting the WALLET_LOCATION
parameter in sqlnet.ora
has the following effects:
- If
WALLET_LOCATION
is not set insqlnet.ora
, then you can also placedsi.ora
in the default wallet directory for the CDB root container, located in the$ORACLE_BASE/admin/db_unique_name/wallet
directory. However, this will only connect the CDB root container to the Active Directory, not the entire CDB database. - If
WALLET_LOCATION
is set insqlnet.ora
, then you can place thedsi.ora
in that wallet location, and this will also only connect the CDB root container to the Active Directory, not the entire CDB database.
Changing the Contents of dsi.ora
If you change the contents of dsi.ora
after the database has been started, then you must either restart the database instance or re-execute the following DDL to make the updated content in dsi.ora
effective:
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';
In a multitenant environment, you should set the LDAP_DIRECTORY_ACCESS
parameter in each PDB, not in the CDB root.
Parent topic: Step 4: Create the dsi.ora or ldap.ora File
6.2.2.4.3 Creating the dsi.ora File
The dsi.ora
configuration file sets the information to find the Active Directory servers for centrally managed users.
dsi.ora
configuration file:
- Log in to the host where the Oracle database is located.
- Choose a directory where to use the
dsi.ora
file, based on the search order for thedsi.ora
file. (See Related Topics.) If this directory does not exist, then create the directory. Then go to this directory to create thedsi.ora
file. - Add the following parameters to the
dsi.ora
file:DSI_DIRECTORY_SERVERS
, which sets the Active Directory server host and port number, and alternate directory servers. The directory server name must be a fully qualified name. You can also have multiple Active Directory servers here if you want to use multiple Windows domains. For example:DSI_DIRECTORY_SERVERS = (AD-server.production.examplecorp.com:389:636, sparky.production.examplecorp.com:389:636)
DSI_DEFAULT_ADMIN_CONTEXT
, which sets the search base where the Active Directory users and groups are located. This parameter is optional. By default, Oracle locates Active Directory users and groups in Active Directory's default naming context. Oracle recommends that you do not set this parameter. Set this parameter only if you want to limit the search scope for Active Directory users and groups. For example:DSI_DEFAULT_ADMIN_CONTEXT = "OU=sales,DC=production,DC=examplecorp,DC=com"
DSI_DIRECTORY_SERVER_TYPE
, which determines the Active Directory server access. You must set it toAD
for Active Directory. Enter this value in upper case.DSI_DIRECTORY_SERVER_TYPE = AD
Related Topics
Parent topic: Step 4: Create the dsi.ora or ldap.ora File
6.2.2.4.4 About Using an ldap.ora File
You can use an ldap.ora
file to specify Active Directory servers for centrally managed users.
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, then you must create and use a dsi.ora
file to identify the Active Directory servers for centrally managed users. Even if the database currently is not 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.
If ldap.ora
is being used for naming services, then do not make any changes to ldap.ora
. Only use dsi.ora
to configure CMU-Active Directory.
Benefit of Using ldap.ora
The benefit of using ldap.ora
is that you can use the DBCA graphical interface or the DBCA silent mode to complete configuring the connection to the Active Directory servers. When using dsi.ora
, the steps to complete configuring the connection to Active Directory must be done separately.
Placement of ldap.ora
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
.
Search Order for ldap.ora
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
Changing the Contents of ldap.ora
If you change the contents of ldap.ora
after the database has been started, then you must either restart the database instance or re-execute the following DDL to make the updated content in ldap.ora
effective:
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'PASSWORD';
In a multitenant environment, set the LDAP_DIRECTORY_ACCESS
parameter in each PDB, not in the CDB root.
Parent topic: Step 4: Create the dsi.ora or ldap.ora File
6.2.2.4.5 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.
Related Topics
Parent topic: Step 4: Create the dsi.ora or ldap.ora File
6.2.2.5 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.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.6 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.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.7 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. - 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. - 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 whenldap.ora
is configured for CMU-Active Directory. - Configuring the Access Using Database Configuration Assistant Silent Mode
Assumingldap.ora
(notdsi.ora
) has been created in the correct location and configured properly, DBCA silent mode can create a new database or alter an existing database for the Microsoft Active Directory-Oracle Database integration.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.7.1 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 only recognizes the ldap.ora
that is configured for centrally managed users, and only creates the wallet in the recommended default location. To use the default wallet locations, you must not set WALLET_LOCATION
in sqlnet.ora
.
Note:
Oracle recommends using dsi.ora
for CMU-Active Directory.
6.2.2.7.2 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.
SYSDBA
administrative privilege and check the LDAP parameters settings as follows:show parameter ldap
6.2.2.7.3 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.
ldap.ora
file (not dsi.ora
) to identify the Active Directory servers for the centrally managed users. If you have not installed the database software yet, then you can install the software using Oracle Universal Installer (OUI). After that, use DBCA to create the database, and at the same time you can configure the connection for Active Directory centrally managed users.
6.2.2.7.4 Configuring the Access Using Database Configuration Assistant Silent Mode
Assuming ldap.ora
(not dsi.ora
) has been created in the correct location and configured properly, DBCA silent mode can create a new database or alter an existing database for the Microsoft Active Directory-Oracle Database integration.
Related Topics
6.2.2.8 Step 8: Verify the Oracle Wallet
The orapki
utility can verify that the wallet for this database was created successfully.
Parent topic: Connecting to Microsoft Active Directory
6.2.2.9 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.
Parent topic: Connecting to Microsoft Active Directory
6.3 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 generate and store Oracle Database password verifiers on Active Directory. - 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. - 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.
6.3.1 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 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.
Parent topic: Configuring Authentication for Centrally Managed Users
6.3.1.1 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.
For Active Directory users to log in Oracle database with administrative privileges, you must also set a password file with Oracle database.
For password authentication, because Oracle Database does not pass Active Directory users' passwords through the ldapbind
command to authenticate 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 his or her Active Directory password.
To maintain backward 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). If an Active Directory user no long needs to log in to Oracle databases, in order to clear the Oracle password verifiers generated for the Active Directory user, remove the user from any ORA_VFR
groups, and reset the password (or require password change) for this user. You can also manually clear the orclCommonAttribute
attribute for this user. Oracle password verifiers will no longer be generated after the user has been removed from ORA_VFR
groups.
6.3.1.2 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.
6.3.1.3 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.
To log in to a 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
The following connection assumes the Windows domain name is production
:
connect "production\pfitch"@inst1
If the Active Directory user is in the same Active Directory domain as the Oracle Service Directory User Account configured in the database wallet, then an Active Directory user can use this user name (samAccountName
) directly to log on to the database:
sqlplus samAccountName@tnsname_of_database Enter password: password
For example:
connect pfitch@instl
Enter password: password
Alternatively, the user can use their Active Directory Windows user logon name with the DNS domain name.
connect "Active_Directory_user_name@Windows_DNS_domain_name"@tnsname_of_database Password: password
For example:
connect "pfitch@production.examplecorp.com"@inst1
6.3.2 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.
Note:
You do not create database users identified externally as an Active Directory user's Kerberos UPN. Instead, you use global users that are mapped to Active Directory users or groups.6.3.3 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.
Note:
You use an Active Directory user certificate when you configure Secure Sockets Layer Authentication. However, you do not create database users identified externally as the DN of the Active Directory user certificate. Instead, you use global users that are mapped to Active Directory users or groups.Related Topics
Parent topic: Configuring Authentication for Centrally Managed Users
6.4 Configuring Authorization for Centrally Managed Users
With centrally managed users, you can manage the authorization for Active Directory users to access Oracle databases.
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. - 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. - 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 been granted through their login schemas. - Exclusively Mapping a Directory User to a Database Global User
You can map a Microsoft Active Directory user exclusively to an Oracle Database global user. - Altering or Migrating a User Mapping Definition
You can update an Active Directory user to a Database global user mapping by using theALTER USER
statement. - 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. - Verifying the Centrally Managed User Logon Information
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.
6.4.1 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.
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.
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.2 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.
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.
samAccountName
), and enterprise identity (DN) are tracked and audited inside the database.
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.3 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 been granted through their login schemas.
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.4 Exclusively Mapping a Directory User to a Database Global User
You can map a Microsoft Active Directory user exclusively to an Oracle Database global user.
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.
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.5 Altering or Migrating a User Mapping Definition
You can update an Active Directory user to a Database global user mapping by using the ALTER USER
statement.
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 distinguished name (DN).
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.6 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. - Configuring Database Administrative Users Using Exclusive Mapping
Database administrators can also be mapped to exclusive schemas in databases.
Parent topic: Configuring Authorization for Centrally Managed Users
6.4.6.1 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.
ad_dba_backup_users
Active Directory group will be assigned to the new database shared schema with the SYSBACKUP
administrative privilege.
Parent topic: Configuring Administrative Users
6.4.6.2 Configuring Database Administrative Users Using Exclusive Mapping
Database administrators can also be mapped to exclusive schemas in databases.
Parent topic: Configuring Administrative Users
6.4.7 Verifying the Centrally Managed User Logon Information
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.
Parent topic: Configuring Authorization for Centrally Managed Users
6.5 Integration of Oracle Database with Microsoft Active Directory Account Policies
As part of the Oracle Database-Microsoft Active Directory integration, Oracle Database enforces the Active Directory account policies when Active Directory users log into the Oracle database.
Active Directory account policy settings cover the password policy, account lockout policy, and Kerberos policy. Oracle Database enforces all of the account policies for centrally managed users from Active Directory. For example, Oracle prevents Active Directory users with account status, such as password expired
, password must change
, account locked out
, or account disabled
from logging in to the database. If you are using Kerberos authentication, then Oracle prevents Active Directory users with expired Kerberos tickets from logging in the database. If you are using password authentication, then an Active Directory user account will be locked out for a specified period of time on Active Directory after the user makes a specified number of failed attempts consecutively when trying to log in to the Oracle database using incorrect passwords. With enforcing the account lockout policy, Oracle effectively prevents password guessing attacks against Active Directory user accounts.
6.6 Configuring Centrally Managed Users with Oracle Autonomous Database
You can deploy centrally managed users (CMU) on Oracle Autonomous Database.
For instructions on deploying CMU on Oracle Autonomous Database, see "Use Microsoft Active Directory with Autonomous Database" in Using Oracle Autonomous Database on Shared Exadata Infrastructure.
6.7 Troubleshooting Centrally Managed Users
You can find troubleshooting information about the configuration of centrally managed users (CMU) on My Oracle Support.
For troubleshooting information about the CMU configuration for on-premise databases, see "How To Configure Centrally Managed Users For Database Release 18c or Later Releases" (Doc ID 2462012.1) on My Oracle Support.