Freigeben über

Behebung von 403-Fehlern in Azure Blob Storage

Beim Zugriff auf Azure Blob Storage treten möglicherweise HTTP 403-Fehler auf, die verhindern, dass Clients Daten lesen, schreiben oder verwalten. Diese Fehler können aus einer Vielzahl von Konfigurations- oder Autorisierungsproblemen resultieren, einschließlich Rollenzuweisungen, Tokeneinstellungen, Netzwerkeinschränkungen, Verschlüsselungsrichtlinien und mehr. Dieser Artikel enthält eine umfassende Checkliste und Anleitungen zur Problembehandlung, mit denen Sie die Ursache von 403 Fehlern identifizieren und effizient beheben können.

Ungefähr 403 Fehler

Ein 403-Fehler ist ein HTTP-Statuscode, der die Zeichenfolge 403 enthält (z. B Forbidden (403). ). Jeder 403-Fehler wird von einem spezifischeren Fehlercode begleitet, wie zum Beispiel UnauthorizedBlobOverwrite oder QueryParameterSasMandatory. Diese detaillierten Fehlercodes können Ihnen helfen, die Ursache des Problems einzugrenzen. In den folgenden Artikeln werden die häufigsten Arten von 403 Fehlern beschrieben:

Ein 403-Fehler kann entweder aus Steuerebene- oder Datenebenevorgängen resultieren. Steuerungsebenenvorgänge sind Azure Resource Manager-Anforderungen, z. B. das Erstellen eines Speicherkontos oder das Aktualisieren seiner Eigenschaften. Vorgänge auf datenebenen umfassen Anforderungen an den Speicherdienstendpunkt, z. B. Das Hochladen oder Herunterladen von Blobs. Sie können Azure-Ressourcenprotokolle verwenden, um Fehlerdetails zu finden, einschließlich Informationen zum Sicherheitsprinzipal, Schlüssel oder SAS, die für die Autorisierung verwendet werden.

Authentifizierungsfehler treten auf, wenn Probleme mit Anmeldeinformationen, Token oder Authentifizierungsmethoden auftreten.

Fehler Ursachen und Lösungen
Fehlermeldung
Serverfehler beim Authentifizieren der Anforderung. Stellen Sie sicher, dass der Wert des Autorisierungsheaders, einschließlich der Signatur, korrekt ist.

Fehlercode
Authentifizierung fehlgeschlagen

Fehlerdetails
Die signierte Ablaufzeit <date> muss nach der signierten Startzeit <date> liegen.		 Abgelaufener Token: Das SAS-Token hat sein Ablaufdatum überschritten. Generieren Sie ein neues SAS-Token mit einer zukünftigen Ablaufzeit.

Taktversatz: Zeitunterschiede zwischen Systemen können dazu führen, dass Token frühzeitig als abgelaufen erscheinen. Erwägen Sie das Hinzufügen von Pufferzeit zum Ablauf.

Startzeit in Zukunft: Vermeiden Sie das Festlegen einer Startzeit, wenn die SAS zur sofortigen Verwendung verwendet wird.
Fehlermeldung
Serverfehler beim Authentifizieren der Anforderung. Stellen Sie sicher, dass der Wert des Autorisierungsheaders, einschließlich der Signatur, korrekt ist.

Fehlercode
Authentifizierung fehlgeschlagen

Fehlerdetails
Die MAC-Signatur in der HTTP-Anforderung "xyz..." ist nicht mit einer berechneten Signatur identisch.		 Falscher Kontoschlüssel: Überprüfen Sie, ob Sie den richtigen primären oder sekundären Schlüssel für das Speicherkonto verwenden.

Neu generierte Schlüssel: Wenn Speicherzugriffsschlüssel kürzlich neu generiert wurden, aktualisieren Sie Ihre Anwendung mit dem neuen Schlüssel.

Codierungsprobleme: Stellen Sie sicher, dass der Kontoschlüssel ordnungsgemäß codiert und formatiert ist.
Fehlermeldung
Serverfehler beim Authentifizieren der Anforderung. Stellen Sie sicher, dass der Wert des Autorisierungsheaders, einschließlich der Signatur, korrekt ist.

Fehlercode
Authentifizierung fehlgeschlagen

Fehlerdetails
DAS SAS-Feld "sv" ist nicht wohlgeformt.		 Ungültiges SAS-Format: Verwenden Sie offizielle Azure SDKs oder Tools wie Storage Explorer, um SAS-Token zu generieren.

