PowerScale: Erro "Não foi possível processar a solicitação de autenticação" com LDAP centralizado

Exemplos:

# isi auth groups members list dellgroup --zone dellzone --provider="lsa-ldap-provider:Centrify LDAP Proxies"
Failed to get members for group GROUP:dellgroup: The authentication request could not be handled

OU

isi auth groups members list --gid 30118 
Failed to get members for group GID:30118: The authentication request could not be handled

Nas capturas de pacotes, a Dell Technologies vê os seguintes erros:
 

errorMessage: cdcLdapSearch :Bad parameter (cdcRC=4), errSystem=Ldap, errCode=-7, errString=Bad search filter

Exemplo completo de captura de pacote:

# tshark -r file.cap

1060 736.218674 10.193.45.68 â 10.193.3.52  LDAP 1194 searchRequest(4) "ou=North America,dc=acf,dc=dell,dc=com" wholeSubtree
1061 736.218828  10.193.3.52 â 10.193.45.68 TCP 66 389 â 15206 [ACK] Seq=3557 Ack=1413 Win=261656 Len=0 TSval=1645667785 TSecr=662636581
1062 736.258022  10.193.3.52 â 10.193.45.68 LDAP 175 searchResDone(4) other (cdcLdapSearch :Bad parameter (cdcRC=4), errSystem=Ldap, errCode=-7, errString=Bad search filter)  [2 results]
1063 736.258142  10.193.3.52 â 10.193.45.68 LDAP 175 searchResDone(4) other (cdcLdapSearch :Bad parameter (cdcRC=4), errSystem=Ldap, errCode=-7, errString=Bad search filter)  [2 results]
1064 736.258150 10.193.45.68 â 10.193.3.52  TCP 66 15206 â 389 [ACK] Seq=1413 Ack=3775 Win=131648 Len=0 TSval=662641755 TSecr=1645667785
1065 736.261570 10.193.45.68 â 10.193.3.52  LDAP 73 unbindRequest(5)

Dentro da estrutura, o Suporte pode ver o seguinte:
 

Lightweight Directory Access Protocol
    LDAPMessage searchResDone(4) other (cdcLdapSearch :Bad parameter (cdcRC=4), errSystem=Ldap, errCode=-7, errString=Bad search filter) [2 results]
        messageID: 4
        protocolOp: searchResDone (5)
            searchResDone
                resultCode: other (80)
                matchedDN:
                errorMessage: cdcLdapSearch :Bad parameter (cdcRC=4), errSystem=Ldap, errCode=-7, errString=Bad search filter
        [Response To: 1060]
        [Time: 0.039348000 seconds]

A partir do OneFS versão 8.2.2.0, as solicitações de enumeração de membros LDAP agrupam intencionalmente as consultas para melhorar os tempos de resposta. O OneFS mudou de uma consulta UID iterativa, usuário por usuário, para uma consulta em lote, por motivos de desempenho. 
O erro nos paps sugere que o proxy não suporta várias entradas 'uid' em um filtro de pesquisa. Se o proxy não for compatível com várias entradas "uid", o suporte precisará do fornecedor do proxy (ou seja, Centrify) para corrigir esse problema.

O proxy parece não gostar do que o OneFS envia pela rede, que tem a forma de (&(objectClass=posixAccount)(|( uid=user1)(uid=user2)(uid=user3))) para resolver a consulta dos membros do usuário a partir do memberUid para que o grupo resolva totalmente o nome do lance>e os membros, nomes>uid.

Além disso, a Centrify reconheceu que nosso comportamento mudou em algum momento, de uma consulta uid iterativa, usuário por usuário, para uma consulta em lote, como acima. De acordo com artigos e documentação da base de conhecimento da Centrify, o erro sugere que o proxy não suporta várias entradas 'uid' em um filtro de pesquisa.

A Centrify reconheceu que a sintaxe que o PowerScale está usando agora não é compatível. Há uma RFE (Request for Enhancement, solicitação de aprimoramento) para adicioná-la ao Centrify, e nosso nome foi adicionado a esse RFE.

Como não há nada de errado com o filtro de pesquisa, e nosso código de software não está revertendo para um nonbatched (por motivos de desempenho), o Centrify deve acomodar nosso filtro de consulta de pesquisa válido consultando vários usuários para uidNumber.

Entre em contato com o fornecedor (Centrify) para obter resolução. 

Para confirmar se um cliente está enfrentando o problema, o suporte da Dell Technologies também pode coletar capturas de pacotes ao replicar o erro:

Aqui estão as etapas para capturas de pacotes:


1. Gere uma lista de servidores LDAP configurados no cluster do PowerScale:
 

# isi auth ldap ls
Name  Base DN       Server Uris         Status
-----------------------------------------------
LDAP  DC=amd,DC=com ldap://isilon02 online
                    ldap://isilon0404

2. Resolva os endereços IP de cada um dos servidores LDAP, acima.
 

#nslookup <ldap host>

Anote os endereços IP LDAP para suporte.

Por exemplo:
 

powerscale-2-1# nslookup isilon02
Server:         127.42.0.1
Address:        127.42.0.1#53

Non-authoritative answer:
Name:   isilon02.dell.com
Address: 10.178.35.1

3.  Crie um diretório para conter os dados de captura de pacotes: 
 

# mkdir -p /ifs/data/Isilon_Support/<SR number>

Substitua o número do SR acima pelo número de chamado de suporte adequado do PowerScale, por exemplo, para o número do chamado 1234567:
 

# mkdir -p /ifs/data/Isilon_Support/1234567

4. Ssh para um nó como usuário "root".

5. Iniciar capturas de pacote de nó:ou

seja, para o chamado # 1234567, o comando seria o seguinte:
 

# for i in $(ifconfig | grep flags= | cut -f1 -d':'|egrep -v "ib0|ib1|lo0"); do tcpdump -i ${i} -s0 -C 200 -W 3 -w /ifs/data/Isilon_Support/1234567/${HOST}_${i}.pcap port 389 &; done

Digite Ctrl-C para sair e deixar tcpdump Execute em segundo plano.

6. Em seguida, crie novamente o problema/erro no nó.
7. Depois de replicar o problema/erro, interrompa o pcap:
 

# pkill -9 tcpdump

Certifique-se de que o pcaket A captura não está mais em execução:
 

# ps -auxwww|grep tcpdump

Você deve ver No tcpdump processos em execução.

8. Carregue o pcaps ao Suporte para revisão.