Utiliser Microsoft Active Directory avec Autonomous Database sur une infrastructure Exadata dédiée

Préalables à la configuration de CMU avec Microsoft Active Directory dans Autonomous Database

Les préalables suivants sont requis pour configurer la connexion d'Autonomous Database à Active Directory :

Microsoft Active Directory doit être installé et configuré. Voir Introduction à AD DS pour plus d'informations.
Vous devez créer un utilisateur de service de répertoire Oracle dans Active Directory. Voir Étape 1 : Créer un compte d'utilisateur Oracle Service Directory dans Microsoft Active Directory et accorder des autorisations dans le guide de sécurité Oracle Database 19c ou le guide de sécurité Oracle Database 23ai pour plus d'informations sur le compte d'utilisateur du répertoire de services Oracle.
Un administrateur système Active Directory doit avoir installé le filtre de mot de passe Oracle sur les serveurs Active Directory et configuré des groupes Active Directory avec des utilisateurs Active Directory selon vos besoins.

Seule l'authentification par mot de passe est prise en charge par CMU pour la base de données autonome. Vous devez donc utiliser l'utilitaire inclus, opwdintg.exe, pour installer le filtre de mot de passe Oracle sur Active Directory, étendre le schéma et créer trois nouveaux groupes ORA_VFR pour trois types de génération de vérificateur de mot de passe. Voir Étape 2 : Pour l'authentification par mot de passe, installez le filtre de mot de passe et étendez le schéma Microsoft Active Directory dans le guide de sécurité Oracle Database 19c ou le guide de sécurité Oracle Database 23ai pour plus d'informations sur l'installation du filtre de mot de passe Oracle.
Les serveurs Active Directory doivent être accessibles à partir d'Autonomous Database par l'Internet public et le port 636 des serveurs Active Directory doit être ouvert à Autonomous Database dans Oracle Cloud Infrastructure, de sorte qu'Autonomous Database puisse avoir un accès LDAP sécurisé par TLS/SSL aux serveurs Active Directory par Internet.

Vous pouvez également étendre votre service Active Directory sur place à Oracle Cloud Infrastructure, ce qui vous permet de configurer des contrôleurs de domaine en lecture seule (RODC) pour Active Directory sur place. Vous pouvez ensuite utiliser ces contrôleurs RODC dans Oracle Cloud Infrastructure pour authentifier et autoriser les utilisateurs d'Active Directory sur place à accéder aux bases de données autonomes.

Pour plus d'informations, voir Étendre l'intégration d'Active Directory dans le nuage hybride.
Vous avez besoin du portefeuille de base de données de configuration CMU, cwallet.sso, et du fichier de configuration CMU, dsi.ora, pour configurer CMU pour la base de données autonome :
- Si vous avez configuré CMU pour une base de données sur place, vous pouvez obtenir ces fichiers de configuration à partir de votre serveur de base de données sur place.
- Si vous n'avez pas configuré CMU pour une base de données sur place, vous devez créer ces fichiers. Vous chargez ensuite les fichiers de configuration dans le nuage pour configurer CMU sur votre instance Autonomous Database. Vous pouvez valider le portefeuille et le fichier dsi.ora en configurant CMU pour une base de données sur place et en vérifiant qu'un utilisateur Active Directory peut se connecter à la base de données sur place avec ces fichiers de configuration. Chargez ensuite ces fichiers de configuration dans le nuage afin de configurer CMU pour votre base de données autonome.
Pour plus de détails sur le fichier de portefeuille pour CMU, voir :
- Étape 6 : Créer le portefeuille pour une connexion sécurisée dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 23ai
- Étape 8 : Vérifier Oracle Wallet dans le guide de sécurité d'Oracle Database 19c et le guide de sécurité d'Oracle Database 23ai.
Pour plus de détails sur le fichier dsi.ora pour CMU, voir Création du fichier dsi.ora dans le guide de sécurité Oracle Database 19c ou le guide de sécurité Oracle Database 23ai.

Pour plus de détails sur la configuration d'Active Directory pour CMU et sur le dépannage de CMU pour les bases de données sur place, voir Comment configurer des utilisateurs gérés de façon centralisée pour les bases de données version 18c ou ultérieures (ID document 2462012.1).

