PowerScale: Error "No se pudo manejar la solicitud de autenticación" con LDAP de Centrify

Ejemplos:

# 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

O

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

En las capturas de paquetes, Dell Technologies observa los siguientes errores:
 

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

Ejemplo completo de captura de paquetes:

# 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)

En el marco, el soporte puede ver lo siguiente:
 

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 de la versión 8.2.2.0 de OneFS, las solicitudes de enumeración de miembros de LDAP agrupan intencionalmente las consultas para mejorar los tiempos de respuesta. OneFS cambió de una consulta de UID iterativa, usuario por usuario, a una consulta por lote, por motivos de rendimiento. 
El error en los paparazzi sugiere que el proxy no soporta varias entradas 'uid' en un filtro de búsqueda. Si el proxy no es compatible con varias entradas "uid", el soporte necesita el proveedor del proxy (es decir, Centrify) para solucionar este problema.

Parece que al proxy no le gusta lo que OneFS envía por cable, que tiene el formato de (&(objectClass=posixAccount)(|( uid=user1)(uid=user2)(uid=user3))) para resolver los miembros del usuario de la consulta memberUid para que el grupo resuelva completamente el nombre de la oferta>y los miembros, nombres>uid.

Además, Centrify ha reconocido que nuestro comportamiento cambió en algún momento, de una consulta uid iterativa, usuario por usuario, a una consulta por lotes, como se indicó anteriormente. Según los artículos y la documentación de la base de conocimientos de Centrify, el error sugiere que el proxy no admite varias entradas 'uid' en un filtro de búsqueda.

Centrify ha reconocido que la sintaxis que ahora utiliza PowerScale no es compatible. Hay una solicitud de mejora (RFE) para agregar esto a Centrify, y nuestro nombre se agregó a esa RFE.

Ya que no hay ningún problema con el filtro de búsqueda y nuestro código de software no se revierte a un nonbatched consulta (por motivos de rendimiento), Centrify debe adaptarse a nuestro filtro de consulta de búsqueda válido que consulta a varios usuarios para uidNumber.

Póngase en contacto con el proveedor (Centrify) para obtener una solución. 

Para confirmar si un cliente está experimentando el problema, el soporte de Dell Technologies también puede recolectar capturas de paquetes mientras replica el error:

Estos son los pasos para las capturas de paquetes:


1. Genere una lista de servidores LDAP configurados en el clúster de PowerScale:
 

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

2. Resuelva las direcciones IP de cada uno de los servidores LDAP mencionados anteriormente.
 

#nslookup <ldap host>

Tome nota de las direcciones IP de LDAP para el soporte.

Por ejemplo:
 

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.  Cree un directorio para contener los datos de captura de paquetes: 
 

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

Sustituya el número de SR anterior por el número de solicitud de servicio de soporte de PowerScale adecuado; por ejemplo, el número de solicitud de servicio 1234567:
 

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

4. Acceda mediante SSH a un nodo como el usuario "raíz".

5. Inicie las capturas de paquetes del nodo,

es decir, para la solicitud de servicio # 1234567, el comando sería el siguiente:
 

# 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

Escriba Ctrl-C para separarse y dejar tcpdump Se ejecutan en segundo plano.

6. A continuación, vuelva a crear el problema o el error en el nodo.
7. Una vez que replique el problema/error, detenga el pcap:
 

# pkill -9 tcpdump

Asegúrese de que el pcaket La captura ya no está en ejecución:
 

# ps -auxwww|grep tcpdump

No debería ver ningún tcpdump procesos en ejecución.

8. Cargue el archivo pcaps al Soporte para su revisión.