WIP helps to protect against this potential data leakage without otherwise interfering with the employee experience. On both, enterprise-owned devices and personal devices that employees bring to work, enterprise applications as well as data can be protected by WIP without requiring changes to the customer environment or applications. Azure Information Protection and Azure Rights Management will work alongside WIP in the future to extend data protection for data that leaves the device, such as when email attachments are sent from an enterprise aware version of a rights management mail client.

Thus, WIP will provide an end-to-end protection of data, addressing all situations an employee is confronted with. For this, it is necessary to differentiate between two scenarios: Data-At-Rest, when data is stored and worked on at a Desktop, Tablet PC or mobile device, and Data-In-Transit, when data is being sent or received via email or shared via SharePoint or OneDrive for Business for instance. In order to address all use cases, both, the protection of data in rest, and the protection of Data-In-Transit is crucial for an end-to-end protection.

Data-At-Rest

Data-At-Rest is data, which is handled on a device itself only. Data on this device can be compromised when the device itself is lost or stolen and unauthorized access is possible.

Many customers understand the need for a Data-At-Rest Protection solution for mobile devices as a mobile phone is easily lost. Nonetheless, not only mobile devices need to be protected. Especially personal computers (PCs) are not only susceptible of extraction of data, but also to other risks when the device is unencrypted. Attackers can use hacking tools to log into the devices with a local admin account and extract domain user usernames and passwords (Pass-The-Hash attacks). Furthermore, data can easily be extracted if no secure wiping procedures are used when you decommission devices and disks due to age or hardware failure.

These scenarios explain why it is crucial to encrypt every volume on every device, particularly if it is an OS volume, including desktops, servers and mobile devices. The protection of Data-At-Rest with WIP leverages Encrypting File System (EFS). Data-At-Rest protection ensures that all enterprise related data which is stored on a PC is encrypted.

Data-At-Rest encryption and decryption

WIP uses public key encryption in conjunction with symmetric key encryption to provide confidentiality for files that resists all but the most sophisticated methods of attack. The file encryption key (FEK) — a symmetric bulk encryption key — is used to encrypt the file and is then itself encrypted by using the public key of the user, which is located in the user's profile. The encrypted FEK is stored with the encrypted file and is unique to it. To decrypt the FEK, WIP uses the encryptor's private key which only the file encryptor has. In addition to this, the DRA is also able to decrypt the file.

Data-At-Rest encryption workflow

Data-At-Rest decryption workflow

Revoke on un-enroll

In case a device gets stolen or an employee leaves the company, WIP protected data needs to be made inaccessible to the original user of the device.

One possibility to do that is by removing the private/public key pair of the user from the device. This ensures that the user on the device cannot decrypt his/her WIP protected files any longer, as the private key, which would be needed for that operation, does not exist anymore. In case the user's keys are removed from the device, the EDP protected data still resides on the desktop device of that user – but it is inaccessible. Of course, the Data Recovery Agent is always able to decrypt the data. For more details about the DRA, please refer to DRA section

Another possibility to make data inaccessible for someone is by wiping the device. When a device was stolen, a complete wipe of the device might be necessary. This operation removes both personal as well as enterprise owned files and can be performed via SCCM or Intune. In case an employee resigns and takes his/her BYOD device with him/her, it is also possible to remove enterprise data only. This can be done by performing a selective wipe via Microsoft Intune, not yet with SCCM.

Note: For mobile devices WIP protected data gets always wiped.

Revoke on un-enroll workflow

Encrypting File SystemEncrypting File System

Application and Data Types

Windows Information Protection clusters any applications and data into three areas: business, personal, and enlightened.

Personal applications and data are not managed and do not apply and Windows Information Protection related behaviors. These applications cannot have files written out in an encrypted format. Business applications and data are managed and are also called enlightened or unenlightened.

Unenlightened applications are policy unaware. They consider all data corporate and encrypt everything. Typically, unenlightened applications can be recognized because the Windows Desktop shows them as always running in enterprise mode and the Windows Save As experiences only allow to save files as enterprise ones.

Enlightened applications and data are aware of the Windows Information Protection policy. They can differentiate between corporate and personal data, correctly determining which to protect, based on the set policies. For example, enlightened applications provide users the user interface to choose between saving data as encrypted or non-encrypted. In case the user decides to save a file which has been identified as an enterprise resource as non-encrypted, the appropriate UI would warn the user of his/her actions.

The following applications are example of enlightened Microsoft applications:

Modern Apps or Universal Windows Apps

• Microsoft Edge
• Microsoft People
• Mobile Office apps, including Word, Excel, PowerPoint, OneNote, and Outlook Mail and Calendar
• Microsoft Photos
• Microsoft OneDrive
• Groove Music
• Microsoft Paint
• Microsoft Movies & TV
• Microsoft Messaging

Classic Apps or Win32 Apps

• Internet Explorer 11
• Notepad

Enlightened applications need to be added to the list of protected applications to allow them to access applications and data and to interact differently when used with not allowed, non-enterprise aware, or personal-only apps.

Business, enlightened and personal applications and data

Protection Modes

Windows Information Protection can operate in one of four different protection and management modes when using applications and data.

Reporting and Auditing

The Windows Information Protection reporting automatically audits the usage of WIP protected files. This includes any WIP policy violations (e.g. "override corporate saving").

As Windows Information Protection does not support an out-of-the box solution for WIP Reporting, a custom implementation is recommended. To give a general idea, there will be a scale report which exemplarily shows Windows Information Protection reports in Intune. On desktop devices, Windows Event Forwarding could also be used to forward the events to an SIEM for analysis/processing.

Data Recovery Agent

The data recovery agent (DRA) is able to recover Windows Information Protection encrypted data.

If an employee leaves the company and WIP protected data needs to be made available for someone, a DRA can help to do so. The DRA could also help to recover data in case an employee's certificate is accidentally revoked.

Usually, data can only be decrypted using a person's private key and the symmetric FEK when the public key was used to decrypt it in the first place. In addition to encrypting data with the FEK protected by the owner's public key, data is also encrypted with the FEK protected by the public key of the DRA. This way, besides the owner of the document, the DRA can decrypt data.

Note: The DRA is a highly privileged role and must be protected accordingly. The private key should be bound to a smartcard, so that the private key never actually gets copied to a device when performing a decryption of data on a Windows 10 desktop device.

You have two options for backing up the private key:

1. Export the DRA certificate containing the private key manually
2. Use the Certificate Authority to archive the private key in its database when the DRA certificate is issued

The DRA certificate can be either issued from a CA or from a specific user device as a self-signed certificate. The public key is exported in Base64 format and added to the Windows Information Protection policy in SCCM or the MDM (e.g. Microsoft Intune). When provisioning the WIP policy to the devices, the DRA certificate (public key only) is provisioned to each device. From then onwards, besides the user's public key, the DRA public key is wrapped around data when encrypting it. This way, not only the private key of the user but also the private key of the DRA can decrypt data.

Note: It is strongly recommended to use a CA to issue the DRA certificate.

Current Windows Information Protection Limitations

As of June 2016, there exist several limitations in WIP:

• Windows Information Protection supports only Office 2016 click-to-run. It does not support Office Desktop 2013 MSI/C2R and Office 2016 MSI.
• Windows Information Protection does not support multiple users on one device. The first domain user who authenticates him-/herself on the device is eligible for WIP protection.
• Windows Information Protection does not support a protection of Data-In-Transit within the Windows 10 Anniversary Update timeframe. Only Data-At-Rest is protected by WIP so far.
• Windows Information Protection does not protect enterprises from malicious user behavior. For example, when a user intentionally circumvents the WIP protection by saving a corporate document as a private one and shares content of it afterwards with an unauthorized third-person, and thereby abuses the functionality of enlightened apps.
• Windows Information Protection supports no automatic reporting regarding WIP violations. Event forwarding to a SIEM solution is therefore recommended for domain-joined machines. Otherwise, a custom implementation for Windows Information Protection reporting is possible.

Technical Implementation

The following section will describe the step by step configurations on Windows Information Protection policy using Configuration Manager with Microsoft Intune. This document assumes that Active Directory and PKI infrastructure (ADCS) have been deployed in the IT environment.

Hybrid – Configuration Manager with Microsoft Intune

Hybrid always refers to a hybrid identity by synchronizing the local AD to Azure AD.

The following prerequisites need to be present for a Hybrid identity implementation

• Users need to be present in both Azure AD and the local AD.
• The devices need to be managed in Configuration Manager (version 1606 or later), which manages domain joined devices only, in combination with a cloud-based MDM, e.g. Microsoft Intune, to manage mobile devices.
• Windows 10 Anniversary Update needs to be running on all devices which want to get WIP provisioned.

When those prerequisites are met, WIP is provisioned as follows:

1. The user adds his/her work or school account or performs a domain join using their AD account.
2. Windows 10 devices are managed with MDM and/or Configuration Manager.
3. The WIP policy is created within the Configuration Manager.
4. The Configuration Manager then provisions the policy including the DRA key (public key only) to the user devices.
5. Windows Information Protection can then be used by the users.

Creating a Data Recovery Agent

A key recovery agent is a person who is authorized to recover a data on behalf of an end user. Because the role of key recovery agents can involve sensitive data, only highly trusted individuals should be assigned to this role.

To identify a key recovery agent, you must configure the Key Recovery Agent certificate template to allow the person assigned to this role to enroll for a key recovery agent certificate.

Note: If you are already using a Data Recovery Agent (DRA) for EFS, you can use the same account to decrypt/recover files protected by Windows Information Protection.

Creating the Data Recovery Agent Account

Create the following account:

Creating the Certificate Template

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

1. Open the Certification Authority Snap-in, expand the name of your CA, right-click Certificate Templates and click Manage.
2. The Certificate Templates Console starts.
3. Right-click the EFS Recovery Agent Template and click Duplicate Template.
4. Open the tab General and enter a Template display name.
5. Check the box Publish certificate in Active Directory.
6. Open the tab Request Handling and verify that the purpose is set to Encryption and Allow private key to be exported is checked.

   

Note: If you want to archive the private key by leveraging the CA key archival feature you must also check Archive subject's encryption private key.

Check Managing Key Archival and Recovery for Key recovery settings on Certificate Services.

1. Open the tab Security, and click Add.
2. The Select Users, Computers, Service Accounts and Groups window opens.
3. Enter the name of your service account, click Check Names and confirm with OK.
4. Check the permission for Enroll.

   

Note: After a DRA certificate is issued, you may remove the permission for the service account from the template security settings.

1. Click Apply and OK.
2. Close the Certificate Templates Console window.
3. Right-click Certificate Templates, select New and click Certificate Template to Issue.
4. Select the previously created template from the list and click OK.

    

Requesting a DRA certificate

1. Login with the previously created account to a domain-joined system.

Note: If this step violates your corporate policy, please refer to this TechNet article about requesting a certificate on behalf of a user. Additional requirements may apply. https://technet.microsoft.com/en-us/library/cc770802.aspx

You can also use the Certificate Authority Web Enrollment (certsrv) feature to request the certificate. Please refer to the following TechNet article for further guidance. This step requires logon with the service account to the certificate web services. https://technet.microsoft.com/en-us/library/hh831649.aspx

