Un serveur Identity Management (IdM) est un contrôleur de domaine : il définit et gère le domaine IdM.
Pour configurer un serveur IdM, nous devons :
Red Hat recommande vivement de configurer plusieurs contrôleurs de domaine dans votre domaine pour l'équilibrage de charge et la redondance.
Ces serveurs supplémentaires sont des répliques du serveur maître IdM initial.
La RAM est la caractéristique matérielle la plus importante à dimensionner correctement. Pour déterminer la quantité de RAM requise, tenez compte des recommandations suivantes:
Note:
Une entrée utilisateur de base ou une simple entrée hôte avec un certificat a une taille d'environ 5 à 10 Ko.
Pour les déploiements plus importants, il est plus efficace d'augmenter la mémoire vive que d'augmenter l'espace disque, car la plupart des données sont stockées dans le cache.
Pour améliorer les performances, vous pouvez optimiser le serveur d'annuaire sous-jacent pour améliorer les performances.
Identity Management 4.4 est pris en charge sur Red Hat Enterprise Linux 7.
Installez un serveur IdM sur un système propre sans aucune configuration personnalisée pour des services tels que DNS, Kerberos ou Directory Server. L'installation du serveur IdM remplace les fichiers système pour configurer le domaine IdM. IdM sauvegarde les fichiers système d'origine dans /var/lib/ipa/sysrestore/.
Prise en charge de la norme FIPS (Federal Information Processing Standard)
Dans les environnements configurés à l'aide de Red Hat Enterprise Linux 7.4 et versions ultérieures:
Attention:
Vous ne pouvez pas:
Dans les environnements configurés avec Red Hat Enterprise Linux 7.3 et versions antérieures:
Configuration requise pour le démon de cache de service de noms (NSCD)
Red Hat recommande de désactiver le NSCD sur les ordinateurs Identity Management. Sinon, si la désactivation de NSCD n'est pas possible, activez uniquement NSCD pour les cartes que SSSD ne met pas en cache.
NSCD et le service SSSD effectuent tous deux la mise en cache et des problèmes peuvent survenir lorsque les systèmes utilisent les deux services simultanément. Reportez-vous au Guide d'authentification de niveau système pour savoir comment éviter les conflits entre NSCD et SSSD.
IPv6 doit être activé sur le système
L'installation et l'exécution d'un serveur IdM nécessite que IPv6 soit activé sur le réseau. Notez que IPv6 est activé par défaut sur les systèmes Red Hat Enterprise Linux 7.
Si vous avez désactivé IPv6 auparavant, réactivez-le.
Attention:
Soyez extrêmement prudent et assurez-vous que:
Cette exigence s'applique aux serveurs IdM dotés de services DNS intégrés ainsi qu'aux serveurs IdM installés sans DNS. Les enregistrements DNS sont vitaux pour presque toutes les fonctions du domaine IdM, y compris les services d'annuaire LDAP, l'intégration Kerberos et Active Directory.
Notez que le domaine DNS primaire et le domaine Kerberos ne peuvent pas être modifiés après l'installation.
Le DNS doit être configuré correctement sur le serveur hôte, que celui-ci soit intégré à IdM ou qu'il soit hébergé en externe. La gestion des identités nécessite un domaine DNS distinct à utiliser pour les enregistrements de service. Pour éviter les conflits au niveau DNS, le domaine DNS principal utilisé pour IdM ne peut être partagé avec aucun autre système.
Note:
Les noms d'hôte des clients IdM ne doivent pas nécessairement faire partie du domaine DNS principal.
Le nom d'hôte doit être un nom de domaine complet, tel que server.example.com. Pour vérifier le nom d'hôte de votre machine, utilisez l'utilitaire hostname:
[root@srvidm01 ~] # hostname srvidm01.oowy.fr
La sortie du nom d'hôte ne doit pas être localhost ou localhost6.
Attention:
Le nom de domaine complet doit être un nom DNS valide, ce qui signifie que seuls les nombres, les caractères alphabétiques et les tirets (-) sont autorisés. D'autres caractères, tels que les traits de soulignement, dans le nom d'hôte provoquent des échecs DNS. De plus, le nom d'hôte doit être tout en minuscule; aucune majuscule n'est autorisée.
Le nom de domaine complet ne doit pas être résolu en adresse de bouclage. Il doit être résolu en adresse IP publique de la machine et non en 127.0.0.1.
Obtenir l'adresse IP du serveur. La commande ip addr show affiche les adresses IPv4 et IPv6:
[root@srvidm01 ~]# ip addr show ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0 valid_lft 106694sec preferred_lft 106694sec inet6 2001:DB8::1111/32 scope global dynamic valid_lft 2591521sec preferred_lft 604321sec inet6 fe80::56ee:75ff:fe2b:def6/64 scope link valid_lft forever preferred_lft forever
Exécutez la commande dig +short server.example.com A. L'adresse IPv4 renvoyée doit correspondre à l'adresse IP renvoyée par ip addr show:
[root@srvidm01 ~] # dig +short server.example.com A 192.0.2.1
Exécutez la commande dig +short server.example.com AAAA. Si la commande renvoie une adresse, celle-ci doit correspondre à l'adresse IPv6 renvoyée par ip addr show:
[root@srvidm01 ~] # dig +short server.example.com AAAA 2001:DB8::1111
Note:
Si aucune sortie n'est renvoyée pour l'enregistrement AAAA, cela indique que la configuration est incorrecte. Aucune sortie signifie uniquement qu'aucune adresse IPv6 n'est configurée dans DNS pour la machine serveur. Si vous n'avez pas l'intention d'utiliser le protocole IPv6 sur votre réseau, vous pouvez procéder à l'installation.
Nous allons vérifiez la configuration DNS inverse (enregistrements PTR) à l'aide de l'utilitaire “dig” et en ajoutant l'adresse IP.
Exécutez la commande dig +short -x IPv4 address. Le nom d'hôte du serveur doit être affiché dans la sortie de la commande.
[root@srvidm01 ~]# dig +short -x 192.0.2.1 srvidm01.oowy.fr
Utilisez “dig” pour interroger également l'adresse IPv6.
Si la commande dig +short -x server.example.com AAAA à l'étape précédente a renvoyé une adresse IPv6. Là encore, le nom d'hôte du serveur doit être affiché dans la sortie de la commande.
[root@srvidm01 ~]# dig +short -x 2001:DB8::1111 srvidm01.oowy.fr
Note:
Si dig +short server.example.com AAAA à l'étape précédente n'a pas affiché d'adresse IPv6, l'interrogation de l'enregistrement AAAA ne génère rien. Dans ce cas, il s'agit d'un comportement normal et n'indique pas une configuration incorrecte.
Si un nom d'hôte différent ou aucun nom d'hôte n'est retourné, même si dig +short server.example.com à l'étape précédente a renvoyé une adresse IP, cela indique que la configuration DNS inverse est incorrecte.
Lors de la configuration d'IdM avec le service DNS intégré, il est recommandé d'utiliser la validation des enregistrements DNSSEC (DNS Security Extensions). En validant les enregistrements DNS signés à partir d'autres serveurs, vous protégez votre installation IdM contre les adresses usurpées.
Cependant, la validation DNSSEC n'est pas une exigence difficile pour une installation réussie d'IdM.
Le programme d'installation d'IdM active la validation des enregistrements DNSSEC par défaut.
Pour une validation DNSSEC réussie, il est essentiel de disposer de redirecteurs sur lesquels DNSSEC a été correctement configuré. Lors de l'installation, IdM vérifie les redirecteurs globaux et si un redirecteur ne prend pas en charge DNSSEC, la validation DNSSEC sera désactivée sur le redirecteur.
Pour vérifier que tous les redirecteurs DNS que vous souhaitez utiliser avec le serveur DNS IdM sont conformes aux normes relatives aux mécanismes d'extension pour DNS (EDNS0) et DNSSEC:
$ dig +dnssec @IP_address_of_the_DNS_forwarder . SOA
Le résultat attendu affiché par la commande contient les informations suivantes:
Si l'un de ces éléments est manquant dans la sortie, examinez la documentation de votre redirecteur DNS et vérifiez que EDNS0 et DNSSEC sont pris en charge et activés.
Dans les dernières versions du serveur BIND, cela correspond au paramètre dnssec-enable yes;. L'option doit être définie dans le fichier “/etc/named.conf”.
Par exemple :
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; ANSWER SECTION: . 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400 . 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
Le fichier /etc/hosts
Attention:
Ne modifiez pas le fichier /etc/hosts manuellement. Si /etc/hosts a été modifié, assurez-vous que son contenu est conforme aux règles suivantes.
Voici un exemple de fichier /etc/hosts correctement configuré. Il répertorie correctement les entrées d'hôte local IPv4 et IPv6 pour l'hôte, suivies de l'adresse IP du serveur IdM et du nom d'hôte en tant que première entrée. Notez que le nom d'hôte du serveur IdM ne peut pas faire partie de l'entrée localhost.
127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.0.2.1 srvidm01.oowy.fr srvidm01 2001:DB8::1111 srvidm01.oowy.fr srvidm01
IdM utilise un certain nombre de ports pour communiquer avec ses services. Ces ports doivent être ouverts et disponibles pour que IdM fonctionne. Ils ne peuvent pas être utilisés par un autre service ou bloqués par un pare-feu.
| Service | Ports | Protocol |
|---|---|---|
| HTTP/HTTPS | 80, 443 | TCP |
| LDAP/LDAPS | 389, 636 | TCP |
| Kerberos | 88, 464 | TCP and UDP |
| DNS | 53 | TCP and UDP |
| NTP | 123 | UDP |
Note:
Ne vous inquiétez pas, IdM utilise les ports 80 et 389.
De plus, IdM peut écouter sur le port 8080 et dans certaines installations également sur les ports 8443 et 749.
Cependant, ces trois ports ne sont utilisés qu'en interne: même si IdM les maintient ouverts, ils ne doivent pas nécessairement être accessibles de l'extérieur.
Il est recommandé de ne pas ouvrir les ports 8080, 8443 et 749 et de les laisser bloqués par un pare-feu.
| Service name | For details, see: |
|---|---|
| freeipa-ldap | /usr/lib/firewalld/services/freeipa-ldap.xml |
| freeipa-ldaps | /usr/lib/firewalld/services/freeipa-ldaps.xml |
| dns | /usr/lib/firewalld/services/dns.xml |
Assurez-vous que le service pare-feu est en cours d'exécution. Pour savoir si “firewalld” est en cours d'exécution:
# systemctl status firewalld.service
Pour démarrer “firewalld” et le configurer pour qu'il démarre automatiquement au démarrage du système:
# systemctl start firewalld.service
# systemctl enable firewalld.service
Ouvrez les ports requis à l'aide de l'utilitaire “firewall-cmd”. Choisissez l'une des options suivantes:
Par exemple, pour ouvrir les ports dans la zone par défaut:
# firewall-cmd --permanent --add-port = {80 / tcp, 443 / tcp, list_of_ports}
Par exemple, pour ouvrir les ports dans la zone par défaut:
# firewall-cmd --permanent --add-service = {freeipa-ldap, list_of_services}
Pour plus d'informations sur l'utilisation de “firewall-cmd” pour ouvrir des ports sur un système, reportez-vous au manuel “Security Guide” ou à la page de manuel “firewall-cmd (1)”.
Rechargez la configuration firewall-cmd pour vous assurer que la modification a lieu immédiatement:
# firewall-cmd --reload
Note:
Le rechargement de firewalld sur un système en production peut provoquer des délais de connexion DNS. Si nécessaire, pour éviter le risque d'expiration, répétez les commandes sans l'option --permanent pour appliquer les modifications au système en cours d'exécution.
Note:
Pour vérifier que les ports sont disponibles maintenant, utilisez les utilitaires nc, telnet ou nmap pour vous connecter à un port ou exécuter une analyse de port.
Pour installer les packages requis pour un serveur sans services DNS intégrés:
# yum install ipa-server
Pour installer les packages requis pour un serveur avec des services DNS intégrés:
# yum install ipa-server ipa-server-dns
Le package ipa-server installe automatiquement les packages requis en tant que dépendances, telles que:
Note:
Les procédures d'installation et les exemples des sections suivantes ne s'excluent pas mutuellement : vous pouvez les combiner pour obtenir le résultat souhaité. Par exemple, vous pouvez installer un serveur avec DNS intégré et une autorité de certification racine hébergée en externe.
L'utilitaire “ipa-server-install” installe et configure un serveur IdM et fournit un mode d'installation non interactif qui permet une configuration de serveur automatisée et sans surveillance.
Le script d'installation “ipa-server-install” crée un fichier journal dans /var/log/ipaserver-install.log. Si l'installation échoue, le journal peut vous aider à identifier le problème.
IdM prend en charge l'installation d'un serveur avec DNS intégré ou sans DNS intégré.
Le serveur DNS intégré fourni par IdM n'est pas conçu pour être utilisé comme serveur DNS général. Il ne prend en charge que les fonctionnalités liées au déploiement et à la maintenance des IdM. Il ne prend pas en charge certaines des fonctionnalités DNS avancées.
Red Hat recommande fortement l'utilisation du DNS intégré à IdM pour une utilisation de base dans le déploiement IdM : Lorsque le serveur IdM gère également le DNS, il existe une intégration étroite entre les outils DNS et IdM natifs, ce qui permet d'automatiser une partie de la gestion des enregistrements DNS.
Note:
Même si un serveur IdM est utilisé comme serveur DNS maître, d'autres serveurs DNS externes peuvent toujours être utilisés en tant que serveurs esclaves.
Par exemple, si votre environnement utilise déjà un autre serveur DNS, tel qu'un serveur DNS intégré à Active Directory, vous ne pouvez déléguer que le domaine principal IdM au DNS intégré à IdM. Vous n'êtes pas obligé de migrer les zones DNS vers le DNS intégré à la gestion IdM.
Un serveur DNS externe est utilisé pour fournir les services DNS. Envisagez d'installer un serveur IdM sans DNS dans ces situations:
Lors de l'utilisation d'un serveur DNS intégré, la majeure partie de la maintenance de l'enregistrement DNS est automatisée. Vous devez seulement:
Lorsque vous utilisez un serveur DNS externe, vous devez:
La configuration par défaut du serveur DNS intégré à IdM permet à tous les clients d'émettre des requêtes récursives sur le serveur DNS. Si votre serveur est déployé sur un réseau avec un client non approuvé, modifiez la configuration du serveur pour limiter la récursivité aux clients autorisés uniquement.
Pour vous assurer que seuls les clients autorisés sont autorisés à émettre des requêtes récursives, ajoutez les instructions de liste de contrôle d'accès (ACL) appropriées au fichier /etc/named.conf sur votre serveur.
Par exemple:
acl authorized { 192.0.2.0/24; 198.51.100.0/24; }; options { allow-query { any; }; allow-recursion { authorized; }; };
IdM prend en charge l'installation d'un serveur avec une autorité de certification IdM intégrée ou sans autorité de certification.
C'est la configuration par défaut adaptée à la plupart des déploiements. Le système de certificats utilise un certificat de signature CA pour créer et signer les certificats dans le domaine IdM.
Attention:
Red Hat recommande vivement de conserver les services CA installés sur plusieurs serveurs. Pour plus d'informations sur l'installation d'une réplique du serveur initial, y compris les services de l'autorité de certification, reportez-vous à la Section 4.5.4, «Installation d'une réplique avec une autorité de certification».
Si vous installez l’autorité de certification sur un seul serveur, vous risquez de perdre la configuration de l’autorité de certification sans aucune possibilité de récupération si le serveur de l’autorité de certification échoue. Voir Section B.2.6, «Récupération d'un serveur CA perdu» pour plus de détails.
Le certificat de signature de l'autorité de certification doit être signé par une autorité de certification racine, qui est l'autorité de certification la plus élevée de la hiérarchie de l'autorité de certification. L'autorité de certification racine peut être l'autorité de certification IdM ou une autorité de certification hébergée en externe.
C'est la configuration par défaut.
Pour installer un serveur avec cette configuration, reportez-vous à la Section «Installation d'un serveur IdM avec DNS intégré» et à la Section, «Installation d'un serveur sans DNS intégré».
L'autorité de certification IdM est subordonnée à une autorité de certification externe. Cependant, tous les certificats du domaine IdM sont toujours émis par l'instance du système de certificats.
L'autorité de certification externe peut être une autorité de certification d'entreprise ou une autorité de certification tierce, telle que Verisign ou Thawte. Les certificats émis dans le domaine IdM sont potentiellement soumis à des restrictions définies par l'autorité de certification racine externe pour des attributs tels que la période de validité.
Cette option de configuration convient aux cas très rares où les restrictions au sein de l'infrastructure ne permettent pas d'installer les services de certificats avec le serveur.
Vous devez demander ces certificats à une autorité tierce avant l'installation:
La gestion des certificats sans CA IdM intégrée représente une charge de maintenance importante.
Notamment:
Pour installer un serveur IdM avec le service DNS intégré, fournissez les informations suivantes lors du processus d'installation:
Les paramètres de redirecteur DNS suivants sont pris en charge:
Les paramètres de zone DNS inversés suivants sont pris en charge:
Cette procédure installe un serveur:
Exécutez l'utilitaire “ipa-server-install”.
# ipa-server-install
Le script vous invite à configurer un service DNS intégré. Entrez oui
Do you want to configure integrated DNS (BIND)? [no]: yes
Le script demande plusieurs paramètres requis.
Server host name [server.example.com]: Please confirm the domain name [example.com]: Please provide a realm name [EXAMPLE.COM]:
Attention:
Red Hat recommande fortement que le nom de domaine Kerberos soit identique au nom de domaine DNS principal, avec toutes les lettres en majuscule.
Par exemple, si le domaine DNS principal est ipa.exemple.com, utilisez IPA.EXAMPLE.COM pour le nom de domaine Kerberos.
Différentes pratiques de nommage vous empêcheront d'utiliser des approbations Active Directory et peuvent avoir d'autres conséquences négatives.
Entrez les mots de passe du super-utilisateur Directory Server, cn=Directory Manager et du compte utilisateur admin IdM .
Directory Manager password: IPA admin password:
Le script demande des redirecteurs DNS.
Do you want to configure DNS forwarders? [yes]:
Le script vous invite à vérifier si des enregistrements inverses DNS (PTR) pour les adresses IP associées au serveur doivent être configurés.
Do you want to search for missing reverse zones? [yes]:
Si vous exécutez des recherches et que des zones inversées manquantes sont découvertes, le script vous demande si vous souhaitez créer les zones inversées avec les enregistrements PTR.
Do you want to create reverse zone for IP 192.0.2.1 [yes]: Please specify the reverse zone name [2.0.192.in-addr.arpa.]: Using reverse zone(s) 2.0.192.in-addr.arpa.
Note:
L'utilisation d'IdM pour gérer les zones inverses est facultative. Vous pouvez utiliser un service DNS externe à cette fin.
Entrez “yes” pour confirmer la configuration du serveur.
Continue to configure the system with these values? [no]: yes
Le script d'installation configure maintenant le serveur. Attendez que l'opération se termine.
Ajoutez la délégation DNS du domaine parent au domaine DNS IdM. Par exemple, si le domaine DNS IdM est ipa.example.com, ajoutez un enregistrement de serveur de noms (NS) au domaine parent example.com.
Attention:
Cette étape doit être répétée chaque fois qu'un serveur DNS IdM est installé.
Authentifiez-vous dans le royaume Kerberos à l'aide des informations d'identification d'administrateur. Cela vérifie que le compte “admin” est correctement configuré et que le royaume Kerberos est accessible.
# kinit admin
Exécutez une commande telle que “ipa user-find”. Sur un nouveau serveur, la commande affiche le seul utilisateur configuré : “admin”.
# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
Pour installer un serveur sans DNS intégré, exécutez l'utilitaire “ipa-server-install” sans aucune option liée au DNS.
Cette procédure installe un serveur:
Exécutez l'utilitaire “ipa-server-install”.
# ipa-server-install
Le script vous invite à configurer un service DNS intégré. Appuyez sur Entrée pour sélectionner l'option par défaut.
Do you want to configure integrated DNS (BIND)? [no]:
Le script demande plusieurs paramètres requis.
Server host name [server.example.com]: Please confirm the domain name [example.com]: Please provide a realm name [EXAMPLE.COM]:
Attention:
Red Hat recommande fortement que le nom de domaine Kerberos soit identique au nom de domaine DNS principal, avec toutes les lettres en majuscule.
Par exemple, si le domaine DNS principal est ipa.exemple.com, utilisez IPA.EXAMPLE.COM pour le nom de domaine Kerberos.
Différentes pratiques de nommage vous empêcheront d'utiliser des approbations Active Directory et peuvent avoir d'autres conséquences négatives.
Entrez les mots de passe du super-utilisateur Directory Server, cn=Directory Manager et du compte d'utilisateur admin IdM.
Directory Manager password: IPA admin password:
Entrez “yes” pour confirmer la configuration du serveur.
Continue to configure the system with these values? [no]: yes
Le script d'installation configure maintenant le serveur. Attendez que l'opération se termine.
Le script d'installation produit un fichier avec des enregistrements de ressources DNS: le fichier /tmp/ipa.system.records.UFRPto dans l'exemple ci-dessous. Ajoutez ces enregistrements aux serveurs DNS externes existants. Le processus de mise à jour des enregistrements DNS varie en fonction de la solution DNS particulière.
... Restarting the KDC Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db Restarting the web server ...
Attention:
L'installation du serveur n'est pas terminée tant que vous n'avez pas ajouté les enregistrements DNS aux serveurs DNS existants.
Authentifiez-vous dans le royaume Kerberos à l'aide des informations d'identification d'administrateur. Cela vérifie que le compte “admin” est correctement configuré et que le royaume Kerberos est accessible.
# kinit admin
Exécutez une commande telle que “ipa-user-find”. Sur un nouveau serveur, la commande affiche le seul utilisateur configuré : “admin”.
# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------
Cette partie ne sera pas traitée dans ce howto, nous vous renvoyons à la documentation Redhat.
Réf : Red hat - IdM 2.3.5
Cette partie ne sera pas traitée dans ce howto, nous vous renvoyons à la documentation Redhat.
Réf : Red hat - IdM 2.3.6
Les options minimales requises pour une installation non interactive sont les suivantes:
Vous pouvez éventuellement fournir des valeurs personnalisées pour ces paramètres:
Attention:
Red Hat recommande fortement que le nom de domaine Kerberos soit identique au nom de domaine DNS principal, avec toutes les lettres en majuscule. Par exemple, si le domaine DNS principal est ipa.exemple.com, utilisez IPA.EXAMPLE.COM pour le nom de domaine Kerberos.
Différentes pratiques de nommage vous empêcheront d'utiliser des approbations Active Directory et peuvent avoir d'autres conséquences négatives.
Pour obtenir une liste complète des options acceptées par “ipa-server-install”, exécutez la commande “ipa-server-install –help”.
Exécutez l'utilitaire “ipa-server-install” en indiquant les paramètres requis.
Par exemple, ce qui suit installe un serveur sans DNS intégré et avec une autorité de certification intégrée :
# ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
Le script de configuration configure maintenant le serveur. Attendez que l'opération se termine.
Le script d'installation produit un fichier avec des enregistrements de ressources DNS: le fichier /tmp/ipa.system.records.UFRPto dans l'exemple ci-dessous. Ajoutez ces enregistrements aux serveurs DNS externes existants. Le processus de mise à jour des enregistrements DNS varie en fonction de la solution DNS particulière.
... Restarting the KDC Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db Restarting the web server ...
Attention:
L'installation du serveur n'est pas terminée tant que vous n'avez pas ajouté les enregistrements DNS aux serveurs DNS existants.
Authentifiez-vous dans le royaume Kerberos à l'aide des informations d'identification d'administrateur. Cela vérifie que le compte “admin” est correctement configuré et que le royaume Kerberos est accessible.
# kinit admin
Exécutez une commande telle que “ipa-user-find”. Sur un nouveau serveur, la commande affiche le seul utilisateur configuré : “admin”.
# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 939000000 GID: 939000000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ----------------------------