Configurer CMU avec Microsoft Active Directory dans une base de données autonome

Pour configurer la base de données autonome pour la connexion CMU aux serveurs Active Directory :

Connectez-vous à Autonomous Database en tant qu'utilisateur ADMIN.
Vérifiez si un autre modèle d'authentification externe est activé dans votre base de données et désactivez-le.

Note :
Vous pouvez continuer avec la configuration CMU-AD au-dessus de Kerberos pour fournir l'authentification CMU-AD Kerberos aux utilisateurs de Microsoft Active Directory.
Chargez les fichiers de configuration CMU, y compris le fichier de portefeuille de base de données, cwallet.sso, et le fichier de configuration CMU, dsi.ora, dans votre magasin d'objets. Cette étape dépend du magasin d'objets que vous utilisez.

Le fichier de configuration dsi.ora contient les informations permettant de trouver les serveurs Active Directory.

Si vous utilisez le magasin d'objets Oracle Cloud Infrastructure, voir Ajout de données dans le stockage d'objets pour plus de détails sur le chargement de fichiers.
Dans Autonomous Database, créez un nouvel objet de répertoire ou sélectionnez un objet de répertoire existant. Il s'agit du répertoire dans lequel vous stockez le portefeuille et le fichier de configuration pour la connexion à Active Directory :
Par exemple :
```
CREATE OR REPLACE DIRECTORY cmu_wallet_dir AS 'cmu_wallet';
```
Utilisez l'énoncé SQL suivant pour interroger le chemin de répertoire du système de fichiers de l'objet de répertoire :
```
SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE 
   DIRECTORY_NAME='directory_object_name';
```
Par exemple :
```
SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE 
   DIRECTORY_NAME='CMU_WALLET_DIR';


DIRECTORY_PATH
----------------------------------------------------------------------------
/file_system_directory_path_example/cmu_wallet
```
Note :
Le nom de l'objet de répertoire dans l'interrogation doit être en majuscules car sa casse n'a pas été conservée lors de la création de l'objet de répertoire.
Si vous voulez conserver la casse pour le nom de l'objet répertoire, vous devez inclure son nom entre guillemets doubles. Par exemple :
```
CREATE OR REPLACE DIRECTORY "CMU_wallet_dir" AS 'cmu_wallet';
```
Utilisez DBMS_CLOUD.GET_OBJECT pour copier les fichiers de configuration CMU, le portefeuille de base de données cwallet.sso et dsi.ora, depuis votre magasin d'objets vers le répertoire que vous avez créé ou sélectionné à l'étape 4 ci-dessus.
Par exemple, utilisez DBMS_CLOUD.GET_OBJECT pour copier les fichiers du magasin d'objets vers CMU_WALLET_DIR comme suit :
```
BEGIN
   DBMS_CLOUD.GET_OBJECT(
      credential_name => 'DEF_CRED_NAME',
      object_uri => 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o/cwallet.sso',
      directory_name => 'CMU_WALLET_DIR');
   DBMS_CLOUD.GET_OBJECT(
      credential_name => 'DEF_CRED_NAME',
      object_uri => 'https://objectstorage.us-phoenix-1.oraclecloud.com/n/namespace-string/b/bucketname/o/dsi.ora',
      directory_name => 'CMU_WALLET_DIR');
END;
/
```
Dans cet exemple, namespace-string est l'espace de noms du stockage d'objets pour Oracle Cloud Infrastructure et bucketname est le nom du seau. Pour plus d'informations, voir Présentation des espaces de noms du stockage d'objets.
Voir Procédure GET_OBJECT pour plus d'informations.
Utilisez l'énoncé SQL suivant pour interroger les fichiers copiés dans le répertoire.
```
SELECT * FROM DBMS_CLOUD.LIST_FILES('directory_object_name');
```
Par exemple :
```
SELECT * FROM DBMS_CLOUD.LIST_FILES('CMU_WALLET_DIR');
```
Notez que le nom de l'objet de répertoire dans cette interrogation doit être en majuscules car sa casse n'a pas été conservée lors de la création de l'objet de répertoire.
Activez CMU-AD dans Autonomous Database à l'aide de l'ensemble DBMS_CLOUD_ADMIN.
Note :
Remplacez les noms de répertoire dans l'exemple ci-dessous par ceux choisis pour votre environnement. Assurez-vous d'être connecté en tant qu'utilisateur ADMIN avant d'exécuter cette commande.
```
BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
    type     => 'CMU',
    params   => JSON_OBJECT('directory_name' value 'CMU_WALLET_DIR')
  ); 
END;
/ 
```
Pour assurer la sécurité, supprimez du magasin d'objets les fichiers de configuration CMU, y compris le portefeuille de base de données cwallet.sso et le fichier de configuration CMU dsi.ora. Vous pouvez utiliser les méthodes du magasin d'objets local pour supprimer ces fichiers ou utiliser DBMS_CLOUD.DELETE_OBJECT pour supprimer les fichiers du magasin d'objets.
Voir Procédure DELETE_OBJECT pour plus d'informations sur DBMS_CLOUD.DELETE_OBJECT.

