(2007-09-09) Is Your Authoritative Restore Being Undone?

Some time ago you create a System State backup and now you are using that same backup to restore one or more objects that got deleted. You perform the non-authoritative restore by restoring the System State in DSRM and perform the authoritative restore using NTDSUTIL. You reboot the DC in normal mode and object are gone again. Your authoritative restore is being undone. Man that sucks, what’s going on?!

I’m not going to explain how to do an authoritative restore. More information on that can be found in MS-KBQ840001. I’m going to explain how this can happen.

One thing to remember:

• Restore <object | subtree> "<object DN>" à increases the version of the specified object(s) with 100.000
  
• Restore <object | subtree> "<object DN>" verinc <version increase> à increases the version of the specified object(s) with what is specified in <version increase>
  
• The used System State backup must not be older than the configured tombstone lifetime of the AD forest
  
• More than one DC exist in the AD domain
  

There are two scenarios known to me where an authoritative restore on object(s) is undone…

(1) More changes occurred on the object that is restored using an old System State backup than the version increase during the authoritative restore

Imagine some object in AD (e.g. Object-X) which has version 10. On a DC you create a System State backup and that object is included in the backup. Object-X in the backup also has version 10. The moment of the backup is t=0. After the backup, for whatever administration purpose, Object-X is changed a lot of times. Because of all those changes, Object-X now has version 100.011. While managing AD an administrator makes a mistake and deletes Object-X (version now is 100.012). You want to restore Object-X and you want to use the backup from t=0 to achieve that.

Using the procedure for an authoritative restore as mentioned in MS-KBQ840001, you do a non-authoritative restore followed by an authoritative restore. You boot the DC in normal mode, and while you think Object-X has been restored it is gone again. So, what may have happened here?

For this scenario during the authoritative restore the following may have happened…

(a) You used: Restore <object | subtree> "<object DN>"

Remember that will increase the version of the object with the default value of 100.000. The version of Object-X in the System State backup is 10 and after the authoritative restore it will have version 100.010. Remember the deleted object has version 100.012. In this case the restore object will be gone again. The version of the tombstoned object is higher!

(b) You used: Restore <object | subtree> "<object DN>" verinc <version increase>

The version of Object-X in the System State backup is 10 and after the authoritative restore it will have version <version increase> + 10. Remember the deleted object has version 100.012. So if the value specified for <version increase> is lower than 100.012 – 10 = 100.002 the restored object will be gone again. The version of the tombstoned object is higher!

(2) The object is restored multiple times using the same System State backup

Again imagine some object in AD (e.g. Object-X) which has version 10. On a DC you create a System State backup and that object is included in the backup. Object-X in the backup also has version 10. The moment of the backup is t=0. After the backup, for whatever administration purpose, Object-X is changed a lot of times. Because of all those changes, Object-X now has version 1000. While managing AD an administrator makes a mistake and deletes Object-X (version now is 1001). You want to restore Object-X and you want to use the backup from t=0 to achieve that.

For this scenario during the authoritative restore the following may have happened…

You used: Restore <object | subtree> "<object DN>"

Remember that will increase the version of the object with the default value of 100.000. The version of Object-X in the System State backup is 10 and after the authoritative restore it will have version 100.010. The deleted object has version 1001, so the restored object wins and Object-X is in AD again. The deletion has been undone. The object is changed again a few times and because of that the object now has version 100.100. Another administrator that was not paying attention mistakenly deletes Object-X (version now is 100.101). That administrator does not want his a$$ kicked for making that mistake and tries to restore the object using the backup that was taken at t=0.

To restore the object he uses: Restore <object | subtree> "<object DN>"

Remember that will increase the version of the object with the default value of 100.000. The version of Object-X in the System State backup is 10 and after the authoritative restore it will have version 100.010. The deleted object has version 100.101, so the restored object looses and Object-X is not restored into AD.

This happens because the object was already restored once using the same backup. Now that is not a terrible thing to do. You just need to make sure the System State backup is not older than the tombstone lifetime of the AD forest. The command line that the administrator should have used is: Restore <object | subtree> "<object DN>" verinc <version increase> where <version increase> is higher than 100.101-10 = 100.091. So if the administrator for example specified: Restore <object | subtree> "<object DN>" verinc 200.000, the object would have been restored.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————