Host DKE on IIS, using an on-premises server

[Martin_Sieber]

This blog post is intended to show how to publish Double Key Encrytion (DKE) reference implementation in an on-premises Windows Server with IIS – keeping full control over the key and the service.

Double Key Encryption (DKE) is a new feature, which enables customers to protect their most confidential content using a key they control, thereby allowing them to comply with regulatory requirements. DKE ensures that Microsoft cannot access their data under any circumstances.

The quickest way to get the DKE reference implementation running is by publishing it to Azure – detailed steps can be found in our documentation . However, many of our customers prefer to test and run DKE on-premises – here we describe the necessary steps to implement this option.

For this post, we assume the server will be reachable under the following URL:

https://aip-dke4.contoso-o365.net
(Make sure the DNS domain of the URL used is registered on your Azure AD tenant.)

Preparation

Whether the DKE service is published on Azure or on IIS, the following preparation steps from our documentation are required:

1. Install software prerequisites for the DKE service
2. Clone the Double Key Encryption GitHub repository
3. Modify application settings
4. Generate test keys
5. Build the project
   
   

Provision machine and build IIS

By going through the following steps, the virtual machine is provisioned and IIS is installed:

1. Provision VM with Windows Server 2019 Datacenter.
2. Make sure the VM has outbound Internet Connectivity (among other, it needs to reach the following URL: <https://login.microsoftonline.com/common/v2.0>), for an exhaustive list of URLs and IP addresses, please consult box 56 on our documentation:URLs and IP addresses that need to be reachable
3. Join the server to a domain, in case membership of a local AD group should be the criteria for authorizing access to the DKE service.
4. Install a suitable Web server certificate to the machine store. The certificate needs to match the URL, under which the service can be reached.
   Certificate used for IIS
5. Install IIS with with default role features – selecting «Next» on each page of the wizard.
   
   
6. Download and install the latest .NET hosting bundle. The bundle is available here.

Build and publish code to IIS

1. Switch to the machine with Visual Studio Code installed, which was used for steps 1 to 5.
2. Open an administrative command line and switch to the directory «DoubleKeyEncryptionService\src\customer-key-store»
3. Run the following command:
   dotnet publish --configuration Release
4. Transfer the following directory to the folder c:\ of the IIS machine – this will result in a new folder c:\publish on the IIS machine:
   «DoubleKeyEncryptionService\src\customer-key-store\bin\Release\netcoreapp3.1\publish»
5. On IIS, create a new web site «DKE» with https binding, port 443 and using host name "aip-dke4.contoso-o365.net":
   IIS site configuration
6. Make sure the value for «JwtAudience» matches the selected URL for the IIS Server:
   

Finish DKE implementation

The following steps are needed to complete the DKE implementation (refer again to our documentation)

7. Validate your deployment

8. Register your key store

9. Create sensitivity labels using DKE

10. Enable DKE in your client

11. Migrate protected files from HYOK labels to DKE labels

Conclusion

By publishing the DKE service on an on-premises server with IIS, customers maintain full control over the key used for protecting their most sensitive content.

[Peter Forster]

Hi,

thanks for that.

Question about High Availability: What happens when this service is due to malfunction or any other disaster not available. What are the issues cause by that?

[Martin_Sieber]

If the DKE service is unavailable, clients may not be able to open DKE protected content. It's suggested to host multiple instances of IIS and put a hardware load balancer in front of these instances. Since the DKE service is stateless, session affinity is not a concern.

[LudwigW]

Hi @Martin_Sieber and thanks for the very detailed description on this topic.

Could you, as an extension to this one, elaborate a little bit on how the rekeying will work. On the Azure Information Protection Service Microsoft is doing this on their own schedule and Microsoft is making sure the old keys are still available for opening old documents.

But how will I do that in case of DKE? If I change the PublicPEM and PrivatePEM entries in my appsettings.json file I assume I will no longer be able to open old stuff. What is an Microsoft prefered and supported way to have new keys?