Note :

Voir Désactiver l'accès à Active Directory dans Autonomous Database pour obtenir des instructions sur la désactivation de l'accès d'Autonomous Database à Active Directory.

Pour plus d'informations, voir Configuration d'utilisateurs gérés de manière centralisée avec Microsoft Active Directory dans le guide de sécurité Oracle Database 19c ou le guide de sécurité Oracle Database 19c.

Configurer CMU avec Microsoft Active Directory sur Exadata Cloud@Customer

S'APPLIQUE À : Exadata Cloud@Customer seulement

Pour configurer Autonomous Database sur Exadata Cloud@Customer pour que CMU se connecte aux serveurs Active Directory, sans utiliser le service Oracle Object Store :

Connectez-vous à Autonomous Database en tant qu'utilisateur ADMIN.
Vérifiez si un autre modèle d'authentification externe est activé dans votre base de données et désactivez-le à l'aide de la commande SQL suivante.
```
BEGIN
  DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
END;
/
```
CMU-AD a besoin de votre portefeuille de connexions Active Directory cwallet.sso et des fichiers dsi.ora sur un système de fichiers local dans votre grappe de machines virtuelles Exadata autonome (AVMC). Pour ce faire, hébergez ces fichiers dans le service de magasin d'objets Oracle sur Oracle Cloud Infrastructure, puis copiez-les localement à l'aide de l'ensemble DBMS_CLOUD. Vous trouverez ce processus avec des étapes détaillées et des exemples dans Configurer CMU avec Microsoft Active Directory dans Autonomous Database.
Si l'hébergement de cwallet.sso et de dsi.ora dans le stockage en nuage n'est pas possible, vous pouvez utiliser un partage de système de fichiers réseau (NFS) dans votre centre de données pour héberger ces fichiers, puis les déplacer vers un répertoire de base de données sous le système de fichiers de base de données (DBFS). Pour ce faire, vous devez d'abord attacher un partage NFS disponible localement à l'objet de répertoire Autonomous Database, comme indiqué ci-dessous :
1. Créez un répertoire de base de données dans votre instance Autonomous Database à l'aide de la commande SQL suivante à partir de votre client SQL :
```
create or replace directory TMPFSSDIR as 'tmpfssdir';
```
2. Montez votre partage NFS dans ce répertoire à l'aide de l'ensemble DBMS_CLOUD_ADMIN disponible dans Autonomous Database.
  
  Conseil :
  Vous devrez peut-être travailler avec votre administrateur de réseau ou de stockage pour rendre un partage NFS disponible.
```
BEGIN
  DBMS_CLOUD_ADMIN.attach_file_system(
    file_system_name => <some_name_you_assign>,
    file_system_location => <your_nfs_fs_path>,
    directory_name => <tmpfssdir_created_above>,
    description => ‘Any_desc_you_like_to_give’
  );
END
```
  Par exemple :
```
BEGIN 
  DBMS_CLOUD_ADMIN.attach_file_system(
    file_system_name => 'AD-FSS',
    file_system_location => acme.com:/nfs/mount1',
    directory_name => 'TMPFSSDIR',
    description => ‘nfs to host AD files’
  );
END;
```
Pour éviter une dépendance au partage NFS pour que les fichiers cwallet.sso et dsi.ora soient disponibles pour CMU, déplacez-les vers un dossier de système de fichiers local à l'aide d'un mappage de répertoire de base de données. Comme Autonomous Database restreint l'accès au système de fichiers local, créez une procédure de copie à l'aide de utl_file, comme indiqué ci-dessous :
1. Créez un répertoire de base de données dans votre instance Autonomous Database à l'aide de la commande SQL suivante à partir de votre client SQL :
```
CREATE OR REPLACE DIRECTORY cmu_wallet_dir AS 'cmu_wallet';
```
2. Vérifiez le chemin d'accès au répertoire créé ci-dessus à l'aide de la commande SQL suivante :
```
SELECT DIRECTORY_PATH 
FROM DBA_DIRECTORIES 
WHERE DIRECTORY_NAME ='CMU_WALLET_DIR';
```
  Note :
  Le nom de l'objet de répertoire doit être en majuscules dans l'interrogation, car sa casse n'a pas été conservée lors de la création de l'objet de répertoire.
3. Copiez dsi.ora et cwallet.sso du répertoire NFS dans le répertoire du portefeuille CMU local à l'aide de l'utilitaire UTL_FILE.
  Par exemple :
  Créez une procédure stockée nommée copyfile comme indiqué ci-dessous :
```
CREATE OR REPLACE PROCEDURE copyfile(
  in_loc_dir IN VARCHAR2,
  in_filename IN VARCHAR2,
  out_loc_dir IN VARCHAR2,
  out_filename IN VARCHAR2
)
IS
  in_file UTL_FILE.file_type;
  out_file UTL_FILE.file_type;
  buffer_size CONSTANT INTEGER := 32767;
  buffer RAW (32767);
  buffer_length INTEGER; 
BEGIN
  in_file := UTL_FILE.fopen (in_loc_dir, in_filename, 'rb', buffer_size);
  out_file := UTL_FILE.fopen (out_loc_dir, out_filename, 'wb', buffer_size);
  UTL_FILE.get_raw (in_file, buffer, buffer_size);
  buffer_length := UTL_RAW.LENGTH (buffer);

  WHILE buffer_length > 0
  LOOP 
    UTL_FILE.put_raw (out_file, buffer, TRUE);

    IF buffer_length = buffer_size
      THEN
        UTL_FILE.get_raw (in_file, buffer, buffer_size);
        buffer_length := UTL_RAW.LENGTH (buffer);
      ELSE
        buffer_length := 0;
      END IF;
  END LOOP;

  UTL_FILE.fclose (in_file);
  UTL_FILE.fclose (out_file);
EXCEPTION
  WHEN NO_DATA_FOUND
  THEN
    UTL_FILE.fclose (in_file);
    UTL_FILE.fclose (out_file);
END;
/ 
```
  Compilez la procédure stockée copyfile. Une fois la compilation réussie, exécutez la procédure copyfile une fois chacun pour copier dsi.ora et cwallet.sso du répertoire NFS vers le répertoire du portefeuille CMU local, comme indiqué ci-dessous :
```
EXEC copyfile('TMPFSSDIR','dsi.ora','CMU_WALLET_DIR','dsi.ora');
```
```
EXEC copyfile('TMPFSSDIR','cwallet.sso','CMU_WALLET_DIR','cwallet.sso');
```
4. Exécutez l'interrogation SQL suivante pour valider si les fichiers sont copiés avec succès dans le répertoire du portefeuille CMU local.
```
SELECT * FROM DBMS_CLOUD.LIST_FILES('CMU_WALLET_DIR');
```
A l'aide de la commande suivante, détachez le partage NFS car vous n'en avez pas besoin pour CMU-AD après la copie des fichiers dans le répertoire local.
```
exec DBMS_CLOUD_ADMIN.detach_file_system(file_system_name => <FILE_SYSTEM_NAME>);
```
Activez CMU-AD dans Autonomous Database à l'aide de l'ensemble DBMS_CLOUD_ADMIN.
Note :
Remplacez les noms de répertoire dans l'exemple ci-dessous par ceux choisis pour votre environnement. Assurez-vous d'être connecté en tant qu'utilisateur ADMIN avant d'exécuter cette commande.
```
BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
    type     => 'CMU',
    params   => JSON_OBJECT('directory_name' value 'CMU_WALLET_DIR')
  ); 
END;
/ 
```

Effectuez la validation en interrogeant la valeur de propriété de la propriété de base de données CMU_WALLET, comme indiqué ci-dessous.

SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'CMU_WALLET';

Par exemple :

SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME='CMU_WALLET';

PROPERTY_VALUE
--------------
CMU_WALLET_DIR

Vous avez maintenant configuré CMU-AD pour utiliser l'authentification externe au moyen de Microsoft Active Directory avec Autonomous Database sur Exadata Cloud@Customer.

Ajouter des rôles Microsoft Active Directory dans une base de données autonome

Pour ajouter des rôles Active Directory, mappez les rôles de base de données globaux à des groupes Active Directory à l'aide d'énoncés CREATE ROLE ou ALTER ROLE (en incluant la clause IDENTIFIED GLOBALLY AS).

Pour ajouter des rôles globaux pour les groupes Active Directory dans une base de données autonome :

Connectez-vous en tant qu'utilisateur ADMIN à la base de données configurée pour utiliser Active Directory (l'utilisateur ADMIN dispose des privilèges système CREATE ROLE et ALTER ROLE dont vous avez besoin pour ces étapes).
Définissez l'autorisation de base de données pour les rôles de la base de données autonome à l'aide de l'énoncé CREATE ROLE ou ALTER ROLE. Incluez la clause IDENTIFIED GLOBALLY AS et spécifiez le nom distinctif d'un groupe Active Directory.
Utilisez la syntaxe suivante pour mapper un groupe d'utilisateurs Active Directory à un rôle de base de données global :
```
CREATE ROLE global_role IDENTIFIED GLOBALLY AS 
     'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
```
Par exemple :
```
CREATE ROLE widget_sales_role IDENTIFIED GLOBALLY AS
     'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';
```
Dans cet exemple, tous les membres de widget_sales_group disposent des autorisations du rôle de base de données widget_sales_role lorsqu'ils se connectent à la base de données.
Utilisez des énoncés GRANT pour accorder les privilèges requis ou d'autres rôles au rôle global.
Par exemple :
```
GRANT CREATE SESSION TO WIDGET_SALES_ROLE;
GRANT DWROLE TO WIDGET_SALES_ROLE;
```
DWROLE est un rôle prédéfini disposant de privilèges communs. Voir Gérer les privilèges d'utilisateur de base de données pour plus d'informations sur la définition de privilèges communs pour les utilisateurs d'Autonomous Database.
Pour associer un rôle de base de données existant à un groupe Active Directory, utilisez l'énoncé ALTER ROLE pour modifier le rôle de base de données existant afin de mapper ce rôle à un groupe Active Directory.
Utilisez la syntaxe suivante pour modifier un rôle de base de données existant afin de le mapper à un groupe Active Directory :
```
ALTER ROLE existing_database_role 
   IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
```
Pour créer des mappages de rôles globaux supplémentaires pour d'autres groupes Active Directory, suivez ces étapes pour chaque groupe Active Directory.

Pour plus d'informations sur la configuration des rôles avec Microsoft Active Directory, voir Configuration de l'autorisation pour les utilisateurs gérés de manière centralisée dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 23ai.

Ajouter des utilisateurs Microsoft Active Directory dans une base de données autonome

Pour ajouter des utilisateurs Active Directory pour qu'ils puissent accéder à une base de données Autonomous Database, mappez des utilisateurs de base de données globaux à des groupes ou des utilisateurs Active Directory à l'aide d'énoncés CREATE USER ou ALTER USER (avec la clause IDENTIFIED GLOBALLY AS).

L'intégration des bases de données autonomes avec Active Directory fonctionne en mappant les utilisateurs et les groupes Microsoft Active Directory directement aux utilisateurs et aux rôles globaux de base de données Oracle.

Pour ajouter des utilisateurs globaux pour des groupes ou des utilisateurs Active Directory dans une base de données autonome :

