Learn WIP with Joy – File Protection Deep Dive – Part 3

Hello! I hope you are all doing well and are safe along with your friends and family.

This is the last and concluding article on the Windows Information Protection series that I started, “Learn WIP with Joy!” If you have not read Part 1 and Part 2 of the series yet, I will urge you to read those in sequence 1st before continuing with this.

In the Modern Workplace, employee experience comes first. But information protection is also crucial. Finding the right balance is challenging for organizations. Strict measures can affect employee experience, while lenient measures leave security vulnerabilities. IT and security administrators must make tough decisions to balance these extremes, impacting employees’ workplace experience.

Today in this article, I will be taking you through the following topics

Patch My PC
  • the general flow of EFS file protection
  • any deviations when EFS is invoked by WIP
  • importance of DRA in WIP policy
  • WIP file protection when a file is copied to removable media
  • discuss the limitations of WIP

Let’s get started.

Index
[Recap] EFS – The components involved
EFS encryption process in a nutshell [Generalized]
Preliminary Requirement – Check for a public/private key pair
Actual encryption workflow of EFS
EFS encryption with WIP is not the same as EFS encryption in general
EFS encryption – How secure is the protection?
Importance of DRA
WIP file protection is persistent when files are moved/copied to removable media
WIP – Limitations
An Ending
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Table 1

[Recap] EFS – The components involved

I will continue from where I left off in Part 2 of this article series—EFS is the worker behind WIP file protection. Below is an overtly simplistic overview of the components responsible for the EFS functionalities.

Adaptiva
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.1
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.1

The main components of EFS are

Kernel Mode

  • NTFS File System
  • EFS Driver

User Mode

  • EFS service [runs within the LSASS process] (LSASS handles crypto key requests utilizing EFS functions)
  • CryptoAPI
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.2
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.2

As mentioned, this is a very high-level view of the components involved. Explaining the entire flow in detail is not the scope of this article. You can find good documentation on EFS over the internet, like this.

We focus on the working mechanism of EFS encryption rather than the components involved. Let’s start by uncovering the general process flow for EFS file encryption.

EFS encryption process in a nutshell [Generalized]

If you have read Part 2, you would know that EFS file encryption uses both symmetric and asymmetric keys. The symmetric key (FEK) is used for encryption/decryption of the file content whereas an RSA public/private key pair generated for the user account is used to protect the FEK, ensuring protection and restricting unauthorized file access.

A simplistic overview of the EFS encryption process is shown below

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.3
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.3

Preliminary Requirement – Check for a public/private key pair

On a Windows 10 endpoint, when you manually encrypt a file, either by

  • using File Explorer, marking the checkbox for Encryption from the Advanced menu of file Properties
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.4
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.4
  • using the cipher cmd line tool command: cipher /e <filename(complete path to file if not in present location)>

EFS checks to see

  • If the currently signed-in user account has a public/private key pair that can be used for EFS encryption. Basically, a check in the user’s Personal certificate store to see if it has any cert with EKU for EFS.
  • If no such key pair is found, EFS generates a public/private key pair (RSA 2048 bit) for the currently signed-in user account.

This results in a self-signed certificate (EKU is EFS) for the public/private key pair. The public key cert is added to the User Personal Certificate store as shown below. (%AppData%\Microsoft\SystemCertificates\My\Certificates)

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.5
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.5

The certificate thumbprint is also added to the registry under HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys where EFS uses it. You can see the same info using the Cipher cmd line tool command cipher /y Which shows you the public key cert thumbprint/cert hash currently used by EFS.

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.6
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.6

