Microsoft Azure Active Directory-Benutzer für Autonomous Database authentifizieren und autorisieren

Oracle Autonomous Database on Dedicated Exadata Infrastructure mit Microsoft Azure AD integrieren

Oracle Autonomous Database on Dedicated Exadata Infrastructure und Microsoft Azure AD können so konfiguriert werden, dass Benutzer und Anwendungen mit ihren Azure AD-Zugangsdaten eine Verbindung zur Datenbank herstellen können.

Azure AD-Benutzer und -Anwendungen können sich mit Azure AD-Single Sign-On-(SSO-)Zugangsdaten anmelden, um auf die Datenbank zuzugreifen. Dies geschieht mit einem Azure AD-Zugriffstoken OAuth2, das der Benutzer oder die Anwendung zuerst von Azure AD anfordert. Dieses OAuth2-Zugriffstoken enthält die Benutzeridentitäts- und Datenbankzugriffsinformationen und wird dann an die Datenbank gesendet. Informationen zum Konfigurieren der Multifaktor- und kennwortlosen Authentifizierung finden Sie im Microsoft-Artikel Optionen für die kennwortlose Authentifizierung für Azure Active Directory.

Sie können diese Integration in den folgenden Oracle Database-Umgebungen ausführen:

On-Premise-Version von Oracle Database Release 19.18 und höher
Oracle Autonomous Database on Shared Exadata Infrastructure
Oracle Autonomous Database auf dedizierter Exadata-Infrastruktur
Oracle Base Database Service
Oracle Exadata Cloud Service (Oracle ExaCS)

In den Anweisungen zum Konfigurieren von Azure AD umfasst der Begriff "Oracle Database" (bzw. Oracle-Datenbank) diese Umgebungen.

Mit diesem Integrationstyp kann der Azure AD-Benutzer auf eine Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz zugreifen. Azure AD-Benutzer und -Anwendungen können sich mit Azure AD-Single Sign-On-(SSO-)Zugangsdaten anmelden, um ein OAuth2-Zugriffstoken für Azure AD abzurufen, das an die Datenbank gesendet wird.

Der Azure AD-Administrator erstellt und registriert Oracle Autonomous Database on Dedicated Exadata Infrastructure bei Azure AD. Innerhalb von Azure AD wird dies als App-Registrierung bezeichnet, die für die Anwendungsregistrierung steht. Dies sind die digitalen Informationen, die Azure AD über die Software wissen muss, die Azure AD verwendet. Der Azure AD-Administrator erstellt auch Anwendungsrollen für die Registrierung der Datenbankanwendung in Azure AD. Anwendungsrollen verbinden Azure-Benutzer, -Gruppen und -Anwendungen mit Datenbankschemas und -rollen. Der Azure AD-Administrator weist den Anwendungsrollen Azure AD-Benutzer, -Gruppen oder -Anwendungen zu. Diese Anwendungsrollen werden einem globalen Datenbankschema oder einer globalen Rolle oder einem Schema und einer Rolle zugeordnet. Ein Azure AD-Benutzer, eine Gruppe oder eine Anwendung, die einer Anwendungsrolle zugewiesen ist, wird einem globalen Datenbankschema, einer globalen Rolle oder sowohl einem Schema als auch einer Rolle zugeordnet. Außerdem kann ein globales Oracle-Schema einem Azure AD-Benutzer exklusiv zugeordnet werden. Ein Azure AD-Gastbenutzer (Nicht-Organisationsbenutzer) oder ein Azure AD-Service-Principal (Anwendung) kann nur über eine Azure AD-Anwendungsrolle einem globalen Datenbankschema zugeordnet werden. Eine globale Oracle-Rolle kann nur von einer Azure-Anwendungsrolle aus zugeordnet werden und kann nicht von einem Azure-Benutzer zugeordnet werden.

Mit Oracle Autonomous Database on Dedicated Exadata Infrastructure-Tools wie Oracle APEX, Database Actions, Oracle Graph Studio und der Oracle Database-API für MongoDB können Sie keine Azure AD-Token für die Verbindung mit der Datenbank verwenden.

Tools und Anwendungen, die zur Unterstützung von Azure AD-Token aktualisiert werden, können Benutzer direkt bei Azure AD authentifizieren und das Datenbankzugriffstoken an die Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz übergeben. Sie können vorhandene Datenbanktools wie SQL*Plus so konfigurieren, dass ein Azure AD-Token aus einem Dateispeicherort verwendet wird. In diesen Fällen können Azure AD-Token mit Tools wie Microsoft PowerShell oder der Azure-CLI abgerufen und in einem Dateispeicherort abgelegt werden. Ein Azure AD-OAuth2-Datenbankzugriffstoken wird mit einer Ablaufzeit ausgegeben. Der Oracle Database-Clienttreiber stellt sicher, dass das Token ein gültiges Format aufweist und nicht abgelaufen ist, bevor es an die Datenbank übergeben wird. Das Token hat einen Geltungsbereich für die Datenbank, d.h. das Token enthält Informationen über die Datenbank, in der das Token verwendet wird. Die Anwendungsrollen, denen der Azure AD-Prinzipal in der Azure AD-Anwendungsregistrierung der Datenbank zugewiesen wurde, sind als Teil des Zugriffstokens enthalten. Für das Verzeichnis für das Azure AD-Token sollten nur ausreichende Berechtigungen vorhanden sein, damit der Benutzer die Tokendatei in den Speicherort schreiben und der Datenbankclient diese Dateien abrufen kann (z.B. nur Lese- und Schreibberechtigung für den Benutzer). Da das Token Zugriff auf die Datenbank gewährt, muss es im Dateisystem geschützt werden.

Azure AD-Benutzer können ein Token von Azure AD mit einer Reihe von Methoden anfordern, um ein Azure-Anmeldefenster zu öffnen und ihre Azure AD-Zugangsdaten einzugeben.

Oracle Autonomous Database on Dedicated Exadata Infrastructure akzeptiert Token, die folgende Azure AD-Principals darstellen:

Azure AD-Benutzer: Ist im Azure AD-Mandanten als Benutzer registriert
Gastbenutzer: Ist im Azure AD-Mandanten als Gastbenutzer registriert
Service: Hierbei handelt es sich um die registrierte Anwendung, die eigenständig mit dem Clientzugangsdatenfluss eine Verbindung zur Datenbank herstellt (Anwendungsfall für Verbindungspool)

Oracle Autonomous Database on Dedicated Exadata Infrastructure unterstützt die folgenden Azure AD-Authentifizierungsabläufe:

Autorisierungscode, der am häufigsten für menschliche Benutzer (nicht für Anwendungen) zur Authentifizierung bei Azure AD in einer Clientumgebung mit einem Browser verwendet wird
Clientzugangsdaten: Werden für Datenbankanwendungen verwendet, die sich selbst (nicht als Endbenutzer) anmelden
OBO (On-Behalf-Of): Hierbei fordert eine Anwendung ein Zugriffstoken im Namen eines angemeldeten Benutzers an, um es an die Datenbank zu senden
Resource Owner Password Credentials (ROPC), die nicht für die Produktion empfohlen werden, aber in Testumgebungen verwendet werden können, in denen eine Popup-Browserbenutzerauthentifizierung nur schwer integriert werden kann. ROPC benötigt den Azure AD-Benutzernamen und die Kennwortzugangsdaten, um Teil des Tokenanforderungsaufrufs zu sein.

Architektur der Microsoft Azure AD-Integration mit Autonomous Database

Microsoft Azure Active Directory-Token folgen dem OAuth2-Standard mit Erweiterungen. Die Verwendung eines Azure AD-Tokens für den Zugriff auf eine Oracle-Datenbank ähnelt der Verwendung von OCI-IAM-Token. Eine ausführliche Erläuterung finden Sie unter Architektur der Microsoft Azure AD-Integration mit einer Oracle Database im Sicherheitshandbuch.

Zuordnung von Azure AD-Benutzern zu Autonomous Database

Microsoft Azure-Benutzer müssen einem Autonomous Database-Schema zugeordnet sein und (über Rollen) über die erforderlichen Berechtigungen verfügen, bevor sie sich bei der Autonomous Database-Instanz authentifizieren können. Informationen zu den verschiedenen Methoden zum Zuordnen von Benutzern, Gruppen und Anwendungen in Microsoft Azure finden Sie unter Azure AD Users Mapping to the Oracle Database in der Sicherheitsdokumentation.

