{"id":1100,"date":"2024-08-19T13:58:15","date_gmt":"2024-08-19T11:58:15","guid":{"rendered":"https:\/\/blog.chrisse.se\/?p=1100"},"modified":"2024-08-19T13:58:15","modified_gmt":"2024-08-19T11:58:15","slug":"the-active-directory-database-epoch-copy-protection","status":"publish","type":"post","link":"https:\/\/blog.chrisse.se\/?p=1100","title":{"rendered":"The Active Directory Database Epoch \/ Copy Protection"},"content":{"rendered":"\n

This blog post will describe and go into details about the may not so known Active Directory Database Epoch \/ Copy Protection.<\/p>\n\n\n\n

This concept that was introduced with Active Directory Application Mode) ADAM initial release (Now follows some ADAM history), but never made it to Active Directory Domain Services (AD DS) until Longhorn\/WS2008 for some good reasons. One of the changes with Windows Server 2008 was that AD got exposed as a windows service allowing admins to stop, restart and start the service on DCs, this behavior already existed since day one in Active Directory Application Mode (ADAM ) first introduced as a standalone package to the web in November 2003 and was also targeting Windows XP, in Windows Server 2003 R2, Active Directory Application Mode (ADAM) Service Pack 1 (SP1) is included as a windows component (On CD2) but still ship as a download for other operating systems, Active Directory Application Mode (ADAM) Service Pack 2 (SP2) is the latest version to ship except some QFEs and Security Updates before the source code of Active Directory Application Mode (ADAM) merges into the Directory Service (DS) source depot, integrates into windows builds and get\u2019s available again with Windows Server 2008\/Windows 7 rebranded as Active Directory Lightweight Directory Service (AD LDS) \u00a0as an installable role with the operating system \u2013 no more downloads are available.<\/p>\n\n\n\n

The potential issues and damages that this feature is trying to protect from, given the above.<\/strong><\/p>\n\n\n\n

Pre-Windows Server 2008 and ADAM it wasn\u2019t that easy to manually restore or replace the database (DIT) using none supported restore methods for let\u2019s say average sysadmins \u2013 you needed to boot into DSRM \u2013 Directory Services Restore Mode cause the DB was locked by LSASS\/ESE and the database by default was located under C:\\Windows folder.<\/p>\n\n\n\n

Now with these requirements gone as peer Windows Server 2008 and ADAM\/AD LDS \u2013 Microsoft wanted to prevent some scenarios:<\/p>\n\n\n\n

Potentially foreseen scenarios:<\/strong><\/p>\n\n\n\n

\u2022 Stop service, copy off database, restart service, make changes that replicate, stop service, copy old database back in.<\/p>\n\n\n\n

\u2022 Stop service, copy off database from instance1, stop second service, copy database over data files for instance2.<\/p>\n\n\n\n

Both these scenarios breaks the Active Directory replication model, because two different\/distinct changes could get the same <OriginatingInvocationID>:<OriginatingUSN> pair (lets call this the ChangeID).  If two changes have the same ChangeID, one of those two changes would fail to replicate, because the DSA will claim to have \u201cseen\u201d the change with the same ChangeID, from the previous instance of the database, and fail to replicate the new change with this ChangeID.  Also, other partners of this instance, will assume they\u2019ve seen any new changes made that match previous changes this DSA has replicated out.<\/p>\n\n\n\n

The implementation<\/strong> \u2013 a database epoch stored in both in the database (DIT) and the registry, during initialization of the DSA and the DB a random value is written in case of a none-existent epoch or the current epoch +1 is written both to the database (DIT) \u2013 more specifically to the  \u201cepoch_col<\/strong>\u201d column in the hiddentable<\/strong> and the \u201cHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\Parameters\\ DSA Database Epoch<\/strong>\u201d Registry DWORD.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Rules are as following<\/strong><\/p>\n\n\n\n

    \n
  1. If both the registry and the database have NULL \u2013 it\u2019s considered a match. The epoch is initially set with rand() in both the database and the registry<\/li>\n\n\n\n
  2. if the value stored in the database is > than the value stored in the registry \u2013 it\u2019s considered a match.<\/li>\n\n\n\n
  3. If the value stored in the database and the registry match \u2013 it\u2019s considered a match<\/li>\n\n\n\n
  4. If either 2 or 3 the epoch is advanced by 1 in both the database and the registry, if any of the updates fail the ESE update to the DIT is rolledback.<\/li>\n\n\n\n
  5. If the \u201cHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NTDS\\Parameters\\ Disable DSA Database Epoch Check<\/strong>\u201d Registry DWORD is set to 1<\/strong> it\u2019s considered a match.<\/li>\n\n\n\n
  6. If the values do not match as per above 1-3, a \u201crestore\u201d is forced to get a new invocationID for the DSA\/DRA and the following event is logged:<\/li>\n<\/ol>\n\n\n\n

    Table 1: Epoch mismatch and restore initiated.<\/p>\n\n\n\n

    Event ID<\/td>Source<\/td>Category<\/td>Description<\/td><\/tr>
    2524<\/td>ActiveDirectory_DomainService<\/td>Backup<\/td>The Directory Server detected that the database has been replaced.  This is an unsafe and unsupported operation.   User Action: None.  Active Directory Domain Services was able to recover the database in this instance, but this is not guaranteed in all circumstances. Replacing the database is strongly discouraged.  The user is strongly encouraged to use the backup and restore facility to rollback the database.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    The \u201crestore\u201d is forced by writing\/setting the \u201cstate_col<\/strong>\u201d in the \u201chiddentable<\/strong>\u201d to \u201c4<\/strong>\u201d aka \u201cBackedupDIT\u201d as well \u201cuns_col\u201d to next USN-1 and \u201cbackupexpiration<\/strong>_col\u201d to the next day.<\/p>\n\n\n\n