PowerScale OneFS: O provedor do Active Directory desaparece após a tentativa de ingresso no mesmo domínio

Depois de executar uma associação do AD com o mesmo nome de um provedor do AD ao qual o cluster já está associado, o provedor pode desaparecer. Os administradores podem ver um erro relacionado à tentativa de ingresso, embora esse erro possa variar dependendo da causa.

No exemplo abaixo, reproduzimos o problema com o provedor TESTDOMAIN.LOCAL usando a conta incorreta para facilitar a associação.

Saídas de isi auth status e isi auth ads list -v Mostrar que o provedor está presente antes de executar o comando:

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

Abaixo, executamos o comando. Observe que o nome de usuário incorreto listado (por exemplo, usamos o nome do grupo para 'Administradores' em vez da conta de administrador ):

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

Agora o provedor está ausente. Na WebUI, isso pode aparecer como sem estilo, mas na CLI, não está no resultado para 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

Como o status isi auth pode mostrar que um provedor está ausente por outros motivos, devemos validar isso ainda mais. O comando isi auth ads list -v Não exibe nenhuma saída correspondente ao provedor TESTDOMAIN.LOCAL abaixo. Isso significa que a configuração não contém entradas correspondentes ao domínio ausente.

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

Os logs do LSASS mostram erros semelhantes observados ao executar o comando inicial:

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)

O cenário acima não se limita ao uso de credenciais incorretas. Se houver alguma condição presente que induza a uma falha ao ingressar no provedor do AD, a falha resultará na exclusão do provedor. Por exemplo, se o mesmo nome para a conta da máquina for usado em outro lugar dentro da floresta ou em um domínio confiável, isso induz a uma falha. A única diferença pode ser o erro fornecido.

Ao fazer uma associação do AD em um domínio já associado, a presença de condições que induziriam a falha resulta na exclusão do provedor do AD. Isso ocorre por padrão, pois o OneFS trataria isso como uma tentativa de "reingresso". Quando a falha é encontrada, qualquer configuração relacionada ao provedor de autenticação especificado é excluída.

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

Os nomes dos provedores de autenticação são globais, portanto, não é possível ter dois provedores com o mesmo nome. Se não houver outras condições pendentes presentes que impeçam uma operação de associação, reingressar no domínio resolverá o problema.

Se houver um requisito para ingressar no mesmo provedor de domínio do AD com contas de máquina separadas, o recurso de várias instanciações deverá ser usado. Isso é detalhado na seção "Provedores de autenticação específicos de zona" dos Guias de administração do OneFS. Lembre-se de que o provedor do AD reingressado deve ser adicionado de volta a todas as zonas de acesso que o tinham anteriormente para restaurar o acesso.

Consulte o artigo Hubs de informações do PowerScale OneFS para obter a documentação sobre sua versão do OneFS.