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.
# Benutzer für Serverendpunkte verwalten
In den folgenden Abschnitten finden Sie Informationen zum Hinzufügen von Benutzern mithilfe AWS Transfer Family eines benutzerdefinierten Identitätsanbieters. AWS Directory Service for Microsoft Active Directory
Sie speichern außerdem in den Eigenschaften der Benutzer den öffentlichen Secure Shell (SSH)-Schlüssel des jeweiligen Benutzers. Dies ist für die schlüsselbasierte Authentifizierung erforderlich. Der private Schlüssel wird lokal auf dem Computer Ihres Benutzers gespeichert. Wenn Ihr Benutzer mithilfe eines Clients eine Authentifizierungsanfrage an Ihren Server sendet, bestätigt Ihr Server zunächst, dass der Benutzer Zugriff auf den zugehörigen privaten SSH-Schlüssel hat. Der Server authentifiziert den Benutzer dann erfolgreich.
**Anmerkung**
Informationen zur automatisierten Bereitstellung und Verwaltung von Benutzern mit mehreren SSH-Schlüsseln finden Sie unter. [Terraform-Module der Transfer Family](terraform.md)
Darüber hinaus geben Sie das Home-Verzeichnis oder das Landing-Verzeichnis eines Benutzers an und weisen dem Benutzer eine AWS Identity and Access Management (IAM-) Rolle zu. Optional können Sie eine Sitzungsrichtlinie angeben, um den Benutzerzugriff nur auf das Home-Verzeichnis Ihres Amazon S3 S3-Buckets zu beschränken.
**Wichtig**
AWS Transfer Family verhindert, dass sich Benutzernamen, die 1 oder 2 Zeichen lang sind, bei SFTP-Servern authentifizieren. Darüber hinaus blockieren wir auch den `root` Benutzernamen.
Der Grund dafür liegt in der großen Anzahl böswilliger Anmeldeversuche durch Passwortscanner.
## Amazon EFS im Vergleich zu Amazon S3
Eigenschaften der einzelnen Speicheroptionen:
+ Um den Zugriff zu beschränken: Amazon S3 unterstützt Sitzungsrichtlinien; Amazon EFS unterstützt POSIX-Benutzer, Gruppen und sekundäre Gruppen IDs
+ Beide unterstützen Schlüssel public/private
+ Beide unterstützen Home-Verzeichnisse
+ Beide unterstützen logische Verzeichnisse
**Anmerkung**
Für Amazon S3 erfolgt der Großteil der Unterstützung für logische Verzeichnisse über API/CLI. Sie können das Kontrollkästchen **Eingeschränkt** in der Konsole verwenden, um einen Benutzer auf sein Home-Verzeichnis zu sperren, aber Sie können keine virtuelle Verzeichnisstruktur angeben.
## Logische Verzeichnisse
Wenn Sie logische Verzeichniswerte für Ihren Benutzer angeben, hängt der verwendete Parameter vom Benutzertyp ab.
+ Geben Sie für vom Dienst verwaltete Benutzer logische Verzeichniswerte in `HomeDirectoryMappings` ein.
+ Geben Sie für Benutzer eines benutzerdefinierten Identitätsanbieters logische Verzeichniswerte in an`HomeDirectoryDetails`.
AWS Transfer Family unterstützt die Angabe eines HomeDirectory Werts bei Verwendung von LOGICAL HomeDirectoryType. Dies gilt für vom Service verwaltete Benutzer, Active Directory-Zugriff und benutzerdefinierte Identity Provider-Implementierungen, bei denen sie in der Antwort angegeben HomeDirectoryDetails werden.
**Wichtig**
Wenn Sie a HomeDirectory mit LOGICAL angeben HomeDirectoryType, muss der Wert einer Ihrer logischen Verzeichniszuordnungen zugeordnet werden. Der Dienst überprüft dies sowohl bei der Benutzererstellung als auch bei Aktualisierungen, um Konfigurationen zu verhindern, die nicht funktionieren würden.
### Standardverhalten
Wenn nichts angegeben wird, HomeDirectory ist der standardmäßig auf „/“ für den LOGISCHEN Modus gesetzt. Dieses Verhalten ist unverändert und bleibt mit bestehenden Benutzerdefinitionen kompatibel.
+ Stellen Sie sicher, dass HomeDirectory Sie Ihrem *Eintrag* und nicht einem *Ziel zuordnen*. Weitere Details finden Sie unter [Regeln für die Verwendung logischer Verzeichnisse](logical-dir-mappings.md#logical-dir-rules).
+ Einzelheiten zur Struktur eines virtuellen Verzeichnisses finden Sie unter[Struktur des virtuellen Verzeichnisses](implement-log-dirs.md#virtual-dirs).
### Überlegungen zu benutzerdefinierten Identitätsanbietern
Wenn Sie einen benutzerdefinierten Identitätsanbieter verwenden, können Sie jetzt HomeDirectory in der Antwort a angeben, während Sie LOGICAL verwenden HomeDirectoryType. Der TestIdentityProvider API-Aufruf führt zu korrekten Ergebnissen, wenn der benutzerdefinierte IDP HomeDirectory im LOGICAL-Modus a angibt.
Beispiel für eine benutzerdefinierte IDP-Antwort mit HomeDirectory und LOGICAL: HomeDirectoryType
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-user-role",
"HomeDirectoryType": "LOGICAL",
"HomeDirectory": "/marketing",
"HomeDirectoryDetails": "[{\"Entry\":\"/\",\"Target\":\"/bucket/home\"},{\"Entry\":\"/marketing\",\"Target\":\"/marketing-bucket/campaigns\"}]"
}
```
## Active Directory-Gruppenkontingente
AWS Transfer Family hat ein Standardlimit von 100 Active Directory-Gruppen pro Server. Wenn Ihr Anwendungsfall mehr als 100 Gruppen erfordert, sollten Sie die Verwendung einer benutzerdefinierten Identitätsanbieterlösung in Betracht ziehen, wie unter [Vereinfachen der Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
Dieses Limit gilt für Server, die die folgenden Identitätsanbieter verwenden:
+ AWS Directory Service für Microsoft Active Directory
+ AWS Directory Service für Entra ID Domain Services
Wenn Sie eine Erhöhung des Servicelimits beantragen müssen, finden Sie Informationen zu den [AWS-Service Kontingenten](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in der *Allgemeine AWS-Referenz*. Wenn Ihr Anwendungsfall mehr als 100 Gruppen erfordert, sollten Sie die Verwendung einer benutzerdefinierten Identitätsanbieterlösung in Betracht ziehen, wie unter [Vereinfachen der Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
Informationen zur Problembehandlung im Zusammenhang mit Active Directory-Gruppenlimits finden Sie unter[Die Active Directory-Gruppenlimits wurden überschritten](auth-issues.md#managed-ad-group-limits).
**Topics**
+ [
## Amazon EFS im Vergleich zu Amazon S3
](#efs-vs-s3-users)
+ [
## Logische Verzeichnisse
](#logical-dir-users)
+ [
## Active Directory-Gruppenkontingente
](#ad-group-quotas)
+ [
# Arbeiten mit Benutzern, die vom Dienst verwaltet werden
](service-managed-users.md)
+ [
# Mit Anbietern benutzerdefinierter Identitäten arbeiten
](custom-idp-intro.md)
+ [
# Verwenden des AWS Directory Service für Microsoft Active Directory
](directory-services-users.md)
+ [
# Verwenden des AWS Directory Service für Entra ID Domain Services
](azure-sftp.md)
# Arbeiten mit Benutzern, die vom Dienst verwaltet werden
Sie können Ihrem Server entweder vom Service verwaltete Amazon S3- oder Amazon EFS-Benutzer hinzufügen, abhängig von der **Domain-Einstellung** des Servers. Weitere Informationen finden Sie unter [Konfiguration eines SFTP-, FTPS- oder FTP-Serverendpunkts](tf-server-endpoint.md).
Wenn Sie einen vom Dienst verwalteten Identitätstyp verwenden, fügen Sie Benutzer zu Ihrem Server hinzu, auf dem das File Transfer Protocol aktiviert ist. Wenn Sie dies tun, muss jeder Benutzername auf Ihrem Server einzigartig sein.
Informationen zum programmgesteuerten Hinzufügen eines vom Service verwalteten Benutzers finden Sie im [Beispiel für die API](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_Examples). [CreateUser](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html)
**Anmerkung**
Für Benutzer, die vom Service verwaltet werden, gilt eine Obergrenze von 2.000 logischen Verzeichniseinträgen. Hinweise zur Verwendung logischer Verzeichnisse finden Sie unter[Verwendung logischer Verzeichnisse zur Vereinfachung Ihrer Transfer Family Family-Verzeichnisstrukturen](logical-dir-mappings.md).
**Topics**
+ [
## Hinzufügen von vom Service verwalteten Amazon S3-Benutzern
](#add-s3-user)
+ [
## Hinzufügen von vom Service verwalteten Amazon EFS-Benutzern
](#add-efs-user)
+ [
## Verwaltung von Benutzern, die vom Service verwaltet werden
](#managing-service-managed-users)
## Hinzufügen von vom Service verwalteten Amazon S3-Benutzern
**Anmerkung**
Wenn Sie einen kontoübergreifenden Amazon S3 S3-Bucket konfigurieren möchten, folgen Sie den Schritten in diesem Knowledge Center-Artikel: [Wie konfiguriere ich meinen AWS Transfer Family Server für die Verwendung eines Amazon Simple Storage Service-Buckets, der sich in einem anderen AWS Konto befindet?](https://aws.amazon.com/premiumsupport/knowledge-center/sftp-cross-account-s3-bucket/) .
**So fügen Sie Ihrem Server einen vom Service verwalteten Amazon S3 S3-Benutzer hinzu**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)und wählen Sie dann im Navigationsbereich **Server** aus.
1. Aktivieren Sie auf der Seite **Server** das Kontrollkästchen des Servers, zu dem Sie einen Benutzer hinzufügen möchten.
1. Wählen Sie **Benutzer hinzufügen**.
1. Geben Sie im Abschnitt **Benutzerkonfiguration** für **Benutzername** den Benutzernamen ein. Dieser Benutzername muss mindestens 3 und maximal 100 Zeichen lang sein. Sie können die folgenden Zeichen im Benutzernamen verwenden: a—z, A-Z, 0—9, Unterstrich '\$1', Bindestrich '-', Punkt '.' und das Zeichen '@'. Der Benutzername darf nicht mit einem Bindestrich '-', einem Punkt '.' oder einem Zeichen '@' beginnen.
1. Wählen Sie für **Access** die IAM-Rolle aus, die Sie zuvor erstellt haben und die Zugriff auf Ihren Amazon S3 S3-Bucket bietet.
Sie haben diese IAM-Rolle in der Prozedur [Erstellen Sie eine IAM-Rolle und -Richtlinie](requirements-roles.md) erstellt. Diese IAM-Rolle beinhaltet eine IAM-Richtlinie, die den Zugriff auf Ihren Amazon S3 S3-Bucket ermöglicht. Dazu gehört auch eine Vertrauensbeziehung mit dem AWS Transfer Family Service, die in einer anderen IAM-Richtlinie definiert ist. Wenn Sie eine detaillierte Zugriffskontrolle für Ihre Benutzer benötigen, lesen Sie den Blogbeitrag [Enhance data access control with AWS Transfer Family and Amazon S3](https://aws.amazon.com/blogs/storage/enhance-data-access-control-with-aws-transfer-family-and-amazon-s3-access-points/).
1. (Optional) Wählen Sie **unter Richtlinie** eine der folgenden Optionen aus:
+ **Keine**
+ **Bestehende Richtlinie**
+ **Wählen Sie eine Richtlinie aus IAM** aus: Ermöglicht die Auswahl einer vorhandenen Sitzungsrichtlinie. Wählen Sie **Ansicht**, um ein JSON-Objekt mit den Details der Richtlinie anzuzeigen.
+ **Richtlinie automatisch auf Basis des Basisordners generieren**: Generiert eine Sitzungsrichtlinie für Sie. Wählen Sie **Ansicht**, um ein JSON-Objekt mit den Details der Richtlinie anzuzeigen.
**Anmerkung**
Wenn Sie die Option **Richtlinie auf Basis des Basisordners automatisch generieren** wählen, wählen Sie für diesen Benutzer nicht die Option **Eingeschränkt** aus.
Weitere Informationen zu Sitzungsrichtlinien finden Sie unter [Erstellen Sie eine IAM-Rolle und -Richtlinie](requirements-roles.md)[Sitzungsrichtlinie für einen Amazon S3 S3-Bucket erstellen](users-policies-session.md), oder[Dynamische Ansätze zur Rechteverwaltung](dynamic-permission-management.md).
1. Wählen Sie für **das Home-Verzeichnis** den Amazon S3 S3-Bucket aus, in dem die zu übertragenden Daten gespeichert AWS Transfer Family werden sollen. Geben Sie den Pfad zu dem `home` Verzeichnis ein, in dem Ihr Benutzer landet, wenn er sich mit seinem Client anmeldet.
Wenn Sie diesen Parameter leer lassen, wird das `root` Verzeichnis Ihres Amazon S3 S3-Buckets verwendet. Stellen Sie in diesem Fall sicher, dass die IAM-Rolle Zugriff auf dieses `root`-Verzeichnis gewährt.
**Anmerkung**
Wir empfehlen Ihnen, einen Verzeichnispfad zu wählen, der den Benutzernamen des Benutzers enthält, sodass Sie eine Sitzungsrichtlinie effektiv verwenden können. Die Sitzungsrichtlinie beschränkt den Benutzerzugriff im Amazon S3 S3-Bucket auf das `home` Verzeichnis dieses Benutzers.
1. (Optional) Aktivieren Sie für **Eingeschränkt** das Kontrollkästchen, sodass Ihre Benutzer auf nichts außerhalb dieses Ordners zugreifen können und den Amazon S3 S3-Bucket- oder Ordnernamen nicht sehen können.
**Anmerkung**
Dem Benutzer ein Home-Verzeichnis zuzuweisen und den Benutzer auf dieses Home-Verzeichnis zu beschränken, sollte ausreichen, um den Zugriff des Benutzers auf den angegebenen Ordner zu sperren. Wenn Sie weitere Kontrollen anwenden müssen, verwenden Sie eine Sitzungsrichtlinie.
Wenn Sie für diesen Benutzer die Option **Eingeschränkt** auswählen, können Sie die Option **Richtlinie automatisch auf Basis des Basisordners generieren** nicht auswählen, da der Basisordner kein definierter Wert für Benutzer mit eingeschränkten Rechten ist.
1. Geben Sie für den **öffentlichen SSH-Schlüssel** den öffentlichen SSH-Schlüsselteil des SSH-Schlüsselpaars key pair.
Der Schlüssel wird vom Service validiert, bevor Sie den neuen Benutzer hinzufügen können.
**Anmerkung**
Anleitungen zum Generieren eines SSH-Schlüsselpaars siehe [Generieren Sie SSH-Schlüssel für vom Service verwaltete Benutzer](sshkeygen.md).
1. **(Optional) Geben Sie für **Schlüssel** und **Wert** ein oder mehrere Tags als Schlüssel-Wert-Paare ein und wählen Sie Tag hinzufügen aus.**
1. Wählen Sie **Add (Hinzufügen)**, um den neuen Benutzer dem ausgewählten Server hinzuzufügen.
Der neue Benutzer wird auf der Seite mit den **Serverdetails** im Bereich **Benutzer** angezeigt.
**Nächste Schritte** — Fahren Sie für den nächsten Schritt fort mit[Übertragung von Dateien über einen Serverendpunkt mit einem Client](transfer-file.md).
## Hinzufügen von vom Service verwalteten Amazon EFS-Benutzern
Amazon EFS verwendet das POSIX-Dateiberechtigungsmodell (Portable Operating System Interface), um den Dateibesitz darzustellen.
+ Weitere Informationen zum Besitz von Amazon EFS-Dateien finden Sie unter [Amazon EFS-Dateibesitz](configure-storage.md#efs-file-ownership).
+ Weitere Informationen zum Einrichten von Verzeichnissen für Ihre EFS-Benutzer finden Sie unter[Amazon EFS-Benutzer für Transfer Family einrichten](configure-storage.md#configure-efs-users-permissions).
**So fügen Sie Ihrem Server einen vom Amazon EFS Service verwalteten Benutzer hinzu**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)und wählen Sie dann im Navigationsbereich **Server** aus.
1. Wählen Sie auf der Seite **Server** den Amazon EFS-Server aus, zu dem Sie einen Benutzer hinzufügen möchten.
1. Wählen **Sie Benutzer hinzufügen**, um die Seite **Benutzer hinzufügen** anzuzeigen.
1. Verwenden Sie im Abschnitt **Benutzerkonfiguration** die folgenden Einstellungen.
1. Der **Benutzername** muss mindestens 3 und maximal 100 Zeichen lang sein. Sie können die folgenden Zeichen im Benutzernamen verwenden: a—z, A-Z, 0—9, Unterstrich '\$1', Bindestrich '-', Punkt ' . 'und beim Zeichen „@“. Der Benutzername darf nicht mit einem Bindestrich '-' oder Punkt 'beginnen . ', oder beim Zeichen „@“.
1. Beachten Sie bei **Benutzer-ID** **und Gruppen-ID** Folgendes:
+ Für den ersten Benutzer, den Sie erstellen, empfehlen wir, den Wert sowohl **0** für die **Gruppen-ID** als auch für die **Benutzer-ID** einzugeben. Dadurch werden dem Benutzer Administratorrechte für Amazon EFS gewährt.
+ Geben Sie für weitere Benutzer die POSIX-Benutzer-ID und die Gruppen-ID des Benutzers ein. Diese IDs werden für alle vom Benutzer ausgeführten Amazon Elastic File System-Operationen verwendet.
+ Verwenden Sie für **Benutzer-ID** **und Gruppen-ID** keine führenden Nullen. Zum Beispiel **12345** ist akzeptabel, **012345** ist nicht.
1. (Optional) Geben Sie für **Secondary Group IDs** eine oder mehrere zusätzliche POSIX-Gruppen IDs für jeden Benutzer ein, getrennt durch Kommas.
1. Wählen Sie für **Access** die IAM-Rolle aus, die:
+ Gewährt dem Benutzer nur Zugriff auf die Amazon EFS-Ressourcen (Dateisysteme), auf die er zugreifen soll.
+ Definiert, welche Dateisystemoperationen der Benutzer ausführen kann und welche nicht.
Wir empfehlen, dass Sie die IAM-Rolle für die Auswahl des Amazon EFS-Dateisystems mit Bereitstellungszugriff und read/write -berechtigungen verwenden. Die Kombination der folgenden beiden AWS verwalteten Richtlinien ist zwar recht freizügig, gewährt Ihrem Benutzer jedoch die erforderlichen Berechtigungen:
+ AmazonElasticFileSystemClientFullAccess
+ AWSTransferConsoleFullAccess
Weitere Informationen finden Sie im Blogbeitrag [AWS Transfer Family Unterstützung für Amazon Elastic File System](https://aws.amazon.com/blogs/aws/new-aws-transfer-family-support-for-amazon-elastic-file-system/).
1. Gehen Sie für **das Home-Verzeichnis** wie folgt vor:
+ Wählen Sie das Amazon EFS-Dateisystem aus, das Sie zum Speichern der zu übertragenden Daten verwenden möchten AWS Transfer Family.
+ Entscheiden Sie, ob Sie das Home-Verzeichnis **auf Eingeschränkt** setzen möchten. Wenn Sie das Home-Verzeichnis auf **Eingeschränkt** setzen, hat dies folgende Auswirkungen:
+ Amazon EFS-Benutzer können auf keine Dateien oder Verzeichnisse außerhalb dieses Ordners zugreifen.
+ Amazon EFS-Benutzer können den Namen des Amazon EFS-Dateisystems (**fs-xxxxxxx**) nicht sehen.
**Anmerkung**
Wenn Sie die Option **Eingeschränkt** auswählen, werden Symlinks für Amazon EFS-Benutzer nicht aufgelöst.
+ (Optional) Geben Sie den Pfad zu dem Basisverzeichnis ein, in dem sich Benutzer befinden sollen, wenn sie sich mit ihrem Client anmelden.
Wenn Sie kein Home-Verzeichnis angeben, wird das Stammverzeichnis Ihres Amazon EFS-Dateisystems verwendet. Stellen Sie in diesem Fall sicher, dass Ihre IAM-Rolle Zugriff auf dieses Stammverzeichnis bietet.
1. Geben Sie für den **öffentlichen SSH-Schlüssel** den öffentlichen SSH-Schlüsselteil des SSH-Schlüsselpaars key pair.
Der Schlüssel wird vom Service validiert, bevor Sie den neuen Benutzer hinzufügen können.
**Anmerkung**
Anleitungen zum Generieren eines SSH-Schlüsselpaars siehe [Generieren Sie SSH-Schlüssel für vom Service verwaltete Benutzer](sshkeygen.md).
1. (Optional) Geben Sie beliebige Tags für den Benutzer ein. Geben Sie für **Schlüssel** und **Wert** ein oder mehrere Tags als Schlüssel-Wert-Paare ein und wählen Sie Tag **hinzufügen** aus.
1. Wählen Sie **Add (Hinzufügen)**, um den neuen Benutzer dem ausgewählten Server hinzuzufügen.
Der neue Benutzer wird auf der Seite mit den **Serverdetails** im Bereich **Benutzer** angezeigt.
Probleme, die auftreten können, wenn Sie zum ersten Mal SFTP zu Ihrem Transfer Family Family-Server verwenden:
+ Wenn Sie den `sftp` Befehl ausführen und die Eingabeaufforderung nicht angezeigt wird, wird möglicherweise die folgende Meldung angezeigt:
`Couldn't canonicalize: Permission denied`
`Need cwd`
In diesem Fall müssen Sie die Richtlinienberechtigungen für die Rolle Ihres Benutzers erhöhen. Sie können eine AWS verwaltete Richtlinie hinzufügen, `AmazonElasticFileSystemClientFullAccess` z.
+ Wenn Sie `pwd` an der `sftp` Eingabeaufforderung das Home-Verzeichnis des Benutzers aufrufen, wird möglicherweise die folgende Meldung angezeigt, in der *USER-HOME-DIRECTORY* es um das Home-Verzeichnis für den SFTP-Benutzer geht:
`remote readdir("/USER-HOME-DIRECTORY"): No such file or directory`
In diesem Fall sollten Sie in der Lage sein, zum übergeordneten Verzeichnis (`cd ..`) zu navigieren und das Home-Verzeichnis des Benutzers zu erstellen (`mkdir username`).
**Nächste Schritte** — Fahren Sie für den nächsten Schritt fort mit[Übertragung von Dateien über einen Serverendpunkt mit einem Client](transfer-file.md).
## Verwaltung von Benutzern, die vom Service verwaltet werden
In diesem Abschnitt finden Sie Informationen zum Anzeigen einer Benutzerliste, zum Bearbeiten von Benutzerdetails und zum Hinzufügen eines öffentlichen SSH-Schlüssels.
+ [Eine Liste von Benutzern anzeigen](#list-users)
+ [Benutzerdetails anzeigen oder bearbeiten](#view-user-details)
+ [Löschen eines Benutzers](#delete-user)
+ [Fügen Sie den öffentlichen SSH-Schlüssel hinzu](#add-user-ssh-key)
+ [Löschen Sie den öffentlichen SSH-Schlüssel](#delete-user-ssh-key)
**Um eine Liste Ihrer Benutzer zu finden**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Wählen Sie im Navigationsbereich **Server** aus, um die Seite **Server** anzuzeigen.
1. Wählen Sie den Bezeichner in der Spalte **Server-ID** aus, um die Seite mit den **Serverdetails** aufzurufen.
1. Sehen Sie sich unter **Benutzer** eine Liste der Benutzer an.
**Um Benutzerdetails anzuzeigen oder zu bearbeiten**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Wählen Sie im Navigationsbereich **Server** aus, um die Seite **Server** anzuzeigen.
1. Wählen Sie den Bezeichner in der Spalte **Server-ID** aus, um die Seite mit den **Serverdetails** aufzurufen.
1. Wählen Sie unter **Benutzer** einen Benutzernamen aus, um die Seite mit den **Benutzerdetails** aufzurufen.
Sie können die Eigenschaften des Benutzers auf dieser Seite ändern, indem Sie **Bearbeiten** wählen.
1. Wählen Sie auf der Seite mit den **Benutzerdetails** neben **Benutzerkonfiguration** die Option **Bearbeiten** aus.
![\[Das Bild zeigt den Bildschirm zum Bearbeiten der Benutzerkonfiguration\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/edit-user-details-page-user-config.png)
1. Wählen Sie auf der Seite **Konfiguration bearbeiten** für **Access** die IAM-Rolle aus, die Sie zuvor erstellt haben und die Zugriff auf Ihren Amazon S3 S3-Bucket bietet.
Sie haben diese IAM-Rolle in der Prozedur [Erstellen Sie eine IAM-Rolle und -Richtlinie](requirements-roles.md) erstellt. Diese IAM-Rolle beinhaltet eine IAM-Richtlinie, die den Zugriff auf Ihren Amazon S3 S3-Bucket ermöglicht. Dazu gehört auch eine Vertrauensbeziehung mit dem AWS Transfer Family Service, die in einer anderen IAM-Richtlinie definiert ist.
1. (Optional) Wählen Sie für **Policy** eine der folgenden Optionen aus:
+ **Keine**
+ **Bestehende Richtlinie**
+ **Wählen Sie eine Richtlinie aus IAM** aus, um eine bestehende Richtlinie auszuwählen. Wählen Sie **Ansicht**, um ein JSON-Objekt mit den Details der Richtlinie anzuzeigen.
Weitere Informationen zu Sitzungsrichtlinien finden Sie unter[Erstellen Sie eine IAM-Rolle und -Richtlinie](requirements-roles.md). Weitere Informationen zum Erstellen einer Sitzungsrichtlinie finden Sie unter[Sitzungsrichtlinie für einen Amazon S3 S3-Bucket erstellen](users-policies-session.md).
1. Wählen Sie für **das Home-Verzeichnis** den Amazon S3 S3-Bucket aus, in dem die zu übertragenden Daten gespeichert AWS Transfer Family werden sollen. Geben Sie den Pfad zu dem `home` Verzeichnis ein, in dem Ihr Benutzer landet, wenn er sich mit seinem Client anmeldet.
Wenn Sie diesen Parameter leer lassen, wird das `root` Verzeichnis Ihres Amazon S3 S3-Buckets verwendet. Stellen Sie in diesem Fall sicher, dass die IAM-Rolle Zugriff auf dieses `root`-Verzeichnis gewährt.
**Anmerkung**
Wir empfehlen Ihnen, einen Verzeichnispfad zu wählen, der den Benutzernamen des Benutzers enthält, sodass Sie eine Sitzungsrichtlinie effektiv verwenden können. Die Sitzungsrichtlinie beschränkt den Benutzerzugriff im Amazon S3 S3-Bucket auf das `home` Verzeichnis dieses Benutzers.
1. (Optional) Aktivieren Sie für **Eingeschränkt** das Kontrollkästchen, sodass Ihre Benutzer auf nichts außerhalb dieses Ordners zugreifen können und den Amazon S3 S3-Bucket- oder Ordnernamen nicht sehen können.
**Anmerkung**
Wenn Sie dem Benutzer ein Home-Verzeichnis zuweisen und den Benutzer auf dieses Home-Verzeichnis beschränken, sollte dies ausreichen, um den Zugriff des Benutzers auf den angegebenen Ordner zu sperren. Verwenden Sie eine Sitzungsrichtlinie, wenn Sie weitere Kontrollen vornehmen müssen.
1. Wählen Sie **Speichern**, um Ihre Änderungen zu speichern.
**So löschen Sie einen Benutzer**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Wählen Sie im Navigationsbereich **Server** aus, um die Seite **Server** anzuzeigen.
1. Wählen Sie den Bezeichner in der Spalte **Server-ID** aus, um die Seite mit den **Serverdetails** aufzurufen.
1. Wählen Sie unter **Benutzer** einen Benutzernamen aus, um die Seite mit den **Benutzerdetails** aufzurufen.
1. Wählen Sie auf der Seite mit den **Benutzerdetails** rechts neben dem Benutzernamen die Option **Löschen** aus.
1. Geben Sie im daraufhin angezeigten Bestätigungsdialogfeld das Wort ein und wählen Sie dann **Löschen **delete****, um zu bestätigen, dass Sie den Benutzer löschen möchten.
Der Benutzer wird aus der **Benutzerliste** gelöscht.
**Um einen öffentlichen SSH-Schlüssel für einen Benutzer hinzuzufügen**
1. Öffnen Sie die AWS Transfer Family Konsole unter. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)
1. Klicken Sie im Navigationsbereich auf **Servers (Server)**.
1. Wählen Sie den Bezeichner in der Spalte **Server-ID** aus, um die Seite mit den **Serverdetails** aufzurufen.
1. Wählen Sie unter **Benutzer** einen Benutzernamen aus, um die Seite mit den **Benutzerdetails** aufzurufen.
1. Wählen Sie **Add SSH public key (Öffentlichen SSH-Schlüssel hinzufügen)**, um einem Benutzer einen neuen öffentlichen SSH-Schlüssel hinzuzufügen.
**Anmerkung**
SSH-Schlüssel werden nur von Servern verwendet, die für Secure Shell (SSH) File Transfer Protocol (SFTP) aktiviert sind. Hinweise zum Generieren eines SSH-Schlüsselpaars finden Sie unter[Generieren Sie SSH-Schlüssel für vom Service verwaltete Benutzer](sshkeygen.md).
1. Geben Sie für **SSH public key (Öffentlicher SSH-Schlüssel)** den öffentlichen SSH-Schlüssel des SSH-Schlüsselpaars ein.
Der Schlüssel wird vom Service validiert, bevor Sie den neuen Benutzer hinzufügen können. Das Format des SSH-Schlüssels lautet `ssh-rsa string`. Informationen zum Generieren eines SSH-Schlüsselpaars finden Sie unter[Generieren Sie SSH-Schlüssel für vom Service verwaltete Benutzer](sshkeygen.md).
1. Wählen Sie **Schlüssel hinzufügen**.
**So löschen Sie einen öffentlichen SSH-Schlüssel für einen Benutzer**
1. Öffnen Sie die AWS Transfer Family Konsole unter. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)
1. Klicken Sie im Navigationsbereich auf **Servers (Server)**.
1. Wählen Sie den Bezeichner in der Spalte **Server-ID** aus, um die Seite mit den **Serverdetails** aufzurufen.
1. Wählen Sie unter **Benutzer** einen Benutzernamen aus, um die Seite mit den **Benutzerdetails** aufzurufen.
1. Um einen öffentlichen Schlüssel zu löschen, aktivieren Sie das entsprechende Kontrollkästchen für den SSH-Schlüssel und wählen Sie **Löschen** aus.
# Mit Anbietern benutzerdefinierter Identitäten arbeiten
AWS Transfer Family bietet verschiedene Optionen für benutzerdefinierte Identitätsanbieter zur Authentifizierung und Autorisierung von Benutzern für sichere Dateiübertragungen. Hier sind die wichtigsten Ansätze:
+ [Lösung für einen benutzerdefinierten Identitätsanbieter](custom-idp-toolkit.md)— In diesem Thema wird die benutzerdefinierte Identitätsanbieter-Lösung von Transfer Family mithilfe eines Toolkits beschrieben, das unter gehostet wird. GitHub
**Anmerkung**
Für die meisten Anwendungsfälle ist dies die empfohlene Option. Insbesondere wenn Sie mehr als 100 Active Directory-Gruppen unterstützen müssen, bietet die benutzerdefinierte Identitätsanbieter-Lösung eine skalierbare Alternative ohne Gruppenbeschränkungen. Diese Lösung wird im Blogbeitrag [Simplify Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
+ [Verwenden Sie Amazon API Gateway zur Integration Ihres Identitätsanbieters](authentication-api-gateway.md)— In diesem Thema wird beschrieben, wie eine AWS Lambda Funktion zur Unterstützung einer Amazon API Gateway Gateway-Methode verwendet wird.
Sie können eine RESTful Schnittstelle mit einer einzigen Amazon API Gateway Gateway-Methode bereitstellen. Transfer Family ruft diese Methode auf, um eine Verbindung zu Ihrem Identitätsanbieter herzustellen, der Ihre Benutzer authentifiziert und für den Zugriff auf Amazon S3 oder Amazon EFS autorisiert. Verwenden Sie diese Option, wenn Sie eine RESTful API zur Integration Ihres Identitätsanbieters benötigen oder wenn Sie dessen Funktionen zum Geoblocking oder AWS WAF zur Ratenbegrenzung von Anfragen nutzen möchten. Details hierzu finden Sie unter [Verwenden Sie Amazon API Gateway zur Integration Ihres Identitätsanbieters](authentication-api-gateway.md).
+ [Dynamische Ansätze zur Rechteverwaltung](dynamic-permission-management.md)— In diesem Thema werden Ansätze für die dynamische Verwaltung von Benutzerberechtigungen mithilfe von Sitzungsrichtlinien beschrieben.
Um Ihre Benutzer zu authentifizieren, können Sie Ihren vorhandenen Identitätsanbieter mit verwenden. AWS Transfer Family Sie integrieren Ihren Identitätsanbieter mithilfe einer AWS Lambda Funktion, die Ihre Benutzer authentifiziert und für den Zugriff auf Amazon S3 oder Amazon Elastic File System (Amazon EFS) autorisiert. Details hierzu finden Sie unter [Wird AWS Lambda zur Integration Ihres Identitätsanbieters verwendet](custom-lambda-idp.md). In der AWS Transfer Family Management Console können Sie auch auf CloudWatch Diagramme für Messwerte wie die Anzahl der übertragenen Dateien und Byte zugreifen, sodass Sie Dateiübertragungen über ein zentrales Dashboard überwachen können.
+ Transfer Family bietet einen Blogbeitrag und einen Workshop, die Sie durch den Aufbau einer Dateiübertragungslösung führen. Diese Lösung nutzt AWS Transfer Family für verwaltete SFTP/FTPS Endgeräte sowie Amazon Cognito und DynamoDB für die Benutzerverwaltung.
Der Blogbeitrag ist unter [Amazon Cognito als Identitätsanbieter mit AWS Transfer Family Amazon S3 verwenden](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/) verfügbar. Die Details zum Workshop finden Sie [hier.](https://catalog.workshops.aws/transfer-family-sftp/en-US)
**Anmerkung**
Für benutzerdefinierte Identitätsanbieter muss der Benutzername mindestens 3 und maximal 100 Zeichen lang sein. Sie können die folgenden Zeichen im Benutzernamen verwenden: a—z, A-Z, 0—9, Unterstrich '\$1', Bindestrich '-', Punkt '.' und das At-Zeichen '@'. Der Benutzername darf nicht mit einem Bindestrich '-', einem Punkt '.' oder einem Zeichen '@' beginnen.
Beachten Sie bei der Implementierung eines benutzerdefinierten Identitätsanbieters die folgenden bewährten Methoden:
+ Stellen Sie die Lösung in derselben AWS-Konto Region wie Ihre Transfer Family Family-Server bereit.
+ Implementieren Sie bei der Konfiguration von IAM-Rollen und -Richtlinien das Prinzip der geringsten Rechte.
+ Verwenden Sie Funktionen wie die IP-Zulassungsliste und die standardisierte Protokollierung für mehr Sicherheit.
+ Testen Sie Ihren benutzerdefinierten Identitätsanbieter vor der Bereitstellung gründlich in einer Umgebung außerhalb der Produktionsumgebung.
**Topics**
+ [
# Lösung für einen benutzerdefinierten Identitätsanbieter
](custom-idp-toolkit.md)
+ [
# Wird AWS Lambda zur Integration Ihres Identitätsanbieters verwendet
](custom-lambda-idp.md)
+ [
# Verwenden Sie Amazon API Gateway zur Integration Ihres Identitätsanbieters
](authentication-api-gateway.md)
+ [
# Verwendung mehrerer Authentifizierungsmethoden
](custom-idp-mfa.md)
+ [
# IPv6 Unterstützung für benutzerdefinierte Identitätsanbieter
](custom-idp-ipv6.md)
# Lösung für einen benutzerdefinierten Identitätsanbieter
Die AWS Transfer Family benutzerdefinierte Identitätsanbieter-Lösung ist eine modulare benutzerdefinierte Identitätsanbieter-Lösung, die viele gängige Authentifizierungs- und Autorisierungsanwendungsfälle löst, mit denen Unternehmen bei der Implementierung des Dienstes konfrontiert sind. Diese Lösung bietet eine wiederverwendbare Grundlage für die Implementierung benutzerdefinierter Identitätsanbieter mit detaillierter Sitzungskonfiguration pro Benutzer. Sie trennt die Authentifizierungs- und Autorisierungslogik und bietet so eine flexible easy-to-maintain Grundlage für verschiedene Anwendungsfälle.
Mit der AWS Transfer Family benutzerdefinierten Identitätsanbieter-Lösung können Sie allgemeine Anwendungsfälle für die Authentifizierung und Autorisierung in Unternehmen adressieren. Diese modulare Lösung bietet:
+ Eine wiederverwendbare Grundlage für die Implementierung benutzerdefinierter Identitätsanbieter
+ Granulare Sitzungskonfiguration pro Benutzer
+ Separate Authentifizierungs- und Autorisierungslogik
## Implementierungsdetails für das Custom Identity Toolkit
Die Lösung bietet eine flexible und wartungsfreundliche Basis für verschiedene Anwendungsfälle. [Sehen Sie sich zunächst das Toolkit unter [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family) an und folgen Sie dann den Bereitstellungsanweisungen im Abschnitt Erste Schritte.](https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp#getting-started)
![\[Architekturdiagramm für das benutzerdefinierte Identity Provider-Toolkit, verfügbar in. GitHub\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/custom-idp-solution-high-level-architecture.png)
**Anmerkung**
Wenn Sie zuvor benutzerdefinierte Vorlagen und Beispiele für Identitätsanbieter verwendet haben, sollten Sie stattdessen diese Lösung in Betracht ziehen. In Zukunft werden anbieterspezifische Module diese Lösung standardisieren. Diese Lösung wird fortlaufend gewartet und die Funktionen erweitert.
Diese Lösung enthält Standardmuster für die Implementierung eines benutzerdefinierten Anbieters, der Details wie die Protokollierung und den Speicherort der zusätzlichen Sitzungsmetadaten AWS Transfer Family, wie z. B. der `HomeDirectoryDetails` Parameter, berücksichtigt. Diese Lösung bietet eine wiederverwendbare Grundlage für die Implementierung benutzerdefinierter Identitätsanbieter mit einer detaillierten Sitzungskonfiguration pro Benutzer und entkoppelt die Authentifizierungslogik des Identitätsanbieters von der wiederverwendbaren Logik, die eine Konfiguration erstellt, die an Transfer Family zurückgegeben wird, um die Authentifizierung abzuschließen und Einstellungen für die Sitzung festzulegen.
[Der Code und die unterstützenden Ressourcen für diese Lösung sind unter -family verfügbar. https://github.com/aws-samples/ toolkit-for-aws-transfer](https://github.com/aws-samples/toolkit-for-aws-transfer-family)
Das Toolkit enthält die folgenden Funktionen:
+ Eine [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam)Vorlage, die die erforderlichen Ressourcen bereitstellt. Optional können Sie Amazon API Gateway zur Integration bereitstellen und konfigurieren AWS WAF, wie im Blogbeitrag [Securing AWS Transfer Family with AWS Web Application Firewall and Amazon API Gateway](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) beschrieben.
+ Ein [Amazon DynamoDB DynamoDB-Schema](https://aws.amazon.com/dynamodb) zum Speichern von Konfigurationsmetadaten über Identitätsanbieter, einschließlich Benutzersitzungseinstellungen wie `HomeDirectoryDetails``Role`, und. `Policy`
+ Ein modularer Ansatz, der es Ihnen ermöglicht, der Lösung in future neue Identitätsanbieter als Module hinzuzufügen.
+ Abruf von Attributen: Rufen Sie optional IAM-Rollen- und POSIX-Profilattribute (UID und GID) von unterstützten Identitätsanbietern ab, einschließlich AD, LDAP und Okta.
+ Support für mehrere Identitätsanbieter, die mit einem einzigen Transfer Family Family-Server verbunden sind, und für mehrere Transfer Family Family-Server, die dieselbe Bereitstellung der Lösung verwenden.
+ Integrierte Überprüfung von IP-Zulassungslisten, z. B. IP-Zulassungslisten, die optional pro Benutzer oder pro Identitätsanbieter konfiguriert werden können.
+ Detaillierte Protokollierung mit konfigurierbarer Protokollebene und Ablaufverfolgungsunterstützung zur Unterstützung bei der Fehlerbehebung.
Bevor Sie mit der Bereitstellung der benutzerdefinierten Identitätsanbieter-Lösung beginnen, benötigen Sie die folgenden Ressourcen. AWS
+ Eine Amazon Virtual Private Cloud (VPC) mit privaten Subnetzen, mit Internetkonnektivität entweder über ein NAT-Gateway oder einen DynamoDB-Gateway-Endpunkt.
+ Entsprechende IAM-Berechtigungen zur Ausführung der folgenden Aufgaben:
+ Stellen Sie die `custom-idp.yaml` CloudFormation Vorlage bereit,
+ AWS CodePipeline Projekte erstellen
+ AWS CodeBuild Projekte erstellen
+ Erstellen Sie IAM-Rollen und -Richtlinien
**Wichtig**
Sie müssen die Lösung auf demselben AWS-Konto Server bereitstellen AWS-Region , der Ihre Transfer Family Family-Zielserver enthält.
## Unterstützte Identitätsanbieter
Die folgende Liste enthält Informationen zu Identitätsanbietern, die für die benutzerdefinierte Identitätsanbieterlösung unterstützt werden.
| Anbieter | Passwörter fließen | Öffentliche Schlüssel fließen | Multifaktoriell | Abrufen von Attributen | Details |
| --- | --- | --- | --- | --- | --- |
| Active Directory und LDAP | Ja | Ja | Nein | Ja | Die Benutzerverifizierung kann im Rahmen der Authentifizierung mit öffentlichen Schlüsseln durchgeführt werden. |
| Argon2 (lokaler Hash) | Ja | Nein | Nein | Nein | Argon2-Hashes werden im Benutzerdatensatz für Anwendungsfälle der „lokalen“ passwortbasierten Authentifizierung gespeichert. |
| Amazon Cognito | Ja | Nein | Ja\$1 | Nein | Nur auf der Grundlage von zeitbasiertem Einmalpasswort (TOTP) mehrstufige Authentifizierung. \$1SMS-basierte MFA wird nicht unterstützt. |
| Entra ID (früher Azure AD) | Ja | Nein | Nein | Nein | |
| Okta | Ja | Ja | Ja\$1 | Ja | Nur TOTP-basierte MFA. |
| Öffentlicher Schlüssel | Nein | Ja | Nein | Nein | Öffentliche Schlüssel werden im Benutzerdatensatz in DynamoDB gespeichert. |
| Secrets Manager | Ja | Ja | Nein | Nein | |
# Wird AWS Lambda zur Integration Ihres Identitätsanbieters verwendet
In diesem Thema wird beschrieben, wie Sie eine AWS Lambda Funktion erstellen, die eine Verbindung zu Ihrem benutzerdefinierten Identitätsanbieter herstellt. Sie können einen beliebigen benutzerdefinierten Identitätsanbieter wie Okta, Secrets Manager oder einen benutzerdefinierten Datenspeicher verwenden OneLogin, der Autorisierungs- und Authentifizierungslogik enthält.
Für die meisten Anwendungsfälle wird empfohlen, einen benutzerdefinierten Identitätsanbieter zu konfigurieren, die [Lösung für einen benutzerdefinierten Identitätsanbieter](custom-idp-toolkit.md) Verwendung von.
**Anmerkung**
Bevor Sie einen Transfer Family Family-Server erstellen, der Lambda als Identitätsanbieter verwendet, müssen Sie die Funktion erstellen. Eine Beispielfunktion für Lambda finden Sie unter [Beispiele für Lambda-Funktionen](#lambda-auth-examples). Oder Sie können einen CloudFormation Stack bereitstellen, der einen der [Lambda-Funktionsvorlagen](#lambda-idp-templates) folgenden verwendet. Stellen Sie außerdem sicher, dass Ihre Lambda-Funktion eine ressourcenbasierte Richtlinie verwendet, die Transfer Family vertraut. Eine Beispielrichtlinie finden Sie unter [Ressourcenbasierte Lambda-Richtlinie](#lambda-resource-policy).
1. Öffnen Sie die [AWS Transfer Family -Konsole](https://console.aws.amazon.com/transfer/).
1. **Wählen Sie **Server erstellen, um die Seite Server erstellen** zu öffnen.** **Wählen Sie für Wählen Sie einen Identitätsanbieter** die Option **Benutzerdefinierter Identitätsanbieter** aus, wie im folgenden Screenshot gezeigt.
![\[Im Bereich Konsole „Identitätsanbieter auswählen“ ist die Option Benutzerdefinierter Identitätsanbieter ausgewählt. Außerdem ist der Standardwert ausgewählt, der besagt, dass Benutzer sich entweder mit ihrem Passwort oder Schlüssel authentifizieren können.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/custom-lambda-console.png)
**Anmerkung**
Die Wahl der Authentifizierungsmethoden ist nur verfügbar, wenn Sie SFTP als eines der Protokolle für Ihren Transfer Family Family-Server aktivieren.
1. Vergewissern Sie sich, dass der Standardwert „** AWS Lambda Zur Verbindung Ihres Identitätsanbieters verwenden**“ ausgewählt ist.
1. Wählen Sie unter **AWS Lambda Funktion** den Namen Ihrer Lambda-Funktion.
1. Füllen Sie die verbleibenden Felder aus und wählen Sie dann **Server erstellen** aus. Einzelheiten zu den verbleibenden Schritten zum Erstellen eines Servers finden Sie unter[Konfiguration eines SFTP-, FTPS- oder FTP-Serverendpunkts](tf-server-endpoint.md).
## Ressourcenbasierte Lambda-Richtlinie
Sie benötigen eine Richtlinie, die auf den Transfer Family Family-Server und Lambda ARNs verweist. Sie könnten beispielsweise die folgende Richtlinie mit Ihrer Lambda-Funktion verwenden, die eine Verbindung zu Ihrem Identitätsanbieter herstellt. Bei der Richtlinie wird JSON als Zeichenfolge maskiert.
****
```
"Policy":
"{\"Version\":\"2012-10-17\",
\"Id\":\"default\",
\"Statement\":[
{\"Sid\":\"AllowTransferInvocation\",
\"Effect\":\"Allow\",
\"Principal\":{\"Service\":\"transfer.amazonaws.com\"},
\"Action\":\"lambda:InvokeFunction\",
\"Resource\":\"arn:aws:lambda:region:123456789012:function:my-lambda-auth-function\",
\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:transfer:region:123456789012:server/server-id\"}}}
]}"
```
**Anmerkung**
Ersetzen Sie in der obigen Beispielrichtlinie jede Richtlinie *user input placeholder* durch Ihre eigenen Informationen.
## Struktur von Ereignismeldungen
Die Struktur der Ereignisnachrichten, die vom SFTP-Server an die Lambda-Funktion des Autorisierers für einen benutzerdefinierten IDP gesendet werden, lautet wie folgt.
```
{
"username": "value",
"password": "value",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
Wo `username` und `password` sind die Werte für die Anmeldeinformationen, die an den Server gesendet werden.
Sie geben beispielsweise den folgenden Befehl ein, um eine Verbindung herzustellen:
```
sftp bobusa@server_hostname
```
Sie werden dann aufgefordert, Ihr Passwort einzugeben:
```
Enter password:
mysecretpassword
```
Sie können dies von Ihrer Lambda-Funktion aus überprüfen, indem Sie das übergebene Ereignis aus der Lambda-Funktion heraus drucken. Es sollte dem folgenden Textblock ähneln.
```
{
"username": "bobusa",
"password": "mysecretpassword",
"protocol": "SFTP",
"serverId": "s-abcd123456",
"sourceIp": "192.168.0.100"
}
```
Die Ereignisstruktur ist für FTP und FTPS ähnlich: Der einzige Unterschied besteht darin, dass diese Werte für den `protocol` Parameter und nicht für SFTP verwendet werden.
## Lambda-Funktionen für die Authentifizierung
Bearbeiten Sie die Lambda-Funktion, um verschiedene Authentifizierungsstrategien zu implementieren. Um die Anforderungen Ihrer Anwendung zu erfüllen, können Sie einen CloudFormation Stack bereitstellen. Weitere Informationen zu Lambda finden Sie im [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) oder im [Building Lambda functions with Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).
**Topics**
+ [
### Gültige Lambda-Werte
](#lambda-valid-values)
+ [
### Beispiele für Lambda-Funktionen
](#lambda-auth-examples)
+ [
### Testen Sie Ihre Konfiguration
](#authentication-test-configuration)
+ [
### Lambda-Funktionsvorlagen
](#lambda-idp-templates)
### Gültige Lambda-Werte
In der folgenden Tabelle werden Details zu den Werten beschrieben, die Transfer Family für Lambda-Funktionen akzeptiert, die für benutzerdefinierte Identitätsanbieter verwendet werden.
| Wert | Description | Erforderlich |
| --- | --- | --- |
| `Role` | Gibt den Amazon-Ressourcennamen (ARN) der IAM-Rolle an, die den Zugriff Ihrer Benutzer auf Ihren Amazon S3-Bucket oder Ihr Amazon EFS-Dateisystem steuert. Die mit dieser Rolle verknüpften Richtlinien bestimmen die Zugriffsebene, die Sie Ihren Benutzern beim Übertragen von Dateien in und aus Ihrem Amazon S3- oder Amazon EFS-Dateisystem gewähren möchten. Die IAM-Rolle sollte außerdem eine Vertrauensstellung enthalten, mit der der Server Zugriff auf Ihre Ressourcen erhält, wenn er die Übertragungsanfragen Ihres Benutzers bearbeitet. Einzelheiten zum Aufbau einer Vertrauensbeziehung finden Sie unter[So stellen Sie eine Vertrauensbeziehung her](requirements-roles.md#establish-trust-transfer). | Erforderlich |
| `PosixProfile` | Die vollständige POSIX-Identität, einschließlich Benutzer-ID (`Uid`), Gruppen-ID (`Gid`) und jeder sekundären Gruppe IDs (`SecondaryGids`), die den Zugriff Ihrer Benutzer auf Ihre Amazon EFS-Dateisysteme steuert. Die POSIX-Berechtigungen, die für Dateien und Verzeichnisse in Ihrem Dateisystem festgelegt sind, bestimmen die Zugriffsebene, die Ihre Benutzer beim Übertragen von Dateien in und aus Ihren Amazon EFS-Dateisystemen erhalten. | Erforderlich für Amazon EFS-Backing-Speicher |
| `PublicKeys` | Eine Liste der Werte für öffentliche SSH-Schlüssel, die für diesen Benutzer gültig sind. Eine leere Liste bedeutet, dass dies kein gültiges Login ist. Darf bei der Passwortauthentifizierung nicht zurückgegeben werden. | Optional |
| `Policy` | Eine Sitzungsrichtlinie für Ihren Benutzer, sodass Sie dieselbe IAM-Rolle für mehrere Benutzer verwenden können. Diese Richtlinie grenzt den Benutzerzugriff auf Teile ihres Amazon S3-Buckets ein. Weitere Informationen zur Verwendung von Sitzungsrichtlinien mit benutzerdefinierten Identitätsanbietern finden Sie in den Beispielen für Sitzungsrichtlinien in diesem Thema. | Optional |
| `HomeDirectoryType` | Die Art des Zielverzeichnisses (Ordners), das das Home-Verzeichnis Ihrer Benutzer sein soll, wenn sie sich beim Server anmelden. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/custom-lambda-idp.html) | Optional |
| `HomeDirectoryDetails` | Logische Verzeichniszuordnungen, die angeben, welche Amazon S3- oder Amazon EFS-Pfade und -Schlüssel für Ihren Benutzer sichtbar sein sollen und wie Sie sie sichtbar machen möchten. Sie müssen das `Entry` `Target` Und-Paar angeben, das `Entry` zeigt, wie der Pfad sichtbar gemacht `Target` wird und der tatsächliche Amazon S3- oder Amazon EFS-Pfad ist. | Erforderlich, wenn `HomeDirectoryType` der Wert `LOGICAL` |
| `HomeDirectory` | Das Zielverzeichnis für einen Benutzer, wenn er sich über den Client am Server anmeldet. Das Format hängt von Ihrem Speicher-Backend ab: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/custom-lambda-idp.html) Der Bucket-Name oder die Amazon EFS-Dateisystem-ID müssen im Pfad enthalten sein. Wenn Sie diese Informationen weglassen, treten bei Dateiübertragungen die Fehlermeldung „Datei nicht gefunden“ auf. | Optional |
**Anmerkung**
`HomeDirectoryDetails`ist eine Zeichenkettendarstellung einer JSON-Map. Dies steht im Gegensatz zu`PosixProfile`, was ein eigentliches JSON-Map-Objekt ist und `PublicKeys` welches ein JSON-Array von Zeichenketten ist. Die sprachspezifischen Details finden Sie in den Codebeispielen.
**HomeDirectory Anforderungen an das Format**
Achten Sie bei der Verwendung des `HomeDirectory` Parameters darauf, dass Sie das vollständige Pfadformat angeben:
**Für Amazon S3 S3-Speicher:** Geben Sie immer den Bucket-Namen im Format an `/bucket-name/path`
**Für Amazon EFS-Speicher:** Geben Sie immer die Dateisystem-ID im Format an `/fs-12345/path`
Eine häufige Ursache für Fehler „Datei nicht gefunden“ ist das Auslassen des Bucket-Namens oder der EFS-Dateisystem-ID im `HomeDirectory` Pfad. Die Einstellung „`HomeDirectory`Nur `/` ohne Speicher-ID“ führt dazu, dass die Authentifizierung erfolgreich ist, Dateioperationen jedoch fehlschlagen.
### Beispiele für Lambda-Funktionen
In diesem Abschnitt werden einige Lambda-Beispielfunktionen sowohl in NodeJS als auch in Python vorgestellt.
**Anmerkung**
In diesen Beispielen sind der Benutzer, die Rolle, das POSIX-Profil, das Passwort und die Home-Verzeichnisdetails allesamt Beispiele und müssen durch Ihre tatsächlichen Werte ersetzt werden.
------
#### [ Logical home directory, NodeJS ]
Die folgende NodeJS-Beispielfunktion stellt die Details für einen Benutzer bereit, der über ein [logisches Home-Verzeichnis](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html) verfügt.
```
// GetUserConfig Lambda
exports.handler = (event, context, callback) => {
console.log("Username:", event.username, "ServerId: ", event.serverId);
var response;
// Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
if (event.serverId !== "" && event.username == 'example-user') {
var homeDirectoryDetails = [
{
Entry: "/",
Target: "/fs-faa1a123"
}
];
response = {
Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
PosixProfile: {"Gid": 65534, "Uid": 65534}, // Required for EFS access, but not needed for S3
HomeDirectoryDetails: JSON.stringify(homeDirectoryDetails),
HomeDirectoryType: "LOGICAL",
};
// Check if password is provided
if (!event.password) {
// If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
// Check if password is correct
} else if (event.password !== 'Password1234') {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
} else {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
callback(null, response);
};
```
------
#### [ Path-based home directory, NodeJS ]
Die folgende NodeJS-Beispielfunktion stellt die Details für einen Benutzer bereit, der über ein pfadbasiertes Home-Verzeichnis verfügt.
```
// GetUserConfig Lambda
exports.handler = (event, context, callback) => {
console.log("Username:", event.username, "ServerId: ", event.serverId);
var response;
// Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
// There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
if (event.serverId !== "" && event.username == 'example-user') {
response = {
Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
Policy: '', // Optional, JSON stringified blob to further restrict this user's permissions
// HomeDirectory format depends on your storage backend:
// For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
// For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
HomeDirectory: '/my-transfer-bucket/users/example-user' // S3 example - replace with your bucket name
// HomeDirectory: '/fs-faa1a123/users/example-user' // EFS example - uncomment for EFS
};
// Check if password is provided
if (!event.password) {
// If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
// Check if password is correct
} else if (event.password !== 'Password1234') {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
} else {
// Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {};
}
callback(null, response);
};
```
------
#### [ Logical home directory, Python ]
Die folgende Python-Beispielfunktion stellt die Details für einen Benutzer bereit, der über ein [logisches Home-Verzeichnis](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html) verfügt.
```
# GetUserConfig Python Lambda with LOGICAL HomeDirectoryDetails
import json
def lambda_handler(event, context):
print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))
response = {}
# Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
if event['serverId'] != '' and event['username'] == 'example-user':
homeDirectoryDetails = [
{
'Entry': '/',
'Target': '/fs-faa1a123'
}
]
response = {
'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
'PosixProfile': {"Gid": 65534, "Uid": 65534}, # Required for EFS access, but not needed for S3
'HomeDirectoryDetails': json.dumps(homeDirectoryDetails),
'HomeDirectoryType': "LOGICAL"
}
# Check if password is provided
if event.get('password', '') == '':
# If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
# Check if password is correct
elif event['password'] != 'Password1234':
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
else:
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
return response
```
------
#### [ Path-based home directory, Python ]
Die folgende Python-Beispielfunktion stellt die Details für einen Benutzer bereit, der über ein pfadbasiertes Home-Verzeichnis verfügt.
```
# GetUserConfig Python Lambda with PATH HomeDirectory
def lambda_handler(event, context):
print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))
response = {}
# Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
# There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
if event['serverId'] != '' and event['username'] == 'example-user':
response = {
'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
'Policy': '', # Optional, JSON stringified blob to further restrict this user's permissions
# HomeDirectory format depends on your storage backend:
# For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
# For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
'HomeDirectory': '/my-transfer-bucket/users/example-user', # S3 example - replace with your bucket name
# 'HomeDirectory': '/fs-faa1a123/users/example-user', # EFS example - uncomment for EFS
'HomeDirectoryType': "PATH" # Not strictly required, defaults to PATH
}
# Check if password is provided
if event.get('password', '') == '':
# If no password provided, return the user's SSH public key
response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
# Check if password is correct
elif event['password'] != 'Password1234':
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
else:
# Return HTTP status 200 but with no role in the response to indicate authentication failure
response = {}
return response
```
------
### Testen Sie Ihre Konfiguration
Nachdem Sie Ihren benutzerdefinierten Identitätsanbieter erstellt haben, sollten Sie Ihre Konfiguration testen.
------
#### [ Console ]
**Um Ihre Konfiguration mit der AWS Transfer Family Konsole zu testen**
1. Öffnen Sie die [AWS Transfer Family -Konsole](https://console.aws.amazon.com/transfer/).
1. Wählen Sie auf der Seite **Server** Ihren neuen Server aus, klicken Sie auf **Aktionen** und dann auf **Test**.
1. Geben Sie den Text für **Benutzername** und **Passwort ein**, den Sie bei der Bereitstellung des CloudFormation Stacks festgelegt haben. Wenn Sie die Standardoptionen beibehalten haben, lautet der Benutzername `myuser` und das Passwort`MySuperSecretPassword`.
1. Wählen Sie das **Serverprotokoll** und geben Sie die IP-Adresse für **Quell-IP** ein, falls Sie diese bei der Bereitstellung des CloudFormation Stacks festgelegt haben.
------
#### [ CLI ]
**So testen Sie Ihre Konfiguration mit der AWS CLI**
1. Führen Sie den Befehl [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html) aus. Ersetzen Sie jede `user input placeholder` durch Ihre eigenen Informationen, wie in den nachfolgenden Schritten beschrieben.
```
aws transfer test-identity-provider --server-id s-1234abcd5678efgh --user-name myuser --user-password MySuperSecretPassword --server-protocol FTP --source-ip 127.0.0.1
```
1. Geben Sie die Server-ID ein.
1. Geben Sie den Benutzernamen und das Passwort ein, die Sie bei der Bereitstellung des CloudFormation Stacks festgelegt haben. Wenn Sie die Standardoptionen beibehalten haben, lautet der Benutzername `myuser` und das Passwort`MySuperSecretPassword`.
1. Geben Sie das Serverprotokoll und die Quell-IP-Adresse ein, falls Sie sie bei der Bereitstellung des CloudFormation Stacks festgelegt haben.
------
Wenn die Benutzerauthentifizierung erfolgreich ist, gibt der Test eine `StatusCode: 200` HTTP-Antwort, eine leere Zeichenfolge `Message: ""` (die andernfalls einen Grund für den Fehler enthalten würde) und ein `Response` Feld zurück.
**Anmerkung**
Im Antwortbeispiel unten ist das `Response` Feld ein JSON-Objekt, das „stringifiziert“ wurde (in eine einfache JSON-Zeichenfolge umgewandelt, die innerhalb eines Programms verwendet werden kann) und die Details der Rollen und Berechtigungen des Benutzers enthält.
```
{
"Response":"{\"Policy\":\"{\\\"Version\\\":\\\"2012-10-17\\\",\\\"Statement\\\":[{\\\"Sid\\\":\\\"ReadAndListAllBuckets\\\",\\\"Effect\\\":\\\"Allow\\\",\\\"Action\\\":[\\\"s3:ListAllMybuckets\\\",\\\"s3:GetBucketLocation\\\",\\\"s3:ListBucket\\\",\\\"s3:GetObjectVersion\\\",\\\"s3:GetObjectVersion\\\"],\\\"Resource\\\":\\\"*\\\"}]}\",\"Role\":\"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\":\"/\"}",
"StatusCode": 200,
"Message": ""
}
```
### Lambda-Funktionsvorlagen
Sie können einen CloudFormation Stack bereitstellen, der eine Lambda-Funktion zur Authentifizierung verwendet. Wir stellen mehrere Vorlagen zur Verfügung, mit denen Sie Ihre Benutzer mithilfe von Anmeldeinformationen authentifizieren und autorisieren können. Sie können diese Vorlagen oder den AWS Lambda Code ändern, um den Benutzerzugriff weiter anzupassen.
**Anmerkung**
Sie können einen FIPS-fähigen AWS Transfer Family Server erstellen, CloudFormation indem Sie in Ihrer Vorlage eine FIPS-fähige Sicherheitsrichtlinie angeben. Die verfügbaren Sicherheitsrichtlinien werden unter beschrieben [Sicherheitsrichtlinien für Server AWS Transfer Family](security-policies.md)
**Um einen CloudFormation Stack für die Authentifizierung zu erstellen**
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Folgen Sie den Anweisungen zum Bereitstellen eines CloudFormation Stacks aus einer vorhandenen Vorlage unter [Auswahl einer Stack-Vorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) im *AWS CloudFormation Benutzerhandbuch*.
1. Verwenden Sie eine der folgenden Vorlagen, um eine Lambda-Funktion für die Authentifizierung in Transfer Family zu erstellen.
+ [Klassische (Amazon Cognito) Stack-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml)
Eine grundlegende Vorlage zum Erstellen einer Vorlage AWS Lambda zur Verwendung als benutzerdefinierter Identitätsanbieter in AWS Transfer Family. Es authentifiziert sich bei Amazon Cognito für die kennwortbasierte Authentifizierung und öffentliche Schlüssel werden aus einem Amazon S3 S3-Bucket zurückgegeben, wenn eine Authentifizierung auf Basis eines öffentlichen Schlüssels verwendet wird. Nach der Bereitstellung können Sie den Lambda-Funktionscode ändern, um etwas anderes zu tun.
+ [AWS Secrets Manager Vorlage stapeln](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml)
Eine grundlegende Vorlage, die AWS Lambda zusammen mit einem AWS Transfer Family Server verwendet wird, um Secrets Manager als Identitätsanbieter zu integrieren. Sie authentifiziert sich anhand eines Eintrags in AWS Secrets Manager diesem Format`aws/transfer/server-id/username`. Darüber hinaus muss das Geheimnis die Schlüssel-Wert-Paare für alle Benutzereigenschaften enthalten, die an Transfer Family zurückgegeben werden. Nach der Bereitstellung können Sie den Lambda-Funktionscode ändern, um etwas anderes zu tun.
+ [Okta-Stack-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml): Eine Basisvorlage, die AWS Lambda zusammen mit einem AWS Transfer Family Server verwendet wird, um Okta als benutzerdefinierten Identitätsanbieter zu integrieren.
+ [Okta-MFA-Stack-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml): Eine Basisvorlage, die AWS Lambda zusammen mit einem AWS Transfer Family Server zur Integration von Okta mit Multi-Faktor-Authentifizierung als benutzerdefiniertem Identitätsanbieter verwendet wird.
+ [Azure Active Directory-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml): Einzelheiten zu diesem Stack werden im Blogbeitrag [Authentifizierung AWS Transfer Family mit](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/) Azure Active Directory und beschrieben. AWS Lambda
Nachdem der Stack bereitgestellt wurde, können Sie Details dazu auf der Registerkarte **Ausgaben** in der CloudFormation Konsole einsehen.
Die Bereitstellung eines dieser Stacks ist der einfachste Weg, einen benutzerdefinierten Identitätsanbieter in den Transfer Family Family-Workflow zu integrieren.
# Verwenden Sie Amazon API Gateway zur Integration Ihres Identitätsanbieters
In diesem Thema wird beschrieben, wie Sie eine AWS Lambda Funktion verwenden, um eine API-Gateway-Methode zu unterstützen. Verwenden Sie diese Option, wenn Sie eine RESTful API zur Integration Ihres Identitätsanbieters benötigen oder wenn Sie deren Funktionen zum Geoblocking oder AWS WAF zur Ratenbegrenzung von Anfragen nutzen möchten.
Für die meisten Anwendungsfälle wird empfohlen, einen benutzerdefinierten Identitätsanbieter zu konfigurieren, die Verwendung von. [Lösung für einen benutzerdefinierten Identitätsanbieter](custom-idp-toolkit.md)
**Einschränkungen bei der Verwendung eines API Gateway zur Integration Ihres Identitätsanbieters**
+ Diese Konfiguration unterstützt keine benutzerdefinierten Domänen.
+ Diese Konfiguration unterstützt keine private API-Gateway-URL.
Wenn Sie eines davon benötigen, können Sie Lambda als Identitätsanbieter ohne API Gateway verwenden. Details hierzu finden Sie unter [Wird AWS Lambda zur Integration Ihres Identitätsanbieters verwendet](custom-lambda-idp.md).
## Authentifizierung mit einer API-Gateway-Methode
Sie können eine API-Gateway-Methode zur Verwendung als Identitätsanbieter für Transfer Family erstellen. Dieser Ansatz bietet Ihnen eine äußerst sichere Methode zum Erstellen und Bereitstellen APIs. Mit API Gateway können Sie einen HTTPS-Endpunkt erstellen, sodass alle eingehenden API-Operationen mit größerer Sicherheit übertragen werden. Weitere Informationen zum API Gateway-Dienst finden Sie im [API Gateway Developer Guide](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).
API Gateway bietet eine Autorisierungsmethode mit dem Namen`AWS_IAM`, die Ihnen dieselbe Authentifizierung auf Basis von AWS Identity and Access Management (IAM) bietet, die auch intern AWS verwendet wird. Wenn Sie die Authentifizierung mit aktivieren`AWS_IAM`, können nur Aufrufer mit ausdrücklichen Berechtigungen zum Aufrufen einer API die API-Gateway-Methode dieser API erreichen.
Um Ihre API Gateway Gateway-Methode als benutzerdefinierten Identitätsanbieter für Transfer Family zu verwenden, aktivieren Sie IAM für Ihre API Gateway Gateway-Methode. Im Rahmen dieses Prozesses stellen Sie eine IAM-Rolle mit Berechtigungen für Transfer Family bereit, Ihr Gateway zu verwenden.
**Anmerkung**
Um die Sicherheit zu verbessern, können Sie eine Firewall für Webanwendungen konfigurieren. AWS WAF ist eine Firewall für Webanwendungen, mit der Sie die HTTP- und HTTPS-Anfragen überwachen können, die an ein Amazon API Gateway weitergeleitet werden. Details hierzu finden Sie unter [Fügen Sie eine Firewall für Webanwendungen hinzu](web-application-firewall.md).
**API-Gateway-Caching nicht aktivieren**
Aktivieren Sie das Caching nicht für Ihre API-Gateway-Methode, wenn Sie sie als benutzerdefinierten Identitätsanbieter für Transfer Family verwenden. Caching ist aus folgenden Gründen unangemessen und für Authentifizierungsanfragen ungültig:
Jede Authentifizierungsanfrage ist einzigartig und erfordert eine Live-Antwort, keine zwischengespeicherte Antwort
Caching bietet keine Vorteile, da Transfer Family niemals doppelte oder wiederholte Anfragen an das API Gateway sendet
Wenn Sie das Caching aktivieren, antwortet das API Gateway mit nicht übereinstimmenden Daten, was zu ungültigen Antworten auf Authentifizierungsanfragen führt.
**So verwenden Sie Ihre API Gateway Gateway-Methode für die benutzerdefinierte Authentifizierung mit Transfer Family**
1. Erstellen Sie einen CloudFormation Stapel. So gehen Sie vor:
**Anmerkung**
Die Stack-Vorlagen wurden aktualisiert und verwenden nun BASE64 -kodierte Passwörter: Einzelheiten finden Sie unter. [Verbesserungen an den Vorlagen CloudFormation](#base64-templates)
1. [Öffnen Sie die CloudFormation Konsole unter /cloudformation. https://console.aws.amazon.com](https://console.aws.amazon.com/cloudformation/)
1. Folgen Sie den Anweisungen zum Bereitstellen eines CloudFormation Stacks aus einer vorhandenen Vorlage unter [Auswahl einer Stack-Vorlage](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) im *AWS CloudFormation Benutzerhandbuch*.
1. Verwenden Sie eine der folgenden Basisvorlagen, um eine AWS Lambda-gestützte API-Gateway-Methode zur Verwendung als benutzerdefinierter Identitätsanbieter in Transfer Family zu erstellen.
+ [Grundlegende Stack-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-apig.template.yml)
Standardmäßig wird Ihre API Gateway Gateway-Methode als benutzerdefinierter Identitätsanbieter verwendet, um einen einzelnen Benutzer auf einem einzelnen Server mithilfe eines hartcodierten SSH-Schlüssels (Secure Shell) oder eines Passworts zu authentifizieren. Nach der Bereitstellung können Sie den Lambda-Funktionscode ändern, um etwas anderes zu tun.
+ [AWS Secrets Manager Vorlage stapeln](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml)
Standardmäßig authentifiziert sich Ihre API Gateway Gateway-Methode anhand eines Eintrags im Secrets Manager des Formats`aws/transfer/server-id/username`. Darüber hinaus muss das Geheimnis die Schlüssel-Wert-Paare für alle Benutzereigenschaften enthalten, die an Transfer Family zurückgegeben werden. Nach der Bereitstellung können Sie den Lambda-Funktionscode ändern, um etwas anderes zu tun. Weitere Informationen finden Sie im Blogbeitrag [Aktivieren der Kennwortauthentifizierung für die AWS Transfer Family Verwendung AWS Secrets Manager](https://aws.amazon.com/blogs/storage/enable-password-authentication-for-aws-transfer-family-using-aws-secrets-manager-updated/).
+ [Okta-Stack-Vorlage](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-apig.template.yml)
Ihre API-Gateway-Methode lässt sich in Okta als benutzerdefinierter Identitätsanbieter in Transfer Family integrieren. Weitere Informationen finden Sie im Blogbeitrag [Okta als Identitätsanbieter verwenden mit](https://aws.amazon.com/blogs/storage/using-okta-as-an-identity-provider-with-aws-transfer-for-sftp/). AWS Transfer Family
Die Bereitstellung eines dieser Stacks ist der einfachste Weg, einen benutzerdefinierten Identitätsanbieter in den Transfer Family Family-Workflow zu integrieren. Jeder Stack verwendet die Lambda-Funktion, um Ihre API-Methode auf Basis von API Gateway zu unterstützen. Anschließend können Sie Ihre API-Methode als benutzerdefinierten Identitätsanbieter in Transfer Family verwenden. Standardmäßig authentifiziert die Lambda-Funktion einen einzelnen Benutzer, der `myuser` mit dem Passwort aufgerufen wird. `MySuperSecretPassword` Nach der Bereitstellung können Sie diese Anmeldeinformationen bearbeiten oder den Lambda-Funktionscode aktualisieren, um etwas anderes zu tun.
**Wichtig**
Wir empfehlen, dass Sie die standardmäßigen Benutzer- und Kennwortanmeldedaten bearbeiten.
Nachdem der Stack bereitgestellt wurde, können Sie Details dazu auf der Registerkarte **Ausgaben** in der CloudFormation Konsole einsehen. Zu diesen Details gehören der Amazon-Ressourcenname (ARN) des Stacks, der ARN der IAM-Rolle, die der Stack erstellt hat, und die URL für Ihr neues Gateway.
**Anmerkung**
Wenn Sie die Option des benutzerdefinierten Identitätsanbieters verwenden, um die passwortbasierte Authentifizierung für Ihre Benutzer zu aktivieren, und Sie die von API Gateway bereitgestellte Anfrage- und Antwortprotokollierung aktivieren, protokolliert API Gateway die Passwörter Ihrer Benutzer in Ihren Amazon Logs. CloudWatch Wir empfehlen nicht, dieses Protokoll in Ihrer Produktionsumgebung zu verwenden. Weitere Informationen finden Sie unter [ CloudWatch API-Protokollierung in API Gateway einrichten](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html) im *API Gateway Developer Guide*.
1. Überprüfen Sie die Konfiguration der API Gateway Gateway-Methode für Ihren Server. So gehen Sie vor:
1. Öffnen Sie die API Gateway Gateway-Konsole unter [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/).
1. Wählen Sie die **Basisvorlagen-API für Transfer Custom Identity Provider** aus, die von der CloudFormation Vorlage generiert wurde. Möglicherweise müssen Sie Ihre Region auswählen, um Ihre Gateways zu sehen.
1. Wählen Sie im Bereich **Ressourcen** die Option **GET** aus. Der folgende Screenshot zeigt die korrekte Methodenkonfiguration.
![\[API-Konfigurationsdetails mit den Methodenkonfigurationsparametern für die Anforderungspfade und die für die URL-Abfragezeichenfolge.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/apig-config-method-fields.png)
Zu diesem Zeitpunkt ist Ihr API-Gateway bereit für die Bereitstellung.
1. Wählen Sie für **Aktionen** die Option **Deploy API** aus. Wählen Sie für die **Bereitstellungsphase** die Option **prod** und dann **Deploy** aus.
Nachdem die API Gateway Gateway-Methode erfolgreich bereitgestellt wurde, können Sie sich ihre Leistung unter **Stufen** **> Phasendetails** ansehen, wie im folgenden Screenshot gezeigt.
**Anmerkung**
Kopieren Sie die **Invoke-URL-Adresse**, die oben auf dem Bildschirm angezeigt wird. Möglicherweise benötigen Sie sie für den nächsten Schritt.
![\[Details zur Phase, wobei die Aufruf-URL hervorgehoben ist.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/apig-config-method-invoke.png)
1. Öffnen Sie die AWS Transfer Family Konsole unter. [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)
1. Eine Transfer Family sollte für Sie erstellt worden sein, als Sie den Stack erstellt haben. Wenn nicht, konfigurieren Sie Ihren Server mithilfe dieser Schritte.
1. Wählen Sie **Server erstellen**, um die Seite **Server erstellen** zu öffnen. **Wählen Sie für Wählen Sie einen Identitätsanbieter** die Option **Benutzerdefiniert** und dann **Amazon API Gateway verwenden, um eine Verbindung zu Ihrem Identitätsanbieter** herzustellen, wie im folgenden Screenshot gezeigt.
![\[Der Identitätsanbieter-Bildschirm mit ausgewähltem Custom Identity Provider und ausgewähltem API Gateway für die Verbindung mit Ihrem Identitätsanbieter.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/create-server-choose-idp-custom.png)
1. Fügen Sie in das Textfeld **Geben Sie eine Amazon API Gateway Gateway-URL** ein die **Aufruf-URL-Adresse** des API Gateway-Endpunkts ein, den Sie in Schritt 3 dieses Verfahrens erstellt haben.
1. Wählen Sie unter **Rolle** die IAM-Rolle aus, die mit der CloudFormation Vorlage erstellt wurde. Diese Rolle ermöglicht es Transfer Family, Ihre API-Gateway-Methode aufzurufen.
Die Aufrufrolle enthält den CloudFormation Stack-Namen, den Sie für den Stack ausgewählt haben, den Sie in Schritt 1 erstellt haben. Es hat das folgende Format:`CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI`.
1. Füllen Sie die verbleibenden Felder aus und wählen Sie dann **Server erstellen**. Einzelheiten zu den verbleibenden Schritten zum Erstellen eines Servers finden Sie unter[Konfiguration eines SFTP-, FTPS- oder FTP-Serverendpunkts](tf-server-endpoint.md).
## Implementierung Ihrer API-Gateway-Methode
Um einen benutzerdefinierten Identitätsanbieter für Transfer Family zu erstellen, muss Ihre API-Gateway-Methode eine einzelne Methode implementieren, die einen Ressourcenpfad von hat`/servers/serverId/users/username/config`. Die `username` Werte `serverId` und stammen aus dem RESTful Ressourcenpfad. Fügen Sie außerdem `sourceIp` und `protocol` als **URL-Abfragezeichenfolgenparameter** zur **Methodenanforderung** hinzu, wie in der folgenden Abbildung gezeigt.
![\[Der Ressourcenbildschirm des API Gateway mit den GET Methodendetails.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/apig-config-method-request.png)
**Anmerkung**
Der Benutzername muss mindestens 3 und maximal 100 Zeichen lang sein. Sie können die folgenden Zeichen im Benutzernamen verwenden: a—z, A-Z, 0—9, Unterstrich '\$1', Bindestrich '-', Punkt '.' und das Zeichen '@'. Der Benutzername darf nicht mit einem Bindestrich '-', einem Punkt '.' oder einem Zeichen '@' beginnen.
Wenn Transfer Family versucht, Ihren Benutzer mit einem Passwort zu authentifizieren, stellt der Dienst ein `Password:` Header-Feld bereit. In Ermangelung eines `Password:` Headers versucht Transfer Family, Ihren Benutzer mit einer Authentifizierung mit öffentlichem Schlüssel zu authentifizieren.
Wenn Sie einen Identitätsanbieter zur Authentifizierung und Autorisierung von Endbenutzern verwenden, können Sie neben der Überprüfung ihrer Anmeldeinformationen auch Zugriffsanfragen auf der Grundlage der IP-Adressen der von Ihren Endbenutzern verwendeten Clients zulassen oder ablehnen. Mit dieser Funktion können Sie sicherstellen, dass auf Daten, die in Ihren S3-Buckets oder Ihrem Amazon EFS-Dateisystem gespeichert sind, über die unterstützten Protokolle nur von IP-Adressen aus zugegriffen werden kann, die Sie als vertrauenswürdig angegeben haben. Um diese Funktion zu aktivieren, müssen Sie sie `sourceIp` in der Abfragezeichenfolge angeben.
Wenn Sie mehrere Protokolle für Ihren Server aktiviert haben und den Zugriff mit demselben Benutzernamen über mehrere Protokolle ermöglichen möchten, können Sie dies tun, sofern die für jedes Protokoll spezifischen Anmeldeinformationen in Ihrem Identitätsanbieter eingerichtet wurden. Um diese Funktion zu aktivieren, müssen Sie den `protocol` Wert in den RESTful Ressourcenpfad aufnehmen.
Ihre API Gateway Gateway-Methode sollte immer den HTTP-Statuscode zurückgeben`200`. Jeder andere HTTP-Statuscode bedeutet, dass beim Zugriff auf die API ein Fehler aufgetreten ist.
**Amazon S3 S3-Beispielantwort**
Der Beispielantworttext ist ein JSON-Dokument der folgenden Form für Amazon S3.
```
{
"Role": "IAM role with configured S3 permissions",
"PublicKeys": [
"ssh-rsa public-key1",
"ssh-rsa public-key2"
],
"Policy": "STS Assume role session policy",
"HomeDirectory": "/amzn-s3-demo-bucket/path/to/home/directory"
}
```
**Anmerkung**
Der Richtlinie wird JSON als Zeichenfolge maskiert. Beispiel:
****
```
"Policy":
"{
\"Version\": \"2012-10-17\",
\"Statement\":
[
{\"Condition\":
{\"StringLike\":
{\"s3:prefix\":
[\"user/*\", \"user/\"]}},
\"Resource\": \"arn:aws:s3:::amzn-s3-demo-bucket\",
\"Action\": \"s3:ListBucket\",
\"Effect\": \"Allow\",
\"Sid\": \"ListHomeDir\"},
{\"Resource\": \"arn:aws:s3:::*\",
\"Action\": [\"s3:PutObject\",
\"s3:GetObject\",
\"s3:DeleteObjectVersion\",
\"s3:DeleteObject\",
\"s3:GetObjectVersion\",
\"s3:GetObjectACL\",
\"s3:PutObjectACL\"],
\"Effect\": \"Allow\",
\"Sid\": \"HomeDirObjectAccess\"}]
}"
```
Die folgende Beispielantwort zeigt, dass ein Benutzer einen logischen Home-Verzeichnistyp hat.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-s3",
"HomeDirectoryType":"LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/amzn-s3-demo-bucket1\"}]",
"PublicKeys":[""]
}
```
**Amazon EFS-Beispielantwort**
Der Beispielantworttext ist ein JSON-Dokument der folgenden Form für Amazon EFS.
```
{
"Role": "IAM role with configured EFS permissions",
"PublicKeys": [
"ssh-rsa public-key1",
"ssh-rsa public-key2"
],
"PosixProfile": {
"Uid": "POSIX user ID",
"Gid": "POSIX group ID",
"SecondaryGids": [Optional list of secondary Group IDs],
},
"HomeDirectory": "/fs-id/path/to/home/directory"
}
```
Das `Role` Feld zeigt, dass eine erfolgreiche Authentifizierung stattgefunden hat. Bei der Passwortauthentifizierung (wenn Sie einen `Password:` Header angeben), müssen Sie keine öffentlichen SSH-Schlüssel angeben. Wenn ein Benutzer nicht authentifiziert werden kann, z. B. wenn das Passwort falsch ist, sollte Ihre Methode eine Antwort zurückgeben, die nicht gesetzt ist. `Role` Ein Beispiel für eine solche Antwort ist ein leeres JSON-Objekt.
Die folgende Beispielantwort zeigt einen Benutzer mit einem logischen Home-Verzeichnistyp.
```
{
"Role": "arn:aws:iam::123456789012:role/transfer-access-role-efs",
"HomeDirectoryType": "LOGICAL",
"HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/faa1a123\"}]",
"PublicKeys":[""],
"PosixProfile":{"Uid":65534,"Gid":65534}
}
```
Sie können Benutzerrichtlinien in die Lambda-Funktion im JSON-Format aufnehmen. Weitere Informationen zur Konfiguration von Benutzerrichtlinien in Transfer Family finden Sie unter[Verwaltung von Zugriffssteuerungen](users-policies.md).
## Standard-Lambda-Funktion
Um verschiedene Authentifizierungsstrategien zu implementieren, bearbeiten Sie die Lambda-Funktion, die Ihr Gateway verwendet. Um Ihnen zu helfen, die Anforderungen Ihrer Anwendung zu erfüllen, können Sie die folgenden Lambda-Beispielfunktionen in Node.js verwenden. Weitere Informationen zu Lambda finden Sie im [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) oder im [Building Lambda functions with Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).
Die folgende Lambda-Beispielfunktion verwendet Ihren Benutzernamen, Ihr Passwort (wenn Sie eine Passwortauthentifizierung durchführen), Ihre Server-ID, Ihr Protokoll und Ihre Client-IP-Adresse. Sie können eine Kombination dieser Eingaben verwenden, um nach Ihrem Identitätsanbieter zu suchen und festzustellen, ob die Anmeldung akzeptiert werden soll.
**Anmerkung**
Wenn Sie mehrere Protokolle für Ihren Server aktiviert haben und den Zugriff mit demselben Benutzernamen über mehrere Protokolle ermöglichen möchten, können Sie dies tun, sofern die für das Protokoll spezifischen Anmeldeinformationen in Ihrem Identitätsanbieter eingerichtet wurden.
Für das File Transfer Protocol (FTP) empfehlen wir, separate Anmeldeinformationen für Secure Shell (SSH) File Transfer Protocol (SFTP) und File Transfer Protocol over SSL (FTPS) zu verwenden. Wir empfehlen, separate Anmeldeinformationen für FTP zu verwenden, da FTP im Gegensatz zu SFTP und FTPS Anmeldeinformationen im Klartext überträgt. Wenn FTP-Anmeldeinformationen von SFTP oder FTPS isoliert werden, bleiben Ihre Workloads, die SFTP oder FTPS verwenden, sicher, wenn FTP-Anmeldeinformationen geteilt oder offengelegt werden.
Diese Beispielfunktion gibt die Rollen- und logischen Basisverzeichnisdetails zusammen mit den öffentlichen Schlüsseln zurück (sofern sie die Authentifizierung mit öffentlichen Schlüsseln durchführt).
Wenn Sie vom Service verwaltete Benutzer erstellen, legen Sie deren Basisverzeichnis fest, entweder logisch oder physisch. In ähnlicher Weise benötigen wir die Ergebnisse der Lambda-Funktion, um die gewünschte physische oder logische Verzeichnisstruktur des Benutzers zu vermitteln. Die von Ihnen festgelegten Parameter hängen vom Wert für das [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType)Feld ab.
+ `HomeDirectoryType`gesetzt auf `PATH` — das `HomeDirectory` Feld muss dann ein absolutes Amazon S3 S3-Bucket-Präfix oder ein absoluter Amazon EFS-Pfad sein, der für Ihre Benutzer sichtbar ist.
+ `HomeDirectoryType`gesetzt auf `LOGICAL` — Legen Sie *kein* `HomeDirectory` Feld fest. Stattdessen legen wir ein `HomeDirectoryDetails` Feld fest, das die gewünschten Entry/Target Zuordnungen bereitstellt, ähnlich den im [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings)Parameter beschriebenen Werten für vom Service verwaltete Benutzer.
Die Beispielfunktionen sind unter aufgeführt. [Beispiele für Lambda-Funktionen](custom-lambda-idp.md#lambda-auth-examples)
## Lambda-Funktion zur Verwendung mit AWS Secrets Manager
Um sie AWS Secrets Manager als Identitätsanbieter zu verwenden, können Sie mit der Lambda-Funktion in der CloudFormation Beispielvorlage arbeiten. Die Lambda-Funktion fragt den Secrets Manager Manager-Dienst mit Ihren Anmeldeinformationen ab und gibt bei Erfolg ein bestimmtes Geheimnis zurück. Weitere Informationen zu Secrets Manager finden Sie im [Benutzerhandbuch für AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Um eine CloudFormation Beispielvorlage herunterzuladen, die diese Lambda-Funktion verwendet, rufen Sie den [Amazon S3 S3-Bucket auf, der von bereitgestellt wird AWS Transfer Family](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml).
## Verbesserungen an den Vorlagen CloudFormation
An den veröffentlichten CloudFormation Vorlagen wurden Verbesserungen an der API Gateway Gateway-Schnittstelle vorgenommen. Die Vorlagen verwenden jetzt BASE64 -kodierte Passwörter mit dem API Gateway. Ihre bestehenden Bereitstellungen funktionieren auch ohne diese Erweiterung, lassen jedoch keine Passwörter zu, deren Zeichen außerhalb des grundlegenden US-ASCII-Zeichensatzes liegen.
Die Änderungen in der Vorlage, die diese Funktion ermöglichen, lauten wie folgt:
+ Die `GetUserConfigRequest AWS::ApiGateway::Method` Ressource muss diesen `RequestTemplates` Code haben (die kursiv gedruckte Zeile ist die aktualisierte Zeile)
```
RequestTemplates:
application/json: |
{
"username": "$util.urlDecode($input.params('username'))",
"password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
"protocol": "$input.params('protocol')",
"serverId": "$input.params('serverId')",
"sourceIp": "$input.params('sourceIp')"
}
```
+ Der Wert `RequestParameters` für die `GetUserConfig` Ressource muss geändert werden, damit der `PasswordBase64` Header verwendet werden kann (die kursiv gedruckte Zeile ist die aktualisierte Zeile):
```
RequestParameters:
method.request.header.PasswordBase64: false
method.request.querystring.protocol: false
method.request.querystring.sourceIp: false
```
**Um zu überprüfen, ob die Vorlage für Ihren Stack die neueste ist**
1. Öffnen Sie die CloudFormation Konsole unter [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Wählen Sie aus der Liste der Stacks Ihren Stack aus.
1. Wählen Sie im Detailbereich die Registerkarte **Vorlage** aus.
1. Achten Sie auf Folgendes:
+ Suchen Sie nach dieser Zeile und stellen Sie sicher`RequestTemplates`, dass Sie sie haben:
```
"password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
```
+ Suchen Sie nach dieser Zeile und stellen Sie sicher`RequestParameters`, dass Sie sie haben:
```
method.request.header.PasswordBase64: false
```
Wenn Sie die aktualisierten Zeilen nicht sehen, bearbeiten Sie Ihren Stapel. Einzelheiten zum Aktualisieren Ihres CloudFormation Stacks finden Sie unter [Ändern einer Stack-Vorlage](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-get-template.html) im *AWS CloudFormation; Benutzerhandbuch*.
# Verwendung mehrerer Authentifizierungsmethoden
Der Transfer Family Family-Server steuert die AND-Logik, wenn Sie mehrere Authentifizierungsmethoden verwenden. Transfer Family behandelt dies als zwei separate Anfragen an Ihren benutzerdefinierten Identitätsanbieter: Ihre Wirkung ist jedoch kombiniert.
Beide Anfragen müssen erfolgreich mit der richtigen Antwort zurückgegeben werden, damit die Authentifizierung abgeschlossen werden kann. Transfer Family setzt voraus, dass die beiden Antworten vollständig sind, d. h. sie enthalten alle erforderlichen Elemente (Rolle, Home-Verzeichnis, Richtlinie und das POSIX-Profil, wenn Sie Amazon EFS als Speicher verwenden). Transfer Family verlangt außerdem, dass die Passwortantwort keine öffentlichen Schlüssel enthalten darf.
Die Anfrage nach einem öffentlichen Schlüssel muss vom Identitätsanbieter separat beantwortet werden. Dieses Verhalten bleibt unverändert, wenn **Password OR Key oder** **Password AND Key** verwendet wird.
Das SSH/SFTP-Protokoll fordert den Software-Client zunächst mit einer Authentifizierung über einen öffentlichen Schlüssel auf und fordert dann eine Passwortauthentifizierung an. Dieser Vorgang setzt voraus, dass beide erfolgreich sind, bevor der Benutzer die Authentifizierung abschließen kann.
Für benutzerdefinierte Identitätsanbieter-Optionen können Sie eine der folgenden Optionen für die Authentifizierung angeben.
+ **Passwort ODER Schlüssel** — Benutzer können sich entweder mit ihrem Passwort oder ihrem Schlüssel authentifizieren. Dies ist der Standardwert.
+ **NUR Passwort** — Benutzer müssen ihr Passwort angeben, um eine Verbindung herzustellen.
+ **NUR Schlüssel** — Benutzer müssen ihren privaten Schlüssel angeben, um eine Verbindung herzustellen.
+ **Passwort UND Schlüssel** — Benutzer müssen sowohl ihren privaten Schlüssel als auch ihr Passwort angeben, um eine Verbindung herzustellen. Der Server überprüft zuerst den Schlüssel, und wenn der Schlüssel gültig ist, fordert das System dann zur Eingabe eines Kennworts auf. Wenn der angegebene private Schlüssel nicht mit dem gespeicherten öffentlichen Schlüssel übereinstimmt, schlägt die Authentifizierung fehl.
# IPv6 Unterstützung für benutzerdefinierte Identitätsanbieter
AWS Transfer Family benutzerdefinierte Identitätsanbieter unterstützen IPv6 Verbindungen vollständig. Bei der Implementierung eines benutzerdefinierten Identitätsanbieters kann Ihre Lambda-Funktion Authentifizierungsanfragen sowohl von als auch von IPv6 Clients ohne zusätzliche Konfiguration empfangen IPv4 und verarbeiten. Die Lambda-Funktion empfängt die IP-Adresse des Clients im `sourceIp` Feld der Anfrage. Dabei kann es sich entweder um eine IPv4 Adresse (zum Beispiel`203.0.113.42`) oder um eine IPv6 Adresse (zum Beispiel`2001:db8:85a3:8d3:1319:8a2e:370:7348`) handeln. Ihre benutzerdefinierte Identitätsanbieter-Implementierung sollte beide Adressformate angemessen handhaben.
**Wichtig**
Wenn Ihr benutzerdefinierter Identitätsanbieter eine IP-basierte Validierung oder Protokollierung durchführt, stellen Sie sicher, dass Ihre Implementierung die IPv6 Adressformate ordnungsgemäß verarbeitet. IPv6 Adressen sind länger als IPv4 Adressen und verwenden ein anderes Notationsformat.
**Anmerkung**
Achten Sie beim Umgang mit IPv6 Adressen in Ihrem benutzerdefinierten Identitätsanbieter darauf, dass Sie die richtigen Funktionen zur IPv6 Adressanalyse verwenden und nicht einfache Zeichenkettenvergleiche. IPv6Adressen können in verschiedenen kanonischen Formaten dargestellt werden (z. B. `fd00:b600::ec2` oder). `fd00:b600:0:0:0:0:0:ec2` Verwenden Sie die entsprechenden IPv6 Adressbibliotheken oder Funktionen in Ihrer Implementierungssprache, um Adressen korrekt zu validieren und zu vergleichen IPv6 .
**Example Behandlung von IPv6 Adressen IPv4 sowohl als auch in einem benutzerdefinierten Identitätsanbieter**
```
def lambda_handler(event, context):
# Extract the source IP address from the request
source_ip = event.get('sourceIp', '')
# Log the client IP address (works for both IPv4 and IPv6)
print(f"Authentication request from: {source_ip}")
# Example of IP-based validation that works with both IPv4 and IPv6
if is_ip_allowed(source_ip):
# Continue with authentication
# ...
else:
# Reject the authentication request
return {
"Role": "",
"HomeDirectory": "",
"Status": "DENIED"
}
```
Weitere Informationen zur Implementierung benutzerdefinierter Identitätsanbieter finden Sie unter[Wird AWS Lambda zur Integration Ihres Identitätsanbieters verwendet](custom-lambda-idp.md).
# Verwenden des AWS Directory Service für Microsoft Active Directory
Sie können AWS Transfer Family es verwenden, um Ihre Dateiübertragung von Endbenutzern mithilfe von AWS Directory Service for Microsoft Active Directory zu authentifizieren. Es ermöglicht eine nahtlose Migration von Dateiübertragungsworkflows, die auf der Active Directory-Authentifizierung basieren, ohne dass die Anmeldeinformationen der Endbenutzer geändert werden oder ein benutzerdefinierter Autorisierer erforderlich ist.
Mit AWS Managed Microsoft AD können Sie Directory Service Benutzern und Gruppen sicheren Zugriff über SFTP, FTPS und FTP auf Daten gewähren, die in Amazon Simple Storage Service (Amazon S3) oder Amazon Elastic File System (Amazon EFS) gespeichert sind. Wenn Sie Active Directory zum Speichern der Anmeldeinformationen Ihrer Benutzer verwenden, haben Sie jetzt eine einfachere Möglichkeit, Dateiübertragungen für diese Benutzer zu aktivieren.
Sie können den Zugriff auf Active Directory-Gruppen AWS Managed Microsoft AD in Ihrer lokalen Umgebung oder in der AWS Cloud mithilfe von Active Directory-Connectors bereitstellen. Sie können Benutzern, die bereits in Ihrer Microsoft Windows-Umgebung konfiguriert sind, entweder in der AWS Cloud oder in ihrem lokalen Netzwerk, Zugriff auf einen AWS Transfer Family Server gewähren, der AWS Managed Microsoft AD für die Identität verwendet wird. Der AWS Speicher-Blog enthält einen Beitrag, in dem eine Lösung für die Verwendung von Active Directory mit Transfer Family beschrieben wird: [Vereinfachen Sie die Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
**Anmerkung**
AWS Transfer Family unterstützt Simple AD nicht.
Transfer Family unterstützt keine regionsübergreifenden Active Directory-Konfigurationen: Wir unterstützen nur Active Directory-Integrationen, die sich in derselben Region wie die des Transfer Family Family-Servers befinden.
Transfer Family unterstützt AWS Managed Microsoft AD weder die Verwendung von AD Connector noch die Verwendung von AD Connector zur Aktivierung der Multi-Faktor-Authentifizierung (MFA) für Ihre bestehende RADIUS-basierte MFA-Infrastruktur.
AWS Transfer Family unterstützt keine replizierten Regionen von Managed Active Directory.
Zur Verwendung AWS Managed Microsoft AD müssen Sie die folgenden Schritte ausführen:
1. Erstellen Sie mit der Directory Service Konsole ein oder mehrere AWS Managed Microsoft AD Verzeichnisse.
1. Verwenden Sie die Transfer Family Family-Konsole, um einen Server zu erstellen, der ihn AWS Managed Microsoft AD als Identitätsanbieter verwendet.
1. Richten Sie AWS Directory mit einem Active Directory Connector ein.
1. Fügen Sie Zugriff von einer oder mehreren Ihrer Directory Service Gruppen aus hinzu.
1. Obwohl dies nicht erforderlich ist, empfehlen wir Ihnen, den Benutzerzugriff zu testen und zu überprüfen.
**Topics**
+ [
## Bevor Sie mit der Verwendung beginnen AWS Directory Service for Microsoft Active Directory
](#managed-ad-prereq)
+ [
## Arbeiten mit Active Directory-Bereichen
](#managed-ad-realms)
+ [
## Wählen Sie AWS Managed Microsoft AD als Ihren Identitätsanbieter
](#managed-ad-identity-provider)
+ [
## Verbindung mit lokalem Microsoft Active Directory herstellen
](#on-prem-ad)
+ [
## Zugriff auf Gruppen gewähren
](#directory-services-grant-access)
+ [
## Benutzer werden getestet
](#directory-services-test-user)
+ [
## Serverzugriff für eine Gruppe wird gelöscht
](#directory-services-misc)
+ [
## Mit SSH (Secure Shell) eine Verbindung zum Server herstellen
](#directory-services-ssh-procedure)
+ [
## Mithilfe von Gesamtstrukturen und Vertrauensstellungen eine Verbindung AWS Transfer Family zu einem selbstverwalteten Active Directory herstellen
](#directory-services-ad-trust)
## Bevor Sie mit der Verwendung beginnen AWS Directory Service for Microsoft Active Directory
**Anmerkung**
AWS Transfer Family hat ein Standardlimit von 100 Active Directory-Gruppen pro Server. Wenn Ihr Anwendungsfall mehr als 100 Gruppen erfordert, sollten Sie die Verwendung einer benutzerdefinierten Identitätsanbieterlösung in Betracht ziehen, wie unter [Vereinfachen der Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
### Geben Sie eine eindeutige Kennung für Ihre AD-Gruppen ein
Bevor Sie es verwenden können AWS Managed Microsoft AD, müssen Sie für jede Gruppe in Ihrem Microsoft AD-Verzeichnis eine eindeutige Kennung angeben. Sie können dazu die Sicherheits-ID (SID) für jede Gruppe verwenden. Die Benutzer der Gruppe, die Sie zuordnen, haben über die aktivierten Protokolle mithilfe von AWS Transfer Family Zugriff auf Ihre Amazon S3- oder Amazon EFS-Ressourcen.
Verwenden Sie den folgenden PowerShell Windows-Befehl, um die SID für eine Gruppe abzurufen, und *YourGroupName* ersetzen Sie sie durch den Namen der Gruppe.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
**Anmerkung**
Wenn Sie AWS Directory Service als Identitätsanbieter verwenden und wenn `userPrincipalName` und unterschiedliche Werte `SamAccountName` haben, AWS Transfer Family akzeptiert der Wert in`SamAccountName`. Transfer Family akzeptiert den in angegebenen Wert nicht`userPrincipalName`.
### Fügen Sie Ihrer Rolle Directory Service Berechtigungen hinzu
Sie benötigen außerdem Directory Service API-Berechtigungen, um sie AWS Directory Service als Ihren Identitätsanbieter verwenden zu können. Die folgenden Berechtigungen sind erforderlich oder werden empfohlen:
+ `ds:DescribeDirectories`ist erforderlich, damit Transfer Family das Verzeichnis nachschlagen kann
+ `ds:AuthorizeApplication`ist erforderlich, um die Autorisierung für Transfer Family hinzuzufügen
+ `ds:UnauthorizeApplication`wird empfohlen, alle provisorisch erstellten Ressourcen zu entfernen, falls bei der Servererstellung etwas schief geht
Fügen Sie diese Berechtigungen der Rolle hinzu, die Sie für die Erstellung Ihrer Transfer Family Family-Server verwenden. Weitere Informationen zu diesen Berechtigungen finden Sie unter [Directory Service API-Berechtigungen: Referenz zu Aktionen, Ressourcen und Bedingungen](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/UsingWithDS_IAM_ResourcePermissions.html).
## Arbeiten mit Active Directory-Bereichen
Wenn Sie überlegen, wie Ihre Active Directory-Benutzer auf AWS Transfer Family Server zugreifen können, sollten Sie den Bereich des Benutzers und den Bereich seiner Gruppe berücksichtigen. Idealerweise sollten die Realm des Benutzers und der Realm seiner Gruppe übereinstimmen. Das heißt, sowohl der Benutzer als auch die Gruppe befinden sich im Standardbereich oder beide befinden sich im vertrauenswürdigen Bereich. Ist dies nicht der Fall, kann der Benutzer nicht von Transfer Family authentifiziert werden.
Sie können den Benutzer testen, um sicherzustellen, dass die Konfiguration korrekt ist. Details hierzu finden Sie unter [Benutzer werden getestet](#directory-services-test-user). Wenn es ein Problem mit dem user/group Bereich gibt, erhalten Sie die Fehlermeldung Kein zugeordneter Zugriff für Benutzergruppen gefunden.
## Wählen Sie AWS Managed Microsoft AD als Ihren Identitätsanbieter
In diesem Abschnitt wird die Verwendung AWS Directory Service for Microsoft Active Directory mit einem Server beschrieben.
**Zur Verwendung AWS Managed Microsoft AD mit Transfer Family**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Directory Service Konsole unter [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).
Verwenden Sie die Directory Service Konsole, um ein oder mehrere verwaltete Verzeichnisse zu konfigurieren. Weitere Informationen finden Sie unter [AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) im *Administratorhandbuch für Directory Service *.
![\[Die Verzeichnisdienst-Konsole mit einer Liste von Verzeichnissen und deren Details.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/directory-services-AD-list.png)
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)und wählen Sie **Server erstellen** aus.
1. **Wählen Sie auf der Seite „Protokolle** auswählen“ ein oder mehrere Protokolle aus der Liste aus.
**Anmerkung**
Wenn Sie **FTPS** auswählen, müssen Sie das AWS Certificate Manager Zertifikat bereitstellen.
1. **Wählen Sie für Wählen Sie einen Identitätsanbieter** die Option **AWS Directory Service** aus.
![\[Konsolen-Screenshot mit dem Abschnitt „Identitätsanbieter auswählen“ mit ausgewähltem Directory Service.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/create-server-choose-idp-directory-services.png)
1. Die **Verzeichnisliste** enthält alle verwalteten Verzeichnisse, die Sie konfiguriert haben. Wählen Sie ein Verzeichnis aus der Liste aus und klicken Sie auf **Weiter**.
**Anmerkung**
Kontoübergreifende Verzeichnisse und gemeinsam genutzte Verzeichnisse werden für AWS Managed Microsoft AD nicht unterstützt.
Um einen Server mit Directory Service als Identitätsanbieter einzurichten, müssen Sie einige Directory Service Berechtigungen hinzufügen. Details hierzu finden Sie unter [Bevor Sie mit der Verwendung beginnen AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Verwenden Sie eines der folgenden Verfahren, um die Erstellung des Servers abzuschließen:
+ [Erstellen Sie einen SFTP-fähigen Server](create-server-sftp.md)
+ [Erstellen Sie einen FTPS-fähigen Server](create-server-ftps.md)
+ [Erstellen Sie einen FTP-fähigen Server](create-server-ftp.md)
Fahren Sie in diesen Verfahren mit dem folgenden Schritt fort: Wählen Sie einen Identitätsanbieter aus.
**Wichtig**
Sie können ein Microsoft AD-Verzeichnis nicht löschen, Directory Service wenn Sie es auf einem Transfer Family Family-Server verwendet haben. Sie müssen zuerst den Server löschen, und dann können Sie das Verzeichnis löschen.
## Verbindung mit lokalem Microsoft Active Directory herstellen
In diesem Abschnitt wird beschrieben, wie Sie ein AWS Verzeichnis mithilfe eines AD Connector einrichten.
**So richten Sie Ihr AWS Verzeichnis mit AD Connector ein**
1. Öffnen Sie die [Directory Service Service-Konsole](https://console.aws.amazon.com/directoryservicev2/) und wählen Sie **Verzeichnisse** aus.
1. Wählen Sie **Verzeichnis einrichten** aus.
1. Wählen Sie als Verzeichnistyp **AD Connector** aus.
1. Wählen Sie eine Verzeichnisgröße, klicken Sie auf **Weiter** und wählen Sie dann Ihre VPC und Subnetze aus.
1. Wählen Sie **Weiter** aus und füllen Sie dann die Felder wie folgt aus:
+ **Verzeichnis-DNS-Name**: Geben Sie den Domainnamen ein, den Sie für Ihr Microsoft Active Directory verwenden.
+ **DNS-IP-Adressen**: Geben Sie Ihre Microsoft Active Directory-IP-Adressen ein.
+ **Benutzername und **Passwort** des Serverkontos**: Geben Sie die Details für das zu verwendende Dienstkonto ein.
1. Füllen Sie die Bildschirme aus, um den Verzeichnisdienst zu erstellen.
Der nächste Schritt besteht darin, einen Transfer Family Family-Server mit dem SFTP-Protokoll und dem Identitätsanbietertyp **AWS Directory Service** zu erstellen. **Wählen Sie in der Dropdownliste Verzeichnis das Verzeichnis aus, das Sie im vorherigen Verfahren hinzugefügt haben.**
## Zugriff auf Gruppen gewähren
Nachdem Sie den Server erstellt haben, müssen Sie auswählen, welche Gruppen im Verzeichnis Zugriff auf das Hoch- und Herunterladen von Dateien über die aktivierten Protokolle haben sollen AWS Transfer Family. Sie tun dies, indem Sie einen *Zugriff* erstellen.
**Anmerkung**
AWS Transfer Family hat ein Standardlimit von 100 Active Directory-Gruppen pro Server. Wenn Ihr Anwendungsfall mehr als 100 Gruppen erfordert, sollten Sie die Verwendung einer benutzerdefinierten Identitätsanbieterlösung in Betracht ziehen, wie unter [Vereinfachen der Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
**Anmerkung**
Benutzer müssen *direkt* zu der Gruppe gehören, der Sie Zugriff gewähren. Nehmen wir beispielsweise an, dass Bob ein Benutzer ist und zu Gruppe A gehört und dass Gruppe A selbst in Gruppe B enthalten ist.
Wenn Sie Zugriff auf Gruppe A gewähren, wird Bob Zugriff gewährt.
Wenn Sie Zugriff auf Gruppe B (und nicht auf Gruppe A) gewähren, hat Bob keinen Zugriff.
**Um einer Gruppe Zugriff zu gewähren**
1. Öffnen Sie die AWS Transfer Family Konsole unter [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Navigieren Sie zu Ihrer Serverdetailseite.
1. Wählen Sie im Abschnitt **Zugriffe** die Option **Zugriff hinzufügen** aus.
1. Geben Sie die SID für das AWS Managed Microsoft AD Verzeichnis ein, auf das Sie Zugriff auf diesen Server haben möchten.
**Anmerkung**
Informationen darüber, wie Sie die SID für Ihre Gruppe finden, finden Sie unter[Bevor Sie mit der Verwendung beginnen AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Wählen Sie für **Access** eine AWS Identity and Access Management (IAM-) Rolle für die Gruppe aus.
1. Wählen Sie im Abschnitt **Richtlinie** eine Richtlinie aus. Die Standardeinstellung ist **Keine**.
1. Wählen Sie für **Home-Verzeichnis** einen Amazon S3 S3-Bucket aus, der dem Home-Verzeichnis der Gruppe entspricht.
**Anmerkung**
Sie können die Teile des Buckets einschränken, die Benutzer sehen, indem Sie eine Sitzungsrichtlinie erstellen. Um beispielsweise Benutzer auf ihren eigenen Ordner im `/filetest` Verzeichnis zu beschränken, geben Sie den folgenden Text in das Feld ein.
```
/filetest/${transfer:UserName}
```
Weitere Informationen zum Erstellen einer Sitzungsrichtlinie finden Sie unter[Sitzungsrichtlinie für einen Amazon S3 S3-Bucket erstellen](users-policies-session.md).
1. Wählen Sie **Hinzufügen**, um die Zuordnung zu erstellen.
1. Wählen Sie Ihren Server aus.
1. Wählen **Sie Zugriff hinzufügen**.
1. Geben Sie die SID für die Gruppe ein.
**Anmerkung**
Informationen darüber, wie Sie die SID finden, finden Sie unter[Bevor Sie mit der Verwendung beginnen AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).
1. Wählen Sie **Zugriff hinzufügen** aus.
Im Bereich **Zugriffe** werden die Zugriffe für den Server aufgelistet.
![\[Konsole, in der der Bereich Zugriffe mit den aufgelisteten Serverzugriffen angezeigt wird.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/accesses-list.png)
## Benutzer werden getestet
Sie können testen, ob ein Benutzer Zugriff auf das AWS Managed Microsoft AD Verzeichnis für Ihren Server hat.
**Anmerkung**
Ein Benutzer muss zu genau einer Gruppe (einer externen ID) gehören, die im Abschnitt **Zugriff auf** der **Endpunktkonfigurationsseite** aufgeführt ist. Wenn der Benutzer keiner Gruppe angehört oder zu mehr als einer einzigen Gruppe gehört, wird diesem Benutzer kein Zugriff gewährt.
**Um zu testen, ob ein bestimmter Benutzer Zugriff hat**
1. Wählen Sie auf der Seite mit den Serverdetails **Aktionen** und dann **Test** aus.
1. Geben Sie zum **Testen des Identitätsanbieters** die Anmeldeinformationen für einen Benutzer ein, der zu einer der Gruppen gehört, die Zugriff haben.
1. Wählen Sie **Test** aus.
Sie sehen einen erfolgreichen Identitätsanbietertest, der zeigt, dass dem ausgewählten Benutzer Zugriff auf den Server gewährt wurde.
![\[Konsolen-Screenshot der erfolgreichen Antwort auf den Identitätsanbieter-Test.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/identity-provider-test-success.png)
Wenn der Benutzer zu mehr als einer Gruppe gehört, die Zugriff hat, erhalten Sie die folgende Antwort.
```
"Response":"",
"StatusCode":200,
"Message":"More than one associated access found for user's groups."
```
## Serverzugriff für eine Gruppe wird gelöscht
**Um den Serverzugriff für eine Gruppe zu löschen**
1. Wählen Sie auf der Seite mit den Serverdetails **Aktionen** und anschließend **Zugriff löschen** aus.
1. Bestätigen Sie im Dialogfeld, dass Sie den Zugriff für diese Gruppe entfernen möchten.
Wenn Sie zur Seite mit den Serverdetails zurückkehren, sehen Sie, dass der Zugriff für diese Gruppe nicht mehr aufgeführt ist.
## Mit SSH (Secure Shell) eine Verbindung zum Server herstellen
Nachdem Sie Ihren Server und Ihre Benutzer konfiguriert haben, können Sie über SSH eine Verbindung zum Server herstellen und den vollqualifizierten Benutzernamen für einen Benutzer verwenden, der Zugriff hat.
```
sftp user@active-directory-domain@vpc-endpoint
```
Beispiel: `transferuserexample@mycompany.com@vpce-0123456abcdef-789xyz.vpc-svc-987654zyxabc.us-east-1.vpce.amazonaws.com`.
Dieses Format zielt auf die Suche im Verbund ab und schränkt die Suche in einem potenziell großen Active Directory ein.
**Anmerkung**
Sie können den einfachen Benutzernamen angeben. In diesem Fall muss der Active Directory-Code jedoch alle Verzeichnisse im Verbund durchsuchen. Dadurch kann die Suche eingeschränkt werden, und die Authentifizierung schlägt möglicherweise fehl, selbst wenn der Benutzer Zugriff haben sollte.
Nach der Authentifizierung befindet sich der Benutzer in dem Basisverzeichnis, das Sie bei der Konfiguration des Benutzers angegeben haben.
## Mithilfe von Gesamtstrukturen und Vertrauensstellungen eine Verbindung AWS Transfer Family zu einem selbstverwalteten Active Directory herstellen
Directory Service bietet die folgenden Optionen, um eine Verbindung zu einem selbstverwalteten Active Directory herzustellen:
+ Die unidirektionale Gesamtvertrauensstellung (ausgehend von AWS Managed Microsoft AD und eingehend für lokales Active Directory) funktioniert nur für die Stammdomäne.
+ Für untergeordnete Domänen können Sie eine der folgenden Optionen verwenden:
+ Verwenden Sie bidirektionale Vertrauensstellung zwischen AWS Managed Microsoft AD und lokalem Active Directory
+ Verwenden Sie für jede untergeordnete Domäne eine unidirektionale externe Vertrauensstellung.
Wenn der Benutzer über eine vertrauenswürdige Domäne eine Verbindung zum Server herstellt, muss er beispielsweise `transferuserexample@mycompany.com` die vertrauenswürdige Domäne angeben.
# Verwenden des AWS Directory Service für Entra ID Domain Services
Für Kunden, die nur SFTP-Transfer benötigen und keine Domain verwalten möchten, gibt es Simple Active Directory. Alternativ können Kunden, die die Vorteile von Active Directory und hoher Verfügbarkeit in einem vollständig verwalteten Dienst nutzen möchten, AWS Managed Microsoft AD verwenden. Und für Kunden, die ihre bestehende Active Directory-Gesamtstruktur für ihre SFTP-Übertragung nutzen möchten, gibt es den Active Directory Connector.
Beachten Sie Folgendes:
+ Um Ihre bestehende Active Directory-Gesamtstruktur für Ihre SFTP-Übertragungsanforderungen zu nutzen, können Sie [Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) verwenden.
+ Wenn Sie die Vorteile von Active Directory und hoher Verfügbarkeit in einem vollständig verwalteten Dienst nutzen möchten, können Sie Folgendes verwenden AWS Directory Service for Microsoft Active Directory. Details hierzu finden Sie unter [Verwenden des AWS Directory Service für Microsoft Active Directory](directory-services-users.md).
In diesem Thema wird beschrieben, wie Sie einen Active Directory-Connector und [Entra ID-Domänendienste (früher Azure AD)](https://azure.microsoft.com/en-us/services/active-directory-ds/) verwenden, um SFTP-Übertragungsbenutzer mit Entra ID zu authentifizieren.
**Topics**
+ [
## Bevor Sie beginnen, AWS Directory Service für Entra ID Domain Services zu verwenden
](#azure-prereq)
+ [
## Schritt 1: Hinzufügen von Entra ID Domain Services
](#azure-add-adds)
+ [
## Schritt 2: Erstellen eines Dienstkontos
](#azure-create-service-acct)
+ [
## Schritt 3: AWS Verzeichnis mit AD Connector einrichten
](#azure-setup-directory)
+ [
## Schritt 4: AWS Transfer Family Server einrichten
](#azure-setup-transfer-server)
+ [
## Schritt 5: Zugriff auf Gruppen gewähren
](#azure-grant-access)
+ [
## Schritt 6: Benutzer testen
](#azure-test)
## Bevor Sie beginnen, AWS Directory Service für Entra ID Domain Services zu verwenden
**Anmerkung**
AWS Transfer Family hat ein Standardlimit von 100 Active Directory-Gruppen pro Server. Wenn Ihr Anwendungsfall mehr als 100 Gruppen erfordert, sollten Sie die Verwendung einer benutzerdefinierten Identitätsanbieterlösung in Betracht ziehen, wie unter [Vereinfachen der Active Directory-Authentifizierung mit einem benutzerdefinierten Identitätsanbieter für](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/) beschrieben AWS Transfer Family.
Für AWS benötigen Sie Folgendes:
+ Eine virtuelle private Cloud (VPC) in einer AWS Region, in der Sie Ihre Transfer Family Family-Server verwenden
+ Mindestens zwei private Subnetze in Ihrer VPC
+ Die VPC muss über eine Internetverbindung verfügen
+ Ein Kunden-Gateway und ein virtuelles privates Gateway für die site-to-site VPN-Verbindung mit Microsoft Entra
Für Microsoft Entra benötigen Sie Folgendes:
+ Eine Entra-ID und ein Active Directory-Domänendienst
+ Eine Entra-Ressourcengruppe
+ Ein virtuelles Entra-Netzwerk
+ VPN-Konnektivität zwischen Ihrer Amazon VPC und Ihrer Entra-Ressourcengruppe
**Anmerkung**
Dies kann über native IPSEC-Tunnel oder mithilfe von VPN-Appliances erfolgen. In diesem Thema verwenden wir IPSEC-Tunnel zwischen einem virtuellen Entra-Netzwerk-Gateway und einem lokalen Netzwerk-Gateway. Die Tunnel müssen so konfiguriert sein, dass sie den Verkehr zwischen Ihren Entra Domain Service-Endpunkten und den Subnetzen, in denen sich Ihre VPC befindet, zulassen. AWS
+ Ein Kunden-Gateway und ein virtuelles privates Gateway für die site-to-site VPN-Verbindung mit Microsoft Entra
Das folgende Diagramm zeigt die Konfiguration, die Sie benötigen, bevor Sie beginnen.
![\[Entra/Azure AD und AWS Transfer Family Architekturdiagramm. Eine AWS VPC, die über das Internet eine Verbindung zu einem virtuellen Entra-Netzwerk herstellt und dabei einen AWS Directory Service Service-Connector zum Entra-Domänendienst verwendet.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-architecture.png)
## Schritt 1: Hinzufügen von Entra ID Domain Services
Entra ID unterstützt standardmäßig keine Domänenbeitritte. Um Aktionen wie den Domänenbeitritt durchzuführen und Tools wie Gruppenrichtlinien zu verwenden, müssen Administratoren die Entra ID Domain Services aktivieren. Wenn Sie Entra DS noch nicht hinzugefügt haben oder Ihre bestehende Implementierung nicht mit der Domain verknüpft ist, die Ihr SFTP-Übertragungsserver verwenden soll, müssen Sie eine neue Instanz hinzufügen.
Informationen zur Aktivierung der Entra ID Domain Services finden Sie unter [Tutorial: Erstellen und Konfigurieren einer verwalteten Microsoft Entra Domain Services-Domain Services-Domain](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started).
**Anmerkung**
Wenn Sie Entra DS aktivieren, stellen Sie sicher, dass es für die Ressourcengruppe und die Entra-Domäne konfiguriert ist, mit der Sie Ihren SFTP-Übertragungsserver verbinden.
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-ad-add-instance.png)
## Schritt 2: Erstellen eines Dienstkontos
Entra muss über ein Dienstkonto verfügen, das Teil einer Admin-Gruppe in Entra DS ist. Dieses Konto wird mit dem AWS Active Directory-Connector verwendet. Stellen Sie sicher, dass dieses Konto mit Entra DS synchronisiert ist.
![\[Entra-Bildschirm mit einem Profil für einen Benutzer.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-service-acct.png)
**Tipp**
Die Multi-Faktor-Authentifizierung für Entra ID wird für Transfer Family Family-Server, die das SFTP-Protokoll verwenden, nicht unterstützt. Der Transfer Family Family-Server kann das MFA-Token nicht bereitstellen, nachdem sich ein Benutzer bei SFTP authentifiziert hat. Stellen Sie sicher, dass MFA deaktiviert ist, bevor Sie versuchen, eine Verbindung herzustellen.
![\[Geben Sie Details zur Multi-Faktor-Authentifizierung ein, aus denen hervorgeht, dass der MFA-Status für zwei Benutzer deaktiviert ist.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-ad-mfa-disable.png)
## Schritt 3: AWS Verzeichnis mit AD Connector einrichten
Nachdem Sie Entra DS konfiguriert und ein Dienstkonto mit IPSEC-VPN-Tunneln zwischen Ihrer AWS VPC und dem Entra Virtual Network erstellt haben, können Sie die Konnektivität testen, indem Sie die Entra DS-DNS-IP-Adresse von einer beliebigen EC2-Instance aus pingen. AWS
Nachdem Sie sich vergewissert haben, dass die Verbindung aktiv ist, können Sie weiter unten fortfahren.
**So richten Sie Ihr AWS Verzeichnis mit AD Connector ein**
1. Öffnen Sie die [Directory Service Service-Konsole](https://console.aws.amazon.com/directoryservicev2/) und wählen Sie **Verzeichnisse** aus.
1. Wählen Sie **Verzeichnis einrichten** aus.
1. Wählen Sie als Verzeichnistyp **AD Connector** aus.
1. Wählen Sie eine Verzeichnisgröße aus, klicken Sie auf **Weiter** und wählen Sie dann Ihre VPC und Subnetze aus.
1. Wählen Sie **Weiter** aus und füllen Sie dann die Felder wie folgt aus:
+ **DNS-Name des Verzeichnisses**: Geben Sie den Domainnamen ein, den Sie für Ihren Entra DS verwenden.
+ **DNS-IP-Adressen**: Geben Sie Ihre Entra DS-IP-Adressen ein.
+ **Benutzername und **Passwort** für das Serverkonto**: Geben Sie die Details für das Dienstkonto *ein, das Sie in Schritt 2: Dienstkonto erstellen* erstellt haben.
1. Füllen Sie die Bildschirme aus, um den Verzeichnisdienst zu erstellen.
Jetzt sollte der Verzeichnisstatus **Aktiv** lauten und es kann mit einem SFTP-Übertragungsserver verwendet werden.
![\[Auf dem Bildschirm mit den Verzeichnisdiensten wird je nach Bedarf ein Verzeichnis mit dem Status Aktiv angezeigt.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-connector-ready.png)
## Schritt 4: AWS Transfer Family Server einrichten
Erstellen Sie einen Transfer Family Family-Server mit dem SFTP-Protokoll und dem Identitätsanbietertyp **AWS Directory Service**. **Wählen Sie aus der Dropdownliste Verzeichnis das Verzeichnis aus, das Sie in *Schritt 3: AWS Verzeichnis mit AD Connector einrichten* hinzugefügt haben.**
**Anmerkung**
Sie können ein Microsoft AD-Verzeichnis nicht im AWS Directory Service löschen, wenn Sie es auf einem Transfer Family Family-Server verwendet haben. Sie müssen zuerst den Server löschen, und dann können Sie das Verzeichnis löschen.
## Schritt 5: Zugriff auf Gruppen gewähren
Nachdem Sie den Server erstellt haben, müssen Sie auswählen, welche Gruppen im Verzeichnis Zugriff auf das Hoch- und Herunterladen von Dateien über die aktivierten Protokolle haben sollen AWS Transfer Family. Dazu erstellen Sie einen *Zugriff*.
**Anmerkung**
Benutzer müssen *direkt* zu der Gruppe gehören, der Sie Zugriff gewähren. Nehmen wir beispielsweise an, dass Bob ein Benutzer ist und zu Gruppe A gehört und dass Gruppe A selbst in Gruppe B enthalten ist.
Wenn Sie Zugriff auf Gruppe A gewähren, wird Bob Zugriff gewährt.
Wenn Sie Zugriff auf Gruppe B (und nicht auf Gruppe A) gewähren, hat Bob keinen Zugriff.
Um Zugriff zu gewähren, müssen Sie die SID für die Gruppe abrufen.
Verwenden Sie den folgenden PowerShell Windows-Befehl, um die SID für eine Gruppe abzurufen, und *YourGroupName* ersetzen Sie sie durch den Namen der Gruppe.
```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```
![\[Windows PowerShell zeigt eine Objekt-SID an, die abgerufen wird.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-grant-access.png)
**Gewähren Sie Gruppen Zugriff**
1. Öffnen Sie [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).
1. Navigieren Sie zu Ihrer Serverdetailseite und wählen Sie im Bereich **Zugriffe** die Option **Zugriff hinzufügen** aus.
1. Geben Sie die SID ein, die Sie aus der Ausgabe des vorherigen Verfahrens erhalten haben.
1. Wählen Sie für **Access** eine AWS Identity and Access Management Rolle für die Gruppe aus.
1. Wählen Sie im Abschnitt **Richtlinie** eine Richtlinie aus. Der Standardwert ist **None (Kein)**.
1. Wählen Sie für **Home-Verzeichnis** einen Amazon S3 S3-Bucket aus, der dem Home-Verzeichnis der Gruppe entspricht.
1. Wählen Sie **Hinzufügen**, um die Zuordnung zu erstellen.
Die Details von Ihrem Transferserver sollten etwa wie folgt aussehen:
![\[Ein Teil des Detailbildschirms mit den Transfer Family Family-Servern, der ein Beispiel für eine Verzeichnis-ID für den Identity Provider zeigt.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-assoc-1.png)
![\[Ein Teil des Detailbildschirms mit den Transfer Family Family-Servern, in dem die externe ID des Active Directory im Bereich Zugriffe angezeigt wird.\]](http://docs.aws.amazon.com/de_de/transfer/latest/userguide/images/azure-assoc-2.png)
## Schritt 6: Benutzer testen
Sie können testen ([Benutzer werden getestet](directory-services-users.md#directory-services-test-user)), ob ein Benutzer Zugriff auf das AWS Managed Microsoft AD Verzeichnis für Ihren Server hat. Ein Benutzer muss zu genau einer Gruppe gehören (eine externe ID), die im Abschnitt **Zugriff auf** der **Endpunktkonfigurationsseite** aufgeführt ist. Wenn der Benutzer keiner oder mehreren Gruppen angehört, wird diesem Benutzer kein Zugriff gewährt.