Planification des noms de serveurs et d'utilisateurs sur un site Domino®
Lors de l'installation et de l'intégration de Domino et de sa gamme de produits de collaboration, vous devez décider d'un système de dénomination des serveurs, prévoir et créer plusieurs serveurs d'administration importants et créer des mots de passe pour ces utilisateurs. Familiarisez-vous avec les noms de serveurs et un tableau d'identités que vous pouvez utiliser lors de l'installation et de la configuration des serveurs, avec des recommandations concernant les noms qui doivent coïncider pour obtenir de meilleures performances.
A propos des noms de serveurs
Lorsque votre site de portail comprend plusieurs serveurs IBM® Domino®, leurs noms doivent être relativement courts et ne pas contenir d'espaces. Les noms de serveurs seront visibles pour les utilisateurs, il faut donc qu'ils soient les plus descriptifs possibles. Si le nom du serveur Domino® est différent de celui du serveur physique, vous devez vous assurer qu'il est identifiable via DNS. Par exemple, vous pouvez nommer un serveur concentrateur à Chicago acmehub, lequel, combiné au nom de domaine du serveur, donnera le nom d'hôte complet : acmehub.chicago.acme.com. Il convient de configurer une entrée dans DNS pour acmehub.chicago.acme.com afin de pointer vers l'adresse IP physique du serveur. Il n'est pas obligatoire que le nom du serveur Domino® soit identique à celui du serveur physique, mais si ce n'est pas le cas, des documents de connexion serveur sont nécessaires sur tous les autres serveurs Domino®, ainsi que dans le logiciel Lotus Notes ou client Domino® Administrator qu'ils exécutent.
Tableau des identités d'utilisateur
Certains noms du tableau suivant sont spécifiés lors de la procédure de configuration du serveur Domino® que vous effectuez après l'installation initiale du serveur Domino® LDAP. Si vous effectuez ultérieurement une installation de mise à niveau, les options de configuration seront reprises d'après la première installation du serveur. Vous ne reverrez donc pas les écrans présentant ces options.
| Identité | Description | Recommandation |
|---|---|---|
| Nom d'entreprise du serveur LDAP Domino® | Ce nom est spécifié lors de la procédure de configuration du serveur Domino®. | Voir A propos des noms de serveurs. Exemple : |
| Administrateur du serveur LDAP Domino® | Cette identité d'administrateur est définie lors de la procédure de configuration du serveur Domino®. | Conseil : Pour des raisons pratiques, vous pouvez le faire correspondre au nom d'utilisateur d'un administrateur dans HCL (PortalAdminId dans le fichier wkplc.properties) Exemple : wpsadmin |
| Utilisateur de liaison OU administrateur IBM® WebSphere® Application Server OU les deux | HCL Digital Experience utilise cette identité pour accéder à l'annuaire LDAP. A la fois l'annuaire LDAP et la configuration de la sécurité de HCL impliquent de modifier les valeurs du fichier Cette identité d'utilisateur est définie durant la configuration du serveur. |
Doit être identique à l'ID utilisateur d'un administrateur pour le WebSphere® Application Server (WasUserID dans le fichier wkplc.properties) Exemple : wpsbindPour plus d'informations sur la création d'un utilisateur de liaison ou d'un administrateur, utilisez la fonction de recherche pour identifier la rubrique sur la préparation d'un serveur Domino Directory sur <platform> (par exemple, Préparation d'un serveur Domino Directory sur Windows™). |
| Groupe d'administrateurs HCL | Editez manuellement le groupe wpsadmins et remplacez-le par wpsadmins/yourorgname. Cette édition créer le nom LDAP distinctif complet cn=wpsadmins/o=yourorgname. Cette modification doit être apportée lors de l'utilisation d'un annuaire LDAP Domino®, car Domino® ne stocke pas les groupes dans le format hiérarchique attendu par HCL . |
Doit correspondre au nom du groupe des administrateurs représentant tous les administrateurs du serveur HCL (PortalAdminGroupId dans le fichier wkplc.properties) Exemple :wpsadmins/renovationscorpRemarque : Dans la liste de contrôle d'accès de l'annuaire Domino®, ce groupe doit disposer de l'accès Auteur ou Editeur et ses types de rôles correspondants. Ces paramètres autorisent le groupe des administrateurs à écrire dans les documents personnels et à les modifier dans l'annuaire Domino® ; ces tâches sont nécessaires dans un portail qui a recours à la gestion des abonnés. |
| Administration du serveur Sametime | Ce nom d'utilisateur dispose d'un accès d'administrateur au serveur Sametime et est autorisé à modifier les pages Web du serveur. | Exemple : stAdmin |
| Administrateur Conférences Web Sametime | Le nom d'utilisateur est créé dans le répertoire Domino® (names.nsf) sur le serveur de Conférences Web Sametime et il est utilisé uniquement pour l'intégration de Sametime. Remarque : Dans la liste de contrôle d'accès de la base de données STConfig.nsf, ce nom d'utilisateur correspond au titre Person/Manager et dispose au minimum de rôles équivalents à ceux définis pour l'entrée du servlet de l'API de réunion dans le fichier servlets.properties du serveur Domino®. |
Exemple : st_webconf_adminRecommandation : Au moins le rôle [SametimeAdmin] |