Actual encryption workflow of EFS

  • A log file called Efs(x).log (x is a unique number) is created in the System Volume Information folder on the same drive as the file to be encrypted.
  • NTFS sets the Encryption Flag and creates the $EFS attribute for the file to store the encryption information (DDF and DRF, explained in later steps)
  • EFS utilizes Windows’s CryptoAPI functionality to generate the symmetric key (FEK) for file content encryption/decryption.
  • EFS creates a Data Decryption Field (DDF) within the $EFS attribute of the file. The FEK is encrypted with the public key certificate of the currently signed-in user and placed in the DDF field.
  • If the WIP policy defines a Data Recovery Agent, EFS also creates a Data Recovery Field (DRF) within the $EFS attribute, where it places the FEK, which is encrypted with the DRA cert (public) as provided.
  • A temporary file, Efs0.tmp, is created in the same folder as the encrypted file. The original file’s contents (plain text) are copied into a temporary file, and then the original is overwritten with encrypted data.
  • After encryption is done, temporary and log files are deleted.

This entire process happens in the backend and, as such, is transparent to the end-user. The file gets encrypted when it is closed and automatically decrypted if the current user account has a private key matching the public key. To check the entire process in detail, please refer here.

EFS encryption with WIP is not the same as EFS encryption in general

On a Windows Information Protection enabled Windows 10 endpoint (both with and without enrollment) where you have not manually encrypted a file using EFS,

  • you will not find the self-signed cert in the User Personal Cert store. (there may be other user certs deployed by your organization reflected here)
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.7
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.7
  • you will not see the CurrentKeys reg_key under  HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\ and instead will have only entries for EDPCredentials
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.8
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.8
  • If you run the command cypher/y to view the EFS cert thumbprint that EFS is currently using, you will not get any output.

Let’s consider a WIP-enabled system where you also have files manually encrypted via EFS. Below, you can see I have two files

  • one is WIP protected, and
  • other is EFS encrypted manually
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.9
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.9

See the difference in file ownership?

  • WIP protected file is tagged to the Enterprise Identity as defined in the WIP policy for File Ownership
  • Manual EFS protection, which shows the CN(SAN) of the EFS public key cert used for protecting the file

Using the EFSDump Sysinternals tool to check the protection information of the files, you will see that for the

  •  WIP protected file, DDF field returned is empty.
  •  The DDF field has the public key cert thumbprint value for the Manual EFS encrypted file.
Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.10
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.10

Checking the protection info of the two files using the Cipher utility

PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\Personal.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E Personal.txt
  Compatibility Level:
    Windows XP/Server 2003
 
  Users who can decrypt:
    AzureAD\JoymalyaBasuRoy [JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)]
    Certificate thumbprint: C855 DD0A D5B4 70DE 1FB7 C580 ADFC F355 E82B 2367
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256
 
PS C:\Users\JoymalyaBasuRoy\Desktop\EFSDump> cipher /c .\work2.txt
 
 Listing C:\Users\JoymalyaBasuRoy\Desktop\EFSDump\
 New files added to this directory will not be encrypted.
 
E work2.txt
  Compatibility Level:
    Enterprise Protected
 
  Enterprise protected by:
    joymalya.com
 
  Recovery Certificates:
    JoymalyaBasuRoy(JoymalyaBasuRoy@AzureAD)
    Certificate thumbprint: E3B4 DCA2 D7EC E661 C8E7 EC5C D54B 5928 E0B8 F53B
 
  Key Information:
    Algorithm: AES
    Key Length: 256
    Key Entropy: 256

For the manual EFS encrypted file, you will get public cert details with which the file was encrypted. Using the Certutil tool, you can find out the corresponding private key details as shown below

PS Cert:\CurrentUser\My> $cert = gi cert:\CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PS Cert:\CurrentUser\My> $cert | fl *
 
 
PSPath                   : Microsoft.PowerShell.Security\Certificate::CurrentUser\My\C855DD0AD5B470DE1FB7C580ADFCF355E8
                           2B2367
PSParentPath             : Microsoft.PowerShell.Security\Certificate::CurrentUser\My
PSChildName              : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
PSDrive                  : Cert
PSProvider               : Microsoft.PowerShell.Security\Certificate
PSIsContainer            : False
EnhancedKeyUsageList     : {Encrypting File System (1.3.6.1.4.1.311.10.3.4)}
DnsNameList              : {JoymalyaBasuRoy}
SendAsTrustedIssuer      : False
EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
PolicyId                 :
Archived                 : False
Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                           System.Security.Cryptography.Oid}
FriendlyName             :
IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter                 : 2/27/2120 6:54:09 PM
NotBefore                : 3/22/2020 6:54:09 PM
HasPrivateKey            : True
PrivateKey               : System.Security.Cryptography.RSACryptoServiceProvider
PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
RawData                  : {48, 130, 3, 25...}
SerialNumber             : 47DFA194526BE4AC4A62CF38C0B2D7D3
SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
SignatureAlgorithm       : System.Security.Cryptography.Oid
Thumbprint               : C855DD0AD5B470DE1FB7C580ADFCF355E82B2367
Version                  : 3
Handle                   : 1992566309712
Issuer                   : CN=JoymalyaBasuRoy
Subject                  : CN=JoymalyaBasuRoy
 
PS Cert:\CurrentUser\My> $cert.PrivateKey.CspKeyContainerInfo
 
 
MachineKeyStore        : False
ProviderName           : Microsoft Enhanced Cryptographic Provider v1.0
ProviderType           : 1
KeyContainerName       : c309ccd7-f8c6-4e7b-b4bf-6cc17b3fe76b
UniqueKeyContainerName : f9969d35521c72e688cffc35d6d9da2c_5f5f326a-34f7-469e-bdea-529234e0c80f
KeyNumber              : Exchange
Exportable             : True
HardwareDevice         : False
Removable              : False
Accessible             : True
Protected              : False
CryptoKeySecurity      : System.Security.AccessControl.CryptoKeySecurity
RandomlyGenerated      : False

Notice the CSP is Microsoft Enhanced Cryptographic Provider v1.0, a legacy CryptoAPI (CAPI) CSP (deprecated; for details, check here) that implements both crypto algorithms and also provides key storage. CNG (CryptoAPI—Next Generation), the successor to CryptoAPI, separates cryptographic providers (algorithm implementation) from key storage providers (KSP) services, providing better key isolation for protection.

The corresponding private key will be found at the user profile location  %APPDATA%\Microsoft\Crypto\RSA\{User SID}

Notice the filename of the key matches the Unique container name value as shown above.

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.11
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.11

This private key is protected by DPAPI using a symmetric key known as the User Master Key, which is derived from the user logon credentials using some salt. The User Master Key itself is stored and protected to the location %APPDATA%\Microsoft\Protect\{User SID}

If you go to the location mentioned, you will see that the folder is empty. However, checking the folder properties will reveal that it actually contains files. (The files in this location are protected OS files)

In general, you would see 2 files here. This is because the User Master Key protected by the Protected Storage service is stored in two parts

Part 1 – the Password Encryption Key (PEK), is produced by the HMAC and SHA1 message digest function and is a hash of:

  • Asymmetric encryption of the user’s master key is produced by 160-bit RC4.
  • The user’s security identifier (SID).
  • The user’s logon password.

Part 2 – the backup/restore form of the master key, which is used in case, the system fails to detect password changes and thereby fails to update the password encryption key, uses the backup to recover the previous key and regenerate Part 1.

You will only see that the WIP-protected file is enterprise-protected, but it will not show you details of any cert with which the file was encrypted.

When WIP invokes EFS for file protection, EFS does not check to see if there is a public/private key pair available in the User Personal cert store suitable for EFS encryption. Even if one is created by EFS for the current user account (in case you have manually encrypted files with EFS already), it won’t be used for file protection of WIP-tagged files.

However, the file encryption process remains identical, as explained above, in the sense that the file content gets encrypted using a symmetric key, which in turn is protected by an asymmetric key. The encryption key itself remains stored in the current user profile.

You can see the records for the EDP Account that EFS will use at reg_path HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\EFS\EdpCredentials

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.12
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.12

In the event of unenrollment (or MDM handoff), the key still remains on the device. However, if the policy is configured to revoke access for such events, the key becomes useless as it can’t be accessed to decrypt the FEK to decrypt the file content. In such cases, the encrypted files can only be recovered with a DRA cert if the WIP policy defines one.

