Merge branch 'master' into App-v-revision

mdop/mbam-v25/mbam-25-supported-configurations.md

@@ -464,6 +464,12 @@ The following table lists the operating systems that are supported for MBAM Clie
 </tr>
 </thead>
 <tbody>
+<tr class="even">
+    <td align="left"><p>Windows 10 IoT</p></td>
+    <td align="left"><p>Enterprise</p></td>
+    <td align="left"><p></p></td>
+    <td align="left"><p>32-bit or 64-bit</p></td>
+</tr>  
 <tr class="odd">
 <td align="left"><p>Windows 10</p></td>
 <td align="left"><p>Enterprise</p></td>
@@ -518,6 +524,12 @@ The following table lists the operating systems that are supported for MBAM Grou
 </tr>
 </thead>
 <tbody>
+ <tr class="even">
+      <td align="left"><p>Windows 10 IoT</p></td>
+      <td align="left"><p>Enterprise</p></td>
+      <td align="left"><p></p></td>
+      <td align="left"><p>32-bit or 64-bit</p></td>
+ </tr>
 <tr class="odd">
 <td align="left"><p>Windows 10</p></td>
 <td align="left"><p>Enterprise</p></td>

mdop/mbam-v25/release-notes-for-mbam-25-sp1.md

@@ -139,8 +139,10 @@ Digging this further with Fiddler – it does look like once we click on Reports
     <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
 
 Original setting is: 
+
     <meta http-equiv="X-UA-Compatible" content="IE=8" />
 
+
 This is the reason why the issue was not seen with other browsers like Chrome, Firefox etc.
 
 

windows/deployment/update/update-compliance-get-started.md

@@ -27,6 +27,9 @@ Steps are provided in sections that follow the recommended setup process:
 
 Update Compliance is offered as a solution in the Microsoft Operations Management Suite (OMS), a collection of cloud-based servicing for monitoring and automating your on-premise and cloud environments. For more information about OMS, see [Operations Management Suite overview](https://azure.microsoft.com/en-us/documentation/articles/operations-management-suite-overview/) or the Azure [Log Analytics overview](https://azure.microsoft.com/services/log-analytics/).
 
+>[!IMPORTANT]
+>Update Compliance is a free solution for Azure subscribers.
+
 If you are already using OMS, skip to step **6** to add Update Compliance to your workspace.
 
 >[!NOTE]

windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md

@@ -31,6 +31,7 @@ Some ways to store credentials are not protected by Windows Defender Credential
 -   Digest and CredSSP credentials
     -   When Windows Defender Credential Guard is enabled, neither Digest nor CredSSP have access to users' logon credentials. This implies no Single Sign-On use for these protocols.
 -   Supplied credentials for NTLM authentication are not protected. If a user is prompted for and enters credentials for NTLM authentication, these credentials are vulnerable to be read from LSASS memory. Note that these same credentials are vulnerable to key loggers as well.- 
+-  Kerberos service tickets are not protected by Credential Guard, but the Kerberos Ticket Granting Ticket (TGT) is.
 -  When Windows Defender Credential Guard is deployed on a VM, Windows Defender Credential Guard protects secrets from attacks inside the VM. However, it does not provide additional protection from privileged system attacks originating from the host.
 -  Windows logon cached password verifiers (commonly called "cached credentials")
 do not qualify as credentials because they cannot be presented to another computer for authentication, and can only be used locally to verify credentials. They are stored in the registry on the local computer and provide validation for credentials when a domain-joined computer cannot connect to AD DS during user logon. These “cached logons”, or more specifically, cached domain account information, can be managed using the security policy setting **Interactive logon: Number of previous logons to cache** if a domain controller is not available.

windows/security/information-protection/windows-information-protection/create-wip-policy-using-intune.md

@@ -193,9 +193,9 @@ In this example, you'd get the following info:
 Where the text, `O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US` is the publisher name to enter in the **Publisher Name** box.
 
 ### Add an AppLocker policy file
-For this example, we’re going to add an AppLocker XML file to the **App Rules** list. You’ll use this option if you want to add multiple apps at the same time. For more info about AppLocker, see the [AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/applocker-overview) content.
+Now we’re going to add an AppLocker XML file to the **App Rules** list. You’ll use this option if you want to add multiple apps at the same time. The first example shows how to create a Publisher rule for packaged apps. The second example shows how to create a Path rule for unsigned apps. For more info, see [AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/applocker-overview).
 
-**To create an app rule and xml file using the AppLocker tool**
+**To create a Publisher rule and xml file for packaged apps using the AppLocker tool**
 1.	Open the Local Security Policy snap-in (SecPol.msc).
     
 2.	In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then click **Packaged App Rules**.
@@ -262,6 +262,43 @@ For this example, we’re going to add an AppLocker XML file to the **App Rules*
     ```
 12.	After you’ve created your XML file, you need to import it by using Microsoft Intune.
 
+**To create a Path rule and xml file for unsigned apps using the AppLocker tool**
+1. Open the Local Security Policy snap-in (SecPol.msc).
+    
+2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then click **Executable Rules**.
+
+   ![Local security snap-in, showing the Executable Rules](images/create-new-path-rule.png)
+
+3. Right-click in the right-hand pane, and then click **Create New Rule**.
+
+4. On the **Before You Begin** page, click **Next**.
+
+5. On the **Permissions** page, make sure the **Action** is set to **Allow** and the **User or group** is set to **Everyone**, and then click **Next**.
+
+6. On the **Conditions** page, click **Path** and then click **Next**.
+
+    ![Create Packaged app Rules wizard, showing the Publisher](images/path-condition.png)
+
+7. Click **Browse Folders...** and select the path for the unsigned apps. For this example, we’re using "C:\Program Files".
+
+    ![Create Packaged app Rules wizard, showing the Select applications page](images/select-path.png)
+
+8. On the **Exceptions** page, add any exceptions and then click **Next**.
+
+9. On the **Name** page, type a name and description for the rule and then click **Create**.
+
+10.	In the left pane, right-click on **AppLocker**, and then click **Export policy**.
+
+    The **Export policy** box opens, letting you export and save your new policy as XML.
+
+    ![Local security snap-in, showing the Export Policy option](images/intune-local-security-export.png)
+
+11.	In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then click **Save**.
+
+    The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
+
+12.	After you’ve created your XML file, you need to import it by using Microsoft Intune.
+
 **To import your Applocker policy file app rule using Microsoft Intune**
 1.	From the **App Rules** area, click **Add**.