ЕКС: Як налаштувати з'єднання з сервером AD або LDAP в інтерфейсі користувача

Підтвердьте інформацію EXACT AD або LDAP, яку потрібно використовувати.

Може статися так, що значення, введені в ECS (див. нижче), не збігаються з даними на сервері AD або LDAP, і це може спричинити неприпустимий вихід облікових даних для спроб входу користувача домену.

Перегляньте та переконайтеся, що значення містяться на сервері AD або LDAP.

Прочитайте розділ «Посібник з адміністрування ECS» у розділі «Постачальники автентифікації» та «Додайте постачальника автентифікації AD або LDAP».

Частина 1)
Обов'язковим є правильненалаштування постачальника автентифікації.
Постачальник автентифікації – це місце, де визначено з'єднання ECS із сервером AD або LDAP.

Розділ 2 і 3)
ECS можна налаштувати на використання користувачів AD або LDAP як користувачів об'єктів або як користувачів керування для входу в інтерфейс ECS UI.

У налаштуванні або усуненні несправностей почніть з мінімізації складності можливих проблем і дійте в кілька кроків.

1. Перейдіть до постачальника автентифікації ECS UI > та налаштуйте постачальника автентифікації для одного сервера AD або LDAP з однією URL-адресою сервера. Це зроблено для мінімізації складності.
   1. У полі URL-адреси сервера спробуйте використовувати LDAP замість LDAPS для тестування, якщо це можливо. Начебто LDAP не працює, то і LDAPS не працює. 
   2. Мати правильного керівника DN.
   3. Встановіть базу пошуку в точну папку користувача, а не велику базу пошуку, це робиться для того, щоб дисконтувати перевищене значення часу очікування LDAP.
   4. В якості пошукового фільтра виберіть правильний тип, атрибути користувача на сервері AD або LDAP покажуть, який з них використовувати. Див. Можливі варіанти фільтра пошуку: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Зауважте, що поширеним питанням є те, який тип постачальника автентифікації використовувати; н.е., Keystone чи LDAP? Порада полягає в тому, що якщо сервером є Windows Active Directory, то використовуйте тип AD. Якщо сервером є Linux openLDAP, використовуйте тип LDAP. Якщо сервер є Keystone, то використовуйте Keystone. 
2. Додайте тестового користувача як користувача з керуванням доменом і перевірте логін.
   1. Додати тестового користувача на ECS UI користувача>керування>користувачами > додати
   2. Правильним форматом буде username@domainname, ECS використовує символ @, щоб визначити, що він повинен шукати користувача домену, як визначено в Постачальнику аутентифікації.
   3. Ви повинні додати користувачів до списку користувачів, щоб визначити їх права на ECS, тобто admin або контролювати привілеї користувача.
3. Перевірте вхід користувача.
   1. У разі невдачі з входом користувача домену, перевірте та усуньте неполадки  
      1. Якщо це вдалося, то змініть базу пошуку на основну базу пошуку, яку хочуть користувачі, тобто кореневе розташування,
         1. Якщо потім це не вдається, єдиною зміною між успішним і невдалим входом є зміна бази пошуку, дивіться статтю знань ECS: Періодична помилка входу користувачів домену через перевищення значення тайм-ауту AD/LDAP
         2. У разі успіху доменні групи тепер можна протестувати.
   2. Якщо користувач може увійти в систему, то може використовуватися і група користувачів.
      1. Переконайтеся, що група та користувачі потрібної групи знаходяться в межах обсягу пошукової бази.
      2. Найкраще протестувати тестового користувача, як описано вище, щоб визначити, що з'єднання працює.
      3. Видаліть тестового користувача групи зі списку керування ECS, а замість цього додайте тестову групу, до якої належить користувач, до списку користувачів керування ECS. Подібно до наведених вище кроків ми намагаємося мінімізувати можливе усунення несправностей. Єдина відмінність полягає в тому, що тепер ECS знає про групу, а не про безпосереднього користувача.
      4. Ознайомтеся зі статтею зі знаннями (для доступу до статті потрібен логін для входу в обліковий запис служби підтримки Dell). Тобто, якщо ви хочете використовувати групи, ви повинні знати про цю статтю зі знаннями.
4. Якщо користувач або група з керування можуть увійти в систему, це корисно знати, оскільки легше усунути неполадки під час налаштування користувача керування доменом, ніж під час налаштування об'єкта домену, тому варто протестувати.
   1.  Якщо користувач потім хоче використовувати об'єкт домену і може довести собі, що ті самі користувачі домену працюють як користувач керування інтерфейсом користувача, то це корисно знати, оскільки якщо користувач може працювати як користувач керування інтерфейсом користувача, то він повинен працювати як користувач об'єкта.
5. Для сертифікатів LDAP (LDAP over SSL або TLS) дивіться посібник для адміністратора та статтю про знання ECS: Як налаштувати та прийняти всі сертифікати через LDAPS на ECS
   1. Рекомендується переконатися, що з'єднання LDAP працюють і користувачі можуть увійти до системи на LDAP, перш ніж розглядати параметри налаштування LDAP.
   2. Зверніть увагу, що може знадобитися дійсний і повний ланцюжок сертифікатів.
   3. Якщо використовується LDAP, адреси серверів у постачальнику розпізнавання мають бути у форматі FQDN, а не IP-адреси, щоб відповідати сертифікатам LDAP, у яких замість IP-адреси вказано FQDN серверів LDAP.   
       

Мета перелічених кроків полягає в тому, щоб зменшити можливі проблеми шляхом спрощення проблем до кроків для перевірки.

Частина 1: Постачальник
автентифікації Перегляньте посібник адміністратора ECS для всіх кроків.

Ви можете додати постачальників автентифікації до ECS, якщо хочете, щоб користувачі проходили автентифікацію в системах, зовнішніх по відношенню до ECS.

Постачальник автентифікації — це система, яка є зовнішньою по відношенню до ECS і може автентифікувати користувачів від імені ECS.

ECS зберігає інформацію, яка дозволяє їй підключатися до постачальника автентифікації, щоб ECS могла запросити автентифікацію користувача.

У ECS доступні такі типи постачальників автентифікації:

• Автентифікація Active Directory (AD) або автентифікація за протоколом легкого доступу до каталогів (LDAP): Використовується для аутентифікації користувачів домену, яким призначено ролі керування в ECS.
• Наріжний камінь: Використовується для автентифікації користувачів об'єктів OpenStack Swift.

1. Створіть користувача або групу в AD, яка містить конкретних користувачів, які повинні увійти в ECS:

1. Навігації: Керувати >Автентифікація

2.  Введіть поле Ім'я та Опис та виберіть правильний тип сервера:

 
Примітка: Повідомлення про помилку може виникнути, якщо ви намагаєтеся зберегти неправильний тип.

3. Введіть домени, які будуть використовуватися.

4. URL-адреса сервера AD або LDAP:

ldap://<Domain controller IP>:<port> Or ldaps://<Domain controller IP>:<port>

5. Зміна або оновлення DN диспетчера.

 
Наприклад: Керівник ДН: CN=Administrator,CN=Users,DC=nas2008test,DC=com
Має бути правильним розташуванням користувача Manager DN на сервері AD або LDAP.

Керівник ДН:
Це обліковий запис користувача Active Directory Bind, який ECS використовує для підключення до сервера Active Directory або LDAP. Цей обліковий запис використовується для пошуку в Active Directory, коли адміністратор ECS вказує користувача для призначення ролей.

Цей обліковий запис користувача повинен мати функцію «Прочитати всю інформацію inetOrgPerson» в Active Directory. Клас об'єктів InetOrgPerson використовується в декількох службах каталогів, що не належать Microsoft, LDAP і X.500, для представлення людей в організації.

6. Опція провайдерів

7. Встановлення атрибутів групи:

8. Оновлення або зміна білого списку груп

9. Оновлення або зміна області пошуку

10. Оновлення або зміна Пошукової бази.

11. Пошуковий фільтр

1. Підтвердьте правильний пошуковий фільтр, який мають використовувати користувачі:

dn:CN=user1,CN=Users,DC=marketing,DC=example,DC=com
userPrincipalName: user1@marketing.example.com
memberOf: CN=marketing,CN=Users,DC=example,DC=com

dn: uid=ldapuser1,ou=People,dc=example,dc=com
uid: ldapuser1
cn: ldapuser1
sn: ldapuser1

12. Налаштування мультидоменного лісу.

Мультидоменний ліс – це де є домени, які пов'язані один з одним, наприклад, батьківський і дочірній домени.

Приклад для батьків: dell.com
Дочірні домени приклад: amer.dell.com, emea.dell.com, apac.dell.com

1) Група може бути в одному з доменів, а деякі її користувачі можуть бути в інших доменах.
2) Зазвичай домени не видно один для одного, але батьківський домен може бачити всі дочірні домени, тому при налаштуванні мультидоменного лісового з'єднання використовуйте батьківський домен як основний домен для постачальника аутентифікації. 

Кроки, які відрізняються:
A) Назвіть домен на честь батьківського домену.
Б) Перелічіть усі домени, які вас цікавлять, у полі доменів постачальника автентифікації.
В) Якщо постачальник автентифікації підтримує мультидоменний ліс, використовуйте IP-адресу глобального сервера каталогу та завжди вказуйте номер порту. Порти за замовчуванням: ЛДАП: 3268, ЛДАП: 3269
D) Встановіть базу пошуку на корінь батьківського домену.
E) Зверніть увагу, що ім'я постачальника автентифікації буде основним ідентифікатором для використання домену користувачем. Тобто для цього прикладу додайте користувачів або групи, наприклад: group1@dell.com, а не субдомен, як group1@amer.dell.com
Дивіться розділ Керування та об'єкт Налаштування користувачів.

 
 

Частина 2: Управління та налаштування об'єктів Користувачі 

1. Додайте Групу в якості Користувача управління і виберіть відповідні ролі:

2. Перевірте логін з іншим користувачем у групі.

Частина 3: Користувачі AD або LDAP як користувачі об'єктів, що налаштовуються
Створення користувача керування є корисним для перевірки з'єднання з AD або LDAP і має бути виконано перед створенням об'єкта користувача.

Перегляньте Посібник адміністратора ТА Посібник із доступу до даних.

1. Додайте користувачів домену до простору імен для використання об'єктними користувачами:

Ви повинні додавати (призначати) користувачів домену в простір імен, якщо ви хочете, щоб ці користувачі виконували операції з об'єктом ECS. Щоб отримати доступ до сховища об'єктів ECS, користувачам об'єктів та адміністраторам простору імен має бути призначено простір імен. Ви можете додати цілий домен користувачів у простір імен або додати підмножину користувачів домену до простору імен, вказавши певну групу або атрибут, пов'язаний із доменом.

Домен може надавати користувачам кілька просторів імен. Наприклад, ви можете вирішити додати таких користувачів, як відділ бухгалтерського обліку в домені "yourco.com" у простір імен1, а також користувачів, як-от фінансовий відділ у домені "yourco.com", у простір імен2. У цьому випадку домен "yourco.com" надає користувачам два простори імен.

Цілий домен, певний набір користувачів або конкретний користувач не можуть бути додані до більш ніж одного простору імен. Наприклад, домен "yourco.com" можна додати до простору імен1, але домен не можна додати до простору імен2.

У наведеному нижче прикладі показано, що адміністратор системи або простору імен додав до простору імен підмножину користувачів у домені «yourco.com»; користувачів, які мають атрибут Department = Accounts in Active Directory. Адміністратор системи або простору імен додав користувачів у відділі облікових записів із цього домену до простору імен за допомогою простору імен Редагувати на порталі ECS.

Малюнок 1. Додавання підмножини користувачів домену в простір імен за допомогою одного атрибута
AD Користувачі об'єкта домену, вибрані під вибором "домен", будуть користувачами об'єктів , які не є адміністраторами, з правами доступу лише до власних створених сегментів.

 
Атрибути — це опція підмножини, яку можна видалити, натиснувши «X».
Підмножина «Атрибути» має збігатися з атрибутами користувачів домену на сервері AD.

У наведеному нижче прикладі показаний інший приклад, коли система або адміністратор простору імен використовує більшу деталізацію при додаванні користувачів до простору імен. У цьому випадку Адміністратор системи або простору імен додав учасників у домені "yourco.com", які належать до групи адміністраторів сховища з атрибутом Відділ = Облікові записи ТА Регіон = Тихоокеанський регіон, АБО належать до групи Адміністраторів сховища з атрибутом Відділ = Фінанси.

Малюнок 2. Додавання підмножини користувачів домену в простір імен за допомогою кількох атрибутів AD

2. Користувач домену для створення секретного ключа відповідно до керівництва з доступу до даних ECS

user@device:~$ curl -ik -u TestUser@TestDomain.com https://10.xxx.xxx.xxx:4443/login
Enter host password for user 'TestUser@TestDomain.com':
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 14:30:04 GMT
Content-Type: application/xml
Content-Length: 106
Connection: keep-alive
X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=
X-SDS-AUTH-USERNAME: TestUser@TestDomain.com
X-SDS-AUTH-MAX-AGE: 28800

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>TestUser@TestDomain.com</user></loggedIn>

user@device:~$ curl -ks -H "X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=" https://10.xxx.xxx.xxx:4443/object/secret-keys | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user_secret_keys>
  <secret_key_1/>
  <secret_key_1_exist>false</secret_key_1_exist>
  <secret_key_2/>
  <secret_key_2_exist>false</secret_key_2_exist>
  <key_timestamp_1/>
  <key_timestamp_2/>
</user_secret_keys>

