PowerScale OneFS: Dostawca usługi Active Directory znika po próbie dołączenia dla tej samej domeny

Po wykonaniu sprzężenia AD o tej samej nazwie co dostawca AD, do którego klaster jest już przyłączony, dostawca może zaginąć. Administratorzy mogą zobaczyć błąd związany z próbą dołączenia, chociaż ten błąd może się różnić w zależności od przyczyny.

W poniższym przykładzie odtwarzamy problem z dostawcą TESTDOMAIN.LOCAL używając niewłaściwego konta w celu ułatwienia dołączenia.

Wyjścia z isi auth status i isi auth ads list -v Pokaż, że dostawca jest obecny przed uruchomieniem polecenia:

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

Poniżej uruchamiamy polecenie. Zwróć uwagę, że wymieniona jest nieprawidłowa nazwa użytkownika (w naszym przykładzie użyliśmy nazwy grupy dla "Administratorzy" zamiast konta administratora ):

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

Teraz brakuje dostawcy. W interfejsie WebUI może to być wyświetlane jako brak stylu, ale w interfejsie wiersza poleceń nie ma tego w danych wyjściowych dla 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

Ponieważ status uwierzytelniania isi może wskazywać, że dostawca jest nieobecny z innych powodów, musimy to zweryfikować dalej. Polecenie isi auth ads list -v Nie wyświetla żadnych danych wyjściowych pasujących do dostawcy TESTDOMAIN.LOCAL poniżej. Oznacza to, że konfiguracja nie zawiera wpisów pasujących do brakującej domeny.

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

Dzienniki LSASS pokazują podobne błędy obserwowane podczas uruchamiania początkowego polecenia:

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)

Powyższy scenariusz nie ogranicza się do użycia nieprawidłowych poświadczeń. Jeśli występuje jakikolwiek warunek, który spowodowałby niepowodzenie w dołączeniu do dostawcy usługi AD, niepowodzenie powoduje usunięcie dostawcy. Jeśli na przykład ta sama nazwa konta maszyny jest używana w innym miejscu w lesie lub w zaufanej domenie, powoduje to awarię. Jedyną różnicą może być podany błąd.

Podczas wykonywania sprzężenia usługi AD względem już przyłączonej domeny obecność warunków, które wywołałyby awarię, powoduje usunięcie dostawcy usługi AD. Jest to celowe, ponieważ OneFS potraktowałby to jako próbę "ponownego sprzężenia". W przypadku napotkania błędu wszelkie powiązane konfiguracje z tym określonym dostawcą uwierzytelniania zostaną usunięte.

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

Nazwy dostawców uwierzytelniania są globalne, więc posiadanie dwóch dostawców o tej samej nazwie nie jest obsługiwane. Jeśli nie występują inne zaległe warunki, które uniemożliwiałyby operację sprzężenia, ponowne dołączenie do domeny rozwiązuje problem.

Jeśli istnieje wymóg dołączenia do tego samego dostawcy domeny usługi AD przy użyciu oddzielnych kont komputerów, należy użyć funkcji wielu wystąpień. Jest to szczegółowo omówione w sekcji "Dostawcy uwierzytelniania specyficzni dla strefy" w Podręcznikach administracyjnych OneFS. Należy pamiętać, że ponownie przyłączony dostawca usługi AD musi zostać dodany z powrotem do wszystkich stref dostępu, które wcześniej miały go w celu przywrócenia dostępu.

Zapoznaj się z artykułem Centra informacji PowerScale OneFS, aby uzyskać dokumentację dotyczącą używanej wersji OneFS.