Authentification et autorisation des utilisateurs Microsoft Azure Active Directory pour Autonomous Database

A propos de l'intégration d'Oracle Autonomous Database on Dedicated Exadata Infrastructure à Microsoft Azure AD

Oracle Autonomous Database on Dedicated Exadata Infrastructure et Microsoft Azure AD peuvent être configurés pour permettre aux utilisateurs et aux applications de se connecter à la base de données à l'aide de leurs informations d'identification Azure AD.

Les utilisateurs et les applications Azure AD peuvent se connecter avec les informations d'identification SSO (accès avec connexion unique) Azure AD pour accéder à la base de données. Cette opération est effectuée avec un jeton d'accès OAuth2 Azure AD que l'utilisateur ou l'application demande en premier à partir d'Azure AD. Ce jeton d'accès OAuth2 contient les informations d'identité utilisateur et d'accès à la base de données, puis est envoyé à la base de données. Reportez-vous à l'article Microsoft Options d'authentification sans mot de passe pour Azure Active Directory pour plus d'informations sur la configuration de l'authentification à plusieurs facteurs et sans mot de passe.

Vous pouvez effectuer cette intégration dans les environnements Oracle Database suivants :

Oracle Database sur site versions 19.18 et ultérieures
Oracle Autonomous Database on Shared Exadata Infrastructure
Oracle Autonomous Database sur une infrastructure Exadata dédiée
Oracle Base Database Service
Oracle Exadata Cloud Service (Oracle ExaCS)

Les instructions de configuration d'Azure AD utilisent le terme "Oracle Database" pour englober ces environnements.

Ce type d'intégration permet à un utilisateur Azure AD d'accéder à une instance Oracle Autonomous Database on Dedicated Exadata Infrastructure. Les utilisateurs et les applications Azure AD peuvent se connecter avec les informations d'identification SSO (accès avec connexion unique) Azure AD pour obtenir un jeton d'accès OAuth2 Azure AD à envoyer à la base de données.

L'administrateur Azure AD crée et inscrit Oracle Autonomous Database on Dedicated Exadata Infrastructure auprès d'Azure AD. Dans Azure AD, il s'agit d'une inscription d'application, qui est courte pour l'inscription d'application. Il s'agit des informations numériques qu'Azure AD doit connaître sur le logiciel qui utilise Azure AD. L'administrateur Azure AD crée également des rôles d'application pour l'inscription de l'application de base de données dans Azure AD. Les rôles d'application connectent les utilisateurs, les groupes et les applications Azure aux schémas et aux rôles de base de données. L'administrateur Azure AD affecte des utilisateurs, des groupes ou des applications Azure AD aux rôles d'application. Ces rôles d'application sont mis en correspondance avec un schéma global de base de données ou un rôle global, ou avec un schéma et un rôle. Un utilisateur, un groupe ou une application Azure AD affecté à un rôle d'application sera mis en correspondance avec un schéma global de base de données, un rôle global ou à la fois avec un schéma et un rôle. Un schéma global Oracle peut également être mis en correspondance exclusivement avec un utilisateur Azure AD. Un utilisateur invité Azure AD (non-utilisateur d'organisation) ou un principal de service Azure AD (application) peut uniquement être mis en correspondance avec un schéma global de base de données via un rôle d'application Azure AD. Un rôle global Oracle peut uniquement être mis en correspondance à partir d'un rôle d'application Azure et ne peut pas être mis en correspondance à partir d'un utilisateur Azure.

Les outils Oracle Autonomous Database on Dedicated Exadata Infrastructure, notamment Oracle APEX, Database Actions, Oracle Graph Studio et l'API Oracle Database pour MongoDB, ne sont pas compatibles avec l'utilisation de jetons Azure AD pour la connexion à la base de données.

Les outils et applications mis à jour pour prendre en charge les jetons Azure AD peuvent authentifier les utilisateurs directement avec Azure AD et transmettre le jeton d'accès à la base de données à l'instance Oracle Autonomous Database on Dedicated Exadata Infrastructure. Vous pouvez configurer des outils de base de données existants tels que SQL*Plus pour utiliser un jeton Azure AD à partir d'un emplacement de fichier. Dans ce cas, les jetons Azure AD peuvent être extraits à l'aide d'outils tels que Microsoft PowerShell ou l'interface de ligne de commande Azure, puis placés dans un emplacement de fichier. Les jetons d'accès à la base de données OAuth2 Azure AD sont émis avec un délai d'expiration. Le pilote client Oracle Database vérifie que le jeton est dans un format valide et qu'il n'a pas expiré avant de le transmettre à la base de données. La portée du jeton est définie sur la base de données, ce qui signifie qu'il contient des informations sur la base de données dans laquelle le jeton sera utilisé. Les rôles d'application auxquels le principal Azure AD a été affecté dans l'inscription d'application Azure AD de base de données sont inclus dans le jeton d'accès. L'emplacement du répertoire du jeton Azure AD doit disposer des droits d'accès suffisants pour que l'utilisateur puisse écrire le fichier de jeton dans l'emplacement et que le client de base de données puisse extraire ces fichiers (par exemple, l'utilisateur doit simplement disposer des droits d'accès en lecture et en écriture). Etant donné que le jeton autorise l'accès à la base de données, il doit être protégé dans le système de fichiers.

Les utilisateurs Azure AD peuvent demander un jeton à Azure AD en utilisant un certain nombre de méthodes pour ouvrir une fenêtre de connexion Azure afin de saisir leurs informations d'identification Azure AD.

Oracle Autonomous Database on Dedicated Exadata Infrastructure accepte les jetons représentant les principaux Azure AD suivants :

un utilisateur Azure AD, inscrit dans la location Azure AD ;
un utilisateur invité, inscrit en tant qu'utilisateur invité dans la location Azure AD ;
un service, soit l'application inscrite se connectant à la base de données en son nom avec le flux d'informations d'identification client (cas d'emploi de pool de connexions).

