Introduction to Remote File Server File encryption

 

On the Forum these two days, some netizens asked, "Can you use some simple methods to protect private files/folders on the file server? Because you don't want other users to browse some files in their shared folders! ".

To meet this requirement, the file server administrator usually creates a subdirectory under a large directory shared on the file server and then modifies the NTFS permission. however, if common domain users want to control the security and privacy of their file files more flexibly and simply, the permission overlay or setting is hard for them to master.

In fact, for a large number of enterprises that use Windows XP as the client and Windows server 2003 or above as the file server operating system and have a domain environment, enabling users to use EFS to encrypt private data stored on remote servers has become an alternative solution. after all, the transparency and simplicity of EFS for user operations are more advantageous than other solutions.

Next, let's take a look at how to configure EFS to encrypt files on remote file servers.

I believe that my friends who have read my previous blog post

Encryption failed

Here I use a common domain user account named "cfo" to log on to the client (IP: 172.16.0.201), first on his file server (IP: 172.16.0.101, FQDN: contoso-sccm.contoso.com) to access the shared folder (shared name test, cfo has full control of its permissions) to do a disk ing, and then try to encrypt the files in EFS, you can see

Figure 1

The system prompts "An error occurred during application properties" and an error occurred while trying to encrypt the data.

Delegate task

In fact, it is inevitable that the remote server is not trusted and authorized by the user, at the same time, it does not own the user's certificate and key (if you do not understand the concept of the certificate and key, please read my previous blog ), how can we easily implement encryption in place of users.

Therefore, we need to first delegate the action to the remote server to the domain control,

Open "Active Directory users and computers", find the machine name of the file server, right-click "properties", and click the "delegate" tab, select "trust this computer only to delegate the specified service", click "add", click "user and computer", browse to the file server, and click "OK ", A list of available services appears. Select "cifs" and "protectedstorage. after the operation, restart the file server.

Figure 2

Certificate and key

After the delegated operation is completed, it is equivalent to authorizing the server to execute some (or all) service on behalf of the user. what needs to be done below is to let the file server have the certificate and key of the domain user. there are two methods for this step,

1. log on directly to the file server using the domain user account once, and encrypt a file at will, so that the certificate and key of the domain user can be generated.

2. When the domain user owns the user's Roaming configuration file (Roaming Users Profile), he can directly download the RUP to the corresponding location on the file server. (This step is omitted. Due to my experiment environment problems, I chose the first method to obtain the user certificate and key ).

After completing the above operations, we try to use EFS on the client to encrypt the shared documents on the remote server.

The error is returned in Figure 1. At this time, we may wish to go to the file server to see if there is any relevant information.

Run eventvwr. msc on the file server to open the Event Viewer. An error message is displayed:

Figure 3

This is because EFS does not support the NTLM authentication protocol, but can only use the Kerberos protocol.

Authentication Protocol

So how can we see what identity authentication protocol is used for network sharing the account logged on to the client?

This is also recorded in the Event Viewer:

Figure 4

Cfo uses the NTLM protocol for identity authentication.

To convert it to Kerberos protocol, we need to locate the shared folder in \ FQDN mode and then map the disk. remember: for Kerberos to work properly, all communications must use a fully qualified domain name (FQDN ).

Therefore, make sure that the DNS server in your domain runs properly.

Log records

Similarly, after the Kerberos protocol is used for authentication, the event log will also have corresponding records:

Figure 5

File encryption

Let's try to encrypt the files on the remote server:

Figure 6

We can see that the EFS method can be used to encrypt files on the remote server.

To sum up the general steps of using the EFS delegate mode to encrypt files on the remote server:

1. Authorize and restart the remote server on the domain control. (For security reasons, only two services are assigned and will not be repeated. For details, see the text)
2. Generate the user's profile and private key on the remote server (the two methods are not repeated. For details, refer to the text)
3. Use the \ FQDN name to access the shared folder and map the disk to the local device (required)

There are still some notes:

1. For domain users who want to use EFS encryption of remote servers, be sure to clear the "sensitive account, cannot be delegated" check box in their account attributes.

2. Remote encryption does not support cross-Forest delegated server mode. To use this solution, the delegated server and user account must be in the same domain.

3. EFS can only encrypt data stored on disks. data is still not encrypted when data is transmitted over the network. therefore, to ensure data security during network transmission, you may need to use the IPsec or EFS over WebDAV mode.

4. when multiple users have sufficient permissions for a folder, when one user uses EFS to encrypt some files, other users will no longer be able to access these files. in view of this, please plan the use of remote EFS encryption and describe the correct use cases for users. to prevent this, set the EFS domain recovery proxy in advance.

5. Although self-signed user certificates can be used in the domain, the best practice for certificates is to create a CA server to obtain a PKI environment that is integrated with the Active Directory.