Gestion des utilisateurs
Gestion des utilisateurs
Les utilisateurs peuvent être créés manuellement ou automatiquement via l'authentification SAML 2. Pour démarrer le processus :
- Créer des dossiers utilisateurs : Commencez par créer des dossiers dans le module Utilisateurs pour organiser les utilisateurs. Cela nécessite un modèle d'utilisateur avec le code « admin ».
- Ajouter des utilisateurs : avec le modèle en place, vous pouvez commencer à ajouter des utilisateurs :
- Ouvrez la vue Autorisations à partir de l’interface utilisateur d’administration.
- Sélectionnez « Utilisateurs et rôles » dans le volet arborescence.
- Cliquez sur « Nouveau dossier » dans le menu d’affichage.
- Une fois que vous avez nommé le dossier, attribué des autorisations et enregistré le dossier, il apparaît dans le volet de l'arborescence Autorisations.
- Ensuite, ajoutez le modèle d’administrateur en tant que modèle autorisé, entrez un code pour le dossier et enregistrez à nouveau.

Création manuelle des utilisateurs
Pour créer manuellement un utilisateur :
- Accédez au dossier approprié.
- Sélectionnez « Nouvel utilisateur » pour ouvrir la vue Utilisateur effectif.
- Donnez un nom au nouvel utilisateur.
- Remplissez les informations requises (le cas échéant).
- Cliquez sur Enregistrer.

Les informations sur le nouvel utilisateur apparaissent dans la zone de contenu ESM et le nom du nouvel utilisateur apparaît sous le dossier actif dans le volet de l'arborescence des autorisations.
Gestion automatique des utilisateurs
La création, la mise à jour et la suppression automatiques d'utilisateurs peuvent être orchestrées grâce au Efecte Provisioning Engine (EPE) grâce à un nœud d'orchestration intégré aux workflows. Consultez la documentation EPE pour plus de détails.
Paramètres spécifiques à l'utilisateur
Les paramètres spécifiques à l'utilisateur permettent de personnaliser les méthodes d'authentification et les préférences d'interface, notamment la langue et le fuseau horaire. Ces paramètres sont propres à chaque utilisateur.
Cliquez sur Paramètres dans le menu d’affichage pour ouvrir la vue Paramètres utilisateur :

Paramètres de sécurité spécifiques à l'utilisateur
- Méthode d'authentification : choisissez entre l'authentification par identifiant/mot de passe ( autre ), basée sur LDAP AD ou SAML 2. Chaque méthode possède ses propres spécificités concernant la correspondance des identifiants utilisateur et l'attribution des rôles.
- a. Si une autre méthode d'authentification est sélectionnée, l'utilisateur ESM peut être authentifié soit localement avec l'ID utilisateur/mot de passe stocké dans la base de données, soit avec l'authentification NTSM avec l'ID utilisateur stocké dans la base de données ou avec l'ID utilisateur récupéré via l'interface LDAP.
- En règle générale, l'authentification LDAP utilise Windows Active Directory . Vous devez spécifier les paramètres LDAP (généralement les serveurs LDAP) dans la section « Paramètres de l'authentificateur enfichable » des paramètres de la plateforme (modifiables via Administration > Maintenance > Modifier les paramètres).
- REMARQUE ! Si l'authentification LDAP est utilisée, l'identifiant utilisateur effectif de l'utilisateur doit correspondre à un identifiant utilisateur existant dans le système LDAP et LDAP doit être ajouté comme première valeur du paramètre de plateforme auth.chain. Le paramètre LDAP spécifique à l'utilisateur configuré dans la vue Paramètres de sécurité spécifiques à l'utilisateur peut être remplacé par le paramètre de plateforme auth.chain.
- Si d'autres méthodes d'authentification (par exemple, base de données ou ntlm) sont répertoriées dans la valeur auth.chain avant LDAP, l'authentification sera d'abord tentée en les utilisant, quel que soit le paramètre dans la vue Paramètres de sécurité de l'utilisateur.
- Si LDAP est absent de la valeur auth.chain, l'authentification LDAP ne sera jamais tentée, quel que soit le paramètre défini dans la vue des paramètres de sécurité de l'utilisateur.
- Lorsque l’authentification SAML 2 est activée, les rôles d’un utilisateur ESM sont attribués en fonction des rôles identifiés dans les messages SAML 2.
- Lorsque l'authentification SAML 2 est utilisée, il n'est pas possible d'attribuer des rôles dans l'interface utilisateur d'administration ESM à un utilisateur manuellement, mais uniquement via le message SAML 2.
- REMARQUE ! Les identifiants externes identifiant les rôles doivent être mappés aux rôles ESM dans la vue de l'éditeur de rôles.
- ID utilisateur et mot de passe ESM : pour l’authentification locale, spécifiez l’ID utilisateur et le mot de passe.
- Notez que seul l'utilisateur root est autorisé à modifier les identifiants utilisateur.
- Niveau utilisateur ESM : les options incluent :
- Normal - Affichez, modifiez et supprimez des modèles, des dossiers et des cartes de données selon les autorisations du rôle utilisateur.
- Lecture seule : lisez les cartes de données selon les autorisations du rôle utilisateur.
- Root - droits illimités sur les données ESM et la maintenance des données, sans aucune restriction de rôle d'utilisateur.
- Utilisez le niveau d’utilisateur root avec précaution, car il est exceptionnellement puissant.
Paramètres du fuseau horaire de l'utilisateur
L'activation de multiple.timezone.support permet aux utilisateurs de définir leur fuseau horaire préféré, améliorant ainsi la convivialité globale d'ESM.

Méthode d'authentification
Vous pouvez choisir d'authentifier les utilisateurs en fonction de l'ID utilisateur/mot de passe (Autre), de l'authentification basée sur LDAP AD (LDAP) ou de l'authentification SAML 2 ( SAML 2).
Création automatique d'utilisateurs avec SAML 2
L'authentification SAML 2 facilite la création automatique d'utilisateurs à partir des informations d'attributs contenues dans les messages SAML 2, en attribuant les rôles et les niveaux d'utilisateur en conséquence. La gestion des utilisateurs (à l'exception des utilisateurs root) est ainsi transférée au fournisseur d'identité, comme Efecte Identity Management (EIM) ou Secure Access ( ESA ).
Notez qu'en cas d'utilisation de l'authentification SAML 2 pour l'utilisateur, la gestion des rôles doit être assurée par l'EIM ou ESA . Même si la méthode d'authentification est modifiée manuellement pour LDAP et que de nouveaux rôles sont ajoutés à l'utilisateur, l'authentification sera rétablie sur SAML 2.0 lors de la prochaine connexion si l'EIM ou ESA envoie les informations de niveau utilisateur.
Configuration de l'authentification basée sur SAML 2
Pour utiliser l’authentification basée sur SAML 2 :
- Ajustez la chaîne d’authentification dans les paramètres de la plateforme pour inclure SAML 2.
- Configurez le fournisseur d'identité pour envoyer les attributs requis par Shibboleth.
- §roles - liste des rôles sous forme de chaîne séparée par le caractère « ; ».
- esm_userLevel - valeurs possibles Root, Normal, Readonly, NoAccess.
- esm_email - Pour créer une personne, obligatoire.
- esm_firstName - Pour créer une personne, facultatif.
- esm_lastName - Pour créer une personne, facultatif.
- Mappez les rôles ESM à ceux identifiés via SAML 2 dans l'éditeur de rôles.

Mappage des rôles dans la vue de l'éditeur de rôles :

Configuration de l'authentification NTLM (sur site)
Applicable uniquement aux installations sur site, l’authentification NTLM permet aux utilisateurs de se connecter avec leurs informations d’identification Windows.
Remarque ! Ceci s'applique uniquement aux installations ESM sur site.
Si ESM est configuré pour utiliser l'authentification HTTP NTLM, les utilisateurs peuvent se connecter à ESM avec leurs identifiants Windows sans avoir à ressaisir leur nom d'utilisateur et leur mot de passe (une fois connectés à leur poste de travail Windows). L'authentification HTTP NTLM est un protocole de type « challenge/réponse » : le serveur envoie un défi au client (c'est-à-dire le navigateur), et le serveur et le client répondent via HTTP.
ESM prend en charge les protocoles NTLMv1 et NTLMv2. L'ancien protocole v1 n'est plus recommandé et ne fonctionne même pas avec les paramètres par défaut des postes de travail et serveurs Windows plus récents. ESM prend en charge l'ancienne version du protocole pour des raisons de rétrocompatibilité.
Avec le paramètre auth.sso.use.fully.qualified.account.name, ESM peut être configuré pour comparer le nom d'utilisateur Windows au nom d'utilisateur ESM en utilisant le nom de compte complet (DOMAINE\nom d'utilisateur). Cette configuration est compatible avec toutes les authentifications SSO : NTLMv1, NTLMv2 et Kerberos. Cela nécessite que les identifiants des utilisateurs ESM soient au format DOMAINE\nom d'utilisateur.
Comment utiliser l'authentification NTLM dans ESM :
- Les utilisateurs doivent avoir le même nom d’utilisateur dans le domaine Windows et ESM.
- NTLM doit être configuré comme l’une des méthodes d’authentification.
- Cela peut être réalisé en ajoutant la valeur « negotiate » ou « NTLM » (pour NTLMv1) au paramètre « auth.chain » (dans Administration > Maintenance > Modifier les paramètres ), par exemple : « auth.chain = negotiate, database ». Cet exemple de configuration active l'authentification NTLMv2 pour ESM et en fait la première méthode d'authentification testée.
Note:
Les valeurs de configuration les plus courantes sont base de données ; LDAP, base de données ; et négociation, LDAP, base de données. Si NTLM et négociation sont configurés simultanément, seule négociation sera utilisée.
Négocier (ou NTLM) doit être la première option de la liste si elle est utilisée. Sinon, 1) si la méthode de connexion principale réussit, l'authentification NTLM sera également effectuée, mais elle n'est jamais utilisée dans ESM ; ou 2) si la méthode de connexion principale échoue, la connexion semble réussir avec n'importe quel mot de passe, car l'authentification NTLM sera utilisée comme solution de secours, mais aucune notification ne s'affiche.
- Cela peut être réalisé en ajoutant la valeur « negotiate » ou « NTLM » (pour NTLMv1) au paramètre « auth.chain » (dans Administration > Maintenance > Modifier les paramètres ), par exemple : « auth.chain = negotiate, database ». Cet exemple de configuration active l'authentification NTLMv2 pour ESM et en fait la première méthode d'authentification testée.
- Pour NTLMv1 uniquement : les contrôleurs de domaine doivent être configurés. Par exemple, si les utilisateurs appartiennent à l'un des domaines VENTES et DÉVELOPPEMENT, les contrôleurs de domaine des deux domaines doivent être spécifiés. Pour ce faire, ajoutez les lignes suivantes aux paramètres de la plateforme :
- auth.ntlm.SALES.domaincontroller = salesdc.mycompany.com
- auth.ntlm.DEVEL.domaincontroller = develdc.mycompany.com
- La forme générale de ce paramètre est auth.ntlm.<nom NetBIOS du domaine>.domaincontroller.
- Veuillez noter que le nom NetBIOS n'est qu'une partie d'un nom de domaine complet. Par exemple, sales.mycompany.com est un nom de domaine complet et SALES est le nom NetBIOS du domaine.) La valeur du paramètre est un nom DNS, un nom de domaine complet ou une adresse IP du contrôleur de domaine du domaine concerné.
Note:
Il peut également y avoir plusieurs contrôleurs de domaine. Dans ce cas, le premier contrôleur de domaine est configuré comme auth.ntlm.DOMAIN.domaincontroller, et les suivants comme auth.ntlm.DOMAIN.domaincontroller.1 , auth.ntlm.DOMAIN.domaincontroller.2 , etc.
- Veuillez noter que le nom NetBIOS n'est qu'une partie d'un nom de domaine complet. Par exemple, sales.mycompany.com est un nom de domaine complet et SALES est le nom NetBIOS du domaine.) La valeur du paramètre est un nom DNS, un nom de domaine complet ou une adresse IP du contrôleur de domaine du domaine concerné.
Pour NTLMv1 uniquement : Notez que le paramètre auth.ntlm.defaultdomaincontroller doit également être configuré (il se trouve dans la section « Paramètres de l'authentificateur enfichable » des paramètres de la plateforme). La valeur de ce paramètre est un nom DNS, un nom de domaine complet ou l'adresse IP du contrôleur de domaine. Ce paramètre est utilisé si le navigateur n'envoie pas d'informations sur le domaine ou si celui-ci est inconnu. Le problème se pose lorsqu'un utilisateur IE provient d'un domaine inconnu. Si le contrôleur de domaine par défaut n'est pas configuré, IE considère que la négociation NTLM n'est pas terminée et n'envoie pas le nom d'utilisateur et le mot de passe du formulaire de connexion au serveur ESM. Autrement dit, l'authentification échoue systématiquement.
Prise en charge du navigateur pour l'authentification HTTP NTLM
Microsoft Internet Explorer négocie l'authentification HTTP NTLM de manière transparente. Une fois l'authentification HTTP NTLM négociée, Internet Explorer renégocie proactivement l'authentification NTLM pour les requêtes POST de tout le contenu associé au serveur. Cela signifie qu'Internet Explorer renégocie chaque fois qu'il doit envoyer des données POST à ESM (par exemple, lors de l'enregistrement d'une carte de données). Il est possible de modifier le comportement d'Internet Explorer, mais cela nécessite de modifier le registre Windows.
Pour que l’authentification NTLM fonctionne comme prévu, les paramètres de sécurité IE doivent être configurés de la manière suivante :
- L'URL ESM doit être configurée comme site de confiance dans IE (à partir d'Options Internet > Sécurité > Sites de confiance > Sites > Avancé ).
- L' option de connexion dans les paramètres de sécurité d'IE doit être définie sur « Connexion automatique uniquement dans la zone Intranet » ou « Connexion automatique avec le nom d'utilisateur et le mot de passe actuels » (dans Options Internet > Sécurité > Sites de confiance > Niveau personnalisé… ).
Paramètres de sécurité d'Internet Explorer pour l'authentification NTLM
Note:
Les connexions automatiques ne fonctionnent que lorsque ESM est exécuté sur un réseau local et que les utilisateurs ESM sont connectés directement à Windows, lequel est exécuté sur un domaine approuvé par ESM (plus précisément, sur le même domaine depuis lequel ESM effectue l'authentification NTLM). Si ESM doit être accessible depuis un réseau étendu (WAN), l'authentification NTLM ne doit pas être utilisée.
Mozilla et les navigateurs basés sur Mozilla, comme Firefox, prennent en charge l'authentification HTTP NTLM, mais demandent systématiquement à l'utilisateur ses identifiants. Il est toutefois possible de configurer les navigateurs basés sur Mozilla pour une négociation NTLM transparente :
- Démarrez le navigateur.
- Écrivez à propos de : config dans la barre d'adresse.
- Modifiez la préférence network.automatic-ntlm-auth.trusted-uris : la valeur de cette préférence est une liste de préfixes d'URL ou de domaines, séparés par des virgules. Ajoutez le préfixe d'URL de votre serveur ESM, par exemple : http://efecteserver .
Cette modification peut également être effectuée sur un fichier de configuration Mozilla pour un déploiement plus facile.
Note:
L'authentification HTTP NTLM ne doit être utilisée qu'avec les serveurs d'une zone intranet, car les hachages de mots de passe NTLM sont facilement piratés par des attaques par force brute par dictionnaire. Si NTLM est utilisé sur des connexions réseau non sécurisées, des communications sécurisées peuvent être établies via SSL (HTTPS).
L'authentification NTLM échouera probablement en présence d'un pare-feu entre le serveur ESM et le contrôleur de domaine. Les pare-feu bloquent généralement les messages SMB.
Configuration de l'authentification Kerberos (sur site uniquement)
Pour une prise en charge client optimale et une sécurité optimale, l'authentification Kerberos peut être utilisée. L'inconvénient de Kerberos est que, bien qu'il s'agisse de l'option d'authentification la plus sûre, elle est aussi la plus difficile à mettre en œuvre. Dans la plupart des cas où il n'y a que des postes de travail Windows, NTLMv2 devrait être largement suffisant et beaucoup plus facile à mettre en œuvre.
Avec le paramètre auth.sso.use.fully.qualified.account.name, ESM peut être configuré pour comparer le nom d'utilisateur Windows au nom d'utilisateur ESM en utilisant le nom de compte complet (DOMAINE\nom d'utilisateur). Cette configuration est compatible avec toutes les authentifications SSO : NTLMv1, NTLMv2 et Kerberos. Cela nécessite que les identifiants des utilisateurs ESM soient au format DOMAINE\nom d'utilisateur.
Comment configurer l'authentification Kerberos dans ESM
- Les utilisateurs doivent avoir le même nom d’utilisateur dans le domaine Windows et ESM.
- La négociation doit être configurée comme l'une des méthodes d'authentification. Pour ce faire, ajoutez la valeur « negotiate » au paramètre « auth.chain » (dans Maintenance > Modifier les paramètres) ; par exemple, « auth.chain = negotiate » , « base de données ». Cet exemple de configuration active l'authentification Kerberos par négociation pour ESM et en fait la première méthode d'authentification testée.
- Modifiez la valeur du paramètre de plateforme « negotiate.protocol » sur « Négocier ». Veuillez noter que les modifications apportées à ce paramètre ne prendront effet qu'au redémarrage du service ESM.
Si vous souhaitez exécuter le service ESM avec un autre utilisateur que le système local, vous devez désactiver la pré-authentification Kerberos pour cet utilisateur dans Active Directory et créer un nom principal de service (SPN) correspondant au serveur sur lequel ESM est exécuté. Voici un exemple de SPN : HTTP/efecteserver.domain.com.
La configuration du navigateur pour l'authentification Kerberos est identique à celle de NTLM dans Internet Explorer. Dans Firefox, le paramètre où le serveur ESM doit être ajouté est network.negotiate-auth.trusted-uris.
Authentification LDAP avec plusieurs domaines (sur site uniquement)
L'authentification à partir de plusieurs domaines peut être activée en définissant la valeur du paramètre de plate-forme auth.ldap.multidomain.enabled sur true.
Les URL LDAP doivent être spécifiées via le paramètre auth.ldap.host.uri.DOMAIN , où le mot DOMAIN doit être remplacé par le nom réel du domaine. Ce paramètre peut contenir plusieurs valeurs, séparées par une virgule. Exemple : auth.ldap.host.uri.SALES=ldap://dc1:3268,ldap://dc2:3268
Tous les contrôleurs de domaine utilisés ici doivent activer le catalogue global (GC) (port par défaut : 3268). GC est nécessaire car aucun nom de domaine de base n'est défini pour les domaines et seul GC permet les recherches sans lui. Les utilisateurs se connectant à ESM doivent indiquer leur nom d'utilisateur au format DOMAINE\nom_utilisateur.
Authentificateur de servlet
L'authentification des servlets peut être configurée via des paramètres de plate-forme spécifiques, permettant le contrôle de connexion basé sur les groupes Active Directory et la création automatique de comptes d'utilisateurs dans ESM basée sur l'authentification des servlets.
- servlet.auth.admin.ad.group : nom du groupe AD permettant aux administrateurs de se connecter à ESM. Plusieurs groupes sont pris en charge. Les valeurs doivent être séparées par des virgules.
- servlet.auth.create.users : si le compte utilisateur n'existe pas déjà, il sera créé. La valeur par défaut est « true ».
- servlet.auth.person.groups.attribute.code - Code d'attribut de groupe sur « modèle de personne » qui contient une référence au modèle « Groupe Active Directory ».
- servlet.auth.person.template.code - Code de modèle contenant des informations personnelles.
- uid - Code d'attribut de groupe sur « modèle de personne » qui contient une chaîne pour l'ID utilisateur dans Active Directory .
- servlet.auth.person.user.attribute.code - Code d'attribut de groupe sur « modèle de personne » qui contient une référence au modèle d'utilisateur effectif.
- servlet.auth.user.ad.group : nom du groupe AD permettant aux utilisateurs normaux de se connecter à ESM. Plusieurs groupes sont pris en charge. Les valeurs doivent être séparées par des virgules.
- servlet.auth.user.folder.code - Code de dossier d'un dossier d'arborescence d'autorisations dans lequel un nouvel utilisateur sera créé.
- servlet.auth.user.name.attribute.code - Code d'attribut de groupe sur le modèle « Utilisateur » qui contient une chaîne pour le nom d'utilisateur.
- servlet.auth.user.person.attribute.code - Code d'attribut de groupe sur le modèle « Utilisateur » qui contient une référence au modèle Personne.
- servlet.auth.user.readonly.roles - Nom du rôle d'administrateur, qui sera attribué aux utilisateurs reconnus comme utilisateurs en lecture seule.
- Ceux-ci n'appartiennent pas à « servlet.auth.user.ad.group » ou « servlet.auth.admin.ad.group ».
- Si ce paramètre est vide, les utilisateurs qui n'appartiennent à aucun de ces rôles ne peuvent pas se connecter.
- Ceux-ci n'appartiennent pas à « servlet.auth.user.ad.group » ou « servlet.auth.admin.ad.group ».
- servlet.auth.user.roles – Nom du rôle administrateur attribué aux utilisateurs reconnus comme utilisateurs normaux. Voir « servlet.auth.user.ad.group ».