Manuelle Konstruktionsfehler: Wenn SAS-Token manuell erstellt werden, überprüfen Sie alle erforderlichen Felder und deren Formate.

Versionskonflikt: Stellen Sie sicher, dass der Parameter (Version) Ihrer Version der sv Speicherclientbibliothek entspricht.
Fehlermeldung
Serverfehler beim Authentifizieren der Anforderung. Stellen Sie sicher, dass der Wert des Autorisierungsheaders, einschließlich der Signatur, korrekt ist.

Fehlercode
Authentifizierung fehlgeschlagen

Fehlerdetails
Die angegebene signierte Ressource ist für diese Ressourcenebene nicht zulässig.		 Dienst- und Konto-SAS: Sie verwenden eine Dienst-SAS (für bestimmte Blobs/Container) für Vorgänge auf Kontoebene.

Bereichskonflikt: Generieren Sie den entsprechenden SAS-Typ für Ihren Vorgang. Verwenden Sie ein Konto-SAS für Vorgänge auf Kontoebene (Listencontainer), und verwenden Sie eine Dienst-SAS für bestimmte Blob-/Containervorgänge.
Fehlermeldung
Die schlüsselbasierte Authentifizierung ist für dieses Speicherkonto nicht zulässig.

Fehlercode
SchlüsselbasierteAuthentifizierungNichtErlaubt		 Richtlinieneinschränkung: Das Speicherkonto wurde so konfiguriert, dass die Authentifizierung gemeinsam genutzter Schlüssel nicht zulässig ist.

Wechseln Sie zu Azure AD: Verwenden Sie die Azure Active Directory-Authentifizierung (Entra-ID) anstelle von Kontoschlüsseln.

Freigegebenen Schlüssel aktivieren: Aktivieren Sie bei Bedarf den Zugriff auf gemeinsam genutzte Schlüssel in der Konfiguration des Speicherkontos erneut.

Autorisierungsfehler treten auf, wenn ein Client über gültige Anmeldeinformationen verfügt, aber nicht genügend Berechtigungen für den angeforderten Vorgang.

Fehler Ursachen und Lösungen
Fehlermeldung
Diese Anforderung ist nicht berechtigt, diesen Vorgang mit dieser Befugnis auszuführen.

Fehlercode
Autorisierungsberechtigungsfehler		 Fehlende Berechtigungen: Das SAS-Token enthält nicht die erforderliche Berechtigung (Lesen, Schreiben, Löschen, Liste).

Vorgangsanforderungen: Einige Vorgänge erfordern mehrere Berechtigungen (z. B. das Überschreiben eines Blobs erfordert sowohl Schreib- als auch Löschvorgänge).

Überprüfen Sie SAS-Berechtigungen: Überprüfen Sie, ob das sp Feld (Berechtigungen) in Ihrem SAS-Token alle erforderlichen Berechtigungen enthält.

Unzureichende Azure RBAC-Rolle: Der Benutzer- oder Dienstprinzipal verfügt nicht über die erforderliche Rolle für den Vorgang.

Verwenden Sie für Lesevorgänge den Speicher-Blob-Datenleser.
Verwenden Sie für Schreibvorgänge den Storage Blob Data Contributor.
Verwenden Sie für Verwaltungsvorgänge die Rolle "Storage Blob Data Owner".

Rollenzuweisungsbereich: Stellen Sie sicher, dass Rollen im entsprechenden Bereich zugewiesen sind (Abonnement, Ressourcengruppe, Speicherkonto oder Container).
Fehlermeldung
Diese Anforderung ist nicht autorisiert, diese Operation mit diesem Dienst auszuführen.

Fehlercode
Berechtigungsdienst-Fehlanpassung		 Falscher Diensttyp: Das SAS-Token wurde für einen anderen Azure Storage-Dienst erstellt.

Nichtübereinstimmung des Dienstfelds: Überprüfen Sie das ss Feld (Dienste) in Ihrem SAS-Token.
Verwenden Sie b für den Blob-Dienst
Verwenden Sie f für den Dateiservice
Verwendung q für Warteschlangendienst
Verwenden Sie t für den Tabellendienst.
Fehlermeldung
Diese Anforderung ist nicht autorisiert, diesen Vorgang auszuführen.

Fehlercode
AuthorizationFailure		 Öffentlicher Netzwerkzugriff deaktiviert: Das Speicherkonto lässt keinen öffentlichen Netzwerkzugriff zu.

IP-Adresseinschränkungen: Ihre IP-Adresse ist nicht in den zulässigen IP-Bereichen enthalten.

Einschränkungen für virtuelle Netzwerke: Der Zugriff ist auf bestimmte virtuelle Netzwerke oder Subnetze beschränkt.

Firewallregeln: Die Firewall des Speicherkontos blockiert Ihre Anforderung.

Umfassende Diagnoseprüfliste

Wenn Sie einen anderen Fehler als die in den vorherigen Abschnitten beschriebenen Fehler erhalten, oder die in diesen Abschnitten beschriebenen Ursachen und Lösungen haben Ihnen nicht geholfen, Ihren Fehler zu beheben, verwenden Sie diese Checkliste als Leitfaden, um die Ursache zu identifizieren und eine Lösung zu finden.

  • Sichere Dateiübertragung – Wenn eine sichere Übertragung erforderlich ist, stellen Sie sicher, dass Anforderungen über HTTPS gestellt werden. (Weitere Informationen).

  • Azure rollenbasierte Zugriffskontrolle: Überprüfen Sie, ob der Sicherheitsprinzipal die korrekte Azure RBAC-Rolle hat. (Weitere Informationen).

  • SAS (Shared Access Signature)-Tokens: Überprüfen Sie den Ablauf, die Berechtigungen und die Generierungsmethode des Tokens. (Weitere Informationen).

  • SAS der Benutzerdelegierung: Bestätigen Sie die erforderlichen Felder, Berechtigungen und den Schlüsselstatus für das Benutzerdelegierungs-SAS. (Weitere Informationen).

  • Gespeicherte Zugriffsrichtlinien: Überprüfen Sie die Einstellungen für gespeicherte Zugriffsrichtlinien und die Verzögerung der Verteilung. (Weitere Informationen).

  • Zugriffssteuerungslisten (ACCESS Control Lists, ACLs): Stellen Sie sicher, dass ACL-Einträge und -Berechtigungen für den Client korrekt sind. (Weitere Informationen).

  • Shared Key-Autorisierung: Wenn Sie einen Kontoschlüssel verwenden, bestätigen Sie, dass die Autorisierung für gemeinsam genutzte Schlüssel zulässig ist. (Weitere Informationen).

  • Öffentlicher Netzwerkendpunkt: Überprüfen Sie den Zugriff auf öffentliche Endpunkte, Firewallregeln und den Netzwerksicherheitsperimeter. (Weitere Informationen).

  • Private Endpunkte: Überprüfen der Subnetz- und Ressourcenkonfiguration für private Endpunkte. (Weitere Informationen).

  • Verschlüsselungsbereiche: Überprüfen sie die Einstellungen für den Verschlüsselungsbereich und den Status des vom Kunden verwalteten Schlüssels. (Weitere Informationen).

  • Deaktivierte Konten: Bestätigen Sie, dass das Speicherkonto oder Abonnement nicht deaktiviert ist. (Weitere Informationen).

  • Azure DataBricks und Azure RBAC: Bereichsrollen für die Ressourcengruppe, das Konto oder den Container. (Weitere Informationen).

  • Überprüfen Sie den Gültigkeitsbereich der Kopiervorgänge: Überprüfen Sie, ob die Kontoeinstellungen den Umfang der Kopiervorgänge einschränken. (Weitere Informationen).

SAS-Token

