Prüfen der Integrität von Sicherungen der Zertifizierungsstellen-Datenbank

Im Rahmen der Erstellung einer Sicherung (Backup) einer Zertifizierungsstelle kann die Frage aufkommen, wie man sicherstellen kann, dass die Integrität der Sicherung der Zertifizierungsstellen-Datenbank gewährleistet ist, sodass diese im Notfall auch korrekt wiederhergestellt werden kann.

Die Zertifizierungsstellen-Datenbank ist in einer Microsoft JET Blue Datenbankengine (auch bekannt als Extensible Storage Engine, ESE) anbgebildet. Deren Arbeits- und Sicherungsdateien haben die Endung .edb und können mit dem Betriebssystem-Werkzeug esentutl verwaltet werden.

Bitte den Artikel aufmerksam lesen und verstehen, bevor die dargestellten Befehle ausgeführt werden. Es besteht bei falscher Anwendung ein sehr hohes Risiko, die Zertifizierungsstellen-Datenbank der laufenden Zertifizierungsstelle zu beschädigen.

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Die Integrität einer ESE-Datenbankdatei kann mit folgendem Befehl geprüft werden:

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

Führt man diesen Befehl jedoch gegen eine Sicherung der Zertifizierungsstellen-Datenbank aus, wird man auf folgende Fehlermeldung stoßen:

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?

Selbst wenn man die Frage mit "OK" bestätigt, wird die Prüfung mit dem gleichen Fehler fehlschlagen.

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.

Mit folgendem Befehl kann ein Blick in die Metainformationen der Datenbankdatei geworfen werden:

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

Hier wird sehr wahrscheinlich herauskommen, dass sich die Datenbankdatei im Zustand "Dirty Shutdown" befindet. Auch wenn es auf den ersten Blick nicht intuitiv wirkt ist dies der erwartete Zustand, wenn eine Sicherung der Zertifizierungsstellen-Datenbank von einem laufenden Server vorgenommen wird (da ein Dateisystem-Snapshot verwendet wird). Die Datenbankdatei entspricht somit 1:1 dem Zustand auf dem laufenden Server zum Zeitpunkt der Sicherung.

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

Dies erklärt auch, warum sich der Integritätscheck mit esentutl darüber beschwert, dass die Datenbank-Transaktionsprotokolle (engl. "Transaction Logs") nicht in die Datenbankdatei überführt wurden – dies erfolgt auf der Zertifizierungsstelle erst, wenn eine Vollsicherung erfolgreich durchgeführt wurde. Ergo wird eine Sicherung immer Transaktionsprotokolle enthalten.

Diese müssen somit zunächst in die Datenbank-Datei überführt werden. Der folgerichtige Schritt wäre folgender Befehl, jedoch…

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

Die Option /r ("Recovery") entnimmt die Information, in welche Datenbank die Transaktionsprotokolle überführt werden sollen aus den Transaktionsprotokollen selbst. Ergo wird das Werkzeug versuchen, diese gegen die originale Datenbank der Zertifizierungsstelle wiederherzustellen versuchen. Der Befehl sollte damals niemals auf der Zertifizierungsstelle selbst ausgeführt werden.

Führt man den Befehl somit auf der Zertifizierungsstelle aus, zerstört man die originale Zertifizierungsstellen-Datenbank.

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.

Korrekter Weise gibt man also mit dem /d Argument den Ziel-Ordner an, in welchem sich die "richtige" Datenbankdatei befindet. Hier kann mit dem Ordnernamen "." auch angegeben werden, dass der Ziel-Ordner der gleiche ist, in welchem sich die Transaktionsprotokolle befinden.

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.

Inspiziert man nun erneut die Metadaten der Datenbankdatei, befindet sich diese im "Clean Shutdown" Status.

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

Nun wird auch die Integritätsprüfung korrekt ausgeführt.

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.

Versucht man nun jedoch die vermeintlich "reparierte" Datei, mit Bordmitteln wiederherzustellen, wird die Zertifizierungsstelle dies verweigern:

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)

Ursache ist, wie wir zuvor festgestellt haben, dass der erwartete Zustand einer Datenbanksicherung "Dirty Shutdown" ist. Die integritätsgeprüfte Variante der Datenbankdatei ist somit nicht für eine (reguläre und vom Hersteller unterstützte) Wiederherstellung geeignet.

Sollte sich dennoch der Bedarf ergeben, kann jedoch (auf eigenes Risiko) wie folgt vorgegangen werden:

Beenden des Zertifizierungsstellen-Dienstes.
Inhalt des originalen Datenbank-Ordners löschen.
Die "integritätsgeprüften" Dateien in den Datenbank-Ordner kopieren.
Zertifizierungsstellen-Dienst wieder starten.

Weiterführende Links:

Externe Quellen

esentutl (Microsoft Corporation)

Weiterführende Links:

Externe Quellen

Ein Gedanke zu „Prüfen der Integrität von Sicherungen der Zertifizierungsstellen-Datenbank“