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. # Fehler beim Domänenbeitritt der Amazon EC2 EC2-Linux-Instance Im Folgenden können Sie einige Fehlermeldungen beheben, die beim Hinzufügen einer Amazon EC2 EC2-Linux-Instance zu Ihrem AWS Managed Microsoft AD-Verzeichnis auftreten können. ## Linux-Instances können nicht in die Domain eingebunden oder authentifiziert werden Ubuntu 14.04-, 16.04- und 18.04-Instanzen *müssen* im DNS rückwärts auflösbar sein, bevor ein Bereich mit Microsoft Active Directory funktionieren kann. Andernfalls könnte eines der beiden folgenden Szenarien eintreten: ### Szenario 1: Ubuntu-Instances, die noch keinem Bereich beigetreten sind Für Ubuntu-Instances, die versuchen, einem Bereich beizutreten, könnte der `sudo realm join`-Befehl nicht die erforderlichen Berechtigungen für die Verbindung mit der Domain liefern und den folgenden Fehler ausgeben: \$1 Authentifizierung bei Active Directory ist fehlgeschlagen: SASL(-1): allgemeiner Fehler: GSSAPI-Fehler: Es wurde ein ungültiger Name angegeben (Erfolg) adcli: konnte keine Verbindung zur Domain EXAMPLE.COM herstellen: Authentifizierung bei Active Directory ist fehlgeschlagen: SASL(-1): allgemeiner Fehler: GSSAPI-Fehler: Es wurde ein ungültiger Name angegeben (Success) \$1 Unzureichende Berechtigungen, um den Domainbereich zu verbinden: Der Bereich konnte nicht verbunden werden: Unzureichende Berechtigungen, um die Domain zu verbinden ### Szenario 2: Ubuntu-Instances, die einem Bereich beigetreten sind Bei Ubuntu-Instanzen, die bereits mit einer Microsoft Active Directory-Domäne verknüpft sind, schlagen Versuche, mithilfe der Domänenanmeldedaten per SSH auf die Instanz zuzugreifen, möglicherweise mit folgenden Fehlern fehl: \$1 ssh admin@EXAMPLE.COM@198.51.100 keine solche Identität:/Users/username/.ssh/id\$1ed25519: Keine solche Datei oder kein solches Verzeichnis admin@EXAMPLE.COM@198.51.100's password: Permission denied, please try again. admin@EXAMPLE.COM@198.51.100's password: Wenn Sie sich mit einem öffentlichen Schlüssel bei der Instance anmelden und `/var/log/auth.log` prüfen, werden möglicherweise die folgenden Fehlermeldungen in Bezug auf den nicht gefundenen Benutzer angezeigt: May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 user=admin@EXAMPLE.COM May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): received for user admin@EXAMPLE.COM: 10 (User not known to the underlying authentication module) May 12 01:02:14 ip-192-0-2-0 sshd[2251]: Failed password for invalid user admin@EXAMPLE.COM from 203.0.113.0 port 13344 ssh2 May 12 01:02:15 ip-192-0-2-0 sshd[2251]: Connection closed by 203.0.113.0 [preauth] `kinit` funktioniert für den Benutzer jedoch. Hier ein Beispiel: ubuntu@ip-192-0-2-0:\$1\$1 kinit admin@EXAMPLE.COM Password for admin@EXAMPLE.COM: ubuntu@ip-192-0-2-0:\$1\$1 klist Ticket cache: FILE:/tmp/krb5cc\$11000 Default principal: admin@EXAMPLE.COM ### Workaround Der aktuell empfohlene Workaround für beide dieser Szenarien ist, wie nachstehend beschrieben, die Deaktivierung von Reverse DNS in `/etc/krb5.conf` im Abschnitt [libdefaults]: ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` ## Probleme bei der einseitigen Vertrauensauthentifizierung mit nahtloser Domainverbindung Wenn Sie eine unidirektionale ausgehende Vertrauensstellung zwischen Ihrem AWS verwalteten Microsoft AD und Ihrem lokalen Active Directory eingerichtet haben, tritt möglicherweise ein Authentifizierungsproblem auf, wenn Sie versuchen, sich mit Ihren vertrauenswürdigen Active Directory-Anmeldeinformationen mit Winbind für die zur Domäne gehörende Linux-Instanz zu authentifizieren. ### Fehler 31. Juli 00:00:00 EC2 AMAZ- LSMWq T sshd [23832]: Fehlgeschlagenes Passwort für user@corp.example.com von xxx.xxx.xxx.xxx Port 18309 ssh2 31. Juli 00:05:00 EC2 AMAZ- T sshd [23832]: pam\$1winbind (sshd:auth): Passwort abrufen (0x00000390) LSMWq 31. Juli EC2 00:05:00 AMAZ- T sshd [23832]: pam\$1winbind (sshd:auth): pam\$1get\$1item hat ein Passwort zurückgegeben LSMWq 31. Juli 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd:auth): Anfrage wbcLogonUser fehlgeschlagen: WBC\$1ERR\$1AUTH\$1ERROR, PAM-Fehler: PAM\$1SYSTEM\$1ERR (4), NTSTATUS: \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, Fehlermeldung lautete: Der Objektname wurde nicht gefunden. 31. Juli 00:05:00 EC2 AMAZ- LSMWq T sshd [23832]: pam\$1winbind (sshd:auth): interner Modulfehler (retval = PAM\$1SYSTEM\$1ERR (4), user = 'CORP\$1 user') ## Workaround Um dieses Problem zu beheben, müssen Sie eine Anweisung in der Konfigurationsdatei des PAM-Moduls auskommentieren oder entfernen (`/etc/security/pam_winbind.conf`). Gehen Sie dazu wie folgt vor. 1. Öffnen Sie die Datei `/etc/security/pam_winbind.conf` in einem Text-Editor. ``` sudo vim /etc/security/pam_winbind.conf ``` 1. Kommentieren Sie die folgende Anweisung aus oder entfernen Sie sie: **krb5\$1auth = yes**. ``` [global] cached_login = yes krb5_ccache_type = FILE #krb5_auth = yes ``` 1. Stoppen Sie den Winbind-Service und starten Sie ihn dann erneut. ``` service winbind stop or systemctl stop winbind net cache flush service winbind start or systemctl start winbind ```