Sauvegarde et restauration de la gestion des identités

Red Hat Enterprise Linux Identity Management fournit une solution pour sauvegarder et restaurer manuellement le système IdM, par exemple lorsqu'un serveur ( ou réplica ) cesse de fonctionner correctement ou que des pertes de données se produisent.

Pendant la sauvegarde, le système crée un répertoire contenant des informations sur la configuration de votre IdM et le stocke. Pendant la restauration, vous pouvez utiliser ce répertoire de sauvegarde pour rétablir la configuration de votre IdM d'origine.

Les scénarios potentiels que la sauvegarde et la restauration peuvent inclure :

• Une défaillance matérielle majeure sur une machine se produit et le système de la machine est inutilisable. Dans ce cas, vous pouvez réinstaller le système d'exploitation , configurer la machine avec le même nom de domaine complet et le même nom d'hôte, installer les packages IdM ainsi que tous les autres packages facultatifs associés à IdM présents sur l'original et restaurer la sauvegarde complète du serveur IdM.

• Une mise à niveau sur une machine isolée échoue. Le système d'exploitation reste fonctionnel, mais les données IdM sont corrompues.

• Des modifications indésirables ont été apportées au contenu LDAP, par exemple des entrées ont été supprimées et vous souhaitez les restaurer. La restauration des données LDAP sauvegardées renvoie les entrées LDAP à l'état précédent sans affecter le système IdM lui-même.

Le serveur restauré devient la seule source d'informations pour IdM. les autres serveurs maîtres sont réinitialisés à partir du serveur restauré. Toutes les données créées après la dernière sauvegarde sont perdues. Par conséquent, vous ne devez pas utiliser la solution de restauration pour la maintenance normale du système. Si possible, recréez toujours le serveur perdu en le réinstallant comme réplique.

Les fonctionnalités de sauvegarde et de restauration ne peuvent être gérées qu'à partir de la ligne de commande et ne sont pas disponibles dans l'interface utilisateur Web IdM.

La sauvegarde complète du serveur crée une copie de sauvegarde de tous les fichiers du serveur IdM, ainsi que des données LDAP, ce qui en fait une sauvegarde autonome. IdM affecte des centaines de fichiers; les fichiers que le processus de sauvegarde copie sont un mélange de répertoires entiers et de fichiers spécifiques, tels que des fichiers de configuration ou des fichiers journaux, et se rapportent directement à IdM ou à divers services dont dépend la solution.

La sauvegarde de serveur complet étant une sauvegarde de fichier brut, elle est effectuée hors ligne. Le script qui effectue la sauvegarde de serveur complet arrête tous les services IdM pour garantir la sécurité du processus de sauvegarde.

La sauvegarde de données uniquement crée une copie de sauvegarde des données LDAP et du journal des modifications. Le processus sauvegarde l'instance IPA-REALM et peut également sauvegarder plusieurs back-ends ou un seul back-end; les back-ends incluent le backend IPA et le back-end CA Dogtag. Cette méthode sauvegarde également un enregistrement du contenu LDAP stocké dans LDIF (LDAP Data Interchange Format). Ce type de sauvegarde peut être effectuée à la fois en ligne et hors ligne.

Par défaut, IdM stocke les sauvegardes créées dans le répertoire /var/lib/ipa/backup/. Les conventions de dénomination des sous-répertoires contenant les sauvegardes sont les suivantes:

• ipa-full-YEAR-MM-JJ-HH-MM-SS dans le fuseau horaire GMT pour la sauvegarde complète du serveur
• ipa-data-YEAR-MM-JJ-HH-MM-SS dans le fuseau horaire GMT pour la sauvegarde de données uniquement

Les sauvegardes sont créées à l'aide de l'utilitaire “ipa-backup”, qui doit toujours être exécuté en tant que root.

Pour créer une sauvegarde complète du serveur, exécutez “ipa-backup”.

Pour créer une sauvegarde de données uniquement, exécutez la commande “ipa-backup –data”.

Vous pouvez ajouter plusieurs options supplémentaires à “ipa-backup”:

• –online effectue une sauvegarde en ligne; cette option est uniquement disponible avec les sauvegardes de données uniquement
• –logs inclut les fichiers journaux du service IdM dans la sauvegarde

Si la sauvegarde échoue en raison d'un espace insuffisant dans le répertoire “/tmp”, modifiez l'emplacement des fichiers à créer lors de la sauvegarde à l'aide de la variable d'environnement TMPDIR:

# TMPDIR=/path/to/backup ipa-backup

