Vérification de l'intégrité des sauvegardes de la base de données des autorités de certification

Auteur Uwe GradeneggerPublié le Catégories Sauvegarder et restaurer, Dépannage, Base de données des organismes de certificationÉtiquettes ,

Dans le cadre de la création d'une Sauvegarde (backup) d'une autorité de certification peut soulever la question de savoir comment s'assurer que l'intégrité de la sauvegarde de la base de données de l'autorité de certification est garantie, de sorte qu'en cas d'urgence, elle soit correctement rétabli peut être.

La base de données des organismes de certification est Moteur de base de données Microsoft JET Blue (également connu sous le nom de Moteur de stockage extensible, ESE) abgebildet. Deren Arbeits- und Sicherungsdateien haben die Endung .edb und können mit dem Betriebssystem-Werkzeug esentutl sont gérés.

Veuillez lire attentivement l'article et le comprendre avant d'exécuter les commandes présentées. Il existe un risque très élevé d'endommager la base de données de l'autorité de certification en cours d'utilisation en cas de mauvaise application.

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

L'intégrité d'un fichier de base de données ESE peut être vérifiée à l'aide de la commande suivante :

esentutl /g "{Datenbank-Datei}.edb"

Toutefois, si l'on exécute cette commande par rapport à une sauvegarde de la base de données de l'autorité de certification, on se heurte au message d'erreur suivant :

The database is not up-to-date. Integrity checks may find that this database is corrupt because data from the log files hat yet to be placed in the database. It is strongly recommended the database is brought up-to-date before continuing! Do you wish to abort the operation?

Même si l'on confirme la question par "OK", l'examen échouera avec la même erreur.

D:\Backup\DataBase\esentutl /g "ADCS Labor Issuing CA 1.edb"

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.3
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating INTEGRITY mode...
        Database: ADCS Labor Issuing CA 1.edb
  Temp. Database: .\TEMPINTEG2888.EDB

Checking database integrity.

The database is not up-to-date. This operation may find that
this database is corrupt because data from the log files has
yet to be placed in the database.

To ensure the database is up-to-date please use the 'Recovery' operation.

Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was not shutdown cleanly. Recovery must first be run to properly complete databaseoperations for the previous shutdown.) after 19.250 seconds.

La commande suivante permet de jeter un coup d'œil sur les méta-informations du fichier de la base de données :

esentutl /mh "{Datenbank-Datei}.edb" | findstr /i "log state last" | findstr /i /vc:"Gen:"

Il est très probable qu'il en ressorte que le fichier de la base de données se trouve dans l'état "Dirty Shutdown". Même si cela ne semble pas intuitif à première vue, c'est l'état attendu lorsqu'une sauvegarde de la base de données de l'autorité de certification est effectuée à partir d'un serveur en fonctionnement (puisqu'un instantané du système de fichiers est utilisé). Le fichier de la base de données correspond donc 1:1 à l'état du serveur en cours d'exécution au moment de la sauvegarde.

D:\Backup\DataBase\esentutl /mh "ADCS Labor Issuing CA 1.edb" | findstr /i "log state last" | findstr /i /vc:"Gen:"
            State: Dirty Shutdown
     Log Required: 1-2 (0x1-0x2)
    Log Committed: 0-2 (0x0-0x2)
   Log Recovering: 0 (0x0)
       Last Objid: 72
  Last Consistent: (0x1,B0,1BC)  08/28/2018 06:32:12.540
      Last Attach: (0x1,B2,268)  11/28/2018 00:45:08.528
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00.000
    Last ReAttach: (0x0,0,0)  00/00/1900 00:00:00.000
    Log Signature: Create time:08/28/2018 06:21:54.359 Rand:1662563503 Computer:

  Last checksum finish Date: 00/00/1900 00:00:00.000

Cela explique également pourquoi le contrôle d'intégrité avec esentutl se plaint du fait que les journaux de transactions de la base de données (en anglais "Transaction Logs") n'ont pas été transférés dans le fichier de la base de données - cela n'a lieu sur l'autorité de certification que lorsqu'une sauvegarde complète a été effectuée avec succès. Par conséquent, une sauvegarde contiendra toujours des journaux de transactions.

