PowerScale: Fehler "Die Authentifizierungsanfrage konnte nicht verarbeitet werden" mit Centrify LDAP

Beispiele:

# 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

ODER

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

Bei der Paketerfassung sieht Dell Technologies die folgenden Fehler:
 

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

Vollständiges Beispiel für die Paketerfassung:

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

Innerhalb des Frames kann der Support Folgendes sehen:
 

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]

Ab OneFS-Version 8.2.2.0 gruppieren LDAP-Mitgliederaufzählungsanforderungen die Abfragen absichtlich, um die Antwortzeiten zu verbessern. OneFS wurde aus Performancegründen von einer iterativen UID-Abfrage, jeweils für einzelne Nutzer, zu einer Batchabfrage geändert. 
Der Fehler in den PAPs deutet darauf hin, dass der Proxy nicht mehrere "UID"-Einträge in einem Suchfilter unterstützt. Wenn der Proxy nicht mehrere "UID"-Einträge unterstützt, benötigt der Support den Proxyanbieter (d. h. Centrify), um dieses Problem zu beheben.

Dem Proxy scheint nicht zu gefallen, was OneFS über das Netzwerk sendet, und zwar in der Form von (&(objectClass=posixAccount)(|( uid=user1)(uid=user2)(uid=user3))) auf, um die Nutzermitglieder aus der memberUid-Abfrage für die Gruppe aufzulösen, um den Angebotsnamen>und die Mitgliedsnamen>uid vollständig aufzulösen.

Darüber hinaus hat Centrify eingeräumt, dass sich unser Verhalten irgendwann geändert hat, von einer iterativen UID-Abfrage, Benutzer für Benutzer, zu einer Batch-Abfrage, wie oben beschrieben. Laut Artikeln und Dokumentationen der Centrify-Wissensdatenbank deutet der Fehler darauf hin, dass der Proxy nicht mehrere "UID"-Einträge in einem Suchfilter unterstützt.

Centrify hat bestätigt, dass die von PowerScale verwendete Syntax nicht unterstützt wird. Es gibt einen Request for Enhancement (RFE), um dies zu Centrify hinzuzufügen, und unser Name wurde zu dieser RFE hinzugefügt.

Da mit dem Suchfilter nichts falsch ist und unser Softwarecode nicht zu einem nonbatched query (aus Leistungsgründen) muss Centrify unseren gültigen Suchabfragefilter berücksichtigen, der mehrere Benutzer nach uidNumberaus.

Wenden Sie sich zur Lösung an den Anbieter (Centrify). 

Um zu überprüfen, ob bei einem Kunden das Problem auftritt, kann der Support von Dell Technologies auch Paketerfassungen erfassen, während der Fehler repliziert wird:

Hier sind die Schritte für Paketerfassungen:


1. Erzeugen Sie eine Liste der LDAP-Server, die im PowerScale-Cluster konfiguriert sind:
 

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

2. Lösen Sie die IP-Adressen der einzelnen LDAP-Server oben auf.
 

#nslookup <ldap host>

Notieren Sie sich die LDAP-IP-Adressen für den Support.

Zum Beispiel:
 

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.  Erstellen Sie ein Verzeichnis, das die Paketerfassungsdaten enthalten soll: 
 

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

Ersetzen Sie die obige SR-Nummer durch die richtige Service-Request-Nummer des PowerScale-Supports, z. B. für die Service-Request-Nummer 1234567:
 

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

4. Stellen Sie eine SSH-Verbindung zu einem Node als Root-Nutzer her.

5. Starten der Node-Paketerfassung

:, d. h. für Service-Request # 1234567 lautet der Befehl wie folgt:
 

# 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

Geben Sie Strg-C ein, um die Trennung zu unterbrechen und tcpdump im Hintergrund ausführen.

6. Erstellen Sie als Nächstes das Problem/den Fehler auf dem Node neu.
7. Sobald Sie das Problem/den Fehler repliziert haben, beenden Sie die pcapverwalten:
 

# pkill -9 tcpdump

Stellen Sie sicher, dass die pcaket Die Erfassung wird nicht mehr ausgeführt:
 

# ps -auxwww|grep tcpdump

Sie sollten keine tcpdump Prozesse, die ausgeführt werden.

8. Laden Sie die pcaps an den Support zur Überprüfung weiterleiten.