Use Microsoft Active Directory
with Autonomous Database
You
can configure Autonomous Database to
authenticate and authorize Microsoft Active Directory users.
This configuration allows Active Directory users to access Autonomous Database using their Active Directory
credentials including passwords and Kerberos.
Kerberos Authentication for CMU with Microsoft Active Directory You can configure Autonomous Database to use Kerberos authentication for CMU with Microsoft Active Directory users. This configuration allows CMU Active Directory (CMU-AD) users to access an Autonomous Database instance using Kerberos credentials.
Add Microsoft Active Directory Roles on Autonomous Database To add Active Directory roles, map the database global roles to Active Directory groups with CREATE ROLE or ALTER ROLE statements (and include the IDENTIFIED GLOBALLY AS clause).
Add Microsoft Active Directory Users on Autonomous Database To add Active Directory users to access a database, map database global users to Active Directory groups or users with CREATE USER or ALTER USER statements (with IDENTIFIED GLOBALLY AS clause).
Remove Active Directory Users and Roles on Autonomous Database To remove Active Directory users and roles from Autonomous Databases, use standard database commands. This does not remove the related Active Directory users or groups that were mapped from the dropped database users or roles.
Disable Active Directory Access on Autonomous Database Describes the steps to remove the CMU configuration from your Autonomous Database (and disable the LDAP access from your Autonomous Database to Active Directory).
Prerequisites to Configure CMU
with Microsoft Active Directory on Autonomous Database 🔗
You can configure Autonomous Database to authenticate and authorize
Microsoft Active Directory users.
Depending on where the Active Directory servers reside, there are two options
for configuring Autonomous Database with
Centrally Managed Users (CMU) with Microsoft Active Directory:
Active Directory (AD) servers publicly accessible: the Active
Directory servers are accessible from Autonomous Database through the public
internet.
Active Directory (AD) servers reside on a private endpoint: the
Active Directory servers reside on a private endpoint and are not accessible from Autonomous Database through the public internet. For this case, an extra
configuration step is required as shown in last step in Configure CMU with Microsoft Active Directory on Autonomous Database where you set the database property
ROUTE_OUTBOUND_CONNECTIONS.
Note
See Use Azure Active Directory (Azure AD) with Autonomous Database for information on using Azure Active Directory with Autonomous Database. The CMU option supports Microsoft Active Directory servers but does not support the Azure Active Directory service.
The integration of Autonomous Database with Centrally Managed Users (CMU) provides integration with Microsoft
Active Directory. CMU with Active Directory works by mapping Oracle database global
users and global roles to Microsoft Active Directory users and groups.
The following are required prerequisites to configure the connection from
Autonomous Database to Active
Directory:
You must have Microsoft Active Directory installed and configured. See
AD DS Getting Started for
more information.
You must create an Oracle service directory user in Active Directory.
See Connecting to Microsoft Active
Directory for information on the Oracle service directory user
account.
An Active Directory system administrator must have installed Oracle
password filter on the Active Directory servers, and set up Active Directory
groups with Active Directory users to meet your requirements.
If you use password authentication with CMU Active Directory for Autonomous Database, you must use the
included utility opwdintg.exe to install the Oracle password
filter on Active Directory, extend the schema, and create three new
ORA_VFR groups for three types of password verifier
generation. See Connecting to Microsoft Active
Directory for information on installing the Oracle password filter.
You need the CMU configuration database wallet,
cwallet.sso and the CMU configuration file
dsi.ora to configure CMU for your Autonomous Database:
If you have configured CMU for an on-premise database, you can obtain these
configuration files from your on-premise database server.
If you have not configured CMU for an on-premise database, you need to
create these files. Then you upload the configuration files to the cloud to
configure CMU on your Autonomous Database instance. You can validate the wallet and the
dsi.ora by configuring CMU for an on-premise
database and verifying that an Active Directory user can successfully log on
to the on-premise database with these configuration files.
Port 636 of the Active Directory servers must be open to Autonomous Database in Oracle Cloud
Infrastructure. This allows Autonomous Database to
access the Active Directory servers.
When the Active Directory servers are on a public endpoint:
The Active Directory servers must be accessible from Autonomous Database through the public internet.
You can also extend your on-premise Active Directory to Oracle Cloud
Infrastructure where you can set up Read Only Domain Controllers (RODCs) for the
on-premise Active Directory. This allows you to use the RODCs in Oracle Cloud
Infrastructure to authenticate and authorize on-premise Active Directory users for
access to Autonomous Databases.
Upload the CMU configuration files, including the database wallet file, cwallet.sso and the CMU configuration file, dsi.ora to your Object Store. This step depends on the Object Store you use.
The dsi.ora configuration file contains the information to find the Active Directory servers.
Run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION procedure and pass in a location URI with the params JSON argument. You must place the configuration files cwallet.sso and dsi.ora in the Object Storage location specified in the location_uri parameter.
For example:
BEGIN
DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
type => 'CMU',
params => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
'credential_name' value 'my_credential_name')
);
END;
/
Oracle recommends that you store the CMU configuration files in a private bucket
in your Object Store.
In this example, namespace-string is the Oracle
Cloud Infrastructure object storage namespace and
bucketname is the bucket
name. See Understanding
Object Storage Namespaces for more
information.
The credential_name you use in this step is the credentials to access the Object Store.
If the location_uri is a pre-authenticated URL or a pre-signed URL, then supplying a credential_name is not required.
The procedure creates a directory object named CMU_WALLET_DIR in your database and copies the CMU configuration files from the Object Store location to the directory object. This procedure also sets the database property CMU_WALLET to the value 'CMU_WALLET_DIR' and sets the LDAP_DIRECTORY_ACCESS parameter value to the value PASSWORD to enable access from the Autonomous Database instance to Active Directory.
After you enable CMU authentication, remove the CMU configuration files including the database wallet cwallet.sso and the CMU configuration file dsi.ora from Object Store. You can use local Object Store methods to remove these files or use DBMS_CLOUD.DELETE_OBJECT to delete the files from Object Store.
When Active Directory servers are on a private endpoint, perform additional
configuration steps to provide access to the private endpoint.
Set the database property ROUTE_OUTBOUND_CONNECTIONS to the
value 'PRIVATE_ENDPOINT'.
Validate that the CMU-AD configuration file dsi.ora
includes host names. When ROUTE_OUTBOUND_CONNECTIONS is set to
'PRIVATE_TARGET', IP addresses cannot be specified in
dsi.ora.
Note for CMU with Active Directory on Autonomous Database:
Only "password authentication" and Kerberos are supported for CMU
with Autonomous Database. When you are
using CMU authentication with Autonomous Database, other CMU authentication methods such as PKI are not
supported.
Kerberos Authentication for CMU with
Microsoft Active Directory 🔗
You can configure Autonomous Database to use
Kerberos authentication for CMU with Microsoft Active Directory users. This
configuration allows CMU Active Directory (CMU-AD) users to access an Autonomous Database instance
using Kerberos credentials.
Kerberos can be configured with or without CMU-AD. Just
configuring Kerberos requires you to create and maintain a database
user for every Kerberos user. Configuring Kerberos with CMU allows
you to map an Active Directory group of Kerberos users to a single
database user, shared schema, so database access can be controlled
by Active Directory group membership. See Configure Kerberos Authentication with Autonomous Database for details on configuring Kerberos without CMU-AD.
Note
When implementing both
the Kerberos authentication and CMU-AD for authorization, Oracle
recommends implementing Kerberos authentication first, and then
adding CMU-AD authorization.
Enable Kerberos in your Autonomous Database instance using Microsoft
Active Directory Kerberos server.
Only Microsoft Active Directory Kerberos
servers are supported for Kerberos when you
configure Kerberos authentication with CMU-AD.
To enable Kerberos authentication for your Autonomous Database, you must obtain the Kerberos
configuration files: krb.conf
and the service key table file
v5srvtab.
To generate these files when you configure
Kerberos authentication with CMU-AD you need the
server host name. You can obtain the value of the
server host from the attribute
PUBLIC_DOMAIN_NAME in the
CLOUD_IDENTITY column of
V$PDBS. This value is different
from the Fully Qualified Domain Name (FQDN) for a
database on a private endpoint.
Use the following command to obtain
the server host name:
SELECT guid ||'/'|| json_value(cloud_identity, '$.PUBLIC_DOMAIN_NAME')
"KSERVICE/KINSTANCE" FROM v$pdbs;
You can use a command such as the following to
generate the service key table file:
Run DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION
to enable Kerberos external authentication.
For example:
BEGIN
DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
type => 'KERBEROS',
params => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
'credential_name' value 'my_credential_name')
);
END;
/
Note
Oracle recommends that you store the Kerberos
configuration files in a private bucket in your
Object Store.
In this example, namespace-string is the Oracle
Cloud Infrastructure object storage namespace and
bucketname is the bucket
name. See Understanding
Object Storage Namespaces for more
information.
The
credential_name you use in this
step is the credentials for the Object Store.
SELECT property_value FROM database_properties
WHERE property_name='KERBEROS_DIRECTORY';
Enable and configure CMU-AD on Autonomous Database.
Upload the CMU configuration files, including
the database wallet file,
cwallet.sso and the CMU
configuration file, dsi.ora to
your Object Store.
You upload the cwallet.sso so
that the CMU-AD configuration has the credentials
for the Autonomous Database instance to connect to
the Active Directory service account.
The dsi.ora
configuration file contains the information to
find the Active Directory servers.
This step differs depending on the
Object Store you use.
Run the DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION
procedure and pass in a location URI with the
params JSON argument. You must
place the configuration files
cwallet.sso and
dsi.ora in the Object Storage
location specified in the
location_uri parameter.
For example:
BEGIN
DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
type => 'CMU',
params => JSON_OBJECT('location_uri' value 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o',
'credential_name' value 'my_credential_name')
);
END;
/
Oracle recommends that you store
the CMU configuration files in a private bucket in
your Object Store.
In this example, namespace-string is the Oracle
Cloud Infrastructure object storage namespace and
bucketname is the bucket
name. See Understanding
Object Storage Namespaces for more
information.
The
credential_name you use in this
step is the credentials to access the Object
Store.
Adding or removing Active Directory users is supported,
in the same manner as with CMU with Active Directory
when you are using password authentication. See
Add Microsoft Active Directory Users on Autonomous Database for more information.
The existing restrictions about authenticating against
the Autonomous Database Built-in Tools with CMU with Active
Directory password also apply to CMU with Active
Directory with Kerberos authentication. See Tools Restrictions with Active Directory on Autonomous Database for more information.
Use DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION
to disable CMU-AD with Kerberos authentication. See
DISABLE_EXTERNAL_AUTHENTICATION Procedure for more information.
When the CMU-AD servers are on a private
endpoint, to use CMU-AD with Kerberos authentication
the server host name used for generating the key tab
must be set to the value of attribute
PUBLIC_DOMAIN_NAME in the
CLOUD_IDENTITY column of
V$PDBS. This value is different
from the FQDN for a private endpoint database.
Add Microsoft Active Directory
Roles on Autonomous Database 🔗
To add Active Directory roles, map the
database global roles to Active Directory groups with CREATE ROLE or
ALTER ROLE statements (and include the IDENTIFIED GLOBALLY
AS clause).
To add global roles for Active Directory groups on Autonomous Database:
Log in as the ADMIN user to the database that is
configured to use Active Directory (the ADMIN user
has the CREATE ROLE and ALTER ROLE system
privileges that you need for these steps).
Set the database authorization for Autonomous Database roles with CREATE ROLE or ALTER
ROLE statement. Include the IDENTIFIED GLOBALLY AS
clause and specify the DN of an Active Directory group.
Use the following syntax to map a directory user group to a database
global role:
CREATE ROLE global_role IDENTIFIED GLOBALLY AS
'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
For example:
CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';
In this example all members of the widget_sales_group
are authorized with the database role widget_sales_role when they
log in to the database.
Use GRANT statements to grant the required privileges or other
roles to the global role.
For example:
GRANT CREATE SESSION TO WIDGET_SALES_ROLE;
GRANT DWROLE TO WIDGET_SALES_ROLE;
If you want to make an existing database role to be associated with an Active
Directory group, then use ALTER ROLE statement to alter the existing
database role to map the role to an Active Directory group.
Use the following syntax to alter an existing database role to map it
to an Active Directory group:
ALTER ROLE existing_database_role
IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
If you want to create additional global role mappings for other Active Directory
groups, follow these steps for each Active Directory group.
Add Microsoft Active Directory
Users on Autonomous Database 🔗
To add Active Directory users to access a database, map database global
users to Active Directory groups or users with CREATE USER or ALTER
USER statements (with IDENTIFIED GLOBALLY AS clause).
The integration of Autonomous Database with Active Directory works by mapping Microsoft Active Directory users
and groups directly to Oracle database global users and global roles.
To add global users for Active Directory groups or users on Autonomous Database:
Log in as the ADMIN user to the database that is
configured to use Active Directory (the ADMIN user
has the required CREATE USER and ALTER USER system
privileges that you need for these steps).
Set database authorization for Autonomous Database users with CREATE USER or ALTER
USER statements and include the IDENTIFIED GLOBALLY AS
clause, specifying the DN of an Active Directory user or group.
Use the following syntax to map a directory user to a database global
user:
CREATE USER global_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';
Use the following syntax to map a directory group to a database global
user:
CREATE USER global_user IDENTIFIED GLOBALLY AS
'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
For example, to map a directory group named
widget_sales_group in the sales organization
unit of the production.example.com domain to a shared database
global user named WIDGET_SALES:
CREATE USER widget_sales IDENTIFIED GLOBALLY AS
'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';
This creates a shared global user mapping. The mapping, with global
user widget_sales, is effective for all users in the Active
Directory group. Thus, anyone in the widget_sales_group can log
in to the database using their Active Directory credentials (through the shared
mapping of the widget_sales global user).
If you want Active Directory users to use an existing database user, own its
schema, and own its existing data, then use ALTER USER to alter an
existing database user to map the user to an Active Directory group or user.
Use the following syntax to alter an existing database user to
map it to an Active Directory user:
ALTER USER existing_database_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';
Use the following syntax to alter an existing database user to
map it to an Active Directory group:
ALTER USER existing_database_user
IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
If you want to create additional global user mappings for other Active Directory
groups or users, follow these steps for each Active Directory group or user.
Tools Restrictions with Active
Directory on Autonomous Database 🔗
Notes for using Autonomous Database tools with
Active Directory:
Oracle APEX is not supported for Active Directory users with Autonomous Database. See Create Oracle APEX Workspaces in Autonomous Database for information on using regular database users with Autonomous Database.
Database Actions is not supported for Active Directory users with Autonomous Database. See Provide Database Actions Access to Database Users for information on using regular database users with Autonomous Database.
Connect to Autonomous Database with Active Directory User
Credentials
🔗
After the ADMIN user completes the CMU Active Directory configuration steps and creates global
roles and global users, users log in to the database using their Active Directory username and password.
Note
Do not log in using a Global User
name. Global User names do not have a password and connecting with a Global User name
will not be successful. You must have a global user mapping in your Autonomous Database in order to log in to the
database. You cannot log in to the database with only global role mappings.
To log in to the database
using an Active Directory username and password, connect as follows:
You need to include double quotes when the Active Directory domain is included
along with the username, as with this example:
"production\pfitch".
In this example, the Active Directory username is
pfitch in domain production. The Active
Directory user is a member of widget_sales_group group which is
identified by its DN
'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com'.
After configuring CMU with Active Directory on Autonomous Database and setting up Active Directory authorization, with global roles and global users, you can connect to your database using any of the connection methods described in Connect to Autonomous Database. When you connect, if you want to use an Active Directory user then use Active Directory user credentials. For example, provide a username in this form, "AD_DOMAIN\AD_USERNAME" (double quotes must be included), and use your AD_USER_PASSWORD for the password.
If your Autonomous Database instance is in Restricted
Mode, this mode only allows users with the RESTRICTED SESSION privilege
to connect to the database. The ADMIN user has this privilege. You can use restricted
access mode to perform administrative tasks such as indexing, data loads, or other
planned activities. See Change Autonomous Database Operation Mode to Read/Write Read-Only or Restricted for more information.
The Active Directory user's log on username (samAccountName) is
pfitch and widget_sales_group is the Active
Directory Group name, and widget_sales is the database global user.
After pfitch logs in to the database, the command SHOW
USER shows the global user name:
SHOW USER;
USER is "WIDGET_SALES"
The following command shows the DN (Distinguished Name) of the Active
Directory user:
SELECT SYS_CONTEXT('USERENV', 'ENTERPRISE_IDENTITY') FROM DUAL;
For example you can verify this centrally managed user's enterprise
identity:
SQL> SELECT SYS_CONTEXT('USERENV', 'ENTERPRISE_IDENTITY') FROM DUAL;
SYS_CONTEXT('USERENV','ENTERPRISE_IDENTITY')
----------------------------------------------------------------------
cn=Peter Fitch,ou=sales,dc=production,dc=examplecorp,dc=com
The following command shows the
"AD_DOMAIN\AD_USERNAME":
SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') FROM DUAL;
For example, the Active Directory authenticated user identity is captured
and audited when the user logs on to the database:
SQL> SELECT SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') FROM DUAL;
SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY')
----------------------------------------------------------------------
production\pfitch
Remove Active Directory Users and
Roles on Autonomous Database 🔗
To remove Active Directory users and roles
from Autonomous Databases, use standard database
commands. This does not remove the related Active Directory users or groups that were mapped
from the dropped database users or roles.
To remove users or roles from Autonomous Database:
Log in to the database that is configured to use Active Directory as a user who has
been granted the DROP USER or DROP ROLE system
privilege.
Drop the global users or the global roles that are mapped to Active Directory
groups or users with DROP USER or DROP ROLE
statement.
Disable Active Directory Access
on Autonomous Database 🔗
Describes the
steps to remove the CMU configuration from your Autonomous Database (and disable the LDAP access from your Autonomous Database to Active Directory).
After you configure your Autonomous Database instance to access CMU Active Directory, you can disable the access as
follows:
Connect to the Autonomous Database as the ADMIN user.
Use the DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION to disable CMU authentication.
Note
To run this procedure you must be logged in as ADMIN user or have the EXECUTE privilege on DBMS_CLOUD_ADMIN.
For example:
BEGIN
DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
END;
/
This disables CMU authentication on your Autonomous Database instance.