Celles-ci doivent donc d'abord être transférées dans le fichier de la base de données. L'étape logique serait la commande suivante, mais...

esentutl /r {Präfix-der-Transaktionsprotokoll-Dateien}

L'option /r ("Recovery") extrait des journaux de transactions eux-mêmes l'information sur la base de données vers laquelle les journaux de transactions doivent être transférés. Ergo, l'outil tentera de les restaurer par rapport à la base de données originale de l'autorité de certification essayer. La commande ne devait alors jamais être exécutée sur l'autorité de certification elle-même..

Ainsi, si l'on exécute la commande sur l'autorité de certification, on détruit la base de données originale de l'autorité de certification.

D:\Backup\DataBase\esentutl /r edb

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.3
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: edb
            Log files: {current directory}
         System files: {current directory}

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          .................................X



Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info) after 0.47 seconds.

La bonne façon de procéder est donc d'utiliser le /d indique le dossier cible dans lequel se trouve le "bon" fichier de base de données. Il est également possible d'indiquer ici, avec le nom de dossier ".", que le dossier cible est le même que celui dans lequel se trouvent les journaux de transactions.

esentutl /r {Präfix} /d {Ordner}
D:\Backup\DataBase\esentutl /r edb /d.

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.3
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: edb
            Log files: {current directory}
         System files: {current directory}
   Database Directory: .

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................



Operation completed successfully in 0.156 seconds.

Si l'on inspecte à nouveau les métadonnées du fichier de la base de données, celui-ci se trouve dans le statut "Clean Shutdown".

D:\Backup\DataBase\esentutl /mh "ADCS Labor Issuing CA 1.edb" | findstr /i "log state las
t" | findstr /i /vc:"Gen:"
            State: Clean Shutdown
     Log Required: 0-0 (0x0-0x0)
    Log Committed: 0-0 (0x0-0x0)
   Log Recovering: 0 (0x0)
       Last Objid: 103
  Last Consistent: (0x3,1,31)  11/28/2018 03:37:42.906
      Last Attach: (0x1,B2,268)  11/28/2018 03:37:42.796
      Last Detach: (0x3,1,31)  11/28/2018 03:37:42.906
    Last ReAttach: (0x0,0,0)  00/00/1900 00:00:00.000
    Log Signature: Create time:08/28/2018 06:21:54.359 Rand:1662563503 Computer:

  Last checksum finish Date: 00/00/1900 00:00:00.000

Maintenant, le contrôle d'intégrité est également effectué correctement.

D:\Backup\DataBase\esentutl /g "ADCS Labor Issuing CA 1.edb"

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.3
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating INTEGRITY mode...
        Database: ADCS Labor Issuing CA 1.edb
  Temp. Database: .\TEMPINTEG1528.EDB

Checking database integrity.

                     Scanning Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................


Integrity check successful.

Operation completed successfully in 0.125 seconds.

Si l'on tente de restaurer le fichier prétendument "réparé" avec les moyens du bord, l'autorité de certification refusera de le faire :

The expected data does not exist in this directory. Please choose a different directory.

The directory name is invalid. 0x8007010b (WIN32/HTTP: 267 ERROR_DIRECTORY)

La raison en est, comme nous l'avons constaté précédemment, que l'état attendu d'une sauvegarde de base de données est "Dirty Shutdown". La variante du fichier de base de données dont l'intégrité a été vérifiée n'est donc pas adaptée à une restauration (régulière et prise en charge par le fabricant).

Si le besoin s'en fait néanmoins sentir, il est toutefois possible de procéder comme suit (à ses propres risques) :

  • Arrêter le service d'autorité de certification.
  • Supprimer le contenu du dossier de la base de données d'origine.
  • Copier les fichiers "dont l'intégrité a été vérifiée" dans le dossier de la base de données.
  • Redémarrer le service d'autorité de certification.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais