PowerScale: Помилка «Запит на автентифікацію не вдалося обробити» з Centrify LDAP

Приклади:

# 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

АБО

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

Під час захоплення пакетів Dell Technologies бачить такі помилки:
 

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

Повний приклад захоплення пакетів:

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

У межах кадру Підтримка може побачити наступне:
 

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]

Починаючи з версії OneFS 8.2.2.0, запити на перелік членів LDAP навмисно групують ці запити для покращення часу відповіді. OneFS перейшов з ітеративного UID-запиту, поодинокого користувача, на пакетний запит з міркувань продуктивності. 
Помилка в paps свідчить, що проксі не підтримує кілька записів 'uid' у фільтрі пошуку. Якщо проксі не підтримує кілька записів 'uid', тоді Служба підтримки потребує постачальника проксі (тобто. Centrify), щоб вирішити цю проблему.

Проксі, здається, не подобається те, що OneFS надсилає по дроту, а це у формі (&(objectClass=posixAccount)(|( uid=user1)(uid=user2)(uid=user3))) для розв'язання учасників користувачів із запиту memberUid для групи, щоб повністю розв'язати назву заявки>та членів, імена>uid

.Крім того, Centrify визнав, що наша поведінка змінилася в якийсь момент — від ітеративного uid-запиту, окремого користувача, до пакетного запиту, як зазначено вище. Згідно зі статтями та документацією з бази знань Centrify, ця помилка свідчить про те, що проксі не підтримує кілька записів 'uid' у фільтрі пошуку.

Centrify визнав, що синтаксис, який зараз використовує PowerScale, не підтримується. Є запит на покращення (RFE) на додавання цього до Centrify, і наше ім'я додано до цього RFE.

Оскільки з фільтром пошуку все гаразд, і наш програмний код не повертається до nonbatched query (з міркувань продуктивності), Centrify має підтримувати наш дійсний фільтр пошукового запиту, який звертається до кількох користувачів для uidNumber.

Зверніться до постачальника (Centrify) для вирішення питання. 

Щоб підтвердити, чи має клієнт проблему, служба підтримки Dell Technologies також може збирати захоплення пакетів, відтворюючи помилку:

Ось кроки для захоплення пакетів:


1. Згенеруйте список LDAP-серверів, налаштованих на кластері PowerScale:
 

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

2. Розв'яжіть IP-адреси кожного з LDAP-серверів, наведених вище.
 

#nslookup <ldap host>

Зверніть увагу на LDAP-IP-адреси для підтримки.

Наприклад:
 

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.  Створіть каталог із даними захоплення пакетів: 
 

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

Замініть номер SR вище на відповідний номер запиту PowerScale Support, наприклад, на номер запиту 1234567:
 

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

4. Відправляйте ssh до вузла як 'root' користувач

.5. Запустити захоплення пакетів вузлів:

тобто для сервісного запиту # 1234567 команда буде такою:
 

# 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

Введіть Ctrl-C, щоб розділити і дозволити tcpdump Працюй у фоні.

6. Далі знову створіть проблему/помилку на вузлі.
7. Після повторення проблеми/помилки зупиніть pcap:
 

# pkill -9 tcpdump

Переконайтеся, що pcaket Capture більше не працює:
 

# ps -auxwww|grep tcpdump

Ти маєш бачити, що ні tcpdump Процеси запускаються.

8. Завантажити pcaps до підтримки для перегляду.