ECS : Configuration d’une connexion au serveur AD ou LDAP dans l’interface utilisateur

Confirmez les informations AD ou LDAP EXACTES à utiliser.

Il peut arriver que les valeurs saisies dans ECS (voir ci-dessous) ne correspondent pas aux détails du serveur AD ou LDAP, ce qui peut générer une sortie d’erreur d’informations d’identification non valide pour les tentatives de connexion des utilisateurs de domaine.

Affichez et vérifiez les valeurs dans le serveur AD ou LDAP.

Lisez la section du guide d’administration d’ECS dans le chapitre Authentication Providers et « Add an AD or LDAP authentication provider ».

Chapitre 1)
Le fournisseur d’authentification doit obligatoirement être configuré correctement.
Le fournisseur d’authentification est l’endroit où la connexion ECS au serveur AD ou LDAP est définie.

Sections 2 et 3)
ECS peut être configuré pour utiliser les utilisateurs AD ou LDAP en tant qu’utilisateurs d’objets ou en tant qu’utilisateurs de gestion pour se connecter à l’interface utilisateur ECS.

Lors de la configuration ou du dépannage, commencez par réduire la complexité des problèmes possibles et procédez en plusieurs étapes.

1. Accédez au fournisseur d’authentification de l’interface utilisateur > ECS et configurez un fournisseur d’authentification sur un serveur AD ou LDAP avec une URL de serveur. Cela permet de minimiser la complexité.
   1. Dans la zone URL du serveur, essayez d’utiliser LDAP au lieu de LDAPS pour les tests, si possible. Comme si LDAP ne fonctionnait pas, LDAPS non plus. 
   2. Disposer d’un DN de gestionnaire correct.
   3. Définissez la base de recherche dans un dossier utilisateur exact, et non dans une grande base de recherche. Cela permet d’ignorer le dépassement de la valeur du délai d’expiration LDAP.
   4. Pour le filtre de recherche, sélectionnez le type approprié. Les attributs des utilisateurs sur le serveur AD ou LDAP indiquent lequel utiliser. Voir ci-dessous. Options de filtre de recherche possibles : sAMAccountName=%U, userPrincipalName=%u, uid=%U
   5. Notez qu’une question fréquente est de savoir quel type de fournisseur d’authentification utiliser. AD, Keystone ou LDAP ? Nous conseillons d’utiliser le type AD si le serveur est un Windows Active Directory. Si le serveur est un linux openLDAP, utilisez le type LDAP. S’il s’agit d’un serveur Keystone, utilisez-le. 
2. Ajoutez l’utilisateur test en tant qu’utilisateur de gestion de domaine et testez la connexion.
   1. Ajoutez l’utilisateur de test sur ECS>UI users > management user>add
   2. Le format correct est username@domainname. ECS utilise le symbole @ pour détecter qu’il doit rechercher un utilisateur de domaine tel que défini dans le fournisseur d’authentification.
   3. Vous devez ajouter des utilisateurs à la liste des utilisateurs pour définir leurs droits sur ECS avec des privilèges d’administrateur ou de surveillance.
3. Testez la connexion utilisateur.
   1. En cas d’échec de la connexion de l’utilisateur de domaine, examinez et résolvez les problèmes  
      1. En cas de succès, remplacez la base de recherche par la base de recherche principale souhaitée par les utilisateurs, c’est-à-dire l’emplacement racine,
         1. En cas d’échec, le seul changement entre une connexion réussie et une connexion infructueuse est un changement de base de recherche. Voir l’article de la base de connaissances ECS : Échec intermittent de la connexion des utilisateurs du domaine en raison d’une valeur de délai d’expiration AD/LDAP dépassée
         2. En cas de réussite, les groupes de domaines peuvent maintenant être testés.
   2. Si un utilisateur peut se connecter, un groupe d’utilisateurs peut également être utilisé.
      1. Assurez-vous que le groupe et les utilisateurs du groupe requis se trouvent dans le périmètre de la base de recherche.
      2. Il est préférable de tester un utilisateur test comme ci-dessus pour déterminer que la connexion fonctionne.
      3. Supprimez l’utilisateur test du groupe de la liste de gestion ECS et ajoutez à la place le groupe de test auquel appartient l’utilisateur dans la liste des utilisateurs de gestion ECS. Tout comme les étapes ci-dessus, nous essayons de minimiser les éventuels dépannages. La seule différence réside dans le fait qu’ECS connaît le groupe et non l’utilisateur direct.
      4. Prenez connaissance de l’article de la base de connaissances (vous devez vous connecter au compte de support Dell pour accéder à l’article). C’est-à-dire que si vous souhaitez utiliser des groupes, vous devez connaître cet article de la base de connaissances.