user@device:~$ curl -ks -H "X-SDS-AUTH-TOKEN: BAAcYnJ_token_NlU0PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOmJhOGQ3ZTkzLTMyMGYtNDNmNy05Y2FkLWM4YWQzMWFiMzY1MAIADTE1ODYzNjE0Mjg5MTADAC51cm46VG9rZW46NGE3M2Q5ODYtODQ3My00ZjYxLTkwYWQtMzg5NTcyNmRmZGM3AgAC0A8=" -H "Content-Type:application/json" -X POST -d "{}" https://10.xxx.xxx.xxx:4443/object/secret-keys | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user_secret_key>
  <link rel="self" href="/object/user-secret-keys/TestUser@TestDomain.com"/>
  <secret_key>6C7fW_Secret_Key_COl38yzAHIRorJ3oiK</secret_key>
  <key_expiry_timestamp/>
  <key_timestamp>2020-04-09 14:44:27.431</key_timestamp>
</user_secret_key>

Помилка входу користувача:

"Access is denied due to invalid or expired credentials."

 
 

Приклад з інтерфейсу ECS 3.4:

 
    

1. Користувач або Пароль невірні.
2. Користувач не знайдено та користувач не знайдено може бути пов'язаний з неправильною базою пошуку в службі автентифікації для цього користувача.
3. Зміни постачальника автентифікації ECS можуть набути чинності протягом кількох хвилин, а виправлений постачальник автентифікації все одно оновлює з'єднання до AD або LDAP.
4. Параметр AD користувача "Користувач повинен змінити пароль при наступному вході" активний для цього користувача. Зауважте, що ECS не може змінити пароль користувачів домену на сервері AD або LDAP, тому це спричиняє помилку, оскільки сервер AD або LDAP намагається застосувати параметр. Або змінити пароль в іншому додатку, або зняти прапорець параметра. Також рекомендується використовувати версію 3.6.2.0 або новішу для вирішення цієї проблеми, оскільки ECS тоді повідомить користувачів про запит сервера AD до "User must change password at next login."
5. У користувача типу sAMAccountName відсутнє правильне значення домену, яке є username@domain.
6. Можливо, ви встановили базу пошуку так:

"Error 1008 (http:400): invalid parameter"

 
"Connection to the LDAP server succeeded, but the Manager DN CN=Users,DC=CAS,DC=EMC,DC=com or its password failed to authenticate"
 

1. Встановлено точне правильне місцезнаходження користувача, CN=Адміністратор,CN=Користувачі,DC=CAS,DC=EMC,DC=com не CN=Користувачі,DC=CAS,DC=EMC,DC=com 
2. Пароль правильний.
3. Користувач має необхідний дозвіл, щоб бути користувачем DN Manager.  

command type REQUEST_AUTHPROVIDER_CREATE failed with error code ERROR_RG_NOT_FOUND and message 'replication group urn:storageos:ReplicationGroupInfo:00000000-0000-0000-0000-000000000000:global not found'

Якщо користувач змінив сервер LDAP, при цьому FQDN нового сервера LDAP збігається з FQDN старого сервера LDAP.

Поточний сертифікат LDAP SSL може вказувати на старий сервер LDAP, тому сертифікат LDAP SSL має бути замінено на оновлений сертифікат LDAP SSL.

Можливе повідомлення про помилку:

 

Перевірте виданий сертифікат і переконайтеся, що FQDN точно відповідає URL-адресі, яка використовується в інтерфейсі ECS. Крім того, можна точно переглянути збіги альтернативних назв суб'єктів із сертифіката:

Команда:

sudo openssl s_client -connect :636 < /dev/null | openssl x509 -noout -text | grep DNS:

Приклад:

node1:~ # sudo openssl s_client -connect XXX.XXX.XXX:636 < /dev/null| openssl x509 -noout -text | grep DNS:
 
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
                DNS:FQDN.LDAPS1.LOCAL


node1:~ # sudo openssl s_client -connect XXX.XXX.XXX:636| openssl x509 -noout -text | grep DNS:
 
depth=0
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
verify error:num=21:unable to verify the first certificate
verify return:1
                DNS:FQDN.LDAPS.LOCAL

 
Перегляньте свій сертифікат LDAPS щодо збігів ECS, якщо ні, можливо, для ECS потрібен новий, правильний сертифікат. 

Користувач може розглянути можливість відкриття SR з підтримкою ECS для отримання допомоги, якщо це так.

---

 

1. Чи правильно користувач заповнив поле «Постачальник автентифікації»?
2. Чи створено Користувача керування?
3. Чи правильно введено користувача та пароль тесту під час входу в ECS?
4. Чи можуть вони увійти в систему з іншим користувачем з домену?
5. Це перший випадок налаштування AD або LDAP на ECS?
6. Якщо не новий AD або LDAP, налаштований на ECS, чи могли вони коли-небудь увійти в систему за допомогою цих облікових даних? Якщо так, то визначте, чи були якісь зміни, які вплинули б на авторизацію?