Connectez-vous en tant qu'utilisateur ADMIN à la base de données configurée pour utiliser Active Directory (l'utilisateur ADMIN dispose des privilèges système CREATE USER et ALTER USER requis pour ces étapes).
Définissez l'autorisation de base de données pour les utilisateurs de base de données autonome à l'aide d'énoncés CREATE USER ou ALTER USER et incluez la clause IDENTIFIED GLOBALLY AS, en spécifiant le nom distinctif d'un utilisateur ou d'un groupe Active Directory.
Utilisez la syntaxe suivante pour mapper un utilisateur Active Directory à un utilisateur de base de données global :
```
CREATE USER global_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';
```
Utilisez la syntaxe suivante pour mapper un groupe Active Directory à un utilisateur de base de données global :
```
CREATE USER global_user IDENTIFIED GLOBALLY AS
    'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
```
Par exemple, pour mapper un groupe Active Directory nommé widget_sales_group dans l'unité organisationnelle sales du domaine production.example.com à un utilisateur de base de données global partagé nommé WIDGET_SALES :
```
CREATE USER widget_sales IDENTIFIED GLOBALLY AS
     'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com';
```
Un mappage d'utilisateur global partagé est créé. Ce mappage, avec l'utilisateur global widget_sales, est en vigueur pour tous les utilisateurs du groupe Active Directory. Ainsi, tout membre de widget_sales_group peut se connecter à la base de données à l'aide de ses données d'identification Active Directory (au moyen du mappage partagé de l'utilisateur global widget_sales).
Si vous voulez que les utilisateurs d'Active Directory utilisent un utilisateur de base de données existant, possèdent son schéma et ses données existantes, utilisez ALTER USER pour modifier un utilisateur de base de données existant afin de le mapper à un groupe ou à un utilisateur Active Directory.
- Utilisez la syntaxe suivante pour modifier un utilisateur de base de données existant afin de le mapper à un utilisateur Active Directory :
```
ALTER USER existing_database_user IDENTIFIED GLOBALLY AS 'DN_of_an_AD_USER';
```
- Utilisez la syntaxe suivante pour modifier un utilisateur de base de données existant afin de le mapper à un groupe Active Directory :
```
ALTER USER existing_database_user 
     IDENTIFIED GLOBALLY AS 'DN_of_an_AD_GROUP_of_WHICH_the_AD_USER_IS_a_MEMBER';
```
Pour créer des mappages d'utilisateurs globaux supplémentaires pour d'autres groupes Active Directory, suivez ces étapes pour chaque groupe ou utilisateur Active Directory.

Pour plus d'informations sur la configuration des rôles avec Microsoft Active Directory, voir Configuration de l'autorisation pour les utilisateurs gérés de manière centralisée dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 23ai.

Se connecter à une base de données autonome avec les données d'identification d'un utilisateur Active Directory

Une fois que l'utilisateur ADMIN a exécuté les étapes de configuration de CMU avec Active Directory et créé des rôles et des utilisateurs globaux, les utilisateurs se connectent à Autonomous Database à l'aide de leur nom d'utilisateur et de leur mot de passe Active Directory.

Note :

Ne vous connectez pas avec un nom d'utilisateur global. Les noms d'utilisateur globaux n'ont pas de mot de passe et la connexion avec un nom d'utilisateur global ne peut pas aboutir. Vous devez disposer d'un mappage d'utilisateur global dans votre base de données autonome pour pouvoir vous connecter à la base de données. Vous ne pouvez pas vous connecter à la base de données avec des mappages de rôles globaux uniquement.

Pour vous connecter à Autonomous Database à l'aide d'un nom d'utilisateur et d'un mot de passe Active Directory :
```
CONNECT "AD_DOMAIN\AD_USERNAME"/AD_USER_PASSWORD@TNS_ALIAS_OF_THE_AUTONOMOUS_DATABASE;
```
Par exemple :
```
CONNECT "production\pfitch"/password@adbname_medium;
```
Vous devez inclure des guillemets doubles lorsque le domaine Active Directory est indiqué avec le nom d'utilisateur, comme dans l'exemple suivant : "production\pfitch".

Dans cet exemple, le nom d'utilisateur Active Directory est pfitch dans le domaine production. L'utilisateur Active Directory est membre du groupe widget_sales_group, identifié par son nom distinctif 'CN=widget_sales_group,OU=sales,DC=production,DC=example,DC=com'.

Après avoir configuré CMU avec Active Directory dans Autonomous Database et configuré l'autorisation Active Directory, avec des rôles globaux et des utilisateurs globaux, vous pouvez vous connecter à Autonomous Database à l'aide de l'une des méthodes de connexion décrites dans À propos de la connexion à une base de données Autonomous Database dédiée. Lorsque vous vous connectez, si vous souhaitez utiliser un utilisateur Active Directory, fournissez les données d'identification de ce dernier. Par exemple, entrez un nom d'utilisateur au format "AD_DOMAIN\AD_USERNAME" (les guillemets doubles sont obligatoires) et utilisez votre AD_USER_PASSWORD comme mot de passe.

Vérifier les informations de connexion d'un utilisateur Active Directory avec une base de données autonome

Lorsque les utilisateurs se connectent à Autonomous Database à l'aide de leur nom d'utilisateur et de leur mot de passe Active Directory, vous pouvez vérifier leur activité.

Par exemple, lorsque l'utilisateur pfitch se connecte :

CONNECT "production\pfitch"/password@exampleadb_medium;

Le nom de connexion de l'utilisateur Active Directory (samAccountName) est pfitch, widget_sales_group est le nom du groupe Active Directory et widget_sales est l'utilisateur global d'Autonomous Database.

Une fois pfitch connecté à la base de données, la commande SHOW USER affiche le nom d'utilisateur global :

SHOW USER;

USER is "WIDGET_SALES"

La commande suivante affiche le nom distinctif de l'utilisateur Active Directory :

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

Par exemple, vous pouvez vérifier l'identité d'entreprise de cet utilisateur géré de manière centralisée :

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

La commande suivante affiche la valeur "AD_DOMAIN\AD_USERNAME" :

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

Par exemple, l'identité de l'utilisateur authentifié par Active Directory est saisie et vérifiée lorsque l'utilisateur se connecte à la base de données :

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

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

Pour plus d'informations, voir Vérification des informations de connexion de l'utilisateur géré de manière centralisée dans le guide de sécurité d'Oracle Database 19c ou le guide de sécurité d'Oracle Database 23ai.

Supprimer des utilisateurs et des rôles Active Directory dans une base de données autonome

Pour supprimer des utilisateurs et des rôles Active Directory des bases de données autonomes, utilisez les commandes de base de données standard. Les utilisateurs ou les groupes Active Directory associés mappés à partir des utilisateurs ou des rôles de base de données, ne sont pas supprimés.

Pour supprimer des utilisateurs ou des rôles d'une base de données autonome :

Connectez-vous à la base de données configurée pour utiliser Active Directory en tant qu'utilisateur disposant du privilège système DROP USER ou DROP ROLE.
Supprimez les utilisateurs ou les rôles globaux mappés aux groupes ou aux utilisateurs Active Directory à l'aide de l'énoncé DROP USER ou DROP ROLE.
Pour plus d'informations, voir Supprimer des utilisateurs de base de données.

Désactiver l'accès à Active Directory dans une base de données autonome

Décrit les étapes permettant de supprimer la configuration CMU de la base de données autonome (et de désactiver l'accès LDAP depuis la base de données autonome à Active Directory).

Après avoir configuré votre base de données autonome pour l'accès à Active Directory, vous pouvez désactiver l'accès comme suit :

Connectez-vous à Autonomous Database en tant qu'utilisateur ADMIN.
Utilisez DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION pour désactiver l'authentification CMU.

Note :
Pour exécuter cette procédure, vous devez être connecté en tant qu'utilisateur ADMIN ou disposer du privilège EXECUTE sur DBMS_CLOUD_ADMIN.
Par exemple :
```
BEGIN   
   DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
END;
/
```
Cet exemple désactive l'authentification CMU pour votre instance de base de données autonome.

Voir Procédure DISABLE_EXTERNAL_AUTHENTICATION pour plus d'informations.

Limites avec Microsoft Active Directory dans Autonomous Database

Les limitations suivantes s'appliquent à CMU avec Active Directory sur Autonomous Database :

Seules l'authentification par mot de passe et Kerberos sont prises en charge pour CMU avec Autonomous Database. Lorsque vous utilisez l'authentification CMU avec Autonomous Database, d'autres méthodes d'authentification telles qu'Azure AD, OCI IAM et PKI ne sont pas prises en charge.
Oracle Application Express et Database Actions ne sont pas pris en charge pour les utilisateurs d'Active Directory avec Autonomous Database.