Häufige Ursachen von 403 Fehlern bei der Verwendung von SAS-Token sind:

  • Unangemessener SAS-Tokenablauf oder Startzeit: Die Ablauf- und Startzeiten des SAS-Tokens werden für die beabsichtigte Verwendung nicht ordnungsgemäß festgelegt.

  • Fehlende Berechtigungen: Nicht alle erforderlichen Berechtigungen werden für das SAS-Token ausgewählt.

  • Unzureichende Berechtigungen: Der Client versucht einen Vorgang, der vom SAS-Token nicht zulässig ist. Beispielsweise versucht der Client, in ein Blob mit einer SAS zu schreiben, die nur Lesevorgänge zulässt. Einige Aktionen erfordern zusätzliche Berechtigungen. Damit ein Client beispielsweise ein Blob überschreiben kann, muss das SAS-Token sowohl Schreib- als auch Löschberechtigungen zulassen.

  • Tokengenerierungsmethode: Das SAS-Token wurde nicht mit einem offiziellen SDK oder Tool (z. B. Speicher-Explorer) generiert. Um Fehler in der Signaturzeichenfolge zu vermeiden, sollten Sie offizielle SDKs zum Generieren von SAS-Token verwenden. Wenn Sie SAS-Token manuell erstellen, verwenden Sie die neueste Speicherdienstversion und -bibliotheken. Weitere Informationen finden Sie unter Delegieren des Zugriffs mit einer Freigegebenen Zugriffssignatur.

  • Abgelaufenes SAS-Token: Der Client verwendet ein SAS-Token, das abgelaufen ist.

  • Uhr schief: Es gibt kleine Zeitunterschiede zwischen dem Host, der die SAS und den Speicherdienst generiert, was dazu führt, dass die SAS ungültig oder früher als erwartet abläuft.

  • Falsche SAS-Startzeit: Vermeiden Sie das Festlegen einer Startzeit, wenn die SAS zur sofortigen Verwendung verwendet wird, da Die Taktunterschiede die SAS noch nicht gültig machen können.

  • Kurze Ablaufzeit: Das Festlegen einer kurzen Ablaufzeit kann aufgrund von Taktunterschieden zu einem vorzeitigen Ablauf führen.

  • Versionskonflikt: Der sv Parameter (Version) im SAS-Token sollte mit der verwendeten Version der Speicherclientbibliothek übereinstimmen. Verwenden Sie immer die neueste Bibliotheksversion.

  • Neu generierte Zugriffstasten: Wenn Speicherzugriffsschlüssel neu generiert werden, können vorhandene SAS-Token ungültig sein, insbesondere solche mit langen Ablaufzeiten.

  • Falsch formatierte Signatur: Die SAS- oder freigegebene Schlüsselsignatur ist falsch gebildet, codiert oder enthält ungültige Parameter.

  • Nicht autorisierte IP-Adresse: Die Anforderung stammt aus einer IP, die nicht vom SAS-Token autorisiert wurde. Überprüfen Sie, ob das Feld "sip" mit der IP-Adresse des Clients übereinstimmt.

  • Interferenzen durch eine Speicherzugriffsrichtlinie Container mit gespeicherten Zugriffsrichtlinien können die von einer SAS erteilte Berechtigung außer Kraft setzen. Beispielsweise kann eine gespeicherte Zugriffsrichtlinie für einen Container die Berechtigung vor dem Ablaufdatum und der Ablaufzeit des SAS widerrufen.

Sehen Sie bewährte Methoden bei der Verwendung von SAS.

SAS-Token der Benutzerdelegierung

Häufige Ursachen von 403 Fehlern im Zusammenhang mit SAS-Token der Benutzerdelegierung sind:

  • Erforderliche Felder fehlen: Stellen Sie sicher, dass alle für die Benutzerdelegierungs-SAS spezifischen Felder vorhanden sind: skoid, sktid, , sktund ske. Wenn keines vorhanden ist, schlägt die Authentifizierung fehl.

  • Nicht unterstützte API-Version: Nur REST-API-Versionen höher als "2018-11-09" werden für Benutzerdelegation für SAS unterstützt.

  • Ungültiges Token: Die Start-st und Endzeiten-se des SAS-Tokens müssen sich innerhalb der Start-skt und Endzeiten-ske des Delegierungsschlüssels befinden.

  • Anforderungszeitpunkt: Die Startzeit der Anforderung muss sich innerhalb des gültigen Zeitrahmens des SAS-Tokens befinden.

  • Signaturkonflikt: Die vom Client bereitgestellte SAS-Signatur muss mit der vom Speicherdienst generierten Signatur übereinstimmen. Ein für Container X erstelltes SAS schlägt z. B. fehl, wenn er für den Zugriff auf Container Y verwendet wird.

  • Unzureichende SAS-Berechtigung: Das SAS-Token muss den angeforderten Vorgang zulassen. Beispielsweise kann eine Berechtigung "Lesen" nicht für eine "Write"-Anforderung verwendet werden. Überprüfen Sie das Feld „sp“.

  • Unzureichende Azure RBAC-Rolle: Der Benutzer muss über die erforderliche Azure-Rolle für den angeforderten Vorgang verfügen. Ein Schreibvorgang erfordert beispielsweise die Rolle "Storage Blob Data Contributor".

  • OAuth-Authentifizierung: Stellen Sie sicher, dass die OAuth-Autorisierung (Azure RBAC) für den angeforderten Vorgang übergeben wird.

  • Widerrufener Schlüssel – Die Anforderung erfolgt, nachdem der Benutzerdelegierungsschlüssel widerrufen oder abgelaufen ist.