Oracle Autonomous Database on Dedicated Exadata Infrastructure prend en charge les flux d'authentification Azure AD suivants :

Code d'autorisation, le plus souvent utilisé par les utilisateurs humains (et non par les applications) pour s'authentifier auprès d'Azure AD dans un environnement client avec un navigateur
Les informations d'identification client, destinées aux applications de base de données qui se connectent en leur nom (et non en tant qu'utilisateur final).
l'authentification OBO (au nom de), soit quand une application demande un jeton d'accès au nom d'un utilisateur connecté pour l'envoyer à la base de données.
Informations d'identification de mot de passe de propriétaire de ressource (ROPC), qui ne sont pas recommandées pour une utilisation en production, mais peuvent être utilisées dans des environnements de test où une authentification utilisateur de navigateur instantanée serait difficile à intégrer. ROPC a besoin du nom utilisateur et des informations d'identification de mot de passe Azure AD pour faire partie de l'appel de demande de jeton.

Architecture de l'intégration de Microsoft Azure AD à Autonomous Database

Les jetons Microsoft Azure Active Directory respectent la norme OAuth2 avec des extensions. L'utilisation d'un jeton Azure AD pour accéder à une base de données Oracle est semblable à l'utilisation de jetons OCI IAM. Pour obtenir une explication détaillée, reportez-vous à Architecture de l'intégration de Microsoft Azure AD avec Oracle Database dans le guide de sécurité.

Mise en correspondance des utilisateurs Azure AD avec Autonomous Database

Les utilisateurs Microsoft Azure doivent être mis en correspondance avec un schéma Autonomous Database et disposer des privilèges nécessaires (via des rôles) pour pouvoir vous authentifier auprès de l'instance Autonomous Database. Pour plus d'informations sur les différentes façons de mettre en correspondance des utilisateurs, des groupes et des applications dans Microsoft Azure, reportez-vous à Mise en correspondance d'utilisateurs Azure AD avec Oracle Database dans le guide de sécurité.

Cas d'emploi de la connexion à Autonomous Database à l'aide d'Azure AD

Oracle Database prend en charge trois types de cas d'emploi de la connexion à une instance Autonomous Database à l'aide de Microsoft Azure Active Directory. Pour plus de détails, reportez-vous à Cas d'emploi de la connexion à Oracle Database à l'aide d'Azure AD.

Processus général de l'authentification des identités Microsoft Azure AD avec Oracle Autonomous Database on Dedicated Exadata Infrastructure

L'administrateur Oracle Database et l'administrateur Microsoft Azure AD jouent des rôles pour permettre aux utilisateurs Azure AD de se connecter à la base de données à l'aide de jetons d'accès OAuth2 Azure AD.

Le processus général est le suivant :

L'administrateur Oracle Database s'assure que l'environnement Oracle Database répond aux exigences de l'intégration de Microsoft Azure AD. Reportez-vous à Exigences d'Oracle Database pour l'intégration de Microsoft Azure AD.
L'administrateur Azure AD crée une inscription d'application Azure AD pour la base de données et l'administrateur Oracle Database permet à la base de données d'utiliser des jetons Azure AD pour l'accès à la base de données.
Dans le cadre du processus d'inscription à l'application, l'administrateur Azure AD crée des rôles d'application Azure à utiliser pour les mises en correspondance entre les utilisateurs, les groupes et les applications Azure avec les rôles et les schémas Oracle Database.
L'administrateur Oracle Database crée des schémas globaux et les met en correspondance avec un utilisateur Azure AD (mise en correspondance de schéma exclusive) ou avec un rôle d'application Azure (mise en correspondance de schéma partagée). L'application ou l'utilisateur Azure AD doit être mis en correspondance avec un schéma.
L'administrateur Oracle peut éventuellement créer des rôles Oracle Database globaux et les mettre en correspondance avec des rôles d'application Azure.
L'utilisateur final Azure AD qui veut se connecter à l'instance Oracle Autonomous Database on Dedicated Exadata Infrastructure inscrit l'application client en tant que client Azure AD (semblable à l'inscription de la base de données Oracle).
Le client Azure AD dispose d'une identification client et d'une clé secrète de client, sauf si le client d'application est public. Si le client d'application est public, seule l'identification du client d'application est nécessaire.
L'utilisateur final Azure AD (qui peut être un administrateur de base de données) se connecte à l'aide d'un utilitaire tel que PowerShell ou l'interface de ligne de commande Azure pour extraire le jeton d'accès à la base de données OAuth2 et le stocker dans un répertoire de fichiers local. Une application peut également demander un jeton d'accès OAuth2 Azure AD directement à partir d'Azure AD et le transmettre via une API client de base de données. Pour plus d'informations sur la transmission de jetons OAuth2 Azure AD, reportez-vous à la documentation du client Oracle Database suivante :
- Clients légers JDBC : Guide du développeur Oracle Database JDBC
- Oracle Call Interface (OCI) : Guide du programmeur Oracle Call Interface
- Oracle Data Provider for .NET (ODP) : Guide du développeur Oracle Data Provider for .NET pour Microsoft Windows, Connexion à Oracle Database
Une fois connecté à l'instance Oracle Autonomous Database on Dedicated Exadata Infrastructure, l'utilisateur final Azure AD effectue des opérations de base de données selon vos besoins.

Activation de l'authentification Azure AD sur Autonomous Database

Un administrateur Azure AD et un administrateur Autonomous Database réalisent des étapes pour configurer l'authentification Azure AD sur Autonomous Database.

Prérequis

L'intégration de Microsoft Azure AD à Oracle Autonomous Database on Dedicated Exadata Infrastructure requiert les éléments suivants :

Autonomous Database avec la version 19.18 ou une version supérieure.
Connectivité à la base de données sur le port TLS 2484. Les connexions non TLS ne sont pas prises en charge.
Connectivité réseau à Azure AD sortante afin que la base de données puisse demander la clé publique Azure AD.
Autonomous Database inscrit auprès d'Azure AD.
Pour les déploiements Exadata Cloud@Customer, les paramètres de proxy HTTP de votre environnement doivent autoriser la base de données à utiliser Azure AD.

Ces paramètres sont définis par l'administrateur de parc lors de la création de l'infrastructure Exadata Cloud@Customer, comme décrit dans Utilisation de la console pour provisionner Exadata Database Service on Cloud@Customer.

Remarques :
La configuration réseau, y compris le proxy HTTP, ne peut être modifiée que jusqu'à ce que l'infrastructure Exadata présente l'état Activation requise. Une fois activé, vous ne pouvez plus modifier ces paramètres.

La configuration d'un proxy HTTP pour une infrastructure Exadata déjà provisionnée nécessite une demande de service (SR) dans My Oracle Support. Pour plus d'informations, reportez-vous à Création d'une demande d'assistance dans My Oracle Support.

Procédure

Implémentez les tâches suivantes afin de configurer votre instance Autonomous Database pour l'intégration Microsoft Azure AD.

Inscription de l'instance Autonomous Database auprès d'une location Microsoft Azure AD : un utilisateur disposant de privilèges d'administrateur Azure AD utilise Microsoft Azure AD pour inscrire l'instance Oracle Database auprès de la location Microsoft Azure AD. Reportez-vous à Inscription de l'instance Oracle Autonomous Database auprès d'une location Microsoft Azure AD dans le guide de sécurité.
Activer les jetons d'accès v2 Microsoft Azure AD : si votre organisation utilise le jeton d'accès v2 Microsoft Azure AD (au lieu des jetons v1), vous devrez peut-être apporter des modifications supplémentaires dans Azure AD pour prendre en charge la demande upn: dans votre jeton. Reportez-vous à Activation des jetons d'accès v2 Microsoft Azure AD et à Vérification de la version du jeton d'accès Azure AD dans le guide de sécurité.
Gérer les rôles d'application dans Microsoft Azure AD : Dans Azure AD, vous pouvez créer et gérer des rôles d'application qui seront affectés aux utilisateurs et aux groupes Azure AD, et qui seront également mis en correspondance avec des schémas et des rôles globaux Oracle Database. Reportez-vous à Gestion des rôles d'application dans Microsoft Azure AD dans le guide de sécurité.
Configurez la connectivité sortante à Microsoft Azure AD à l'aide d'une passerelle NAT :

Créez une passerelle NAT dans le réseau cloud virtuel (VCN) où résident vos ressources Autonomous Database en suivant les instructions fournies dans Création d'une passerelle NAT dans la documentation Oracle Cloud Infrastructure.

Après avoir créé la passerelle NAT, ajoutez une règle de routage et une règle de sécurité sortante à chaque sous-réseau (dans le VCN) dans lesquelles résident les ressources Autonomous Database afin que ces ressources puissent utiliser la passerelle pour obtenir une clé publique à partir de votre instance Azure AD :
1. Accédez à la page Détails du sous-réseau.
2. Dans l'onglet Informations sur le sous-réseau, cliquez sur le nom de la table de routage du sous-réseau pour afficher la page Détails de la table de routage correspondante.
3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle avec les caractéristiques suivantes :
  - Destination : 0.0.0.0/0
  - Type de cible : passerelle NAT
  - Cible : nom de la passerelle NAT que vous venez de créer dans le VCN
  Si une telle règle n'existe pas, cliquez sur Ajouter des règles de routage et ajoutez une règle possédant ces caractéristiques.
4. Revenez à la page Détails du sous-réseau.
5. Dans la table Listes de sécurité du sous-réseau, cliquez sur le nom de la liste de sécurité du sous-réseau pour afficher la page Détails de la liste de sécurité correspondante.
6. Dans le menu latéral, sous Resources, cliquez sur Egress Rules.
7. Dans la table des règles sortantes existantes, vérifiez s'il existe déjà une règle avec les caractéristiques suivantes :
  - Type de destination : CIDR
  - Destination : 0.0.0.0/0
  - Protocole IP : TCP
  - Plage de ports source: 443
  - Plage de ports de destination : Tout
  Si une telle règle n'existe pas, cliquez sur Ajouter des règles sortantes et ajoutez une règle présentant ces caractéristiques.
Test de l'accessibilité de l'adresse d'ID Entra

Assurez-vous que votre instance Oracle Database peut accéder à l'adresse d'ID Entra en suivant les étapes décrites dans Test de l'accessibilité de l'adresse Azure dans le guide de sécurité.

Si la base de données ne peut pas se connecter à l'adresse d'ID Microsoft Entra, même après avoir défini la stratégie d'ACL, vérifiez les prérequis répertoriés ci-dessus pour vérifier que vous avez correctement configuré le réseau conformément aux prérequis. Si le problème persiste, vérifiez votre réseau pour vous assurer que l'instance de base de données peut se connecter à l'adresse d'ID Entra MS.
Configurez Azure AD en tant que fournisseur d'identités externe pour Autonomous Database :

Par défaut, les instances Autonomous Database et les bases de données Conteneur Autonomous sont configurées pour connecter les utilisateurs avec l'authentification et l'autorisation Oracle Cloud Infrastructure (IAM). Un administrateur de base de données d'application peut également passer à un autre modèle d'authentification externe, tel que Utilisateurs gérés centralement avec Active Directory (CMU-AD) ou Kerberos. Cependant, Autonomous Database ne peut activer qu'un seul modèle d'authentification externe à la fois.

Pour activer Azure AD en tant que fournisseur d'identités externe sur une instance Autonomous Database, procédez comme suit :
1. Connectez-vous à l'instance Autonomous Database en tant qu'utilisateur disposant du privilège EXECUTE sur le package PL/SQL DBMS_CLOUD_ADMIN. Ce privilège est accordé à l'utilisateur ADMIN.
2. Etant donné qu'un seul modèle d'authentification externe peut être activé pour une instance Autonomous Database à un moment donné, exécutez la procédure DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION afin de désactiver tout modèle d'authentification externe déjà activé pour votre base de données.
  Pour exécuter la procédure, vous devez être connecté en tant qu'utilisateur ADMIN ou disposer du privilège EXECUTE sur DBMS_CLOUD_ADMIN.
```
BEGIN
    DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
END;
/
```
3. Exécutez la procédure DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION avec les paramètres Azure AD requis.
```
BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
      type   =>'AZURE_AD',
      params => JSON_OBJECT('tenant_id' VALUE 'tenant_id',
                            'application_id' VALUE 'application_id',
                            'application_id_uri' VALUE 'application_id_uri'),
      force => TRUE
  );
END;
```
  Dans cette procédure, les paramètres Azure AD sont les suivants :
  - type : indique le fournisseur d'authentification externe. Pour Azure AD, utilisez 'AZURE_AD'.
  - params : les valeurs des paramètres Azure AD requis sont disponibles à partir du portail Azure dans le panneau Présentation de l'inscription d'application d'Azure Active Directory. Les paramètres params requis pour Azure AD sont les suivants :
    - tenant_id : ID de locataire du compte Azure. L'ID de locataire indique l'inscription d'application Azure AD de l'instance Autonomous Database.
    - application_id : ID d'application Azure créé dans Azure AD permettant d'affecter des rôles/mises en correspondance de schéma pour l'authentification externe dans l'instance Autonomous Database.
    - application_id_uri : URI unique affecté à l'application Azure.
      Il s'agit de l'identificateur de l'instance Autonomous Database. Ce doit être un nom qualifié de domaine (il prend en charge l'accès aux ressources interlocations).
      
      La longueur maximale pour ce paramètre est de 256 caractères.
  - force : définissez ce paramètre sur TRUE si une autre méthode EXTERNAL AUTHENTICATION est configurée pour l'instance Autonomous Database et que vous voulez la désactiver.
  Exemple :
```
BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
      type   =>'AZURE_AD',
      params => JSON_OBJECT('tenant_id' VALUE '29981886-6fb3-44e3-82',
                            'application_id' VALUE '11aa1a11-aaa',
                            'application_id_uri' VALUE 'https://example.com/111aa1aa'),
      force  => TRUE
  );
END;
```
  Cette commande définit le paramètre système IDENTITY_PROVIDER_TYPE.
  Par exemple, vous pouvez utiliser la commande suivante pour vérifier le paramètre IDENTITY_PROVIDER_TYPE :
```
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
 
NAME                   VALUE   
---------------------- -------- 
identity_provider_type AZURE_AD
```
Pour plus d'informations, reportez-vous à Procédure ENABLE_EXTERNAL_AUTHENTICATION.

Mise en correspondance de schémas et de rôles de base de données Oracle

Les utilisateurs Azure AD seront mis en correspondance avec un schéma de base de données et éventuellement avec des rôles de base de données.

Vous disposez des options suivantes pour mettre en correspondance les rôles et les schémas de base de données Oracle avec les utilisateurs Microsoft Azure AD :

Mise en correspondance exclusive d'un schéma Oracle Database avec un utilisateur Microsoft Azure AD : reportez-vous à Mise en correspondance exclusive d'un schéma Oracle Database avec un utilisateur Microsoft Azure AD dans le guide de sécurité.
Mapper un schéma Oracle partagé avec un rôle d'application : reportez-vous à Mappage d'un schéma Oracle partagé avec un rôle d'application dans le guide de sécurité.
Mapper un rôle global Oracle Database avec un rôle d'application : reportez-vous à Mapper un rôle global Oracle Database avec un rôle d'application dans le Guide de sécurité.

Configuration des connexions client à des AD Azure

Il existe de nombreuses façons de configurer un client pour la connexion à une instance Oracle Autonomous Database on Dedicated Exadata Infrastructure à l'aide de jetons Azure AD.

Vous devez choisir la méthode de connexion client qui convient le mieux à votre environnement. Ce guide fournit des exemples de connexion de SQL*Plus avec différentes méthodes d'obtention d'un jeton d'accès OAuth2 Azure AD. Tous les clients Oracle Database version 19c peuvent accepter un jeton transmis en tant que fichier. Les pilotes JDBC Thin, Instant Client et ODP.NET acceptent également le jeton via l'API client de base de données d'une application. Les outils Oracle Database tels que SQL*Plus ne peuvent pas extraire les jetons directement. Par conséquent, des outils tels que PowerShell ou l'interface de ligne de commande Azure doivent être utilisés pour extraire le jeton d'accès OAuth2 Azure AD. Pour extraire un jeton Azure AD, le client doit être inscrit via le processus d'inscription d'application Azure AD. L'inscription du client est semblable à l'inscription du serveur Oracle Autonomous Database on Dedicated Exadata Infrastructure auprès d'Azure AD à l'aide de l'inscription d'application. La base de données et le client doivent être inscrits auprès d'Azure AD.

La base de données doit être inscrite afin que le client puisse être autorisé à obtenir un jeton d'accès pour la base de données. Le client doit être inscrit pour qu'Azure AD puisse reconnaître qu'un client sécurisé demande un jeton d'accès.

Remarques :

Sur le client, vous devez définir les paramètres TOKEN_AUTH et TOKEN_LOCATION dans le fichier sqlnet.ora afin d'extraire le jeton d'accès à la base de données Azure AD à partir d'un emplacement et de l'utiliser lorsque la connexion à la barre oblique / est utilisée. Les détails exacts sont traités dans Configuration de SQL*Plus pour les jetons d'accès Azure AD.

Pour plus d'informations sur la connexion de clients à Azure AD, reportez-vous aux articles Microsoft Azure suivants :

Flux opérationnel d'une connexion client SQL*Plus dans PowerShell à Autonomous Database

La connexion entre l'utilisateur Azure, Azure AD et l'instance Autonomous Database repose sur la transmission du jeton OAuth2 entre ces composants.

Reportez-vous à Operational Flow for SQL*Plus Client Connection in PowerShell to Oracle Database dans le Guide de sécurité pour obtenir un exemple illustrant l'utilisation du flux d'informations d'identification de mot de passe de propriétaire de ressource (ROPC) avec un client public.

Inscription d'un client avec l'inscription d'application Azure AD

Ce type d'inscription est semblable à l'inscription d'Autonomous Database avec l'inscription d'application Azure AD. Pour plus de détails, reportez-vous aux sections suivantes :

Inscrivez le client de base de données auprès d'Azure en tant que client confidentiel ou public selon votre cas d'emploi : Inscription de client confidentiel et public
Inscription d'une application client de base de données auprès d'Azure AD : Inscription d'une application client de base de données auprès d'Azure AD

Exemples d'extraction de jetons OAuth2 Azure AD

Pour obtenir des exemples montrant les différentes façons d'extraire des jetons OAuth2 Azure AD, reportez-vous à Exemples d'extraction de jetons OAuth2 Azure AD dans le guide de sécurité.

Configuration de SQL*Plus pour les jetons d'accès Azure AD

Vous devez configurer SQL*Plus de sorte à extraire le jeton d'accès à la base de données Azure AD à partir d'un emplacement et à l'utiliser lorsque la connexion / à barre oblique est utilisée. Pour obtenir des instructions détaillées, reportez-vous à Configuration de SQL*Plus pour les jetons d'accès Azure AD dans le guide de sécurité.

Dépannage des connexions Microsoft Entra ID

Vous pouvez utiliser des fichiers trace pour diagnostiquer les problèmes liés aux connexions Microsoft Entra ID. Vous pouvez également corriger facilement les erreurs ORA-12599 et ORA-03114.

Vous pouvez utiliser des fichiers trace pour dépanner l'intégration d'Oracle Database avec Microsoft Azure AD. Pour plus d'informations, reportez-vous à Fichiers trace pour le dépannage des connexions client Oracle Database avec Azure AD dans le guide de la sécurité de base de données.
Les erreurs ORA-12599: TNS: cryptographic checksum mismatch et ORA-03114: not connected to ORACLE indiquent que la base de données à laquelle vous tentez de vous connecter est protégée par le cryptage réseau natif.

Lorsque des jetons sont utilisés pour accéder à une base de données Oracle, une connexion TLS (Transport Layer Security) doit être établie, et non un cryptage natif réseau. Pour corriger ces erreurs, assurez-vous que TLS est correctement configuré pour votre base de données. Vous devez tester la configuration avec un nom utilisateur et un mot de passe de base de données locaux et vérifier les paramètres SYSCONTEXT USERENV suivants :
- NETWORK_PROTOCOL
- TLS_VERSION
Vous pouvez vérifier la version du jeton d'accès Microsoft Azure AD que votre site utilise à l'aide du site Web Jetons Web JSON. Pour plus d'informations, reportez-vous à Vérification de la version du jeton d'accès Azure AD dans le guide de sécurité de base de données.