7.2 Préparation de l'installation du coffre-fort d'identité

L'environnement d'installation du coffre-fort d'identité doit être configuré correctement. Par exemple, le serveur doit disposer d'une méthode (un service ou un fichier spécifié) pouvant être utilisée pour résoudre les noms d'arborescence du coffre-fort d'identité en adresses de renvoi du serveur. Cette section vous explique comment préparer votre environnement avant d'installer le coffre-fort d'identité.

7.2.1 Utilisation de caractères d'échappement lorsque le nom d'un conteneur comprend un point (« . »)

Vous pouvez ajouter à une arborescence d'annuaire un serveur Windows dont le nom contient un point, par exemple, O=netiq.com ou C=u.s.a. Toutefois, si les noms de vos conteneurs dans l'arborescence comportent un point (« . »), vous devez utiliser des caractères d'échappement. Passez en revue les considérations suivantes :

  • N'utilisez pas de point au début d'un nom de serveur, par exemple, .netiq.

  • Insérez une barre oblique inverse (« \ ») avant le point dans le nom du conteneur. Par exemple :

    O=novell\.com

    ou

    C=a\.b\.c

Insérez des caractères d'échappement lorsque vous entrez un nom et un contexte d'administrateur contenant des points pour des utilitaires tels qu'iMonitor, iManager, DHost iConsole, DSRepair, Backup, DSMerge, DSLogin et ldapconfig. Par exemple, lorsque vous vous connectez à iMonitor, si le nom du conteneur Organisation dans votre arborescence est netiq.com, entrez 'admin.netiq\.com' ou admin.netiq\.com.

7.2.2 Utilisation d'OpenSLP ou d'un fichier hosts.nds pour résoudre les noms d'arborescence

Avant d'installer l'infrastructure de coffre-fort d'identité, assurez-vous que le serveur dispose d'une méthode (un service ou un fichier spécifié) pouvant être utilisée pour résoudre les noms d'arborescence du coffre-fort d'identité en adresses de renvoi du serveur. NetIQ recommande l'utilisation des services SLP (Service Location Protocol) pour résoudre les noms d'arborescence. Dans les versions précédentes d'eDirectory, OpenSLP était installé automatiquement. Toutefois, à partir de la version 8.8, OpenSLP n'est plus installé automatiquement lors de l'installation d'eDirectory. Vous devez installer séparément un service SLP ou utiliser un fichier hosts.nds. Si vous utilisez un service SLP, les agents d'annuaire pour ce service (SLPDA) doivent être stables.

Cette section contient les informations suivantes :

Utilisation d'un fichier hosts.nds pour résoudre les noms d'arborescence

Le fichier hosts.nds est une table de recherche statique utilisée par les applications de coffre-fort d'identité pour rechercher des partitions et des serveurs de coffre-fort d'identité. Il vous permet d'éviter les délais de multidiffusion SLP lorsqu'aucun SLPDA n'est présent sur le réseau. Pour chaque arborescence ou serveur, vous devez spécifier les informations suivantes dans une seule ligne du fichier hosts.nds :

  • Nom du serveur ou nom de l'arborescence : les noms d'arborescence doivent se terminer par un point final (.).

  • Adresse Internet : il peut s'agir d'un nom DNS ou d'une adresse IP. N'utilisez pas localhost.

  • Port du serveur : facultatif, ajouté à l'adresse Internet à l'aide du signe deux-points (:).

Il n'est pas nécessaire d'inclure une entrée pour le serveur local dans le fichier, sauf si le serveur n'écoute pas sur un port NCP par défaut.

Pour configurer un fichier hosts.nds :

  1. Créez ou ouvrez un fichier hosts.nds.

  2. Ajoutez les informations suivantes :

                      partition_name.tree_name. host_name/ip-addr:port server_name dns-addr/ip-addr:port
                    

    Par exemple :

    # This is an example of a hosts.nds file:
    # Tree name Internet address/DNS Resolvable Name
      CORPORATE. myserver.mycompany.com
      novell.CORPORATE. 1.2.3.4:524
    
    # Server name Internet address
      CORPSERVER myserver.mycompany.com:524
  3. (Facultatif) Si vous décidez par la suite d'utiliser SLP pour résoudre le nom d'arborescence et garantir la disponibilité de l'arborescence du coffre-fort d'identité sur le réseau, ajoutez le texte suivant au fichier hosts.nds :

    /usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==[treename or *])"

    Par exemple, pour rechercher les services dont l'attribut svcname-ws correspond à la valeur SAMPLE_TREE, entrez la commande suivante :

    /usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==SAMPLE_TREE)"

    REMARQUE :effectuez cette opération après avoir installé SLP et le coffre-fort d'identité.

    Si vous disposez d'un service dont l'attribut svcname-ws a pour valeur SAMPLE_TREE, vous obtenez un résultat similaire à servicndap.novell:///SAMPLE_TREE. Sinon, la recherche ne renvoie aucun résultat.

Présentation d'OpenSLP

OpenSLP est une mise en œuvre Open Source de la norme IETF Service Location Protocol version 2.0, documentée dans la RFC (Request for Comments) 2608 de l'IETF.

L'interface fournie par le code source OpenSLP est une mise en œuvre d'une autre norme de l'IETF concernant l'accès par programme à la fonctionnalité SLP, documentée dans la RFC 2614.

Pour comprendre parfaitement les travaux de SLP, il est important de lire ces documents et de les assimiler. Leur lecture peut s'avérer laborieuse, mais ils sont essentiels pour procéder à une configuration correcte de SLP sur un intranet.

Pour plus d'informations sur le projet OpenSLP, reportez-vous aux sites Web d'OpenSLP et de SourceForge. Le site Web d'OpenSLP propose plusieurs documents qui offrent de précieux conseils de configuration. La plupart de ces documents sont encore incomplets à la date de publication de la présente documentation.

Cette section inclut les rubriques suivantes sur l'utilisation de SLP et sa relation avec le coffre-fort d'identité :

Protocole SLP NetIQ

La version NetIQ de SLP prend certaines libertés vis-à-vis de la norme SLP afin de fournir un environnement d'annonce de service renforcé, mais au prix d'une certaine évolutivité.

Par exemple, pour améliorer l'évolutivité d'une structure d'annonce de service, vous pouvez limiter le nombre de paquets diffusés ou multidiffusés sur un sous-réseau. La norme SLP gère ce facteur en imposant des limitations aux agents Service et Utilisateur concernant les requêtes à l'agent Annuaire. Le premier agent Annuaire identifié qui dessert l'étendue souhaitée est celui qu'un agent de service (et par conséquent des agents Utilisateur locaux) utilisera pour toutes les requêtes futures sur cette étendue.

La mise en œuvre de NetIQ SLP permet d'analyser tous les agents Annuaire connus, à la recherche des informations de la requête. Un acheminement AR de 300 millisecondes étant considéré comme trop long, 10 serveurs peuvent être analysés en 3 à 5 secondes. Il n'est pas nécessaire d'effectuer cette opération si SLP est configuré correctement sur le réseau et que OpenSLP considère le réseau comme configuré correctement pour le trafic SLP. Les valeurs de timeout de réponse de OpenSLP sont supérieures à celles du fournisseur de services SLP de NetIQ et cela limite le nombre d'agents Annuaire au premier qui répond, que les informations de celui-ci soient ou non précises et complètes.

Agents Utilisateur

Un agent Utilisateur prend la forme physique d'une bibliothèque statique ou dynamique liée à une application. Il permet à l'application d'émettre des requêtes de services SLP. La fonction de l'agent Utilisateur est de fournir une interface par programmation aux clients pour leurs requêtes de services, et aux services pour leur permettre de publier leurs annonces. Un agent Utilisateur contacte un agent Annuaire pour interroger des services enregistrés d'une classe de service et d'une étendue spécifiées.

Les agents Utilisateur suivent un algorithme pour obtenir l'adresse d'un agent Annuaire auquel les requêtes seront envoyées. Une fois qu'ils ont obtenu l'adresse d'un agent Annuaire sur une étendue spécifiée, ils continuent à utiliser cette adresse pour cette étendue jusqu'à ce qu'elle ne réponde plus. Là, ils se procurent l'adresse d'un autre agent Annuaire pour l'étendue. Les agents Utilisateur localisent l'adresse d'un agent Annuaire sur une étendue spécifiée en :

  1. vérifiant si l'identificateur de socket de la requête en cours est connecté à un agent Annuaire pour l'étendue indiquée ; s'il se trouve que la requête fait partie d'une requête en plusieurs parties, elle peut déjà contenir une connexion en cache ;

  2. recherchant dans le cache de l'agent Annuaire connu un agent Annuaire correspondant à l'étendue indiquée ;

  3. recherchant auprès de l'agent Service local un agent Annuaire de l'étendue spécifiée (et en ajoutant de nouvelles adresses au cache) ;

  4. interrogeant DHCP pour obtenir des adresses d'agents Annuaire configurées pour le réseau et correspondant à l'étendue indiquée (et en ajoutant de nouvelles adresses au cache) ;

  5. envoyant une requête d'identification d'agent Annuaire par multidiffusion sur un port connu (et en ajoutant de nouvelles adresses au cache).