4. Avec un utilisateur ou un groupe de gestion capable de se connecter, cela est utile car il est plus facile de dépanner la configuration de l’utilisateur de gestion de domaine que la configuration de l’utilisateur d’objet de domaine. Il est donc bon de tester.
   1.  Si un utilisateur souhaite ensuite utiliser un objet de domaine et peut se prouver à lui-même que ces mêmes utilisateurs de domaine fonctionnent en tant qu’utilisateur de gestion de l’interface utilisateur, cela est utile à savoir, car si un utilisateur peut travailler en tant qu’utilisateur de gestion de l’interface utilisateur, il doit travailler en tant qu’utilisateur d’objet.
5. Pour les certificats LDAP (LDAP sur SSL ou TLS), reportez-vous au guide d’administration et à l’article de la base de connaissances ECS : Configuration et acceptation de tous les certificats via LDAPS sur ECS
   1. Il est recommandé de confirmer que les connexions LDAP fonctionnent et que les utilisateurs peuvent se connecter sur LDAP avant d’examiner la configuration LDAPS.
   2. Notez qu’une chaîne de certificats valide et complète peut être requise.
   3. Si vous utilisez LDAPS, les URL de serveur dans le fournisseur d’authentification doivent être au format FQDN plutôt que l’adresse IP, afin de correspondre aux certificats LDAPS qui répertorient le FQDN des serveurs LDAP au lieu de l’adresse IP.   
       

L’objectif des étapes répertoriées est d’écarter les problèmes possibles en les simplifiant en étapes de vérification.

Chapitre 1 : Fournisseur
d’authentification Consultez le Guide d’administration d’ECS pour connaître toutes les étapes.

Vous pouvez ajouter des fournisseurs d’authentification à ECS si vous souhaitez que les utilisateurs soient authentifiés par des systèmes externes à ECS.

Un fournisseur d’authentification est un système externe à ECS qui peut authentifier les utilisateurs pour le compte d’ECS.

ECS stocke les informations qui lui permettent de se connecter au fournisseur d’authentification afin qu’ECS puisse demander l’authentification d’un utilisateur.

Dans ECS, les types de fournisseurs d’authentification suivants sont disponibles :

• Authentification Active Directory (AD) ou authentification LDAP (Lightweight Directory Access Protocol) : Utilisé pour authentifier les utilisateurs de domaine attribués à des rôles de gestion dans ECS.
• Clef de voûte: Utilisé pour authentifier les utilisateurs d’objets OpenStack Swift.

1. Créez l’utilisateur ou le groupe dans AD contenant les utilisateurs spécifiques qui doivent se connecter à ECS :

1. Navigation : Gérer >Authentification

2.  Renseignez les champs Nom et description, puis sélectionnez le type de serveur approprié :

 
Remarque : Un message d’erreur peut s’afficher si vous tentez d’enregistrer un type incorrect.

3. Saisissez les domaines à utiliser.

4. URL du serveur AD ou LDAP :

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

5. Modification ou mise à jour du nom unique du gestionnaire.

 
Par exemple : Nom distinctif du gestionnaire : CN=Administrator,CN=Users,DC=nas2008test,DC=com
Il doit s’agir de l’emplacement correct de l’utilisateur Manager DN sur le serveur AD ou LDAP.

Le nom unique du gestionnaire :
Il s’agit du compte d’utilisateur de liaison Active Directory qu’ECS utilise pour se connecter au serveur Active Directory ou LDAP. Ce compte sert à effectuer des recherches dans Active Directory lorsqu’un administrateur ECS choisit un utilisateur auquel attribuer un rôle.

Ce compte d’utilisateur doit avoir « Lire toutes les informations inetOrgPerson » dans Active Directory. La classe d’objets InetOrgPerson est utilisée dans plusieurs services d’annuaire non-Microsoft, LDAP et X.500 pour représenter les personnes d’une organisation.

6. Option Fournisseurs

7. Définition des attributs du groupe :

8. Mise à jour ou modification de la liste blanche de groupes

9. Mise à jour ou modification du périmètre de recherche

10. Mise à jour ou modification de la base de recherche.

11. Filtre de recherche