1. Open certmgr.msc, expand Personal, right-click Certificates (or Personal), select All Tasks and click Request New Certificate.

   

2. The Certificate Enrollment Wizard starts.
3. Click Next, verify Active Directory Enrollment Policy is selected, click Next, select the previously created certificate template from the list and click Enroll.
4. Wait for the enrollment process to complete and click Finish.

   

   

    

Export the DRA certificate

You have to export the DRA certificate twice. Once including the private key so you can back it up at a secure location and the second time without the private key. The second one will later be used when creating the INTUNE/CONFIGURATION MANAGER policy for WIP.

Export the DRA certificate including the private key

Note: This step is only required if you don't archive the private key using the CA key archival feature.

1. Right click on the DRA certificate, select All Tasks and click Export.

   

2. Click Next, select Yes, export the private key and click Next again.
3. Enter a secure password and click Next.
4. Browse to a secure location and click Save.
5. Click Finish.

    

Export the DRA certificate without the private key

1. Open certmgr.msc, expand Personal, expand Certificates, right-click the previously created DRA certificate, select All Tasks and click Export.

   

2. The Certificate Export Wizard starts.
3. Click Next, verify No, do not export the private key is selected, click Next, select Base-64 encoded X.509 (.CER), click Next, specify a filename and location, click Next, click Finish.
4. Open Windows Explorer and navigate to the location of the exported certificate.
5. Copy the certificate to a location where it can later be accessed when creating the Intune/CONFIGURATION MANAGER policy.

Note: After the private key was successfully backed up, either by using the key archival feature or by saving it to a secure backup location, deleting the certificate with the private key from the system is recommended where it was requested.

Creating a Group Policy for the DRA

Note: If there is already a deployed EFS Certificate, they need to use the existing DRA certificate for the Windows Information Protection encryption and decryption. This certificate is used as a Recovery Certificate prior to the DRA certificate in WIP configured in Configuration Manager. If there is no certificate deployed in EFS, then the DRA certificate in WIP will be used.

1. Open the Group Policy Management Snap-in.
2. Expand your forest, expand Domains, expand your domain, expand and right-click Group Policy Objects (GPO) and click New.
3. Enter a Name, optionally select a Source Starter GPO and click OK.
4. Right-click on the newly created GPO and click Edit.
5. The Group Policy Management Editor starts.
6. Expand Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, expand Public Key Policies and click Encrypting File System.
7. Right-click Encrypting File System click Add Data Recovery Agent.

   

Note: If you click New Data Recovery Agent and have sufficient permissions, a certificate for the currently logged on user will be automatically issued by one of your CAs. This certificate is based on the default certificate template EFSRecovery.

1. The Add Data Recovery Agent Wizard starts.
2. Click Next, click Browse Directory, type the name of the previously created service account, click Check Name and click OK.
3. A confirmation pane showing the previously enrolled certificate for the service account is shown.
4. Verify the certificate information and continue by clicking OK.
5. Click Next and click Finish.
6. Verify the information in the right pane of the Group Policy Management Editor.

Create a Policy with System Center Configuration Manager

After you've installed and set up System Center Configuration Manager for your organization, you must create a configuration item for WIP, which in turn becomes your Windows Information Protection policy.

There are Mandatory Polices that you must include in the Windows Information Protection Policy that you will create otherwise WIP will not work, these are:

1. Protected Application List
2. WIP Protection Mode
3. Corporate Identity
4. Enterprise Network Domain
5. Enterprise IP Address Range
6. Data Recovery Agent Certificate

Create a Configuration Item Policy for WIP

1. Open the System Center Configuration Manager console, click the Assets and Compliance node, expand the Overview node, expand the Compliance Settings node, and then expand the Configuration Items node.

   

2. Click the Create Configuration Item button.
3. The Create Configuration Item Wizard starts.
4. On the General Information screen, type a name (required) and an optional description for your policy into the Name and Description boxes.
5. In the Specify the type of configuration item you want to create area, pick the option that represents whether you use System Center Configuration Manager client for device management, and then click Next.

   

6. On the Supported Platforms screen, click the Windows 10 box, and then click Next.

   

7. On the Device Settings screen, select WIP, and then click Next.

   

8. The Configure WIP settings page appears, where you'll configure the policy for your organization.

   

    

Choose Which Apps Can Access to your Enterprise Data

During the policy-creation process in Configuration Manager, you can choose the apps you want to give access to your enterprise data through Windows Information Protection. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps or unprotected network locations. This is Mandatory.

The steps to add your apps are based on the type of app it is; either a Universal Windows Platform (UWP) app, or a signed Classic Windows application.

Note: Windows Information Protection -aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary and will encrypt all files they create or modify, meaning that they could encrypt personal data and cause data leaks during the revocation process. Care must be taken to get a support statement from the software provider that their app is safe with Windows Information Protection before adding it to your Protected App list.

To add a Universal app

1. From the Configure the following apps to be protected by WIP table in the Protected Apps area, click Add.
2. Click Universal App, type the Publisher Name and the Product Name into the associated boxes, and then click OK. If you don't have the publisher or product name, you can find them by following these steps.

Within Configuration Manager, a new option can be added to all apps which are added to the App Rules: For each app you can choose if it is set to Allow, Exempt, and Block If it is set to Allow, all WIP operations are allowed. In case it is set to Exempt, it bypasses the encryption capability (opening encrypted files is working, but saving a file as an encrypted file is not working). Block is to avoid accidental allow

Recommendation: All enlightened apps should be set to Allow. The Exempt mode should be used very rarely as no protection of corporate data can be enforced within exempted apps. It is usually use for Application Compatibility and Use for unenlightened apps needed for work that touch personal data. Block is recommended for unenlightened apps that handle work & personal data.

Unenlightened apps: Whether to use the Allow, Exempt or Block mode depends on whether it should be able to access personal data. If unenlightened apps shall be handling enterprise only (e.g. LOB app, like in-house finance), that should be set to Allowed. (to ensure its data gets encrypted.) But should test the revocation process thoroughly.

If an unenlightened app could access personal data, you'd want to tell the admin to choose to Exempt mode (knowing that it will potentially leak, but won't be encrypting personal data).

To find the Publisher and Product name values for Microsoft Store apps without installing them Go to the Windows Store for Business website, and find your app. For example, Microsoft OneNote. Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, 9wzdncrfhvjl. In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON) file that includes the publisher and product name values. For example, run

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfhvjl/applockerdata where 9wzdncrfhvjl is replaced with your ID value.

The API runs and opens a text editor with the app details.
{
"packageIdentityName": "Microsoft.Office.OneNote",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
}

Copy the publisherCertificateName value and paste them into the Publisher Name box, copy the packageIdentityName value into the Product Name box of the Add app box, and then click OK.

Note: The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name boxes. This means that you have an app that's using a XAP package and that you must set the Product Name as windowsPhoneLegacyId, and set the Publisher Name as "CN=" followed by the windowsPhoneLegacyId.

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

To add a Classic Windows application

1. From the Configure the following apps to be protected by WIP table in the Protected Apps area, click Add.
2. A dialog box appears, letting you pick whether the app is a Universal App or a Desktop App.
3. Click Desktop App, pick the options you want (see table), and then click OK.

If you're unsure about what to include for the publisher, you can run this PowerShell command:

• Get-AppLockerFileInformation -Path "<path of the exe>"

Where "<path of the exe>" goes to the location of the app on the device.

For example:

• Get-AppLockerFileInformation -Path "C:\Program Files\Internet Explorer\iexplore.exe".

In this example, you'd get the following info:

Path Publisher

---- ---------

%PROGRAMFILES%\INTERNET EXPLORER\IEXPLORE.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET EXPLOR...

Where the text, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US is the publisher name to enter in the Publisher Name box.

TIP: Another way to easily get the Publisher Name and Product Name for the Universal Applications or Classic Applications is to have them installed in a reference PC then run a PowerShell cmdlet to extract all that information.

Manage the Windows Information Protection -Protection Level for your Enterprise Data

After you've added the apps you want to protect with EDP, you'll need to apply an app management mode. This is mandatory.

We recommend that you start with Silent or Override while verifying with a small group that you have the right apps on your App Rules. After you're done, you can change to your final enforcement policy, either Override or Block.

Note: After you turn off Windows Information Protection, an attempt is made to decrypt any closed WIP-tagged files on the locally attached drives.

Choose Where Apps Can Access Enterprise Data

After you've added a management level to your protected apps, you'll need to decide where those apps can access enterprise data on your network.

Corporate Identity (Mandatory)

Specify the name of your primary identity domain in the Primary domain/Corporate Identity field. The domain should usually match your User Principal Name suffix. For example, if your user's UPN is user@contoso.com, then you should enter contoso.com as the requested domain name. If you have multiple domains owned by your enterprise you can add them and separate with the "|" character. For example, (contoso.com|contosolive.com). With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list.

The domain you enter here is also used to tag your files. Depending on a later policy setting, users might see a symbol indicating that the currently opened application is protected by WIP.

If you have multiple suffixes or mail addresses you can specify those in the next step.

Network Locations

There are 7 options, including your cloud domain, network domain, proxy server, internal proxy server, IPv4 range, and IPv6 range.
Add additional network locations your apps can access by clicking Add, and then choosing your location type, including:

1. Add as many locations as you need, and then click OK.

    

Configure Additional Policy Options

Enterprise Proxy Servers list is authoritative (do not auto-detect)
Enable this box if you want Windows to treat the proxy servers you specified in the network boundary definition as the complete list of proxy servers available on your network. If you clear this box, Windows will search for additional proxy servers in your immediate network.

Enterprise IP Ranges list is authoritative (do not auto-detect)
Enable this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network.

Show the enterprise data protection icon overlay on your allowed apps that are EDP-unaware in the Windows Start menu and on corporate file icons in the File ExplorerIf you enable this setting your clients will display several indicators that an app is managed by WIP.

When you pin a tile of a managed application to the start menu:

When you open an application from the App Rules it will show a notification in the top right corner:

Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data (Mandatory)

Here you can specify the previously exported DRA certificate which does not include the private key. Please check Export the DRA certificate without the private key for reference.

Show the Personal option in the File ownership menus of File Explorer and the Save As dialog box

Enabling this setting prevents users from decrypting data that is tagged as corporate data. The corresponding options are either not available or greyed out.

Prevent corporate data from being accessed by apps when the device is locked. Applies only to Windows 10 Mobile
Activating this setting prevents any access to corporate files when a device is in a locked state. This includes any applications running in the background or notifications usually shown on the lock screen.

Revoke local encryption keys during the unerollment process
If you enable this setting and unenroll a client from WIP, all user keys get automatically revoked. Please be aware if you leave this setting unchecked and a client gets unenrolled from Windows Information Protection, protected data is potentially vulnerable to data leakage as the protected data is fully accessible by the user without any protection or auditing.

Allow Windows Search to search encrypted corporate data and Store apps
When an WIP policy is configured, Windows encrypts corporate data on the local disk. Set this option to true to allow the Windows Search to index encrypted corporate data and Store apps so that they appear in the Windows Search results. Set this option to false to prevent these items from appearing in Windows Search results.

Deploying the Configuration Item

1. Open the System Center Configuration Manager console, click the Assets and Compliance node, expand the Overview node, right-click Device Collections and then click Create Device Collection.

   Note: You may decide to deploy the configuration baseline to a group of users instead of a group of devices. Though this is possible, please keep in mind that WIP does currently not support multi-user scenarios.

2. The Create Device Collection Wizard starts.

   

3. Enter a Name (for example, Windows Information Protection Collection) and click Browse.
4. In Limiting Collection field, if your devices are managed by the System Center Configuration Manager client, please select All Desktop and Server Clients and confirm with OK. Otherwise please choose All Systems and confirm with OK.
5. Click Next, expand Add Rule and select Direct Rule.
6. The Create Direct Membership Rule Wizard starts, and click Next.
7. In the Value field, enter the name(s) of the client(s) that should be managed by WIP. You can use "%" as a wildcard.
8. Click Next, select the client(s) from the list, click Next and Next.
9. Please wait for the process to complete and exit the wizard by clicking Close.
10. Click Next, review the settings, click Next once more, wait for the process to complete and finish by clicking Close.
11. Expand the Compliance Settings node, right-click the Configuration Baselines node and select Create Configuration Baseline.

    

12. The Create Configuration Baseline window starts.

    

13. Enter a Name for the Baseline, expand Add and select Configuration Items.

    

14. Select the previously created configuration item, click Add and confirm by finishing with OK. Click OK again to close Create Configuration Baseline window.
15. Right-click the newly created configuration baseline and select Deploy.

    

16. The Deploy Configuration Baselines window opens.
17. Verify the baseline shows up under Selected configuration baselines.
18. Check Remediate noncompliant rules when supported. Optionally check Allow remediation outside the maintenance window.
19. In Select the collection for this Configuration baseline deployment, Click Browse and change the scope to Device Collections

    

20. Select the previously created Device Collection and confirm by clicking OK.

    

21. Click OK to close Create Configuration Baseline window.
22. Go to the test cases after finishing this step.

     

Unenrollment from Windows Information Protection

If you want to unenroll a specific device, you have multiple options to choose from:

1. Unenroll from the device itself by removing the connection to the Mobile Device Management service
2. Remote wipe via Exchange Server

Please note that this feature only works for mobile devices registered via Exchange Server. Additional information can be found on TechNet:
https://technet.microsoft.com/en-us/library/aa998614.aspx

1. Selective/Full wipe via Configuration Manager console

Please note that this feature is only available in hybrid mode with a correctly configured Microsoft Intune subscription. Additional information can be found on TechNet: https://technet.microsoft.com/en-us/library/dn956981.aspx

1. Uninstall the Configuration Manager client

If you unenroll a desktop device, the user key gets revoked during the unenrollment process. The WIP protected data remains on the device and can still be accessed with the private key of the DRA.

If you unenroll a mobile device, the user key gets revoked and additionally all WIP protected data gets removed as well. In case you might not want to completely unenroll but rather disable WIP, you have the following options:

1. Disable WIP in the configuration item.
2. Remove the device from the deployment scope.

Note: Please be aware that disabling WIP does not revoke or remove the user keys which could lead to data leakage as the user has full access to protected data without any WIP policy awareness/auditing/enforcement.

Recovery

1. Sign in to the devices where the encrypted files are located with a DRA account.
2. Attach the smart card containing the private key of the DRA to the device
3. Launch a command prompt (Admin)
4. Type cipher /d <encryptedfile.extension>

Note: Please refer to the TechNet article for further information about the cipher tool.
https://technet.microsoft.com/en-us/library/bb490878.aspx

Scripts & Useful Commands

Command to create a DRA certificate

For customers that doesn't have PKI Infrastructure but still want to deploy WIP Policy, they can use a Self-Sign generated certificate by the chosen Data Recovery Agent.

1. Sign in to a Windows 10 machine with a DRA user account. You will need to know a local Administrator credential later.
2. Launch elevated CMD and navigate to a folder directory where you want to create a DRA certificates.
3. Type cipher /r:EFS-DRA-FILENAME
   1. (Enter a password when prompted. This will create two certificates, a .cer file and a .pfx file.)
4. The .cer file (cert without private key) is the one you will use to your EDP Policy and the .pfx file (cert with private key) should be kept on a secured location.

To verify the DRC is correctly configured on an WIP client machine

(*without* an EFS DRA configured through Group Policy):

1. Encrypt a file with WIP
2. Launch elevated CMD and navigate to the encrypted file location
3. Type cipher /c filename (cipher /file.txt)
4. Verify that Recovery Certificates: lists a certificate with thumbprint that matches the expected DRA Cert.

To quickly recover data (or verify your DRC settings are correct)

1. Copy the encrypted file to a known location on a machine you have admin access to
2. Install the EFSDRA.pfx (using the password)
3. Launch elevated CMD and navigate to encrypted file
4. cipher /d <encryptedfile.extension>

Troubleshooting

1. Control Panel, Configuration Manager, Actions, select Machine Policy Retrieval & Evaluation Cycle and click Run Now.

   

   

2. Switch to the Configurations tab and click Refresh until your policy appears.
3. When your policy appears the status is likely to be Unknown or Non-Compliant.
4. Select your policy and click Evaluate Now.
5. Hit Refresh a couple of times until the Compliance State is Compliant.

Reference:
https://technet.microsoft.com/en-us/itpro/windows/whats-new/WIP-whats-new-overview

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/protect-enterprise-data-using-WIP

https://technet.microsoft.com/en-us/itpro/windows/keep-secure/create-WIP-policy-using-sccm

Set-Up Mobile Application Management (MAM)

System Center Configuration Manager application management policies let you modify the functionality of apps that you deploy to help bring them into line with your company compliance and security policies. For example, you can restrict cut, copy, and paste operations within a restricted app, or configure an app to open all web links inside a managed browser. App management policies support:

• Devices that run Android 4 and later.
• Devices that run iOS 7 and later.

To apply restrictions to an app, the app must incorporate the Microsoft Intune App Software Development Kit (SDK). There are two methods of obtaining this type of app:

• Use a policy managed app (Android and iOS): Has the App SDK built-in. To add this type of app, you specify a link to the app from an app store such as the iTunes store or Google Play. No further processing is required for this type of app. For a list of the policy managed apps that are available for iOS and Android devices, see https://www.microsoft.com/en-us/cloud-platform/microsoft-intune-partners
• Use a 'wrapped' app – (Android and iOS): Apps that are repackaged to include the App SDK by using the Microsoft Intune App Wrapping Tool. This tool is typically used to process company apps that were created in-house. It cannot be used to process apps that were downloaded from the app store. See Prepare iOS apps for mobile application management with the Microsoft Intune App Wrapping Tool and Prepare Android apps for mobile application management with the Microsoft Intune App Wrapping Tool.

Create and deploy an app with a mobile application management policy

Step 1: Obtain the link to a policy managed app, or create a wrapped app

• To obtain a link to a policy managed app - From the app store, find, and note the URL of the policy managed app you want to deploy.
  • For example, the URL of the Microsoft Word App for iOS is: https://itunes.apple.com/us/app/microsoft-word/id586447913?mt=8
  • for Android is: https://play.google.com/store/apps/details?id=com.microsoft.office.word&hl=en

   

• To create a wrapped app - Use the information in the topics Prepare iOS apps for mobile application management with the Microsoft Intune App Wrapping Tool and Prepare Android apps for mobile application management with the Microsoft Intune App Wrapping Tool to create a wrapped app.

  The tool creates a processed app and an associated manifest file. You will use these files when you create a Configuration Manager application containing the app.

  Note: You can check what are the applications that are currently have a built in Intune SDK and "MAM Aware" apps here: https://www.microsoft.com/en-us/cloud-platform/microsoft-intune-partners

  

  When you update to the 1602 release from 1511, Configuration Manager automatically creates the following Microsoft Office mobile apps for Android and iOS:

  

  Step 2: Create a Configuration Manager application that contains an app

  The procedure to create the Configuration Manager application differs depending on whether you are using a policy managed app (external link), or an app that was created by using the Microsoft Intune App Wrapping Tool for iOS (App package for iOS). Use one of the following procedures to create the Configuration Manager application.

  To create an application for an app wrapping tool for iOS and Android app

1. In the Configuration Manager console, click Software Library.
2. In the Software Library workspace, expand Application Management, and then click Applications.
3. In the Home tab, in the Create group, click Create Application to open the Create Application Wizard.

   

4. On the General page, select Automatically detect information about this application from installation files.
5. In the Type drop-down list, select App package for iOS (*.ipa file) or App package for Android (*.apk file)

   

    

   

6. Click Browse to select the app package you want to import, and then click Next.
7. On the General Information page, enter the descriptive text and category information that you want users to see in the company portal.
8. Complete the wizard.

The new application is displayed in the Applications node of the Software Library workspace.

To create an application containing a link to a policy managed app

1. In the Configuration Manager console, click Software Library.
2. In the Software Library workspace, expand Application Management, and then click Applications.
3. In the Home tab, in the Create group, click Create Application to open the Create Application Wizard.

   

4. On the General page, select Automatically detect information about this application from installation files.
5. In the Type drop-down, select one of the following:

• For iOS: App Package for iOS from App Store and Enter the URL for the app (from step 1), and then click Next.

• For Android: App Package for Android on Google Play 

1. On the General Information page, enter the descriptive text and category information that you want users to see in the company portal.
2. Complete the wizard.

The new application is displayed in the Applications node of the Software Library workspace.

Step 3: Create an application management policy

1. In the Configuration Manager console, click Software Library.
2. In the Software Library workspace, expand Application Management, and then click Application Management Policies.
3. In the Home tab, in the Create group, click Create Application Management Policy.

   

4. On the General page, enter the name and description for the policy, and then click Next.

   

5. On the Policy Type page, select the platform either iOS or Android device and the policy type for this policy, and then click Next. The following policy types are available:

   

    

   

• General: The General policy type lets you modify the functionality of apps that you deploy to help bring them into line with your company compliance and security policies. For example, you can restrict cut, copy, and paste operations within a restricted app.
• Managed Browser: Configure whether to allow or block the managed browser from opening a list of URLs. The Managed Browser policy type lets you modify the functionality of the Intune Managed Browser app. This is a web browser that lets you manage the actions that users can perform, including the sites they can visit, and how links to content within the browser are opened. Learn more about the Intune Managed Browser app for iOS and the Intune Managed Browser app for Android.

1. On the iOS Policy or Android Policy page, configure the following values as required, and then click Next. The options might differ depending on the device type for which you are configuring the policy.

   

    

   

1. On the Managed Browser page, select whether the managed browser is allowed to open only URLs in the list or to block the managed browser from opening the URLs in the list, manage the URLs in the list, and then click Next.
2. Complete the wizard.

Deploy Apps and Associate the Application Management Policy.

1. In the Configuration Manager console, click Software Library.
2. In the Software Library workspace, expand Application Management, and then click Applications.
3. In the Applications list, select the application that you want to deploy. Then, on the Home tab, in the Deployment group, click Deploy.

   

4. On the General page of the Deploy Software Wizard, specify the following information:

• Software – This displays the application to deploy. You can click Browse to select a different application.
• Collection – Click Browse to select the collection to deploy the application to.
• Automatically distribute content for dependencies – If this is enabled and any of the deployment types in the application contain dependencies, then the dependent application content will be also sent to distribution points.

  

   

Important: If you update the dependent application after the primary application has been deployed, any new content for the dependency will not be automatically distributed.

1. On the Content page of the wizard,

• If you are deploying applications that will be coming from the App Store for iOS or Google Play for Android or Windows Store, just click Next

• If you are deploying applications that are wrapped and have. App package for iOS (*.ipa file) or App package for Android (*.apk file), then you have to select Add and select the manage.microsoft.com distribution point and click Next

1. On the Deployment Settings page of the Deploy Software Wizard, specify the following information:

• Action – From the drop-down list, choose whether this deployment is intended to Install or Uninstall the application.

Note: If an application is deployed twice to a device, once with an action of Install and once with an action of Uninstall, the application deployment with an action of Install will take priority.You cannot change the action of a deployment after it has been created.

• Purpose – From the drop-down list, choose one of the following options:
  • Available - If the application is deployed to a user, the user sees the published application in Software Center and can install it on demand.
  • Required - The application is deployed automatically according to the configured schedule. However, a user can track the application deployment status if it is not hidden, and can install the application before the deadline from Software Center.

  

Note: When the deployment action is set to Uninstall, the deployment purpose is automatically set to Required and cannot be changed.

Note: Application approval requests are displayed in the Approval Requests node, under Application Management in the Software Library workspace. If an approval request is not approved within 45 days, it will be removed. Additionally, reinstalling the Configuration Manager client might cancel any pending approval requests. The options Software Installation and System restart (if required to complete the installation) are not used if the deployment purpose is set to Available. You can also configure the level of notification a user sees when the application is installed.

1. For Application that are "Managed Apps" or MAM aware, an Application Management page will be visible. When a deployment type is created for an app that requires an application management policy, Configuration Manager will recognize that an app management policy must be linked to this deployment type when the associated app gets deployed and prompt you to associate an app management policy.

   

Important: If the application is already deployed, then the deployment for the new deployment type will fail until this association is made. You can make the association in Properties for the application, on the Application Management tab.

Important: For devices that run operating systems earlier than iOS 7.1, associated policies will not be removed when the app is uninstalled.

If the device is unenrolled from Configuration Manager, polices are not removed from the apps. Apps that had policies applied will retain the policy settings even after the app is uninstalled and reinstalled.

1. (for iOS apps only) - On the App Configuration Policies page of the wizard, click New to associate this deployment with an iOS app configuration policy (if you have created one). For more information about this type of policy, see Configure iOS apps with app configuration policies in System Center Configuration Manager.
2. On the Summary page of the Deploy Software Wizard, review the actions that will be taken by this deployment, and then click Next to complete the wizard.

Monitor the App Deployment

Once you have created and deployed an app associated with a mobile application management policy, you can monitor the app and resolve any policy conflicts.

1. In the Configuration Manager console, click Software Library.
2. In the Monitoring workspace, expand Overview, and then click Deployments.
3. Select the deployment and on the Home tab, click Properties.
4. In the details pane for the deployment, click Application Management Policies under Related Objects.

How policy conflicts are resolved

When there is a mobile application management policy conflict on the first deployment to the user or device, the specific setting value in conflict will be removed from the policy deployed to the app, and the app will use a built-in conflict value.

When there is a mobile app management policy conflict on later deployments to the app or user, the specific setting value in conflict will not be updated on the mobile app management policy deployed to the app, and the app will use the existing value for that setting.

In cases where the device or user receives two conflicting policies, the following behavior applies:

• If a policy has already been deployed to the device, the existing policy settings are not overwritten.
• If no policy has already been deployed to the device, and two conflicting settings are deployed, the default setting built into the device is used.

   

Reference: https://technet.microsoft.com/en-us/library/mt613194.aspx

Setup Email, VPN, Wi-Fi Profiles

Since you have now deployed client certificates from the NDES setup earlier, you can use it to make the profiles that you want to deploy to have a certificate based authentication.

Email Profiles

You can use email profiles to configure the Native email client on the following device types:

• Windows Phone 8 and later
• Windows 10 desktop, Windows 10 Mobile, and later
• OS 7.1 and later
• For Android, only Samsung KNOX Standard (4.0 and later)

Start the Create Exchange ActiveSync Email Profile Wizard.

1. In the System Center Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, expand Company Resource Access, and then click Email Profiles.
3. On the Home tab, in the Create group, click Create Exchange ActiveSync Profile.

   

4. On the General page of the Create Exchange ActiveSync Email Profile Wizard, specify the following information:

   

5. Configure Exchange ActiveSync settings for the Exchange ActiveSync email profile

   

• Exchange ActiveSync host: Specify the hostname of your company Exchange Server that hosts Exchange ActiveSync services.
• Account name: Specify the display name for the email account as it will be displayed to users on their devices.
• Account user name: Select how the email account user name is configured on client devices. You can select one of the following options from the drop-down list:
  • User Principal Name Use the full user principal name to log onto Exchange.
  • Primary SMTP Address Use the users primary SMTP address to log onto Exchange.
• Email address: Select how the email address for the user on each client device is generated. You can select one of the following options from the drop-down list:
  • Primary SMTP Address Use the users primary SMTP address to log onto Exchange.
  • User Principal Name Use the full user principal name as the email address.
• Account domain: Choose one of the following options:
  • Obtain from Active Directory
  • Custom
• Authentication method: Choose one of the following authentication methods that will be used to authenticate the connection to Exchange ActiveSync:
  • Certificates An identity certificate will be used to authenticate the Exchange ActiveSync connection.
  • Username and Password The device user must supply a password to connect to Exchange ActiveSync (the user name is configured as part of the email profile).
• Identity certificate: Click Select and then select a certificate to use for identity.

Note: If you have deployed an email profile and then wish to change the values for host or Email address, you must delete the existing email profile and create a new one with the required values.

1. Configure synchronization settings for the Exchange ActiveSync email profile

   

2. On the Supported Platforms page of the Create Exchange ActiveSync Email Profile Wizard, select the operating systems on which the email profile will be installed, or click Select all to install the email profile on all available operating systems.

   

3. On the Summary page of the wizard, review the actions to be taken, and then complete the wizard. The new Exchange ActiveSync email profile is displayed in the Email Profiles node in the Assets and Compliance workspace.

NOTE: If you want to remove an email profile from a device, edit the deployment and remove any groups of which the device is a member.

Reference: https://technet.microsoft.com/en-us/library/mt629448.aspx

VPN Profiles

You can configure the following device types with VPN profiles:

• Devices that run Windows 8.1 32-bit
• Devices that run Windows 8.1 64-bit
• Devices that run Windows RT 8.1
• Devices that run Windows Phone 8.1
• Devices that run iOS 5, iOS 6, iOS 7 and iOS 8
• Devices that run Android 4.0 and later

Step 1: Start the Create VPN Profile Wizard

1. In the System Center Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace of the System Center Configuration Manager console, expand Compliance Settings, expand Company Resource Access, and then click VPN Profiles.
3. On the Home tab, in the Create group, click Create VPN Profile.
4. On the General page of the Create VPN Profile Wizard, specify the following information

   

5. On the Connection page of the wizard, Provide Connection Information for the VPN Profile

    

Note: Below are the supported connection type for the VPN connection of different platforms.

Note: Please take a look for more information about your VPN profile connection type here: https://technet.microsoft.com/en-US/library/mt629189.aspx

From the drop-down list, select the connection type for the VPN connection

Note: Before you can use VPN profiles deployed to a device, you must ensure that any third-party VPN apps that you require are installed.

1. Server list: Click Add to add a new server to use for the VPN connection. Depending on the connection type, you can add one or more VPN servers and also specify which server is to be the default server.

Note: Devices that run iOS do not support using multiple VPN servers. If you configure multiple VPN servers and then deploy the VPN profile to an iOS device, only the default server is used.

1. Configure the Authentication Method for the VPN Profile

   

Note: Devices that run iOS support only RSA SecurID and MSCHAP v2 for the authentication method when the connection type is PPTP. To avoid reporting errors, deploy a separate PPTP VPN profile to devices that run iOS.

For iOS devices, the SCEP profile you select will be embedded in the VPN profile. For other platforms, an applicability rule is added to ensure that the VPN profile is not installed if the certificate is not present, or not compliant.

If the SCEP certificate you specify is not compliant, or has not been deployed, then the VPN profile will not be installed on the device.

1. Configure Proxy Settings for the VPN Profile
2. Configure Supported Platforms for the VPN Profile

Reference: https://technet.microsoft.com/en-US/library/mt629189.aspx

Wi-Fi Profiles

You can configure the following device types with Wi-Fi profiles:

• Devices that run Windows 8.1 32-bit
• Devices that run Windows 8.1 64-bit
• Devices that run Windows RT 8.1
• Devices that run Windows Phone 8.1
• Devices that run Windows 10 Desktop or Mobile
• iPhone devices that run iOS 5, iOS 6, iOS 7 and iOS 8
• iPad devices that run iOS 5, iOS 6, iOS 7 and iOS 8
• Android devices that run version 4

Start the Create Wi-Fi Profile Wizard

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, expand Company Resource Access, and then click Wi-Fi Profiles.
3. On the Home tab, in the Create group, click Create Wi-Fi Profile.
4. On the General page of the Create Wi-Fi Profile Wizard, enter a unique name and description for the Wi-Fi profile. You can use a maximum of 256 characters.

   

5. In SSID, specify the name (SSID), of the wireless network that you want devices to be able to connect to. You can use a maximum of 32 characters. The SSID name is case-sensitive, so be sure to enter it exactly as it is configured.

   

6. Configure Security for the Wi-Fi Profile.

   In this example WPA2-Enterprise is selected as the security type and will use a certificate based authentication

   

1. Select the Use a certificate on the computer and tick the Use Simple Certificate selection.

    

   

    

Note:

For Android devices only: the security types WPA – Personal, WPA2 – Personal and WEP are not supported.

For Windows Phone devices only: the EAP types LEAP and EAP-FAST are not supported.

For iOS devices only: You must configure the client certificate and either the trusted server certificate name or the root certificate, as follows: Trusted server certificate names: If the server that the device connects to uses a server authentication certificate to identify the server and help secure the communication channel, enter the name or names in that certificate's subject name or subject alternative name

Note: If the client certificate that you select for EAP or client authentication for an iOS device will be used to authenticate to a Remote Authentication Dial-In User Service (RADIUS) server, such as a server that is running Network Policy Server, you must set the Subject Alternative Name to the User Principal Name.

Select root certificates for server validation: If the server that the device connects to uses a server authentication certificate that the device does not trust, select the certificate profile that contains the root certificate for the server certificate, to create a certificate chain of trust on the device.

Select a client certificate for client authentication: If the server or network device requires a client certificate to authenticate the connecting device, select the certificate profile that contains the client authentication certificate.

Reference: https://technet.microsoft.com/en-US/library/mt629440.aspx

Deploy VPN, WIFI or Email Profile

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, expand Company Resource Access, and select the Profiles you want to deploy either VPN, WIFI, or Email Profiles.

   

3. In the Type of Profiles list, select the VPN, WIFI, or Email Profiles that you want to deploy, right click and Deploy.

   

4. In the Deploy VPN Profile dialog box, specify the following information:

   

• Collection - Click Browse to select the collection where you want to deploy the VPN profile.
• Generate an alert - Enable this option to configure an alert that is generated if the VPN profile compliance is less than a specified percentage by a specified date and time. You can also specify whether you want an alert to be sent to System Center Operations Manager.
• Specify the compliance evaluation schedule for this VPN profile - Specify the schedule by which the deployed VPN profile is evaluated on client computers. The schedule can be either a simple or a custom schedule.

   

Note: The profile is evaluated by client computers when the user logs on.

1. Click OK to close the Deploy VPN Profile dialog box and to create the deployment. For more information about how to monitor the deployment, see How to monitor VPN profiles in System Center Configuration Manager.

Monitor the Deployment of the VPN, WIFI or Email Profile

1. In the System Center Configuration Manager console, click Monitoring.

   

2. In the Monitoring workspace, click Deployments.
3. In the Deployments list, select the Profile deployment for which you want to review compliance information. In this example, a certificate profile was deployed.
4. You can review summary information about the compliance of the profile deployment on the main page. To view more detailed information, select profile deployment, and then right click View Status to open the Deployment Status page.

   

   The Deployment Status page contains the following tabs:

• Compliant: Displays the compliance of the profile that is based on the number of affected assets.
• Error: Displays a list of all errors for the selected profile deployment that is based on the number of affected assets.
• Non-Compliant: Displays a list of all noncompliant rules within the profile that are based on the number of affected assets.
• Unknown: Displays a list of all users that did not report compliance for the selected profile deployment together with the current client status of the devices.

Set-Up Azure Rights Management (RMS)

Important: Before you activate Rights Management, make sure that your organization has a service plan that includes Rights Management services. If not, you will not be able to activate Azure RMS.

Activate Azure RMS

When you activate Azure Rights Management (Azure RMS), your organization can start to protect important data by using applications and services that support this information protection solution. Administrators can also manage and monitor protected files and emails that your organization owns. You must enable Rights Management before you can begin to use the information rights management (IRM) features within Office, SharePoint, and Exchange, and protect any sensitive or confidential file.

There are different ways to activate Rights Management from your management portal, select whether you will use the Office 365 admin center (preview or classic), or the Azure classic management portal. In this document Azure Classic management portal will be use.

1. After you have signed up for your Azure account, sign in to the Azure classic portal.
2. In the left pane, click ACTIVE DIRECTORY.
3. From the Active Directory page, click RIGHTS MANAGEMENT.
4. Select the directory to manage for Rights Management, click ACTIVATE, and then confirm your action.

The RIGHTS MANAGEMENT STATUS should now display Active and the ACTIVATE option is replaced with DEACTIVATE.

NOTE: If you see an activation error, it might be because your service plan or product version does not include Rights Management.

Reference: https://docs.microsoft.com/en-us/rights-management/deploy-use/activate-service

Set up Azure Rights Management for Exchange Online

The next steps are completed via connecting to Exchange Online with PowerShell

1. Open PowerShell as Administrator
2. Enter the following commands to connect and import the session

• Set-ExecutionPolicy RemoteSigned

  (In the prompt, choose Yes to All)

• $cred = Get-Credential

  (In the prompt, Enter your O365 Admin username and password)

• $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic –AllowRedirection
• Import-PSSession $Session

1. Check your IRM isn't configured already

• Get-IRMConfiguration

1. Configure RMS with the online key-sharing location for Exchange Online with PowerShell (locations below). In this example North America was used, but the table below shows all the locations

• Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc

1. Import the Trusted Publishing Domain (TPD) from RMS Online

• Import-RMSTrustedPublishingDomain -RMSOnline -name "RMS Online"

1. Verify successful setup of IRM in Exchange Online

• Test-IRMConfiguration –sender admin@domain.com 

1. Enable IRM for Exchange Online and Office 365 Message Encryption

• Set-IRMConfiguration -InternalLicensingEnabled $true

1. View the IRM Configuration

• Get-IRMConfiguration

Reference: https://technet.microsoft.com/en-us/library/dn151475(v=exchg.150).aspx

Configuring custom templates for Azure Rights Management

After you have activated Azure Rights Management (Azure RMS), users are automatically able to use two default templates that make it easy for them to apply policies to sensitive files that restrict access to authorized users in your organization. These two templates have the following rights policy restrictions:

Exchange clients and services (for example, the Outlook client, the Outlook Web Access app, and Exchange transport rules) have one additional information rights protection option for emails: Do Not Forward.

Although this option appears to users (and Exchange administrators) as if it's a default Rights Management template that they can select, Do Not Forward is not a template. That explains why you cannot see it in the Azure classic portal when you view and manage templates for Azure RMS. Instead, the Do Not Forward options is a set of rights that is dynamically applied by users to their email recipients.

Note: Use Do Not Forward when it's important that only the recipients that the sender chooses should see the information in the email. Use a template for emails to restrict rights to a group of people that the administrator specifies in advance, independently from the sender's chosen recipients.

To create a custom template:

1. Depending on whether you sign in to the Office 365 admin center, or the Azure classic portal, do one of the following:

From the Azure classic portal:

1. In the left pane, click ACTIVE DIRECTORY.
2. From the active directory page, click RIGHTS MANAGEMENT.
3. Select the directory to manage for Rights Management.

1. Create a new template:

You can copy custom templates and the default templates. As a best practice, copy one of the default templates instead of creating a new custom template if you want the template to grant rights to all users in your organization. This method means that you don't have to create or select multiple groups to specify all users. In this scenario however, be sure to specify a new name and description for the copied template for additional languages.

If you want to create a new template that has very similar settings to an existing template, select the original template on the TEMPLATES page, click COPY, specify a unique name, and make the changes that you need.

    If you want to a new one and apply only on selected group, Click ADD

1. Choose a language in which you will type the template name and description that users will see (you can add more languages later). Then type a unique name and a description, and click the Complete button.

Note: You can add users from outside your organization ("external users") to the template by selecting a mail-enabled group that contains contacts from Office 365 or Exchange Online. This lets you assign rights to these users in the same way as you can assign rights to users in your organization. For example, you can prevent customers from editing a price list that you send them. Do not use this template configuration for protecting emails if users from outside your organization will read the protected emails by using the Outlook Web App as they will not be able to view it.

1. Assign one of the listed rights to your selected users and groups. These are the users or group that will be able to consume and use the content that is protected by using this template.

1. If you selected Custom, click the Next button, and then select those custom rights.

1. If you want the template to be visible to only a subset of users when they see a list of templates in applications: Click SCOPE to configure this as a departmental template.

By default, all users and groups in your organization can apply the template created.

1. On the TEMPLATE VISIBILITY page, select the users and groups who will be able to see and select the template from the RMS-enlightened applications. As before, as a best practice, use groups rather than users, and the groups or users you select must have an email address.

1. Also decide whether you need to configure application compatibility for your departmental template. If you do, click APPLICATION COMPATIBILITY, select the check box, and click Complete.

For example, if you do not configure application compatibility for the departmental template in our Human Resources example, only users in the Human Resources department see the departmental template when they use the RMS sharing application, but no users see the departmental template when they use Outlook Web Access (OWA) from Exchange Server 2013 because Exchange OWA and Exchange ActiveSync do not currently support departmental templates. If you override this default behavior by configuring application compatibility, only users in the Human Resources department see the departmental template when they use the RMS sharing application, but all users see the departmental template when they use Outlook Web Access (OWA). If users use OWA or Exchange ActiveSync from Exchange Online, either all users will see the departmental templates or no users will see the department templates, based on the template status (archival or published) in Exchange Online.

Note: Office 2016 natively supports departmental templates, and so does Office 2013 starting with version 15.0.4727.1000, released in June 2015 as part of KB 3054853.

1. Click CONFIGURE and add additional languages that users use, together with the name and description of this template in that language and also to configure content expiration and Offline access.

1. When you are confident that the template is configured appropriately for your users, click PUBLISH to make the template visible for users, and then click SAVE.

1. Click the Back button in the classic portal to return to the TEMPLATES page, where your template now has an updated status of Published.

To make any changes to your template, select it, and then use the quick start steps again. Or, select one of the following options:

• To add more users and groups, and define the rights for those users and groups: Click RIGHTS, then click ADD.
• To remove users or groups that you previously selected: Click RIGHTS, select the user or group from the list, and then click DELETE.
• To change which users can see the templates to select them from applications: Click SCOPE, then click ADD or DELETE, or APPLICATION COMPATIBILITY.
• To make the template no longer visible to all users: Click CONFIGURE, click ARCHIVE, and then click SAVE.
• To make other configuration changes: Click CONFIGURE, make your changes, and then click SAVE.

Important: When you make changes to a template that was previously saved or create a new one, clients will not see those changes to the template until templates are refreshed on their computers. Update the templates, each time, you must run the following Exchange Online PowerShell to synchronize these changes to Exchange Online:

• Import-RMSTrustedPublishingDomain -Name "RMS Online - 1" -RefreshTemplates –RMSOnline

Take note: "RMS Online – 1" is the TPD name (a typical name for many organizations, To verify your TPD name, you can use the Get-RMSTrustedPublishingDomain cmdlet.

If you want the templates to be to be available in the Outlook Web App, you must use the Set-RMSTemplate cmdlet and set the Type to Distributed:

• Set-RMSTemplate -Identity "<name or GUID of the template>" -Type Distributed

Because Outlook Web Access caches the UI for 24 hours, users might not see the new template for up to a day.

Reference:
https://docs.microsoft.com/en-us/rights-management/deploy-use/create-template

https://docs.microsoft.com/en-us/rights-management/deploy-use/configure-usage-rights

https://docs.microsoft.com/en-us/rights-management/deploy-use/refresh-templates

This Blog post was published by the authors Lutz Seidemann (Architect) and Raymond Michael Sy Guan (Consultant). We both with Microsoft Consulting Services – Worldwide Enterprise Mobility Center of Excellence (CoE).

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

]]> https://docs.microsoft.com/archive/blogs/mobilityguys/enterprise-mobility-end-to-end-part-5-define-access-conditions Mon, 18 Jul 2016 18:45:41 GMT https://blogs.technet.microsoft.com/mobilityguys/?p=11785 In Part 5 we will focus on Conditional Access, Device Health Attestation and Multi Factor Authentication. Think about a combination of device health status (example: secure boot is enabled) and a location (example: outside of corp network) where you have the option to build powerful access condition policies and enforce MFA when needed. We recommend to have a clear strategy when you want to enforce an additional factor of authentication. If you followed the Blog so far, you have already a second factor authentication using Passport and Hello, adding Azure MFA is your 3 level of authentication. Don't get crazy, your users will hate you and not adopt the solution if you over-engineer. something only you know – Passport Pin + something only you are – Face or Iris + something only you have – Phone

Set-Up Conditional Access Using Configuration Manager with Intune (Hybrid)

With the move to cloud services and BYOD, organizations are looking for secure and effective solutions to protect data while enhancing user productivity and device flexibility. Tenant administrators can leverage conditional access policies to prevent users on non-compliant devices from accessing an O365 service, and to better protect Office 365 content that is accessed from these devices.

A typical flow for conditional access might look as follows: Conditional access can be used to manage access to the following services:

• Microsoft Exchange On-premises
• Microsoft Exchange Online
• Exchange Online Dedicated
• SharePoint Online
• Skype for Business Online

But the main purpose of this document is to define conditional access in relation to Office 365 Exchange Online for Windows 10 desktop and Mobile devices.   Prerequisites 

• O365 subscription. The O365 subscription is for setting up Exchange Online, SharePoint Online and Skype for Business Online. Having O365 subscription will automatically give you an Azure AD
• A Microsoft Intune Subscription. The Microsoft Intune Subscription should be configured in Configuration Manager and Devices should be enrolled to Intune except domain joined PC's
• Register the device in Azure Active Directory (this happens automatically when the device is enrolled with Intune)
• Azure AD Connect to extend the on-premises directory to Azure AD (For managed PC's)
• Have activated email, which associates the device's Exchange ActiveSync ID with the device record in Azure Active Directory (applies to iOS and Android devices only).
• For Skype for Business Online you need to also enable the modern authentication. Fill this connect form to be enrolled in the modern authentication program. Plus, all your end-users must be using Skype for Business Online. If you have a deployment with both Skype for Business Online and Skype for Business on-premises, conditional access policy will not be applied to end-users. (Currently, applies only to iOS and Android devices).

• Currently support only Exchange Online and SharePoint Online
• Support for Exchange On Premise Conditional access will only be applicable if the device is Intune enrolled
• Windows 10 build (build 10551 or newer) for devices
• Automatic device registration with Azure Active Directory for Domain Joined PC
• For BYOD PC's, you must register your device to Azure AD by either adding Work Account or doing an Azure AD joined directly during Out of the Box Experience.
• Office 365 Modern Authentication enabled on the tenant level.
• If using Office 2013, it should have the latest office updates with modern authentication enabled (thru registry settings)
• If Office 2016, modern authentication is already enabled by default.

• Android 4.0 and later, Samsung Knox Standard 4.0 and later (Built-in Native Mail client and Outlook App)
• iOS 7.1 and later (Built-in Native Mail client and Outlook App)
• Windows Phone 8.1 and later (Built-in Native Mail client and Outlook App)
• The Modern Mail Application on Windows 8.1 Desktop and later

Note: Outlook App for iOS and Android is NOT supported for Exchange On-Premise Conditional Access.The OWA apps for iOS and Android are not supported. They should be blocked through ADFS claims rules.

• Microsoft Office Mobile (Android)
• Microsoft OneDrive (Android and iOS)
• Microsoft Word (Android and iOS)
• Microsoft Excel (Android and iOS)
• Microsoft PowerPoint (Android and iOS)
• Microsoft OneNote (Android and iOS)

• If the device is not enrolled, or registered in Azure Active Directory, a message is displayed with instructions about how to install the company portal app and enroll
• If the device is not compliant, a message is displayed that directs the user to the Intune web portal where they can find information about the problem and how to remediate it.
• For a PC:
  • If the policy is set to require domain join, and the PC is not domain joined, a message is displayed to contact the IT admin.
  • If the policy is set to require domain join or compliant, then the PC does not meet either requirement, a message is displayed with instructions about how to install the company portal app and enroll.

Note: Configuration Manager conditional access rules override, allow, block and quarantine rules that are defined in the Exchange Online admin console.

Enable Modern Authentication

Customers are asking for stronger authentication mechanisms and for better capabilities in controlling access to Office 365 services. Some customers want to enforce Multi-Factor Authentication outside of their network perimeter, require Smartcard authentication, or simply do not want to transmit their credentials (username/password) to Microsoft.

To respond to these needs, Office 365 services and clients are gradually updated to support new authentication flows, enabling "Modern Authentication" scenarios for Office 365 rich clients such as:

• Multi-Factor Authentication support;
• Smartcard and certificate-based authentication;
• Claim-based authentication support (Basic Authentication no longer mandatory for Outlook);
• Support for 3^rd party SAML-based identity providers.

Office 365 Service Enablement

The Office 365 tenant/resource host (Exchange Online, SharePoint Online and Skype for Business Online) will need to be configured to accept a modern authentication connection. The table below summarizes Modern Authentication enablement status, for each workload:

Exchange Online: Modern Authentication TENANT Enablement

1. Connect to Exchange Online using remote PowerShell: https://technet.microsoft.com/library/jj984289(v=exchg.160).aspx 
2. Check the current status of your tenant

•  Get-OrganizationConfig | fl OAuth2ClientProfileEnabled

1. Run the following command:

• Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

• Verify that the change was successful by running the following:
  • Get-OrganizationConfig | fl OAuth2ClientProfileEnabled

Office Client Modern Authentication Enablement

To enable modern authentication for any devices running Windows (for example on laptops and tablets), that have Microsoft Office 2013 installed, you need the following:

1. You will need the latest Office 2013 update or at least March 2015 update patch described here: March 2015 Office Update Release
2. Set the following registry keys. The keys have to be set on each device that you want to enable for modern authentication:
   

Block Non-Modern Authentication Client

Currently, apps that do not use modern authentication must be blocked access by using other methods, because they are not enforced by conditional access. This is primarily a consideration for Exchange and SharePoint access, as previous app versions have been built using older protocols.

Important: If your organization is using Active Directory Federation Services (AD FS) for Client Access Filtering and have the scenario as describe in the table below and you enable modern authentication on your O365 Tenant, Rich Clients (Outlook and other Office apps) will be able to bypass your client access filtering policies and in ADFS access resources like Exchange Online and SharePoint online.

• Open the AD FS Management console;
• Navigate to AD FS > Trust Relationships > Relying Part Trusts;
• Right-click the Microsoft Office 365 Identity Platform trust and select Edit Claim Rule.
• Navigate to Issuance Authorization Rules and click Add Rule to open the Add Issuance Authorization Claim Rule Wizard

  

• On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.

  

• On the Choose Claim Rule page, specify a Claim rule name, provide the following Claim rule

  

• Click Finish.
• Verify that this new claim rule is created below the default Permit Access to All Users claim rule.

Note:

Configure Conditional Access Policy

Conditional Access Policy is a requirement configuration if you want to set certain conditions to a group of users to access a particular service like Exchange Online or SharePoint Online. Within this conditions you can choose either the devices must be domain joined or complaint or both.

Compliance Policy is an additional set of rules that you can add to complement the conditional access policy. If you selected the compliance policies that you want the device to evaluate like Encryption or PIN, they must meet those policies during evaluation in order to be tag as Compliant be allow to access a particular service if the policy set in Conditional access should be Compliant.

Note: Compliance Policy is not mandatory. If you didn't specify any Compliance Policy but have set Conditional Access Policy, all devices will be evaluated as Complaint and will be allow to access the service you have defined.

Enable the Exchange Online policy

• In the Configuration Manager console, click Assets and Compliance. 
• Expand Compliance Settings, expand Conditional Access, and then click Exchange Online.
• On the Home tab, in the Links group, click Configure Conditional Access Policy in the Intune Console. You might need to provide the user name and password of the account used to connect Configuration Manager with any global administrator for the Intune service.
• In the Microsoft Intune administration console, click Policy > Conditional Access > Exchange Online Policy.
• On the Exchange Online Policy page, select Enable conditional access policy for Exchange Online. If you check this, the device must be compliant or domain joined, depend on your chosen condition. If this is not checked then conditional access is not applied.
  

• Under Outlook and other apps using modern authentication, you can choose to restrict access only to devices that are compliant for each platform. Windows devices must either be domain joined, or be enrolled in Intune and compliant.
  

Note: Modern Authentication brings Active Directory Authentication Library (ADAL)-based sign in to Office clients.

The ADAL based authentication enables Office clients to engage in browser-based authentication (also known as passive authentication). To authenticate, the user is directed to a sign-in web page.

This new sign-in method enables new scenarios such as, conditional access, based on device compliance and whether multi-factor authentication was performed.

• Using Exchange Online with Configuration Manager and Intune, you can not only manage mobile devices with conditional access, but also desktop computers as well. PCs must either be domain joined, or be enrolled in Intune and compliant.
  You can set the following requirements:
  • Devices must be domain joined or compliant. PCs must either be domain joined or compliant with the policies set in Intune. If a PC does not meet either of these requirements, the user is prompted to enroll the device with Intune.
  • Devices must be domain joined. PCs must be domain joined to access Exchange Online. If a PC is not domain joined, access to email is blocked and the user is prompted to contact the IT admin.
  • Devices must be compliant. PCs must be enrolled in Intune and compliant. If a PC is not enrolled, a message with instructions on how to enroll is displayed.

Note: If you want to enforce Compliance Policy for Managed PC to meet certain conditions like Require registration in Azure Active Directory,

• Under Outlook web access (OWA), you can choose to allow access to Exchange Online only through the supported browsers: Safari (iOS), and Chrome (Android) or Manage Intune Browser. Access from other browsers will be blocked. The same platform restrictions you selected for Application access for Outlook also apply here.

  

  For Android devices, users must enable the browser access. To do this the end-user must enable the "Enable Browser Access" option on the enrolled device as follows:

1. Launch the Company Portal app.
2. Go to the Settings page from the triple dots (…) or the hardware menu button.
3. Press the Enable Browser Access button.
4. In the Chrome browser, sign out of Office 365 and restart Chrome.

On iOS and Android platforms, to identify the device that is used to access the service, Azure Active Directory will issue a Transport layer security (TLS) certificate to the device. The device displays the certificate with a prompt to the end-user to select the certificate as seen in the screenshots below. The end-user must select this certificate before they can continue to use the browser.

• Under Exchange ActiveSync mail apps, you can choose to block email from accessing Exchange Online if the device is noncompliant, and select whether to allow or block access to email when Intune cannot manage the device.
  
• Under Targeted Groups, select the Active Directory Security Groups of users to which the policy will apply.
  

Note: For users that are in the Targeted groups, the Intune polices will replace Exchange rules and policies. Exchange will only enforce Exchange allow, block and quarantine rules, and Exchange policies if:

• The user is not licensed for Intune.
• The user is licensed for Intune, but the user does not belong to any security groups targeted in the conditional access policy.

• Under Exempted Groups, select the Active Directory security groups of users that are exempt from this policy. If a user is in both the targeted and exempted groups, they will be exempt from the policy and will have access to their email.
  
• When you are finished, click Save.

Note:

• You do not have to deploy the conditional access policy; it takes effect immediately.
• After a user creates an email account, the device is blocked immediately.
• If a blocked user enrolls the device with Intune (or remediates noncompliance), email access is unblocked within 2 minutes.
• If the user un-enrolls their device, email is blocked after about 6 hours.

Configure Compliance Policy

• Devices must be domain joined or compliant
• Devices must be domain joined
• Devices must be compliant

• Require registration in Azure Active Directory- This rule checks if the user's device is work-place joined to Azure AD, and if not, the device is automatically registered in Azure AD. Automatic registration is only supported on Windows 8.1. For Windows 7 PCs, deploy an MSI to perform the auto registration
• All required updates installed with a deadline older than a certain number of days - This rule checks to see if the user's device has all required updates (specified in the Required automatic updates rule) within deadline and grace period specified by you, and automatically install the any pending required updates. 
• Require BitLocker drive encryption - This is a check to see if the primary drive (e.g. C:\) on the device is BitLocker encrypted. If BitLocker encryption is not enabled on the primary device access to email and SharePoint services is blocked.
• Require Antimalware - This is a check to see if the antimalware software (System Center Endpoint Protection or Windows Defender only) is enabled and running. If it is not enabled, access to email and SharePoint services is blocked.

1. For Windows PC that are BYOD only MDM managed, meaning this is WITHOUT Configuration Manager client installed. (Compliance policies for devices managed by Microsoft Intune)
2. For Windows PC that are domain joined and WITH Configuration Manager client installed. (Compliance policies for PCs managed by System Center Configuration Manager)

Compliance Rules for devices managed WITHOUT the Configuration Manager client (MDM managed)

• The device will be blocked if the user is targeted by a conditional access policy.
• The company portal or web portal will notify the user about any compliance issues.

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
3. On the Home tab, in the Create group, click Create Compliance Policy.
   
4. On the General page of the Create Compliance Policy Wizard, specify the following information:
   
5. On the Supported Platforms page, choose the device platforms that this compliance policy will be evaluated on, or click Select all to choose all device platforms.
   
6. On the Rules page, you define one or more rules that define the configuration that devices must have in order to be evaluated as compliant. The following table shows the available rules. When you create a compliance policy, some rules are enabled by default, but you can edit or delete these.

Note: Not all rules will be applicable to Windows PC, there are some only applicable to Mobile devices. Please check: Manage device compliance policies in System Center Configuration Manager

Note: "Require devices to be reported as healthy" is only applicable to Window 10 PC and Windows 10 Phone. If you need to enable this capability, look on the Appendix section.

Deploy Compliance Policy Intune managed PC's

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
3. On the Home tab, in the Deployment group, click Deploy.
4. In the Deploy Compliance Policy dialog box, click Browse to select the user collection to which to deploy the policy.
   
5. Additionally, you can select options to generate alerts when the policy is not compliant, and also to configure the schedule by which this policy will be evaluated for compliance.
6. When you are done, click OK.

Compliance Rules for devices managed WITH the Configuration Manager client

Note: Beginning in version 1602 of Configuration Manager, you can configure conditional access for PCs managed by System Center Configuration Manager.

Note: Pre-release features are included in the product for early testing in a production environment, but should not be considered production ready.

Important:

Conditional access for PCs and Windows 10 Mobile devices with apps using modern authentication is not currently available to all Intune customers. If you are already using these features in Intune, you do not need to take any action. You can continue to use them.

This does not apply to PCs or Windows 10 Mobile devices for conditional access to Exchange On-premises.

If you have not created conditional access policies for PCs or Windows 10 Mobile for apps using modern authentication, you will need to submit a request for access. You can find out more information about known issues as well as how to get access to this feature at the connect site.

1. In the Configuration Manager administration console, navigate to Administration >Overview > Cloud Services > Updates and Servicing > Features;
2. Right-click Pre-release – Conditional access for managed PCs and select Turn On.
   

1. Once you have turned On the feature, Login to your Intune Portal, click Policy > Conditional Access > Exchange Online Policy and Set the Windows PC requirement to Devices must be compliant option.
2. Go back to the Configuration Manager console, click Assets and Compliance.
3. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
4. On the Home tab, in the Create group, click Create Compliance Policy.
   
5. On the General page of the Create Compliance Policy Wizard, fill the Name and Select the option Compliance rules for devices managed with Configuration Manager client.
   
6. On the Supported Platforms page, choose the device platforms that this compliance policy will be evaluated on, or click Select all to choose all device platforms.
   
7. On the Rules page, you define one or more rules that define the configuration that devices must have in order to be evaluated as compliant. The following table shows the available rules. When you create a compliance policy, some rules are enabled by default, but you can edit or delete these.
   
8. On the Summary page of the wizard, review the settings you made, and then complete the wizard.

Deploy Compliance Policy for SCCM manage PC's

1. In the Configuration Manager console, click Assets and Compliance.
2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
3. On the Home tab, in the Deployment group, click Deploy.
4. In the Deploy Compliance Policy dialog box, click Browse to select the user collection to which to deploy the policy.
   Additionally, you can select options to generate alerts when the policy is not compliant, and also to configure the schedule by which this policy will be evaluated for compliance.
5. When you are done, click OK.

Note: To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center.

References: Health attestation for System Center Configuration Manager Manage access to O365 services for PCs managed by System Center Configuration Manager

Enabling Device Health Attestation (DHA)

Administrators can view the status of Windows 10 Device Health Attestation in the Configuration Manager console. This functionality is available for Configuration Manager and Configuration Manager with Microsoft Intune. Device health attestation lets the administrator ensure that client computers have the following trustworthy BIOS, TPM, and boot software configurations enabled.

Note: DHA rules for Conditional Access are currently only supported via Hybrid configuration and not yet for full client on premise and these DHA rules cannot be configured individually yet even for hybrid. Meaning it should enable and meet the four parameters to declare the device as healthy: Early-Launch Antimalware, BitLocker, Secure Boot, and Code Integrity

• Client devices running Win10
• TPM 2 enabled (requires UEFI Firmware)
• The Configuration Manager client agent must be enabled to communicate Health Attestation service

How to enable Health Attestation service communication on Configuration Manager client computers

1. In the Configuration Manager console, go Administration > Overview > Client Settings. for Computer Agent settings.
   
2. In the Default Settings dialog box, select Computer Agent and then scroll down to Enable communication with Health Attestation Service
   
3. Set Enable communication with Health Attestation Service to Yes, and then click OK.

How to view Health Attestation

1. To view the device health attestation in the Configuration Manager console, go to the Monitoring workspace, click Security node, and then click Health Attestation.
   
2. To view the Device Health Attestation Reports in the Configuration Manager console, go to the Monitoring >Overview > Reporting > Device Management and select List of devices by Health Attestation State
   
3. Device Health Attestation is displayed.

Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

Reference: https://technet.microsoft.com/en-us/library/mt651779.aspx https://technet.microsoft.com/en-us/library/mt629503.aspx

Conditional access effect on the managed PC

If you have set your Conditional Access to allow Domain Joined or Complaint Devices, then ALL domain joined machines will be automatically granted to set up or access their Outlook client that are modern authentication enabled. But for non-domain joined machines it should meet the compliance policy set by the organization as shown below:

1. Launch the Office Outlook Application. Click Next
   
2. Select Yes and Click Next
   
3. Enter your email address and password, click Next
   
4. It will try to search your mailbox setting
   
5. Once it found your mailbox settings, a browser based authentication will prompt and will ask you to re-enter your credentials.
   
6. If your device is not yet enrolled to Intune MDM, it will ask you to enroll first your device and should meet the compliance policy settings set by your organization.
   

Note: If the organization decided to block the legacy client or non-modern authentication client, it will not let you to set up your Outlook client or if you have existing account already it will keep on prompting to enter your credentials and will disconnect your outlook even you have entered you credential correctly.

Note: The optional Exchange Server connector is optional and connects Configuration Manager to Microsoft Exchange Online and helps you monitor device information through the Configuration Manager console (see How to Manage Mobile Devices by Using Configuration Manager and Exchange). You do not need to use the connector to use compliance policies or conditional access policies, but is required to run reports that help evaluate the impact of conditional access.

Microsoft Intune standalone

Below is the overview table for Microsoft Intune standalone.

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

Configuration Manager with Intune hybrid

Below is the overview table for Microsoft Intune hybrid.

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

Set-Up Per-Application Access Rules (Conditional Access based on Location and MFA)

Conditional Access rules are supported across various Azure AD application types. This list includes:

• Federated applications from the Azure AD application gallery
• Password SSO applications from the Azure AD application gallery
• Applications registered with the Azure Application Proxy
• Developed line of business and multi-tenant applications registered with Azure AD
• Visual Studio Online
• Azure Remote App
• Dynamics CRM
• Microsoft Office 365 Yammer
• Microsoft Office 365 Exchange Online
• Microsoft Office 365 SharePoint Online (includes OneDrive for Business)

Note: These capabilities will be available to customers that have purchased an Azure Active Directory Premium license and Federated or managed Azure Active Directory tenant

1. Sign in to the Azure classic portal Using an account that is a global administrator for Azure AD.
2. On the left pane, select Active Directory.
3. On the Directory tab, select your directory.

   

4. Select the Applications tab.

   

5. Select the application that the rule will be set for.
6. Select the Configure tab.

   

7. Enable the policy by selecting Enabled to be On.
8. Specify the Group of Users the rule will apply to or you can select ALL Users
9. Scroll down to the access rules section. Select the desired access rule.

   Access rule options The current preview supports the following options:

• Require multi-factor authentication: With this option the users that the access rules apply to will be required to complete multi-factor authentication before accessing the application the policy applies to.
• Require multi-factor authentication when not at work: With this option a user that is coming from a trusted IP address will not be required to perform multi-factor authentication. The trusted IP address ranges can be configured on the multi-factor authentication settings page or by using configuring public IP address ranges on the directory Configure tab.
• Block access when not at work: With this option a user that is not coming from a trusted IP address will be blocked. The trusted IP address ranges can be configured on the multi-factor authentication settings page.

If you have decided to configure Trusted IPs, select either:

• For requests from federated users originating from my intranet – All federated users who are signing in from the corporate network will bypass multi-factor authentication using a claim issued by AD FS.
• For requests from a specific range of public IPs – enter the IP addresses in the boxes provided using CIDR notation. For example: xxx.xxx.xxx.0/24 for IP addresses in the range xxx.xxx.xxx.1 – xxx.xxx.xxx.254, or xxx.xxx.xxx.xxx/32 for a single IP address. You can enter up to 50 IP address ranges.

Reference: https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access/ https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-azuread-connected-apps/ https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-supported-apps/

Set-Up Azure Multi-Factor Authentication (MFA)

Multi-factor authentication, also commonly referred to as two-factor authentication, is a best practice for securing user access. It works by requiring any two or more of the following authentication factor:

• A knowledge factor: something only you know (typically a password or a PIN).
• A possession factor: something only you have (a trusted device that is not easily duplicated).
• An inherence factor: something only you are (biometrics).

Azure MFA helps to deliver strong security via a range of easy authentication options. Thus, in addition to entering a username and password during sign in, enabled users are also required to authenticate with a mobile app on their mobile device or via an automated phone call or a text message, allowing these users to choose the method that works best for them. Consequently, in order for an attacker to gain access to a user's account, they would need to know the user's login credentials AND be in possession of the user's phone. Furthermore, support for the above multiple methods enables to support more scenarios such as offline (no carrier) scenarios.

• Azure MFA stand-alone.
• Included in Azure AD Premium (see below).
• A subset of Azure MFA functionality included in Office 365 for both administrators and users.
• Free for Azure administrators.

Whilst Azure MFA is powered by a cloud service, the stand-alone version and well as the one included in Azure AD Premium support on-premises, cloud, and hybrid scenarios. The following solutions are indeed available for use with Azure MFA:

• Adding Multi-Factor Authentication to Azure AD. Azure MFA works with any applications that use the Azure AD directory tenants. As such, Azure MFA can be rapidly enabled for Azure AD identities to help secure access:
  • The Azure management portal,
  • Microsoft Online Services like Office 365, Intune, and Dynamics CRM Online, etc.
  • Any custom LOB, third-party multitenant cloud-based, or modern business applications that integrate with Azure AD for authentication,
  • As well as thousands of cloud SaaS applications like Box, GoToMeeting, Salesforce.com and others.
  Users will be prompted to set up additional verification the next time they sign in.
• Enabling Multi-Factor Authentication for on-premises applications and Windows Server. The Multi-Factor Authentication Server works out-of-the-box with a wide range of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-on systems and much more. This includes:
  • Microsoft products and technologies like Microsoft VPN/RRAS, Remote Desktop Services and Remote Desktop Gateway, Universal Access Gateway, SharePoint, Outlook Web Access, etc.
  • As well as third party VPNs and virtual desktop system.

Multi-Factor Authentication Server can be run on-premises on your existing hardware - as a virtual machine (VM) or not -, or in the cloud for instance as an Azure Virtual Machine. Multiple, redundant servers can be configured for high availability and fail-over.

• Building Multi-Factor Authentication into custom applications. A Software Development Kit (SDK) is available for use for direct integration with custom cloud-based and on-premises applications. It enables to build Multi-Factor Authentication phone call and text message verification into the application's sign-in or transaction processes and leverage the application's existing user database.

Note:    This applies only to browser-based applications. Multi-Factor Authentication is not supported by non-browser applications, excepted with Office 365 ProPlus/Office 2013 applications with modern authentication enabled. Modern authentication is available to any customer running the March 2015 or later update for Office 2013 but is disabled by default. Office 2016 is already enabled by default.

For the other non-browser-based applications, an app password must be created. An app password is a password that allows to by-pass the Multi-Factor Authentication (more information on this later in this document). Eventually, app passwords are only available to users that do not have administrative privileges.

Configuring Azure AD for Multi-Factor Authentication

Note: Adding an Azure Multi-Factor Auth Provider is used to take advantage of features provided by the full version of Azure MFA. It is for users who do not have licenses through Azure MFA, Azure AD Premium, or EMS. Azure MFA, Azure AD Premium, and EMS include the full version of Azure MFA by default. If you have licenses then you do not need an Azure Multi-Factor Auth Provider.

1. From the Azure management portal, click ACTIVE DIRECTORY on the left pane.
2. Under DIRECTORY, click the directory tenant for the user you want to create, for example Fabrikam Corporation as illustrated here.
3. At the top, click USERS.
4. In the tray at the bottom, click MANAGE MULTI-FACTOR AUTH. A new tab opens up with the multi-factor authentication page.

This page allows you to enable and disable Multi-Factor Authentication for users in your directory tenant. This also allows you to force users to provide their contact methods again, and reset application password.

1. Change the view at the top to find the user(s) that you wish to enable for multi-factor authentication. From the View drop down select Sign-in allowed users.
   
2. Check the box next to the users to enable for MFA, for example "Janet Schorr JanetS@corpfabrikam.onmicrosoft.com" as illustrated here.
   
3. Click Enable on the right. This opens up a pop-up that specifies the next steps you need to take with your users.
   
4. Review the content, and then click enable multi-factor auth.
5. Click close.
   

Note:    As previously noticed, non-browser apps do not have built-in support for interactive prompts that are required by Multi-Factor Authentication. More specifically, in the context of Office 365, this applies to clients such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, SkyDrive Pro, Exchange ActiveSync (EAS), POP, and IMAP clients, etc. unless the Office 2013/2016 is already using modern authentication.

When you enable Multi-Factor Authentication for such an Office 365 user account, they will be able to use non-browser apps, such as Outlook, Lync, etc., until they have completed multi-factor enrollment or their account status is set to Enforced. In order to continue to use non-browser apps, they must create app passwords for these apps. An app password, is a password that allows them to by-pass the Multi-Factor Authentication and continue to use their non-browser apps. It is advised that you send them an email that informs them how they can use their non-browser apps and consequently not be locked out.

1. At the top of the multi-factor authentication page, click service settings.
   
2. Ensure that the radio button next to Allow users to create app passwords to sign into non-browser applications is selected.
3. Close the multi-factor authentication page.

Using Multi-Factor Authentication with Azure AD

1. Open an InPrivate browsing session and navigate to http://aka.ms/MFASetup. You will now be redirected to the login page.
   
2. Click Use another account and sign-in with your user's organizational account, for example as JanetS@corpfabrikam.onmicrosoft.com in our illustration. Because Multi-Factor Authentication has been enabled for this user, you are asked to configure it. This step is required the first time after Multi-Factor Authentication has been enabled for a user.
   
3. Click Set it up now.
   
4. From the Step 1: Specify the contact method we should use by default page, ensure Mobile phone is selected in the first drop-down.
5. In the second drop down for the country or the region, select your country.
6. Enter your mobile phone number in the textbox next to the country drop down.
7. Under Mode, select Call me. Alternatively, you can select Send me a code by text message. The steps will be slightly different.
8. Click next.

   

9. From the Step 2: Let's make sure that we can reach you on your Mobile Phone page, click verify now.
10. When you receive the call, answer, press # and hang-up. When Multi-Factor Authentication is provided through a phone call, the user will always press # to proceed with the authentication.

    

11. Click next.

    

12. From the Step 3: Apps like Microsoft Office will need new passwords for this account page, click I don't use this account with these apps.

1. At the login screen, your organizational account is already entered, for example JanetS@corpfabrikam.onmicrosoft.com as illustrated here.
2. Enter the password, click Sign In.

   

3. When your phone rings, answer, press # and hang up.

Note:    While your preferred authentication method is the default, you can also choose to authenticate using any of the other authentication methods you have configured by selecting the Other authentication methods link.

Configuring the Multi-Factor Authentication mobile application

1. From the application store on your phone, find and install the app Multi-Factor Authentication. As previously mentioned, this app is available for Windows Phone, iOS, and Android.
2. Once the Multi-Factor Authentication mobile app has been downloaded and is installed, you can activate it for multiple accounts.
3. Open an InPrivate browsing session and navigate to the Access Panel at https://account.activedirectory.windowsazure.com/profile.
4. Sign-in with your organizational account, for example "ztestuser5@corpfabrikam.onmicrosoft.com" as illustrated here.

   

5. Click ADDITIONAL SECURITY VERIFICATION.

   

6. Check the box to enable Multi-Factor Authentication app.
   
7. Click configure.

   

8. Switch to your mobile device
9. Open the Multi-Factor Authentication application.
10. In the mobile app, click New (+).

Note: The interface will differ slightly between mobile OS apps.

1. Either scan the barcode, or enter the information manually. Upon scanning the barcode or entering the information, you should then see a 6-digit authentication code for the directory.
2. Switch back to the Access Panel.
3. Click done.
4. Notice the checking activation status message. Wait for this to read "Mobile app has been configured" before continuing.
   

Note: You have now activated your mobile application for Multi-Factor Authentication.

1. Under what's your preferred option? from the drop down, select Notify me through app.
2. Click save.
   

Note: In order to use a new Multi-Factor Authentication process, you must first verify the process is working.

1. Click verify preferred option.
2. Switch to your mobile device. When prompted, click verify.
   
3. Click close.
4. Close your browsing session.

1. Open an InPrivate browsing session and navigate to the Access Panel at https://account.activedirectory.windowsazure.com/profile.
2. Sign-in with your organizational account, for example "JanetS@corpfabrikam.onmicrosoft.com" as illustrated here.
   
3. When the Multi-Factor Authentication mobile app notifies you of the authentication attempt, click Verify from the mobile app.
4. The sign in completes. Close the browsing session.

Managing the user settings

1. Open an InPrivate browsing session and navigate to the Azure management portal at https://manage.windowsazure.com.
2. Sign-in with your administrative credentials. To sign-in with your organizational account, select Sign in with your organizational account and logon and enter your credentials (username and password).
3. On the left pane, click ACTIVE DIRECTORY.
4. Under DIRECTORY, click the directory tenant for the user(s) you want to manage.
5. At the top, click USERS.
6. In the tray at the bottom, click MANAGE MULTI-FACTOR AUTH. A new tab opens up with the multi-factor authentication page.
7. Find the user that you wish to manage and place a check in the box located next to the name. As before, you may need to change the view at the top.
   This will bring up two options on the right: Enable and Manage user settings.

1. Click Manage User settings. This brings up an eponym pop-up that allows you to select the following user settings in the event a machine or device is lost or stolen:
   

• Require selected users to provide contact methods again. This setting forces the user to complete the enrollment process again when they sign-in. Non-browser apps (such as Outlook, Lync, etc.) will continue to work if they have app passwords associated with them unless the setting below is also selected.
• Delete all existing app passwords generated by the selected users. This setting deletes all of the app passwords that were created by the selected Office 365 users. Non-browser apps (such as Outlook, Lync, etc.) that were associated with these app passwords will cease to work until a new app password is created.

1. Place a check in the desired boxes and click save.
2. Close the browsing session

1. Open a browser session and navigate to https://account.activedirectory.windowsazure.com/proofup.aspx.
2. Sign-in with your organizational account, for example "JanetS@corpfabrikam.onmicrosoft.com" as illustrated here. This will take you directly to the additional security verification page.

Note:    You will only be able to edit your office phone number using this page if you are a global or user admin and your account is not being synchronized with the Azure AD directory tenant.

App Password for Non-browser based apps.

• App passwords are 16-character randomly generated passwords that, once generated, allow users who are enabled for Multi-Factor Authentication to sign-in with non-browser apps like Outlook, Lync, etc. that are not yet modern authentication enabled.
• App passwords are used in place of the regular user account password.
• App passwords are system-generated, and cannot be manually entered by end-users. They will only be displayed once, upon creation.
• App passwords do not automatically expire, but can be revoked anytime by end-users or an administrator.
• A user can create up to 40 app passwords and can tag them with names indicating their use.

1. From the additional security verification page, click app passwords at the top.
   
2. Click create. A Create app password dialog brings up.
   
3. In Name, enter a name for the app password, for example "Office 365 ProPlus for my laptop" as illustrated here, and then click next.
   
4. Click copy password to clipboard to copy the generated password, and then click close.
   You should see your app password on the app passwords page.
5. Now, paste the app password that was copied to the clipboard into the non-browser app, such as Outlook to login.

Reference:

• https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication/
• https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-cloud/
• https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-auth-provider/

  <#----------------------------------------------------------------------

 |   Modify the Azure AD Relying Party to include the claims needed

 |   for DomainJoin++. The rules include:

 |   -ObjectGuid

 |   -AccountType

 |   -ObjectSid

 +---------------------------------------------------------------------#>

$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules

$rule1 = '@RuleName = "Issue object GUID"

      c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

      c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

      => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), query = ";objectguid;{0}", param = c2.Value);'

$rule2 = '@RuleName = "Issue account type for domain joined computers"

      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

      => issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Value = "DJ");'

$rule3 = '@RuleName = "Pass through primary SID"

      c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

      c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

      => issue(claim = c2);'

$updatedRules = $existingRules + $rule1 + $rule2 + $rule3

$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules

Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString