Active Directory Restore

This may take a while so only read if you have a cuppa and some spare time, but most of all will be willing to explain this in detail..

I'm testing AD restores to figure out the difference between non-authoritative and authoritative restores.

I have this scenario at the moment...

I wanted to restore just an OU that I created called TestOU, and from what I can see, you need to do a non-authoritative restore. I did the following..

1) Created an OU called TestOU
2) Did a system state backup
3) Created a user called TestUser (to see what would happen when I do a system state restore, if it would remain or be overwritten)
4) Rebooted the Server and pressed F8 to go into ADRM.
5) Did a non-authoritative restore with the default options over the current sysvol data.
6) Rebooted and pressed F8 again to get into ADRM
7) Brough up ntdsutil and ran the following commands..

authoritative restore > restore OU=TestOU,DC=testdomain,DC=local

I then rebooted the Server into normal mode and voila!! The TestOU had now returned.....HOWEVER...the TestUser had now dissapeared which had clearly been overwritten by the initial non-authoritative restore.

My "theory" here is that because i'm running just a singular SBS Server, that the old records would replicate back from the other domain controllers that would have TestUser in their database, is this right, or have I simply done something wrong in the restore process?

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Hyper-Me

The effects on trusts and computer accounts when you ...

When other domain controllers exist and an authoritative restore is performed, any objects that were created in the naming context after the backup will remain in Active Directory.

For example, one possible scenario is as follows:
On day 1, the administrator performs a backup of the system.

On day 2, the administrator creates a user named "User Two" and this data replicates to other domain controllers in the domain.

On day 3, the user named "User One" is unintentionally deleted.

On day 4, an authoritative restore of the domain controller is performed with the backup created on day 1.

Therefore, both User One and User Two exist within the domain.

Excellent question, btw. I think its those people that ask questions outside of what the book just teaches you that make effective admins.

dynamik

mr2nut wrote: »

My "theory" here is that because i'm running just a singular SBS Server, that the old records would replicate back from the other domain controllers that would have TestUser in their database, is this right, or have I simply done something wrong in the restore process?

Would they? Didn't you mark the empty OU that you restored as authoritative?

mr2nut

Ahh, don't think I explained the TestUser bit very well..

I created this user inside the standard "Users folder" (so not an OU) it wasn't created in the OU. I could understand it being overwritten by the backup if it was inside that TestOU but it wasn't?

dynamik

So yes, it would replicate back over from another server.

mr2nut

dynamik wrote: »

Would they? Didn't you mark the empty OU that you restored as authoritative?

Correct, I marked JUST the TestOU as authoritative rather than simply typing "authoritative restore database" which would restore the lot, so that's why i'm confused as to why it has made the TestUser dissapear.

I have now read somewhere that you should do the following...

a) When restoring just an OU, you would do a non-authoritative restore and then WITHOUT rebooting, go straight into an authoritative restore (I actually rebooted inbetween the non auth and auth restores but didn't allow a Windows boot, just into ADRM, but this may have been the cause??)

b) You never need to do an authoritative restore with a single DC (i.e. SBS) as nothing else will overwrite what you restore anyway. The weird thing here is, there doesn't seem to be an option with the non-auth restore to just restore an OU like you can do with the auth restore from ntdsutil cmd?

mr2nut

dynamik wrote: »

So yes, it would replicate back over from another server.

But in my case, as I only have one Server it will never get this user back from another Server, so I have clearly done something wrong here..

dynamik

What's the difference between an authoritative and non-authoritative restore?

Given that, how does that effect your situation if you only have a single server?

mr2nut

dynamik wrote: »

What's the difference between an authoritative and non-authoritative restore?

Given that, how does that effect your situation if you only have a single server?

This a trick question? Authoritative marks the section with a far higher USN to that it overwrites all other DCs with the information and non-authoritative is the reverse.

I have read that you would never need to do an authoritative restore on a singular Server as nothing else will try overwrite it, but when doing a normal non-authoritative restore with ntbackup I can't see an option just to restore a single OU?

dynamik

Sounds like you should keep current backups in that type of scenario

Third-party products such as Backup Exec might allow more granular restores; I haven't looked into that specifically.

rwwest7

mr2nut wrote: »

This a trick question? Authoritative marks the section with a far higher USN to that it overwrites all other DCs with the information and non-authoritative is the reverse.

I have read that you would never need to do an authoritative restore on a singular Server as nothing else will try overwrite it, but when doing a normal non-authoritative restore with ntbackup I can't see an option just to restore a single OU?

You do a restore then use ntdsutil to mark your desired OU as authorative. You can't do it from ntbackup.

mr2nut

rwwest7 wrote: »

You do a restore then use ntdsutil to mark your desired OU as authorative. You can't do it from ntbackup.

See this is the bit that confuses me... When it ntdsutil, say you wanted to restore an OU that had been deleted by mistake.......where exactly does it look for the deleted OU. Surely you have to point it somewhere? Thats why I did an ntbackup restore of the system state so that the ntdsutil authoritative restore could actually find the OU to restore.

Perhaps my mistake here was rebooting inbetween the non-auth restore and the auth restore as most procedures on the net specially say in bold Do not restart, click no then do the auth restore. Hmmm..

mr2nut

Hyper-Me wrote: »

The effects on trusts and computer accounts when you ...

Excellent question, btw. I think its those people that ask questions outside of what the book just teaches you that make effective admins.

Cheers. I like to try help others out too so here we go... I managed to do it successfully this time and thought i'd post my findings....

Here's my original test...

1) Created an OU called TestOU
2) Did a system state backup
3) Created a user called TestUser (to see what would happen when I do a system state restore, if it would remain or be overwritten)
4) Rebooted the Server and pressed F8 to go into ADRM.
5) Did a non-authoritative restore with the default options over the current sysvol data.
6) Rebooted and pressed F8 again to get into ADRM
7) Brough up ntdsutil and ran the following commands..
authoritative restore > restore OU=TestOU,DC=testdomain,DC=local

It restore the OU fine, but removed another 'testuser' I created in the default users folder (not OU) so it must have overwritten everything and THEN made the OU authoritative in case there were other DCs (but there weren't as it's a single SBS Server)

And here is my second attempt...

1) Created an OU called TestOU
2) Did a system state backup
3) Created a user called TestUser (to see what would happen when I do a system state restore, if it would remain or be overwritten)
4) Rebooted the Server and pressed F8 to go into ADRM.
5) Did a non-authoritative restore with the default options over the current sysvol data.
6) Clicked on NO to rebooting Server on the prompt *important step change*
7) Brough up ntdsutil and ran the following commands..
authoritative restore > restore OU=TestOU,DC=testdomain,DC=local

There you have it. All the other changes that were previously there from that day still remain (in a business it would have been awful to lose a ton of users if you had new staff for example) but it also restored the OU and the testuser within.

mr2nut

This make sense to people?

mr2nut

mr2nut wrote: »

This make sense to people?

Well??