Weitere Informationen finden Sie unter Erstellen einer SAS für die Benutzerdelegierung.

Gespeicherte Zugriffsrichtlinien

Überprüfen Sie bei Verwendung von gespeicherten Zugriffsrichtlinien die folgenden Elemente:

  • Richtlinieneinstellungen Die in der gespeicherten Zugriffsrichtlinie definierten Berechtigungen, Startzeit und Ablaufzeit sind für Ihr Szenario korrekt.

  • SAS-Token Das SAS-Token, das der Richtlinie zugeordnet ist, entspricht den vorgesehenen Berechtigungen und dem vorgesehenen Zeitfenster.

Nach dem Anwenden oder Aktualisieren einer gespeicherten Zugriffsrichtlinie können bis zu 30 Sekunden dauern, bis die Richtlinie wirksam wird. Während dieses Intervalls kann eine SAS, die der Richtlinie zugeordnet ist, möglicherweise mit einem 403-Fehler (Verboten) fehlschlagen, bis die Richtlinie aktiv wird.

Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Zugriffssteuerungslisten (ACLs)

Wenn Sie ACLs verwenden, um den Zugriff auf Dateien und Verzeichnisse zu autorisieren, überprüfen Sie die folgenden Elemente:

  • Sicherheitsprinzipalmitgliedschaft Der vom Client verwendete Sicherheitsprinzipal muss in einem ACL-Eintrag für die Zieldatei oder das Zielverzeichnis angezeigt werden. Wenn der ACL-Eintrag nur Sicherheitsgruppen enthält, muss der Prinzipal Mitglied einer dieser Gruppen sein.

  • Korrigieren von Berechtigungen Der ACL-Eintrag, der dem Sicherheitsprinzipal zugeordnet ist, gewährt die entsprechende Berechtigungsstufe für den vorgesehenen Vorgang.

  • Sticky bit is not set ACLs verfügen über eine Einstellung namens Sticky Bit, die ebenfalls 403-Fehler verursachen kann. Wenn das Sticky-Bit in einem Verzeichnis aktiviert ist, kann nur der Besitzer des untergeordneten Elements, der Besitzer des Verzeichnisses oder der Superuser ($superuser) untergeordnete Elemente löschen oder umbenennen. Weitere Informationen finden Sie unter "403 Zugriff verweigert"-Autorisierungsfehler, wenn das Sticky-Bit in ADLS Gen2 aktiviert ist.

Weitere Informationen zu ACLs finden Sie unter Access Control Lists (ACLs) in Azure Data Lake Storage Gen2.

Öffentlicher Netzwerkendpunkt

Wenn der Client beim Zugriff auf ein Speicherkonto über seinen öffentlichen Endpunkt einen Fehler von 403 erhält, überprüfen Sie die folgenden Elemente.

  • Firewallregeln Wenn Firewallregeln aktiviert sind, stellen Sie sicher, dass der Client Anforderungen von einer zulässigen IP-Adresse oder einem Subnetz vornimmt. Wenn das Speicherkonto datenverkehr nur von einem bestimmten virtuellen Netzwerk-Subnetz zulässt, ist jeder Versuch, auf Daten aus einem öffentlichen Netzwerk zuzugreifen, verboten. Wenn ein Benutzer beispielsweise versucht, über das Azure-Portal (das das Netzwerk des Browsers verwendet) oder von einem lokalen Computer aus auf das Speicherkonto zuzugreifen, wird ein Fehler von 403 angezeigt, es sei denn, Sie fügen die IP-Adresse des Browsernetzwerks oder des lokalen Computers zu den IP-Adressregeln hinzu. Siehe Azure Storage-Firewallregeln.

  • Quell- und Zielzugriff Für Vorgänge, die Daten zwischen Speicherkonten kopieren, muss der Client über Netzwerkzugriff auf die Quell- und Zielkonten verfügen.

  • Azure-Dienstzugriff Wenn der Fehler 403 von anderen Diensten stammt, die mit dem Back-End Ihres Speicherkontos interagieren müssen, bestätigen Sie, dass der Dienst als zulässige Ressourceninstanz hinzugefügt wird oder dass eine Netzwerksicherheits ausnahme für vertrauenswürdige Azure-Dienste konfiguriert ist. Siehe Vertrauenswürdige Azure-Dienste.

  • Netzwerksicherheitsperimeterregeln Wenn das Speicherkonto Teil eines Netzwerksicherheitsperimeters ist, überschreiben diese Regeln Firewalleinstellungen. Selbst wenn der Client von der Firewall zugelassen ist, kann eine restriktive Netzwerksicherheitsperimeterregel weiterhin zu einem Fehler von 403 führen. Aktivieren Sie Ressourcenprotokolle, um zu ermitteln, welche Regel das Problem verursacht. Siehe Diagnoseprotokolle für den Netzwerksicherheitsperimeter.

  • Richtlinien für Dienstendpunkte Wenn eine Dienstendpunktrichtlinie für die Ressourcengruppe, das Abonnement oder das Speicherkonto definiert ist, überprüfen Sie die Richtlinienregeln. Entfernen Sie entweder die Richtlinie, oder stellen Sie sicher, dass das Speicherkonto enthalten ist. Änderungen an Dienstendpunktrichtlinien können bis zu 15 Minuten in Kraft treten. Siehe Endpunktrichtlinien für virtuelle Netzwerke für Azure Storage.

