PowerScale : Erreur « La demande d’authentification n’a pas pu être traitée » avec Centrify LDAP

Exemples :

# 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

Dans les captures de paquets, Dell Technologies voit les erreurs suivantes :
 

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

Exemple complet de capture de paquets :

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

Dans le cadre, le support peut voir les éléments suivants :
 

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]

À partir de OneFS version 8.2.2.0, les demandes d’énumération des membres LDAP regroupent intentionnellement les requêtes afin d’améliorer les temps de réponse. OneFS est passé d’une requête itérative d’UID, utilisateur par utilisateur, à une requête par lots, pour des raisons de performances. 
L’erreur dans les paps suggère que le proxy ne prend pas en charge plusieurs entrées 'uid' dans un filtre de recherche. Si le proxy ne prend pas en charge plusieurs entrées 'uid', le support a besoin du fournisseur du proxy (c’est-à-dire Centrify) pour résoudre ce problème.

Le proxy semble ne pas aimer ce que OneFS envoie sur le réseau, qui se présente sous la forme (&(objectClass=posixAccount)(|( uid=user1)(uid=user2)(uid=user3))) pour résoudre les membres utilisateur à partir de la requête memberUid pour le groupe afin de résoudre complètement le nom de l’offre>et les membres, noms>uid.

De plus, Centrify a reconnu que notre comportement a changé à un moment donné, passant d’une requête itérative uid, utilisateur par utilisateur, à une requête par lots, comme ci-dessus. Selon les articles et la documentation de la base de connaissances Centrify, l’erreur suggère que le proxy ne prend pas en charge plusieurs entrées « uid » dans un filtre de recherche.

Centrify a reconnu que la syntaxe utilisée par PowerScale n’est pas prise en charge. Il y a une demande d’amélioration (RFE) pour l’ajouter à Centrify, et notre nom a été ajouté à ce RFE.

Comme il n’y a aucun problème avec le filtre de recherche, et que notre code logiciel ne revient pas à un nonbatched (pour des raisons de performance), Centrify doit prendre en charge notre filtre de requête de recherche valide interrogeant plusieurs utilisateurs pour uidNumber.

Contactez le fournisseur (Centrify) pour obtenir une solution. 

Pour confirmer si un client rencontre le problème, le support Dell Technologies peut également collecter des captures de paquets lors de la réplication de l’erreur :

Voici les étapes à suivre pour les captures de paquets :


1. Générez la liste des serveurs LDAP configurés sur le cluster PowerScale :
 

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

2. Résolvez les adresses IP de chacun des serveurs LDAP ci-dessus.
 

#nslookup <ldap host>

Notez les adresses IP LDAP du support.

Par exemple :
 

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.  Créez un répertoire pour contenir les données de capture de paquets : 
 

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

Remplacez le numéro de demande de service ci-dessus par le numéro de demande de service PowerScale approprié, par exemple, pour le numéro de demande de service 1234567 :
 

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

4. Connectez-vous en SSH à un nœud en tant qu’utilisateur root.

5. Démarrer les captures de paquets de nœuds :

c’est-à-dire pour la demande de service # 1234567, la commande doit être la suivante :
 

# 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

Tapez Ctrl-C pour vous évader et laisser tcpdump Exécutez en arrière-plan.

6. Ensuite, recréez le problème/l’erreur sur le nœud.
7. Une fois que vous avez reproduit le problème/l’erreur, arrêtez le pcap:
 

# pkill -9 tcpdump

Assurez-vous que le pcaket La capture n’est plus en cours d’exécution :
 

# ps -auxwww|grep tcpdump

Vous ne devriez pas voir tcpdump processus en cours d’exécution.

8. Téléchargez le pcaps à l’assistance pour révision.