ALTER AUTHORIZATION (Transact-SQL)

Anwendungsbereich: JaSQL Server (alle unterstützten Versionen) JaAzure SQL-Datenbank JaVerwaltete Azure SQL-Instanz JaAzure Synapse Analytics JaParallel Data Warehouse

Ändert den Besitz eines sicherungsfähigen Elements.

Symbol für Themenlink Transact-SQL-Syntaxkonventionen

Syntax

-- Syntax for SQL Server
ALTER AUTHORIZATION
    ON [ <class_type>:: ] entity_name
    TO { principal_name | SCHEMA OWNER }
    [;]

<class_type> ::=
     {
      OBJECT | ASSEMBLY | ASYMMETRIC KEY | AVAILABILITY GROUP | CERTIFICATE
    | CONTRACT | TYPE | DATABASE | ENDPOINT | FULLTEXT CATALOG
    | FULLTEXT STOPLIST | MESSAGE TYPE | REMOTE SERVICE BINDING
    | ROLE | ROUTE | SCHEMA | SEARCH PROPERTY LIST | SERVER ROLE
    | SERVICE | SYMMETRIC KEY | XML SCHEMA COLLECTION
     }
-- Syntax for SQL Database

ALTER AUTHORIZATION
    ON [ <class_type>:: ] entity_name
    TO { principal_name | SCHEMA OWNER }
    [;]

<class_type> ::=
     {
    OBJECT | ASSEMBLY | ASYMMETRIC KEY | CERTIFICATE
     | TYPE | DATABASE | FULLTEXT CATALOG
     | FULLTEXT STOPLIST
     | ROLE | SCHEMA | SEARCH PROPERTY LIST
     | SYMMETRIC KEY | XML SCHEMA COLLECTION
     }
-- Syntax for Azure Synapse Analytics

ALTER AUTHORIZATION ON
     [ <class_type> :: ] <entity_name>
     TO { principal_name | SCHEMA OWNER }
    [;]

    <class_type> ::= {
    SCHEMA
     | OBJECT
    }

    <entity_name> ::=
    {
    schema_name
     | [ schema_name. ] object_name
    }
-- Syntax for Parallel Data Warehouse

ALTER AUTHORIZATION ON
     [ <class_type> :: ] <entity_name>
     TO { principal_name | SCHEMA OWNER }
    [;]

<class_type> ::= {
    DATABASE
     | SCHEMA
     | OBJECT
    }

<entity_name> ::=
    {
    database_name
     | schema_name
     | [ schema_name. ] object_name
    }

Hinweis

Diese Syntax wird vom serverlosen SQL-Pool in Azure Synapse Analytics nicht unterstützt.

Hinweis

Informationen zum Anzeigen der Transact-SQL-Syntax für SQL Server 2014 oder früher finden Sie unter Dokumentation zu früheren Versionen.

Argumente

<class_type> Die sicherungsfähige Klasse der Entität, für die der Besitzer geändert wird. OBJECT ist der Standardwert.

Klasse Produkt
OBJECT GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank, Azure Synapse Analytics, Analytics-Plattformsystem (PDW).
ASSEMBLY GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
ASYMMETRIC KEY GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
AVAILABILITY GROUP GILT FÜR: SQL Server 2012 und höher.
CERTIFICATE GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
CONTRACT GILT FÜR: SQL Server 2008 und höher.
DATABASE GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank. Weitere Informationen finden Sie unter ALTER AUTHORIZATION für Datenbanken.
ENDPOINT GILT FÜR: SQL Server 2008 und höher.
FULLTEXT CATALOG GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
FULLTEXT STOPLIST GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
MESSAGE TYPE GILT FÜR: SQL Server 2008 und höher.
REMOTE SERVICE BINDING GILT FÜR: SQL Server 2008 und höher.
ROLE GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
ROUTE GILT FÜR: SQL Server 2008 und höher.
SCHEMA GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank, Azure Synapse Analytics, Analytics-Plattformsystem (PDW).
SEARCH PROPERTY LIST GILT FÜR: SQL Server 2012 (11.x) und höher, Azure SQL-Datenbank.
SERVER ROLE GILT FÜR: SQL Server 2008 und höher.
SERVICE GILT FÜR: SQL Server 2008 und höher.
SYMMETRIC KEY GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
TYPE GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.
XML SCHEMA COLLECTION GILT FÜR: SQL Server 2008 und höher, Azure SQL-Datenbank.

