PowerScale OneFS: Der Active Directory-Anbieter ist nach dem Beitrittsversuch für dieselbe Domain verschwunden

Nach der Durchführung eines AD-Beitritts mit demselben Namen eines AD-Anbieters, mit dem der Cluster bereits verbunden ist, geht der Anbieter möglicherweise verloren. Administratoren sehen möglicherweise einen Fehler im Zusammenhang mit dem Beitrittsversuch, der jedoch je nach Ursache variieren kann.

Im folgenden Beispiel reproduzieren wir das Problem mit dem Anbieter TESTDOMAIN.LOCAL indem Sie das falsche Konto verwenden, um den Beitritt zu erleichtern.

Ausgaben von isi auth status und isi auth ads list -v Zeigen Sie, dass der Anbieter vorhanden ist, bevor Sie den Befehl ausführen:

corebuddy-1# isi auth status
ID                                            Active Server                Status
----------------------------------------------------------------------------------
lsa-activedirectory-provider:TESTDOMAIN.LOCAL winserv2019.testdomain.local online
lsa-activedirectory-provider:DOMAIN2.LOCAL    domain2DC1.domain2.local     online
lsa-local-provider:System                     -                            active
lsa-local-provider:test                       -                            active
lsa-local-provider:domain2                    -                            active
lsa-file-provider:System                      -                            active
----------------------------------------------------------------------------------
Total: 6

corebuddy-1# isi auth ads list -v | grep -i testdomain
                     Name: TESTDOMAIN.LOCAL
           Primary Domain: TESTDOMAIN.LOCAL
                   Forest: testdomain.local
           NetBIOS Domain: TESTDOMAIN
                 Hostname: corebuddy.testdomain.local

Unten führen wir den Befehl aus. Beachten Sie, dass der falsche Nutzername aufgeführt ist (in unserem Beispiel haben wir den Gruppennamen für "Administratoren" anstelle des Administratorkontos verwendet):

corebuddy-1# isi auth ads create --name=TESTDOMAIN.LOCAL --user=administrators
password:
Failed to join domain 'TESTDOMAIN.LOCAL' account 'corebuddy' user 'administrators@TESTDOMAIN.LOCAL': (LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN) Client not found in Kerberos database

Jetzt fehlt der Anbieter. In der WebUI wird dies möglicherweise als nicht formatiert angezeigt, aber in der CLI ist es nicht in der Ausgabe für isi auth status.

orebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Da der isi auth status anzeigen kann, dass ein Anbieter aus anderen Gründen fehlt, müssen wir dies weiter validieren. Der Befehl isi auth ads list -v Es wird keine Ausgabe angezeigt, die dem Anbieter entspricht TESTDOMAIN.LOCAL unten. Das bedeutet, dass die Konfiguration keine Einträge enthält, die der fehlenden Domain entsprechen.

corebuddy-1# isi auth ads list -v |grep -i test
corebuddy-1#

LSASS-Protokolle zeigen ähnliche Fehler an, die beim Ausführen des anfänglichen Befehls beobachtet wurden:

2024-06-11T21:25:21.298318+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [LwKrb5GetTgtImpl /b/mnt/src/isilon/fsp/lwadvapi/threaded/krbtgt.c:247] KRB5 Error code: -1765328378 (Message: Client 'administrators@TESTDOMAIN.LOCAL' not found in Kerberos database)
2024-06-11T21:25:21.299207+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [lsass] Error occurred while joining domain: Error code: 41737 (symbol: LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN)

Das obige Szenario ist nicht auf die Verwendung falscher Zugangsdaten beschränkt. Wenn eine Bedingung vorliegt, die zu einem Fehler beim Beitritt zum AD-Anbieter führen würde, führt der Fehler dazu, dass der Anbieter gelöscht wird. Wenn z. B. derselbe Name für das Computerkonto an anderer Stelle in der Gesamtstruktur oder in einer vertrauenswürdigen Domäne verwendet wird, führt dies zu einem Fehler. Der einzige Unterschied kann der Fehler sein, der bereitgestellt wird.

Beim Durchführen eines AD-Beitritts für eine bereits hinzugefügte Domain führt das Vorhandensein von Bedingungen, die zu einem Ausfall führen würden, dazu, dass der AD-Anbieter gelöscht wird. Dies ist beabsichtigt, da OneFS dies als erneuten Beitrittsversuch behandeln würde. Wenn der Fehler auftritt, werden alle zugehörigen Konfigurationen zu diesem angegebenen Authentifizierungsanbieter gelöscht.

corebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Namen von Authentifizierungsanbietern sind global, sodass zwei Anbieter mit demselben Namen nicht unterstützt werden. Wenn keine anderen ausstehenden Bedingungen vorliegen, die einen Beitrittsvorgang verhindern würden, wird das Problem durch den erneuten Beitritt zur Domain behoben.

Wenn es erforderlich ist, demselben AD-Domainanbieter mit separaten Maschinenkonten beizutreten, sollte die Multi-Instanziierungsfunktion verwendet werden. Dies wird im Abschnitt "Zonenspezifische Authentifizierungsanbieter" in den OneFS-Administrationshandbüchern näher erläutert. Denken Sie daran, dass der wieder hinzugefügte AD-Anbieter wieder allen Zugriffszonen hinzugefügt werden muss, in denen er zuvor vorhanden war, um den Zugriff wiederherzustellen.

Die Dokumentation zu Ihrer Version von OneFS finden Sie im Artikel PowerScale OneFS Info Hubs .