Private Endpunkte

Wenn der Client beim Zugriff auf ein Speicherkonto über einen privaten Endpunkt einen Fehler von 403 erhält, überprüfen Sie die folgenden Elemente.

  • Domain Name System (DNS) - Einstellungen Stellen Sie sicher, dass die DNS-Auflösung des Speicherkontonamens auf eine private IP-Adresse erfolgt. Es ist möglich, dass eine DNS-Konfiguration den Storage-Account auf den öffentlichen Endpunkt auflöst. Aktualisieren Sie die DNS-Konfiguration, damit Clients im Netzwerk tatsächlich zum privaten Endpunkt gelangen. Siehe DNS-Änderungen für private Endpunkte.

  • Virtuelle Hub-Netzwerkkonnektivität Zum Kopieren von Blobs zwischen Speicherkonten mit privaten Endpunkten in unterschiedlichen virtuellen Spoke-Netzwerken von einem virtuellen Computer in einem virtuellen Hub-Netzwerk, stellen Sie sicher, dass die Netzwerkkonnektivität besteht und überprüfen Sie die Fehlerprotokolle.CannotVerifyCopySource Siehe Kopieren von Blobs zwischen Speicherkonten in einer Hub-Spoke-Architektur mithilfe privater Endpunkte.

  • Private Endpunkte für jede Speicherressource Stellen Sie sicher, dass das Speicherkonto über private Endpunkte für die Data Lake Storage-Ressource und die Blob Storage-Ressource verfügt. Einige Vorgänge können zwischen Endpunkten umgeleitet werden, sodass beide vorhanden sein müssen.

  • Quell- und Zielzugriff Beim Kopieren von Blobs zwischen Speicherkonten muss der Client über Netzwerkzugriff auf beide Konten verfügen. Wenn Sie nur einen privaten Link für ein Konto verwenden, stellen Sie auch den Netzwerkzugriff auf das andere Konto sicher.

Allgemeine Methoden zur Problembehandlung finden Sie unter "Beheben von Problemen bei der Verbindung mit Azure Private Endpoint".

Verschlüsselungsbereiche

Überprüfen Sie bei verwendung von Verschlüsselungsbereichen die folgenden Elemente.

Deaktivierte Konten

Ein 403-Fehler kann auftreten, wenn Sie versuchen, auf Daten in einem Speicherkonto oder Abonnement zuzugreifen, das deaktiviert ist. Häufige Gründe für ein deaktiviertes Abonnement sind abgelaufene Gutschriften, Erreichen eines Ausgabenlimits, überfällige Rechnungen, Überschreiten Ihres Kreditkartenlimits oder der Kontoadministrator, der das Abonnement storniert.

Azure Databricks und Azure RBAC-Rollenzuweisungen

Ein 403-Fehler kann auftreten, wenn Ihr Abonnement einen Azure Databricks-Namespace enthält. Rollen, die auf das Abonnement beschränkt sind, gewähren keinen Zugriff auf Blob- und Warteschlangendaten. Weisen Sie stattdessen Rollen auf Ressourcengruppe, Speicherkonto, Container oder Warteschlangenebene zu.

Siehe auch

  • Last updated on