The key information is at the location %UserProfile%\AppData\Local\Microsoft\EDP\Recovery

If the same user enrols the device back to management (for WIP with enrollment) or the workplace joins the device back (for WIP without enrollment), access to the encryption key is restored, and the files can be accessed again.

EFS encryption – How secure is the protection?

As it is the public key of the public/private key pair generated for the currently active user account which is used to protect the FEK, only the same user account will have access to the private key for decrypting the FEK.

For multiple users logging in to the same system, a unique RSA key pair is generated for each user account which is mutually non-accessible. Thus by default, only the user account under which the file protection activity was performed will have access to the file contents due to the possession of the private key. Other user accounts will be denied access to file contents as they won’t have access to the original account’s private key.

Microsoft recommends WIP to be used by a single user per device – the account that enrolled the device. For multiple users signing in to the same device (Azure AD join device), there may be inconsistency and the service may fail to revoke access to encryption keys for secondary users.

To understand the security of EFS file protection better, see the structure of the DDF field in the $EFS attribute of the file. (Explained in detail here)

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.13
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.13

The DDF field can have multiple DDF Key entries. By default, it will have a single DDF entry for the original user account. Each DDF key entry is identified by the User SID.

Consider a scenario where the system is compromised (lost or stolen), but the user account is not compromised.

In such a case, if another user (attacker) creates a local account and tries to access EFS encrypted files present on the local disk, NTFS will get no match for the current user account SID against the SID value present in the DDF field of $EFS attribute of the protected file. NTFS will deny access to the file.

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.14
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.14

Even if the attacker decides to remove the local disk from the system and access the files from outside Windows, like attaching it to another Linux system, EFS has no third-party component driver support for other OS filesystems. Thus, the file becomes useless to the attacker as it cannot be opened.

The only way to get to the content of an EFS encrypted file is, either

  • gain access to the user’s private key, the public key of which was used to protect the FEK (identified by the EFS cert hash in the DDF entry).

The private key is protected by the DPAPI master key, which is again protected by the user’s login credentials. A password change initiated from within the same user account session causes a rekey/update of the DPAPI master key with the new user password, rekeying all the private keys protected by the previous version. Trying to reset the login credentials of the user account from outside the user account with special tools or from a recovery environment will render it impossible to decrypt the DPAPI master key, thereby securing the private key. The EFS encrypted files can’t be misused unless the original user account is compromised.

  • You can only gain access to the DRA cert (private key) if the file has a DRF entry in the $EFS attribute, which is, again, quite impossible.

However, once a user is logged on successfully, access to his own EFS encrypted data requires no additional authentication. Decryption happens transparently. Thus, any compromise of the user’s password automatically leads to access to that data.

Importance of DRA

When WIP is enforced, work-tagged data residing locally on an endpoint gets encrypted (EFS) using the WIP encryption key – an RSA public/private key pair generated locally on the system for the Azure AD Identity under the authority of the current signed-in User Account.

Windows 10 version 1709 onwards, the WIP encryption key information automatically backs up to Azure against the Azure AD identity account(UPN).

If the WIP policy is configured to revoke encryption keys on unenrollment, MDM handoff, or if the device lost its encryption keys due to an unprecedented event, any such action would lead WIP-protected data residing locally on the endpoint to inaccessible.

Re-enrolling the device back with the same user identity causes Azure to restore the encryption key information on the endpoint, making those protected files accessible again.

Still, this is like a single point of failure and there may be scenarios where re-enrolling the device with the same account is not an option. This is where a Data Recovery Agent certificate comes in handy. DRA is an RSA public/private key pair that can either be

  • requested from a CA (to support key archival), or
  • generated from a standalone device for a designated user account (maybe an EFS Recovery Service Account)

I will show them later as that is easier. For this, sign in to a standalone workstation with the designated user account and use the Cipher cmd line to command cipher /r:<Name for Cert Package>

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.15
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.15

You will find two cert files in the current location.

  • .pfx contains the private key, which can later be used for recovery purposes and as such, should be backed up to a safe location, and
  • .cer, which is the public key cert. (this is the one that needs to be added to the WIP policy to be distributed to the endpoints)

When a DRA cert is defined in the WIP policy, corporate tagged files are protected in a way that those can be accessed either by

  • the primary user, or
  • the IT admin has access to the private key of the DRA

For recovery using DRA, you would just need to import the private key to a system where you have admin rights. Also copy the encrypted inaccessible files to the same system. Then utilize the cipher utility to decrypt the encrypted file. 

WIP file protection is persistent when files are moved/copied to removable media

The Microsoft documentation for WIP states that the file remains protected if copied to a USB drive.

However, this may or may not work as stated since the protection status depends on the file system of the removable media. EFS is now supported with exFAT and FAT32 as well as NTFS (default); however, it is not supported with FAT and other filesystems.

To check if your removable media file format supports EFS, you can use the Windows fsutil cmd line tool command fsutil fsinfo volumeinfo <DriveLetter>:

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.16
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.16

If you check and see that the removable media supports EFS, when you try to move protected data from device’s local storage to removable storage, you get a prompt similar to below

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.17
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.17

Let’s consider that you lost the USB drive, but if you have copied it as Work Protected, you can rest assured that others won’t be able to open the file to get the data/content.

WIP – Limitations

By design, WIP is intended to protect work data at rest residing locally on an endpoint and/or protect work data if copied to a removable media like a USB drive. However, WIP cannot protect work data in transit—when you attach a work file to an email or upload it to a file share or online storage like SharePoint.

This limitation is because WIP depends on EFS to protect data residing locally on an endpoint by encrypting, and this protection information is not stored within the file but as an attribute of the file (protection information resides on local disk separately, the location being pointed by the File Header which contains the $EFS attribute)

This is where Azure Information Protection integration with WIP comes into the scenario since AIP protection stays with the file irrespective of its location,

AIP protection information is defined in the file metadata rather than a file attribute, a filesystem feature.

However, this cannot be considered a limitation, if you see how Microsoft has positioned Windows Information Protection in its lineup of Information Protection offerings.

Learn WIP with Joy - File Protection Deep Dive - Part 3 - Fig.18
Learn WIP with Joy – File Protection Deep Dive – Part 3 – Fig.18

The main purpose of WIP is to differentiate and separate work data from personal data on an endpoint and prevent users from accidentally leaking work data to personal space.

And this is what Windows Information Protection does exactly – it does not try to do what it was never supposed to do – protect data end-to-end throughout its lifecycle.

An EndingLearn WIP with Joy – File Protection Deep Dive

That was all I had in store for you. I hope you all have liked the series and learned something from it, which is the ultimate aim.

Stay tuned for a bonus article on Windows Information Protection—a complete troubleshooting guide for Intune Admins.

Until then, read something every day, learn something every day, but most importantly, Stay Isolated, Stay Safe, and help keep Others Safe!

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site, MDM Tech Space, at https://joymalya.com.