Anwendungsfälle für die Verbindung mit Autonomous Database über Azure AD

Oracle Database unterstützt drei verschiedene Anwendungsfälle für die Verbindung mit einer Autonomous Database-Instanz über Microsoft Azure Active Directory. Weitere Informationen finden Sie unter Anwendungsfälle für die Verbindung mit Oracle Database über Azure AD.

Allgemeine Authentifizierung von Microsoft Azure AD-Identitäten mit Oracle Autonomous Database on Dedicated Exadata Infrastructure

Der Oracle Database-Administrator und der Microsoft Azure AD-Administrator spielen Rollen, damit Azure AD-Benutzer mit Azure AD-Zugriffstoken OAuth2 eine Verbindung zur Datenbank herstellen können.

Der allgemeine Prozess läuft wie folgt ab:

Der Oracle Database-Administrator stellt sicher, dass die Oracle Database-Umgebung die Anforderungen für die Microsoft Azure AD-Integration erfüllt. Siehe Oracle Database-Anforderungen für die Microsoft Azure AD-Integration.
Der Azure AD-Administrator erstellt eine Azure AD-Anwendungsregistrierung für die Datenbank, und der Oracle Database-Administrator ermöglicht der Datenbank, Azure AD-Token für den Datenbankzugriff zu verwenden.
Im Rahmen des Anwendungsregistrierungsprozesses erstellt der Azure AD-Administrator Azure-Anwendungsrollen, die für die Zuordnungen zwischen den Azure-Benutzern, -Gruppen und -Anwendungen zu den Oracle Database-Schemas und -Rollen verwendet werden sollen.
Der Oracle Database-Administrator erstellt globale Schemas und ordnet sie entweder einem Azure AD-Benutzer (eine exklusive Schemazuordnung) oder einer Azure-Anwendungsrolle (eine gemeinsame Schemazuordnung) zu. Der Azure AD-Benutzer oder die Anwendung muss einem Schema zugeordnet sein.
Optional erstellt der Oracle-Administrator globale Oracle Database-Rollen und ordnet sie Azure-Anwendungsrollen zu.
Der Azure AD-Endbenutzer, der eine Verbindung zur Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz herstellen möchte, registriert die Clientanwendung als Azure AD-Client (entspricht der Registrierung der Oracle-Datenbank).
Der Azure AD-Client verfügt über eine Client-ID und ein Client Secret, es sei denn, es handelt sich um einen öffentlichen Anwendungsclient. Bei einem öffentlichen Anwendungsclient ist nur die Anwendungsclient-ID erforderlich.
The Azure AD end user (who can be a database administrator) connects using an utility such as PowerShell or the Azure command-line interface to retrieve the OAuth2 database access token and store it in a local file directory. An application can also request an Azure AD OAuth2 access token directly from Azure AD and pass it through a database client API. Refer to the following Oracle Database client documentation for information about passing Azure AD OAuth2 tokens:
- JDBC-Thin-Clients: JDBC-Entwicklerdokumentation zu Oracle Database
- Oracle Call Interface (OCI): Oracle Call Interface-Programmierdokumentation
- Oracle Data Provider for .NET (ODP): Oracle Data Provider for .NET-Entwicklerdokumentation für Microsoft WindowsVerbindung mit Oracle Database herstellen
Nach der Verbindung zur Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz führt der Azure AD-Endbenutzer Datenbankvorgänge nach Bedarf aus.

Azure AD-Authentifizierung in Autonomous Database aktivieren

Ein Azure AD-Administrator und ein Autonomous Database-Administrator führen Schritte zur Konfiguration der Azure AD-Authentifizierung in Autonomous Database aus.

Voraussetzungen

Für die Microsoft Azure AD-Integration mit der Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz ist Folgendes erforderlich:

Autonomous Database ist Version 19.18 oder höher.
Konnektivität zur Datenbank auf TLS-Port 2484. Nicht-TLS-Verbindungen werden nicht unterstützt.
Ausgehende Netzwerkkonnektivität zu Azure AD muss vorhanden sein, damit die Datenbank den Public Key von Azure AD anfordern kann.
Die Autonomous Database muss bei Azure AD registriert sein.
Bei Exadata Cloud@Customer-Deployments müssen die HTTP-Proxyeinstellungen in Ihrer Umgebung die Verwendung von Azure AD durch die Datenbank zulassen.

Diese Einstellungen werden vom Flottenadministrator beim Erstellen der Exadata Cloud@Customer-Infrastruktur definiert, wie unter Exadata Database Service on Cloud@Customer mit der Konsole bereitstellen beschrieben.

Hinweis:
Die Netzwerkkonfiguration einschließlich des HTTP-Proxys kann nur bearbeitet werden, bis sich die Exadata-Infrastruktur im Status Aktivierung erforderlich befindet. Sobald sie aktiviert ist, können Sie diese Einstellungen nicht mehr bearbeiten.

Für die Einrichtung eines HTTP-Proxys für eine bereits bereitgestellte Exadata-Infrastruktur ist eine Serviceanfrage (SR) in My Oracle Support erforderlich. Weitere Informationen finden Sie unter Serviceanfrage in My Oracle Support erstellen.

Vorgehensweise

Implementieren Sie die folgenden Aufgaben, um Ihre Autonomous Database-Integration für Microsoft Azure AD zu konfigurieren.

Registrieren Sie die Autonomous Database-Instanz bei einem Microsoft Azure AD-Mandanten: Ein Benutzer mit Azure AD-Administratorberechtigungen verwendet Microsoft Azure AD, um die Oracle Database-Instanz beim Microsoft Azure AD-Mandanten zu registrieren. Weitere Informationen finden Sie unter Oracle Autonomous Database-Instanz bei einem Microsoft Azure AD-Mandanten registrieren in der Sicherheitsdokumentation.
Zugriffstoken für Microsoft Azure AD v2 aktivieren: Wenn Ihre Organisation das Zugriffstoken für Microsoft Azure AD v2 (anstelle von v1-Token) verwendet, müssen Sie möglicherweise zusätzliche Änderungen in Azure AD vornehmen, um den upn:-Claim in Ihrem Token zu unterstützen. Siehe Zugriffstoken für Microsoft Azure AD v2 aktivieren und Azure AD-Zugriffstokenversion prüfen in der Sicherheitsdokumentation.
App-Rollen in Microsoft Azure AD verwalten: In Azure AD können Sie App-Rollen erstellen und verwalten, die Azure AD-Benutzern und -Gruppen zugewiesen und auch globalen Oracle Database-Schemas und -Rollen zugeordnet werden. Weitere Informationen finden Sie unter Anwendungsrollen in Microsoft Azure AD verwalten im Sicherheitshandbuch.
Konfigurieren Sie ausgehende Konnektivität zu Microsoft Azure AD mit einem NAT-Gateway:

Erstellen Sie ein NAT-Gateway im virtuellen Cloud-Netzwerk (VCN), in dem sich Ihre Autonomous Database-Ressourcen befinden, indem Sie die Anweisungen unter NAT-Gateway erstellen in der Oracle Cloud Infrastructure-Dokumentation befolgen.

Nachdem Sie das NAT-Gateway erstellt haben, fügen Sie eine Routingregel und eine Egress-Sicherheitsregel zu jedem Subnetz (im VCN) hinzu, in dem sich Autonomous Database-Ressourcen befinden. So können diese Ressourcen mit dem Gateway einen Public Key aus Ihrer Azure AD-Instanz abrufen:
1. Gehen Sie zur Seite Subnetzdetails für das Subnetz.
2. Klicken Sie auf der Registerkarte Informationen zum Subnetz auf den Namen der Routentabelle des Subnetzes, um die Seite Routentabellendetails anzuzeigen.
3. Prüfen Sie in der Tabelle der vorhandenen Routingregeln, ob bereits eine Regel mit den folgenden Eigenschaften vorhanden ist:
  - Zielort: 0.0.0.0/0
  - Zieltyp: NAT-Gateway
  - Ziel: Der Name des NAT-Gateway, das Sie gerade im VCN erstellt haben
  Wenn keine solche Regel vorhanden ist, klicken Sie auf Routenregeln hinzufügen, und fügen Sie eine Routingregel mit diesen Eigenschaften hinzu.
4. Zurück zur Seite Subnetzdetails für das Subnetz.
5. Klicken Sie in der Tabelle Sicherheitslisten des Subnetzes auf den Namen der Sicherheitsliste des Subnetzes, um die Seite Sicherheitslistendetails anzuzeigen.
6. Klicken Sie im Seitenmenü unter Ressourcen auf Egress-Regeln.
7. Prüfen Sie in der Tabelle der vorhandenen Ausgangsregeln, ob bereits eine Regel mit den folgenden Eigenschaften vorhanden ist:
  - Zieltyp: CIDR
  - Zielort: 0.0.0.0/0
  - IP-Protokoll: TCP
  - Quellportbereich: 443
  - Ziel-Portbereich: Alle
  Wenn keine derartige Regel vorhanden ist, klicken Sie auf Egress-Regeln hinzufügen, und fügen Sie eine Egress-Regel mit diesen Eigenschaften hinzu.
Barrierefreiheit des Entra-ID-Endpunkts testen

Stellen Sie sicher, dass Ihre Oracle Database-Instanz auf den Entra-ID-Endpunkt zugreifen kann, indem Sie die unter Barrierefreiheit des Azure-Endpunkts testen in der Sicherheitsdokumentation beschriebenen Schritte ausführen.

Wenn die Datenbank keine Verbindung zum Microsoft Entra ID-Endpunkt herstellen kann, auch nachdem Sie die ACL-Policy festgelegt haben, prüfen Sie die oben aufgeführten Voraussetzungen, um zu bestätigen, dass Sie das Netzwerk ordnungsgemäß gemäß den Voraussetzungen konfiguriert haben. Wenn das Problem weiterhin besteht, prüfen Sie Ihr Networking, um sicherzustellen, dass die Datenbankinstanz eine Verbindung zum MS Entra ID-Endpunkt herstellen kann.
Azure AD als externen Identitätsprovider für Autonomous Database konfigurieren:

Standardmäßig sind Autonomous Databases und autonome Containerdatenbanken so konfiguriert, dass Benutzer mit der Oracle Cloud Infrastructure-(IAM-)Authentifizierung und -Autorisierung verbunden werden. Ein Anwendungs-DBA kann dies auch in ein anderes externes Authentifizierungsschema ändern, wie z.B. zentral verwaltete Benutzer mit Active Directory (CMU-AD) oder Kerberos. eine Autonomous Database kann jedoch jeweils nur ein externes Authentifizierungsschema aktivieren.

So aktivieren Sie Azure AD als externen Identitätsprovider in einer Autonomous Database-Instanz:
1. Melden Sie sich bei der Autonomous Database-Instanz als Benutzer mit der Berechtigung EXECUTE für das PL/SQL-Paket DBMS_CLOUD_ADMIN an. Der ADMIN-Benutzer verfügt über diese Berechtigung.
2. Da jeweils nur ein externes Authentifizierungsschema für eine Autonomous Database aktiviert sein kann, führen Sie die Prozedur DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION aus, um jedes externe Authentifizierungsschema zu deaktivieren, das bereits für Ihre Datenbank aktiviert ist.
  Um die Prozedur auszuführen, müssen Sie als ADMIN-Benutzer angemeldet sein oder die Berechtigung EXECUTE für DBMS_CLOUD_ADMIN besitzen.