D'ailleurs Redhat recommande de modifier le répertoire /tmp configuré par défaut avant de lancer le processus de sauvegarde.

Vous pouvez chiffrer la sauvegarde IdM à l'aide du cryptage GNU Privacy Guard (GPG).

Pour créer une clé GPG, créez un fichier keygen contenant les détails de la clé, par exemple, en exécutant “cat> keygen « EOF” et en fournissant les détails de chiffrement requis au fichier à partir de la ligne de commande:

[root@server ~]# cat >keygen <<EOF
> %echo Generating a standard key
> Key-Type: RSA
> Key-Length:2048
> Name-Real: IPA Backup
> Name-Comment: IPA Backup
> Name-Email: root@example.com
> Expire-Date: 0
> %pubring /root/backup.pub
> %secring /root/backup.sec
> %commit
> %echo done
> EOF
[root@server ~]#

Générez une nouvelle paire de clés appelée “backup” et insérez le contenu de “keygen” dans la commande.

L'exemple suivant génère une paire de clés avec les noms de chemin “/root/backup.sec” et “/root/backup.pub” :

[root@server ~] # gpg --batch --gen-key keygen
[root@server ~] # gpg --no-default-keyring --secret-keyring /root/backup.sec \
--keyring /root/backup.pub --list-secret-keys

Pour créer une sauvegarde chiffrée par GPG, transmettez la clé de sauvegarde générée à “ipa-backup” en fournissant les options suivantes:

• –gpg, qui demande à ipa-backup d'effectuer la sauvegarde cryptée
• –gpg-keyring = GPG_KEYRING, qui fournit le chemin d'accès complet au fichier de clés GPG sans extension de fichier.

Par exemple:

[root@server ~] # ipa-backup --gpg --gpg-keyring = /root/backup

Répertoires:

/usr/share/ipa/html
/root/.pki
/etc/pki-ca
/etc/pki/pki-tomcat
/etc/sysconfig/pki
/etc/httpd/alias
/var/lib/pki
/var/lib/pki-ca
/var/lib/ipa/sysrestore
/var/lib/ipa-client/sysrestore
/var/lib/ipa/dnssec
/var/lib/sss/pubconf/krb5.include.d/
/var/lib/authconfig/last
/var/lib/certmonger
/var/lib/ipa
/var/run/dirsrv
/var/lock/dirsrv

Fichiers:

/etc/named.conf
/etc/named.keytab
/etc/resolv.conf
/etc/sysconfig/pki-ca
/etc/sysconfig/pki-tomcat
/etc/sysconfig/dirsrv
/etc/sysconfig/ntpd
/etc/sysconfig/krb5kdc
/etc/sysconfig/pki/ca/pki-ca
/etc/sysconfig/ipa-dnskeysyncd
/etc/sysconfig/ipa-ods-exporter
/etc/sysconfig/named
/etc/sysconfig/ods
/etc/sysconfig/authconfig
/etc/ipa/nssdb/pwdfile.txt
/etc/pki/ca-trust/source/ipa.p11-kit
/etc/pki/ca-trust/source/anchors/ipa-ca.crt
/etc/nsswitch.conf
/etc/krb5.keytab
/etc/sssd/sssd.conf
/etc/openldap/ldap.conf
/etc/security/limits.conf
/etc/httpd/conf/password.conf
/etc/httpd/conf/ipa.keytab
/etc/httpd/conf.d/ipa-pki-proxy.conf
/etc/httpd/conf.d/ipa-rewrite.conf
/etc/httpd/conf.d/nss.conf
/etc/httpd/conf.d/ipa.conf
/etc/ssh/sshd_config
/etc/ssh/ssh_config
/etc/krb5.conf
/etc/ipa/ca.crt
/etc/ipa/default.conf
/etc/dirsrv/ds.keytab
/etc/ntp.conf
/etc/samba/smb.conf
/etc/samba/samba.keytab
/root/ca-agent.p12
/root/cacert.p12
/var/kerberos/krb5kdc/kdc.conf
/etc/systemd/system/multi-user.target.wants/ipa.service
/etc/systemd/system/multi-user.target.wants/sssd.service
/etc/systemd/system/multi-user.target.wants/certmonger.service
/etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service
/var/run/ipa/services.list
/etc/opendnssec/conf.xml
/etc/opendnssec/kasp.xml
/etc/ipa/dnssec/softhsm2.conf
/etc/ipa/dnssec/softhsm_pin_so
/etc/ipa/dnssec/ipa-ods-exporter.keytab
/etc/ipa/dnssec/ipa-dnskeysyncd.keytab
/etc/idm/nssdb/cert8.db
/etc/idm/nssdb/key3.db
/etc/idm/nssdb/secmod.db
/etc/ipa/nssdb/cert8.db
/etc/ipa/nssdb/key3.db
/etc/ipa/nssdb/secmod.db

Fichiers journaux et répertoires:

/var/log/pki-ca
/var/log/pki/
/var/log/dirsrv/slapd-PKI-IPA
/var/log/httpd
/var/log/ipaserver-install.log
/var/log/kadmind.log
/var/log/pki-ca-install.log
/var/log/messages
/var/log/ipaclient-install.log
/var/log/secure
/var/log/ipaserver-uninstall.log
/var/log/pki-ca-uninstall.log
/var/log/ipaclient-uninstall.log
/var/named/data/named.run

Si vous avez un répertoire avec une sauvegarde créée à l'aide de “ipa-backup”, vous pouvez restaurer votre serveur IdM ou le contenu LDAP dans l'état dans lequel il se trouvait lors de la sauvegarde. Vous ne pouvez pas restaurer une sauvegarde sur un hôte différent de l'hôte sur lequel la sauvegarde a été créée à l'origine.

La désinstallation d'un serveur IdM ne supprime pas automatiquement la sauvegarde de ce serveur.

Les sauvegardes completes et de données uniquement sont restaurées à l'aide de l'utilitaire “ipa-restore”, qui doit toujours être exécuté en tant que root.

Transmettez la sauvegarde à la commande:

• Ne transmettez que le nom du répertoire avec la sauvegarde si elle se trouve dans le répertoire /var/lib/ipa/backup/ par défaut.
• Transmettez le chemin d'accès complet à la sauvegarde si le répertoire contenant la sauvegarde ne se trouve pas dans le répertoire par défaut. Par exemple:

[root@server ~]# ipa-restore /path/to/backup

L'utilitaire “ipa-restore” détecte automatiquement le type de sauvegarde que contient le répertoire de sauvegarde et effectue par défaut le même type de restauration.

Vous pouvez ajouter les options suivantes à ipa-restore:

• –data effectue une restauration de données uniquement à partir d'une sauvegarde complète du serveur, c'est-à-dire restaure uniquement le composant de données LDAP à partir d'un répertoire de sauvegarde contenant la sauvegarde complète du serveur.
• –online restaure les données LDAP dans une restauration en ligne avec données uniquement
• –instance spécifie quelle instance de 389 DS est restaurée. IdM dans Red Hat Enterprise Linux 7 utilise uniquement l'instance IPA-REALM, mais il peut être possible, par exemple, de créer une sauvegarde sur un système avec des instances distinctes. dans de tels cas, –instance vous permet de restaurer uniquement IPA-REALM. Par exemple:

[root @ server ~] # ipa-restore --instance = IPA-REALM /chemin/vers/sauvegarde

Vous ne pouvez utiliser cette option que lors d'une restauration de données uniquement.

• –backend spécifie quel backend est restauré; sans cette option, ipa-restore restaure tous les back-end découverts. Les arguments définissant les back-end possibles sont userRoot, qui restaure le back-end des données IPA, et ipaca, qui restaure le back-end de l'autorité de certification.

Vous ne pouvez utiliser cette option que lors d'une restauration de données uniquement.

• –no-logs restaure la sauvegarde sans restaurer les fichiers journaux

Pour éviter les problèmes d'authentification sur un maître IdM, effacez le cache SSSD après une restauration:

Arrêtez le service SSSD:

[root@server ~] # systemctl stop sssd

Supprimez tout le contenu en cache de SSSD:

[root @ server ~] # find /var/lib/sss/ ! -type d | xargs rm -f

Démarrez le service SSSD:

[root @ server ~] # systemctl start sssd

La restauration à partir de la sauvegarde définit le serveur restauré comme nouveau maître de données et vous devrez réinitialiser tous les autres maîtres après la restauration.

Pour réinitialiser les autres maîtres, exécutez la commande ipa-replica-manage, sur les maîtres disposant d'une CA, la commande ipa-csreplica-manage.

Par exemple:

[root@server ~] # ipa-replica-manage re-initialize --from=restored_master_FQDN

Si vous souhaitez restaurer à partir d'une sauvegarde chiffrée avec GPG, indiquez le chemin d'accès complet aux clés privée et publique à l'aide de l'option –gpg-keyring.

Par exemple:

[root@server ~]# ipa-restore --gpg-keyring=/root/backup /path/to/backup