mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-16 15:27:22 +00:00
Merged PR 13985: 1/25 AM Publish
This commit is contained in:
commit
47366b673d
@ -11,13 +11,13 @@ ms.date: 10/04/2017
|
||||
|
||||
# Enroll a Windows 10 device automatically using Group Policy
|
||||
|
||||
Starting in Windows 10, version 1709 you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain joined devices.
|
||||
Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices.
|
||||
|
||||
Requirements:
|
||||
- AD-joined PC running Windows 10, version 1709
|
||||
- Enterprise has MDM service already configured
|
||||
- Enterprise AD must be registered with Azure AD
|
||||
- Device should not already be enrolled in Intune using the classic agents (devices manged using agents will fail enrollment with error 0x80180026)
|
||||
- AD-joined PC running Windows 10, version 1709 or later
|
||||
- The enterprise has configured a mobile device management (MDM) service
|
||||
- The enterprise AD must be [registered with Azure Active Directory (Azure AD)](azure-active-directory-integration-with-mdm.md)
|
||||
- The device should not already be enrolled in Intune using the classic agents (devices managed using agents will fail enrollment with `error 0x80180026`)
|
||||
|
||||
> [!Tip]
|
||||
> [How to configure automatic registration of Windows domain-joined devices with Azure Active Directory](https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup)
|
||||
|
@ -6,7 +6,7 @@ ms.topic: article
|
||||
ms.prod: w10
|
||||
ms.technology: windows
|
||||
author: MariciaAlforque
|
||||
ms.date: 11/14/2018
|
||||
ms.date: 01/26/2019
|
||||
---
|
||||
|
||||
# Policy CSP - Defender
|
||||
@ -1156,6 +1156,7 @@ Valid values: 0–100
|
||||
<hr/>
|
||||
|
||||
<!--/Scope-->
|
||||
|
||||
<!--Description-->
|
||||
This policy setting allows you to manage whether a check for new virus and spyware definitions will occur before running a scan.
|
||||
|
||||
@ -1170,6 +1171,8 @@ Supported values:
|
||||
- 0 (default) - Disabled
|
||||
- 1 - Enabled
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/CheckForSignaturesBeforeRunningScan
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
@ -1547,6 +1550,8 @@ Supported values:
|
||||
- 0 - Disabled
|
||||
- 1 - Enabled (default)
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/DisableCatchupFullScan
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
@ -1606,9 +1611,9 @@ ADMX Info:
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
This policy setting allows you to configure catch-up scans for scheduled quick scans. A catch-up scan is a scan that is initiated because a regularly scheduled scan was missed. Usually these scheduled scans are missed because the computer was turned off at the scheduled time.
|
||||
This policy setting allows you to configure catch-up scans for scheduled quick scans. A catch-up scan is a scan that is initiated because a regularly scheduled scan was missed. Usually these scheduled scans are missed because the computer was turned off at the scheduled time.
|
||||
|
||||
If you enable this setting, catch-up scans for scheduled quick scans will be turned on. If a computer is offline for two consecutive scheduled scans, a catch-up scan is started the next time someone logs on to the computer. If there is no scheduled scan configured, there will be no catch-up scan run.
|
||||
If you enable this setting, catch-up scans for scheduled quick scans will be turned on. If a computer is offline for two consecutive scheduled scans, a catch-up scan is started the next time someone logs on to the computer. If there is no scheduled scan configured, there will be no catch-up scan run.
|
||||
|
||||
If you disable or do not configure this setting, catch-up scans for scheduled quick scans will be turned off.
|
||||
|
||||
@ -1617,6 +1622,8 @@ Supported values:
|
||||
- 0 - Disabled
|
||||
- 1 - Enabled (default)
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/DisableCatchupQuickScan
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
@ -2457,12 +2464,14 @@ Possible values are:
|
||||
- MMPC
|
||||
- FileShares
|
||||
|
||||
For example: { InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC }
|
||||
For example: InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC
|
||||
|
||||
If you enable this setting, definition update sources will be contacted in the order specified. Once definition updates have been successfully downloaded from one specified source, the remaining sources in the list will not be contacted.
|
||||
|
||||
If you disable or do not configure this setting, definition update sources will be contacted in a default order.
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/SignatureUpdateFallbackOrder
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
@ -2522,12 +2531,18 @@ ADMX Info:
|
||||
|
||||
<!--/Scope-->
|
||||
<!--Description-->
|
||||
This policy setting allows you to configure UNC file share sources for downloading definition updates. Sources will be contacted in the order specified. The value of this setting should be entered as a pipe-separated string enumerating the definition update sources. For example: "{\\unc1 | \\unc2 }". The list is empty by default.
|
||||
This policy setting allows you to configure UNC file share sources for downloading definition updates. Sources will be contacted in the order specified. The value of this setting should be entered as a pipe-separated string enumerating the definition update sources.
|
||||
|
||||
For example: \\unc1\Signatures | \\unc2\Signatures
|
||||
|
||||
The list is empty by default.
|
||||
|
||||
If you enable this setting, the specified sources will be contacted for definition updates. Once definition updates have been successfully downloaded from one specified source, the remaining sources in the list will not be contacted.
|
||||
|
||||
If you disable or do not configure this setting, the list will remain empty by default and no sources will be contacted.
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/SignatureUpdateFileSharesSources
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
@ -2598,6 +2613,8 @@ A value of 0 means no check for new signatures, a value of 1 means to check ever
|
||||
|
||||
The default value is 8.
|
||||
|
||||
OMA-URI Path: ./Vendor/MSFT/Policy/Config/Defender/SignatureUpdateInterval
|
||||
|
||||
<!--/Description-->
|
||||
<!--ADMXMapped-->
|
||||
ADMX Info:
|
||||
|
@ -77,8 +77,8 @@ Device Registration is a prerequisite to Windows Hello for Business provisioning
|
||||
| Phase | Description |
|
||||
| :----: | :----------- |
|
||||
| A | The user signs in to a domain joined Windows 10 computers using domain credentials. This can be user name and password or smart card authentication. The user sign-in triggers the Automatic Device Join task.|
|
||||
|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines directs device registration to Azure Device Registration Service (ADRS).|
|
||||
|C | For the federated environments, the computer authenticates ADFS/STS using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task.
|
||||
|B | The task queries Active Directory using the LDAP protocol for the keywords attribute on service connection point stored in the configuration partition in Active Directory (CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com). The value returned in the keywords attribute determines if device registration is directed to Azure Device Registration Service (ADRS) or the enterprise device registration service hosted on-premises.|
|
||||
|C | For the federated environments, the computer authenticates the enterprise device registration endpoint using Windows integrated authentication. The enterprise device registration service creates and returns a token that includes claims for the object GUID, computer SID, and domain joined state. The task submits the token and claims to Azure Active Directory where it is validated. Azure Active Directory returns an ID token to the running task.
|
||||
|D | The application creates TPM bound (preferred) RSA 2048 bit key-pair known as the device key (dkpub/dkpriv). The application create a certificate request using dkpub and the public key and signs the certificate request with using dkpriv. Next, the application derives second key pair from the TPM's storage root key. This is the transport key (tkpub/tkpriv).|
|
||||
|E | To provide SSO for on-premises federated application, the task requests an enterprise PRT from the on-premises STS. Windows Server 2016 running the Active Directory Federation Services role validate the request and return it the running task.|
|
||||
|F | The task sends a device registration request to Azure DRS that includes the ID token, certificate request, tkpub, and attestation data. Azure DRS validates the ID token, creates a device ID, and creates a certificate based on the included certificate request. Azure DRS then writes a device object in Azure Active Directory and sends the device ID and the device certificate to the client. Device registration completes by receiving the device ID and the device certificate from Azure DRS. The device ID is saved for future reference (viewable from dsregcmd.exe /status), and the device certificate is installed in the Personal store of the computer. With device registration complete, the task exits.|
|
||||
|
@ -23,7 +23,7 @@ Hybrid environments are distributed systems that enable organizations to use on-
|
||||
|
||||
The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure. High-level pieces of the infrastructure include:
|
||||
* [Directories](#directories)
|
||||
* [Public Key Infrastructure](#public-key-infrastructure)
|
||||
* [Public Key Infrastucture](#public-key-infastructure)
|
||||
* [Directory Synchronization](#directory-synchronization)
|
||||
* [Federation](#federation)
|
||||
* [MultiFactor Authentication](#multifactor-authentication)
|
||||
@ -114,9 +114,9 @@ Organizations wanting to deploy hybrid key trust need their domain joined device
|
||||
<br>
|
||||
|
||||
### Next Steps ###
|
||||
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Baseline**.
|
||||
Follow the Windows Hello for Business hybrid key trust deployment guide. For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.
|
||||
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Synchronization**.
|
||||
For environments transitioning from on-premises to hybrid, start with **Configure Azure Directory Syncrhonization**.
|
||||
|
||||
For federated and non-federated environments, start with **Configure Windows Hello for Business settings**.
|
||||
|
||||
|
@ -39,7 +39,7 @@ Windows Hello addresses the following problems with passwords:
|
||||
* Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
|
||||
|
||||
### Hybrid Deployments
|
||||
The table shows the minimum requirements for each deployment.
|
||||
The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process.
|
||||
|
||||
| Key trust</br>Group Policy managed | Certificate trust</br>Mixed managed | Key trust</br>Modern managed | Certificate trust</br>Modern managed |
|
||||
| --- | --- | --- | --- |
|
||||
|
@ -11,7 +11,6 @@ ms.pagetype: security
|
||||
ms.author: macapara
|
||||
author: mjcaparas
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 11/09/2018
|
||||
---
|
||||
|
||||
# Use basic permissions to access the portal
|
||||
@ -66,23 +65,8 @@ Add-MsolRoleMember -RoleName "Security Reader" -RoleMemberEmailAddress "reader@C
|
||||
For more information see, [Manage Azure AD group and role membership](https://technet.microsoft.com/library/321d532e-407d-4e29-a00a-8afbe23008dd#BKMK_ManageGroups).
|
||||
|
||||
## Assign user access using the Azure portal
|
||||
For more information, see [Assign administrator and non-administrator roles to uses with Azure Active Directory](https://docs.microsoft.com/azure/active-directory/fundamentals/active-directory-users-assign-role-azure-portal).
|
||||
|
||||
1. Go to the [Azure portal](https://portal.azure.com).
|
||||
|
||||
2. Select **Azure Active Directory**.
|
||||
|
||||
3. Select **Manage** > **Users and groups**.
|
||||
|
||||
4. Select **Manage** > **All users**.
|
||||
|
||||
5. Search or select the user you want to assign the role to.
|
||||
|
||||
6. Select **Manage** > **Directory role**.
|
||||
|
||||
7. Select **Add role** and choose the role you'd like to assign, then click **Select**.
|
||||
|
||||
|
||||

|
||||
|
||||
## Related topic
|
||||
- [Manage portal access using RBAC](rbac-windows-defender-advanced-threat-protection.md)
|
||||
|
@ -11,7 +11,6 @@ ms.pagetype: security
|
||||
ms.author: macapara
|
||||
author: mjcaparas
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 09/13/2018
|
||||
---
|
||||
|
||||
# Create and manage machine tags
|
||||
@ -79,4 +78,9 @@ You can manage tags from the Actions button or by selecting a machine from the M
|
||||
|
||||

|
||||
|
||||
## Add machine tags using APIs
|
||||
For more information, see [Add or remove machine tags API](add-or-remove-machine-tags-windows-defender-advanced-threat-protection-new.md).
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -11,7 +11,6 @@ ms.pagetype: security
|
||||
ms.author: macapara
|
||||
author: mjcaparas
|
||||
ms.localizationpriority: medium
|
||||
ms.date: 11/19/2018
|
||||
---
|
||||
|
||||
# Onboard previous versions of Windows
|
||||
@ -30,6 +29,9 @@ ms.date: 11/19/2018
|
||||
|
||||
Windows Defender ATP extends support to include down-level operating systems, providing advanced attack detection and investigation capabilities on supported Windows versions.
|
||||
|
||||
>[!IMPORTANT]
|
||||
>This capability is currently in preview. You'll need to turn on the preview features to take advantage of this feature. For more information, see [Preview features](preview-windows-defender-advanced-threat-protection).
|
||||
|
||||
To onboard down-level Windows client endpoints to Windows Defender ATP, you'll need to:
|
||||
- Configure and update System Center Endpoint Protection clients.
|
||||
- Install and configure Microsoft Monitoring Agent (MMA) to report sensor data to Windows Defender ATP as instructed below.
|
||||
|
Loading…
x
Reference in New Issue
Block a user