Non-Authoritative Restoration

Used most commonly in cases when a DC because of a hardware or software related reasons, this is the
default directory services restore mode selection. In this mode, the operating system restores the domain
controller’s contents from the backup. After this, the domain controller then through replication receives
all directory changes that have been made since the backup from the other domain controllers in the
network.

Example: You had hardware problems on a DC and you solved them after re-installing the DC OS. You
can use a non-authoritative restore so that you don't delete recently made changes.

Authoritative Restoration
An authoritative restore is most commonly used in cases in which a change was made within the directory
that must be reversed, such as deleting an organization unit by mistake. This process restores the DC from
the backup and then replicates to and overwrites all other domain controllers in the network to match the
restored DC. The especially valuable thing about this is that you can choose to only make certain objects
within the directory authoritative. For example, if you delete an OU by mistake you can choose to make it
authoritative. This will replicate the deleted OU back to all of the other DC’s in the network and then use
all of the other information from these other DC’s to update the newly restored server back up to date.

Exemple: You accidentally deleted an AD user and you want to restore it. You can use an authoritative
restore to perform that.

Below is In Brief Explanation:

As everyone's saying, and just to add, with a non-authoritative restore, you're simply restoring
AD with a sytem state restore. If there are more than one DC, and you had deleted an object,
that object will remain deleted, even after a non-authoritative restore. If it's a single DC (such as
SBS or just one non-SBS), you can restore a backup prior to the deletion to restore it. But if there
are more than one DC, and you run a non-authoritative restore expecting to bring the object
back, it won't, because the replica DC will replicate the fact that it was deleted.

TO understand this better, keep in mind, that each DC knows of each object, as well as of replica
DCs's USN value. THat is the Update Sequence Number. Whenever a change occurs
(add/delete/modify, etc), the USN value will change. Each DC keeps track of other DCs USNs.
If a DC see a USN was changed on another replication partner DC, it will ask for the changes
(replication), then the change will replicate. Each DC has a overall USN, as each object in the
directory.
If you want to re-animate an object in a multi-DC scenario, you can run an authorative restore.
During this process, with Windows 2003 and newer, as mentioned, you run a non-authoritative
first, and while still in DSRM (Dir Svc Restore Mode), don't restart the DC yet. Before you restart
the DC, you want to use ntdsutil to perform the authoritative by identifying the DN of the
object, and the system will bump up the USN value of that specific object to a value much
higher than other DCs would have for that object, and then restart. Upon
restart, during replication, the other DCs will see that that object has a higher USN than it
previously had, therefore will reanmate it.

IIRC, in Windows 2000, we had to manually bump up the value by adding 100,000 to theobject's
USN in ntdsutil. But as mentioned above, that was changed with Windows 2003 and newer
where it's now done automatically for you.

Read the links that the others provided. They give more info about restoring specific leaf
objects, OU subtrees, etc. Please note, that with a single DC environment, and if you were to
perform an authoritative restore of the whole directory, you may inadvertently cause issues
because you may be restoring the previous secure channel password, which then the current
machines in the domain will no longer communicate with that DC.