12 thoughts on “Learn WIP with Joy – File Protection Deep Dive – Part 3”

  1. Hey Joymalya,

    Awesome series on WIP – just finished going through it including the bonus on troubleshooting.

    Where I struggle with WIP is getting Azure RMS templates to protect USB files. My understanding is that when you copy a work file (EFS encrypted) to USB, it should let you copy, but protect it using the Azure RMS template you specify. However, in all my testing and configuration, I just get an error that reads I cannot place the file on the USB. The only way I’ve been able to do it is to not use Azure RMS, just EFS, but that means the USB cannot be shared with other users.

    Do you have any advice on troubleshooting such a problem?

    Reply
    • Hi Ruairidh,

      Azure RMS (AIP) integration with WIP helps to protect file when it shared as an email attachment or uploaded to cloud locations or file servers.
      For USB, what error are you exactly getting. Is it completely blocking you to copy or it allows to copy by removing protection (depends on the file format of USB drive as it needs to support EFS).
      I haven’t heard or faced anything like that if you have azure RMS configured with WIP, you cannot copy to USB. The AIM of RMS is to keep the file protected irrespective of the file location as unlike WIP, where the EFS protection is applied as file attribute (function of file system), Azure RMS protection is built into the file metatdata and has no dependecy on the underlying filesystem.

      Reply
      • Hey Joymalya, thanks for the reply. I can copy to the drive (NTFS) if I remove protection in the ‘allow overrides’ WIP method. Here’s exactly what happens recorded as a GIF – https://i.imgur.com/be0PxtL.gif

        The error for copying as work protected is simply the ‘organisation does not allow you to place this file here’. This is a clean system with only this app protection policy configured (no BitLocker USB requirements for example). Interestingly, when I copy as personal and then try to change ownership on the USB, it gives me error 0x80071787 (which returns no Google results) saying ‘specified file could not be encrypted with Windows Information Protection’. There are no logs in Event Viewer, and I have tried on MDM enrolled and MAM only PCs.

        I’ve confirmed in registry that the AIP template ID is retrieved but I get the feeling the problem is getting the AIP protection from the AIP service, but not sure. I even added a label policy to confirm permissions.

      • Hi Ruairidh,

        What is the output of fsutil fsinfo volumeinfo as example fsutil fsinfo volumeinfo D:
        Does is shows EFS as supported?
        You are unable to copy to USB drive either because your WIP policy defined EDP enforcement is set to Block or the USB drive itself does not supports EFS. Just a thought!

      • Hey Joymalya, thanks for the feedback. The output of dsutil looks fine as it reports “supports encrypted file system.” All very strange as I can copy and change to personal, so it’s definitely not in block mode either. I will keep investigating and update this thread if I find a solution.

    • Hi Ruairidh,

      Did you find a solution for your problem? We are having the same issue at the moment, I always worked fine before and nothing has changed.

      Your post here is the only one that google can find with the exact error code 0x80071787.

      Reply
  2. Hi Joymalya,

    great series regarding WIP!

    I have just one question. How is WIP working together with SMB File Shares? File Shares are not supporting EFS. What occurs if a users access data on a file share from an enterprise location? Are the data automated protected if accessed? Is it possible to disallow access from non WIP protected apps?

    Many Thanks,
    Markus

    Reply
    • Hi Markus,

      WIP helps tag files to corporate identity and protect them when downloaded to local device storage only. It does not protect files in transit or when shared or when uploaded to a file share. (Need to integrate with AIP)
      If you identify your file server as a WIP protected resource, then files downloaded from that server will be tagged as corp and protection applied.
      And off course, you can disallow access to corporate resources from non-WIP apps. By default, only apps in the protected apps and exempted apps can access corp resources. Apps not in either list gets blocked.

      Regards,
      Joy

      Reply
  3. Hi Joymalya,

    Great series regarding WIP!

    I have a unique situation where we are using WIP but it is not working with a mapped cloud drive. I assume this is sort of similar to One Drive but we are using Citrix ShareFile they have a program that can map a drive to their cloud storage platform. WIP doesn’t look to have a place to specify that the Z:\ drive contains protected content nor does the drive support encrypted files. Can I use PowerShell to encrypt a file using the WIP system when it is moved from the Z drive? Any other suggestion would be helpful as well as far as I know it is a Microsoft Virtual Drive so I am quite puzzled on what to do.

    Reply
    • WIP can help protect data on the local storage of an endpoint by tagging the data to the corp identity and encrypting it. However, as I have mentioned in the blogs, WIP encryption is dependant on EFS which requires NTFS file system. WIP can’t protect data if that data is being shared over the wire or uploaded to cloud storage. Being said that, if you have a file share that is being mapped as Z drive on the endpoint, I believe you could possibly add the URL of the file share as a protected resource within the WIP policy. (Add a Cloud resource with either the URL or IP of the file share) This would make the endpoint treat any file coming from the Z drive as corp data protecting it automatically if saved on the local storage. [This won’t encrypt your files within the file share].

      If you are worried about protecting data, AIP (now Unified labeling and M365 DLP solutions) would be the way to go forward as it will ensure the protection of data remains with the data and not dependent on the file system.

      Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.