Document directory
How to protect the security of important data files in a domain environment (I) --- EFS encryption (I) this article reviews how to use EFS encryption to protect important data files. I believe that through the demonstration, we are also satisfied with the EFS effect. If you are a brother, you are ready to promote and deploy it in the production environment. oh, don't worry. Listen to me more.
When using EFS in a production environment, you need to consider the following very practical issues:
1. Export and backup of User Certificates with keys
Because EFS is easy to use, many people may use it. however, the more people using EFS, the more difficult it is to manage user certificates and keys. It is certainly not feasible to not back up certificates and keys. If a system failure occurs, you must redo the system or delete the user account, it is a very troublesome task. You need to consider the security location where the exported data is stored. It cannot be stored in the user's disk to make it easy to find it.
2. Users should be prevented from inadvertently or maliciously encrypting shared files.
For example, on the eve of his resignation, an employee encrypted a lot of important information on the office computer with EFS. Instead, he patted his ass and went to the meeting to use the information, his domain account was killed by the itmanager. At this time, his successor may suffer. in fact, the domain account is okay, the network administrator can also execute authorization from the AD backup back (please refer to: http://mrfly.blog.51cto.com/151750/191430), if the employee is using their own local account, and then deleted, it's not that easy. therefore, in your environment, if the user account has too many permissions, you need to consider them carefully.
3. EFS is a system application launched by Microsoft for a long time. Because of its long history, its algorithms and encryption processes have been cracked by computer experts, so the Internet also spread a lot of cracking tools (interested friends can see the http://www.cctips.com /? P = 39 ). if your environment does not effectively prevent "caring" people from using the software on others' computers (including technically and administratively ), there is a chance to unbind the encrypted file.
Therefore, in the previous discussion section, the friendship between brother Hu reminds everyone to understand it with great care.
In fact, in the domain environment, we still have some technical means to ease the above problems.
Now, we will introduce you to the EFS Recovery Agent.
EFSRA, to put it simple, is equivalent to one or more people trusted by users. They hold a universal key in their hands and hold the key, attackers can decrypt any files that trust them or their users using EFS encryption.
In the earlier Windows 2000 pro/server System in the working group environment, the default EFSRA is the administrator account administrator, windows 2000 machines without domains cannot be found at the moment ). this means that even if the above mentioned situation occurs, you can use administrator to open any user's encrypted file. this may cause some problems. For network administrators, they may not have to think about whether to back up the user's private key, and the security of user-encrypted files is not high. so in the xp pro/Windows server 2003 era, Microsoft corrected that the Administrator account in the working group environment is no longer the default EFSRA.
Here, I open an XP SP3 computer that has not yet added a domain, encrypted a file using a local administrator account, and then looked at its EFS recovery proxy in the properties. We can see that it is indeed blank, no proxy account is restored.
Now I want to add this machine to the domain.
Use the cto account used in the previous article to log on.
Check the EFSRA information in the file attribute encrypted by the local administrator. The information remains blank.
Create a new file and encrypt it. Check the properties...
You can see that there is an EFSRA, and it is also the administrator, which is automatically added in.
However, this administrator is not the certificate of the local administrator account on the computer, but the domain administrator. It can be automatically added because the default domain group policy takes effect.
Let's take a look at DC.
Open the Default Domain Policy, and find "Computer Configuration" --- "Windows Settings" -- "Security Settings" -- "Public Key Policy" --- "encrypted file system"
We can see that there is a certificate named "administrator", which is expected to be "file fault recovery ".
Double-click this certificate
Browse to the Details tab
Take a closer look at the certificate thumbnail number. (if it is on Windows server 2003, it is called a certificate fingerprint)
AD:
On the client:
Prove that the two are the same object.
So how can we use EFSRA to decrypt users' encrypted files?
Simulated scenario:
The cto domain account has been deleted and cannot be restored. on Windows XP pro, all files encrypted by cto using EFS cannot be opened (including logon using the local administrator and domain administrator accounts ), EFSRA is the domain administrator.
We started the rescue operation and first exported the EFS recovery Proxy Certificate and key on the DC.
Be sure to select and export the Private Key together.
The remaining process diagram is similar to the previous demonstration.
Log on to the client using the domain management account. Import the certificate you just exported.
After the import is successful, try again to view files that cannot be accessed just now.
You can see the files encrypted by Mr. cto ~
The operation process is really simple, isn't it?
What's more, if there is such a real God in the domain, do you feel at ease as a system administrator?
We can use the built-in domain administrator account Administrator and his private key certificate to decrypt the files encrypted by any domain account. However, in actual management, this operation may not be very convenient, because regular enterprises generally require the establishment of corresponding domain accounts for employees, and even network administrators are no exception, therefore, the account we use at ordinary times is basically not the built-in domain administrator account administrator. For example, if my account is jrfly331, can we set our self-built account and the corresponding user certificate as a recovery proxy? The answer is yes. Let's see how to do it.
Go to DC, or open the default domain policy, and find "Computer Configuration" --- "Windows Settings" -- "Security Settings" -- "Public Key Policy" --- "encrypted file system ", right-click it,
Select "add data recovery agent", skip the wizard screen and you will see
Note the highlighted part. Clearly, if the user certificate you want to add has been published in ad, you can directly select "Browse Directory". If it is not published in ad, you must manually specify the user certificate file (. CER format ).
Let's take a look at the method specified manually.
Use my domain account jrfly331 to log on to any client. At this time, the files encrypted by CTO cannot be viewed.
Let's call up the CMD command prompt and enter cipher /?
As you can see, cipher is actually a command line method that uses EFS encryption. there are a lot of parameters. You can take a closer look. It is not difficult to find that, in fact, all the operations in the previous article can basically be done using cipher.
Here we pay special attention to the/R parameter
The. Cer file can be generated in this way.
Continue
Both certificates are generated.
Copy the. Cer certificate to DC, open the add data recovery agent, and find it.
After the import, we can see that jrfly331 has become efsra.
The remaining steps are the same as before. Import the jrfly331 Private Key Certificate on the client.
Use gpupdate/force to refresh the Group Policy
Click the encrypted cto file that cannot be accessed again.
You can view it.
View File Attributes
The figure of jrfly331 is displayed in the encryption proxy.
(If you still cannot view the encrypted file during the test, you need to check whether your group policy has been updated on the client. Because my experiment environment is used, it is faster)
Due to the limited space, as for how to publish the user certificate to the Active Directory and then select "Browse Directory" when "add data recovery agent", let me simply talk about the process:
First, copy the "EFS fault recovery proxy" template from the "Certificate template" on the CA server.
Select release to AD in the new template attributes, add an account in "security", and allow it to register
Create a certificate Template
Enable the new template Just configured
Go to the certmgr. msc certificate control unit on the client and apply for a new certificate.
Select certificate category
Import, we can see that the issuer of the two certificates is different
At the same time, we can also find users with certificates through the directory on the DC.
I don't need to talk about the rest of the work. I have demonstrated it before.
Summary:
After reading these two articles about EFS, I believe you will think about using EFS in the domain environment.
The effect of EFS is remarkable, and the shortcomings are also obvious. If we want to use it to enhance the security of documents and materials, we must do a good job in the early stage of planning and preparation, this includes the backup and storage of user certificates, including the design and implementation of fault recovery. in addition, the final solution will definitely combine EFS with NTFS permissions. who is allowed to decrypt and undo what he can do ......
As he said, it seems that Microsoft does not mention EFS much now. This is also because of the continuous emergence of new products and technologies. now, we must keep pace with the times. You are welcome to watch the content after this series-how to protect the security of important documents in the domain environment (2), and I am looking forward to it ~
Reproduced http://mrfly.blog.51cto.com/151750/192026