Active Directory disaster recovery using backup

This article is from the "Active Directory Series", yue lei's Microsoft Network Class

 

In the previous blog, we introduced how to deploy the first domain. Now let's take a look at what we can do with the domain. Computers in the domain can share user accounts, computer accounts, and security policies. Let's take a look at the changes these shared resources bring to us when allocating network resources. As shown in the experiment topology, we now have a simple task to assign the read permission of a shared folder on the Member Server Berlin to employee Zhang Jianguo of the company. In our last experiment, we created a user account for Zhang Jianguo. This time, we will look at how to use this user account to achieve the goal of resource allocation.

As shown in, right-click the folder tools on the Member Server Berlin and select "share and security" to share the Tools Folder.

Share the Tools Folder with the name "Tools" and click "permission" to grant the read permission of the Tools Folder to Zhang Jianguo only.

The default share permission of the Tools Folder is read-only in the Everyone group. Delete the default permission settings and click Add to grant the folder read permission to Zhang Jianguo.

As shown in, we chose Zhang Jianguo in the adtest.com domain as the carrier for granting permissions. Now we need to understand the meaning of the shared user account in the domain. After creating a user account for Zhang Jianguo on the domain controller, the member server can use these user accounts when allocating resources.

We granted the read permission of the Tools Folder to Zhang Jianguo.

Log on to the tools shared folder on Berlin as the domain administrator, as shown in. The domain administrator has no permission to access the shared folder. This result is consistent with our permission allocation. We only granted the permission of the shared folder to Zhang Jianguo.

As shown in, log on to Perth as Zhang Jianguo.

Zhang Jianguo visited the shared folder tools on Berlin, as shown in. As shown in, Zhang Jianguo successfully accessed the target resources and our resource allocation achieved the expected results.

After this experiment, we should think about why Zhang Jianguo was not asked for authentication when accessing the shared folder? This is a key question. The answer is this. When Zhang Jianguo logs on, the entered user name and password will be sent to the domain controller for verification. If the domain controller recognizes the user name and password entered by Zhang Jianguo, the domain controller will issue an electronic token for Zhang Jianguo, the token describes the groups that Zhang Jianguo belongs to. The token is equivalent to Zhang Jianguo's electronic ID card. When Zhang Jianguo accesses the shared folder on Berlin, the Berlin daemon checks the visitor's token and compares it with the access control list of the accessed resource. If the two match, for example, the shared folder on Berlin in this example allows Zhang Jianguo in the domain to access, and the visitor's token proves that he is Zhang Jianguo in the domain, then, visitors can access resources transparently without any other authentication.

We can imagine the assignment of domain-based permissions. Every morning after employees go to work, they enter the user name and password on their computers, and then the domain controller authenticates and issues the token, after obtaining the token, employees can transparently access various authorized resources in the domain, such as shared printers, shared folders, databases, and email addresses. In addition to entering a password at login, employees do not need to enter a password when accessing resources in the future. Is this domain-based resource allocation method extremely efficient and flexible?

But what if the domain controller is broken ?! If the domain controller is damaged, the user cannot obtain the token upon login. Without the token, the user cannot prove his identity to the member server, can the user still access resources in the domain? The result is self-evident. The resource allocation of the entire domain tends to crash. The consequences are very serious. How should we prevent such catastrophic consequences? We can consider backing up the Active Directory and deploying the out-of-scope domain controller. Today we will first look at how to use the backup of Active Directory to achieve disaster reconstruction of the domain controller.

If there is only one domain controller, we can use the backup tool provided by windows to completely back up Active Directory. In this case, the domain controller has a length of three, two, two, and two, backup can help us out of the predicament.

On Florence, choose Start> program> attachment> System Tools> Backup, as shown in. The Backup Recovery wizard is displayed. Click Next to continue.

Select the backup file and settings.

Instead of backing up all information on the computer, we only back up Active Directory, So we manually select the content to be backed up.

As shown in, we chose to back up system state, which contains active directory. In fact, we only need the Active Directory, registry and sysvol in the system state, but the backup tool does not allow more detailed division of granularity, So we choose to back up the entire system state.

Back up the system state in the C:/adbak directory.

Click Finish Backup Settings.

As shown in, backup starts. After the backup is complete, copy the backup file to the file server and save it.

Well, after the backup is complete, we assume that the domain controller Florence has a physical fault. Now we use another computer to replace Florence. As shown in, the new computer is also named Florence, and the IP settings are consistent with those of the original domain controller. In particular, DNS must be directed to adtest. the DNS server provided by COM for resolution. In this example, It is 192.168.11.1. In addition, the new computer does not need to create active directory. We can recover the Active Directory from the backup.

Copy the backup of system state from the file server to the new Florence, and start the backup tool, as shown in, and select next to continue.

This time, we choose to restore the file and set it.

As shown in, click the Browse button to select the C:/adbak/backup file to be restored. BKF, the backup tool shows backup. BKF's catalog content, select system state as the content to be restored, and select next to continue.

After completing the restore settings, click Finish.

As shown in, the restoration starts. After the restoration ends, we can restart the computer to recreate the Active Directory.

After you restart Florence, as shown in, we found that active directory has been restored.

The role of Florence has also changed.

Attempt to log on to the domain user. Everything is normal. Now, active directory has been restored!

If the only domain controller in the domain has a physical fault, the allocation of resources in the entire domain will crash. Therefore, it is necessary for us to take precautions. Using backup tools to back up the Active Directory database, and restoring the Active Directory with backup content when the domain controller crashes is a frequently used disaster recovery method by engineers. This solution is simple and suitable for small enterprises. I hope everyone can master this basic method. Next we will introduce how to solve fault tolerance and performance problems of Active Directory by deploying a remote domain controller.

This article from the "yue lei's Microsoft Network Classroom" blog, please be sure to keep this source http://yuelei.blog.51cto.com/202879/116181