mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 03:43:39 +00:00
Merge pull request #2455 from MicrosoftDocs/repo_sync_working_branch
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
Tina Burden
GitHub
@ -154,6 +154,9 @@ These procedures configure NTFS and share permissions on the web server to allow
|
||||
|
||||
9. In the **Advanced Sharing** dialog box, click **OK**.
|
||||
|
||||
> [!Tip]
|
||||
> Make sure that users can access **\\\Server FQDN\sharename**.
|
||||
|
||||
#### Disable Caching
|
||||
1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server).
|
||||
2. Right-click the **cdp** folder and click **Properties**. Click the **Sharing** tab. Click **Advanced Sharing**.
|
||||
@ -325,6 +328,9 @@ Sign-in a workstation with access equivalent to a _domain user_.
|
||||
14. Click **Save**
|
||||
15. Sign-out of the Azure portal.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> For more details about the actual experience after everything has been configured, please see [Windows Hello for Business and Authentication](https://docs.microsoft.com/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication).
|
||||
|
||||
## Section Review
|
||||
> [!div class="checklist"]
|
||||
> * Configure Internet Information Services to host CRL distribution point
|
||||
|
||||
@ -122,11 +122,9 @@ Review the [What is Azure Multi-Factor Authentication](https://docs.microsoft.co
|
||||
>
|
||||
> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section.
|
||||
|
||||
#### Azure MFA Provider
|
||||
If your organization uses Azure MFA on a per-consumption model (no licenses), then review the [Create a Multifactor Authentication Provider](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider) section to create an Azure MFA Authentication provider and associate it with your Azure tenant.
|
||||
|
||||
#### Configure Azure MFA Settings
|
||||
Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you need to configure the multi-factor authentication settings. Review the [Configure Azure Multi-Factor Authentication settings](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings.
|
||||
Review the [Configure Azure Multi-Factor Authentication settings](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings.
|
||||
|
||||
#### Azure MFA User States
|
||||
After you have completed configuring your Azure MFA settings, you want to review [How to require two-step verification for a user](https://docs.microsoft.com/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states. User states determine how you enable Azure MFA for your users.
|
||||
|
||||
@ -102,8 +102,8 @@ Organizations using older directory synchronization technology, such as DirSync
|
||||
<br>
|
||||
|
||||
|
||||
## Federation with Azure ##
|
||||
You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated environments, key trust deployments work in environments that have deployed [Password Synchronization with Azure AD Connect](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnectsync-implement-password-synchronization) or [Azure Active Directory Pass-through-Authentication](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication). For federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later.
|
||||
## Federation with Azure
|
||||
You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated environments, key trust deployments work in environments that have deployed [Password Synchronization with Azure AD Connect](https://docs.microsoft.com/azure/active-directory/hybrid/whatis-phs) or [Azure Active Directory Pass-through-Authentication](https://docs.microsoft.com/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication). For federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later.
|
||||
|
||||
> [!div class="checklist"]
|
||||
> * Non-federated environments
|
||||
|
||||
@ -53,7 +53,7 @@ This table provides info about the most common problems you might encounter whil
|
||||
</tr>
|
||||
<tr>
|
||||
<td>WIP is designed for use by a single user per device.</td>
|
||||
<td>A secondary user on a device might experience app compat issues when unenlightened apps start to automatically encrypt for all users. Additionally, only the initial, enrolled user’s content can be revoked during the unenrollment process.</td>
|
||||
<td>A secondary user on a device might experience app compatibility issues when unenlightened apps start to automatically encrypt for all users. Additionally, only the initial, enrolled user’s content can be revoked during the unenrollment process.</td>
|
||||
<td>We recommend only having one user per managed device.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
@ -121,17 +121,25 @@ This table provides info about the most common problems you might encounter whil
|
||||
<tr>
|
||||
<td>Only enlightened apps can be managed without device enrollment
|
||||
</td>
|
||||
<td>If a user enrolls a device for Mobile Application Management (MAM) without device enrollment, only enlightened apps will be managed. This is by design to prevent personal files from being unintenionally encrypted by unenlighted apps. Unenlighted apps that need to access work using MAM need to be re-compiled as LOB apps or managed by using MDM with device enrollment.</td>
|
||||
<td>If a user enrolls a device for Mobile Application Management (MAM) without device enrollment, only enlightened apps will be managed. This is by design to prevent personal files from being unintentionally encrypted by unenlighted apps. Unenlighted apps that need to access work using MAM need to be re-compiled as LOB apps or managed by using MDM with device enrollment.</td>
|
||||
<td>If all apps need to be managed, enroll the device for MDM.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>By design, files in the Windows directory (%windir% or C:/Windows) cannot be encrypted because they need to be accessed by any user. If a file in the Windows directory gets encypted by one user, other users can't access it.<br/> </td>
|
||||
<td>By design, files in the Windows directory (%windir% or C:/Windows) cannot be encrypted because they need to be accessed by any user. If a file in the Windows directory gets encrypted by one user, other users can't access it.<br/> </td>
|
||||
<td>Any attempt to encrypt a file in the Windows directory will return a file access denied error. But if you copy or drag and drop an encrypted file to the Windows directory, it will retain encryption to honor the intent of the owner.
|
||||
</td>
|
||||
<td>If you need to save an encrypted file in the Windows directory, create and encrypt the file in a different directory and copy it.
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Microsoft Office Outlook offline data files (PST and OST files) are not marked as <strong>Work</strong> files, and are therefore not protected.
|
||||
</td>
|
||||
<td>If Microsoft Office Outlook is set to work in cached mode (default setting), or if some emails are stored in a local PST file, the data is unprotected.
|
||||
</td>
|
||||
<td>It is recommended to use Microsoft Office Outlook in Online mode, or to use encryption to protect OST and PST files manually.
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
> [!NOTE]
|
||||
|
||||
@ -28,6 +28,9 @@ Describes the best practices, location, values, management, and security conside
|
||||
|
||||
Beginning with Windows Server 2012 and Windows 8, Windows detects user-input inactivity of a sign-in (logon) session by using the security policy setting **Interactive logon: Machine inactivity limit**. If the amount of inactive time exceeds the inactivity limit set by this policy, then the user’s session locks by invoking the screen saver (screen saver should be active on the destination machine). You can activate the screen saver by enabling the Group Policy **User Configuration\Administrative Templates\Control Panel\Personalization\Enable screen saver**. This policy setting allows you to control the locking time by using Group Policy.
|
||||
|
||||
> [!NOTE]
|
||||
> If the **Interactive logon: Machine inactivity limit** security policy setting is configured, the device locks not only when inactive time exceeds the inactivity limit, but also when the screensaver activates or when the display turns off because of power settings.
|
||||
|
||||
### Possible values
|
||||
|
||||
The automatic lock of the device is set in elapsed seconds of inactivity, which can range from zero (0) to 599,940 seconds (166.65 hours).
|
||||
|
||||
Reference in New Issue
Block a user