ECS. Как настроить подключение к серверу AD или LDAP в пользовательском интерфейсе

Подтвердите ТОЧНУЮ информацию AD или LDAP, которая будет использоваться.

Может случиться так, что значения, введенные в ECS (см. ниже), не совпадут со сведениями на сервере AD или LDAP, из-за чего при попытках входа пользователя домена в систему могут появиться выводы об ошибке недопустимых учетных данных.

Просмотрите и проверьте значения на сервере AD или LDAP.

Прочитайте раздел руководства администратора ECS в главе о поставщиках проверки подлинности и разделе «Добавление поставщика проверки подлинности AD или LDAP».

Раздел 1)
Необходимо правильнонастроить поставщика проверки подлинности.
Поставщик аутентификации определяет подключение ECS к серверу AD или LDAP.

Разделы 2 и 3)
ECS можно настроить для использования пользователей AD или LDAP в качестве пользователей объектов или пользователей управления для входа в пользовательский интерфейс ECS.

При настройке или устранении неисправностей начните с минимизации сложности возможных проблем и переходите к выполнению нескольких шагов.

1. Перейдите в ECS UI > Authentication Provider и настройте для поставщика аутентификации один сервер AD или LDAP с одним URL-адресом сервера. Это необходимо для минимизации сложности.
   1. Попробуйте по возможности использовать для тестирования LDAP вместо LDAPS в поле URL-адреса сервера. Если LDAP не работает, то и LDAPS тоже не работает. 
   2. Подготовьте правильное доменное имя менеджера.
   3. Задайте базу поиска в точной папке пользователей, а не в большой базе поиска, чтобы не учитывать превышение значения времени ожидания LDAP.
   4. В качестве фильтра поиска выберите правильный тип, который будет указан в атрибутах users на сервере AD или LDAP. Смотрите ниже. Возможные варианты фильтра поиска: sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Обратите внимание, что часто возникает вопрос о том, какой тип поставщика проверки подлинности использовать; AD, Keystone или LDAP? Если сервером является Windows Active Directory, следует использовать тип AD. Если используется сервер Linux openLDAP, используйте тип LDAP. Если сервер является Keystone, то используйте Keystone. 
2. Добавьте тестового пользователя в качестве пользователя управления доменом и проверьте вход в систему.
   1. Добавление тестового пользователя в пользовательском интерфейсе> ECS Добавлениепользователя >> управления
   2. Правильным форматом является username@domainname, ECS использует символ @, чтобы определить, что необходимо выполнить поиск пользователя домена, как определено в поставщике проверки подлинности.
   3. Необходимо добавить пользователей в список пользователей, чтобы определить их права в ECS, то есть права администратора или пользователя мониторинга.
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. Прежде чем приступать к настройке LDAPS, рекомендуется убедиться, что подключения LDAP работают и пользователи могут входить в LDAP.
   2. Обратите внимание, что может потребоваться действительная и полная цепочка сертификатов.
   3. При использовании LDAPS URL-адреса серверов в поставщике проверки подлинности должны иметь формат полного доменного имени, а не IP-адреса, чтобы соответствовать сертификатам LDAPS, в которых вместо IP-адреса будет указано полное доменное имя серверов LDAP.   
       

Цель перечисленных шагов — исключить возможные проблемы из списка, упростив их до шагов для проверки.

Раздел 1: Поставщик
проверки подлинностиВсе действия см. в руководстве администратора ECS.

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

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

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

В ECS доступны следующие типы поставщиков проверки подлинности:

• Аутентификация Active Directory (AD) или LDAP (Lightweight Directory Access Protocol): Используется для аутентификации пользователей домена, которым назначены роли управления в 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
Должно быть правильным местоположением пользователя с доменным именем диспетчера на сервере AD или LDAP.

Отличительные данные управляющего:
Это учетная запись пользователя привязки Active Directory, которая 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-адрес сервера глобального каталога и всегда указывайте номер порта. Порты по умолчанию: LDAP: 3268, LDAPS: 3269
D) Установите в качестве базы поиска корень родительского домена.
Д) Обратите внимание, что имя поставщика аутентификации будет основным идентификатором для использования пользователем домена. То есть для этого примера добавьте пользователей или группы, например: 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» можно добавить в namespace1, но домен нельзя добавить в namespace2.

В следующем примере показано, что системный администратор или администратор пространства имен добавил в пространство имен подмножество пользователей в домене «yourco.com»; пользователи, имеющие атрибут Department = Accounts in Active Directory. Системный администратор или администратор пространства имен добавил пользователей из этого домена в отдел учетных записей в пространство имен с помощью функции Изменить пространство имен на портале ECS.

Рисунок 1. Добавление подмножества пользователей домена в пространство имен с помощью одного атрибута
AD Пользователи объектов домена, выбранные в разделе «domain», будут пользователями объектов без прав администратора с правами доступа только к собственным созданным контейнерам.

 
Атрибуты — это параметр подмножества, который можно удалить, нажав «X».
Подмножество Атрибутов должно совпадать с Атрибутами пользователей домена на сервере AD.

В следующем примере показан другой пример, в котором системный администратор или администратор пространства имен использует большую детализацию при добавлении пользователей в пространство имен. В этом случае системный администратор или администратор пространства имен добавил в домен «yourco.com» участников, которые относятся к группе «Администраторы хранилища» с атрибутом «Department = Accounts» И атрибутом «Region» = Pacific, ИЛИ относятся к группе «Администраторы хранилища» с атрибутом «Department = Finance».

Рис. 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 = Administrator, CN = Users, DC = CAS, DC = EMC, DC = com, а не CN = Users, DC = CAS, DC = EMC, DC = com 
2. Введен правильный пароль.
3. Пользователь имеет необходимые права для того, чтобы стать управляющим доменным именем.  

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, а полностью определенное доменное имя нового сервера LDAP совпадает с полным доменным именем старого сервера LDAP.

Текущий SSL-сертификат LDAP может указывать на старый сервер LDAP, поэтому сертификат LDAP SSL необходимо заменить обновленным SSL-сертификатом LDAP.

Возможное сообщение об ошибке:

 

Проверьте, выдан ли сертификат, и убедитесь, что полностью определенное доменное имя точно соответствует URL-адресу, используемому в пользовательском интерфейсе ECS. Либо проверьте, соответствуют ли альтернативные имена субъектов точно из certificate:

Command:

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. Правильно ли заполнено пользователем поле Authentication Provider?
2. Создан ли пользователь управления?
3. Правильно ли введены тестовый пользователь и пароль при входе в ECS?
4. Могут ли они войти в систему с другим пользователем из домена?
5. Это первый раз, когда AD или LDAP настраивается на ECS?
6. Если это не новый AD или LDAP, настроенный на ECS, он когда-либо мог войти с этими учетными данными? Если да, то укажите, произошли ли какие-либо изменения, которые могут повлиять на авторизацию?