Installation d'un réplicas d'Identity Management

Les répliques sont créées en clonant la configuration des serveurs Identity Management existants. Par conséquent, les serveurs et leurs répliques partagent une configuration de base identique. Le processus d'installation du réplica copie la configuration du serveur existant et installe la réplique en fonction de cette configuration.

La maintenance de plusieurs réplicas de serveur est une solution de sauvegarde recommandée pour éviter la perte de données.

Les répliques sont créées en tant que clones des serveurs maîtres initiaux. Une fois le réplica créé, il est fonctionnellement identique au serveur maître: les serveurs et les réplicas créés à partir de ces serveurs partagent les mêmes informations internes sur les utilisateurs, les machines, les certificats et les stratégies configurées.

La réplication est le processus de copie des données entre les réplicas. Les informations entre les réplicas sont partagées à l'aide de la réplication multi-maître: toutes les répliques jointes via un accord de réplication reçoivent des mises à jour et sont donc considérées comme des maîtres de données.

Les serveurs IdM peuvent exécuter un certain nombre de services, tels qu'une autorité de certification (CA) ou un DNS. Un réplica peut exécuter les mêmes services que le serveur à partir duquel il a été créé, mais cela n'est pas nécessaire.

Par exemple, vous pouvez installer une réplique sans services DNS, même si le serveur initial exécute DNS. De même, vous pouvez configurer une réplique en tant que serveur DNS même si le serveur initial a été installé sans DNS.

Si vous configurez une réplique sans autorité de certification, toutes les demandes d'opérations de certificat seront transmises au serveur CA de votre topologie.

Si vous configurez une autorité de certification sur le réplica, sa configuration doit refléter la configuration de l'autorité de certification du serveur initial.

Red Hat recommande de suivre les consignes suivantes:

Ne configuré pas plus de 60 réplicas dans un seul domaine IdM Red Hat garantit une prise en charge des environnements avec 60 répliques ou moins.

Configurer au moins deux, mais pas plus de quatre accords de réplication pour chaque réplica La configuration d'un réplicat supplémentaires garantit que les informations sont répliquées non seulement entre le réplica initial et le serveur maître, mais également entre les autres répliques.

• Si vous créez une réplique B à partir du serveur A puis de la réplique C du serveur A, les répliques B et C ne sont pas directement jointes. Par conséquent, les données du réplicat B doivent d'abord être répliquées sur le serveur A.

La configuration d'un réplicat supplémentaire entre le réplica B et le réplica C garantit la réplication directe des données, ce qui améliore la disponibilité, la cohérence, la tolérance de basculement et les performances des données.

La configuration de plus de quatre accords de réplication par réplica est inutile. Un grand nombre d'accords de réplication par serveur n'apporte pas d'avantages significatifs, car un serveur grand public ne peut être mis à jour que par un maître à la fois. Les autres accords sont donc inactifs et en attente. De plus, la configuration d'un trop grand nombre d'accords de réplication peut avoir un impact négatif sur les performances globales.

L'une des topologies les plus résistantes consiste à créer une configuration de cellule pour les serveurs et les réplicas avec un petit nombre de serveurs dans une cellule:

• Chacune des cellules est une cellule étroite, où tous les serveurs ont des accords de réplication les uns avec les autres.
• Chaque serveur dispose d'un accord de réplication avec un autre serveur en dehors de la cellule. Cela garantit que chaque cellule est faiblement couplée à toutes les autres cellules du domaine.

Pour accomplir une topologie cellulaire serrée:

• Avoir au moins un serveur IdM dans chaque bureau principal, centre de données ou localité. De préférence, avoir deux serveurs IdM.
• Ne pas avoir plus de quatre serveurs par centre de données.
• Dans les petites entreprises, plutôt que d'utiliser une réplique, utilisez SSSD pour mettre en cache les informations d'identification et un serveur IdM hors site en tant que back-end de données.

Les exigences d'installation pour les réplicas sont les mêmes que pour les serveurs IdM.

Assurez-vous que l'ordinateur de réplication remplit toutes les conditions préalables répertoriées dans la Section, «Prérequis à l'installation d'un serveur».

Outre les exigences générales du serveur, vous devez également respecter les conditions suivantes:

Le réplica doit exécuter la même version ou une version ultérieure d'IdM Par exemple, si le serveur maître s'exécute sur Red Hat Enterprise Linux 7 et utilise les packages IdM 4.4, la réplique doit également être exécutée sur Red Hat Enterprise Linux 7 ou version ultérieure et utiliser IdM version 4.4 ou ultérieure. Cela garantit que la configuration peut être correctement copiée du serveur vers la réplique.

La réplique a besoin de ports supplémentaires pour être ouverte Outre les exigences de port de serveur IdM standard décrites à la Section, «Exigences de port», assurez-vous de respecter également les points suivants:

• Au niveau du domaine 0, laissez le port TCP 22 ouvert pendant le processus de configuration du réplica. Ce port est requis pour utiliser SSH et se connecter au serveur maître.
• Si l'un des serveurs exécute Red Hat Enterprise Linux 6 et dispose d'une autorité de certification, conservez également le port TCP 7389 ouvert pendant et après la configuration du réplica. Dans un environnement purement Red Hat Enterprise Linux 7, le port 7389 n'est pas requis.

Les exigences de package d'un réplicat sont les mêmes que celles du package de serveur. Voir Section, «Packages requis pour installer un serveur IdM».

L'utilitaire “ipa-replica-install” permet d'installer une nouvelle réplique à partir d'un serveur IdM existant.

Vous pouvez installer une nouvelle réplique:

• sur un client IdM existant en faisant partie du domaine IdM
• sur une machine qui n'a pas encore été inscrite dans le domaine IdM

Dans cette procédure, un client IdM existant est promu répliquat en utilisant son propre keytab d'hôte pour autoriser la promotion.

La procédure ne vous oblige pas à fournir les informations d'identification de l'administrateur ou du Directory Manager (DM). Il est donc plus sécurisé car aucune information sensible n'est exposée sur la ligne de commande.

Sur un serveur existant:

Connectez-vous en tant qu'administrateur.

$ kinit admin

Ajoutez la machine cliente au groupe hôte ipaservers.

$ ipa hostgroup-add-member ipaservers --hosts client.example.com
  Host-group: ipaservers
  Description: IPA server hosts
  Member hosts: server.example.com, client.example.com
-------------------------
Number of members added 1
-------------------------

L'appartenance à ipaservers octroie à la machine des privilèges analogues à ceux de l'administrateur.

Sur le client, exécutez l'utilitaire ipa-replica-install.

# ipa-replica-install

Dans cette procédure, un réplica est installé de toutes pièces sur un ordinateur qui n'est pas encore un client IdM. Pour autoriser l'inscription, un mot de passe aléatoire spécifique au client valide pour une inscription client uniquement est utilisé.

La procédure ne vous oblige pas à fournir les informations d'identification de l'administrateur ou de Directory Manager (DM). Il est donc plus sécurisé car aucune information sensible n'est exposée sur la ligne de commande.

Sur un serveur existant:

Connectez-vous en tant qu'administrateur.

$ kinit admin

Ajoutez la nouvelle machine en tant qu'hôte IdM. Utilisez l'option –random avec la commande ipa host-add pour générer un mot de passe à usage unique aléatoire à utiliser pour l'installation du réplica.

$ ipa host-add client.example.com --random
--------------------------------------------------
Added host "client.example.com"
--------------------------------------------------
  Host name: client.example.com
  Random password: W5YpARl=7M.n
  Password: True
  Keytab: False
  Managed by: server.example.com

Le mot de passe généré ne sera plus valide une fois que vous l'utiliserez pour inscrire la machine dans le domaine IdM. Il sera remplacé par un keytab d'hôte approprié une fois l'inscription terminée.

Ajoutez la machine au groupe hôte ipaservers.

$ ipa hostgroup-add-member ipaservers --hosts client.example.com
  Host-group: ipaservers
  Description: IPA server hosts
  Member hosts: server.example.com, client.example.com
-------------------------
Number of members added 1
-------------------------

L'appartenance à ipaservers octroie les privilèges élevés requis par la machine pour configurer les services de serveur nécessaires.

Sur l'ordinateur sur lequel vous voulez installer le réplica, exécutez ipa-replica-install et indiquez le mot de passe aléatoire à l'aide de l'option –password. Placez le mot de passe entre guillemets (') car il contient souvent des caractères spéciaux:

# ipa-replica-install --password 'W5YpARl=7M.n'

Cette procédure fonctionne pour installer une réplique sur un client ainsi que sur une machine qui ne fait pas encore partie du domaine IdM.

Exécutez ipa-replica-install avec les options suivantes:

• –setup-dns pour créer une zone DNS si elle n'existe pas déjà et configurez la réplique comme serveur DNS
• –forwarder pour spécifier un redirecteur, ou –no-forwarder si vous ne voulez utiliser aucun redirecteur

Pour spécifier plusieurs redirecteurs pour des raisons de basculement, utilisez –forwarder plusieurs fois.

Par exemple:

# ipa-replica-install --setup-dns --forwarder 192.0.2.1

Si le serveur initial a été créé avec un DNS activé, le réplica est automatiquement créé avec les entrées DNS appropriées. Les entrées garantissent que les clients IdM pourront découvrir le nouveau serveur.

Si le DNS n'était pas activé sur le serveur initial, ajoutez les enregistrements DNS manuellement. Les enregistrements DNS suivants sont nécessaires pour les services de domaine:

• _ldap._tcp
• _kerberos._tcp
• _kerberos._udp
• _kerberos-master._tcp
• _kerberos-master._udp
• _ntp._udp
• _kpasswd._tcp
• _kpasswd._udp

Cet exemple montre comment vérifier que les entrées sont présentes:

Définissez les valeurs appropriées pour les variables DOMAIN et NAMESERVER:

# DOMAIN=example.com
# NAMESERVER=replica

Utilisez la commande suivante pour rechercher les entrées DNS:

# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp ; do
dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority
done | egrep "^_"
 
_ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server1.example.com.
_ldap._tcp.example.com. 86400     IN    SRV     0 100 389 server2.example.com.
_kerberos._tcp.example.com. 86400 IN    SRV     0 100 88  server1.example.com.
...

search example.com
 
; the IdM server
nameserver 192.0.2.1
 
; backup DNS servers
nameserver 198.51.100.1
nameserver 198.51.100.2

Cette procédure fonctionne pour installer une réplique sur un client ainsi que sur une machine qui ne fait pas encore partie du domaine IdM.

Exécutez ipa-replica-install avec l'option –setup-ca.

[root@replica ~]# ipa-replica-install --setup-ca

L'option –setup-ca copie la configuration de l'autorité de certification à partir de la configuration du serveur initial, que l'autorité de certification IdM sur le serveur soit une autorité de certification racine ou qu'elle soit subordonnée à une autorité de certification externe.

Cette procédure fonctionne pour installer une réplique sur un client ainsi que sur une machine qui ne fait pas encore partie du domaine IdM.

Exécutez ipa-replica-install et fournissez les fichiers de certificat requis en ajoutant ces options:

• –dirsrv-cert-file
• –dirsrv-pin
• –http-cert-file
• –http-pin

Par example :

[root@replica ~]# ipa-replica-install \
    --dirsrv-cert-file /tmp/server.crt \
    --dirsrv-cert-file /tmp/server.key \
    --dirsrv-pin secret \
    --http-cert-file /tmp/server.crt \
    --http-cert-file /tmp/server.key \
    --http-pin secret

Pour vérifier si la réplication fonctionne comme prévu après la création d'un réplica:

Créez un utilisateur sur l'un des serveurs:

[admin@server1 ~] $ ipa user-add test_user --first=Test --last=Utilisateur

Assurez-vous que l'utilisateur est visible sur l'autre serveur:

[admin@server2 ~] $ ipa user-show test_user