Problembehebung bei Active Directory

Die folgenden Probleme können auftreten, wenn Sie Active Directory mit Amazon AppStream 2.0 einrichten und verwenden. Weitere Hilfe zu Benachrichtigungscodes bei der Fehlerbehebung finden Sie unter Benachrichtigungscodes für die Fehlerbehebung.

Meine Image Builder und Flotteninstanzen stecken im PENDING Status fest.

Es kann bis zu 25 Minuten dauern, bis Image-Builder- und Flotte-Instances in einen betriebsbereiten Status übergehen und verfügbar sind. Wenn es länger als 25 Minuten dauert, bis Ihre Instanzen verfügbar sind, überprüfen Sie in Active Directory, ob neue Computerobjekte in den richtigen Organisationseinheiten erstellt wurden (OUs). Wenn neue Objekte vorhanden sind, stehen die Streaming-Instances demnächst zur Verfügung. Wenn die Objekte nicht vorhanden sind, überprüfen Sie die Verzeichniskonfigurationsdetails in Ihrer AppStream 2.0-Verzeichniskonfiguration: Verzeichnisname (der vollqualifizierte Domänenname des Verzeichnisses), die Anmeldeinformationen für das Dienstkonto und der definierte Name der Organisationseinheit.

Image Builder- und Flottenfehler werden in der AppStream 2.0-Konsole auf der Registerkarte Benachrichtigungen für die Flotte oder den Image Builder angezeigt. Flottenfehler sind auch bei Verwendung der AppStream Version 2.0 API über die DescribeFleetsOperation oder den CLI Befehl describe-fleets verfügbar.

Meine Benutzer können sich nicht mit der Anwendung anmelden. SAML

AppStream 2.0 verwendet das SAML _Subject-Attribut „NameID“ Ihres Identitätsanbieters, um das Feld für den Benutzernamen auszufüllen, mit dem Sie Ihren Benutzer anmelden können. Der Benutzername kann entweder als „domain\username“ oder „[e-mail]“ formatiert sein. Wenn Sie das Format "domain\username" verwenden, domain kann dies entweder der BIOS Netzname oder der vollqualifizierte Domainname sein. Wenn Sie das Format [e-mail] "" verwenden, kann das UserPrincipalName Attribut verwendet werden. Wenn Sie überprüft haben, dass Ihr SAML _Subject-Attribut korrekt konfiguriert ist und das Problem weiterhin besteht, wenden Sie sich an. AWS Support Weitere Informationen finden Sie unter AWS Support Center.

Meine Flotten-Instances funktionieren für einen Benutzer, aber das Auswechseln wird nicht richtig ausgeführt.

Flotten-Instances werden gewechselt, nachdem ein Benutzer eine Sitzung abgeschlossen hat, um sicherzustellen, dass jeder Benutzer eine neue Instance erhält. Wenn die ausgewechselte Flotten-Instance online geht, tritt sie der Domäne unter Verwendung des Computernamens der vorherigen Instance bei. Um sicherzustellen, dass diese Operation erfolgreich ist, benötigt das Service-Konto die Berechtigungen Passwort ändern und Passwort zurücksetzen für die Organisationseinheit (OU), der das Computerobjekt beitritt. Überprüfen Sie die Berechtigungen für das Service-Konto und versuchen Sie es erneut. Wenn das Problem weiterhin besteht, wenden Sie sich an. AWS Support Weitere Informationen finden Sie unter AWS Support Center.

Meine Benutzer-Gruppenrichtlinienobjekte werden nicht erfolgreich angewendet.

Standardmäßig gelten für Computerobjekte Richtlinien auf Computerebene basierend auf der OU, in der sich das Computerobjekt befindet, während Richtlinien auf Benutzerebene basierend auf der OU angewendet werden, in der sich der Benutzer befindet. Wenn Ihre Benutzerebenenrichtlinien nicht angewendet werden, können Sie einen der folgenden Schritte ausführen:

• Verschieben Sie die Benutzerebenenrichtlinien in die OU, in der sich das Active Directory-Objekt des Benutzers befindet

• Aktivieren Sie die Loopback-Verarbeitung der Computerebene, die die Richtlinien auf Benutzerebene in der OU des Computerobjekts anwendet.

Weitere Informationen finden Sie unter Loopback-Verarbeitung von Gruppenrichtlinien beim Microsoft Support.

Meine AppStream 2.0-Streaming-Instances treten der Active Directory-Domäne nicht bei.

Die Active Directory-Domäne, die mit AppStream 2.0 verwendet werden soll, muss über ihren vollqualifizierten Domänennamen (FQDN) zugänglich sein, über den VPC Ihre Streaming-Instances gestartet werden.

Wie Sie testen, ob ein Zugriff auf Ihre Domäne möglich ist

1. Starten Sie eine EC2 Amazon-Instance in demselben VPC Subnetz und denselben Sicherheitsgruppen, die Sie mit AppStream 2.0 verwenden.

2. Fügen Sie die EC2 Instance manuell Ihrer Active Directory-Domäne hinzu, indem Sie FQDN (z. B.yourdomain.example.com) das Dienstkonto verwenden, das Sie mit AppStream 2.0 verwenden möchten. Verwenden Sie den folgenden Befehl in einer PowerShell Windows-Konsole:

   netdom join computer /domain:FQDN /OU:path /ud:user /pd:password

   Wenn diese manuelle Verbindung fehlschlägt, fahren Sie mit dem nächsten Schritt fort.

3. Wenn Sie Ihrer Domäne nicht manuell beitreten können, öffnen Sie eine Befehlszeile und überprüfen Sie, ob Sie das Problem FQDN mithilfe des nslookup Befehls lösen können. Beispielsweise:

   nslookup yourdomain.exampleco.com

   Die erfolgreiche Namensauflösung gibt eine gültige IP-Adresse zurück. Wenn Sie Ihr Problem nicht lösen könnenFQDN, müssen Sie möglicherweise Ihre VPC DNS Server aktualisieren, indem Sie einen DHCP Optionssatz für Ihre Domain verwenden. Anschließend kehren Sie zu diesem Schritt zurück. Weitere Informationen finden Sie unter DHCPOptionssätze im VPCAmazon-Benutzerhandbuch.

4. Wenn das FQDN Problem behoben ist, verwenden Sie den telnet Befehl, um die Konnektivität zu überprüfen.

   telnet yourdomain.exampleco.com 389

   Bei einer erfolgreichen Verbindung wird eine leere Eingabeaufforderung ohne Verbindungsfehler angezeigt. Möglicherweise müssen Sie die Telnet-Client-Funktion auf Ihrer EC2 Instanz installieren. Weitere Informationen finden Sie unter Install Telnet Client in der Microsoft-Dokumentation.

Wenn Sie die EC2 Instanz nicht manuell zu Ihrer Domäne hinzufügen konnten, die Verbindung mit dem Telnet-Client aber erfolgreich gelöst FQDN und getestet haben, verhindern Ihre VPC Sicherheitsgruppen möglicherweise den Zugriff. Für Active Directory sind bestimmte Netzwerk-Port-Einstellungen erforderlich. Weitere Informationen finden Sie unter Service-Port-Anforderungen von Active Directory und Active Directory Domain in der Microsoft-Dokumentation.

Bei der Benutzeranmeldung dauert es sehr lang, eine mit einer Domäne verbundene Streaming-Sitzung abzuschließen.

AppStream 2.0 führt eine Windows-Anmeldeaktion durch, nachdem Benutzer ihr Domänenkennwort eingegeben haben. Nach erfolgreicher Authentifizierung startet AppStream 2.0 die Anwendung. Die Anmelde- und Startzeiten werden von vielen Variablen beeinflusst, z. B. Netzwerkkonflikten bei den Domänencontrollern oder der Zeit, wie lange es dauert, Gruppenrichtlinieneinstellungen auf die Streaming-Instance anzuwenden. Wenn Domänenauthentifizierung zu lange dauert, versuchen Sie es mit folgenden Aktionen:

• Minimieren Sie die Netzwerklatenz von Ihrer AppStream 2.0-Region zu Ihren Domänencontrollern, indem Sie die richtigen Domänencontroller auswählen. Wenn sich beispielsweise Ihre Flotte in us-east-1 befindet, verwenden Sie Domänencontroller mit hoher Bandbreite und geringer Latenz zu us-east-1 unter Verwendung von Zonenzuordnungen von Active Directory-Standorten und -Diensten. Weitere Informationen finden Sie unter Active Directory-Standorte und -Services in der Microsoft-Dokumentation.

• Stellen Sie sicher, dass Ihre Gruppenrichtlinieneinstellungen und Benutzer-Anmeldeskripts nicht übermäßig lang für die Anwendung oder Ausführung benötigen.

Wenn die Anmeldung Ihrer Domänenbenutzer bei AppStream 2.0 mit der Meldung „Ein unbekannter Fehler ist aufgetreten“ fehlschlägt, müssen Sie möglicherweise die unter beschriebenen Gruppenrichtlinieneinstellungen aktualisierenBevor Sie beginnen, Active Directory mit AppStream 2.0 zu verwenden. Andernfalls verhindern diese Einstellungen möglicherweise, dass AppStream 2.0 Ihre Domänenbenutzer authentifiziert und anmeldet.

Meine Benutzer können nicht auf eine Domänenressource in einer Streaming-Sitzung mit angeschlossener Domäne zugreifen, haben jedoch Zugriff auf die Ressource über einen an die Domäne angeschlossenen Image Builder.

Vergewissern Sie sichVPC, dass Ihre Flotte in denselben Subnetzen und Sicherheitsgruppen wie Ihr Image Builder erstellt wurde und dass Ihr Benutzer über die erforderlichen Berechtigungen verfügt, um auf die Domänenressource zuzugreifen und sie zu verwenden.

Meine Benutzer erhalten die Fehlermeldung „Zertifikatsbasierte Authentifizierung nicht verfügbar“ und werden aufgefordert, ihr Domain-Kennwort einzugeben. Oder Benutzer erhalten die Fehlermeldung „Sitzung wurde getrennt“, wenn sie eine Sitzung starten, die mit zertifikatsbasierter Authentifizierung aktiviert ist.

Diese Fehler treten auf, wenn die zertifikatsbasierte Authentifizierung für die Sitzung fehlgeschlagen ist. Die Fehlermeldung „Zertifikatsbasierte Authentifizierung nicht verfügbar“ wird angezeigt, wenn die zertifikatsbasierte Authentifizierung aktiviert ist, um einen Rückgriff auf die Passwortanmeldung zu ermöglichen. Die Fehlermeldung „Sitzung wurde getrennt“ wird angezeigt, wenn die zertifikatsbasierte Authentifizierung ohne Fallback aktiviert ist.

Die Benutzer können die Seite auf dem Web-Client aktualisieren oder die Verbindung über den Client für Windows erneut herstellen, da es sich hierbei um ein zeitweiliges Problem mit der zertifikatsbasierten Authentifizierung handeln kann. Wenn das Problem weiterhin besteht, kann der Fehler bei der zertifikatsbasierten Authentifizierung auf eines der folgenden Probleme zurückzuführen sein:

• AppStream 2.0 konnte nicht mit AWS Private CA kommunizieren, oder AWS Private CA hat das Zertifikat nicht ausgestellt. Prüfen CloudTrail Sie, ob ein Zertifikat ausgestellt wurde. Weitere Informationen finden Sie unter Was ist AWS CloudTrail? undVerwalten der zertifikatsbasierten Authentifizierung.

• Der Domain-Controller hat kein Domain-Controllerzertifikat für die Smartcard-Anmeldung oder es ist abgelaufen. Weitere Informationen finden Sie in Schritt 7.a unter Voraussetzungen.

• Das Zertifikat ist nicht vertrauenswürdig. Weitere Informationen finden Sie in Schritt 7.c unter Voraussetzungen.

• Das userPrincipalName Format für die SAML _Subject NameID ist nicht richtig formatiert oder wird nicht in die tatsächliche Domäne für den Benutzer aufgelöst. Weitere Informationen finden Sie in Schritt 1 unter Voraussetzungen.

• Das (optionale) ObjectSid Attribut in Ihrer SAML Assertion entspricht nicht der Active Directory-Sicherheitskennung (SID) für den Benutzer, der in der SAML _Subject NameID angegeben ist. Vergewissern Sie sich, dass die Attributzuordnung in Ihrem SAML Verbund korrekt ist und dass Ihr SAML Identitätsanbieter das SID Attribut für den Active Directory-Benutzer synchronisiert.

• Der AppStream 2.0-Agent unterstützt keine zertifikatsbasierte Authentifizierung. Verwenden Sie AppStream 2.0 Agent Version 10-13-2022 oder höher.

• Es gibt Gruppenrichtlinieneinstellungen, die die Standardeinstellungen von Active Directory für die Smartcard-Anmeldung ändern oder Maßnahmen ergreifen, wenn eine Smartcard aus einem Smartcard-Lesegerät entfernt wird. Diese Einstellungen können neben den oben aufgeführten Fehlern noch weitere unerwartete Verhaltensweisen verursachen. Bei der zertifikatsbasierten Authentifizierung wird dem Betriebssystem der Instance eine virtuelle Smartcard vorgelegt, die nach der Anmeldung wieder entfernt wird. Weitere Informationen finden Sie unter Primary Group Policy settings for smart cards und Additional smart card Group Policy settings and registry keys. Aktivieren Sie die Smartcard-Anmeldung für Active Directory nicht in Ihrem Stack, wenn Sie die zertifikatsbasierte Authentifizierung verwenden möchten. Weitere Informationen finden Sie unter Smartcards.

• Der CRL Verteilungspunkt für die private CA ist weder online noch von der AppStream 2.0-Flotteninstanz noch vom Domänencontroller aus zugänglich. Weitere Informationen finden Sie in Schritt 5 unter Voraussetzungen.

Zu den weiteren Schritten zur Problembehandlung gehört die Überprüfung der Windows-Ereignisprotokolle der AppStream 2.0-Instanz. Ein häufiges Ereignis, das Sie auf Anmeldefehler überprüfen sollten, ist 4625(F): An account failed to log on. Weitere Informationen zum Erfassen von Protokollinformationen finden Sie unter Dauerhafte Anwendungs- und Windows-Ereignisprotokolle. Alternativ können Sie zur Problembehandlung einer aktiven AppStream 2.0-Sitzung als Administrator eine Verbindung zu den Protokollen herstellen, indem Sie eine Ereignisanzeige auf einem anderen Computer verwenden. Weitere Informationen finden Sie unter How to Select Computers in Event Viewer. Sie können auch eine Verbindung herstellen, indem Sie Remote Desktop verwenden, um von einem anderen Computer aus, der eine Verbindung zu den Remotedesktopdiensten in Ihrer AppStream virtuellen privaten Cloud 2.0 (VPC) herstellen kann, eine Verbindung zur privaten IP-Adresse der Instanz herzustellen. Verwenden Sie die AWS CLI, um die IP-Adresse für die Sitzung anhand der AWS Region, des AppStream 2.0-Stacknamens, des Flottennamens, der Benutzer-ID und des Authentifizierungstyps zu ermitteln. Weitere Informationen finden Sie in der AWS Command Line Interface.

Wenn das Problem weiterhin besteht, wenden Sie sich an AWS Support. Weitere Informationen finden Sie unter AWS Support -Center.

Nach der Änderung des Active Directory-Dienstkontos (AD) treten beim Domänenbeitritt Fehler auf.

Wenn Sie über eine bestehende Flotte mit einem Image verfügen, das auf dem Microsoft Windows Server-Betriebssystemupdate vom August 2024 basiert, und wenn Sie Ihr Active Directory-Dienstkonto (AD) für diese Flotte ändern, können Ihre Flotteninstanzen bei der Bereitstellung auf Fehler beim Domänenbeitritt stoßen.

Microsoft hat einen Patch KB5020276 veröffentlicht, der das Verhalten von Domänenbeitrittsvorgängen ändert. AppStream 2.0 verwendet beim Verbinden Ihrer Streaming-Instanzen mit Ihren AD-Domänen vorhandene Computerobjekte wieder. Dieses Computerobjekt wird mithilfe des AD-Dienstkontos generiert, das Sie angeben, wenn Sie eine Flotte oder Verzeichniskonfiguration mit AppStream 2.0 erstellen. Vor diesem Microsoft-Patch konnten neue AD-Dienstkonten vorhandene Computerobjekte, die mit AppStream 2.0 erstellt wurden, wiederverwenden, sofern sie über die in der Organisationseinheit (OU) konfigurierten Berechtigungen zum Erstellen von Computerobjekten verfügten.

Wenn der Microsoft-Patch ab dem 13. August 2024 durchgesetzt wird und Sie Ihr AD-Dienstkonto für eine bestehende AppStream 2.0-Flotte ändern, kann das neue Dienstkonto die vorhandenen Computerobjekte im AD nicht mehr wiederverwenden. Dies führt zu Fehlern beim Domänenbeitritt auf AppStream 2.0-Flotten mit einer der folgenden Fehlermeldungen unter Flottenbenachrichtigungen:

• DOMAIN_ JOIN _ INTERNAL _ SERVICE _ ERROR „Der Gruppenname konnte nicht gefunden werden.“

• Ein Konto mit demselben Namen ist in Active Directory vorhanden. Die Wiederverwendung des Kontos wurde durch die Sicherheitsrichtlinie blockiert

Um zu steuern, welches Konto die vorhandenen Computerobjekte wiederverwenden kann, hat Microsoft eine neue Gruppenrichtlinieneinstellung namens Domänencontroller implementiert: Wiederverwendung von Computerkonten während des Domänenbeitritts zulassen. Mit dieser Einstellung können Sie eine Liste vertrauenswürdiger Dienstkonten angeben, die die Überprüfung beim Domänenbeitritt umgehen. Für Ihre selbstverwaltete AD-Konfiguration empfehlen wir, die von Microsoft dokumentierten Schritte zu befolgen, um Ihr AD-Dienstkonto mithilfe von Gruppenrichtlinien auf einem Domänencontroller zur neuen Zulassungslistenrichtlinie hinzuzufügen.

Für Managed Active Directory (MAD) müssen Sie Ihre AppStream 2.0-Flotte neu starten, nachdem Sie Änderungen an Ihrem AppStream 2.0-Domänenbeitrittsdienstkonto vorgenommen haben.

Wenn das Problem weiterhin besteht, wenden Sie sich an AWS Support. Weitere Informationen finden Sie unter AWS Support -Center.