```
BEGIN
    DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
END;
/
```
3. Führen Sie die Prozedur DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION mit den für Azure AD erforderlichen Parametern aus.
```
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;
```
  Die Azure AD-Parameter in dieser Prozedur lauten:
  - type: Gibt den externen Authentifizierungsprovider an. Verwenden Sie für Azure AD wie dargestellt 'AZURE_AD'.
  - params: Werte für die erforderlichen Azure AD-Parameter sind im Azure-Portal im Überblicksbereich für die Anwendungsregistrierung für Azure Active Directory verfügbar. Unter params müssen folgende Parameter für Azure AD angegeben werden:
    - tenant_id: Mandanten-ID des Azure-Accounts. Die Mandanten-ID gibt die Azure AD-Anwendungsregistrierung der Autonomous Database-Instanz an.
    - application_id: In Azure AD erstellte Azure-Anwendungs-ID zum Zuweisen von Rollen-/Schemazuordnungen für die externe Authentifizierung in der Autonomous Database-Instanz.
    - application_id_uri: Eindeutige URI, die der Azure-Anwendung zugewiesen ist.
      Dies ist die ID für die Autonomous Database-Instanz. Der Name muss domainqualifiziert sein (dadurch wird der mandantenübergreifende Ressourcenzugriff unterstützt).
      
      Die maximale Länge für diesen Parameter beträgt 256 Zeichen.
  - force: Setzen Sie diesen Parameter auf TRUE, wenn eine andere EXTERNAL AUTHENTICATION-Methode für die Autonomous Database-Instanz konfiguriert ist und Sie diese deaktivieren möchten.
  Beispiel:
```
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;
```
  Dadurch wird der Systemparameter IDENTITY_PROVIDER_TYPE festgelegt.
  Beispiel: Sie können IDENTITY_PROVIDER_TYPE wie folgt prüfen:
```
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
 
NAME                   VALUE   
---------------------- -------- 
identity_provider_type AZURE_AD
```
Weitere Informationen finden Sie unter Prozedur ENABLE_EXTERNAL_AUTHENTICATION.

Oracle Database-Schemas und -Rollen zuordnen

Azure AD-Benutzer werden einem Datenbankschema und optional einer oder mehreren Datenbankrollen zugeordnet.

Für die Zuordnung von Oracle-Datenbankschemas und -rollen zu Microsoft Azure AD-Benutzern stehen folgende Optionen zur Verfügung:

Oracle Database-Schema einem Microsoft Azure AD-Benutzer exklusiv zuordnen: Weitere Informationen finden Sie unter Oracle Database-Schema einem Microsoft Azure AD-Benutzer exklusiv zuordnen in der Sicherheitsdokumentation.
Gemeinsames Oracle-Schema einer Anwendungsrolle zuordnen: Weitere Informationen finden Sie unter Gemeinsames Oracle-Schema einer Anwendungsrolle zuordnen in der Sicherheitsdokumentation.
Globale Oracle Database-Rolle einer Anwendungsrolle zuordnen: Weitere Informationen finden Sie unter Globale Oracle Database-Rolle einer Anwendungsrolle zuordnen in der Sicherheitsdokumentation.

Clientverbindungen bei Azure ADs konfigurieren

Es gibt zahlreiche Möglichkeiten, wie Sie einen Client für die Verbindung mit einer Oracle Autonomous Database on Dedicated Exadata Infrastructure-Instanz mit Azure AD-Token konfigurieren können.

Wählen Sie die Clientverbindungsmethode aus, die in Ihrer Umgebung am besten funktioniert. Diese Dokumentation enthält Beispiele für das Herstellen von SQL*Plus-Verbindungen mit verschiedenen Methoden zum Abrufen eines OAuth2-Zugriffstokens für Azure AD. Alle Oracle Database Release 19c-Clients können ein Token akzeptieren, das als Datei übergeben wird. Die JDBC-Thin-, Instant Client- und ODP.net-Treiber akzeptieren das Token auch über die Datenbankclient-API von einer Anwendung. Oracle Database-Tools wie SQL*Plus können die Token nicht direkt abrufen. Daher müssen Tools wie PowerShell oder die Azure-CLI zum Abrufen des OAuth2-Zugriffstokens für Azure AD verwendet werden. Um ein Azure AD-Token abzurufen, muss der Client über den Azure AD-App-Registrierungsprozess registriert sein. Die Registrierung des Clients ähnelt der Registrierung des Oracle Autonomous Database on Dedicated Exadata Infrastructure-Servers bei Azure AD über die Anwendungsregistrierung. Datenbank und Client müssen bei Azure AD registriert sein.

Die Datenbank muss registriert sein, damit der Client die Berechtigung zum Abrufen eines Zugriffstokens für die Datenbank erhalten kann. Der Client muss registriert sein, damit Azure AD erkennen kann, dass ein vertrauenswürdiger Client ein Zugriffstoken anfordert.

Hinweis:

Auf dem Client müssen Sie die Parameter TOKEN_AUTH und TOKEN_LOCATION in der Datei sqlnet.ora festlegen, um das Azure AD-Datenbankzugriffstoken von einem Speicherort abzurufen und bei Verwendung der Schrägstrichanmeldung / zu verwenden. Genaue Details werden unter SQL*Plus für Azure AD-Zugriffstoken konfigurieren beschrieben.

Weitere Informationen zum Herstellen von Clientverbindungen zu Azure AD finden Sie in den folgenden Microsoft Azure-Artikeln:

Betriebsablauf für SQL*Plus-Clientverbindung in PowerShell zu Autonomous Database

Die Verbindung zwischen dem Azure-Benutzer, Azure AD und der Autonomous Database-Instanz basiert auf der Übergabe des OAuth2-Token in diesen Komponenten.

Ein Beispiel zur Verwendung des Resource Owner Password Credential-(ROPC-)Ablaufs mit einem öffentlichen Client finden Sie unter Operational Flow for SQL*Plus Client Connection in PowerShell to Oracle Database in der Sicherheitsdokumentation.

Client bei der Azure AD-Anwendungsregistrierung registrieren

Dieser Registrierungstyp ähnelt der Registrierung von Autonomous Database bei der Azure AD-App-Registrierung. Weitere Informationen finden Sie in den folgenden Abschnitten:

Registrieren Sie den Datenbankclient je nach Anwendungsfall als vertraulich oder öffentlich bei Azure: Vertrauliche und öffentliche Clientregistrierung
Datenbankclient-App bei Azure AD registrieren: Datenbankclient-App bei Azure AD registrieren

Beispiele für das Abrufen von OAuth2-Token für Azure AD

Beispiele für die verschiedenen Möglichkeiten, wie Sie OAuth2-Token für Azure AD abrufen können, finden Sie unter Beispiele für das Abrufen von OAuth2-Token für Azure AD in der Sicherheitsdokumentation.

SQL*Plus für Azure AD-Zugriffstoken konfigurieren

Sie müssen SQL*Plus konfigurieren, um das Zugriffstoken für die Azure AD-Datenbank von einem Speicherort abzurufen und bei Verwendung der Schrägstrichanmeldung zu verwenden. Ausführliche Anweisungen finden Sie unter SQL*Plus für Azure AD-Zugriffstoken konfigurieren in der Sicherheitsdokumentation.

Fehlerbehebung bei Microsoft Entra-ID-Verbindungen

Mit Tracedateien können Sie Probleme mit Microsoft Entra ID-Verbindungen diagnostizieren. Sie können auch die Fehler ORA-12599 und ORA-03114 problemlos beheben.

Mit Tracedateien können Sie Fehler in der Oracle Database-Integration mit Microsoft Azure AD beheben. Weitere Informationen finden Sie unter Tracedateien für die Fehlerbehebung bei Oracle Database-Clientverbindungen mit Azure AD in der Datenbanksicherheitsdokumentation.
Die Fehler ORA-12599: TNS: cryptographic checksum mismatch und ORA-03114: not connected to ORACLE weisen darauf hin, dass die Datenbank, bei der Sie eine Verbindung herstellen möchten, durch native Netzwerkverschlüsselung geschützt ist.

Wenn Token für den Zugriff auf eine Oracle-Datenbank verwendet werden, muss eine Transport Layer Security-(TLS-)Verbindung hergestellt werden, nicht die native Netzwerkverschlüsselung. Um diese Fehler zu beheben, stellen Sie sicher, dass TLS ordnungsgemäß für Ihre Datenbank konfiguriert ist. Testen Sie die Konfiguration mit einem lokalen Datenbankbenutzernamen und -kennwort, und prüfen Sie die folgenden SYSCONTEXT USERENV-Parameter:
- NETWORK_PROTOCOL
- TLS_VERSION
Sie können die von Ihrer Site verwendete Version des Microsoft Azure AD-Zugriffstokens über die Website "JSON Web Token" prüfen. Weitere Informationen finden Sie unter Azure AD-Zugriffstokenversion prüfen in der Datenbanksicherheitsdokumentation.