Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Arbeiten mit selbstverwaltetem Active Directory mit einer DB-Instance von Amazon RDS für SQL Server
Amazon RDS für SQL Server lässt sich nahtlos in Ihre selbstverwaltete Active Directory (AD)-Domain integrieren, unabhängig davon, wo Ihr AD gehostet wird – in Ihrem Rechenzentrum, in Amazon EC2 oder bei anderen Cloud-Anbietern. Diese Integration ermöglicht die direkte Benutzerauthentifizierung über NTLM- oder Kerberos-Protokolle, sodass keine komplexen Zwischen-Domains oder Gesamtstruktur-Vertrauensstellungen erforderlich sind. Wenn Sie eine Verbindung zu Ihrer DB-Instance von RDS für SQL Server herstellen, werden Authentifizierungsanfragen sicher an Ihre angegebene AD-Domain weitergeleitet, wobei Ihre bestehende Identitätsverwaltungsstruktur beibehalten und gleichzeitig die verwalteten Datenbankfunktionen von Amazon RDS genutzt werden.
**Topics**
+ [Verfügbarkeit von Regionen und Versionen](#USER_SQLServer_SelfManagedActiveDirectory.RegionVersionAvailability)
+ [Voraussetzungen](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md)
+ [Überlegungen](#USER_SQLServer_SelfManagedActiveDirectory.Limitations)
+ [Einrichten eines selbstverwalteten Active Directory](USER_SQLServer_SelfManagedActiveDirectory.SettingUp.md)
+ [Hinzufügen Ihrer DB-Instance zu Ihrem selbstverwalteten Active Directory](USER_SQLServer_SelfManagedActiveDirectory.Joining.md)
+ [Verwalten einer DB-Instance in einer selbstverwalteten Active-Directory-Domain](USER_SQLServer_SelfManagedActiveDirectory.Managing.md)
+ [Grundlegendes zur Mitgliedschaft in einer selbstverwalteten Active-Directory-Domain](#USER_SQLServer_SelfManagedActiveDirectory.Understanding)
+ [Fehlerbehebung für selbstverwaltetes Active Directory](USER_SQLServer_SelfManagedActiveDirectory.TroubleshootingSelfManagedActiveDirectory.md)
+ [Wiederherstellen einer SQL-Server-DB-Instance und Hinzufügen zu einer selbstverwalteten Active-Directory-Domain](#USER_SQLServer_SelfManagedActiveDirectory.Restore)
## Verfügbarkeit von Regionen und Versionen
Amazon RDS unterstützt selbstverwaltetes AD für SQL Server mit NTLM und Kerberos in allen kommerziellen und. AWS-Regionen AWS GovCloud (US) Regions
# Voraussetzungen
Stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind, bevor Sie eine RDS-für-SQL-Server-DB-Instance Ihrer selbstverwalteten AD-Domain hinzufügen.
**Topics**
+ [Konfigurieren Ihres On-Premises-AD](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.OnPremConfig)
+ [Konfigurieren Ihrer Netzwerkkonnektivität](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig)
+ [Konfigurieren Ihres AD-Domain-Servicekontos](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig)
+ [Konfigurieren der sicheren Kommunikation über LDAPS](#USER_SQLServer_SelfManagedActiveDirectory.Requirements.LDAPS)
## Konfigurieren Ihres On-Premises-AD
Stellen Sie sicher, dass Sie über ein On-Premises-AD oder ein anderes selbstverwaltetes Microsoft-AD verfügen, der Sie die Amazon-RDS-für-SQL- Server-Instance hinzufügen können. Ihr On-Premises-AD sollte folgende Konfiguration aufweisen:
+ Wenn Sie AD-Standorte definiert haben, stellen Sie sicher, dass die Subnetze in der VPC, die Ihrer DB-Instance von RDS für SQL Server zugeordnet sind, an Ihrem AD-Standort definiert sind. Vergewissern Sie sich, dass keine Konflikte zwischen den Subnetzen in Ihrer VPC und den Subnetzen an Ihren anderen AD-Standorten bestehen.
+ Ihr AD-Domain-Controller weist die Domain-Funktionsebene Windows Server 2008 R2 oder höher auf.
+ Ihr AD-Domain-Name darf nicht im SLD-Format (Single Label Domain) vorliegen. RDS für SQL Server unterstützt keine SLD-Domains.
+ Der vollständig qualifizierte Domain-Name (Fully Qualified Domain Name, FQDN) für Ihr AD darf 47 Zeichen nicht überschreiten.
## Konfigurieren Ihrer Netzwerkkonnektivität
Stellen Sie sicher, dass die folgenden Netzwerkkonfigurationsanforderungen erfüllt sind:
+ Die Konnektivität zwischen der Amazon VPC, in der Sie die DB-Instance von RDS für SQL Server erstellen möchten, und Ihrem selbstverwalteten AD wurde konfiguriert. Sie können Konnektivität über AWS Direct Connect, AWS VPN, VPC-Peering oder AWS Transit Gateway einrichten.
+ Für VPC-Sicherheitsgruppen wurde die Standardsicherheitsgruppe für Ihre standardmäßige Amazon VPC bereits in der Konsole zu Ihrer RDS-für-SQL-Server-DB-Instance hinzugefügt. Stellen Sie sicher, dass die Sicherheitsgruppe und das VPC-Netzwerk ACLs für die Subnetze, in denen Sie Ihre RDS for SQL Server-DB-Instance erstellen, Datenverkehr auf den Ports und in den Anweisungen zulassen, die in der folgenden Abbildung dargestellt sind.
![\[Selbstverwaltetes AD – Netzwerkkonfiguration – Portregeln.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/SQLServer_SelfManagedActiveDirectory_Requirements_NetworkConfig.png)
In der folgenden Tabelle ist die Rolle der einzelnen Ports aufgeführt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/USER_SQLServer_SelfManagedActiveDirectory.Requirements.html)
+ Im Allgemeinen befinden sich die Domain-DNS-Server in den AD-Domain-Controllern. Zur Verwendung dieser Funktion müssen Sie den VPC-DHCP-Optionssatz nicht konfigurieren. Weitere Informationen finden Sie unter [DHCP-Optionssätze](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) im *Amazon-VPC-Benutzerhandbuch*.
**Wichtig**
Wenn Sie ein VPC-Netzwerk verwenden ACLs, müssen Sie auch ausgehenden Datenverkehr auf dynamischen Ports (49152-65535) von Ihrer RDS for SQL Server-DB-Instance zulassen. Stellen Sie sicher, dass sich diese Datenverkehrsregeln auch auf den Firewalls widerspiegeln, die für die einzelnen AD-Domain-Controller, DNS-Server und RDS-für-SQL-Server-DB-Instances gelten.
Während für VPC-Sicherheitsgruppen Ports nur in der Richtung geöffnet werden müssen, in der der Netzwerkverkehr initiiert wird, ACLs erfordern die meisten Windows-Firewalls und VPC-Netzwerke, dass Ports in beide Richtungen geöffnet sind.
## Konfigurieren Ihres AD-Domain-Servicekontos
Stellen Sie sicher, dass die folgenden Anforderungen für ein AD-Domain-Servicekonto erfüllt sind:
+ Stellen Sie sicher, dass Sie in Ihrer selbstverwalteten AD-Domain über ein Domain-Servicekonto mit delegierten Berechtigungen zum Hinzufügen von Computern zu der Domain verfügen. Ein Domain-Servicekonto ist ein Benutzerkonto in Ihrem selbstverwalteten AD, an das die Berechtigung zur Ausführung bestimmter Aufgaben delegiert wurde.
+ An das Domain-Servicekonto müssen in der Organisationseinheit, der Sie Ihre RDS-für-SQL-Server-DB-Instance hinzufügen, die folgenden Berechtigungen delegiert werden:
+ Überprüfte Fähigkeit zum Schreiben in den DNS-Hostnamen
+ Überprüfte Fähigkeit zum Schreiben in den Prinzipalnamen des Service
+ Erstellen und Löschen von Computerobjekten
Dies sind die erforderlichen Mindestberechtigungen, um Computerobjekte zu Ihrem selbstverwalteten AD hinzuzufügen. Weitere Informationen finden Sie unter [Fehler beim Versuch, Computer einer Domain hinzuzufügen](https://learn.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers) in der Dokumentation zu Microsoft Windows Server.
+ Um die Kerberos-Authentifizierung zu verwenden, müssen Sie Ihrem AD-Domänendienstkonto Service Principal Names (SPNs) und DNS-Berechtigungen zuweisen:
+ **SPN schreiben**: Delegieren Sie die Berechtigung **SPN Schreiben** an das AD-Domain-Servicekonto in der Organisationseinheit, in der Sie der DB-Instance von RDS für SQL Server beitreten müssen. Diese Berechtigungen unterscheiden sich von validierten SPN-Schreibvorgängen.
+ **DNS-Berechtigungen**: Geben Sie die folgenden Berechtigungen für das AD-Domain-Servicekonto im DNS-Manager auf Serverebene für Ihren Domain-Controller ein:
+ Inhalt auflisten
+ Alle Eigenschaften lesen
+ Berechtigungen lesen
**Wichtig**
Verschieben Sie keine Computerobjekte, die RDS für SQL Server in der Organisationseinheit erstellt, nachdem Ihre DB-Instance erstellt wurde. Wenn Sie die zugehörigen Objekte verschieben, wird Ihre RDS-für-SQL-Server-DB-Instance falsch konfiguriert. Wenn Sie die von Amazon RDS erstellten Computerobjekte verschieben müssen, verwenden Sie den Vorgang [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API, um die Domänenparameter mit dem gewünschten Speicherort der Computerobjekte zu ändern.
## Konfigurieren der sicheren Kommunikation über LDAPS
Die Kommunikation über LDAPS wird für RDS zur Abfrage und zum Zugriff auf Computerobjekte sowie SPNs im Domänencontroller empfohlen. Um sicheres LDAP zu nutzen, verwenden Sie ein gültiges SSL-Zertifikat auf Ihrem Domain-Controller, das die Anforderungen für sicheres LDAPS erfüllt. Wenn auf dem Domain-Controller kein gültiges SSL-Zertifikat vorhanden ist, verwendet die DB-Instance von RDS für SQL Server standardmäßig LDAP. Weitere Informationen zur Gültigkeit von Zertifikaten finden Sie unter [Requirements for an LDAPS certificate](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority#requirements-for-an-ldaps-certificate).
## Überlegungen
Beachten Sie Folgendes, wenn Sie eine DB-Instance von RDS für SQL Server zu einem selbstverwalteten AD hinzufügen:
+ Ihre DB-Instances werden mit dem AWS NTP-Dienst und nicht mit dem Zeitserver der AD-Domain synchronisiert. Für Datenbankverbindungen zwischen verknüpften SQL-Server-Instances innerhalb Ihrer AD-Domain können Sie nur die SQL-Authentifizierung und nicht die Windows-Authentifizierung verwenden.
+ Gruppenrichtlinienobjekteinstellungen aus Ihrer selbstverwalteten AD-Domäne werden nicht an Ihre RDS für SQL Server-Instanzen weitergegeben.
# Einrichten eines selbstverwalteten Active Directory
Gehen Sie wie folgt vor, um ein selbstverwaltetes AD einzurichten.
**Topics**
+ [Schritt 1: Erstellen einer Organisationseinheit in Ihrem AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateOU)
+ [Schritt 2: Erstellen eines AD-Domain-Servicekontos in Ihrem AD](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateADuser)
+ [Schritt 3: Delegieren der Kontrolle an das AD-Domain-Servicekonto](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.DelegateControl)
+ [Schritt 4: Erstellen Sie einen Schlüssel AWS KMS](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateKMSkey)
+ [Schritt 5: Erstellen Sie ein AWS Geheimnis](#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateSecret)
## Schritt 1: Erstellen einer Organisationseinheit in Ihrem AD
**Wichtig**
Wir empfehlen, für jedes AWS Konto, das eine RDS for SQL Server-DB-Instance besitzt, die Ihrer selbstverwalteten AD-Domäne beigetreten ist, eine dedizierte Organisationseinheit und Dienstanmeldedaten zu erstellen, die auf diese Organisationseinheit beschränkt sind. Durch die Zuordnung einer Organisationseinheit und von Service-Anmeldeinformationen können Sie widersprüchliche Berechtigungen vermeiden und dem Prinzip der geringsten Berechtigung folgen.
**So erstellen Sie eine Organisationseinheit in Ihrem AD**
1. Stellen Sie als Domain-Administrator eine Verbindung zu Ihrer AD-Domain her.
1. Öffnen Sie **Active Directory-Benutzer und -Computer** und wählen Sie die Domain aus, in der Sie Ihre Organisationseinheit erstellen möchten.
1. Klicken Sie mit der rechten Maustaste auf die Domain und wählen Sie **Neu** und dann **Organisationseinheit** aus.
1. Geben Sie einen Namen für die Organisationseinheit ein.
1. Lassen Sie das Kontrollkästchen für **Container vor versehentlichem Löschen schützen** aktiviert.
1. Klicken Sie auf **OK**. Ihre neue Organisationseinheit wird unter Ihrer Domain angezeigt.
## Schritt 2: Erstellen eines AD-Domain-Servicekontos in Ihrem AD
Die Anmeldeinformationen des Domänendienstkontos werden für das Geheimnis in AWS Secrets Manager verwendet.
**So erstellen Sie ein AD-Domain-Servicekonto in Ihrem AD**
1. Öffnen Sie **Active-Directory-Benutzer und -Computer** und wählen Sie die Domain und die Organisationseinheit aus, in der Sie Ihren Benutzer erstellen möchten.
1. Klicken Sie mit der rechten Maustaste auf das Objekt **Benutzer** und wählen Sie **Neu** und dann **Benutzer** aus.
1. Geben Sie einen Vornamen, Nachnamen und Anmeldenamen für den Benutzer ein. Klicken Sie auf **Weiter**.
1. Geben Sie ein Passwort für den Benutzer ein. Wählen Sie nicht **Benutzer muss das Passwort bei der nächsten Anmeldung ändern** aus. Wählen Sie nicht **Konto ist deaktiviert** aus. Klicken Sie auf **Weiter**.
1. Klicken Sie auf **OK**. Ihr neuer Benutzer wird unter Ihrer Domain angezeigt.
## Schritt 3: Delegieren der Kontrolle an das AD-Domain-Servicekonto
**So delegieren Sie die Kontrolle an das AD-Domain-Servicekonto in Ihrer Domain**
1. Öffnen Sie das MMC-Snap-In **Active-Directory-Benutzer und -Computer** und wählen Sie die Domain aus, in der Sie Ihren Benutzer erstellen möchten.
1. Klicken Sie mit der rechten Maustaste auf die Organisationseinheit, die Sie zuvor erstellt haben, und wählen Sie **Kontrolle delegieren** aus.
1. Klicken Sie im **Assistenten für die Delegation der Kontrolle** auf **Weiter**.
1. Klicken Sie im Abschnitt **Benutzer oder Gruppen** auf **Hinzufügen**.
1. Geben Sie im Abschnitt **Benutzer, Computer oder Gruppen auswählen** das von Ihnen erstellte AD-Domain-Servicekonto ein und klicken Sie auf **Namen überprüfen**. Wenn Ihre AD-Domain-Servicekontoprüfung erfolgreich ist, klicken Sie auf **OK**.
1. Bestätigen Sie im Abschnitt **Benutzer oder Gruppen**, dass Ihr AD-Domain-Servicekonto hinzugefügt wurde, und klicken Sie auf **Weiter**.
1. Wählen Sie im Abschnitt **Zu delegierende Aufgaben** die Option **Eine zu delegierende benutzerdefinierte Aufgabe erstellen** aus und klicken Sie auf **Weiter**.
1. Gehen Sie im Abschnitt **Active-Directory-Objekttyp** wie folgt vor:
1. Wählen Sie **Nur die folgenden Objekte in dem Ordner** aus.
1. Wählen Sie **Computerobjekte** aus.
1. Wählen Sie **Ausgewählte Objekte in diesem Ordner erstellen** aus.
1. Wählen Sie **Ausgewählte Objekte in diesem Ordner löschen** aus und klicken Sie auf **Weiter**.
1. Gehen Sie im Abschnitt **Berechtigungen** wie folgt vor:
1. Behalten Sie die Auswahl von **Allgemein** bei.
1. Wählen Sie **Überprüfter Schreibvorgang in den DNS-Hostnamen** aus.
1. Wählen Sie **Überprüfter Schreibvorgang in den Service-Prinzipalnamen** aus und klicken Sie auf **Weiter**.
1. Um die Kerberos-Authentifizierung zu aktivieren, lassen Sie die Option **Eigenschaftsspezifisch** aktiviert und wählen Sie in der Liste die Option **Schreiben servicePrincipalName** aus.
1. Überprüfen und bestätigen Sie Ihre Einstellungen unter **Den Assistenten für die Delegation der Kontrolle abschließen** und klicken Sie auf **Fertig stellen**.
1. Öffnen Sie für die Kerberos-Authentifizierung den DNS-Manager und dann die **Servereigenschaften**.
1. Geben Sie im Windows-Dialogfeld `dnsmgmt.msc` ein.
1. Fügen Sie das AD-Domain-Servicekonto auf der Registerkarte **Sicherheit** hinzu.
1. Wählen Sie die Berechtigung **Lesen** aus und übernehmen Sie Ihre Änderungen.
## Schritt 4: Erstellen Sie einen Schlüssel AWS KMS
Der KMS-Schlüssel wird verwendet, um Ihr AWS Geheimnis zu verschlüsseln.
**Um einen Schlüssel zu erstellen AWS KMS**
**Anmerkung**
Verwenden Sie für den **Verschlüsselungsschlüssel** nicht den AWS Standard-KMS-Schlüssel. Stellen Sie sicher, dass Sie den AWS KMS Schlüssel in demselben AWS Konto erstellen, das die RDS for SQL Server-DB-Instance enthält, die Sie Ihrem selbstverwalteten AD hinzufügen möchten.
1. Wählen Sie in der AWS KMS Konsole **Create Key** aus.
1. Wählen Sie für **Schlüsseltyp** **Symmetrisch** aus.
1. Wählen Sie für **Schlüsselnutzung** die Option **Verschlüsseln und Entschlüsseln** aus.
1. Für **Advanced options (Erweiterte Optionen)**:
1. Wählen Sie unter **Schlüsselmaterialursprung** **KMS** aus.
1. Wählen Sie für **Regionalität** **Single-Region-Schlüssel** aus und klicken Sie auf **Weiter**.
1. Geben Sie für **Alias** einen Namen für den KMS-Schlüssel an.
1. (Optional) Geben Sie unter **Beschreibung** eine Beschreibung des KMS-Schlüssels an.
1. (Optional) Geben Sie für **Tags** ein Tag für den KMS-Schlüssel an und klicken Sie auf **Weiter**.
1. Geben Sie für **Schlüsseladministratoren** den Namen eines IAM-Benutzers an und wählen Sie ihn aus.
1. Lassen Sie für **Schlüssellöschung** das Kontrollkästchen für **Ermöglicht Schlüsseladministratoren das Löschen dieses Schlüssels** aktiviert und klicken Sie auf **Weiter**.
1. Geben Sie für **Schlüsselbenutzer** den IAM-Benutzer aus dem vorherigen Schritt an und wählen Sie ihn aus. Klicken Sie auf **Weiter**.
1. Prüfen Sie die Konfiguration.
1. Fügen Sie für **Schlüsselrichtlinie** Folgendes zur Richtlinien-**Anweisung** hinzu:
```
{
"Sid": "Allow use of the KMS key on behalf of RDS",
"Effect": "Allow",
"Principal": {
"Service": [
"rds.amazonaws.com"
]
},
"Action": "kms:Decrypt",
"Resource": "*"
}
```
1. Klicken Sie auf **Beenden**.
## Schritt 5: Erstellen Sie ein AWS Geheimnis
**So erstellen Sie ein Secret**
**Anmerkung**
Stellen Sie sicher, dass Sie das Geheimnis in demselben AWS Konto erstellen, das die RDS for SQL Server-DB-Instance enthält, die Sie Ihrem selbstverwalteten AD hinzufügen möchten.
1. Wählen Sie im AWS Secrets Manager die Option **Neues Geheimnis speichern** aus.
1. Als **Secret-Typ** wählen Sie **Anderer Secret-Typ** aus.
1. Fügen Sie für **Schlüssel/Wert-Paare** Ihre beiden Schlüssel hinzu:
1. Geben Sie als ersten Schlüssel `SELF_MANAGED_ACTIVE_DIRECTORY_USERNAME` ein.
1. Geben Sie als Wert für den ersten Schlüssel nur den Benutzernamen (ohne das Domain-Präfix) des AD-Benutzers ein. Geben Sie den Domain-Namen nicht an, da dies dazu führt, dass die Instance-Erstellung fehlschlägt.
1. Geben Sie als zweiten Schlüssel `SELF_MANAGED_ACTIVE_DIRECTORY_PASSWORD` ein.
1. Geben Sie als Wert des zweiten Schlüssels das Passwort ein, das Sie für den AD-Benutzer in Ihrer Domain erstellt haben.
1. Geben Sie als **Verschlüsselungsschlüssel** den KMS-Schlüssel ein, den Sie in einem vorherigen Schritt erstellt haben, und klicken Sie auf **Weiter**.
1. Geben Sie als **Secret-Name** einen aussagekräftigen Namen ein, anhand dessen Sie das Secret später leichter finden können.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für den Secret-Namen ein.
1. Klicken Sie unter **Ressourcenberechtigung** auf **Bearbeiten**.
1. Fügen Sie der Berechtigungsrichtlinie folgende Richtlinie hinzu:
**Anmerkung**
Wir empfehlen Ihnen, die `aws:sourceAccount` und `aws:sourceArn` Bedingungen in der Police zu verwenden, um das Problem des *verwirrten Vertreters* zu vermeiden. Verwenden Sie Ihre AWS-Konto für `aws:sourceAccount` und die RDS for SQL Server-DB-Instance ARN für`aws:sourceArn`. Weitere Informationen finden Sie unter [Vermeidung des dienstübergreifenden Confused-Deputy-Problems](cross-service-confused-deputy-prevention.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"Service": "rds.amazonaws.com"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*",
"Condition":
{
"StringEquals":
{
"aws:sourceAccount": "123456789012"
},
"ArnLike":
{
"aws:sourceArn": "arn:aws:rds:us-west-2:123456789012:db:*"
}
}
}
]
}
```
------
1. Klicken Sie auf **Speichern** und dann auf **Weiter**.
1. Behalten Sie für **Rotationseinstellungen konfigurieren** die Standardwerte bei und wählen Sie **Weiter** aus.
1. Überprüfen Sie die Einstellungen für das Secret und klicken Sie auf **Speichern**.
1. Wählen Sie das von Ihnen erstellte Secret aus und kopieren Sie den Wert für den **Secret-ARN**. Dieser wird im nächsten Schritt bei der Einrichtung des selbstverwalteten Active Directory verwendet.
# Hinzufügen Ihrer DB-Instance zu Ihrem selbstverwalteten Active Directory
Gehen Sie wie folgt vor, um Ihre DB-Instance von RDS für SQL Server zu Ihrem selbstverwalteten AD hinzuzufügen:
## Schritt 1: Erstellen oder Ändern einer SQL Server-DB-Instance
Sie können die Konsole, die CLI oder die RDS-API verwenden, um eine RDS-für- SQL-Server-DB-Instance mit einer selbstverwalteten AD-Domain zu verknüpfen. Sie können dafür eine der folgenden Möglichkeiten auswählen:
+ Erstellen Sie mit der Konsole, dem [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI-Befehl oder dem Vorgang [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API eine neue SQL Server-DB-Instance.
Detaillierte Anweisungen finden Sie unter [Erstellen einer Amazon-RDS-DB-Instance](USER_CreateDBInstance.md).
+ Ändern Sie eine vorhandene SQL Server-DB-Instance mithilfe der Konsole, des [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI-Befehls oder der Operation [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API.
Detaillierte Anweisungen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md).
+ Stellen Sie mithilfe der Konsole, des CLI-Befehls -db-snapshot oder des API-Vorgangs Restore From DBSnapshot RDS eine SQL [restore-db-instance-fromServer-DB-Instance DBInstance aus einem DB-Snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) [wieder her](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html).
Detaillierte Anweisungen finden Sie unter [Wiederherstellen auf eine DB-Instance](USER_RestoreFromSnapshot.md).
+ Stellen Sie eine SQL Server-DB-Instance point-in-time mithilfe der Konsole, des Befehls [restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI oder der Operation [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API in einer wieder her.
Detaillierte Anweisungen finden Sie unter [Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md).
Wenn Sie den verwenden AWS CLI, sind die folgenden Parameter erforderlich, damit die DB-Instance die von Ihnen erstellte selbstverwaltete AD-Domäne verwenden kann:
+ Verwenden Sie für den Parameter `--domain-fqdn` den vollständig qualifizierten Domain-Namen (FQDN) Ihres selbstverwalteten AD.
+ Verwenden Sie für den Parameter `--domain-ou` die Organisationseinheit, die Sie in Ihrem selbstverwalteten AD erstellt haben.
+ Verwenden Sie für den Parameter `--domain-auth-secret-arn` den Wert des **Secret-ARN**, den Sie in einem vorherigen Schritt erstellt haben.
+ Verwenden Sie für den `--domain-dns-ips` Parameter die primären und sekundären IPv4 Adressen der DNS-Server für Ihr selbstverwaltetes AD. Wenn Sie keine sekundäre DNS-Server-IP-Adresse haben, geben Sie die primäre IP-Adresse zweimal ein.
Die folgenden CLI-Beispielbefehle zeigen, wie Sie eine RDS-für-SQL-Server-DB-Instance mit einer selbstverwalteten AD-Domain erstellen, ändern und entfernen.
**Wichtig**
Wenn Sie eine DB-Instance ändern, um sie einer selbstverwalteten AD-Domain hinzuzufügen oder aus dieser zu entfernen, ist ein Neustart der DB-Instance erforderlich, damit die Änderung wirksam wird. Sie können wählen, ob Sie die Änderungen sofort übernehmen oder bis zum nächsten Wartungsfenster warten möchten. Wenn Sie die Option **Sofort anwenden** auswählen, führt dies bei einer Single-AZ-DB-Instance zu Ausfallzeiten. Eine Multi-AZ-DB-Instance führt ein Failover durch, bevor ein Neustart ausgeführt wird. Weitere Informationen finden Sie unter [Verwenden der Einstellung „Planen von Änderungen“](USER_ModifyInstance.ApplyImmediately.md).
Mit dem folgenden CLI-Befehl wird eine neue RDS-für-SQL-Server-DB-Instance erstellt und einer selbstverwalteten AD-Domain hinzugefügt.
Für Linux, macOS oder Unix:
```
aws rds create-db-instance \
--db-instance-identifier my-DB-instance \
--db-instance-class db.m5.xlarge \
--allocated-storage 50 \
--engine sqlserver-se \
--engine-version 15.00.4043.16.v1 \
--license-model license-included \
--master-username my-master-username \
--master-user-password my-master-password \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Für Windows:
```
aws rds create-db-instance ^
--db-instance-identifier my-DB-instance ^
--db-instance-class db.m5.xlarge ^
--allocated-storage 50 ^
--engine sqlserver-se ^
--engine-version 15.00.4043.16.v1 ^
--license-model license-included ^
--master-username my-master-username ^
--master-user-password my-master-password ^
--domain-fqdn my-AD-test.my-AD.mydomain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \ ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Mit dem folgenden CLI-Befehl wird eine vorhandene DB-Instance von RDS für SQL Server, so geändert, dass sie eine selbstverwaltete AD-Domain verwendet.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--domain-fqdn my_AD_domain.my_AD.my_domain \
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" \
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DBinstance ^
--domain-fqdn my_AD_domain.my_AD.my_domain ^
--domain-ou OU=my-AD-test-OU,DC=my-AD-test,DC=my-AD,DC=my-domain ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:my-AD-test-secret-123456" ^
--domain-dns-ips "10.11.12.13" "10.11.12.14"
```
Mit dem folgenden CLI-Befehl wird eine DB-Instance von RDS für SQL Server aus einer selbstverwalteten AD-Domain entfernt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-DB-instance \
--disable-domain
```
Für Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my-DB-instance ^
--disable-domain
```
## Schritt 2: Verwenden der Kerberos- oder NTLM-Authentifizierung
### NTLM-Authentifizierung
Jede DB-Instance von Amazon RDS hat einen Endpunkt und jeder Endpunkt hat einen DNS-Namen und eine Portnummer für die DB-Instance. Um eine Verbindung mir Ihrer DB-Instance mit einer SQL-Client-Anwendung herzustellen, benötigen Sie den DNS-Namen und die Portnummer für Ihre DB-Instance. Um sich mithilfe der NTLM-Authentifizierung zu authentifizieren, müssen Sie eine Verbindung zum RDS-Endpunkt oder zum Listener-Endpunkt herstellen, wenn Sie eine Multi-AZ-Bereitstellung verwenden.
Während einer geplanten Datenbankwartung oder einer ungeplanten Serviceunterbrechung führt Amazon RDS automatisch einen Failover zur up-to-date sekundären Datenbank durch, sodass der Betrieb schnell und ohne manuelles Eingreifen wieder aufgenommen werden kann. Die primären und sekundären Instances verwenden denselben Endpunkt, dessen physische Netzwerkadresse als Teil des Failover-Prozesses an das sekundäre Replikat übergeben wird. Sie müssen Ihre Anwendung nicht neu konfigurieren, wenn ein Failover auftritt.
### Kerberos-Authentifizierung
Für die Kerberos-basierte Authentifizierung für RDS für SQL Server müssen Verbindungen zu einem bestimmten Service-Prinzipalnamen (SPN) hergestellt werden. Nach einem Failover-Ereignis ist der Anwendung der neue SPN jedoch möglicherweise nicht bekannt. Um dieses Problem zu lösen, bietet RDS für SQL Server einen Kerberos-basierten Endpunkt.
Der Kerberos-basierte Endpunkt folgt einem bestimmten Format. Wenn Ihr RDS-Endpunkt `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com` ist, wäre `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)` der entsprechende Kerberos-basierte Endpunkt.
Wenn der RDS-Endpunkt beispielsweise `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com` ist und der Domain-Name `corp-ad.company.com` lautet, wäre der Kerberos-basierte Endpunkt `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`.
Dieser Kerberos-basierte Endpunkt kann zur Authentifizierung bei der SQL-Server-Instance mithilfe von Kerberos verwendet werden, auch nach einem Failover-Ereignis, da der Endpunkt automatisch aktualisiert wird, sodass er auf den neuen SPN der primären SQL-Server-Instance verweist.
### Auffinden Ihres CNAME
Um Ihren CNAME zu finden, stellen Sie eine Verbindung zu Ihrem Domain-Controller her und öffnen Sie den **DNS-Manager**. Navigieren Sie zu **Forward-Lookup-Zonen** und Ihrem FQDN.
Navigieren Sie durch **awsrds**, **aws-region** und **account and region specific hash**.
![\[Ändern der Speichermenge einer DB-Instance\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/kerb-endpoint-selfManagedAD-RDSMS.png)
Wenn nach der Verbindung mit CNAME vom Remote-Client aus eine NTLM-Verbindung zurückgegeben wird, überprüfen Sie, ob die erforderlichen Ports auf der Zulassungsliste stehen.
Wenn Sie überprüfen möchten, ob Ihre Verbindung Kerberos verwendet, führen Sie die folgende Abfrage aus:
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
Wenn Ihre Instance beim Herstellen einer Verbindung zu einem Kerberos-Endpunkt eine NTLM-Verbindung zurückgibt, überprüfen Sie Ihre Netzwerk- und Benutzerkonfigurationen. Siehe [Konfigurieren Ihrer Netzwerkkonnektivität](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig).
## Schritt 3: SQL Server-Logins für die Windows-Authentifizierung erstellen
Verwenden Sie die Anmeldeinformationen für den Amazon-RDS-Masterbenutzer, um eine Verbindung zur SQL-Server-DB-Instance herzustellen, wie Sie es bei jeder anderen DB-Instance tun würden. Da die DB-Instance der selbstverwalteten AD-Domain hinzugefügt wurde, können Sie SQL-Server-Anmeldungen und -Benutzer bereitstellen. Sie tun dies über das AD-Dienstprogramm für Benutzer und Gruppen in Ihrer selbstverwalteten AD-Domain. Datenbankberechtigungen werden über die Standard-SQL-Server-Berechtigungen verwaltet, die für die Windows-Anmeldungen gewährt und widerrufen werden.
Damit sich ein Domain-Servicekonto eines selbstverwalteten AD mit SQL Server authentifizieren kann, muss eine Windows-Anmeldung für SQL Server für das Domain-Servicekonto des selbstverwalteten AD oder für eine Gruppe des selbstverwalteten AD, der der Benutzer angehört, vorliegen. Eine differenzierte Zugriffskontrolle wird durch das Gewähren und Widerrufen von Berechtigungen für diese SQL Server-Anmeldungen gewährleistet. Ein Domain-Servicekonto des selbstverwalteten AD, das über keine SQL-Server-Anmeldung verfügt oder zu keiner Gruppe des selbstverwalteten AD mit einer solchen Anmeldung gehört, kann nicht auf die DB-Instance von SQL Server zugreifen.
Die Berechtigung ALTER ANY LOGIN ist erforderlich, um eine SQL-Server-Anmeldung für das selbstverwaltete AD zu erstellen. Wenn Sie mit dieser Berechtigung noch keine Anmeldungen erstellt haben, verbinden Sie sich mithilfe der SQL-Server-Authentifizierung als Masterbenutzer der DB-Instance und erstellen Sie Ihre SQL-Server-Anmeldungen für das selbstverwaltete AD im Kontext des Masterbenutzers.
Sie können einen Data Definition Language (DDL)-Befehl wie im Folgenden dargestellt ausführen, um eine SQL-Server-Anmeldung für ein Domain-Servicekonto des selbstverwalteten AD oder eine entsprechende Gruppe zu erstellen.
**Anmerkung**
Geben Sie Benutzer und Gruppen unter Verwendung des Anmeldenamens von Windows 2000 im Format a `my_AD_domain\my_AD_domain_user`. Sie können keinen User Principle Name (UPN) im Format verwenden *`my_AD_domain_user`*`@`*`my_AD_domain`*.
```
USE [master]
GO
CREATE LOGIN [my_AD_domain\my_AD_domain_user] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
Weitere Informationen finden Sie unter [ANMELDENAME ERSTELLEN (Transact-SQL)](https://msdn.microsoft.com/en-us/library/ms189751.aspx) in der Microsoft Developer Network-Dokumentation.
Benutzer (sowohl menschliche Benutzer als auch Anwendungen) aus Ihrer Domain können sich nun von einem einer selbstverwalteten AD-Domain hinzugefügten Client-Computer mithilfe der Windows-Authentifizierung mit der RDS-für-SQL-Server-Instance verbinden.
# Verwalten einer DB-Instance in einer selbstverwalteten Active-Directory-Domain
Sie können die Konsole oder die Amazon RDS-API verwenden AWS CLI, um Ihre DB-Instance und ihre Beziehung zu Ihrer selbstverwalteten AD-Domain zu verwalten. Beispielsweise können Sie die DB-Instance in Domänen, aus Domänen oder zwischen Domänen verschieben.
Sie können z. B. mithilfe der Amazon-RDS-API Folgendes tun:
+ Um aufgrund einer fehlgeschlagenen Mitgliedschaft erneut zu versuchen, einer selbstverwalteten Domain beizutreten, verwenden Sie den Vorgang „DBInstanceAPI [ändern](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)“ und geben Sie dieselben Parameter an:
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ Um eine DB-Instance aus einer selbstverwalteten Domain zu entfernen, verwenden Sie die API-Operation `ModifyDBInstance` und geben Sie `--disable-domain` als Domain-Parameter an.
+ Um eine DB-Instance von einer selbstverwalteten Domain in eine andere zu verschieben, verwenden Sie die API-Operation `ModifyDBInstance` und geben Sie die Domain-Parameter für die neue Domain an:
+ `--domain-fqdn`
+ `--domain-dns-ips`
+ `--domain-ou`
+ `--domain-auth-secret-arn`
+ [Verwenden Sie den Vorgang Describe API, um die selbstverwaltete AD-Domänenmitgliedschaft für jede DB-Instance aufzulisten. DBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html)
## Grundlegendes zur Mitgliedschaft in einer selbstverwalteten Active-Directory-Domain
Nachdem Sie Ihre DB-Instance erstellt oder geändert und dabei AD-Details angegeben haben, wird die Instance ein Mitglied der selbstverwalteten AD-Domain. Die AWS Konsole zeigt den Status der selbstverwalteten Active Directory-Domänenmitgliedschaft für die DB-Instance an. Der Status der DB-Instance kann einer der folgenden sein:
+ **joined** – Die Instance ist Mitglied der AD-Domain.
+ **joining** – Die Instance ist gerade dabei, Mitglied der AD-Domain zu werden.
+ **pending-join** – Die Mitgliedschaft der Instance steht noch aus.
+ **pending-maintenance-join**— versucht, AWS die Instance während des nächsten geplanten Wartungsfensters zu einem Mitglied der AD-Domäne zu machen.
+ **pending-removal** – Das Entfernen der Instance von der AD-Domain steht noch aus.
+ **pending-maintenance-removal**— versucht, AWS die Instanz während des nächsten geplanten Wartungsfensters aus der AD-Domäne zu entfernen.
+ **failed** – Ein Konfigurationsproblem hat verhindert, dass die Instance der Domain beitreten konnte. Überprüfen und korrigieren Sie Ihre Konfiguration, bevor Sie den Befehl zu Änderung der Instance erneut ausführen.
+ **removing** – Die Instance wird gerade von der selbstverwalteten AD-Domain entfernt.
**Wichtig**
Eine Anfrage, Mitglied einer selbstverwalteten AD-Domain zu werden, kann wegen eines Netzwerkverbindungsproblems fehlschlagen. Es könnte beispielsweise sein, dass Sie eine DB-Instance erstellen oder eine vorhandene Instance ändern und der Versuch, die DB-Instance zu einem Mitglied einer selbstverwalteten AD-Domain zu machen, fehlschlägt. Geben Sie in diesem Fall entweder den Befehl zum Erstellen oder Ändern der DB-Instance neu aus oder ändern Sie die neu erstellte Instance, damit sie der selbstverwalteten AD-Domain beitreten kann.
# Fehlerbehebung für selbstverwaltetes Active Directory
Die folgenden Probleme können auftreten, wenn Sie ein selbstverwaltetes AD einrichten oder ändern.
****
| Fehlercode | Description | Häufige Ursachen | Vorschläge für die Fehlerbehebung |
| --- | --- | --- | --- |
| Fehler 2 / 0x2 | Die angegebene Datei wurde nicht gefunden. | Das Format oder der Speicherort für die Organisationseinheit, das/der mit dem Parameter `—domain-ou` angegeben wurde, ist ungültig. Das über AWS Secrets Manager angegebene Domänendienstkonto verfügt nicht über die erforderlichen Berechtigungen, um der Organisationseinheit beizutreten. | Überprüfen Sie den Parameter `—domain-ou`. Stellen Sie sicher, dass das Domain-Servicekonto über die richtigen Berechtigungen für die Organisationseinheit verfügt. Weitere Informationen finden Sie unter [Konfigurieren Ihres AD-Domain-Servicekontos](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). |
| Fehler 5 / 0x5 | Zugriff verweigert. | Falsch konfigurierte Berechtigungen für das Domain-Servicekonto oder das Computerkonto ist bereits in der Domain vorhanden. | Überprüfen Sie die Berechtigungen des Domain-Servicekontos in der Domain und stellen Sie sicher, dass das RDS-Computerkonto nicht doppelt in der Domain vorhanden ist. Sie können den Namen des RDS-Computerkontos überprüfen, indem Sie `SELECT @@SERVERNAME` auf Ihrer RDS-für-SQL-Server-DB-Instance ausführen. Versuchen Sie bei Verwendung von Multi-AZ, einen Neustart mit Failover durchzuführen, und überprüfen Sie dann das RDS-Computerkonto erneut. Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). |
| Fehler 87 / 0x57 | Der Parameter ist falsch. | Das über AWS Secrets Manager angegebene Domänendienstkonto verfügt nicht über die richtigen Berechtigungen. Auch das Benutzerprofil ist möglicherweise beschädigt. | Prüfen Sie die Anforderungen für das Domain-Servicekonto. Weitere Informationen finden Sie unter [Konfigurieren Ihres AD-Domain-Servicekontos](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.DomainAccountConfig). |
| Fehler 234 / 0xEA | Die angegebene Organisationseinheit ist nicht vorhanden. | Die mit dem Parameter `—domain-ou` angegebene Organisationseinheit ist in Ihrem selbstverwalteten AD nicht vorhanden. | Überprüfen Sie den Parameter `—domain-ou` und stellen Sie sicher, dass die angegebene Organisationseinheit in Ihrem selbstverwalteten AD vorhanden ist. |
| Fehler 1326 / 0x52E | Der Benutzername oder das Passwort ist falsch. | Die in AWS Secrets Manager angegebenen Anmeldeinformationen für das Domänendienstkonto enthalten einen unbekannten Benutzernamen oder ein falsches Passwort. Möglicherweise ist das Domain-Konto auch in Ihrem selbstverwalteten AD deaktiviert. | Stellen Sie sicher, dass die in AWS Secrets Manager angegebenen Anmeldeinformationen korrekt sind und das Domain-Konto in Ihrem selbstverwalteten AD aktiviert ist. |
| Fehler 1355 / 0x54B | Die angegebene Domain ist nicht vorhanden oder konnte nicht kontaktiert werden. | Die Domain ist ausgefallen, der angegebene IPs DNS-Satz ist nicht erreichbar oder der angegebene FQDN ist nicht erreichbar. | Stellen Sie sicher, dass die Parameter `—domain-dns-ips` und `—domain-fqdn` korrekt sind. Überprüfen Sie die Netzwerkkonfiguration Ihrer RDS-für-SQL-Server-DB-Instance und stellen Sie sicher, dass Ihr selbstverwaltetes AD erreichbar ist. Weitere Informationen finden Sie unter [Konfigurieren Ihrer Netzwerkkonnektivität](USER_SQLServer_SelfManagedActiveDirectory.Requirements.md#USER_SQLServer_SelfManagedActiveDirectory.Requirements.NetworkConfig). |
| Fehler 1722 / 0x6BA | Der RPC-Server ist nicht verfügbar. | Der RPC-Service Ihrer AD-Domain konnte nicht erreicht werden. Dies könnte auf einen Service- oder Netzwerkfehler zurückzuführen sein. | Stellen Sie sicher, dass der RPC-Service auf Ihren Domain-Controllern ausgeführt wird und dass die TCP-Ports `135` und `49152-65535` in Ihrer Domain von Ihrer RDS-für-SQL -Server-DB-Instance aus erreichbar sind. |
| Fehler 1727 / 0x6BF | Der Remote-Prozeduraufruf ist fehlgeschlagen und wurde nicht ausgeführt. | Netzwerkverbindungsproblem oder Firewall-Einschränkung blockiert die RPC-Kommunikation mit dem Domain-Controller. | Wenn Sie den VPC-übergreifenden Domain-Beitritt verwenden, überprüfen Sie, ob die VPC-übergreifende Kommunikation korrekt mit VPC-Peering oder Transit Gateway eingerichtet ist. Stellen Sie sicher, dass die hohen TCP-Ports `49152-65535` in Ihrer Domain von Ihrer DB-Instance von RDS für SQL Server aus erreichbar sind, einschließlich aller möglichen Firewall-Einschränkungen. |
| Fehler 2224 / 0x8B0 | Das Benutzerkonto besteht bereits. | Das Computerkonto, das zu Ihrem selbstverwalteten AD hinzugefügt werden soll, ist bereits vorhanden. | Ermitteln Sie das Computerkonto, indem Sie `SELECT @@SERVERNAME` auf Ihrer RDS-für-SQL-Server-DB-Instance ausführen, und entfernen Sie es dann vorsichtig aus Ihrem selbstverwalteten AD. |
| Fehler 2242 / 0x8c2 | Das Passwort dieses Benutzers ist abgelaufen. | Das Passwort für das über AWS Secrets Manager angegebene Domänendienstkonto ist abgelaufen. | Aktualisieren Sie das Passwort für das Domain-Servicekonto, über das Sie Ihre RDS-für-SQL-Server-DB-Instance Ihrem selbstverwalteten AD hinzufügen. |
Nachdem Sie Ihre DB-Instance zu einer selbstverwalteten Active-Directory-Domain hinzugefügt haben, erhalten Sie möglicherweise RDS-Ereignisse, die sich auf den Zustand Ihrer Domain beziehen.
```
Unhealthy domain state detected while attempt to verify or
configure your Kerberos endpoint in your domain on
node node_n. message
```
Bei Multi-AZ-Instances stellen Sie möglicherweise die Fehlerberichterstattung sowohl für Knoten1 als auch Knoten2 fest, was darauf hindeutet, dass die Kerberos-Konfiguration Ihrer Instance nicht für einen Failover bereit ist. Im Falle eines Failovers können Probleme bei der Authentifizierung mit Kerberos auftreten. Beheben Sie die Konfigurationsprobleme, um sicherzustellen, dass die Kerberos-Einrichtung gültig und aktuell ist. Bei Multi-AZ-Instances sind keine Aktionen erforderlich, um die Kerberos-Authentifizierung auf dem neuen primären Host zu verwenden, sofern alle Netzwerk- und Berechtigungskonfigurationen vorhanden sind.
Bei Single-AZ-Instances ist Knoten1 der Primärknoten. Wenn Ihre Kerberos-Authentifizierung nicht wie erwartet funktioniert, überprüfen Sie die Instance-Ereignisse und beheben Sie die Konfigurationsprobleme, um sicherzustellen, dass die Kerberos-Einrichtung gültig und aktuell ist.
## Wiederherstellen einer SQL-Server-DB-Instance und Hinzufügen zu einer selbstverwalteten Active-Directory-Domain
Sie können einen DB-Snapshot wiederherstellen oder eine point-in-time Wiederherstellung (PITR) für eine SQL Server-DB-Instance durchführen und sie dann einer selbstverwalteten Active Directory-Domäne hinzufügen. Wenn die DB-Instance wiederhergestellt wurde, ändern Sie die Instance, indem Sie den unter [Schritt 1: Erstellen oder Ändern einer SQL Server-DB-Instance](USER_SQLServer_SelfManagedActiveDirectory.Joining.md#USER_SQLServer_SelfManagedActiveDirectory.SettingUp.CreateModify) beschriebenen Prozess anwenden, um die DB-Instance einer selbstverwalteten AD-Domain hinzuzufügen.