entity_name ist der Name der Entität.

principal_name | SCHEMA OWNER Name des Sicherheitsprinzipals, der die Entität besitzt. Datenbankobjekte müssen im Besitz eines Datenbankprinzipals sein, also ein Datenbankbenutzer oder eine Datenbankrolle. Serverobjekte (beispielsweise Datenbanken) müssen im Besitz eines Serverprinzipals (eines Anmeldenamens) sein. Geben Sie SCHEMA OWNER als *principal_name- an, um anzugeben, dass das Objekt im Besitz des Prinzipals sein sollte, der das Schema des Objekts besitzt.

Bemerkungen

Mit ALTER AUTHORIZATION kann der Besitz einer Entität, die einen Besitzer aufweist, geändert werden. Der Besitz von in der Datenbank enthaltenen Entitäten kann an jeden Prinzipal auf Datenbankebene übertragen werden. Der Besitz von Entitäten auf Serverebene kann nur an Prinzipale auf Serverebene übertragen werden.

Wichtig

Ab SQL Server 2005 (9.x) kann der Benutzer Besitzer eines Objekts oder Typs sein, das bzw. der in einem Schema enthalten ist, dessen Besitzer ein anderer Datenbankbenutzer ist. Dieses Verhalten unterscheidet sich von früheren Versionen von SQL Server. Weitere Informationen finden Sie unter OBJECTPROPERTY (Transact-SQL) und TYPEPROPERTY (Transact-SQL).

Der Besitz der folgenden in einem Schema enthaltenen Entitäten vom Typ "object" kann übertragen werden: Tabellen, Sichten, Funktionen, Prozeduren, Warteschlangen und Synonyme.

Der Besitz der folgenden Entitäten kann nicht übertragen werden: Verbindungsserver, Statistiken, Einschränkungen, Regeln, Standardwerte, Trigger, Service Broker-Warteschlangen, Anmeldeinformationen, Partitionsfunktionen, Partitionsschemas, Datenbank-Hauptschlüssel, Diensthauptschlüssel und Ereignisbenachrichtigungen.

Der Besitz von Mitgliedern der folgenden sicherungsfähigen Klassen kann nicht übertragen werden: Server, Anmeldename, Benutzer, Anwendungsrolle und Spalte.

Die SCHEMA OWNER-Option ist nur gültig, wenn Sie den Besitz einer in einem Schema enthaltenen Entität übertragen. Mit SCHEMA OWNER wird der Besitz der Entität an den Besitzer des Schemas übertragen, in dem sie sich befindet. Nur Entitäten der Klasse OBJECT, TYPE oder XML SCHEMA COLLECTION sind in Schemas enthalten.

Falls es sich bei der Zielentität nicht um eine Datenbank handelt und die Entität an einen neuen Besitzer übertragen wird, werden alle Berechtigungen für das Ziel gelöscht.

Achtung

Das Verhalten der Schemas in SQL Server 2005 (9.x) unterscheidet sich von dem in früheren Versionen von SQL Server. Code, in dem vorausgesetzt wird, dass Schemas Datenbankbenutzern entsprechen, gibt möglicherweise nicht die richtigen Ergebnisse zurück. Alte Katalogsichten, einschließlich „sysobjects“, sollten nicht in einer Datenbank verwendet werden, in der bereits irgendeine der folgenden DDL-Anweisungen verwendet wurde: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. In einer Datenbank, in der jemals eine dieser Anweisungen verwendet wurde, müssen Sie die neuen Katalogsichten verwenden. In den neuen Katalogsichten wird die Trennung zwischen Prinzipalen und Schemas berücksichtigt, die in SQL Server 2005 (9.x) eingeführt wurde. Weitere Informationen zu Katalogansichten finden Sie unter Catalog Views (Transact-SQL) (Katalogansichten (Transact-SQL)).

Beachten Sie dabei außerdem Folgendes:

Wichtig