L'étendue indiquée est celle « par défaut », sauf spécification contraire. Cela signifie que si aucune étendue n'est définie de façon statique dans le fichier de configuration SLP et qu'aucune étendue n'est indiquée dans la requête, l'étendue utilisée est le mot « default ». Notez également que le coffre-fort d'identité n'indique jamais d'étendue dans ses enregistrements. S'il existe une étendue configurée statiquement, celle-ci devient l'étendue par défaut pour les requêtes de l'agent Utilisateur local et les enregistrements de l'agent Service en l'absence d'une étendue spécifiée.

Agents Service

Les agents de service prennent la forme physique d'un processus distinct exécuté sur l'ordinateur hôte. Le fichier slpd.exe s'exécute en tant que service sur la machine locale. Des agents utilisateur interrogent l'agent de service local en envoyant des messages à l'adresse de bouclage sur un port connu.

La fonction de l'agent Service consiste à fournir des points de stockage et de maintenance persistants pour des services locaux s'étant enregistrés auprès de SLP. L'agent de service a pour tâche principale de gérer une base de données en mémoire des services locaux enregistrés. En fait, un service ne peut pas s'enregistrer auprès de SLP tant qu'un agent de service local n'est pas présent. Les clients peuvent identifier les services au moyen d'une seule bibliothèque d'agent Utilisateur, mais l'enregistrement nécessite obligatoirement un agent de service (SA), principalement parce que cet agent doit régulièrement vérifier l'existence de services enregistrés pour maintenir l'enregistrement des agents Annuaire à l'écoute.

Un agent de service localise et met en cache les agents Annuaire et la liste de l'étendue qu'ils prennent en charge en envoyant directement une requête d'identification d'agent Annuaire à des adresses d'agent Annuaire potentielles en :

  1. vérifiant toutes les adresses d'agent Annuaire configurées statiquement (et en ajoutant de nouvelles au cache d'agent Annuaire connu de l'agent de service) ;

  2. demandant la liste des agents Annuaire et des étendues à DHCP (et en en ajoutant de nouveaux au cache d'agent Annuaire connu de l'agent de service) ;

  3. envoyant une requête d'identification d'agent Annuaire par multidiffusion sur un port connu (et en en ajoutant de nouvelles au cache d'agent Annuaire connu de l'agent de service) ;

  4. recevant les paquets d'annonce régulièrement diffusés par les agents Annuaire (et en ajoutant les nouveaux au cache d'agent Annuaire connu de l'agent de service).

Le fait qu'un agent Utilisateur interroge toujours l'agent Service local en premier lieu revêt toute son importance, car la réponse de l'agent Service local détermine si l'agent Utilisateur passe ou non à l'étape suivante de la découverte (en l'occurrence, DHCP-- reportez-vous à l'Étape 3 et l'Étape 4 de la section Agents Utilisateur).

Agents Annuaire

Le fonction de l'agent Annuaire consiste à fournir un cache persistant à long terme pour les services annoncés, ainsi qu'un point d'accès permettant aux agents Utilisateur de rechercher des services. En tant que cache, l'agent Annuaire reste à l'écoute de l'annonce de nouveaux services par les agents de service et met en cache ces notifications. Le cache d'un agent Annuaire se complète ou se remplit rapidement. Les agents Annuaire utilisent un algorithme d'expiration pour faire expirer les entrées de cache. Lorsqu'un agent Annuaire s'active, il lit le cache du stockage persistant (en général un disque dur), puis commence à faire expirer les entrées selon l'algorithme. Lorsqu'un nouvel agent Annuaire arrive ou lorsqu'un cache a été supprimé, l'agent Annuaire détecte cette condition et envoie une notification spéciale à tous les agents Service à l'écoute pour qu'ils vident leurs bases de données locales, de manière à ce que l'agent Annuaire puisse rapidement créer son cache.

En l'absence d'agents Annuaire, l'agent Utilisateur effectue une requête de multidiffusion générale à laquelle les agents de service peuvent répondre listant ainsi les services demandés de la même manière que les agents Annuaire créent leur cache. La liste des services renvoyée par une telle requête est incomplète et bien plus localisée que celle fournie par un agent Annuaire, notamment en présence d'un filtrage multidiffusion mis en œuvre par un grand nombre d'administrateurs réseaux, lesquels limitent les diffusions et les multidiffusions au sous-réseau local seulement.

En bref, tout s'articule autour de l'agent Annuaire trouvé par un agent Utilisateur dans une étendue donnée.

Configuration de SLP pour le coffre-fort d'identité

Les paramètres suivants du fichier %systemroot%/slp.conf contrôlent la découverte des agents Annuaire :

net.slp.useScopes = comma-delimited scope list
net.slp.DAAddresses = comma-delimited address list
net.slp.passiveDADetection = <"true" or "false">
net.slp.activeDADetection = <"true" or "false">
net.slp.DAActiveDiscoveryInterval = <0, 1, or a number of seconds>
useScopes

Ce paramètre indique à quelles étendues l'agent Service va s'annoncer et à quelles étendues les requêtes seront adressées en l'absence d'une étendue spécifique lors de l'enregistrement ou de la requête effectuée par le service ou l'application client. Comme le coffre-fort d'identité émet toujours ses annonces et ses requêtes sur l'étendue par défaut, cette liste sera considérée comme la liste d'étendues par défaut pour l'ensemble des enregistrements et des requêtes du coffre-fort d'identité.

DAAddresses

Ce paramètre représente une liste d'adresses IP décimales avec points, séparées par une virgule, d'agents Annuaire qui doivent être préférés à tous les autres. Si cette liste des agents Annuaire configurés ne prend pas en charge l'étendue d'un enregistrement ou d'une requête, les agents Service et Utilisateur font alors appel à la découverte multidiffusion des agents Annuaire, sauf si cette fonction a été désactivée.

passiveDADetection

Par défaut, ce paramètre est défini sur True. Les agents Annuaire annoncent régulièrement leur existence sur le sous-réseau au moyen d'un port connu si celui-ci est configuré à cet effet. Ils s'intitulent paquets DAAdvert. Si cette option est définie sur False, tous les paquets DAAdvert diffusés sont ignorés par l'agent Service.

activeDADetection

Par défaut, ce paramètre est défini sur True. Elle permet à l'agent de service de diffuser régulièrement une requête à tous les agents Annuaire pour qu'ils répondent au moyen d'un paquet DAAdvert dirigé. Un paquet dirigé n'est pas diffusé, mais envoyé directement à l'agent de service en réponse à ces requêtes. Si cette option est définie sur False, aucune requête régulière de découverte d'agents Annuaire n'est diffusée par l'agent Service.

DAActiveDirectoryInterval

Représente un paramètre à trois états. La valeur par défaut est 1. Cela signifie que l'agent Service doit seulement envoyer une requête de découverte d'agents Annuaire lors de l'initialisation. Si vous définissez cette option sur la valeur 0, vous obtenez le même effet qu'en définissant l'option activeDADetection sur False. Toute autre valeur indique un nombre de secondes entre les diffusions de découverte.

Employées correctement, ces options assurent une utilisation appropriée de la bande passante du réseau pour l'annonce de services. En fait, les paramètres par défaut sont conçus pour optimiser l'évolutivité d'un réseau moyen.

7.2.3 Amélioration des performances du coffre-fort d'identité

eDirectory, l'infrastructure sous-jacente du coffre-fort d'identité, est une application qui consomme davantage d'E/S que de ressources processeur. Deux facteurs augmentent les performances du coffre-fort d'identité : une mémoire cache plus importante et des processeurs plus rapides. Pour obtenir des résultats optimaux, mettez en cache autant de paramètres de l'ensemble DIB (Directory Information Base, base de données des informations de l'Annuaire) que le permet le matériel.

Bien qu'eDirectory fonctionne correctement avec un seul processeur, vous pouvez envisager d'utiliser plusieurs processeurs. L'ajout de processeurs permet d'améliorer les performances dans des domaines tels que les connexions utilisateur. Le fait que plusieurs threads soient actifs sur plusieurs processeurs améliore également les performances.

Le tableau ci-dessous fournit des indications générales concernant les paramètres du serveur, en fonction du nombre d'objets de votre arborescence eDirectory.

Objets

Mémoire

Disque dur

100 000

384 Mo

144 Mo

1 million

4 Go

1,5 Go

10 millions

2 Go et plus

15 Go

Par exemple, une installation de base de eDirectory avec le schéma standard requiert environ 74 Mo d'espace disque pour chaque groupe de 50 000 utilisateurs. Cependant, si vous ajoutez un nouvel ensemble d'attributs ou si vous paramétrez tous les attributs existants, la taille de l'objet augmente. Ces ajouts affectent l'espace disque, le processeur et la mémoire nécessaires. Les exigences relatives aux processeurs dépendent également des services supplémentaires disponibles sur l'ordinateur, ainsi que du nombre d'authentifications, de lectures et d'écritures gérées par l'ordinateur. Certains processus, tels que le chiffrement et l'indexation, peuvent exiger d'importantes ressources processeur.

7.2.4 Utilisation d'adresses IPv6 sur le serveur du coffre-fort d'identité

Le coffre-fort d'identité prend en charge les adresses IPv4 et IPv6. Vous pouvez activer les adresses IPv6 lors de l'installation du coffre-fort d'identité. Si vous effectuez une mise à niveau à partir d'une version antérieure, vous devez activer manuellement les adresses IPv6.

Le coffre-fort d'identité prend également en charge les méthodes de transition de type « double pile IP », « tunnelage » et « pure IPv6 ». Seules les adresses IP globales sont prises en charge. Par exemple :

  • [::]

  • [::1]

  • [2015::12]

  • [2015::12]:524

Les adresses IPv6 doivent être spécifiées entre crochets [ ]. Pour utiliser un nom d'hôte au lieu d'une adresse IP, vous devez indiquer le nom dans le fichier C:\Windows\System32\drivers\etc\hosts et l'associer à l'adresse IPv6.

Pour utiliser des adresses IPv6 sur un serveur Windows, vous devez cocher la case Activer IPv6 sous Préférence IPv6 lors de l'installation. Cette option active les protocoles NCP, HTTP et HTTPS pour les adresses IPv6. Si vous n'activez pas les adresses IPv6 pendant la procédure d'installation et que vous décidez par la suite de les utiliser, vous devez réexécuter le programme d'installation. Pour plus d'informations, reportez-vous au Section 7.3, Installation du coffre-fort d'identité.

Vous pouvez accéder à iMonitor via des adresses IPv6 à l'aide du lien suivant :http://[2015::3]:8028/nds.

7.2.5 Utilisation du protocole LDAP pour communiquer avec le coffre-fort d'identité

Lors de l'installation du coffre-fort d'identité, vous devez spécifier les ports surveillés par le serveur LDAP pour qu'il puisse traiter les demandes LDAP. Dans le cadre de la configuration par défaut, les numéros de port pour texte clair et SSL/TLS sont définis sur 389 et 636.

Une liaison simple LDAP nécessite seulement un DN et un mot de passe. Le mot de passe se présente en texte clair. Si vous employez le port 389, l'ensemble du paquet est en texte clair. Dans la mesure où le port 389 autorise le texte clair, le serveur LDAP traite les demandes de lecture et d'écriture adressées à l'annuaire via ce port. Cette ouverture est adaptée aux environnements de confiance où aucune simulation n'a lieu et dans lesquels aucun utilisateur ne peut intercepter les paquets qui ne lui sont pas destinés. Par défaut, cette option est désactivée lors de l'installation.

La connexion via le port 636 est chiffrée. TLS (auparavant SSL) gère le chiffrement. La connexion au port 636 lance automatiquement une procédure de reconnaissance mutuelle. Si celle-ci échoue, la connexion est refusée.

REMARQUE :le programme d'installation sélectionne par défaut le port 636 pour les communications TLS/SSL. Cette configuration par défaut peut être problématique pour votre serveur LDAP. Si un service déjà chargé sur le serveur hôte (avant l'installation d'eDirectory) utilise le port 636, vous devez spécifier un autre port. Les installations antérieures à eDirectory 8.7 traitaient ce conflit comme une erreur fatale et déchargeaient nldap. Dans les versions ultérieures à 8.7.3, le programme d'installation charge nldap, place un message d'erreur dans le fichier dstrace.log et s'exécute sans le port sécurisé.

Lors de la procédure d'installation, vous pouvez configurer le coffre-fort d'identité pour interdire la transmission en clair de mots de passe et d'autres données. L'option Exiger TLS en cas de liaison simple avec mot de passe dissuade les utilisateurs d'envoyer des mots de passe lisibles. Si vous ne sélectionnez pas cette option, les utilisateurs ne savent pas que d'autres personnes peuvent voir leur mot de passe. Cette option, qui n'autorise pas la connexion, ne s'applique qu'au port non chiffré. Si vous établissez une connexion sécurisée avec le port 636 et disposez d'une liaison simple, la connexion est déjà codée. Personne ne peut voir les mots de passe, les paquets de données ou les demandes de liaison.

Prenons les scénarios suivants :

L'option Exiger TLS en cas de liaison simple avec mot de passe est activée

Olivia utilise un client qui demande un mot de passe. Une fois qu'elle a saisi le mot de passe, le client se connecte au serveur. Cependant, le serveur LDAP ne permet pas à la connexion d'établir la liaison avec le serveur via le port non codé. Tout le monde peut voir le mot de passe d'Olivia, mais cette dernière est dans l'impossibilité d'obtenir une connexion liée.

Le port 636 est déjà utilisé

Votre serveur exécute Active Directory. Active Directory s'exécute sur un programme LDAP qui utilise le port 636. Vous installez eDirectory. Le programme d'installation détecte alors que le port 636 est déjà utilisé et n'affecte pas de numéro de port au serveur LDAP NetIQ. Le serveur LDAP se charge et semble s'exécuter. Toutefois, comme le serveur LDAP ne peut pas dupliquer ni utiliser un port déjà ouvert, il ne traite pas les requêtes sur un port dupliqué.

Pour vérifier si le port 389 ou 636 est assigné au serveur LDAP NetIQ, exécutez l'utilitaire ICE. Si le champ Vendor Version (Version du fournisseur) n'indique pas NetIQ, vous devez reconfigurer le serveur LDAP pour eDirectory et sélectionner un port différent. Pour plus d'informations, reportez-vous à la section Verifying That the LDAP Server is Running (Vérification de l'exécution du serveur LDAP) du manuel NetIQ eDirectory  Administration Guide (Guide d'administration de NetIQ eDirectory 8.8 SP8).

Active Directory est en cours d'exécution

Lorsqu'Active Directory est en cours d'exécution et que le port 389 en texte clair est ouvert, vous pouvez exécuter la commande ICE sur ce port et demander la version du fournisseur. Le résultat affiché est Microsoft*. Vous reconfigurez alors le serveur NetIQ LDAP en sélectionnant un autre port, afin que le serveur LDAP eDirectory puisse répondre aux requêtes LDAP.

iMonitor peut également signaler si le port 389 ou 636 est déjà ouvert. Si le serveur LDAP ne fonctionne pas, utilisez iMonitor pour identifier les détails. Pour plus d'informations, reportez-vous à la section Verifying That the LDAP Server is Running (Vérification de l'exécution du serveur LDAP) du manuel NetIQ eDirectory  Administration Guide (Guide d'administration de NetIQ eDirectory 8.8 SP8).

7.2.6 Installation manuelle de NICI sur les postes de travail disposant d'utilitaires de gestion

Vous devez installer NICI sur tous les postes de travail qui utilisent un utilitaire de gestion tel qu'iManager. Pour plus d'informations sur l'utilisation de NICI avec le coffre-fort d'identité, reportez-vous à la section Conditions préalables à l'installation du coffre-fort d'identité.

Pour installer NICI, utilisez le fichier NICI_wx64.msi, qui se trouve par défaut dans le dossier products\eDirectory\type_processeur\windows\type_processeur\nici. Vous pouvez exécuter le fichier en tant que procédure guidée (assistant) ou qu'installation silencieuse.

7.2.7 Installation du logiciel NMAS Client

Vous devez installer le logiciel client NetIQ Modular Authentication Service (NMAS) sur tous les postes de travail clients sur lesquels vous souhaitez utiliser les méthodes de connexion NMAS. Les méthodes de connexion doivent être spécifiées lors de l'installation du coffre-fort d'identité.

  1. Connectez-vous au poste de travail client avec un compte d'administrateur.

  2. Exécutez le programme nmasinstall.exe à partir du répertoire d'installation (par défaut : Win:\products\eDirectory\type_processeur\nmas\).

  3. Cliquez sur NMAS Client Components (Composants de NMAS Client).

  4. (Facultatif) Sélectionnez l'option NICI pour installer le composant NICI.

  5. Cliquez sur OK.

  6. Une fois l'installation terminée, redémarrez le poste de travail client.