1. Confirmez le filtre de recherche correct que les utilisateurs doivent utiliser :

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. Configuration d’une forêt multidomaine.

Une forêt multidomaine est l’endroit où des domaines sont connectés les uns aux autres, par exemple, un domaine parent et un domaine enfant.

Exemple parent : dell.com
Exemple de domaines enfants : amer.dell.com, emea.dell.com, apac.dell.com

1) Un groupe peut se trouver dans l’un des domaines et certains de ses utilisateurs peuvent se trouver dans d’autres domaines.
2) Normalement, les domaines ne sont pas visibles les uns par les autres, mais le domaine parent peut voir tous les domaines enfants. Par conséquent, lors de la configuration d’une connexion de forêt multidomaine, utilisez le domaine parent comme domaine principal pour le fournisseur d’authentification. 

Étapes différentes :
A) Nommez le domaine d’après le domaine parent.
B) Répertoriez tous les domaines d’intérêt dans la zone des domaines du fournisseur d’authentification.
C) Si le fournisseur d’authentification prend en charge une forêt multidomaine, utilisez l’adresse IP du serveur du catalogue global et spécifiez toujours le numéro de port. Ports par défaut : LDAP: 3268, LDAPS : 3269
D) Définir la base de recherche à la racine du domaine parent.
E) Notez que le nom du fournisseur d’authentification est l’identifiant principal utilisé par l’utilisateur du domaine. Dans cet exemple, ajoutez des utilisateurs ou des groupes comme par exemple : group1@dell.com, et non un sous-domaine comme group1@amer.dell.com
Voir la section Gestion et configuration des utilisateurs d’objets.

 
 

Section 2 : Configuration des utilisateurs de gestion et d’objets 

1. Ajoutez le groupe en tant qu’utilisateur de gestion et choisissez les rôles appropriés :

2. Testez la connexion avec l’autre utilisateur du groupe.

Section 3 : Utilisateurs AD ou LDAP en tant qu’utilisateurs d’objets configurés
La création d’un utilisateur de gestion est utile pour tester la connexion à AD ou LDAP et doit être effectuée avant de créer un utilisateur d’objets.

Consultez le Guide d’administration ET le Guide d’accès aux données.

1. Ajoutez des utilisateurs de domaine à un espace de nommage à usage d’objets :

Vous devez ajouter (attribuer) des utilisateurs de domaine dans un espace de nommage si vous souhaitez que ces utilisateurs effectuent des opérations sur les utilisateurs d’objets ECS. Pour accéder à la zone de stockage d’objets ECS, les utilisateurs d’objets et les administrateurs d’espace de nommage doivent être affectés à un espace de nommage. Vous pouvez ajouter un domaine entier d’utilisateurs dans un espace de nommage, ou vous pouvez ajouter un sous-ensemble des utilisateurs du domaine dans un espace de nommage en spécifiant un groupe ou un attribut particulier associé au domaine.

Un domaine peut fournir des utilisateurs pour plusieurs espaces de nommage. Par exemple, vous pouvez décider d’ajouter des utilisateurs tels que le service Comptabilité dans le domaine « yourco.com » dans namespace1, et des utilisateurs tels que le département Finance dans le domaine « yourco.com » dans namespace2. Dans ce cas, le domaine « yourco.com » fournit des utilisateurs pour deux espaces de nommage.

Un domaine entier, un ensemble particulier d’utilisateurs ou un utilisateur particulier ne peuvent pas être ajoutés dans plusieurs espaces de nommage. Par exemple, le domaine « yourco.com » peut être ajouté dans namespace1, mais il ne peut pas non plus être ajouté dans namespace2.

L’exemple suivant montre qu’un administrateur de système ou d’espace de nommage a ajouté à un espace de nommage un sous-ensemble d’utilisateurs dans le domaine « yourco.com » ; les utilisateurs qui ont leur attribut Service = Comptes dans Active Directory. L’administrateur du système ou de l’espace de nommage a ajouté les utilisateurs du service des comptes de ce domaine dans un espace de nommage via la commande Edit namespace du portail ECS.

Graphique 1. Ajout d’un sous-ensemble d’utilisateurs de domaine dans un espace de nommage à l’aide d’un attribut
AD Les utilisateurs d’objets de domaine sélectionnés dans la sélection « domain » sont des utilisateurs d’objets non administrateurs disposant uniquement de droits d’accès aux buckets qu’ils ont créés.

 
Les attributs sont une option de sous-ensemble qui peut être supprimée en cliquant sur « X ».
Le sous-ensemble Attributs doit correspondre aux Attributs des utilisateurs de domaine sur le serveur AD.

L’exemple suivant montre un autre exemple dans lequel l’administrateur du système ou de l’espace de nommage utilise une plus grande granularité pour ajouter des utilisateurs dans un espace de nommage. Dans ce cas, l’administrateur du système ou de l’espace de nommage a ajouté les membres du domaine « yourco.com » qui appartiennent au groupe Storage Admins avec l’attribut Department = Accounts AND Region attribut = Pacific, OU appartiennent au groupe Storage Admins avec l’attribut Department = Finance.

Figure 2. Ajout d’un sous-ensemble d’utilisateurs de domaine dans un espace de nommage à l’aide de plusieurs attributs AD

2. L’utilisateur du domaine doit créer une clé secrète conformément au guide d’accès aux données 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>

Erreur de connexion utilisateur :

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

 
 

Exemple tiré de l’interface utilisateur ECS 3.4 :

 
    

1. L’utilisateur ou le mot de passe est incorrect.
2. L’utilisateur introuvable et l’utilisateur introuvable peuvent être dus à une base de recherche incorrecte dans le fournisseur d’authentification pour cet utilisateur.
3. Les modifications apportées à un fournisseur d’authentification ECS peuvent prendre quelques minutes avant d’être prises en compte, et le fournisseur d’authentification corrigé est toujours en train de mettre à jour la connexion à AD ou LDAP.
4. Le paramètre AD de l’utilisateur « L’utilisateur doit changer le mot de passe à la prochaine connexion » est actif pour cet utilisateur. Notez qu’ECS ne peut pas modifier le mot de passe des utilisateurs de domaine sur le serveur AD ou LDAP, ce qui entraîne une erreur, car le serveur AD ou LDAP tente d’appliquer le paramètre. Modifiez le mot de passe sur une autre application ou décochez la case du paramètre. Il est également recommandé d’utiliser la version 3.6.2.0 ou une version supérieure pour résoudre ce problème, car ECS invite ensuite les utilisateurs à présenter la demande du serveur AD à "User must change password at next login."
5. L’utilisateur de type sAMAccountName n’a pas la valeur de domaine correcte qui est username@domain.
6. Vous avez peut-être défini la base de recherche sur :

"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. Est défini sur l’emplacement utilisateur exact et correct, CN=Administrator,CN=Users,DC=CAS,DC=EMC,DC=com et non CN=Users,DC=CAS,DC=EMC,DC=com 
2. Le mot de passe est correct.
3. L’utilisateur dispose de l’autorisation requise pour être l’utilisateur DN du gestionnaire.  

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'

Si un utilisateur a modifié le serveur LDAP, alors que le FQDN du nouveau serveur LDAP correspond au FQDN de l’ancien serveur LDAP.

Le certificat SSL LDAP actuel peut pointer vers l’ancien serveur LDAP. Par conséquent, le certificat SSL LDAP doit être remplacé par un certificat SSL LDAP mis à jour.

Message d’erreur possible :

 

Vérifiez que le certificat a été émis et assurez-vous que le FQDN correspond exactement à l’URL utilisée dans l’interface utilisateur ECS. Vous pouvez également consulter les correspondances de noms alternatifs de l’objet à partir du certificat :

Command :

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

Exemple :

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

 
Vérifiez votre certificat LDAPS sur les correspondances ECS. Si ce n’est pas le cas, un nouveau certificat correct peut être nécessaire pour ECS. 

Un utilisateur peut envisager d’ouvrir une demande de service auprès du support ECS pour obtenir de l’aide, le cas échéant.

---

 

1. Le champ Authentication Provider a-t-il été correctement renseigné par l’utilisateur ?
2. L’utilisateur de gestion a-t-il été créé ?
3. L’utilisateur et le mot de passe de test ont-ils été saisis correctement lors de la connexion ECS ?
4. Peuvent-ils se connecter avec d’autres utilisateurs à partir d’un domaine ?
5. Est-ce la première fois qu’AD ou LDAP est configuré sur ECS ?
6. Si aucune nouvelle configuration AD ou LDAP n’a été configurée sur ECS, a-t-il déjà été en mesure de se connecter avec ces informations d’identification ? Dans l’affirmative, indiquez s’il y a eu des changements qui auraient une incidence sur l’autorisation.