Die einzig zuverlässige Möglichkeit, den Besitzer eines Objekts zu finden, besteht darin, die sys.objects-Katalogsicht abzufragen. Die einzige zuverlässige Möglichkeit, den Besitzer eines Typs zu finden, besteht in der Verwendung der TYPEPROPERTY-Funktion.

Spezialfälle und Bedingungen

In der folgenden Tabelle sind Spezialfälle, Ausnahmen und Bedingungen aufgeführt, die beim Ändern der Autorisierung gelten.

Klasse Bedingung
OBJECT Der Besitz von Triggern, Einschränkungen, Regeln, Standardwerten, Statistiken, Systemobjekten, Warteschlangen, indizierten Sichten oder Tabellen mit indizierten Sichten kann nicht geändert werden.
SCHEMA Wenn der Besitz übertragen wird, werden Berechtigungen für in einem Schema enthaltene Objekte, die keine expliziten Besitzer aufweisen, gelöscht. Der Besitzer von sys, dbo oder information_schema kann nicht geändert werden.
TYPE Der Besitz eines TYPE-Objekts, das zu sys oder information_schema gehört, kann nicht geändert werden.
CONTRACT, MESSAGE TYPE oder SERVICE Der Besitz von Systementitäten kann nicht geändert werden.
SYMMETRIC KEY Der Besitz von globalen temporären Schlüsseln kann nicht geändert werden.
CERTIFICATE oder ASYMMETRIC KEY Der Besitz dieser Entitäten kann nicht an eine Rolle oder Gruppe übertragen werden.
ENDPOINT Der Prinzipal muss ein Anmeldename sein.

ALTER AUTHORIZATION für Datenbanken

Für SQL Server

Anforderungen für den neuen Besitzer: Der neue Besitzerprinzipal muss einer der folgenden sein:

  • Ein Anmeldename für die SQL Server-Authentifizierung
  • Ein Anmeldename für die Windows-Authentifizierung, der einen Windows-Benutzer (keine Gruppe) darstellt
  • Ein Windows-Benutzer, der sich über einen Anmeldenamen für die Windows-Authentifizierung authentifiziert, der eine Windows-Gruppe darstellt

Anforderungen an die Person, die die ALTER AUTHORIZATION-Anweisung ausführt: Wenn Sie kein Mitglied der festen Serverrolle sysadmin sind, benötigen Sie mindestens die Berechtigung TAKE OWNERSHIP für die Datenbank und die Berechtigung IMPERSONATE für den neuen Besitzeranmeldenamen.

Für Azure SQL-Datenbank

Anforderungen für den neuen Besitzer: Der neue Besitzerprinzipal muss einer der folgenden sein:

  • Ein Anmeldename für die SQL Server-Authentifizierung
  • Ein Verbundbenutzer (keine Gruppe) in Azure AD
  • Ein verwalteter Benutzer (keine Gruppe) oder eine Anwendung in Azure AD

Wenn der neue Besitzer ein Azure Active Directory-Benutzer ist, darf dieser Benutzer nicht in der Datenbank vorhanden sein, für die der neue Besitzer der DBO werden soll. Der Azure AD-Benutzer muss zunächst aus der Datenbank entfernt werden, bevor die ALTER AUTHORIZATION-Anweisung ausgeführt wird, die den Datenbankbesitz auf den neuen Benutzer überträgt. Weitere Informationen zum Konfigurieren von Azure Active Directory-Benutzern mit SQL-Datenbank finden Sie unter Herstellen einer Verbindung mit SQL-Datenbank oder Azure Synapse Analytics mithilfe der Azure Active Directory-Authentifizierung.

Anforderungen an die Person, die die ALTER AUTHORIZATION-Anweisung ausführt: Sie müssen eine Verbindung zur Zieldatenbank herstellen, um den Besitzer der Datenbank zu ändern.

Die folgenden Kontotypen können den Besitzer einer Datenbank ändern.

  • Der Prinzipalanmeldename auf Serverebene (Der SQL Azure-Administrator, der bei der Erstellung des SQL-Datenbankservers bereitgestellt wird.)
  • Der Active Directory-Administrator für den Azure SQL-Server
  • Der aktuelle Besitzer der Datenbank

In der folgenden Tabelle werden die Anforderungen zusammengefasst:

Ausführendes Konto Ziel Ergebnis
Ein Anmeldename für die SQL Server-Authentifizierung Ein Anmeldename für die SQL Server-Authentifizierung Erfolg
Ein Anmeldename für die SQL Server-Authentifizierung Ein Azure AD-Benutzer Fehler
Ein Azure AD-Benutzer Ein Anmeldename für die SQL Server-Authentifizierung Erfolg
Ein Azure AD-Benutzer Ein Azure AD-Benutzer Erfolg

Um den Azure AD-Besitzer der Datenbank zu bestätigen, führen Sie den folgenden Transact-SQL-Befehl in einer Benutzerdatenbank aus (in diesem Beispiel testdb).

SELECT CAST(owner_sid as uniqueidentifier) AS Owner_SID
FROM sys.databases
WHERE name = 'testdb';

Bei der Ausgabe handelt es sich um einen Bezeichner (z. B. 6D8B81F6-7C79-444C-8858-4AF896C03C67), der der Azure AD ObjectID entspricht, die richel@cqclinic.onmicrosoft.com zugewiesen ist. Wenn ein SQL Server-Benutzer, der sich mit Authentifizierung anmeldet, der Datenbankbesitzer ist, führen Sie die folgende Anweisung in der Master-Datenbank aus, um den Datenbankbesitzer zu überprüfen:

SELECT d.name, d.owner_sid, sl.name
FROM sys.databases AS d
JOIN sys.sql_logins AS sl
ON d.owner_sid = sl.sid;

Bewährte Methode

Statt Azure AD-Benutzer als einzelne Datenbankbesitzer zu verwenden, verwenden Sie eine Azure AD-Gruppe als Mitglied der festen Datenbankrolle db_owner. In den folgenden Schritten wird gezeigt, wie ein deaktivierter Anmeldename als Datenbankbesitzer und eine Azure Active Directory-Gruppe (mydbogroup) als Mitglied der db_owner-Rolle konfiguriert wird.

  1. Melden Sie sich als Azure AD-Administrator bei SQL Server an, und ändern Sie den Datenbankbesitzer in einen deaktivierten Anmeldenamen für die SQL Server-Authentifizierung. Führen Sie über die Benutzerdatenbank z.B. Folgendes aus:

    ALTER AUTHORIZATION ON database::testdb TO DisabledLogin;
    
  2. Erstellen Sie eine Azure AD-Gruppe, die Datenbankbesitzer werden soll, und fügen Sie sie als Benutzer zur Benutzerdatenbank hinzu. Beispiel:

    CREATE USER [mydbogroup] FROM EXTERNAL PROVIDER;
    
  3. Fügen Sie den Benutzer, der die Azure AD-Gruppe darstellt, in der Benutzerdatenbank zur festen Datenbankrolle db_owner hinzu. Beispiel:

    ALTER ROLE db_owner ADD MEMBER mydbogroup;
    

Nun können die mydbogroup-Mitglieder die Datenbank als Mitglieder der db_owner-Rolle zentral verwalten.

  • Wenn Mitglieder dieser Gruppe aus der Azure AD-Gruppe entfernt werden, verlieren sie automatisch die DBO-Berechtigungen für diese Datenbank.
  • Auch wenn neue Mitglieder zur mydbogroup-Azure AD-Gruppe hinzugefügt werden, erhalten sie automatisch DBO-Zugriff auf diese Datenbank.

Um festzustellen, ob ein bestimmter Benutzer über die effektive DBO-Berechtigung verfügt, muss der Benutzer folgende Anweisung ausführen:

SELECT IS_MEMBER ('db_owner');

Lautet der Rückgabewert 1, bedeutet dies, dass der Benutzer ein Mitglied der Rolle ist.

Berechtigungen

Erfordert die TAKE OWNERSHIP-Berechtigung für die Entität. Falls der neue Besitzer nicht der Benutzer ist, der diese Anweisung ausführt, ist zudem eine der folgenden Berechtigungen erforderlich: 1) IMPERSONATE-Berechtigung für den neuen Besitzer, falls es sich um einen Benutzer oder einen Anmeldenamen handelt. Oder: 2) Falls der neue Besitzer eine Rolle ist, Mitgliedschaft in der Rolle oder ALTER-Berechtigung in der Rolle. Oder: 3) Falls der neue Besitzer eine Anwendungsrolle ist, ALTER-Berechtigung in der Anwendungsrolle.

Beispiele

A. Übertragen des Besitzes einer Tabelle

Im folgenden Beispiel wird der Besitz der Sprockets-Tabelle an den Benutzer MichikoOsada übertragen. Die Tabelle befindet sich im Parts-Schema.

ALTER AUTHORIZATION ON OBJECT::Parts.Sprockets TO MichikoOsada;
GO

Die Abfrage kann auch folgendermaßen aussehen:

ALTER AUTHORIZATION ON Parts.Sprockets TO MichikoOsada;
GO

Wenn das Objektschema kein Bestandteil der Anweisung ist, sucht die Datenbank-Engine das Objekt im Standardschema des Benutzers. Beispiel:

ALTER AUTHORIZATION ON Sprockets TO MichikoOsada;
ALTER AUTHORIZATION ON OBJECT::Sprockets TO MichikoOsada;

B. Übertragen des Besitzes einer Sicht an den Schemabesitzer

Im folgenden Beispiel wird der Besitz der ProductionView06-Sicht an den Besitzer des Schemas übertragen, das sie enthält. Die Sicht befindet sich im Production-Schema.

ALTER AUTHORIZATION ON OBJECT::Production.ProductionView06 TO SCHEMA OWNER;
GO

C. Übertragen des Besitzes eines Schemas an einen Benutzer

Im folgenden Beispiel wird der Besitz des SeattleProduction11-Schemas an den Benutzer SandraAlayo übertragen.

ALTER AUTHORIZATION ON SCHEMA::SeattleProduction11 TO SandraAlayo;
GO

D: Übertragen des Besitzes für einen Endpunkt an einen SQL Server-Anmeldenamen

Im folgenden Beispiel wird der Besitz des CantabSalesServer1-Endpunkts auf JaePak übertragen. Da es sich bei dem Endpunkt um ein sicherungsfähiges Element auf Serverebene handelt, kann der Endpunkt nur an einen Prinzipal auf Serverebene übertragen werden.

Gilt für: SQL Server 2008 und höher.

ALTER AUTHORIZATION ON ENDPOINT::CantabSalesServer1 TO JaePak;
GO

E. Ändern eines Tabellenbesitzers

In jedem der folgenden Beispiele wird der Besitzer der Sprockets-Tabelle in der Parts-Datenbank in den Datenbankbenutzer MichikoOsada geändert.

ALTER AUTHORIZATION ON Sprockets TO MichikoOsada;
ALTER AUTHORIZATION ON dbo.Sprockets TO MichikoOsada;
ALTER AUTHORIZATION ON OBJECT::Sprockets TO MichikoOsada;
ALTER AUTHORIZATION ON OBJECT::dbo.Sprockets TO MichikoOsada;

F. Ändern eines Datenbankbesitzers

GILT FÜR: SQL Server 2008 und höher, Analytics-Plattformsystem (PDW), SQL-Datenbank.

Im folgenden Beispiel wird der Besitzer der Parts-Datenbank in den Anmeldenamen MichikoOsada geändert.

ALTER AUTHORIZATION ON DATABASE::Parts TO MichikoOsada;

G. Ändern des Besitzers einer SQL-Datenbank in einen Azure AD-Benutzer

Im folgenden Beispiel kann ein Azure Active Directory-Administrator für SQL Server in einer Organisation mit einer Active Directory namens cqclinic.onmicrosoft.com den aktuellen Besitzer der Datenbank targetDB ändern und den AAD-Benutzer richel@cqclinic.onmicorsoft.com zum neuen Datenbankbesitzer machen. Dazu muss er den folgenden Befehl ausführen:

ALTER AUTHORIZATION ON database::targetDB TO [rachel@cqclinic.onmicrosoft.com];

Für Azure AD müssen eckige Klammern [] den Benutzernamen umschließen.

Weitere Informationen

OBJECTPROPERTY (Transact-SQL) TYPEPROPERTY (Transact-SQL) EVENTDATA (Transact-SQL)