Authentifier et autoriser les utilisateurs Microsoft Azure Active Directory pour Autonomous Database

À 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 données d'identification Azure AD.

Les utilisateurs et les applications Azure AD peuvent se connecter avec les données d'authentification unique Azure AD pour accéder à la base de données. Cela se fait avec un jeton d'accès Azure AD OAuth2 que l'utilisateur ou l'application demande d'abord à partir d'Azure AD. Ce jeton d'accès OAuth2 contient l'identité de l'utilisateur et les informations d'accès à la base de données, puis il 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 multifacteur et sans mot de passe.

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

Oracle Database sur place version 19.18 ou ultérieure
Oracle Autonomous Database sur une infrastructure Exadata partagée
Oracle Autonomous Database sur une infrastructure Exadata dédiée
Service de base de données de base Oracle
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 à l'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 données d'authentification 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 enregistre Oracle Autonomous Database on Dedicated Exadata Infrastructure dans Azure AD. Dans Azure AD, cela s'appelle un enregistrement d'application, qui est court pour l'enregistrement 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'enregistrement 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 mappés à un schéma global de base de données ou à un rôle global ou à la fois à un schéma et à un rôle. Un utilisateur, un groupe ou une application Azure AD qui est affecté à un rôle d'application sera mappé à un schéma global de base de données, à un rôle global, ou à la fois à un schéma et à un rôle. Un schéma global Oracle peut également être mappé exclusivement à un utilisateur Azure AD. Un utilisateur invité Azure AD (utilisateur non organisation) ou un principal de service Azure AD (application) ne peut être mappé à un schéma global de base de données qu'au moyen d'un rôle d'application Azure AD. Un rôle global Oracle ne peut être mappé à partir d'un rôle d'application Azure et ne peut pas être mappé à partir d'un utilisateur Azure.

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

Les outils et les 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 type de cas, les jetons Azure AD peuvent être extraits à l'aide d'outils tels que Microsoft PowerShell ou l'interface de ligne de commande Azure et placés dans un emplacement de fichier. Un jeton d'accès à la base de données Azure AD OAuth2 est émis avec un délai d'expiration. Le pilote du client Oracle Database s'assure que le jeton a 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 la base de données, ce qui signifie qu'il y a des informations dans le jeton sur la base de données où le jeton sera utilisé. Les rôles d'application auxquels le principal Azure AD a été affecté dans l'enregistrement d'application Azure AD dans la base de données sont inclus dans le jeton d'accès. L'emplacement de répertoire du jeton Azure AD ne doit disposer que des autorisations suffisantes pour que l'utilisateur puisse y écrire le fichier du jeton et pour que le client de base de données puisse récupérer ces fichiers (par exemple, lecture et écriture par l'utilisateur). Comme le jeton autorise l'accès à la base de données, il doit être protégé dans le système de fichiers.

Les utilisateurs d'Azure AD peuvent demander un jeton à Azure AD à l'aide d'un certain nombre de méthodes pour ouvrir une fenêtre de connexion Azure afin d'entrer leurs données d'identification Azure AD.

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

Utilisateur Azure AD : utilisateur enregistré dans la location Azure AD
Utilisateur invité : en tant qu'utilisateur invité dans la location Azure AD
Service : application enregistrée qui se connecte à la base de données en tant qu'elle-même avec le flux de données d'identification de client (cas d'utilisation de la réserve 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 à l'aide d'un navigateur
Données d'identification de client, qui concernent les applications de base de données qui se connectent en tant qu'elles-mêmes (et non l'utilisateur final)
OBO (au nom de), où une application demande un jeton d'accès au nom d'un utilisateur connecté pour l'envoyer à la base de données
Données d'identification du mot de passe du responsable de la ressource (ROPC), qui ne sont pas recommandées pour une utilisation en production, mais peuvent être utilisées dans les environnements de test où l'authentification de l'utilisateur d'un navigateur contextuel serait difficile à intégrer. ROPC a besoin du nom d'utilisateur et des données 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 avec une base de données 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 similaire à l'utilisation de jetons GIA OCI. Voir Architecture de l'intégration de Microsoft Azure AD à Oracle Database dans le guide sur la sécurité pour une explication détaillée.

Mappage des utilisateurs Azure AD à Autonomous Database

Les utilisateurs Microsoft Azure doivent être mappés à un schéma Autonomous Database et disposer des privilèges nécessaires (via des rôles) pour pouvoir s'authentifier auprès de l'instance Autonomous Database. Voir Mappage d'utilisateurs Azure AD à Oracle Database dans le guide sur la sécurité pour plus d'informations sur les différentes façons de mapper des utilisateurs, des groupes et des applications dans Microsoft Azure.

Cas d'utilisation pour la connexion à un service Autonomous Database à l'aide d'Azure AD

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

Processus général d'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 Azure AD OAuth2.

Voici le processus général :

L'administrateur Oracle Database s'assure que l'environnement Oracle Database répond aux exigences pour l'intégration de Microsoft Azure AD. Voir Exigences relatives à Oracle Database pour l'intégration de Microsoft Azure AD.
L'administrateur Azure AD crée un enregistrement 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'enregistrement de l'application, l'administrateur Azure AD crée des rôles d'application Azure à utiliser pour les mappages entre les utilisateurs, les groupes et les applications Azure et les schémas et rôles Oracle Database.
L'administrateur Oracle Database crée et mappe des schémas globaux à un utilisateur Azure AD (mappage de schéma exclusif) ou à un rôle d'application Azure (mappage de schéma partagé). L'utilisateur ou l'application Azure AD doit être mappé à un schéma.
Facultativement, l'administrateur Oracle crée des rôles globaux pour Oracle Database et les mappe aux rôles d'application Azure.
L'utilisateur final Azure AD qui souhaite se connecter à l'instance Oracle Autonomous Database on Dedicated Exadata Infrastructure enregistre l'application client en tant que client Azure AD (semblable à la façon dont la base de données Oracle est enregistrée).
Le client Azure AD aura une identification de client et une clé secrète client, sauf si le client d'application est public. Si le client d'application est public, seule l'identification de 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 au moyen d'une API client de base de données. Consultez la documentation sur le client Oracle Database suivante pour plus d'informations sur la transmission de jetons Azure AD OAuth2 :
- Clients légers JDBC : Guide du développeur Oracle Database JDBC
- Interface d'appel Oracle (OCI) : Guide du programmeur d'interface d'appel Oracle
- Oracle Data Provider for .NET (ODP) : Guide du développeur Oracle Data Provider for .NET pour Microsoft WindowsConnexion à Oracle Database
Une fois connecté à l'instance Oracle Autonomous Database on Dedicated Exadata Infrastructure, l'utilisateur final Azure AD effectue les opérations de base de données selon les besoins.

Activer l'authentification Azure AD sur Autonomous Database

Un administrateur Azure AD et un administrateur Autonomous Database effectuent les étapes de configuration de l'authentification Azure AD sur Autonomous Database.

Conditions requises

L'intégration de Microsoft Azure AD à Oracle Autonomous Database on Dedicated Exadata Infrastructure nécessite :

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

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

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

La configuration d'un mandataire HTTP pour une infrastructure Exadata déjà provisionnée nécessite une demande de service dans My Oracle Support. Pour plus de détails, voir Créer une demande de service dans My Oracle Support.

Procédure

Mettez en oeuvre les tâches suivantes pour configurer votre intégration à Autonomous Database pour Microsoft Azure AD.

Enregistrer l'instance Autonomous Database dans une location AD Microsoft Azure : Un utilisateur doté de privilèges d'administrateur Azure AD utilise Microsoft Azure AD pour enregistrer l'instance Oracle Database dans la location AD Microsoft Azure. Consultez Enregistrer une instance Oracle Autonomous Database dans une location AD Microsoft Azure dans le guide de sécurité.
Activer les jetons d'accès Microsoft Azure AD v2 : Si votre organisation utilise le jeton d'accès Microsoft Azure AD v2 (au lieu des jetons v1), vous devrez peut-être apporter des modifications supplémentaires dans Azure AD pour prendre en charge la revendication upn: dans votre jeton. Voir Activation des jetons d'accès Microsoft Azure AD v2 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 groupes Azure AD et qui seront également mappés aux schémas et rôles globaux Oracle Database. Reportez-vous à Gérer les rôles d'application dans Microsoft Azure AD dans le guide sur la sécurité.
Configurer la connectivité sortante vers Microsoft Azure AD à l'aide d'une passerelle NAT :

Créez une passerelle NAT dans le réseau en nuage virtuel (VCN) où résident vos ressources Autonomous Database en suivant les instructions sous Créer une passerelle NAT dans la documentation sur Oracle Cloud Infrastructure.

Après avoir créé la passerelle NAT, ajoutez une règle de routage et une règle de sécurité de trafic sortant à chaque sous-réseau (dans le VCN) où résident des ressources Autonomous Database afin que ces ressources puissent utiliser la passerelle pour obtenir une clé publique de votre instance Azure AD :
1. Allez à la page Détails du sous-réseau correspondante.
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.
3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
  - Destination : 0.0.0.0/0
  - Type de cible : Passerelle NAT
  - Target : 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 de routage avec ces caractéristiques.
4. Retournez à 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é.
6. Dans le menu latéral, sous Ressources, cliquez sur Règles de trafic sortant.
7. Dans la table des règles de trafic sortant existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
  - Type de destination : CIDR
  - Destination : 0.0.0.0/0
  - Protocole IP : TCP
  - Intervalle de ports sources : 443
  - Intervalle de ports de destination : Tout
  Si une telle règle n'existe pas, cliquez sur Ajouter des règles de trafic sortant et ajoutez une règle de trafic sortant avec ces caractéristiques.
Tester l'accessibilité du point d'extrémité Entra ID

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

Si la base de données ne peut pas se connecter au point d'extrémité Microsoft Entra ID, même après avoir défini la politique de liste de contrôle d'accès, vérifiez les préalables énumérés ci-dessus pour vérifier que vous avez configuré le réseau correctement selon les préalables. Si le problème persiste, vérifiez votre réseau pour vous assurer que l'instance de base de données peut se connecter au point d'extrémité MS Entra ID.
Configurez Azure AD en tant que fournisseur d'identités externe pour Autonomous Database :

Par défaut, les bases de données Autonomous Database et conteneur autonomes sont configurées pour connecter les utilisateurs à l'authentification et à l'autorisation Oracle Cloud Infrastructure (IAM). Un DBA d'application peut également le remplacer par un autre modèle d'authentification externe, tel que les utilisateurs gérés de manière centralisée avec Active Directory (CMU-AD) ou Kerberos. Cependant, une base de données 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 :
1. Connectez-vous à l'instance Autonomous Database en tant qu'utilisateur disposant du privilège EXECUTE sur l'ensemble PL/SQL DBMS_CLOUD_ADMIN. L'utilisateur ADMIN dispose de ce privilège.
2. Comme il ne peut y avoir qu'un seul modèle d'authentification externe activé pour une base de données Autonomous Database à la fois, exécutez la procédure DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION pour 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 : Spécifie le fournisseur d'authentification externe. Pour Azure AD, comme indiqué, utilisez 'AZURE_AD'.
  - params : Les valeurs des paramètres Azure AD requis sont disponibles sur le portail Azure, dans le volet d'aperçu de l'enregistrement de l'application pour Azure Active Directory. Les params requis pour Azure AD sont les suivants :
    - tenant_id : ID locataire du compte Azure. L'ID locataire spécifie l'enregistrement de l'application Azure AD de l'instance de base de données autonome.
    - application_id : ID application Azure créé dans Azure AD pour affecter des mappages rôles/schéma pour l'authentification externe dans l'instance de base de données autonome.
    - application_id_uri : URL unique affectée à l'application Azure.
      Il s'agit de l'identificateur de l'instance de base de données autonome. Il doit s'agir d'un nom qualifié de domaine (prenant en charge l'accès aux ressources interlocations).
      
      La longueur maximale de ce paramètre est de 256 caractères.
  - force : Réglez ce paramètre à TRUE si une autre méthode EXTERNAL AUTHENTICATION est configurée pour l'instance Autonomous Database et que vous voulez la désactiver.
  Par 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 du système IDENTITY_PROVIDER_TYPE.
  Par exemple, vous pouvez utiliser ce qui suit pour vérifier IDENTITY_PROVIDER_TYPE :
```
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
 
NAME                   VALUE   
---------------------- -------- 
identity_provider_type AZURE_AD
```
Voir Procédure ENABLE_EXTERNAL_AUTHENTICATION pour plus d'informations.

Mapper des schémas et des rôles Oracle Database

Les utilisateurs Azure AD seront mappés à un schéma de base de données et éventuellement à un ou plusieurs rôles de base de données.

Vous disposez des options suivantes pour mapper les schémas et les rôles de base de données Oracle aux utilisateurs de Microsoft Azure AD :

Mapper de manière exclusive un schéma Oracle Database à un utilisateur Microsoft Azure AD : Voir Mappage exclusif d'un schéma Oracle Database à un utilisateur Microsoft Azure AD dans le guide de sécurité.
Mapper un schéma Oracle partagé à un rôle d'application : Voir Mappage d'un schéma Oracle partagé à un rôle d'application dans le guide de sécurité.
Mapper un rôle global Oracle Database à un rôle d'application : Voir Mapper un rôle global Oracle Database à un rôle d'application dans le guide de sécurité.

Configurer les connexions de client aux domaines de disponibilité Azure

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

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

La base de données doit être enregistrée afin que le client puisse obtenir l'autorisation d'obtenir un jeton d'accès pour la base de données. Le client doit être enregistré pour qu'Azure AD puisse reconnaître qu'un client approuvé demande un jeton d'accès.

Note :

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

Voir les articles Microsoft Azure suivants pour plus d'informations sur la connexion des clients à Azure AD :

Flux opérationnel pour la connexion de 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 dans tous ces composants.

Reportez-vous à Flux opérationnel pour la connexion client SQL*Plus dans PowerShell à Oracle Database dans le guide de sécurité pour obtenir un exemple montrant l'utilisation du flux de données d'identification par mot de passe du responsable de la ressource (ROPC) avec un client public.

Enregistrement d'un client à l'aide de l'enregistrement d'application Azure AD

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

Enregistrez le client de base de données dans Azure en tant qu'utilisateur confidentiel ou public, selon votre cas d'utilisation : Enregistrement de client privé et public
Enregistrer une application client de base de données dans Azure AD : Enregistrement d'une application client de base de données dans Azure AD

Exemples d'extraction de jetons Azure AD OAuth2

Pour des exemples montrant les différentes façons d'extraire des jetons Azure AD OAuth2, voir Exemples d'extraction de jetons Azure AD OAuth2 dans le guide sur la sécurité.

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

Vous devez configurer SQL*Plus pour extraire le jeton d'accès à la base de données Azure AD à partir d'un emplacement et l'utiliser lors de l'utilisation de la connexion par une barre oblique /. Pour obtenir des instructions détaillées, voir Configuration de SQL*Plus pour les jetons d'accès Azure AD dans le guide sur la sécurité.

Dépannage des connexions Microsoft Entra ID

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

Vous pouvez utiliser des fichiers de suivi pour dépanner l'intégration d'Oracle Database à Microsoft Azure AD. Pour plus d'informations, voir Fichiers de suivi pour le dépannage des connexions de client à Oracle Database à l'aide d'Azure AD dans le guide de 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 chiffrement du 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 le chiffrement natif du 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 d'utilisateur et un mot de passe de base de données local 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. Voir Vérification de la version du jeton d'accès Azure AD dans le guide sur la sécurité des bases de données pour obtenir des conseils.