| Category | Microsoft Docs article | Related commit history on GitHub | Change details |
|---|---|---|---|
| admin | Office 365 Groups | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/admin/create-groups/office-365-groups.md | The following limits apply to Microsoft 365 Groups: |Owners per group|100| |Groups a user can create|250| |Groups an admin can create|There are no Microsoft 365 group specific limits. There's an overall Azure AD object limit specific to each organization. An Azure AD admin who can manage groups in the organization can create an unlimited number of Microsoft 365 groups up to the Azure AD object limit. See [AAD service limits and restrictions](/azure/active-directory/enterprise-users/directory-service-limits-restrictions).|-|Number of members|More than 1,000, though only 1,000 can access the Group conversations concurrently. <br>Users might notice delays when accessing the calendar and conversations in large groups in Outlook.| -|Number of Groups a user can be a member of|7,000| +|Number of members|More than 1,000, though only 1,000 can access the group conversations concurrently. <br>Users might notice delays when accessing the calendar and conversations in large groups in Outlook.| +|Number of groups a user can be an owner of|7,000| +|Number of groups a user can be a member of|7,000| |File storage|1 Terabyte + 10 GB per subscribed user + any other storage purchased. You can purchase an unlimited amount of extra storage.| |Group Mailbox size|50 GB| |
| business-premium | M365bp Setup | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/business-premium/m365bp-setup.md | Make sure that you meet the following requirements before you begin your setup p ## Guided setup process -Microsoft 365 Business Premium includes a guided process. The following video shows the guided setup process for Microsoft 365 Business Standard, which also applies to Microsoft 365 Business Premium. <br/><br/> +Microsoft 365 Business Premium includes a guided process. The following video shows the guided setup process for Microsoft 365 Business Standard, which also applies to Microsoft 365 Business Premium. (Microsoft 365 Business Premium includes [advanced security settings that you'll configure](m365bp-security-overview.md) after your basic setup process is complete.)<br/><br/> > [!VIDEO https://www.microsoft.com/videoplayer/embed/RE471FJ] -As soon as you've completed the guided setup process, make sure to proceed to [bump up security](m365bp-security-overview.md). +**As soon as you've completed the guided setup process, proceed to [bump up security](m365bp-security-overview.md)**. > [!TIP] > After you have added users, give them a link to the [Employee quick setup guide](../admin/setup/employee-quick-setup.md). The guide walks them through signing in, getting Microsoft 365 apps, and saving, copying, and sharing files. +### The guided setup process, step by step ++1. As a global administrator, go to the [Microsoft 365 admin center](https://admin.microsoft.com/) and sign in. By default, you'll see the simplified view, as shown in the following image: ++ :::image type="content" source="media/m365bp-simplifiedview.png" alt-text="Screenshot showing the simplified view of the Microsoft 365 admin center."lightbox="media/m365bp-simplifiedview.png"::: ++2. In the upper right corner, select **Dashboard view** so that your admin center resembles the following image. Then select **Go to guided setup**. ++ :::image type="content" source="media/m365bp-dashboardview.png" alt-text="Screenshot of the dashboard view of the Microsoft 365 admin center."lightbox="media/m365bp-dashboardview.png"::: ++3. To install your Microsoft 365 apps (Office), select the download button, and then follow the prompts. Alternately, you can skip this step for now and install your apps later. Then select **Continue**. ++ :::image type="content" source="media/m365bp-installoffice.png" alt-text="Screenshot of the Install Office download button."lightbox="media/m365bp-installoffice.png"::: ++4. To add your organization's domain (*recommended*) or to use your default `.onmicrosoft.com` domain, select an option and then follow the prompts. Then select **Use this domain**. ++ :::image type="content" source="media/m365bp-adddomain.png" alt-text="Screenshot showing the option to add a domain."lightbox="media/m365bp-adddomain.png"::: ++ > [!TIP] + > To get help with this task, see [Add a domain to Microsoft 365](../admin/setup/add-domain.md). ++5. To add a user, fill in the user's first name, last name, and user name, and then select **Add users and assign licenses**. Alternately, you can select **View all users** to go to your active users page, where you can view, add, and manage users. ++ :::image type="content" source="media/m365bp-addusers.png" alt-text="Screenshot showing the Add Users and Assign Licenses page."lightbox="media/m365bp-addusers.png"::: ++ > [!TIP] + > We recommend adding your administrators and members of your security team now. To get help with this task, see [Add users and assign licenses at the same time](../admin/add-users/add-users.md). ++6. If you added your domain in step 4, you can now connect your domain to Microsoft 365. To get help with this task, see [Change nameservers to set up Microsoft 365 with any domain registrar](../admin/get-help-with-domains/change-nameservers-at-any-domain-registrar.md). ++When you're finished with the basic setup process, you'll see **Setup is complete**, where you can tell us how setup went and then go to your Microsoft 365 admin center. At this point, basic setup is complete, but you still need to [set up and configure your security settings](m365bp-security-overview.md). + ## Work with a Microsoft partner -If you'd prefer to have a Microsoft partner help you get and set up Microsoft 365, follow these steps: +If you'd prefer to have a Microsoft partner help you get and set up Microsoft 365 Business Premium, follow these steps: 1. Go to the [Browse Partners](https://appsource.microsoft.com/marketplace/partner-dir) page. 2. In the **Filters** pane, specify search criteria, such as: - Your location- - Your organization's size + - Your organization's size (**Microsoft Customer Size**) - **Focus areas**, such as **Security** and/or **Threat Protection** - **Services**, such as **Licensing** or **Managed Services (MSP)** If you'd prefer to have a Microsoft partner help you get and set up Microsoft 36 ## See also +- [Overview of the Microsoft 365 admin center](../admin/admin-overview/admin-center-overview.md) +- [Business subscriptions and billing documentation](../commerce/index.yml) - [Find a Microsoft partner or reseller](../admin/manage/find-your-partner-or-reseller.md)-- [Set up self-service passwords](../admin/add-users/let-users-reset-passwords.md)-- [Set up self-service group management](/azure/active-directory/enterprise-users/groups-self-service-management) ## Next objective |
| compliance | Record Versioning | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/compliance/record-versioning.md | You can now do the following things: > [!NOTE] > If the label is configured to unlock the record by default, but versioning is not enabled by the admin, or prevented by the records management setting, users will not be able to unlock the document after they lock it. -- **Have the records automatically stored in an in-place records repository located with the site.** Each site in SharePoint and OneDrive preserves content in its Preservation Hold library. Record versions are stored in the Records folder in this library. For more information about how the Preservation Hold library works, see [How retention works for SharePoint and OneDrive](retention-policies-sharepoint.md#how-retention-works-for-sharepoint-and-onedrive).+- **Have the records automatically stored in an in-place records repository located with the site.** Each site in SharePoint and OneDrive preserves content in its Preservation Hold library. Record versions are stored in the Records folder in this library as individual files. For more information about how the Preservation Hold library works, see [How retention works for SharePoint and OneDrive](retention-policies-sharepoint.md#how-retention-works-for-sharepoint-and-onedrive). - **Maintain an evergreen document that contains all versions.** By default, each SharePoint and OneDrive document has a version history available on the item menu. In this version history, you can easily see which versions are records and view those documents. > [!TIP] > When you use record versioning with a retention label that has a delete action, consider configuring the retention setting **Start the retention period based on:** to be **When items were labeled**. With this label setting, the start of the retention period is reset for each new record version, which ensures that older versions will be deleted before newer versions. +If the retention label is configured for [disposition review](disposition.md) at the end of the retention period, each version undergoes its own disposition review. + By default, record versioning is automatically available for any document that has a retention label applied that marks the item as a record, and that label is [published to the site](create-apply-retention-labels.md). When a user views the document properties by using the details pane, they can toggle the **Record status** between **Locked** and **Unlocked**. While the document is unlocked, any user with standard edit permissions can edit the file. However, users can't delete the file, because it's still a record. When editing is complete, a user can then toggle the **Record status** from **Unlocked** to **Locked**, which prevents further edits while in this status. |
| compliance | Retention Policies Exchange | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/compliance/retention-policies-exchange.md | description: "Learn how Microsoft 365 retention works for Exchange, using retent >*[Microsoft 365 licensing guidance for security & compliance](/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance).* -The information in this article supplements [Learn about retention](retention.md) because it has information that's specific to Exchange. For other workloads, see: +The information in this article supplements [Learn about retention](retention.md) because it has information that's specific to Exchange. For other workloads, see: - [Learn about retention for SharePoint and OneDrive](retention-policies-sharepoint.md) - [Learn about retention for Microsoft Teams](retention-policies-teams.md) The following Exchange items from user mailboxes and shared mailboxes can be ret Calendar items that have an end date are supported for retention policies but aren't supported for retention labels. +Public folders are supported for retention policies but aren't supported for retention labels. + Contacts, and any tasks and calendar items that don't have an end date are not supported. Other items stored in a mailbox, such as Skype and Teams messages, aren't included in retention policies or labels for Exchange. These items have their own retention policies. Both a mailbox and a public folder use the [Recoverable Items folder](/exchange/ When a user deletes a message in a folder other than the Deleted Items folder, by default, the message moves to the Deleted Items folder. However, a user can soft delete an item (Shift+Delete) in any folder, which bypasses the Deleted Items folder and moves the item directly to the Recoverable Items folder. -When you apply retention settings to Exchange data, a timer job periodically evaluates items in the Recoverable Items folder. If an item doesn't match the rules of at least one retention policy or retention label to retain the item, it is permanently deleted (also called hard deleted) from the Recoverable Items folder. +When you apply retention settings to Exchange data, a timer job periodically evaluates items in the Recoverable Items folder. If an item doesn't match the rules of at least one retention policy or retention label to retain the item, it is permanently deleted (also called hard deleted) from the Recoverable Items folder. Items configured for [disposition review](disposition.md) are never permanently deleted from the Recoverable Items folder until the disposition is confirmed. > [!NOTE] > Because of the [first principle of retention](retention.md#the-principles-of-retention-or-what-takes-precedence), permanent deletion is always suspended if the same item must be retained because of another retention policy or retention label, or it is under eDiscovery holds for legal or investigative reasons. |
| compliance | Retention Policies Sharepoint | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/compliance/retention-policies-sharepoint.md | To store content that needs to be retained, SharePoint and OneDrive create a Pre When a user changes an item that's subject to retention from a retention policy or a retention label that marks items as a record, or deletes any item subject to retention, the original content is copied to the Preservation Hold library. This behavior lets the user to change or delete the content in their app, while keeping a copy of the original for compliance reasons. -A timer job periodically runs on the Preservation Hold library. For content that has been in the Preservation Hold library for more than 30 days, this job compares the content to all queries used by the retention settings for that content. Content that is older than their configured retention period is then deleted from the Preservation Hold library, and from the original location if it is still there. This timer job runs every seven days, which means that together with the minimal 30 days, it can take up to 37 days for content to be deleted from the Preservation Hold library. +A timer job periodically runs on the Preservation Hold library. For content that has been in the Preservation Hold library for more than 30 days, this job compares the content to all queries used by the retention settings for that content. Content that is older than their configured retention period and isn't awaiting [disposition review](disposition.md) is then deleted from the Preservation Hold library, and from the original location if it is still there. This timer job runs every seven days, which means that together with the minimal 30 days, it can take up to 37 days for content to be deleted from the Preservation Hold library. This behavior for copying files into the Preservation Hold library applies to content that exists when the retention settings were applied. In addition, for retention policies, any new content that's created or added to the site after it was included in the policy will be retained in the Preservation Hold library. However, new content isn't copied to the Preservation Hold library the first time it's edited, only when it's deleted. To retain all versions of a file, [versioning](#how-retention-works-with-document-versions) must be turned on for the original site. Only pages and sections are impacted by the retention settings that you specify. Versioning is a feature of all document lists and libraries in SharePoint and OneDrive. By default, versioning retains a minimum of 500 major versions, although you can increase this limit. For more information, see [Enable and configure versioning for a list or library](https://support.office.com/article/1555d642-23ee-446a-990a-bcab618c7a37) and [How versioning works in lists and libraries](https://support.microsoft.com/office/how-versioning-works-in-lists-and-libraries-0f6cd105-974f-44a4-aadb-43ac5bdfd247). -When a document with versions is subject to retention settings to retain that content, how the versions are stored in the Preservation Hold library changed in July 2022 to improve performance. Now, all versions of the file are retained in a single file in the Preservation Hold library. Before the change, versions were copied to the Preservation Hold library as separate files, and after the change, remain as separate files. +When a document with versions is subject to retention settings to retain that content, and it's not marked as a record, how the versions are stored in the Preservation Hold library changed in July 2022 to improve performance. Now, all versions of that file are retained in a single file in the Preservation Hold library. Before the change, versions were copied to the Preservation Hold library as separate files, and after the change, remain as separate files. -If the retention settings are configured to delete at the end of the retention period: +> [!NOTE] +> Versions that are from a record continue to be copied to the Preservation Hold library as separate files, which means that they can expire independently from each other and the current version. ++If the label doesn't mark the item as a record and retention settings are configured to delete the item at the end of the retention period: - If the retention period is based on when the content was created, when labeled, or when an event starts, each version has the same expiration date as the original document. The original document and its versions all expire at the same time. |
| enterprise | Microsoft 365 Vpn Split Tunnel | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel.md | We can then trigger policy such as approve, trigger MFA or block authentication ### How do I protect against viruses and malware? -Again, Microsoft 365 provides protection for the Optimize marked endpoints in various layers in the service itself, [outlined in this document](/office365/Enterprise/office-365-malware-and-ransomware-protection). As noted, It's vastly more efficient to provide these security elements in the service itself rather than try to do it in line with devices that may not fully understand the protocols/traffic. By default, SharePoint Online [automatically scans file uploads](../security/office-365-security/virus-detection-in-spo.md) for known malware +Again, Microsoft 365 provides protection for the Optimize marked endpoints in various layers in the service itself, [outlined in this document](/office365/Enterprise/office-365-malware-and-ransomware-protection). As noted, it's vastly more efficient to provide these security elements in the service itself rather than try to do it in line with devices that may not fully understand the protocols/traffic. By default, SharePoint Online [automatically scans file uploads](../security/office-365-security/anti-malware-protection-for-spo-odfb-teams-about.md) for known malware For the Exchange endpoints listed above, [Exchange Online Protection](/office365/servicedescriptions/exchange-online-protection-service-description/exchange-online-protection-service-description) and [Microsoft Defender for Microsoft 365](/office365/servicedescriptions/office-365-advanced-threat-protection-service-description) do an excellent job of providing security of the traffic to the service. |
| frontline | Flw Deploy Overview | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/frontline/flw-deploy-overview.md | Last updated 10/28/2022 # Learn where to start with a frontline deployment -Thanks for choosing Microsoft 365 for frontline workers. Whether you're a small business or a large multi-national chain, Teams for frontline workers can help bring your organization together with chats, helpful apps, and more. And no matter whether you're just getting into collaboration tools for the first time, or you've already been using Teams for your non-frontline workers, we can help you get up and running. +Thanks for choosing Microsoft 365 for frontline workers. Whether you're an independent business or a large multi-national enterprise, Microsoft 365 and Teams for frontline workers can help bring your organization together with tools for communication, collaboration, and productivity. And no matter whether you're just getting into collaboration tools for the first time, or you've already been using Microsoft 365 and Teams for your non-frontline workers, we can help you get up and running. -| Image |Path |Description | -|-|-|--| -| . | -| |Before you commit to a full rollout of Microsoft 365 for frontline workers across your organization, it's a good idea to try it out first with a small set of real people in your organization. | -|  to complete your deployment. | +|Article |Description | +|-|-| +|[Trial setup for frontline managers](get-up-and-running.md)|If you're a manager of a frontline worker team, you can set up a trial for your frontline workforce from within Microsoft Teams. Admins can learn more about the manager-led setup at: [Manage the Frontline Trial in Teams](flw-trial.md). | +|[Start with a pilot deployment of Microsoft 365 for frontline workers](flw-pilot.md)|Before you commit to a full rollout of Microsoft 365 for frontline workers across your organization, it's a good idea to try it out first with a small set of real people in your organization. | +|[Set up Microsoft 365 for frontline workers](flw-setup-microsoft-365.md)|Follow this setup path if you're an IT pro or responsible for planning, or deploying Teams for Frontline Workers. It walks through preparing your environment, setting up the core of Microsoft 365, and then setting up the services you need for your scenarios. | +|[Deploy Microsoft Teams at scale](deploy-teams-at-scale.md) |Once you've set up Microsoft 365 and assigned licenses to your users, you can use PowerShell to create and manage Teams for your whole frontline workforce. | After you have set up Microsoft 365, Microsoft Teams, and any services you need, you can configure Teams and the apps in Teams to support your scenarios. Each of the paths above will walk you through the whole process, from initial setup to a configured team with the apps your users need to start working. |
| frontline | Flw Devices | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/frontline/flw-devices.md | Title: Manage mobile devices for frontline workers + Title: Manage devices for frontline workers audience: admin ms.localizationpriority: high search.appverid: MET150-description: Get an overview of managing mobile devices for frontline workers in your organization. +description: Get an overview of managing mobile shared and BYOD devices for frontline workers in your organization. - m365-frontline - highpri-# Manage mobile devices for frontline workers --## Overview +# Manage devices for frontline workers Across every industry, frontline workers make up a large segment of the workforce. Frontline worker roles include retail associates, factory workers, field and service technicians, healthcare personnel, and many more. +## Overview + Because the workforce is largely mobile and often shift-based, managing the devices that frontline workers use is a key fundamental. Some questions to consider: - Do workers use company-owned devices or their own personal devices? Because the workforce is largely mobile and often shift-based, managing the devi ItΓÇÖs important to set a secure, compliant baseline to manage devices for your workforce, whether theyΓÇÖre shared devices or workersΓÇÖ own devices. This article gives you an overview of common frontline worker device scenarios and management capabilities to help empower your workforce while safeguarding company data. -## My Staff +## Device types -With the [My Staff](/azure/active-directory/roles/my-staff-configure) feature in Azure Active Directory (Azure AD), you can delegate common user management tasks to frontline managers through the My Staff portal. Frontline managers can perform password resets or manage phone numbers for frontline workers directly from the store or factory floor, without having to route the requests to helpdesk, operations, or IT. +Shared, bring-your-own, and kiosk devices are the most common device types used by frontline workers. -My Staff also enables frontline managers to register their team members' phone numbers for SMS sign-in. If [SMS-based authentication](/azure/active-directory/authentication/howto-authentication-sms-signin) is enabled in your organization, frontline workers can sign in to Teams and other apps using only their phone numbers and a one-time passcode sent via SMS. This makes signing in for frontline workers simple, secure, and fast. +|Device type|Description|Why to use|Deployment considerations| +|--|--|-|--| +|Shared devices |Devices are owned and managed by your organization. Employees access devices while at work. |Worker productivity and customer experience are a top priority. <br><br> Workers can't access organization resources while not at work. <br><br> Local laws may prevent personal devices from being used for business purposes. |Sign in/out can add friction to worker experience. <br><br> Potential for inadvertent sharing of sensitive data. | +|Bring-your-own devices (BYOD) |Personal devices are owned by the user and managed by your organization. |Your existing mobile device management (MDM) solution prevents your organization from adopting a shared devices model. <br><br>Shared devices or dedicated devices may be impractical from a cost or business-readiness perspective. |Support complexity may not be feasible in field locations. <br><br> Personal devices vary in OS, storage, and connectivity. <br><br> Some workers may not have reliable access to a personal mobile device. <br><br> You could incur potential liability for wages if workers access resources while not clocked in. <br><br> Personal device use may be against union rules or government regulations. | +|Kiosk devices |Devices are owned and managed by your organization. Users don't need to sign in or out. |Device has a dedicated purpose. <br><br> Use case doesn't require user authentication.|Collaboration, communication, task, and workflow applications need a user identity to function. <br><br> Not possible to audit user activity. <br><br> Unable to use some security capabilities including multifactor authentication. | ++Shared devices and BYOD are commonly adopted in frontline deployments. You can use capabilities discussed in subsequent sections of this article may resolve or mitigate your organizationΓÇÖs concerns over user experience, unauthorized worker access to data, and resources and ability to deploy and manage devices at scale. -## Shared devices +> [!NOTE] +> Kiosk device deployments arenΓÇÖt recommended because they donΓÇÖt allow user auditing and user-based security capabilities like multifactor authentication. [Learn more about kiosk devices](/windows/configuration/kiosk-methods). ++### Shared devices Many frontline workers use shared mobile devices to do work. Shared devices are company-owned devices that are shared between employees across tasks, shifts, or locations. HereΓÇÖs an example of a typical scenario. An organization has a pool of devices Shared devices present unique security challenges. For example, employees may have access to company or customer data that shouldnΓÇÖt be available to others on the same device. -This section provides an overview of capabilities available to manage shared devices for frontline workers. +### Personal devices (BYOD) ++Some organizations use a bring-your-own-device (BYOD) model where frontline workers use their own mobile devices to access Teams and other business apps. Here's an overview of some ways to manage access and compliance on personal devices. ++### Device operating system ++The deployment model you select will partly determine the device operating systems you support. For example, if you implement a BYOD model, youΓÇÖll need to support both Android and iOS devices. If you implement a shared devices model, the device OS you choose will determine the capabilities available. For example, Windows devices natively support the ability to store multiple user profiles for automated sign-on and easy authentication with Windows Hello. With Android and iOS, more steps and pre-requisites apply. ++|Device OS|Considerations| +||--| +|Windows |Native support for storing multiple user profiles on the device. <br> Supports Windows Hello for passwordless authentication. <br> Simplified deployment and management capabilities when used with Microsoft Intune. | +|Android |[Limited native capabilities](https://source.android.com/docs/devices/admin/multi-user) for storing multiple user profiles on devices. <br> Android devices can be enrolled in shared device mode to automate single sign-on and sign out. <br> Robust management of controls and APIs. <br> Existing ecosystem of devices built for frontline use. | +|iOS and iPadOS |iOS devices can be enrolled in shared device mode to automate single sign-on and sign out. <br> Storing multiple user profiles on iPadOS devices is possible with Shared iPad for Business. Conditional access isn't available with Shared iPad for Business because of the way Apple partitions user profiles. | ++In a shared devices deployment, the ability to store multiple user profiles on a device to simplify user sign on and the ability to clear app data from the previous user (single sign out) are practical requirements for frontline deployments. These capabilities are native on Windows devices and iPads using Shared iPad for Business. ++## User identity ++Microsoft 365 for frontline workers uses Azure AD as the underlying identity service for delivering and securing all applications and resources. Users must have an identity that exists in Azure AD to access Microsoft 365 cloud applications. ++If you choose to manage frontline user identities with Active Directory Domain Services (AD DS) or a third-party identity provider, youΓÇÖll need to federate these identities to Azure AD. [Learn how to integrate your third-party service with Azure AD](flw-setup-microsoft-365.md#provision-users). ++The possible implementation patterns for managing frontline identities include: ++- **Azure AD standalone:** Your organization creates and manages user, device, and application identities in Azure AD as a standalone identity solution for your frontline workloads. This implementation pattern is recommended as it simplifies your frontline deployment architecture and maximizes performance during user sign-on. +- **Active Directory Domain Services (AD DS) integration with Azure AD:** Microsoft provides Azure AD Connect to join these two environments. Azure AD Connect replicates AD user accounts to Azure AD, allowing a user to have a single identity capable of accessing both local and cloud-based resources. Although both AD DS and Azure AD can exist as independent directory environments, you can choose to create hybrid directories. +- **Third-party identity solution sync with Azure AD:** Azure AD supports integration with third-party identity providers such as Okta and Ping Identity through federation. [Learn more about using third-party identity providers](flw-setup-microsoft-365.md#provision-users). ++### HR-driven user provisioning ++Automating user provisioning is a practical need for organizations that want frontline employees to be able to access applications and resources on day one. From a security perspective, itΓÇÖs also important to automate deprovisioning during employee offboarding to ensure that previous employees donΓÇÖt retain access to company resources. ++Azure AD user provisioning service integrates with cloud-based and on-premises HR applications, such as Workday and SAP SuccessFactors. You can configure the service to automate user provisioning and deprovisioning when an employee is created or disabled in the HR system. ++### My Staff ++With the [My Staff](/azure/active-directory/roles/my-staff-configure) feature in Azure Active Directory (Azure AD), you can delegate common user management tasks to frontline managers through the My Staff portal. Frontline managers can perform password resets or manage phone numbers for frontline workers directly from the store or factory floor, without having to route the requests to helpdesk, operations, or IT. ++My Staff also enables frontline managers to register their team members' phone numbers for SMS sign-in. If [SMS-based authentication](/azure/active-directory/authentication/howto-authentication-sms-signin) is enabled in your organization, frontline workers can sign in to Teams and other apps using only their phone numbers and a one-time passcode sent via SMS. This makes signing in for frontline workers simple, secure, and fast. ++## Mobile device management ++Mobile device management (MDM) solutions can simplify deployment, management and monitoring of devices. Microsoft Intune natively supports features important for deploying shared devices to frontline workers. These capabilities include: ++- **Zero-touch provisioning:** IT admins can enroll and pre-configure mobile devices without physical custody of the devices (for manual configuration). This capability is useful when deploying shared devices at scale to field locations because devices can be shipped directly to the intended frontline location where automated configuration and provisioning steps can be completed remotely. +- **Single sign-out:** Stops background processes and automates user sign out across all applications and resources assigned to the previous user when a new user signs in. Android and iOS devices must be enrolled in shared device mode to use single sign out. +- **Azure AD conditional access:** IT admins can implement automated access control decisions for cloud-based applications and resources through identity-driven signals. For example, itΓÇÖs possible to prevent access by a shared or BYOD device that doesnΓÇÖt have the latest security updates installed. [Learn more about how to secure your deployment](flw-setup-microsoft-365.md#step-6-configure-security). ++If youΓÇÖre using a third-party MDM solution for your shared devices deployment, such as VMwareΓÇÖs Workspace ONE or SOTI MobiControl, itΓÇÖs important to understand the associated capabilities, limitations and available workarounds. ++Some third-party MDMs can clear app data when a global sign out occurs on an Android device. However, app data clearing can miss data that is stored in a shared location, delete app settings, or cause first-run experiences to reappear. Android devices enrolled in shared device mode can selectively clear the necessary application data during device check-in or when the new user logs in to the device. [Learn more about authentication in shared device mode](#authentication). ++You can manually configure shared device mode in third-party MDM solutions for iOS and Android devices, however, manual configuration steps donΓÇÖt mark the device compliant in Azure AD, which means conditional access isnΓÇÖt supported in this scenario. If you choose to manually configure devices in shared device mode, youΓÇÖll need to take additional steps to re-enroll Android devices in shared device mode with zero-touch provisioning to get conditional access support when third-party MDM support is available by uninstalling and reinstalling Authenticator from the device. ++A device can only be enrolled in one MDM solution, but you can use multiple MDM solutions to manage separate pools of devices. For example, you could use Workspace ONE for shared devices and Intune for BYOD. If you use multiple MDM solutions, keep in mind that some users may not be able to access shared devices because of a mismatch in conditional access policies. ++|MDM solution |Single sign out|Zero touch provisioning|Azure AD conditional access| +|-||--|| +|Intune (Microsoft) |Supported for Android and iOS devices enrolled in shared device mode |Supported for Android and iOS devices enrolled in shared device mode |Supported for Android and iOS devices enrolled in shared device mode | +|Workspace ONE (VMware) |Supported with [Clear Android app data](https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/services/iOS_Platform/GUID-SharedDevicesOverview.html) capabilities. Unavailable for iOS |Currently unavailable for Android and iOS. |Currently unavailable for Android and iOS. | +|MobiControl (SOTI) |Supported with [Wipe program data](https://www.soti.net/mc/help/v14.4/en/console/applications/wipe_app_data.html) capabilities. Unavailable for iOS. |Currently unavailable for Android and iOS. |Currently unavailable for Android and iOS. | ++Windows devices enrolled in Intune support single sign out, zero touch provisioning, and Azure AD conditional access. You donΓÇÖt need to configure shared device mode on Windows devices. ++Intune is recommended for BYOD scenarios because it provides the best support and functionality out-of-the-box across device types. ++### Enroll Android and iOS personal devices ++In addition to your company-owned devices, you can [enroll](/mem/intune/enrollment/device-enrollment) users' personally owned devices into management in Intune. For BYOD enrollment, you add device users in the Microsoft Endpoint Manager admin center, configure their enrollment experience, and set up Intune policies. Users complete enrollment themselves in the Intune Company Portal app that's installed on their device. ++In some cases, users may be reluctant to enroll their personal devices into management. If device enrollment isn't an option, you can choose a mobile application management (MAM) approach and use [app protection policies](/mem/intune/apps/app-protection-policies) to manage apps that contain corporate data. For example, you can apply app protection policies to Teams and Office mobile apps to prevent company data from being copied to personal apps on the device. ++To learn more, see ["Personal devices vs Organization-owned devices" in the Intune planning guide](/mem/intune/fundamentals/intune-planning-guide#personal-devices-vs-organization-owned-devices) and [Deployment guidance: Enroll devices in Microsoft Intune](/mem/intune/fundamentals/deployment-guide-enrollment). ++## Authentication ++Authentication features control who or what uses an account to gain access to applications, data, and resources. Organizations deploying shared devices to frontline workers need authentication controls that donΓÇÖt impede worker productivity while preventing unauthorized or unintended access to applications and data when devices are transferred between authenticated users. ++MicrosoftΓÇÖs frontline solution is delivered from the cloud and utilizes Azure AD as the underlying identity service for securing Microsoft 365 applications and resources. These authentication features in Azure AD address the unique considerations for shared devices deployments: automatic single sign-on, single sign out, and other strong authentication methods. ### Shared device mode -[Shared device mode](/azure/active-directory/develop/msal-shared-devices) is a feature of Azure AD that enables you to configure devices to be shared by employees. This feature enables single sign-on (SSO) and device-wide sign-out for Microsoft Teams and all other apps that support shared device mode. You can integrate this capability into your line-of-business (LOB) apps using the Microsoft Authentication Library (MSAL). +[Shared device mode](/azure/active-directory/develop/msal-shared-devices) is a feature of Azure AD that enables you to configure devices to be shared by employees. This feature enables single sign-on (SSO) and device-wide sign out for Microsoft Teams and all other apps that support shared device mode. You can integrate this capability into your line-of-business (LOB) apps using the Microsoft Authentication Library (MSAL). Once a device is in shared device mode, applications that leverage Microsoft Authentication Library (MSAL) can detect that theyΓÇÖre running on a shared device and determine who the current active user is. With this information, applications can accomplish these authentication controls: ++- **Automatic single sign-on:** If a user has already signed into another MSAL application, the user will be logged into any application compatible with Shared Device Mode. This is an improvement to the previous single sign-on experience because it further reduces the time it takes to access applications after signing into the first application by removing the need for a user to select a previously signed in account. +- **Single sign-out:** Once a user signs out of an app using MSAL, all other applications integrated with shared device mode can stop background processes and commence sign out data clearing processes to prevent unauthorized or unintended access by the next user. ++Here's how shared device mode works, using Teams as an example. When an employee signs in to Teams at the start of their shift, theyΓÇÖre automatically signed in to all other apps that support shared device mode on the device. At the end of their shift, when they sign out of Teams, they're signed out globally from all other apps that support shared device mode. After sign out, the employee's data and company data in Teams (including apps hosted within it) and in all other apps that support shared device mode can no longer be accessed. The device is ready for the next employee and can be safely handed off. ++Shared device mode is an improvement to the app data clear functionality for Android because it allows application developers to selectively clear personal user data without impacting app settings or cached data. With shared device mode, the flags that allow an application to remember if a first run experience is shown aren't deleted so users donΓÇÖt see a first run experience every time they sign-on. -Here's how shared device mode works, using Teams as an example. When an employee signs in to Teams at the start of their shift, theyΓÇÖre automatically signed in to all other apps that support shared device mode on the device. At the end of their shift, when they sign out of Teams, they're signed out globally from all other apps that support shared device mode. After sign-out, the employee's data and company data in Teams (including apps hosted within it) and in all other apps that support shared device mode can no longer be accessed. The device is ready for the next employee and can be safely handed off. +Shared device mode also allows a device to be enrolled into Azure AD once for all users so that you can easily create profiles that secure app and data usage on the shared device. This allows you to support conditional access without having to re-enroll the device every time a new user authenticates into the device. You use a mobile device management (MDM) solution like Microsoft Intune in Microsoft Endpoint Manager to prepare a device to be shared by installing the [Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) and turning on shared mode. Teams and all other apps that support shared device mode use the shared mode setting to manage users on the device. The MDM solution you use should also perform a device cleanup when sign out occurs. +> [!NOTE] +> Shared device mode isnΓÇÖt a full data loss prevention solution. Shared device mode should be used in conjunction with Microsoft Application Manager (MAM) policies to ensure that data doesnΓÇÖt leak to areas of the device that arenΓÇÖt leveraging shared device mode (e.g., local file storage). ++#### Prerequisites and considerations ++YouΓÇÖll need to meet the following prerequisites to use shared device mode. ++- The device must first have Microsoft Authenticator installed. +- The device must be enrolled in shared device mode. +- All the applications that need these benefits need to integrate with the shared device mode APIs in MSAL. ++MAM policies are required to prevent data from moving from shared device mode enabled applications to non-shared device mode enabled applications. ++Currently, zero-touch provisioning of shared device mode is only available with Intune. If youΓÇÖre using a third-party MDM solution, devices must be enrolled in shared device mode using the [manual configuration steps](/azure/active-directory/develop/tutorial-v2-shared-device-mode#set-up-an-android-device-in-shared-mode). ++> [!NOTE] +> Conditional access isnΓÇÖt fully supported for devices that are configured manually. ++Some Microsoft 365 applications donΓÇÖt currently support shared device mode. The table below summarizes what is available. If the application you need lacks shared device mode integration, itΓÇÖs recommended that you run a web-based version of your application in either Microsoft Teams or Microsoft Edge to get the benefits of shared device mode. + Shared device mode is currently supported on Android devices. Here's some resources to help you get started. #### Enroll Android devices into shared device mode To manage and enroll Android devices into shared device mode using Intune, devic - [Set up Intune enrollment for Android Enterprise dedicated devices](/mem/intune/enrollment/android-kiosk-enroll) - [Enroll Android Enterprise dedicated devices into Azure AD shared device mode](https://techcommunity.microsoft.com/t5/intune-customer-success/enroll-android-enterprise-dedicated-devices-into-azure-ad-shared/ba-p/1820093) -You can also choose to deploy the Microsoft Managed Home Screen app to tailor the experience for users on their Intune-enrolled Android dedicated devices. Managed Home Screen acts as a launcher for other approved apps to run on top of it, and lets you customize devices and restrict what employees can access. For example, you can define how apps appear on the home screen, add your company logo, set custom wallpaper, and allow employees to set a session PIN. You can even configure sign-out to happen automatically after a specified period of inactivity. To learn more, see: +You can also choose to deploy the Microsoft Managed Home Screen app to tailor the experience for users on their Intune-enrolled Android dedicated devices. Managed Home Screen acts as a launcher for other approved apps to run on top of it, and lets you customize devices and restrict what employees can access. For example, you can define how apps appear on the home screen, add your company logo, set custom wallpaper, and allow employees to set a session PIN. You can even configure sign out to happen automatically after a specified period of inactivity. To learn more, see: - [Configure the Microsoft Managed Home Screen app for Android Enterprise](/mem/intune/apps/app-configuration-managed-home-screen-app) - [How to set up Microsoft Managed Home Screen on dedicated devices in multi-app kiosk mode](https://techcommunity.microsoft.com/t5/intune-customer-success/how-to-setup-microsoft-managed-home-screen-on-dedicated-devices/ba-p/1388060) If you're a developer, see the following resources for more information about ho - [Shared device mode for Android devices](/azure/active-directory/develop/msal-android-shared-devices) - [Shared device mode for iOS devices](/azure/active-directory/develop/msal-ios-shared-devices) -## Personal devices (BYOD) +### Multifactor authentication -Some organizations use a bring-your-own-device (BYOD) model where frontline workers use their own mobile devices to access Teams and other business apps. Here's an overview of some ways to manage access and compliance on personal devices. +Azure AD supports several forms of multifactor authentication with the Authenticator app, FIDO2 keys, SMS, voice calls, and more. -### Enroll Android and iOS personal devices +Due to higher cost and legal restrictions, the most secure authentication methods may not be practical for many organizations. For example, FIDO2 security keys are typically considered too expensive, biometric tools like Windows Hello may run against existing regulations or union rules, and SMS sign in may not be possible if frontline workers arenΓÇÖt permitted to bring their personal devices to work. -In addition to your company-owned devices, you can [enroll](/mem/intune/enrollment/device-enrollment) users' personally owned devices into management in Intune. For BYOD enrollment, you add device users in the Microsoft Endpoint Manager admin center, configure their enrollment experience, and set up Intune policies. Users complete enrollment themselves in the Intune Company Portal app that's installed on their device. +multifactor authentication provides a high level of security for applications and data but adds ongoing friction to user sign-on. For organizations that choose BYOD deployments, multifactor authentication may or may not be a practical option. It's highly recommended that business and technical teams validate the user experience with multifactor authentication before broad rollout so that the user impact can be properly considered in change management and readiness efforts. -In some cases, users may be reluctant to enroll their personal devices into management. If device enrollment isn't an option, you can choose a mobile application management (MAM) approach and use [app protection policies](/mem/intune/apps/app-protection-policies) to manage apps that contain corporate data. For example, you can apply app protection policies to Teams and Office mobile apps to prevent company data from being copied to personal apps on the device. +If multifactor authentication isn't feasible for your organization or deployment model, you should plan to leverage robust conditional access policies to reduce security risk. -To learn more, see ["Personal devices vs Organization-owned devices" in the Intune planning guide](/mem/intune/fundamentals/intune-planning-guide#personal-devices-vs-organization-owned-devices) and [Deployment guidance: Enroll devices in Microsoft Intune](/mem/intune/fundamentals/deployment-guide-enrollment). +#### Passwordless authentication ++To further simplify access for your frontline workforce, you can leverage passwordless authentication methods so that workers donΓÇÖt need to remember or type in their passwords. Passwordless authentication methods are also typically more secure, and many can satisfy MFA requirements if necessary. ++Before proceeding with a passwordless authentication method, youΓÇÖll need to determine if it can work in your existing environment. Considerations like cost, OS support, personal device requirement, and MFA support can impact whether an authentication method would work for your needs. For example, FIDO2 security keys are currently considered too expensive, and SMS and Authenticator sign in may not be possible if frontline workers aren't permitted to bring their personal devices to work. ++Refer to the table to assess passwordless authentication methods for your frontline scenario. ++|Method|OS support|Requires personal device|Supports multifactor authentication | +||-||-| +|SMS sign in |Android and iOS |Yes |No | +|Windows Hello |Windows |No |Yes | +|Microsoft Authenticator |All |Yes |Yes | +|FIDO2 Key |Windows |No |Yes | ++If you're deploying with shared devices and the previous passwordless options aren't feasible, you can opt to disable strong password requirements so that users can provide simpler passwords while logging into managed devices. If you choose to disable strong password requirements, you should consider adding these strategies to your implementation plan. ++- Only disable strong password requirements for users of shared devices. +- Create a conditional access policy that prevents these users from logging into non-shared devices on non-trusted networks. ++## Authorization ++Authorization features control what an authenticated user can do or access. In Microsoft 365, this is achieved through a combination of Azure AD conditional access policies and application protection policies. ++Implementing robust authorization controls is a critical component of securing a frontline shared devices deployment, particularly if it isn't possible to implement strong authentication methods like multifactor authentication (MFA) for cost or practicality reasons. ++### Azure AD conditional access ++With conditional access, you can create rules that limit access based on the following signals: ++- User or group membership +- IP location information +- Device (only available if the device is enrolled in Azure AD) +- Application +- Real-time and calculated risk detection ++Conditional access policies can be used to block access when a user is on a non-compliant device or while theyΓÇÖre on an untrusted network. For example, you may want to use conditional access to prevent users from accessing an inventory application when they arenΓÇÖt on the work network or are using an unmanaged device, depending on your organizationΓÇÖs analysis of applicable laws. ++For BYOD scenarios where it makes sense to access data outside of work, such as HR-related information or non-business-related applications, you may choose to implement more permissive conditional access policies alongside strong authentication methods like multifactor authentication. ++Conditional access is supported for: ++- Shared Windows devices managed in Intune. +- Shared Android and iOS devices enrolled in shared device mode with zero-touch provisioning. +- BYOD for Windows, Android, and iOS managed with Intune or third-party MDM solutions. ++Conditional access **not** supported for: ++- Devices manually configured with shared device mode, including Android and iOS devices managed with third-party MDM solutions. +- iPad devices that use Shared iPad for Business. ++> [!NOTE] +> Conditional access for Android devices managed with select third-party MDM solutions is coming soon. ++For more information on conditional access, see the [Azure AD conditional access documentation](/azure/active-directory/conditional-access/). ++### App protection policies ++With MAM from Intune, you can use app protection policies (APP) with applications that have integrated with IntuneΓÇÖs [APP SDK](/mem/intune/developer/app-sdk-get-started). This allows you to further protect your organization's data within an application. ++With app protection policies you can add access control safeguards, such as: ++- Require a PIN to open an app in a work context. +- Control the sharing of data between applications +- Prevent the saving of company app data to a personal storage location +- Ensure the deviceΓÇÖs operating system is up to date ++You can also use APPs to ensure that data doesnΓÇÖt leak to applications that don't support shared device mode. To prevent data loss, the following APPs must be enabled on shared devices: ++- Disable copy/paste to non-shared device mode enabled applications. +- Disable local file saving. +- Disable data transfer capabilities to non-shared device mode enabled applications. ++APPs are helpful in BYOD scenarios because they allow you to protect your data at the app level without having to manage the entire device. This is important in scenarios where employees may have a device managed by another tenant (for example, a university or another employer) and can't be managed by another company. ++## Application management ++Your deployment plan should include an inventory and assessment of the applications that frontline workers will need to do their jobs. This section covers considerations and necessary steps to ensure that users have access to required applications and that the experience is optimized in the context of your frontline implementation. ++For the purposes of this assessment, applications are categorized in three groups: ++- **Microsoft applications** are built and supported by Microsoft. Microsoft applications support Azure AD and integrate with IntuneΓÇÖs APP SDK. However, not all Microsoft applications are supported with shared device mode. [See a list of supported applications and availability.](authentication bookmark) +- **Third-party applications** are built and sold commercially by a third-party provider. Some applications donΓÇÖt support Azure AD, IntuneΓÇÖs APP SDK, or shared device mode. Work with the application provider and your Microsoft account team to confirm what the user experience will be. +- **Custom line-of-business applications** are developed by your organization to address internal business needs. If you build applications using Power Apps, your app will automatically be enabled with Azure AD, Intune, and shared device mode. ++The applications that frontline users access meet these requirements (as applicable) for global single-in and single sign out to be enabled. ++- **Integrate custom and third-party applications with [MSAL](/azure/active-directory/develop/msal-overview):** Users can authenticate into your applications using Azure AD, enable SSO, and conditional access policies can be applied. +- **Integrate applications with shared device mode (applies only to Android or iOS shared devices):** Applications can use the necessary shared device mode APIs in MSAL to perform automatic single sign-on and single sign out. Appropriately using these APIs allows you to integrate with shared device mode. This isnΓÇÖt necessary if youΓÇÖre running your application in Teams, Microsoft Edge, or PowerApps. +- **Integrate with IntuneΓÇÖs APP SDK (applies only to Android or iOS shared devices):** Applications can be managed in Intune to prevent unintended or unauthorized data exposure. This isnΓÇÖt necessary if your MDM performs app data clears that wipe any sensitive data during device check-in flows (single sign out). ++Once youΓÇÖve successfully validated your applications, you can deploy them to managed devices using your MDM solution. This allows you to preinstall all the necessary applications during device enrollment so that users have everything they need on day one. ++### App launchers for Android devices ++On Android devices, the best way of providing a focused experience as soon as an employee opens a device is to provide a customized launch screen. With a customized launch screen, you can show only the relevant applications an employee needs to use and widgets that highlight key information. ++Most MDM solutions provide their own app launcher that can be used. For example, Microsoft provides Managed Home Screen. If you want to build your own custom app launcher for shared devices, youΓÇÖll need to integrate it with shared device mode so that single sign-on and single sign out works on your devices. The following table highlights some of the most common app launchers available today by Microsoft and third-party developers. ++|App launcher |Capabilities| +|-|| +|Managed Home Screen |Use Managed Home Screen when you want your end users to have access to a specific set of applications on your Intune-enrolled dedicated devices. Because Managed Home Screen can be automatically launched as the default home screen on the device and appears to the end user as the only home screen, it's useful in shared devices scenarios when a locked down experience is required. | +|Microsoft Launcher |Microsoft Launcher lets users personalize their phone, stay organized on the go, and transfer work from their phone to their PC. Microsoft Launcher differs from Managed Home Screen because it allows the end user access to their standard home screen. Microsoft Launcher is therefore useful in BYOD scenarios. | +|VMware Workspace ONE Launcher |For customers using VMware, the Workspace ONE Launcher is he best tool to curate a set of applications that your frontline workforce needs access to. The sign out option from this launcher is also what enables Android App Data Clear for single sign out on VMware devices. VMware Workspace ONE Launcher doesn't currently support shared device mode. | +|Custom app launcher |If you want a fully customized experience, you can build out your own custom app launcher. You can integrate your launcher with shared device mode so that your users only need to sign in and out once. | ## Related articles |
| frontline | Flw Setup Microsoft 365 | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/frontline/flw-setup-microsoft-365.md | For full deployments, follow the guidance in [Deploy Teams at scale for frontlin #### Set up Viva Connections -Use [Viva Connections](/viva/connections/viva-connections-overview) to create a dashboard that helps engage and inform your frontline workers. Viva Connections is a customizable app in Microsoft Teams that gives everyone a personalized destination to discover relevant news, conversations, and the tools they need to succeed. +Use [Viva Connections](/viva/connections/viva-connections-overview) to create a dashboard that helps engage and inform your frontline workers. Viva Connections is a customizable app in Microsoft Teams that gives everyone a personalized destination to discover relevant news, conversations, and the tools they need to succeed. Follow the [Build your employee experience setup guide](https://aka.ms/EmployeeExperienceDashboard) to set it up. Learn more about [setting up Viva Connections](/viva/connections/guide-to-setting-up-viva-connections). |
| frontline | Switch From Enterprise To Frontline | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/frontline/switch-from-enterprise-to-frontline.md | Start by getting familiar with the service and feature differences between the p Some key differences include: - F plans donΓÇÖt include Office desktop apps or the Outlook desktop app.-- F plans are limited to devices with integrated screens smaller than 10.1 inches on Office mobile apps.+- F plans are limited to devices with integrated screens smaller than 10.9 inches on Office mobile apps. - F plans [pin frontline worker apps](pin-teams-apps-based-on-license.md) like Walkie Talkie, Tasks, Shifts, and Approvals by default in Microsoft Teams. In this section, we've included more information about these key differences and highlighted some additional differences to pay attention to. Keep in mind that this isnΓÇÖt a comprehensive list. To learn more: Office desktop apps aren't included in F3 and F1 plans. Your frontline workers c |Office for the web (Word, Excel, OneNote, PowerPoint)|Yes|Yes|Read-only| |Office mobile apps (Word, Excel, PowerPoint, Outlook, OneNote)|Yes|Yes¹|Read-only| -¹Editing files supported on devices with integrated screens less than 10.1 inches. +¹Editing files supported on devices with integrated screens less than 10.9 inches. #### Office for the web For more information, see [Back up data before switching plans](/microsoft-365/c You can use the Microsoft 365 admin center to manually change plans or a scripted approach through PowerShell cmdlets. Whichever method you choose, it's important to complete the license change assignment in one operation. In other words, remove an existing E license and replace it by assigning an F license in the same operation. -Avoid removing an existing license for a user and then reassigning a new one at a later point in time. Doing this can impact a user's data. To learn more, see [What happens to a user's data when you remove their license?](/microsoft-365/admin/manage/remove-licenses-from-users?view=o365-worldwide#what-happens-to-a-users-data-when-you-remove-their-license). +Avoid removing an existing license for a user and then reassigning a new one at a later point in time. Doing this can impact a user's data. To learn more, see [What happens to a user's data when you remove their license?](/microsoft-365/admin/manage/remove-licenses-from-users#what-happens-to-a-users-data-when-you-remove-their-license). For step-by-step guidance on how to change plans in the Microsoft admin center, see [Manually change Microsoft plans](/microsoft-365/commerce/subscriptions/change-plans-manually). |
| lighthouse | M365 Lighthouse Deploy Baselines | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-deploy-baselines.md | - Title: "Deploy Microsoft 365 Lighthouse baselines"--------- Tier1-- scotvorg-- M365-subscription-management-- Adm_O365--- AdminSurgePortfolio-- M365-Lighthouse -description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to deploy Microsoft 365 Lighthouse baselines." ---# Deploy Microsoft 365 Lighthouse baselines --Microsoft 365 Lighthouse lets you deploy standard managed-tenant configurations to secure users, devices, and data within customer tenants. There are seven [default baseline configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) that come standard with Lighthouse. Using the Lighthouse deployment plan feature, you can view, test, and deploy security configurations across all your tenants. A deployment plan is only available to active tenants. Once a tenant is onboarded, you can compare your customers' current configuration against the default baseline configuration and take the appropriate actions. --## Before you begin --Make sure you and your customer tenants meet the requirements listed in [Requirements for Microsoft 365 Lighthouse](m365-lighthouse-requirements.md). --## View a deployment plan --1. In the left navigation pane in Lighthouse, select **Tenants**. --2. From the list of tenants, select the tenant you want to view. --3. Select the **Deployment Plan** tab. -- The Deployment Plan tab provides a searchable and exportable list of each deployment step that is included in the tenant's deployment plan that includes the following information for each deployment step: -- | Column | Description | - |--|-| - | Deployment step | Description of deployment step. | - | Status | The status of the deployment step. | - | Baseline | The baseline from which the deployment step is derived. | - | Category | Whether the deployment step is associated with managing Devices, Identity, or Data. | - | Last updated | The date at which the deployment step was last updated. | --4. From the list of deployment steps, select the deployment step that you want to review. -- The deployment step details page provides the following information: -- | Column | Description | - |-|--| - | Summary | A summary of the deployment step's purpose. | - | Baseline | The baseline from which the deployment step is derived. | - | Category | Whether the deployment step is associated with managing Devices, Identity, or Data. | - | Required SKU | SKUs required to complete the deployment step. | - | User impact | The impact of deploying the step to the tenant's users. | - | For your users | Links to resources the tenant's users may find helpful. | - | Next steps | Links and guidance around any applicable next steps. | -- Deployment steps include one or more processes that need to be completed. The deployment step details page includes a table that lists each process included in the deployment step and provides the following information: -- | Column | Description | - |-|-| - | Process name | The name of the process, which, when selected, will open the applicable process tab. | - | Status | Detected status of the setting configurations included in the deployment process. | - | Management portal | The portal through which the configurations settings associated with the process are managed. | --## Deploy a deployment step --1. In the left navigation page, select **Tenants**. --2. From the list of tenants, select the tenant that you want to view. --3. Select the **Deployment Plan** tab. --4. From the list of deployment steps, select the deployment step that you want to deploy. --5. Select **Review and deploy**. --6. In the **Confirm configuration** pane, select **Deploy**. --## Test a deployment step --For deployment steps deployed through Conditional Access policies, you can compare the configuration settings in the deployment step with settings in any existing policies without deploying the settings to the tenant. --1. In the left navigation page, select **Tenants**. --2. From the list of tenants, select the tenant that you want to view. --3. Select the **Deployment Plan** tab. --4. From the list of deployment steps, select the deployment step that you want to deploy. --5. Select **Review and deploy**. --6. In the **Confirm configuration** pane, select **Test these settings without a deployment**. --7. Select **Test**. --The **Confirm configuration** pane closes and displays the policy comparison. Each policy within the existing tenant is listed in the Detected settings table. --The Detected settings table lists each existing policy and summarizes the number of settings and, in parentheses, the number of users that have one of the following statuses: --| Status | Description -|-|| -| Equal settings | Total number of configuration settings in the deployment plan with an equivalent value in the tenant. | -| Missing settings | Total number of configuration settings in the deployment plan that are missing a value in the tenant. | -| Conflicting settings | Total number of configuration settings in the deployment plan that have a conflicting value in the tenant. | --You can also view detected settings in a modular table that provides configuration setting details for each policy at the setting and user level and you can sort the table by the following setting statuses: --| Status | Description -|-|| -| Total settings | Total number of configuration settings that are included in the deployment process. | -| Equal settings | Total number of configuration settings in the deployment plan with an equivalent value in the tenant. | -| Missing settings | Total number of configuration settings in the deployment plan that are missing a value in the tenant. | -| Conflicting settings | Total number of configuration settings in the deployment plan that have a conflicting value in the tenant. | -| Extra settings | Total number of configuration settings with a value in the tenant but no value in the deployment plan. | --When this comparison is made, Lighthouse automatically updates the Detected status, Deployment status, and Deployment Step status. --If there are no existing policies to compare, select **Review and deploy** to reopen the **Confirm configuration** pane, and then select **Deploy**. --If there are existing policies with which to compare, you can either: --- Edit the configuration settings of the deployment plan and retest them against the existing policies, select **Review and deploy** to reopen the **Confirm configuration** pane, adjust the desired configuration settings, reselect the checkbox, and then select **Test** at the bottom of the pane.--- Edit the existing policies within the applicable management portal to reconcile the differences by either:- - Applying missing settings - - Editing conflicting settings - - Deleting existing policies --For each deployment process that can be automated through Lighthouse, there's both a deployment status and a detected status. --- The detected status indicates to what extent the settings in this process are currently deployed.-- The deployment status is the status of the last deployment to the tenant.--You can deploy deployment steps regardless of existing policies but they won't be considered complete until there are no conflicting settings. Failure to resolve these conflicting settings may impact the user experience. --The deployment of the deployment step in instances when there are equal settings present in the tenant from an existing policy results in duplication of the existing settings within the tenant but won't impact the user experience. --Extra settings are provided for your awareness but don't require you to take action. --For more information on policy conflict management, see [Azure AD Conditional Access documentation](/azure/active-directory/conditional-access/). --## Update deployment step status --1. In the left navigation page in Lighthouse, select **Tenants**. --2. From the list of tenants, select the tenant that you want to view. --3. Select the **Deployment Plan** tab. --4. From the list of deployment steps, select the deployment step that you want to update. --5. From the **To address** dropdown list, select an action status. -- | Action status | Description | - |--|--| - | To address | The default state of all deployment steps that do NOT include multiple deployment step processes. | - | Planned | The deployment step has been planned but has yet to be completed. | - | Risk accepted | The user has accepted the risk that would otherwise have been averted by applying the deployment step. | - | Risk Resolved Through Third Party | The risk has been resolved by the implementation of a third-party application or software. | - | Resolved through alternate means | The risk has been resolved through alternate means, such as the implementation of an internal tool. | - | Manual configuration applied | The configuration prescribed in the deployment plan has been manually applied. | --## Share deployment step --1. In the left navigation page, select **Tenants**. --2. From the list of tenants, select the tenant you want to view. --3. Select the **Deployment Plan** tab. --4. From the list of deployment steps, select the deployment step that you want to share. --5. From the **Share** dropdown list, select one of the following options. -- | Option | Description | - |--|-| - | Copy | Copies a link to the deployment step into your clipboard. | - | Email | Opens your new email message on your local machine and inserts a link to the deployment step. | -- The link allows anyone with permissions in your organization to view the tenant's deployment plan. ---## Related content --[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ -[Overview of the Windows 365 (Cloud PCs) page in Microsoft 365 Lighthouse](m365-lighthouse-tenants-page-overview.md) (article)\ -[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article)\ -[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article) |
| lighthouse | M365 Lighthouse Deploy Standard Tenant Configurations Overview | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-deploy-standard-tenant-configurations-overview.md | description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthous # Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations -Microsoft 365 Lighthouse baselines provide a repeatable and scalable way for you to manage Microsoft 365 security settings across multiple customer tenants. Baselines provide standard tenant configurations that deploy core security policies and compliance standards that keep your tenants' users, devices, and data secure. To view the Microsoft 365 Lighthouse default baseline that applies to all tenants, select **Baselines** from the left navigation pane. +Microsoft 365 Lighthouse baselines provide a repeatable and scalable way for you to manage Microsoft 365 security settings across multiple customer tenants. Baselines provide standard tenant configurations that deploy core security policies and compliance standards that keep your tenants' users, devices, and data secure and healthy. ++To view the Microsoft 365 Lighthouse default baseline that applies to all tenants, select **Deployment > Baselines** from the left navigation pane. ## Microsoft 365 Lighthouse default baseline -The Microsoft 365 Lighthouse default baseline is designed to ensure all managed tenants are healthy and secure. To view the tasks included in the default baseline, select **View baseline** to open the **Default baseline** page. Select any of the tasks to view additional details about the task and the associated user impact. +The Microsoft 365 Lighthouse default baseline is designed to ensure all managed tenants are healthy and secure. To view the tasks included in the default baseline, select **Default baseline** from the list. Select any of the tasks to view additional details about the task and the associated user impact. :::image type="content" source="../media/m365-lighthouse-deploy-baselines/default-baseline-page.png" alt-text="Lighthouse default baseline"::: The Microsoft 365 Lighthouse default baseline is designed to ensure all managed ## Related content +[Review a deployment plan](m365-lighthouse-review-deployment-plan.md) (article)\ +[Overview of deployment tasks](m365-lighthouse-overview-deployment-task.md) (article)\ +[Common Conditional Access policies](/azure/active-directory/conditional-access/concept-conditional-access-policy-common) (article)\ [Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ [Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ [Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Deploy Task Automatically | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-deploy-task-automatically.md | + + Title: "Deploy a task automatically in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to deploy a task automatically." +++# Deploy a task automatically in Microsoft 365 Lighthouse ++Microsoft 365 Lighthouse enables you to deploy configurations associated with eligible deployment tasks automatically. This capability enables you to ensure that the tenants you manage are healthy and secure. ++## Before you begin ++Make sure you and your customer tenants meet the requirements listed in [Requirements for Microsoft 365 Lighthouse](m365-lighthouse-requirements.md). ++Additionally, each partner tenant user must meet the following requirements: ++- The partner tenant user must have DAP/GDAP access to the applicable tenant. ++ - For DAP, an admin agent group membership. ++ - For GDAP, a role that can create Conditional Access (CA) policies. ++- The partner tenant user must enable MFA for their user account in the partner tenant. ++## Deploy a task automatically ++1. From the left navigation pane in Lighthouse, select **Tenants.** ++2. From the list of tenants, select a tenant you want to view. ++3. Select the **Deployment Plan** tab. ++4. Select a task from the list. ++5. In the task details pane, select **Deploy.** ++6. In the **Review and edit deployment configuration** page, edit the default configuration as needed. ++ 1. Select whether to deploy the applicable configuration as **Enable** or **Report Only** mode if applicable. ++ 2. If applicable, edit the assignment of the task to: ++ 1. Include or exclude specific users. ++ 2. Include or exclude security groups. + > [!NOTE] + > Tasks implemented by a conditional access policy deployment include a drop-down menu to select the deployment state. Tasks are set to the deployment state of **Enabled** by default but can be manually adjusted to **Report Only** via the drop-down menu. Tasks deployed as **Enabled** will immediately impact user experience. Settings from configurations deployed in a **Report only** state will continue to be reported as **Not compliant** in Lighthouse until the deployment state of the applicable configuration is updated to **Enabled**. ++7. Select **Next**. ++8. In the **Review detected configurations** page, review detected configurations. ++ The **Review detected configurations** page is provided for eligible tasks and lists any existing configurations detected within the tenant. From this page, you may either edit the existing configurations or deploy a new configuration through Lighthouse to fulfill the task's requirements. ++ If existing configurations are detected, they’ll be displayed in the detected configuration in the deployment plan comparison table. For each detected configuration, Lighthouse will determine whether the setting is **Compliant**, **Not compliant**, **Missing**, or **Extra**. ++ The detected configurations table at the bottom of the page allows you to compare the detected configurations from the tenant to your deployment plan, inclusive of any selections made on the **Review and edit deployment configuration** page. This table can be filtered by configuration or setting status and searched by user. ++ If there are no detected configurations, you’ll be directed to the confirm and deploy page. ++9. If applicable, edit existing configurations as needed. ++ 1. Open the appropriate management portal. ++ 2. Navigate to the appropriate configuration. ++ 3. Edit the configuration as required by the task. ++ 4. Save the updated configuration in the applicable management portal ++ 5. In Lighthouse, select **Refresh detected configurations** to refresh the results of the detected configuration. ++ When editing existing configurations, the presence of **Extra** settings has no impact on the deployment status of the task. You may retain, edit, or discard, **Extra** settings at your discretion. ++ Once Lighthouse sees no settings from the task that are missing for or not compliant for any of the users to whom the task is targeted, Lighthouse will update the task status to **Compliant**, and you'll be prompted to exit the wizard. ++10. Select **Next**. ++11. From the **Confirm and deploy** page, confirm the configuration and select **Confirm.** ++12. From the **Complete** confirmation page, select **Close**. ++Choosing to deploy a new configuration through Lighthouse will ensure that the security configuration is enforced but doesn't modify any of the existing configurations. This may result in settings with duplicate or conflicting values for users, which may prevent the status of the task from being updated to compliant. To make the task compliant, you'll need to edit or delete the settings that aren't compliant with the existing configuration. ++## Related content ++[Deploy a task manually](m365-lighthouse-deploy-task-manually.md) (article)\ +[Dismiss a task](m365-lighthouse-dismiss-task.md) (article)\ +[Reinstate a task](m365-lighthouse-reinstate-task.md) (article)\ +[Overview of deployment tasks in Microsoft 365 Lighthouse](m365-lighthouse-overview-deployment-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Deploy Task Manually | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-deploy-task-manually.md | + + Title: "Deploy a task manually in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to deploy a task manually." +++# Deploy a task manually in Microsoft 365 Lighthouse ++Tasks that require configurations that can't be deployed automatically through Microsoft 365 Lighthouse require manual deployment. Once the manual deployment is complete, set the task status to **Compliant** to reflect the current state of the task. ++## Before you begin ++Make sure you and your customer tenants meet the requirements listed in [Requirements for Microsoft 365 Lighthouse](m365-lighthouse-requirements.md). ++Additionally, each partner tenant user must meet the following requirements: ++- The partner tenant user must have DAP/GDAP access to the applicable tenant. ++ - For DAP, an admin agent group membership. ++ - For GDAP, a role that can create Conditional Access (CA) policies. ++- The partner tenant user must enable MFA for their user account in the partner tenant. ++## Deploy a task manually ++1. In the left navigation pane in Lighthouse, select **Tenant.** ++2. From the tenant list, select the tenant you want to view. ++3. Select the **Deployment Plan** tab. ++4. From the task list, select the task you want to deploy manually. ++5. From the task details pane, select **Mark as compliant.** ++6. In the confirmation dialog box, type your name as it appears within Lighthouse. ++7. Select **Save**. ++The task status will be updated to **Compliant**, and the Task Details pane will reflect which Lighthouse user completed the implementation steps. ++If the task status changes and is no longer compliant, you can reset the status to **Not compliant**. To do this: ++1. In the left navigation pane in Lighthouse, select **Tenant.** ++2. From the tenant list, select the tenant you want to view. ++3. Select the **Deployment Plan** tab. ++4. From the task list, select the task you want to update. ++5. In the task details pane, select **Mark as not compliant**. ++6. In the **Mark task as not compliant** dialog box, select **Save**. ++Tasks that must be deployed manually can also be dismissed regardless of their deployment status. Tasks that have been dismissed after being set as **Compliant**, will revert to **Not compliant** when reinstated. ++## Related content ++[Deploy a task automatically](m365-lighthouse-deploy-task-automatically.md) (article)\ +[Dismiss a task](m365-lighthouse-dismiss-task.md) (article)\ +[Reinstate a task](m365-lighthouse-reinstate-task.md) (article)\ +[Overview of deployment tasks in Microsoft 365 Lighthouse](m365-lighthouse-overview-deployment-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Dismiss Task | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-dismiss-task.md | description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthous # Dismiss a task in Microsoft 365 Lighthouse -You can dismiss tasks from the deployment plan where a Managed Service Provider (MSP) chooses to accept the associated risk of not completing the task or to resolve the task through a third party or other alternate mitigation. The dismissal of a task doesn’t affect the configuration of the managed tenant. Once dismissed, Microsoft 365 Lighthouse will no longer detect configurations or report the deployment status for that task. Tasks can be dismissed or reinstated at any time. +You can dismiss tasks from the deployment plan where a Managed Service Provider (MSP) chooses to accept the associated risk of not completing the task or to resolve the task through a third party or other alternate mitigation. The dismissal of a task doesn’t affect the configuration of the managed tenant. Once dismissed, Microsoft 365 Lighthouse will no longer detect configurations or report the deployment status for that task. Tasks can be dismissed or reinstated at any time. ## Before you begin Additionally, each partner tenant user must meet the following requirements: - The partner tenant user must have DAP/GDAP access to the applicable tenant. - 1. For DAP, an admin agent group membership. + - For DAP, an admin agent group membership. - 2. For GDAP, a role that can create Conditional Access (CA) policies. + - For GDAP, a role that can create Conditional Access (CA) policies. - The partner tenant user must enable MFA for their user account in the partner tenant. Additionally, each partner tenant user must meet the following requirements: You can also select **More actions** (ellipsis icon) option directly from the task list to dismiss the task. +## Next Steps ++If the status of a dismissed tasks changes, you can reinstate the task. For more information, see [Reinstate a task in Microsoft 365 Lighthouse](m365-lighthouse-reinstate-task.md). + ## Related content [Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\-[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ [Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ [Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Overview Deployment Task | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-overview-deployment-task.md | + + Title: "Overview of deployment tasks in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn about more about deployment tasks." +++# Overview of deployment tasks in Microsoft 365 Lighthouse ++A tenant's deployment plan is complete when all tasks are compliant or explicitly dismissed. Microsoft 365 Lighthouse assesses each task based on the following factors: ++|Factor |Description | +||| +|Is the tenant licensed for the required services associated with the task? | <ul><li>Tasks that aren't licensed won't be eligible for deployment.</li><li>Tasks that aren't licensed may be dismissed.</li><li>Lighthouse will direct users to the Business Workshop Tool to determine licensing needs.</li><li>Once Lighthouse detects that the tenant is licensed for the required services associated with the task, the status will be updated automatically.</li></ul> | +|Is the task related to other tasks? | <ul><li>Tasks related to other tasks must be completed in sequential order.</li><li>Subsequent tasks will be eligible for deployment once the pre-requisite tasks are compliant.</li></ul> | +|Can the configuration associated with the task be deployed through Lighthouse? | <ul><li>Tasks that require configurations that can't be deployed through Lighthouse will require manual implementation.</li><li>Lighthouse can't deploy tasks when it can't detect any existing configuration.</li></ul> | +|Was the task dismissed? | <ul><li>Dismissed tasks aren't eligible for deployment.</li><li>Dismissed tasks can be reinstated.</li><li>Once a task is reinstated, the status will be updated automatically.</li></ul> | +|Is the task compliant? | <ul><li>Compliant tasks require no further action, but users may review task details and existing configurations.</li></ul> | ++## Related content ++[Deploy a task automatically](m365-lighthouse-deploy-task-automatically.md) (article)\ +[Deploy a task manually](m365-lighthouse-deploy-task-manually.md) (article)\ +[View task details](m365-lighthouse-view-task-details.md) (article)\ +[Dismiss a task](m365-lighthouse-dismiss-task.md) (article)\ +[Reinstate a task](m365-lighthouse-reinstate-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Reinstate Task | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-reinstate-task.md | Additionally, each partner tenant user must meet the following requirements: - The partner tenant user must have DAP/GDAP access to the applicable tenant. - 1. For DAP, an admin agent group membership. + - For DAP, an admin agent group membership. - 2. For GDAP, a role that can create Conditional Access (CA) policies. + - For GDAP, a role that can create Conditional Access (CA) policies. - The partner tenant user must enable MFA for their user account in the partner tenant. You can also select **More actions** (ellipsis icon) option directly from the ta ## Related content -[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ -[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Dismiss a task in Microsoft 365 Lighthouse](m365-lighthouse-dismiss-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ [Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ [Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Review Deployment Plan | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-review-deployment-plan.md | + + Title: "Review a deployment plan in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to Review a deployment plan." +++# Review a deployment plan in Microsoft 365 Lighthouse ++All tenants with an Onboarding status of **Active** are assigned the default baseline as their deployment plan. Deployment plans include a series of tasks that comprise the desired state for the tenant. Tasks may be automated through Microsoft 365 Lighthouse or require manual confirmation of implementation. Related tasks may also be grouped together. ++## Before you begin ++Make sure you and your customer tenants meet the requirements listed in [Requirements for Microsoft 365 Lighthouse](m365-lighthouse-requirements.md). ++Additionally, each partner tenant user must meet the following requirements: ++- The partner tenant user must have DAP/GDAP access to the applicable tenant. ++ - For DAP, an admin agent group membership. ++ - For GDAP, a role that can create Conditional Access (CA) policies. ++- The partner tenant user must enable MFA for their user account in the partner tenant. ++## Access a tenant deployment plan ++1. In the left navigation pane in Lighthouse, select **Tenants**. ++2. From the tenant list, select the tenant you want to view. ++3. Select the **Deployment Plan** tab. ++The **Deployment Plan** tab lists all tasks included in the tenant's deployment plan and provides the following information for each task: ++| **Column** | **Description** | +||-| +| Task | The name of the task. | +| Status | The status of the task. | +| Total users | Where applicable, the total number of users detected within the tenant. | +| Excluded | The number of users that have been excluded from the task. | +| Not compliant | The number of users whose configuration is Not compliant with the task. | +| Not licensed | The number of users that haven't been assigned licenses to the services required by the task. | +| Not targeted | The number of users that aren't targeted for assignment of the task. | +| Compliant | The number of users whose configuration is Compliant with the task. | ++The **Deployment Plan** tab also supports the following actions: ++- **Refresh:** Select to retrieve the most current task data. ++- **Search:** Enter keywords to quickly locate a specific task in the list. ++When a tenant’s onboarding status becomes **Active** or when you access a tenant within Lighthouse, Lighthouse queries the tenant for existing configurations. The deployment status is assigned to each task based on the status of each setting included in the subtask and, where applicable, for each user to which the subtask is assigned. ++Deployment statuses are automatically determined by Lighthouse when detection is possible, and by user input when detection isn't possible. ++## Related content ++[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of deployment tasks](m365-lighthouse-overview-deployment-task.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Tenants Page Overview | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-tenants-page-overview.md | The Deployment Plan tab also includes the following options: [Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article)\ [Manage your tenant list in Microsoft 365 Lighthouse](m365-lighthouse-manage-tenant-list.md) (article)\ [Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\-[Deploy Microsoft 365 Lighthouse baselines](m365-lighthouse-deploy-baselines.md) (article) |
| lighthouse | M365 Lighthouse Threat Management Page Overview | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-threat-management-page-overview.md | The Antivirus protection tab on the Threats management page shows the devices ac ## Related content -[Deploy Microsoft 365 Lighthouse baselines](m365-lighthouse-deploy-baselines.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) [Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse Understand Deployment Statuses | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-understand-deployment-statuses.md | + + Title: "Understand deployment statuses in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to understand deployment statuses in Lighthouse." +++# Understand deployment statuses in Microsoft 365 Lighthouse ++When a tenant’s onboarding status becomes **Active** or when you access a tenant within Microsoft 365 Lighthouse, Lighthouse queries the tenant for existing configurations. The deployment status is assigned to each task based on the status of each setting included in the subtask and, where applicable, for each user to which the subtask is assigned. ++Lighthouse automatically determines deployment statuses when detection is possible. When detection isn't possible, Lighthouse relies on the status you manually set. ++Tasks can have the following statuses: ++|Task Status | Description | +|--|| +|Compliant | <ul><li>All settings included in the subtask are Compliant.</li><li>There are no settings that are Missing or Not compliant.</li><li>There may be Extra settings detected within existing configurations.</li></ul> | +|Not Compliant | <ul><li>One or more settings included in the subtask are either Missing or Not compliant.</li><li>There may be Extra settings detected within existing configurations.</li><p>**Note:** Doesn't apply to subtasks that aren't licensed. </p></ul> | +|Not licensed | The tenant isn't licensed for the services required to deploy the configuration associated with the subtask. | +|Dismissed | The subtask has been Dismissed by a Lighthouse user.<p>**NOTE:** Not licensed subtasks may be dismissed by a Lighthouse user.</p> | ++Lighthouse will stop detecting or reporting deployment status for subtasks that have been dismissed. ++To determine the status of each subtask, Lighthouse detects the status of each setting included in the subtask. ++Settings can be assigned the following statuses: ++|Setting Status | Description | +|--|--| +| Compliant | The value detected in the tenant is equivalent to the value in the deployment plan for all targeted users. | +|Not compliant |The value detected in the tenant isn't equivalent to the value in the deployment plan for one or more targeted users. | +| Missing | There's no value detected in the tenant for a setting that is included in the deployment plan. | +| Extra | There's a value detected in the tenant for a setting that isn't included in the deployment plan. | ++Where applicable, Lighthouse detects the status of each user for the applicable subtask. ++Users can be assigned the following statuses: ++|User Status | Description | +|-|--| +|Compliant | <ul><li>The user is targeted for the subtask.</li><li>The user has been assigned licenses for all services required by the subtask.</li><li>All settings included in the subtask are Compliant.</li><li>There are no settings that are Missing or Not compliant.</li><li>There may be Extra settings detected within existing configurations.</li></ul> | +|Not compliant | <ul><li>The user is targeted for the subtask.</li><li>The user has been assigned licenses for all services required by the subtask.</li><li>One or more settings included in the subtask are either Missing or Not compliant.</li><li>There may be Extra settings detected within existing configurations.</li><p>**NOTE:** Doesn't apply to subtasks that are Not licensed.</p></ul> | +|Excluded | The user has been excluded from the subtask.<p>**NOTE**: When a user is excluded from a subtask, status detection and reporting will be updated accordingly, but existing configurations won't be affected.</p> | +|Not licensed | The user isn't licensed for the services required to deploy the prescribed configuration.<p>**NOTE:** Doesn't apply to users with Not targeted status.</p> | +|Not targeted | The user isn't targeted for the subtask. For example, a user that isn't an admin is reported as Not targeted for a subtask that is assigned only to admins. | ++## Related content ++[Overview of deployment tasks in Microsoft 365 Lighthouse](m365-lighthouse-overview-deployment-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| lighthouse | M365 Lighthouse View Task Details | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/lighthouse/m365-lighthouse-view-task-details.md | + + Title: "View task details in Microsoft 365 Lighthouse" +f1.keywords: CSH +++++audience: Admin +++ms.localizationpriority: medium ++- scotvorg +- M365-subscription-management +- Adm_O365 ++- AdminSurgePortfolio +- M365-Lighthouse +search.appverid: MET150 +description: "For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to view task details in Lighthouse." +++# View task details in Microsoft 365 Lighthouse ++Microsoft 365 Lighthouse provides detailed information on each task within a customer deployment plan. When you view a tenant's deployment plan, all tasks for which Lighthouse can detect existing configurations will have a status assigned to them for each setting and, where applicable, each user. ++Each task is designated as **Compliant**, **Not compliant**, or **Not licensed**. For a definition of deployment statuses, see [Understand deployment statuses in Microsoft 365 Lighthouse](m365-lighthouse-understand-deployment-statuses.md). You can deploy, dismiss, or reinstate tasks from this view. ++## Before you begin ++Make sure you and your customer tenants meet the requirements listed in [Requirements for Microsoft 365 Lighthouse](m365-lighthouse-requirements.md). ++Additionally, each partner tenant user must meet the following requirements: ++- The partner tenant user must have DAP/GDAP access to the applicable tenant. ++ - For DAP, an admin agent group membership. ++ - For GDAP, a role that can create Conditional Access (CA) policies. ++- The partner tenant user must enable MFA for their user account in the partner tenant. ++## View task details ++1. In the left navigation pane in Lighthouse, select **Tenants**. ++2. Select an active tenant. ++3. From the tenant page, select the **Deployment Plan** tab. ++4. From the task list, select a task to see more details. ++The task details pane provides task overview and user progress information. The Overview tab provides the following information: ++| **Detail** | **Description** | +|-|-| +| Status | The deployment status of the task. | +| Description | The description of the task. | +| Baseline | The baseline assigned to the tenant. | +| Category | The task category (for example, Identity, Devices, or Data). | +| Required services | The services that are required for completion of the task. | +| Management portal | The management portal where the configuration associated with the task is managed. | +| User impact | The impact of deploying the configuration associated with the task to the tenant's users. | +| For your users | Links to additional resources. | ++The Deployment progress tab provides user status associated with the task. Users are compliant when all settings are **Compliant** or **Extra,** and no settings are **Missing** or **Not Compliant**. No progress is reported for tasks that have been dismissed. ++## Related content ++[Deploy a task manually](m365-lighthouse-deploy-task-manually.md) (article)\ +[Deploy a task automatically](m365-lighthouse-deploy-task-automatically.md) (article)\ +[Dismiss a task](m365-lighthouse-dismiss-task.md) (article)\ +[Reinstate a task](m365-lighthouse-reinstate-task.md) (article)\ +[Overview of deployment tasks in Microsoft 365 Lighthouse](m365-lighthouse-overview-deployment-task.md) (article)\ +[Overview of using Microsoft 365 Lighthouse baselines to deploy standard tenant configurations](m365-lighthouse-deploy-standard-tenant-configurations-overview.md) (article)\ +[Overview of permissions in Microsoft 365 Lighthouse](m365-lighthouse-overview-of-permissions.md) (article)\ +[Configure Microsoft 365 Lighthouse portal security](m365-lighthouse-configure-portal-security.md) (article)\ +[Microsoft 365 Lighthouse FAQ](m365-lighthouse-faq.yml) (article) |
| security | Defender Endpoint False Positives Negatives | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/defender-endpoint-false-positives-negatives.md | ms.pagetype: security ms.localizationpriority: medium Previously updated : 10/24/2022 Last updated : 11/30/2022 audience: ITPro search.appverid: met150 **Applies to:** -- [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037)+- [Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) - Microsoft Defender Antivirus **Platforms** - Windows -In endpoint protection solutions, a false positive is an entity, such as a file or a process that was detected and identified as malicious even though the entity isn't actually a threat. A false negative is an entity that wasn't detected as a threat, even though it actually is malicious. False positives/negatives can occur with any threat protection solution, including [Microsoft Defender for Endpoint](microsoft-defender-endpoint.md). +In endpoint protection solutions, a false positive is an entity, such as a file or a process that was detected and identified as malicious even though the entity isn't actually a threat. A false negative is an entity that wasn't detected as a threat, even though it actually is malicious. False positives/negatives can occur with any threat protection solution, including [Defender for Endpoint](microsoft-defender-endpoint.md). -Fortunately, steps can be taken to address and reduce these kinds of issues. If you're seeing false positives/negatives in [Microsoft 365 Defender](/microsoft-365/security/defender/microsoft-365-defender), your security operations can take steps to address them by using the following process: +Fortunately, steps can be taken to address and reduce these kinds of issues. If you're seeing false positives/negatives occurring with Defender for Endpoint, your security operations can take steps to address them by using the following process: 1. [Review and classify alerts](#part-1-review-and-classify-alerts) 2. [Review remediation actions that were taken](#part-2-review-remediation-actions) You can get help if you still have issues with false positives/negatives after p :::image type="content" source="images/false-positives-step-diagram.png" alt-text="The steps to address false positives and negatives" lightbox="images/false-positives-step-diagram.png"::: > [!NOTE]-> This article is intended as guidance for security operators and security administrators who are using [Microsoft Defender for Endpoint](microsoft-defender-endpoint.md). +> This article is intended as guidance for security operators and security administrators who are using [Defender for Endpoint](microsoft-defender-endpoint.md). ## Part 1: Review and classify alerts -If you see an [alert](alerts.md) that arose because something's detected as malicious or suspicious and it shouldn't be, you can suppress the alert for that entity. You can also suppress alerts that aren't necessarily false positives, but are unimportant. We recommend that you classify alerts as well. +If you see an [alert](alerts.md) that arose because something's detected as malicious or suspicious and it shouldn't be, you can suppress the alert for that entity. You can also suppress alerts that aren't necessarily false positives, but are unimportant. We recommend that you also classify alerts. Managing your alerts and classifying true/false positives helps to train your threat protection solution and can reduce the number of false positives or false negatives over time. Taking these steps also helps reduce noise in your queue so that your security team can focus on higher priority work items. Managing your alerts and classifying true/false positives helps to train your th Before you classify or suppress an alert, determine whether the alert is accurate, a false positive, or benign. -1. Go to the Microsoft 365 Defender portal ([https://security.microsoft.com](https://security.microsoft.com)) and sign in. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), in the navigation pane, choose **Incidents & alerts** and then select **Alerts**. -2. In the navigation pane, choose **Incidents & alerts** and then select **Alerts**. +2. Select an alert to view more details about it. (To get help with this task, see [Review alerts in Defender for Endpoint](review-alerts.md).) -3. Select an alert to view more details about it. (See [Review alerts in Microsoft Defender for Endpoint](review-alerts.md).) --4. Depending on the alert status, take the steps described in the following table: +3. Depending on the alert status, take the steps described in the following table: |Alert status|What to do| ||| |The alert is accurate|Assign the alert, and then [investigate it](investigate-alerts.md) further.|- |The alert is a false positive|1. [Classify the alert](#classify-an-alert) as a false positive.<br/><br/>2. [Suppress the alert](#suppress-an-alert).<br/><br/>3. [Create an indicator](#indicators-for-microsoft-defender-for-endpoint) for Microsoft Defender for Endpoint.<br/><br/>4. [Submit a file to Microsoft for analysis](#part-4-submit-a-file-for-analysis).| + |The alert is a false positive|1. [Classify the alert](#classify-an-alert) as a false positive.<br/><br/>2. [Suppress the alert](#suppress-an-alert).<br/><br/>3. [Create an indicator](#indicators-for-defender-for-endpoint) for Microsoft Defender for Endpoint.<br/><br/>4. [Submit a file to Microsoft for analysis](#part-4-submit-a-file-for-analysis).| |The alert is accurate, but benign (unimportant)|[Classify the alert](#classify-an-alert) as a true positive, and then [suppress the alert](#suppress-an-alert).| ### Classify an alert -Alerts can be classified as false positives or true positives in Microsoft 365 Defender. Classifying alerts helps train Microsoft Defender for Endpoint so that, over time, you'll see more true alerts and fewer false alerts. --1. Go to the Microsoft 365 Defender portal ([https://security.microsoft.com](https://security.microsoft.com)) and sign in. +Alerts can be classified as false positives or true positives in the Microsoft 365 Defender portal. Classifying alerts helps train Defender for Endpoint so that over time, you'll see more true alerts and fewer false alerts. -2. In the navigation pane, choose **Incidents & alerts**, select **Alerts** and then select an alert. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), in the navigation pane, choose **Incidents & alerts**, select **Alerts** and then select an alert. -3. For the selected alert, select **Manage alert**. A flyout pane opens. +2. For the selected alert, select **Manage alert**. A flyout pane opens. -4. In the **Manage alert** section, in the **Classification** field, classify the alert (True positive, Informational, expected activity, or False positive). +3. In the **Manage alert** section, in the **Classification** field, classify the alert (True positive, Informational, expected activity, or False positive). > [!TIP]-> For more information about suppressing alerts, see [Manage Microsoft Defender for Endpoint alerts](/microsoft-365/security/defender-endpoint/manage-alerts). And, if your organization is using a security information and event management (SIEM) server, make sure to define a suppression rule there, too. +> For more information about suppressing alerts, see [Manage Defender for Endpoint alerts](/microsoft-365/security/defender-endpoint/manage-alerts). And, if your organization is using a security information and event management (SIEM) server, make sure to define a suppression rule there, too. ### Suppress an alert If you have alerts that are either false positives or that are true positives but for unimportant events, you can suppress those alerts in Microsoft 365 Defender. Suppressing alerts helps reduce noise in your queue. -1. Go to the Microsoft 365 Defender portal ([https://security.microsoft.com](https://security.microsoft.com)) and sign in. --2. In the navigation pane, choose **Incidents & alerts** and then select **Alerts**. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), in the navigation pane, choose **Incidents & alerts** and then select **Alerts**. -3. Select an alert that you want to suppress to open its **Details** pane. +2. Select an alert that you want to suppress to open its **Details** pane. -4. In the **Details** pane, choose the ellipsis (**...**), and then **Create suppression rule**. +3. In the **Details** pane, choose the ellipsis (**...**), and then **Create suppression rule**. -5. Specify all the settings for your suppression rule, and then choose **Save**. +4. Specify all the settings for your suppression rule, and then choose **Save**. > [!TIP] > Need help with suppression rules? See [Suppress an alert and create a new suppression rule](/microsoft-365/security/defender-endpoint/manage-alerts#suppress-an-alert-and-create-a-new-suppression-rule). When you're done reviewing and undoing actions that were taken as a result of fa ### Review completed actions -1. In the left navigation pane of the <a href="https://go.microsoft.com/fwlink/p/?linkid=2077139" target="_blank">Microsoft 365 Defender portal</a>, select **Actions & submissions** and then select **Action center**. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), select **Actions & submissions** and then select **Action center**. 2. Select the **History** tab to view a list of actions that were taken. When you're done reviewing and undoing actions that were taken as a result of fa ### Restore a quarantined file from the Action Center -1. In the left navigation pane of the Microsoft 365 Defender portal, select **Actions & submissions** and then select **Action center**. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), select **Actions & submissions** and then select **Action center**. 2. On the **History** tab, select an action that you want to undo. When you're done reviewing and undoing actions that were taken as a result of fa ### Undo multiple actions at one time -1. In the left navigation pane of the <a href="https://go.microsoft.com/fwlink/p/?linkid=2077139" target="_blank">Microsoft 365 Defender portal</a>, select **Actions & submissions** and then select **Action center**. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), select **Actions & submissions** and then select **Action center**. 2. On the **History** tab, select the actions that you want to undo. When you're done reviewing and undoing actions that were taken as a result of fa > [!div class="mx-imgBorder"] > :::image type="content" source="images/autoir-quarantine-file-1.png" alt-text="The Quarantine file" lightbox="images/autoir-quarantine-file-1.png"::: -1. In the left navigation pane of the <a href="https://go.microsoft.com/fwlink/p/?linkid=2077139" target="_blank">Microsoft 365 Defender portal</a>, select **Actions & submissions** and then select **Action center**. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), select **Actions & submissions** and then select **Action center**. 2. On the **History** tab, select a file that has the Action type **Quarantine file**. When you're done reviewing and undoing actions that were taken as a result of fa ### Review quarantined messages -1. Go to the Microsoft 365 Defender portal ([https://security.microsoft.com](https://security.microsoft.com)) and sign in. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), in the navigation pane, under **Email & collaboration**, select **Exchange message trace**. -2. In the navigation pane, under **Email & collaboration**, select **Exchange message trace**. --3. Select a message to view details. +2. Select a message to view details. ### Restore file from quarantine You can roll back and remove a file from quarantine if you've determined that it's clean after an investigation. Run the following command on each device where the file was quarantined. -1. Open an elevated command-line prompt on the device: +1. Open Command Prompt as an administrator on the device: 1. Go to **Start** and type _cmd_. 2. Right-click **Command prompt** and select **Run as administrator**. -2. Enter the following command, and press **Enter**: +2. Type the following command, and press **Enter**: ```console "%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Restore -Name EUS:Win32/CustomEnterpriseBlock -All You can roll back and remove a file from quarantine if you've determined that it > [!IMPORTANT] > In some scenarios, the **ThreatName** may appear as `EUS:Win32/CustomEnterpriseBlock!cl`. Defender for Endpoint will restore all custom blocked files that were quarantined on this device in the last 30 days.- > > A file that was quarantined as a potential network threat might not be recoverable. If a user attempts to restore the file after quarantine, that file might not be accessible. This can be due to the system no longer having network credentials to access the file. Typically, this is a result of a temporary log on to a system or shared folder and the access tokens expired. 3. In the pane on the right side of the screen, select **Apply to X more instances of this file**, and then select **Undo**. ## Part 3: Review or define exclusions +> [!CAUTION] +> Before you define an exclusion, review the detailed information in [Manage exclusions for Microsoft Defender for Endpoint and Microsoft Defender Antivirus](defender-endpoint-antivirus-exclusions.md). Keep in mind that every exclusion that is defined lowers your level of protection. + An exclusion is an entity, such as a file or URL, that you specify as an exception to remediation actions. The excluded entity can still get detected, but no remediation actions are taken on that entity. That is, the detected file or process won't be stopped, sent to quarantine, removed, or otherwise changed by Microsoft Defender for Endpoint. To define exclusions across Microsoft Defender for Endpoint, perform the following tasks: - [Define exclusions for Microsoft Defender Antivirus](#exclusions-for-microsoft-defender-antivirus)-- [Create "allow" indicators for Microsoft Defender for Endpoint](#indicators-for-microsoft-defender-for-endpoint)+- [Create "allow" indicators for Microsoft Defender for Endpoint](#indicators-for-defender-for-endpoint) > [!NOTE] > Microsoft Defender Antivirus exclusions apply only to antivirus protection, not across other Microsoft Defender for Endpoint capabilities. To exclude files broadly, use exclusions for Microsoft Defender Antivirus and [custom indicators](/microsoft-365/security/defender-endpoint/manage-indicators) for Microsoft Defender for Endpoint. The procedures in this section describe how to define exclusions and indicators. ### Exclusions for Microsoft Defender Antivirus -In general, you shouldn't need to define exclusions for Microsoft Defender Antivirus. Make sure that you define exclusions sparingly, and that you only include the files, folders, processes, and process-opened files that are resulting in false positives. In addition, make sure to review your defined exclusions regularly. We recommend using [Microsoft Endpoint Manager](/mem/endpoint-manager-overview) to define or edit your antivirus exclusions; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). +In general, you shouldn't need to define exclusions for Microsoft Defender Antivirus. Make sure that you define exclusions sparingly, and that you only include the files, folders, processes, and process-opened files that are resulting in false positives. In addition, make sure to review your defined exclusions regularly. We recommend using [Microsoft Intune](/mem/intune/fundamentals/what-is-intune) to define or edit your antivirus exclusions; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). > [!TIP] > Need help with antivirus exclusions? See [Configure and validate exclusions for Microsoft Defender Antivirus scans](configure-exclusions-microsoft-defender-antivirus.md). -#### Use Microsoft Endpoint Manager to manage antivirus exclusions (for existing policies) +#### Use Intune to manage antivirus exclusions (for existing policies) -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Endpoint security** \> **Antivirus**, and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-intune-to-create-a-new-antivirus-policy-with-exclusions)). -2. Choose **Endpoint security** \> **Antivirus**, and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-microsoft-endpoint-manager-to-create-a-new-antivirus-policy-with-exclusions)). +2. Choose **Properties**, and next to **Configuration settings**, choose **Edit**. -3. Choose **Properties**, and next to **Configuration settings**, choose **Edit**. +3. Expand **Microsoft Defender Antivirus Exclusions** and then specify your exclusions. -4. Expand **Microsoft Defender Antivirus Exclusions** and then specify your exclusions. +4. Choose **Review + save**, and then choose **Save**. -5. Choose **Review + save**, and then choose **Save**. +#### Use Intune to create a new antivirus policy with exclusions -#### Use Microsoft Endpoint Manager to create a new antivirus policy with exclusions +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Endpoint security** \> **Antivirus** \> **+ Create Policy**. -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +2. Select a platform (such as **Windows 10 and later**, **macOS**, or **Windows 10 and Windows Server**). -2. Choose **Endpoint security** \> **Antivirus** \> **+ Create Policy**. +3. For **Profile**, select **Microsoft Defender Antivirus exclusions**, and then choose **Create**. -3. Select a platform (such as **Windows 10 and later**, **macOS**, or **Windows 10 and Windows Server**). +4. Specify a name and description for the profile, and then choose **Next**. -4. For **Profile**, select **Microsoft Defender Antivirus exclusions**, and then choose **Create**. +5. On the **Configuration settings** tab, specify your antivirus exclusions, and then choose **Next**. -5. Specify a name and description for the profile, and then choose **Next**. +6. On the **Scope tags** tab, if you're using scope tags in your organization, specify scope tags for the policy you're creating. (See [Scope tags](/mem/intune/fundamentals/scope-tags).) -6. On the **Configuration settings** tab, specify your antivirus exclusions, and then choose **Next**. --7. On the **Scope tags** tab, if you're using scope tags in your organization, specify scope tags for the policy you're creating. (See [Scope tags](/mem/intune/fundamentals/scope-tags).) --8. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) +7. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) -9. On the **Review + create** tab, review the settings, and then choose **Create**. +8. On the **Review + create** tab, review the settings, and then choose **Create**. -### Indicators for Microsoft Defender for Endpoint +### Indicators for Defender for Endpoint [Indicators](/microsoft-365/security/defender-endpoint/manage-indicators) (specifically, indicators of compromise, or IoCs) enable your security operations team to define the detection, prevention, and exclusion of entities. For example, you can specify certain files to be omitted from scans and remediation actions in Microsoft Defender for Endpoint. Or, indicators can be used to generate alerts for certain files, IP addresses, or URLs. -To specify entities as exclusions for Microsoft Defender for Endpoint, create "allow" indicators for those entities. Such "allow" indicators in Microsoft Defender for Endpoint apply to [next-generation protection](microsoft-defender-antivirus-in-windows-10.md), [endpoint detection and response](overview-endpoint-detection-response.md), and [automated investigation & remediation](/microsoft-365/security/defender-endpoint/automated-investigations). +To specify entities as exclusions for Defender for Endpoint, create "allow" indicators for those entities. Such "allow" indicators apply to [next-generation protection](microsoft-defender-antivirus-in-windows-10.md) and [automated investigation & remediation](/microsoft-365/security/defender-endpoint/automated-investigations). "Allow" indicators can be created for: Before you create indicators for files, make sure the following requirements are - Microsoft Defender Antivirus is configured with cloud-based protection enabled (see [Manage cloud-based protection](/windows/security/threat-protection/microsoft-defender-antivirus/deploy-manage-report-microsoft-defender-antivirus)) - Antimalware client version is 4.18.1901.x or later-- Devices are running Windows 10, version 1703 or later, or Windows 11; Windows Server 2016, or Windows Server 2019, or Windows Server 2022+- Devices are running Windows 10, version 1703 or later, or Windows 11; Windows Server 2012 R2 and Windows Server 2016 with the [modern unified solution in Defender for Endpoint](configure-server-endpoints.md#windows-server-2012-r2-and-windows-server-2016), or Windows Server 2019, or Windows Server 2022 - The [Block or allow feature is turned on](/microsoft-365/security/defender-endpoint/advanced-features) #### Indicators for IP addresses, URLs, or domains Before you create indicators for application certificates, make sure the followi - Microsoft Defender Antivirus is configured with cloud-based protection enabled (see [Manage cloud-based protection](deploy-manage-report-microsoft-defender-antivirus.md) - Antimalware client version is 4.18.1901.x or later-- Devices are running Windows 10, version 1703 or later, or Windows 11; Windows Server 2016, or Windows Server 2019, or Windows Server 2022+- Devices are running Windows 10, version 1703 or later, or Windows 11; Windows Server 2012 R2 and Windows Server 2016 with the [modern unified solution in Defender for Endpoint](configure-server-endpoints.md#windows-server-2012-r2-and-windows-server-2016), or Windows Server 2019, or Windows Server 2022 - Virus and threat protection definitions are up to date > [!TIP] Before you create indicators for application certificates, make sure the followi ## Part 4: Submit a file for analysis -You can submit entities, such as files and fileless detections, to Microsoft for analysis. Microsoft security researchers analyze all submissions, and their results help inform Microsoft Defender for Endpoint threat protection capabilities. When you sign in at the submission site, you can track your submissions. +You can submit entities, such as files and fileless detections, to Microsoft for analysis. Microsoft security researchers analyze all submissions, and their results help inform Defender for Endpoint threat protection capabilities. When you sign in at the submission site, you can track your submissions. ### Submit a file for analysis If you have a file that was either wrongly detected as malicious or was missed, 1. Review the guidelines here: [Submit files for analysis](/windows/security/threat-protection/intelligence/submission-guide). -2. Visit the [Microsoft Security Intelligence submission site](https://www.microsoft.com/wdsi/filesubmission) (https://www.microsoft.com/wdsi/filesubmission), and submit your file(s). +2. [Submit files in Defender for Endpoint](admin-submissions-mde.md) or visit the [Microsoft Security Intelligence submission site](https://www.microsoft.com/wdsi/filesubmission/) and submit your files. ### Submit a fileless detection for analysis If something was detected as malware based on behavior, and you don't have a file, you can submit your `Mpsupport.cab` file for analysis. You can get the *.cab* file by using the Microsoft Malware Protection Command-Line Utility (MPCmdRun.exe) tool on Windows 10 or Windows 11. -1. Go to ` C:\ProgramData\Microsoft\Windows Defender\Platform\<version>`, and then run `MpCmdRun.exe` as an administrator. +1. Go to `C:\ProgramData\Microsoft\Windows Defender\Platform\<version>`, and then run `MpCmdRun.exe` as an administrator. 2. Type `mpcmdrun.exe -GetFiles`, and then press **Enter**. To check for updates regarding your submission, sign in at the [Microsoft Securi ## Part 5: Review and adjust your threat protection settings -Microsoft Defender for Endpoint offers a wide variety of options, including the ability to fine-tune settings for various features and capabilities. If you're getting numerous false positives, make sure to review your organization's threat protection settings. You might need to make some adjustments to: +Defender for Endpoint offers a wide variety of options, including the ability to fine-tune settings for various features and capabilities. If you're getting numerous false positives, make sure to review your organization's threat protection settings. You might need to make some adjustments to: - [Cloud-delivered protection](#cloud-delivered-protection) - [Remediation for potentially unwanted applications](#remediation-for-potentially-unwanted-applications) Check your cloud-delivered protection level for Microsoft Defender Antivirus. By > [!TIP] > To learn more about configuring your cloud-delivered protection, see [Specify the cloud-delivered protection level](/windows/security/threat-protection/microsoft-defender-antivirus/specify-cloud-protection-level-microsoft-defender-antivirus). -We recommend using [Microsoft Endpoint Manager](/mem/endpoint-manager-overview) to edit or set your cloud-delivered protection settings; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). --#### Use Microsoft Endpoint Manager to review and edit cloud-delivered protection settings (for existing policies) +We recommend using [Intune](/mem/intune/fundamentals/what-is-intune) to edit or set your cloud-delivered protection settings; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +#### Use Intune to review and edit cloud-delivered protection settings (for existing policies) -2. Choose **Endpoint security** \> **Antivirus** and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-microsoft-endpoint-manager-to-set-cloud-delivered-protection-settings-for-a-new-policy)). +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Endpoint security** \> **Antivirus** and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-intune-to-set-cloud-delivered-protection-settings-for-a-new-policy)). -3. Under **Manage**, select **Properties**. Then, next to **Configuration settings**, choose **Edit**. +2. Under **Manage**, select **Properties**. Then, next to **Configuration settings**, choose **Edit**. -4. Expand **Cloud protection**, and review your current setting in the **Cloud-delivered protection level** row. We recommend setting cloud-delivered protection to **Not configured**, which provides strong protection while reducing the chances of getting false positives. +3. Expand **Cloud protection**, and review your current setting in the **Cloud-delivered protection level** row. We recommend setting cloud-delivered protection to **Not configured**, which provides strong protection while reducing the chances of getting false positives. -5. Choose **Review + save**, and then **Save**. +4. Choose **Review + save**, and then **Save**. -#### Use Microsoft Endpoint Manager to set cloud-delivered protection settings (for a new policy) +#### Use Intune to set cloud-delivered protection settings (for a new policy) -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Endpoint security** \> **Antivirus** \> **+ Create policy**. -2. Choose **Endpoint security** \> **Antivirus** \> **+ Create policy**. +2. For **Platform**, select an option, and then for **Profile**, select **Antivirus** or **Microsoft Defender Antivirus** (the specific option depends on what you selected for **Platform**.) Then choose **Create**. -3. For **Platform**, select an option, and then for **Profile**, select **Antivirus** or **Microsoft Defender Antivirus** (the specific option depends on what you selected for **Platform**.) Then choose **Create**. +3. On the **Basics** tab, specify a name and description for the policy. Then choose **Next**. -4. On the **Basics** tab, specify a name and description for the policy. Then choose **Next**. --5. On the **Configuration settings** tab, expand **Cloud protection**, and specify the following settings: +4. On the **Configuration settings** tab, expand **Cloud protection**, and specify the following settings: - Set **Turn on cloud-delivered protection** to **Yes**. - Set **Cloud-delivered protection level** to **Not configured**. (This level provides a strong level of protection by default while reducing the chances of getting false positives.) -6. On the **Scope tags** tab, if you're using scope tags in your organization, specify scope tags for the policy. (See [Scope tags](/mem/intune/fundamentals/scope-tags).) +5. On the **Scope tags** tab, if you're using scope tags in your organization, specify scope tags for the policy. (See [Scope tags](/mem/intune/fundamentals/scope-tags).) -7. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) +6. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) -8. On the **Review + create** tab, review the settings, and then choose **Create**. +7. On the **Review + create** tab, review the settings, and then choose **Create**. ### Remediation for potentially unwanted applications Potentially unwanted applications (PUA) are a category of software that can caus Depending on the apps your organization is using, you might be getting false positives as a result of your PUA protection settings. If necessary, consider running PUA protection in audit mode for a while, or apply PUA protection to a subset of devices in your organization. PUA protection can be configured for the Microsoft Edge browser and for Microsoft Defender Antivirus. -We recommend using [Microsoft Endpoint Manager](/mem/endpoint-manager-overview) to edit or set PUA protection settings; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). +We recommend using [Intune](/mem/endpoint-manager-overview) to edit or set PUA protection settings; however, you can use other methods, such as [Group Policy](/azure/active-directory-domain-services/manage-group-policy) (see [Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md). -#### Use Microsoft Endpoint Manager to edit PUA protection (for existing configuration profiles) +#### Use Intune to edit PUA protection (for existing configuration profiles) -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Devices** \> **Configuration profiles**, and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-intune-to-set-pua-protection-for-a-new-configuration-profile).) -2. Choose **Devices** \> **Configuration profiles**, and then select an existing policy. (If you don't have an existing policy, or you want to create a new policy, skip to [the next procedure](#use-microsoft-endpoint-manager-to-set-pua-protection-for-a-new-configuration-profile).) --3. Under **Manage**, choose **Properties**, and then, next to **Configuration settings**, choose **Edit**. --4. On the **Configuration settings** tab, scroll down and expand **Microsoft Defender Antivirus**. +2. Under **Manage**, choose **Properties**, and then, next to **Configuration settings**, choose **Edit**. -5. Set **Detect potentially unwanted applications** to **Audit**. (You can turn it off, but by using audit mode, you'll be able to see detections.) +3. On the **Configuration settings** tab, scroll down and expand **Microsoft Defender Antivirus**. -6. Choose **Review + save**, and then choose **Save**. +4. Set **Detect potentially unwanted applications** to **Audit**. (You can turn it off, but by using audit mode, you'll be able to see detections.) -#### Use Microsoft Endpoint Manager to set PUA protection (for a new configuration profile) +5. Choose **Review + save**, and then choose **Save**. -1. Go to the Microsoft Endpoint Manager admin center (<https://endpoint.microsoft.com>) and sign in. +#### Use Intune to set PUA protection (for a new configuration profile) -2. Choose **Devices** \> **Configuration profiles** \> **+ Create profile**. +1. In the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com), choose **Devices** \> **Configuration profiles** \> **+ Create profile**. -3. For the **Platform**, choose **Windows 10 and later**, and for **Profile**, select **Device restrictions**. +2. For the **Platform**, choose **Windows 10 and later**, and for **Profile**, select **Device restrictions**. -4. On the **Basics** tab, specify a name and description for your policy. Then choose **Next**. +3. On the **Basics** tab, specify a name and description for your policy. Then choose **Next**. -5. On the **Configuration settings** tab, scroll down and expand **Microsoft Defender Antivirus**. +4. On the **Configuration settings** tab, scroll down and expand **Microsoft Defender Antivirus**. -6. Set **Detect potentially unwanted applications** to **Audit**, and then choose **Next**. (You can turn off PUA protection, but by using audit mode, you'll be able to see detections.) +5. Set **Detect potentially unwanted applications** to **Audit**, and then choose **Next**. (You can turn off PUA protection, but by using audit mode, you'll be able to see detections.) -7. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) +6. On the **Assignments** tab, specify the users and groups to whom your policy should be applied, and then choose **Next**. (If you need help with assignments, see [Assign user and device profiles in Microsoft Intune](/mem/intune/configuration/device-profile-assign).) -8. On the **Applicability Rules** tab, specify the OS editions or versions to include or exclude from the policy. For example, you can set the policy to be applied to all devices certain editions of Windows 10. Then choose **Next**. +7. On the **Applicability Rules** tab, specify the OS editions or versions to include or exclude from the policy. For example, you can set the policy to be applied to all devices certain editions of Windows 10. Then choose **Next**. -9. On the **Review + create** tab, review your settings, and, and then choose **Create**. +8. On the **Review + create** tab, review your settings, and, and then choose **Create**. ### Automated investigation and remediation Depending on the [level of automation](/microsoft-365/security/defender-endpoint - [Configure AIR capabilities in Defender for Endpoint](/microsoft-365/security/defender-endpoint/configure-automated-investigations-remediation). > [!IMPORTANT]-> We recommend using *Full automation* for automated investigation and remediation. Don't turn these capabilities off because of a false positive. Instead, use ["allow" indicators to define exceptions](#indicators-for-microsoft-defender-for-endpoint), and keep automated investigation and remediation set to take appropriate actions automatically. Following [this guidance](automation-levels.md#levels-of-automation) helps reduce the number of alerts your security operations team must handle. +> We recommend using *Full automation* for automated investigation and remediation. Don't turn these capabilities off because of a false positive. Instead, use ["allow" indicators to define exceptions](#indicators-for-defender-for-endpoint), and keep automated investigation and remediation set to take appropriate actions automatically. Following [this guidance](automation-levels.md#levels-of-automation) helps reduce the number of alerts your security operations team must handle. ## Still need help? If you've worked through all the steps in this article and still need help, contact technical support. -1. Go to <a href="https://go.microsoft.com/fwlink/p/?linkid=2077139" target="_blank">Microsoft 365 Defender</a> and sign in. +1. In the [Microsoft 365 Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2077139), in the upper right corner, select the question mark (**?**), and then select **Microsoft support**. -2. In the upper right corner, select the question mark (**?**), and then select **Microsoft support**. --3. In the **Support Assistant** window, describe your issue, and then send your message. From there, you can open a service request. +2. In the **Support Assistant** window, describe your issue, and then send your message. From there, you can open a service request. > [!TIP] > If you're looking for Antivirus related information for other platforms, see: If you've worked through all the steps in this article and still need help, cont ## See also -[Manage Microsoft Defender for Endpoint](manage-mde-post-migration.md) --[Overview of Microsoft 365 Defender portal](/microsoft-365/security/defender-endpoint/use) +- [Manage Defender for Endpoint](manage-mde-post-migration.md) +- [Manage exclusions for Microsoft Defender for Endpoint and Microsoft Defender Antivirus](defender-endpoint-antivirus-exclusions.md) +- [Overview of Microsoft 365 Defender portal](/microsoft-365/security/defender-endpoint/use) |
| security | Deploy Manage Removable Storage Group Policy | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-group-policy.md | search.appverid: met150 # Deploy and manage Removable Storage Access Control using group policy **Applies to:**+- [Microsoft Defender for Endpoint Plan 1](https://go.microsoft.com/fwlink/p/?linkid=2154037) - [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) > [!NOTE] |
| security | Deploy Manage Removable Storage Intune | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-intune.md | search.appverid: met150 # Deploy and manage Removable Storage Access Control using Intune **Applies to:**+- [Microsoft Defender for Endpoint Plan 1](https://go.microsoft.com/fwlink/p/?linkid=2154037) - [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) > [!NOTE] |
| security | Device Control Removable Storage Access Control Faq | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/device-control-removable-storage-access-control-faq.md | search.appverid: met150 # Microsoft Defender for Endpoint Device Control Removable Storage frequently asked questions **Applies to:**+- [Microsoft Defender for Endpoint Plan 1](https://go.microsoft.com/fwlink/p/?linkid=2154037) - [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) This article provides answers to frequently asked questions about device control removable storage capabilities in Microsoft Defender for Endpoint. |
| security | Device Control Removable Storage Access Control | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/device-control-removable-storage-access-control.md | search.appverid: met150 # Microsoft Defender for Endpoint Device Control Removable Storage Access Control **Applies to:**+- [Microsoft Defender for Endpoint Plan 1](https://go.microsoft.com/fwlink/p/?linkid=2154037) - [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) > [!NOTE] The following table lists the properties you can use in **Entry**: |||| | **Entry Id** | GUID, a unique ID, represents the entry and will be used in the reporting and troubleshooting.| You can generate ID through [PowerShell](/powershell/module/microsoft.powershell.utility/new-guid)| | **Type** | Defines the action for the removable storage groups in IncludedIDList. <p>Enforcement: Allow or Deny <p>Audit: AuditAllowed or AuditDenied<p> | Allow<p>Deny <p>AuditAllowed: Defines notification and event when access is allowed <p>AuditDenied: Defines notification and event when access is denied; has to work together with **Deny** entry.<p> When there are conflict types for the same media, the system will apply the first one in the policy. An example of a conflict type is **Allow** and **Deny**. |-| **SID** | Local user SID or user SID group or the SID of the AD object or the Object ID of the Azure AD object, defines whether to apply this policy over a specific user or user group. One entry can have a maximum of one SID and an entry without any SID means to apply the policy over the machine. | | -| **ComputerSID** | Local computer SID or computer SID group or the SID of the AD object or the Object Id of the AAD object, defines whether to apply this policy over a specific machine or machine group. One entry can have a maximum of one ComputerSID and an entry without any ComputerSID means to apply the policy over the machine. If you want to apply an Entry to a specific user and specific machine, add both SID and ComputerSID into the same Entry. | | +| **Sid** | Local user Sid or user Sid group or the Sid of the AD object or the Object ID of the Azure AD object, defines whether to apply this policy over a specific user or user group. One entry can have a maximum of one SID and an entry without any SID means to apply the policy over the machine. | | +| **ComputerSid** | Local computer Sid or computer Sid group or the Sid of the AD object or the Object Id of the AAD object, defines whether to apply this policy over a specific machine or machine group. One entry can have a maximum of one ComputerSID and an entry without any ComputerSID means to apply the policy over the machine. If you want to apply an Entry to a specific user and specific machine, add both SID and ComputerSID into the same Entry. | | | **Options** | Defines whether to display notification or not |**When Type Allow is selected**: <p>0: nothing<p>4: disable **AuditAllowed** and **AuditDenied** for this Entry. Even if **Allow** happens and the AuditAllowed is setting configured, the system won't send event. <p>8: capture file information and have a copy of the file as evidence for Write access. <p>16: capture file information for Write access. <p>**When Type Deny is selected**: <p>0: nothing<p>4: disable **AuditDenied** for this Entry. Even if **Block** happens and the AuditDenied is setting configured, the system won't show notification. <p>**When Type **AuditAllowed** is selected**: <p>0: nothing <p>1: nothing <p>2: send event<p> **When Type **AuditDenied** is selected**: <p>0: nothing <p>1: show notification <p>2: send event<p>3: show notification and send event | |AccessMask|Defines the access. | **Disk level access**: <p>1: Read <p>2: Write <p>4: Execute <p>**File system level access**: <p>8: File system Read <p>16: File system Write <p>32: File system Execute <p><p>You can have multiple access by performing binary OR operation, for example, the AccessMask for Read and Write and Execute will be 7; the AccessMask for Read and Write will be 3.| |Parameters|Condition for this Entry, for example Network condition. | Can add groups (non Devices type) or even put Parameters into Parameters. See Parameters properties table below to get details.| |
| security | Device Control Report | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/device-control-report.md | ms.mktglfcycl: deploy ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium Last updated : 11/30/2022 search.appverid: met150 # Device control report **Applies to:** +- [Microsoft Defender for Endpoint Plan 1](https://go.microsoft.com/fwlink/p/?linkid=2154037) - [Microsoft Defender for Endpoint Plan 2](https://go.microsoft.com/fwlink/p/?linkid=2154037) Microsoft Defender for Endpoint device control protects against data loss by monitoring and controlling media use by devices in your organization, such as using removable storage devices and USB drives. |
| security | Ios Configure Features | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/ios-configure-features.md | This configuration is available for both the enrolled (MDM) devices as well as u ## Configure Network Protection -Network protection in Microsoft Defender for endpoint is disabled by default. Admins can use the following steps to configure MAM support for Network protection in iOS devices. (Authenticator device registration is required for MAM configuration) in iOS devices. Network Protection initialization will require the end user to open the app once. +Network protection in Microsoft Defender for endpoint is disabled by default. Admins can use the following steps to configure MAM support for network protection in iOS devices. (Authenticator device registration is required for MAM configuration) in iOS devices. Network protection initialization will require the end user to open the app once. -1. In Microsoft Endpoint Manager Admin, navigate to Apps > App configuration policies. Create a new App configuration policy. +1. In the Microsoft Endpoint Manager admin center, navigate to **Apps** > **App configuration policies** > **Add** > **Managed apps**. Create a new App configuration policy. :::image type="content" source="images/addiosconfig.png" alt-text="Add configuration policy." lightbox="images/addiosconfig.png"::: -2. Provide a name and description to uniquely identify the policy. Then click on 'Select Public apps' and choose 'Microsoft Defender' for Platform iOS/IPadOS +2. Provide a name and description to uniquely identify the policy. Then select **Select Public apps**, and choose **Microsoft Defender for Platform iOS/iPadOS** :::image type="content" source="images/nameiosconfig.png" alt-text="Name the configuration." lightbox="images/nameiosconfig.png"::: -3. In the Settings page, add 'DefenderNetworkProtectionEnable' as the key and the value as 'true' to enable Network Protection. (Network protection is disabled by default.) +3. On the Settings page, add **DefenderNetworkProtectionEnable** as the key and the value as `true` to enable network protection. (Network protection is disabled by default.) :::image type="content" source="images/addiosconfigvalue.png" alt-text="Add configuration value." lightbox="images/addiosconfigvalue.png"::: -4. For other configurations related to Network protection, add the following keys and appropriate corresponding value. +4. For other configurations related to network protection, add the following keys and appropriate corresponding value. |Key| Default (true-enable, false-disable)|Description| ||||- |DefenderOpenNetworkDetection|0|1- Enable, 0 - Disable; This setting is managed by IT Admin to enable or disable open network detection informational alerts with no end user detection experience| - |DefenderEndUserTrustFlowEnable| false | Enable Users to Trust Networks and Certificates| - |DefenderNetworkProtectionAutoRemediation| true |This setting is used by the IT admin to enable or disable the remediation alerts that are sent when a user performs remediation activities like switching to safer WIFI access points or deleting suspicious certificates detected by Defender| - |DefenderNetworkProtectionPrivacy| true |This setting is managed by IT admin to enable or disable privacy in network protection| + |`DefenderOpenNetworkDetection`|0|1- Enable, 0 - Disable; This setting is managed by IT Admin to enable or disable open network detection informational alerts with no end user detection experience| + |`DefenderEndUserTrustFlowEnable`| false | Enable Users to Trust Networks and Certificates| + |`DefenderNetworkProtectionAutoRemediation`| true |This setting is used by the IT admin to enable or disable the remediation alerts that are sent when a user performs remediation activities like switching to safer WIFI access points or deleting suspicious certificates detected by Defender| + |`DefenderNetworkProtectionPrivacy`| true |This setting is managed by IT admin to enable or disable privacy in network protection| -5. In Assignments section, admin can choose groups of users to include and exclude from the policy. +5. In the **Assignments** section, an admin can choose groups of users to include and exclude from the policy. :::image type="content" source="images/assigniosconfig.png" alt-text="Assign configuration." lightbox="images/assigniosconfig.png"::: 6. Review and create the configuration policy. Microsoft Defender for Endpoint can be configured to send threat signals to be u Steps to set up app protection policies with Microsoft Defender for Endpoint are below: -1. Set up the connection from your Microsoft Endpoint Manager tenant to Microsoft Defender for Endpoint. In [Microsoft Endpoint manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Tenant Administration** \> **Connectors and tokens** \> **Microsoft Defender for Endpoint** (under Cross platform) or **Endpoint Security** \> **Microsoft Defender for Endpoint** (under Setup) and turn on the toggles under **App Protection Policy Settings for iOS**. +1. Set up the connection from your Microsoft Endpoint Manager tenant to Microsoft Defender for Endpoint. In the [Microsoft Endpoint manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Tenant Administration** \> **Connectors and tokens** \> **Microsoft Defender for Endpoint** (under Cross platform) or **Endpoint Security** \> **Microsoft Defender for Endpoint** (under Setup) and turn on the toggles under **App Protection Policy Settings for iOS**. -2. Select Save. You should see **Connection status** is now set to **Enabled**. +2. Select **Save**. You should see **Connection status** is now set to **Enabled**. -3. Create app protection policy: After your Microsoft Defender for Endpoint connector setup is complete, navigate to **Apps** \> **App protection policies** (under Policy) to create a new policy or update an existing one. +3. Create app protection policy. After your Microsoft Defender for Endpoint connector setup is complete, navigate to **Apps** \> **App protection policies** (under Policy) to create a new policy or update an existing one. 4. Select the platform, **Apps, Data protection, Access requirements** settings that your organization requires for your policy. 5. Under **Conditional launch** \> **Device conditions**, you will find the setting **Max allowed device threat level**. This will need to be configured to either Low, Medium, High, or Secured. The actions available to you will be **Block access** or **Wipe data**. You may see an informational dialog to make sure you have your connector set up prior to this setting take effect. If your connector is already set up, you may ignore this dialog. -6. Finish with Assignments and save your policy. +6. Finish with assignments and save your policy. For more details on MAM or app protection policy, see [iOS app protection policy settings](/mem/intune/apps/app-protection-policy-settings-ios). Microsoft Defender for Endpoint on iOS enables the App Protection Policy scenari ## Privacy Controls Microsoft Defender for Endpoint on iOS enables Privacy Controls for both the Admins and the End Users. This includes the controls for enrolled (MDM) as well as unenrolled (MAM) devices.+ For Customers with MDM, admins can configure the Privacy Controls through Managed devices in the App Config. For Customers without enrollment, using MAM, admins can configure the Privacy Controls through Managed apps in the App Config. End Users will also have the ability to configure the Privacy Settings from the Defender App settings. ### Configure privacy in phish alert report Customers can now enable privacy control for the phish report sent by Microsoft 1. **Admin Privacy Controls (MDM)** Use the following steps to enable privacy and not collect the domain name as part of the phish alert report for enrolled devices. - - In [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. + - In the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. - Give the policy a name, **Platform > iOS/iPadOS**, select the profile type. - Select **Microsoft Defender for Endpoint** as the target app. - - In Settings page, select **Use configuration designer** and add **DefenderExcludeURLInReport** as the key and value type as **Boolean**. + - On the Settings page, select **Use configuration designer** and add **DefenderExcludeURLInReport** as the key and value type as **Boolean**. - - To enable privacy and not collect the domain name, enter value as `true` and assign this policy to users. By default, this value is set to `false`. + - To enable privacy and not collect the domain name, enter the value as `true` and assign this policy to users. By default, this value is set to `false`. - For users with key set as `true`, the phish alert will not contain the domain name information whenever a malicious site is detected and blocked by Defender for Endpoint. - - Click **Next** and assign this profile to targeted devices/users. + - Select **Next** and assign this profile to targeted devices/users. 1. **Admin Privacy Controls (MAM)** Use the following steps to enable privacy and not collect the domain name as part of the phish alert report for unenrolled devices. Customers can now enable privacy control for the phish report sent by Microsoft - Give the policy a name. - - Under the Select Public Apps, choose **Microsoft Defender for Endpoint** as the target app. + - Under **Select Public Apps**, choose **Microsoft Defender for Endpoint** as the target app. - - In Settings page, under the **General Configuration Settings** add **DefenderExcludeURLInReport** as the key and value as **true**. + - On the Settings page, under the **General Configuration Settings**, add **DefenderExcludeURLInReport** as the key and value as `true`. - - To enable privacy and not collect the domain name, enter value as `true` and assign this policy to users. By default, this value is set to `false`. + - To enable privacy and not collect the domain name, enter the value as `true` and assign this policy to users. By default, this value is set to `false`. - For users with key set as `true`, the phish alert will not contain the domain name information whenever a malicious site is detected and blocked by Defender for Endpoint. - - Click **Next** and assign this profile to targeted devices/users. + - Select **Next** and assign this profile to targeted devices/users. 1. **End User Privacy Controls** These controls help the end user to configure the information shared to their organization. - For Supervised devices, End User controls will not be visible. Admin will decide and controls the settings. Microsoft Defender for Endpoint on iOS enables **Optional Permissions** in the o 1. **Admin flow (MDM)** Use the following steps to enable **Optional VPN** permission for enrolled devices. - - In [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. + - In the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. - Give the policy a name, select **Platform > iOS/iPadOS**. - Select **Microsoft Defender for Endpoint** as the target app. - - In Settings page, select **Use configuration designer** and add **DefenderOptionalVPN** as the key and value type as **Boolean**. + - On the Settings page, select **Use configuration designer** and add **DefenderOptionalVPN** as the key and value type as **Boolean**. - To enable optional VPN permission, enter value as `true` and assign this policy to users. By default, this value is set to `false`. - For users with key set as `true`, the users will be able to onboard the app without giving the VPN permission. - - Click **Next** and assign this profile to targeted devices/users. + - Select **Next** and assign this profile to targeted devices/users. + 1. **End User flow** - User will install and open the app to start the onboarding.- - If admin has setup Optional permissions, then user can **Skip** VPN permission and complete onboarding. - - Even if the user has skipped VPN, the device will be able to onboard, and heartbeat will be sent. - - Since `VPN` is disabled, `Web Protection` will not be active. - - Later, User can enable the `Web Protection` from within the App. This will install the VPN configuration on the device. + - If an admin has set up optional permissions, then the user can **Skip** VPN permission and complete onboarding. + - Even if the user has skipped VPN, the device will be able to onboard, and a heartbeat will be sent. + - If VPN is disabled, web protection will not be active. + - Later, the user can enable web protection from within the app. This will install the VPN configuration on the device. > [!NOTE]->**Optional Permission** is different from **Disable Web Protection**. Optional VPN Permission only helps to skip the permission during onboarding but its available for the end user to later review and enable it. While **Disable Web Protection** allows users to onboard the Defender for Endpoint app without the Web Protection. It cannot be enabled later. +> **Optional Permission** is different from **Disable Web Protection**. Optional VPN Permission only helps to skip the permission during onboarding but its available for the end user to later review and enable it. While **Disable Web Protection** allows users to onboard the Defender for Endpoint app without the Web Protection. It cannot be enabled later. ## Configure compliance policy against jailbroken devices To protect corporate data from being accessed on jailbroken iOS devices, we reco Follow the steps below to create a compliance policy against jailbroken devices. -1. In [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Devices** > **Compliance policies** > **Create Policy**. Select "iOS/iPadOS" as platform and click **Create**. +1. In the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Devices** > **Compliance policies** > **Create Policy**. Select "iOS/iPadOS" as platform and click **Create**. :::image type="content" source="images/ios-jb-policy.png" alt-text="The Create Policy tab" lightbox="images/ios-jb-policy.png"::: Defender for Endpoint on iOS enables admins to configure custom indicators on iO ## Configure vulnerability assessment of apps ->[!Note] ->Vulnerability Assessment of apps on Microsoft Defender for Endpoint for iOS is now in public preview. The following information relates to the prerelease of the product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. If you are interested to participate in the preview, please share your Tenant name and id with us on **mdatpmobile@microsoft.com**. +> [!NOTE] +> Vulnerability Assessment of apps on Microsoft Defender for Endpoint for iOS is now in public preview. The following information relates to the prerelease of the product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. If you are interested to participate in the preview, please share your Tenant name and id with us on **mdatpmobile@microsoft.com**. Defender for Endpoint on iOS supports vulnerability assessments of apps only for enrolled (MDM) devices. Admins can use the following steps to configure the vulnerability assessment of ### On a Supervised Device 1. Ensure the device is configured in the [Supervised mode](ios-install.md#complete-deployment-for-supervised-devices).+ 1. To enable the feature in [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Endpoint Security** > **Microsoft Defender for Endpoint** > **Enable App sync for iOS/iPadOS devices**. :::image type="content" source="images/tvm-app-sync-toggle.png" alt-text="App sync toggleSup" lightbox="images/tvm-app-sync-toggle.png"::: Admins can use the following steps to configure the vulnerability assessment of - For users with key set as `False`, Defender for Endpoint will send the list of apps installed on the device for vulnerability assessment. - Click **Next** and assign this profile to targeted devices/users. - Turning the above privacy controls on or off will not impact the device compliance check or conditional access.+ 1. Once the config is applied, end-user will need to open the app to **Approve** the privacy setting. - Privacy approval screen will come only for unsupervised devices. - Only if end-user approves the privacy, the app information will be sent to the Defender for Endpoint console. Customers now have the option to configure the ability to send feedback data to Use the following steps to configure the option to send feedback data to Microsoft: -1. In [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. +1. In the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Apps** > **App configuration policies** > **Add** > **Managed devices**. -1. Give the policy a name, **Platform > iOS/iPadOS**, select the profile type. +1. Give the policy a name, and select **Platform > iOS/iPadOS** as the profile type. 1. Select **Microsoft Defender for Endpoint** as the target app. -1. In Settings page, select **Use configuration designer** and add **DefenderSendFeedback** as the key and value type as **Boolean**. +1. On the Settings page, select **Use configuration designer** and add **DefenderSendFeedback** as the key and value type as **Boolean**. - To remove the ability of end-users to provide feedback, set the value as `false` and assign this policy to users. By default, this value is set to `true`. For US Government customers, the default value is set to 'false'. - - For users with key set as `true`, there will be an option to send Feedback data to Microsoft within the app (Menu > Help & Feedback > Send Feedback to Microsoft) + - For users with key set as `true`, there will be an option to send Feedback data to Microsoft within the app (**Menu** > **Help & Feedback** > **Send Feedback to Microsoft**). -1. Click **Next** and assign this profile to targeted devices/users. +1. Select **Next** and assign this profile to targeted devices/users. ## Report unsafe site -Phishing websites impersonate trustworthy websites for the purpose of obtaining your personal or financial information. Visit the [Provide feedback about network protection](https://www.microsoft.com/wdsi/filesubmission/exploitguard/networkprotection) page if you want to report a website that could be a phishing site. +Phishing websites impersonate trustworthy websites for the purpose of obtaining your personal or financial information. Visit the [Provide feedback about network protection](https://www.microsoft.com/wdsi/filesubmission/exploitguard/networkprotection) page to report a website that could be a phishing site. |
| security | Ios Install | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/ios-install.md | This topic describes deploying Defender for Endpoint on iOS on Intune Company Po > [!NOTE] > Microsoft Defender for Endpoint on iOS is available in the [Apple App Store](https://aka.ms/mdatpiosappstore). -## Deployment steps +This section covers: ++1. **Deployment steps** (applicable for both **Supervised** and **Unsupervised** devices)- Admins can deploy Defender for Endpoint on iOS via Intune Company Portal. This step is not needed for VPP (volume purchase) apps. ++1. **Complete deployment** (only for Supervised devices)- Admins can select to deploy any one of the given profiles. + 1. **Zero touch (Silent) Control Filter** - Provides Web Protection without the local loopback VPN and also enables silent onboarding for users. App is automatically installed and activated without the need for user to open the app. + 1. **Control Filter** - Provides Web Protection without the local loopback VPN. + +1. **Automated Onboarding setup** (only for **Unsupervised** devices) - Admins can automate the Defender for Endpoint onboarding for users in two different ways: + 1. **Zero touch (Silent) Onboarding** - App is automatically installed and activated without the need for users to open the app. + 1. **Auto Onboarding of VPN** - Defender for Endpoint VPN profile is automatically setup without having the user to do so during onboarding. This step is not recommended in Zero touch configurations. ++## Deployment steps (applicable for both Supervised and Unsupervised devices) Deploy Defender for Endpoint on iOS via Intune Company Portal. Deploy Defender for Endpoint on iOS via Intune Company Portal. 1. On the **Add app** page, click on **Search the App Store** and type **Microsoft Defender** in the search bar. In the search results section, click on *Microsoft Defender* and click **Select**. -1. Select **iOS 12.0** as the Minimum operating system. Review the rest of information about the app and click **Next**. +1. Select **iOS 14.0** as the Minimum operating system. Review the rest of information about the app and click **Next**. 1. In the **Assignments** section, go to the **Required** section and select **Add group**. You can then choose the user group(s) that you would like to target Defender for Endpoint on iOS app. Click **Select** and then **Next**. Configure the supervised mode for Defender for Endpoint app through an App confi 1. On the **Review + create** page, when you're done, choose **Create**. The new profile is displayed in the list of configuration profiles. -#### Device configuration profile +#### Device configuration profile (Control Filter) > [!NOTE] > For devices that run iOS/iPadOS (in Supervised Mode), there is custom **.mobileconfig** profile, called the **ControlFilter** profile available. This profile enables Web Protection **without setting up the local loopback VPN on the device**. This gives end-users a seamless experience while still being protected from phishing and other web-based attacks. -Deploy a custom profile on supervised iOS devices. This is for enhanced Anti-phishing capabilities. Follow the steps below: +Admins deploy any one of the given profiles. ++1. **Zero touch (Silent) Control Filter** - This profile enables silent onboarding for users. Download the config profile from [ControlFilterZeroTouch](https://aka.ms/mdeiosprofilesupervisedzerotouch) ++2. **Control Filter** - Download the config profile from [ControlFilter](https://aka.ms/mdeiosprofilesupervised). ++Once the profile has been downloaded, deploy the custom profile. Follow the steps below: -1. Download the config profile from [https://aka.ms/mdeiosprofilesupervised](https://aka.ms/mdeiosprofilesupervised). 1. Navigate to **Devices** > **iOS/iPadOS** > **Configuration profiles** > **Create Profile**. 1. Select **Profile Type** > **Templates** and **Template name** > **Custom**. Deploy a custom profile on supervised iOS devices. This is for enhanced Anti-phi 1. On the **Review + create** page, when you're done, choose **Create**. The new profile is displayed in the list of configuration profiles. -## Auto-Onboarding of VPN profile (Simplified Onboarding) --For unsupervised devices, a VPN is used in order to provide the Web Protection feature. This is not a regular VPN and is a local/self-looping VPN that does not take traffic outside the device. --> [!NOTE] -> For supervised devices, a VPN is not needed for Web Protection capability and requires admins to set up a configuration profile on supervised devices. To configure for supervised devices, follow the steps in the [Complete deployment for supervised devices](#complete-deployment-for-supervised-devices) section. --Admins can configure auto-setup of VPN profile. This will automatically set up the Defender for Endpoint VPN profile without having the user to do so while onboarding. --This step simplifies the onboarding process by setting up the VPN profile. For a zero-touch or silent onboarding experience, see the next section: [Zero-touch onboard](#zero-touch-onboarding-of-microsoft-defender-for-endpoint). --1. In [Microsoft Endpoint manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Devices** > **Configuration Profiles** > **Create Profile**. -1. Choose **Platform** as **iOS/iPadOS** and **Profile type** as **VPN**. Click **Create**. -1. Type a name for the profile and click **Next**. -1. Select **Custom VPN** for Connection Type and in the **Base VPN** section, enter the following: - - Connection Name = Microsoft Defender for Endpoint - - VPN server address = 127.0.0.1 - - Auth method = "Username and password" - - Split Tunneling = Disable - - VPN identifier = com.microsoft.scmx - - In the key-value pairs, enter the key **AutoOnboard** and set the value to **True**. - - Type of Automatic VPN = On-demand VPN - - Select **Add** for **On Demand Rules** and select **I want to do the following = Connect VPN**, **I want to restrict to = All domains**. -- :::image type="content" source="images/ios-deploy-8.png" alt-text="The VPN profile Configuration settings tab." lightbox="images/ios-deploy-8.png"::: - - - To mandate that VPN cannot be disabled in users device, Admins can select **Yes** from **Block users from disabling automatic VPN**. By default, it's not configured and users can disable VPN only in the Settings. - - To allow Users to Change the VPN toggle from within the app, add **EnableVPNToggleInApp = TRUE**, in the key-value pairs. By default, users cannot change the toggle from within the app. +## Automated Onboarding setup (only for Unsupervised devices) -1. Click **Next** and assign the profile to targeted users. -1. In the *Review + Create* section, verify that all the information entered is correct and then select **Create**. +Admins can automate the Defender onboarding for users in two different ways with Zero touch(Silent) Onboarding or Auto Onboarding of VPN. -## Zero-touch onboarding of Microsoft Defender for Endpoint +### Zero-touch (Silent) onboarding of Microsoft Defender for Endpoint > [!NOTE] > Zero-touch cannot be configured on iOS devices that are enrolled without user affinity (user-less devices or shared devices). Once the above configuration is done and synced with the device, the following a - Web Protection and other features will be activated. > [!NOTE]-> For supervised devices, although a VPN profile is not required, admins still can set up Zero-touch onboarding by configuring the Defender for Endpoint VPN profile through Intune. The VPN profile will be deployed on the device but will only be present on the device as a pass-through profile and can be deleted after initial onboarding. +> For supervised devices, admins can setup Zero touch onboarding with the new [ZeroTouch Control Filter Profile](#device-configuration-profile-control-filter). +Defender for Endpoint VPN Profile will not be installed on the device and Web protection will be provided by the Control Filter Profile. ++### Auto-Onboarding of VPN profile (Simplified Onboarding) ++> [!NOTE] +> This step simplifies the onboarding process by setting up the VPN profile. If you are using Zero touch, you do not need to perform this step. ++For unsupervised devices, a VPN is used to provide the Web Protection feature. This is not a regular VPN and is a local/self-looping VPN that does not take traffic outside the device. ++Admins can configure auto-setup of VPN profile. This will automatically set up the Defender for Endpoint VPN profile without having the user to do so while onboarding. ++1. In [Microsoft Endpoint manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431), go to **Devices** > **Configuration Profiles** > **Create Profile**. +1. Choose **Platform** as **iOS/iPadOS** and **Profile type** as **VPN**. Click **Create**. +1. Type a name for the profile and click **Next**. +1. Select **Custom VPN** for Connection Type and in the **Base VPN** section, enter the following: + - Connection Name = Microsoft Defender for Endpoint + - VPN server address = 127.0.0.1 + - Auth method = "Username and password" + - Split Tunneling = Disable + - VPN identifier = com.microsoft.scmx + - In the key-value pairs, enter the key **AutoOnboard** and set the value to **True**. + - Type of Automatic VPN = On-demand VPN + - Select **Add** for **On Demand Rules** and select **I want to do the following = Connect VPN**, **I want to restrict to = All domains**. ++ :::image type="content" source="images/ios-deploy-8.png" alt-text="The VPN profile Configuration settings tab." lightbox="images/ios-deploy-8.png"::: ++ - To require that VPN cannot be disabled on a users' device, Admins can select **Yes** from **Block users from disabling automatic VPN**. By default, this setting not configured and users can disable VPN only in the Settings. + - To allow Users to Change the VPN toggle from within the app, add **EnableVPNToggleInApp = TRUE**, in the key-value pairs. By default, users cannot change the toggle from within the app. ++1. Click **Next** and assign the profile to targeted users. +1. In the *Review + Create* section, verify that all the information entered is correct and then select **Create**. ## Complete onboarding and check status |
| security | Ios Privacy | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/ios-privacy.md | Here is a list of the types of data being collected: ### Web page or Network information -- Domain name and IP address of the website only when a malicious connection or web page is detected.+- Domain name and IP address of the website only when a malicious connection or web page is detected. Information is collected only when Privacy setting is disabled or turned off. ### Device and account information |
| security | Ios Whatsnew | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/ios-whatsnew.md | On January 25, 2022, we announced the general availability of Vulnerability mana ## 1.1.23250104 - Performance optimizations - Test battery performance with this version and let us know your feedback.-- **Zero-touch onboard for enrolled iOS devices** - With this version, the preview of Zero-touch onboard for devices enrolled through Microsoft Endpoint Manager (Intune) has been added. For more information, see this [documentation](ios-install.md#zero-touch-onboarding-of-microsoft-defender-for-endpoint) for more details on setup and configuration.+- **Zero-touch onboard for enrolled iOS devices** - With this version, the preview of Zero-touch onboard for devices enrolled through Microsoft Endpoint Manager (Intune) has been added. For more information, see this [documentation](ios-install.md#zero-touch-silent-onboarding-of-microsoft-defender-for-endpoint) for more details on setup and configuration. - **Privacy Controls** - Configure privacy controls for phish alert report. For more information, see [Configure iOS features](ios-configure-features.md). ## 1.1.23010101 |
| security | Linux Install Manually | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/linux-install-manually.md | In order to preview new features and provide early feedback, it is recommended t - Install the Microsoft GPG public key: ```bash- curl -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /usr/share/keyrings/microsoft.gpg > + curl -sSL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/microsoft.gpg > ``` - Install the HTTPS driver if not already installed: |
| security | Mac Support License | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/mac-support-license.md | search.appverid: met150 > Want to experience Microsoft Defender for Endpoint? [Sign up for a free trial.](https://signup.microsoft.com/create-account/signup?products=7f379fee-c4f9-4278-b0a1-e4c8c2fcdf7e&ru=https://aka.ms/MDEp2OpenTrial?ocid=docs-wdatp-exposedapis-abovefoldlink) +## No license found + While you are going through [Microsoft Defender for Endpoint on macOS](microsoft-defender-endpoint-mac.md) and [Manual deployment](mac-install-manually.md) testing or a Proof Of Concept (PoC), you might get the following error: :::image type="content" source="images/no-license-found.png" alt-text="License error" lightbox="images/no-license-found.png"::: -**Message:** +### Message: No license found Looks like your organization does not have a license for Microsoft 365 Enterpris Contact your administrator for help. -**Cause:** +### Cause: You deployed and/or installed the Microsoft Defender for Endpoint on macOS package ("Download installation package"), but you might not have run the configuration script ("Download onboarding package"), or you have not assigned a license to the user. You can also encounter this error when the Microsoft Defender for Endpoint on macOS agent isn't up to date. -**Solution:** +### Solution: Follow the MicrosoftDefenderATPOnboardingMacOs.py instructions documented here: [Client configuration](mac-install-manually.md#client-configuration). For scenarios where Microsoft Defender for Endpoint on macOS isn't up to date, you'll need to update the agent.++## Sign in with your Microsoft account ++ ++### Message: ++Sign in with your Microsoft account to get started. ++Create new account or Switch to enterprise app ++### Cause: ++You downloaded and installed [Microsoft Defender for individuals on macOS](https://www.microsoft.com/en-us/microsoft-365/microsoft-defender-for-individuals) on top of previously installed Microsoft Defender for Endpoint. ++### Solution: ++Click **Switch to enterprise app** to switch to Enterprise experience. ++You can also suppress switching to experience for Individuals on MDM enrolled machines by including **userInterface**/**consumerExperience** into Defender's settings: ++```json +<key>userInterface</key> +<dict> + <key>consumerExperience</key> + <string>disabled</string> +</dict> +``` |
| security | Mtd | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/mtd.md | The following table summarizes how to deploy Microsoft Defender for Endpoint on ### End-user onboarding -- [Configure Zero-touch onboard for iOS enrolled devices](ios-install.md#zero-touch-onboarding-of-microsoft-defender-for-endpoint): Admins can configure zero-touch install to silently onboard Microsoft Defender for Endpoint on enrolled iOS devices without requiring the user to open the app. +- [Configure Zero-touch onboard for iOS enrolled devices](ios-install.md#zero-touch-silent-onboarding-of-microsoft-defender-for-endpoint): Admins can configure zero-touch install to silently onboard Microsoft Defender for Endpoint on enrolled iOS devices without requiring the user to open the app. - [Configure Conditional Access to enforce user onboarding](android-configure.md#conditional-access-with-defender-for-endpoint-on-android): This can be applied to ensure end-users onboard to the Microsoft Defender for Endpoint app after deploying. Watch this video for a quick demo on configuring conditional access with Defender for Endpoint risk signals. The following table summarizes how to deploy Microsoft Defender for Endpoint on ### Simplify Onboarding -- [iOS - Zero-Touch Onboard](ios-install.md#zero-touch-onboarding-of-microsoft-defender-for-endpoint)+- [iOS - Zero-Touch Onboard](ios-install.md#zero-touch-silent-onboarding-of-microsoft-defender-for-endpoint) - [Android Enterprise - Setup Always-on VPN](android-intune.md#auto-setup-of-always-on-vpn). - [iOS - Auto-setup of VPN profile](ios-install.md#auto-onboarding-of-vpn-profile-simplified-onboarding) |
| security | Tamperprotection Macos | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender-endpoint/tamperprotection-macos.md | There are several ways you can configure tamper protection: ### Before you begin Verify that "tamper_protection" is set to "disabled" or "audit" to observe the state change.-Also, make sure that "release_ring" does not report "Production". ```bash mdatp health |
| security | Advanced Hunting Limits | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender/advanced-hunting-limits.md | Title: Advanced hunting quotas and usage parameters in Microsoft 365 Defender + Title: Use the advanced hunting query resource report description: Understand various quotas and usage parameters (service limits) that keep the advanced hunting service responsive keywords: advanced hunting, threat hunting, cyber threat hunting, Microsoft 365 Defender, microsoft 365, m365, search, query, telemetry, schema, kusto, CPU limit, query limit, resources, maximum results, quota, parameters, allocation search.product: eADQiWindows 10XVcnh-# Advanced hunting quotas and usage parameters +# Use the advanced hunting query resource report [!INCLUDE [Microsoft 365 Defender rebranding](../includes/microsoft-defender.md)] **Applies to:** - Microsoft 365 Defender+ +> [!IMPORTANT] +> Some information relates to prereleased product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. ++## Understand advanced hunting quotas and usage parameters To keep the service performant and responsive, advanced hunting sets various quotas and usage parameters (also known as "service limits"). These quotas and parameters apply separately to queries run manually and to queries run using [custom detection rules](custom-detection-rules.md). Customers who run multiple queries regularly should be mindful of these limits and [apply optimization best practices](advanced-hunting-best-practices.md) to minimize disruptions. Refer to the following table to understand existing quotas and usage parameters. >[!NOTE] >A separate set of quotas and parameters apply to advanced hunting queries performed through the API. [Read about advanced hunting APIs](./api-advanced-hunting.md) +## View query resources report to find inefficient queries ++The query resources report shows your organization's consumption of CPU resources for hunting based on queries that ran in the last 30 days using any of the hunting interfaces. +This report is useful in identifying the most resource-intensive queries and understanding how to prevent throttling due to excessive use. ++### Access the query resources report ++The report can be accessed in two ways: +- In the advanced hunting page, select **Query resources report**: ++- Within the **Reports** page, find the new report entry in the **General** section +++All users can access the reports, however, only the AAD global admin, AAD security admin, and AAD security reader roles can see queries done by all users in all interfaces. Any other user can only see: +- Queries they ran via the portal +- Public API queries they ran themselves and not through the application +- Custom detections they created ++### Query resource report contents +By default, the report table displays queries from the last day, and is sorted by Resource usage, to help you easily identify which queries consumed the highest amount of CPU resources. ++The query resources report contains all queries that ran, including detailed resource information per query: +- **Time** ΓÇô when the query was run +- **Interface** ΓÇô whether the query ran in the portal, in custom detections, or via API query +- **User/App** ΓÇô the user or app that ran the query +- **Resource usage** ΓÇô an indicator of the amount of CPU resources a query consumed (can be Low, Medium, or High, where High means the query used a large amount of CPU resources and should be improved to be more efficient) +- **State** ΓÇô whether the query was completed, failed, or was throttled +- **Query time** ΓÇô how long it took to run the query +- **Time range** ΓÇô the time range used in the query ++> [!TIP] +> If the query state is **Failed**, you can hover the field to view the reason for the query failure. +++### Find resource-heavy queries +Queries with high resource usage or a long query time can probably be optimized to prevent throttling via this interface. ++The graph displays resource usage over time per interface. You can easily identify excessive usage and click the spikes in the graph to filter the table accordingly. Once you select an entry in the graph, the table is filtered to that specific date. ++You can identify the queries that used the most resources on that day and take action to improve them ΓÇô by [applying query best practices](advanced-hunting-best-practices.md) or educating the user who ran the query or created the rule to take query efficiency and resources into consideration. For guided mode, the user needs to [switch to advanced mode](advanced-hunting-query-builder-details.md#switch-to-advanced-mode-after-building-a-query) to edit the query. ++ +The graph supports two views: +- Average use per day ΓÇô the average use of resources per day +- Highest use per day ΓÇô the highest actual use of resources per day ++ ++This means that, for instance, if on a specific day you ran two queries, one used 50% of your resources and one used 100%, the average daily use value would show 75%, while the top daily use would show 100%. + ## Related topics - [Advanced hunting best practices](advanced-hunting-best-practices.md) - [Handle advanced hunting errors](advanced-hunting-errors.md) - [Advanced hunting overview](advanced-hunting-overview.md)-- [Custom detections overview](custom-detections-overview.md) |
| security | Eval Defender Office 365 Pilot | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender/eval-defender-office-365-pilot.md | The table below provides references and more guidance for configuring and assign |Anti-malware policies|Protect users from email malware including what actions to take and who to notify if malware is detected.|Yes|Yes|[Configure anti-malware policies in EOP](../office-365-security/configure-anti-malware-policies.md)| |Anti-spam policies|Protect users from email spam including what actions to take if spam is detected.|Yes|Yes|[Configure anti-spam policies in Defender for Office 365](../office-365-security/configure-your-spam-filter-policies.md)| |Anti-spoofing protection|Protect users from spoofing attempts using spoof intelligence and spoof intelligence insights.|Yes|Yes|[Configure spoof intelligence in Defender for Office 365](../office-365-security/learn-about-spoof-intelligence.md) <br><br> [Configure anti-phishing policies in EOP](../office-365-security/configure-anti-phishing-policies-eop.md)|-|Impersonation protection|Protect users from phishing attacks and configure safety tips on suspicious messages|Yes, but some configuration required.|Yes, but some configuration required.|[Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365](../office-365-security/set-up-anti-phishing-policies.md#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) <br><br> [Impersonation insight in Defender for Office 365](../office-365-security/impersonation-insight.md) <br><br> [Configure anti-phishing policies in Microsoft Defender for Office 365](../office-365-security/configure-mdo-anti-phishing-policies.md)| +|Impersonation protection|Protect users from phishing attacks and configure safety tips on suspicious messages|Yes, but some configuration required.|Yes, but some configuration required.|[Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365](../office-365-security/set-up-anti-phishing-policies.md#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) <br><br> [Impersonation insight in Defender for Office 365](../office-365-security/anti-phishing-mdo-impersonation-insight.md) <br><br> [Configure anti-phishing policies in Microsoft Defender for Office 365](../office-365-security/configure-mdo-anti-phishing-policies.md)| |Safe Attachments policies|Protect users from malicious content in email attachments and files in SharePoint, OneDrive, and Teams.|Yes|Effectively, via Built-in protection|[Set up Safe Attachment policies in Defender for Office 365](../office-365-security/set-up-safe-attachments-policies.md)| |Safe Links policies|Protect users from opening and sharing malicious links in email messages or supported Office apps.|Yes|Effectively, via Built-in protection|[Set up Safe Links policies in Defender for Office 365](../office-365-security/set-up-safe-links-policies.md)| |
| security | Whats New | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/defender/whats-new.md | You can also get product updates and important notifications through the [messag ## November 2022 - (Preview) Microsoft Defender Experts for XDR (Defender Experts for XDR) is now available for preview. Defender Experts for XDR is a managed detection and response service that helps your security operations centers (SOCs) focus and accurately respond to incidents that matter. It provides extended detection and response for customers who use Microsoft 365 Defender workloads: Microsoft Defender for Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, and Azure Active Directory (Azure AD). For details, refer to [Expanded Microsoft Defender Experts for XDR preview](dex-xdr-overview.md).+- (Preview) The query resource report is now available in advanced hunting. The report shows your organization's consumption of CPU resources for hunting based on queries that ran in the last 30 days using any of the hunting interfaces. See [View query resources report](advanced-hunting-limits.md#view-query-resources-report-to-find-inefficient-queries) to find inefficient queries. ## August 2022 - (GA) [Microsoft Defender Experts for Hunting](defender-experts-for-hunting.md) is now generally available. If you're a Microsoft 365 Defender customer with a robust security operations center but want Microsoft to help you proactively hunt for threats across endpoints, Office 365, cloud applications, and identity using Microsoft Defender data, then learn more about applying, setting up, and using the service. Defender Experts for Hunting is sold separately from other Microsoft 365 Defender products. |
| security | Anti Malware Policies Configure | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-malware-policies-configure.md | + + Title: Configure anti-malware policies +f1.keywords: + - NOCSH +++ Last updated :+audience: ITPro +++ms.localizationpriority: medium +search.appverid: + - MET150 +ms.assetid: b0cfc21f-e3c6-41b6-8670-feb2b2e252e5 ++ - m365-security + - m365initiative-defender-office365 +description: Admins can learn how to view, create, modify, and remove anti-malware policies in Exchange Online Protection (EOP). ++- seo-marvel-apr2020 +++++# Configure anti-malware policies in EOP +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, email messages are automatically protected against malware by EOP. EOP uses anti-malware policies for malware protection settings. For more information, see [Anti-malware protection](anti-malware-protection.md). ++Admins can view, edit, and configure (but not delete) the default anti-malware policy to meet the needs of their organizations. For greater granularity, you can also create custom anti-malware policies that apply to specific users, groups, or domains in your organization. Custom policies always take precedence over the default policy, but you can change the priority (running order) of your custom policies. ++You can configure anti-malware policies in the Microsoft 365 Defender portal or in PowerShell (Exchange Online PowerShell for Microsoft 365 organizations with mailboxes in Exchange Online; standalone EOP PowerShell for organizations without Exchange Online mailboxes). ++## What do you need to know before you begin? ++- You open the Microsoft 365 Defender portal at <https://security.microsoft.com>. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++- To connect to Exchange Online PowerShell, see [Connect to Exchange Online PowerShell](/powershell/exchange/connect-to-exchange-online-powershell). To connect to standalone EOP PowerShell, see [Connect to Exchange Online Protection PowerShell](/powershell/exchange/connect-to-exchange-online-protection-powershell). ++- You need to be assigned permissions in **Exchange Online** before you can do the procedures in this article: + - To add, modify, and delete anti-malware policies, you need to be a member of the **Organization Management** or **Security Administrator** role groups. + - For read-only access to anti-malware policies, you need to be a member of the **Global Reader** or **Security Reader** role groups. ++ For more information, see [Permissions in Exchange Online](/exchange/permissions-exo/permissions-exo). ++ **Notes**: ++ - Adding users to the corresponding Azure Active Directory role in the Microsoft 365 admin center gives users the required permissions _and_ permissions for other features in Microsoft 365. For more information, see [About admin roles](../../admin/add-users/about-admin-roles.md). + - The **View-Only Organization Management** role group in [Exchange Online](/Exchange/permissions-exo/permissions-exo#role-groups) also gives read-only access to the feature. ++- For our recommended settings for anti-malware policies, see [EOP anti-malware policy settings](recommended-settings-for-eop-and-office365.md#eop-anti-malware-policy-settings). ++## Use the Microsoft 365 Defender portal to create anti-malware policies ++Creating a custom anti-malware policy in the Microsoft 365 Defender portal creates the malware filter rule and the associated malware filter policy at the same time using the same name for both. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware** page, click  **Create**. ++3. The policy wizard opens. On the **Name your policy** page, configure these settings: + - **Name**: Enter a unique, descriptive name for the policy. + - **Description**: Enter an optional description for the policy. ++ When you're finished, click **Next**. ++4. On the **Users and domains** page, identify the internal recipients that the policy applies to (recipient conditions): + - **Users**: The specified mailboxes, mail users, or mail contacts. + - **Groups**: + - Members of the specified distribution groups or mail-enabled security groups. + - The specified Microsoft 365 Groups. + - **Domains**: All recipients in the specified [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in your organization. ++ Click in the appropriate box, start typing a value, and select the value that you want from the results. Repeat this process as many times as necessary. To remove an existing value, click remove  next to the value. ++ For users or groups, you can use most identifiers (name, display name, alias, email address, account name, etc.), but the corresponding display name is shown in the results. For users, enter an asterisk (\*) by itself to see all available values. ++ Multiple values in the same condition use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). Different conditions use AND logic (for example, _\<recipient1\>_ and _\<member of group 1\>_). ++ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions. The settings and behavior are exactly like the conditions. ++ > [!IMPORTANT] + > Multiple different types of conditions or exceptions are not additive; they're inclusive. The policy is applied _only_ to those recipients that match _all_ of the specified recipient filters. For example, you configure a recipient filter condition in the policy with the following values: + > + > - Users: romain@contoso.com + > - Groups: Executives + > + > The policy is applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy is not applied to him. + > + > Likewise, if you use the same recipient filter as an exception to the policy, the policy is not applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy still applies to him. ++ When you're finished, click **Next**. ++5. On the **Protection settings** page, configure the following settings: ++ - **Enable the common attachments filter**: If you select this option, messages with the specified attachments are treated as malware and are automatically quarantined. You can modify the list by clicking **Customize file types** and selecting or deselecting values in the list. ++ For the default and available values, see [Anti-malware policies](anti-malware-protection.md#anti-malware-policies). ++ **When these types are found**: Select one of the following values: ++ - **Reject the message with a non-delivery report (NDR)** (this is the default value) + - **Quarantine the message** ++ - **Enable zero-hour auto purge for malware**: If you select this option, ZAP quarantines malware messages that have already been delivered. For more information, see [Zero-hour auto purge (ZAP) in Exchange Online](zero-hour-auto-purge.md). ++ - **Quarantine policy**: Select the quarantine policy that applies to messages that are quarantined as malware. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++ A blank value means the default quarantine policy is used (AdminOnlyAccessPolicy for malware detections). When you later edit the anti-malware policy or view the settings, the default quarantine policy name is shown. For more information about default quarantine policies that are used for supported protection filtering verdicts, see [this table](quarantine-policies.md#step-2-assign-a-quarantine-policy-to-supported-features). ++ > [!NOTE] + > The quarantine policy determines whether recipients receive email notifications for messages that were quarantined as malware. Quarantine notifications are disabled in the AdminOnlyAccessPolicy, so you'll need to create and assign a custom quarantine policy where notifications are turned on. For more information, see [Quarantine policies](quarantine-policies.md). + > + > Users can't release their own messages that were quarantined as malware. At best, admins can configure the quarantine policy so users can request the release of their quarantined malware messages. ++ - **Admin notifications**: Select none, one, or both of the following options: ++ - **Notify an admin about undelivered messages from internal senders**: If you select this option, enter a recipient email address in the **Admin email address** box that appears. ++ - **Notify an admin about undelivered messages from external senders**: If you select this option, enter a recipient email address in the **Admin email address** box that appears. ++ > [!NOTE] + > Admin notifications are sent only for _attachments_ that are classified as malware. ++ - **Customize notifications**: Use the settings in this section to customize the message properties that are used for admin notifications. ++ - **Use customized notification text**: If you select this option, use the **From name** and **From address** boxes to specify the sender's name and email address for admin notification messages. ++ - **Customize notifications for messages from internal senders**: If you previously selected **Notify an admin about undelivered messages from internal senders**, use the **Subject** and **Message** boxes to specify the subject and message body of admin notification messages. ++ - **Customize notifications for messages from external senders**: If you previously selected **Notify an admin about undelivered messages from external senders**, you need to use the **Subject** and **Message** boxes to specify the subject and message body of admin notification messages. ++ When you're finished, click **Next**. ++6. On the **Review** page, review your settings. You can select **Edit** in each section to modify the settings within the section. Or you can click **Back** or select the specific page in the wizard. ++ When you're finished, click **Submit**. ++7. On the confirmation page that appears, click **Done**. ++## Use the Microsoft 365 Defender portal to view anti-malware policies ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware** page, the following properties are displayed in the list of anti-malware policies: + - **Name** + - **Status** + - **Priority** ++3. When you select a policy by clicking on the name, the policy settings are displayed in a flyout. ++## Use the Microsoft 365 Defender portal to modify anti-malware policies ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware** page, select a policy from the list by clicking on the name. ++3. In the policy details flyout that appears, select **Edit** in each section to modify the settings within the section. For more information about the settings, see the previous [Use the Microsoft 365 Defender portal to create anti-malware policies](#use-the-microsoft-365-defender-portal-to-create-anti-malware-policies) section in this article. ++ For the default anti-malware policy, the **Users, groups, and domains** section isn't available (the policy applies to everyone), and you can't rename the policy. ++To enable or disable a policy or set the policy priority order, see the following sections. ++### Enable or disable custom anti-malware policies ++You can't disable the default anti-malware policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see one of the following values: + - **Policy off**: To turn on the policy, click  **Turn on** . + - **Policy on**: To turn off the policy, click  **Turn off**. ++4. In the confirmation dialog that appears, click **Turn on** or **Turn off**. ++5. Click **Close** in the policy details flyout. ++Back on the main policy page, the **Status** value of the policy will be **On** or **Off**. ++### Set the priority of custom anti-malware policies ++By default, anti-malware policies are given a priority that's based on the order they were created in (newer policies are lower priority than older policies). A lower priority number indicates a higher priority for the policy (0 is the highest), and policies are processed in priority order (higher priority policies are processed before lower priority policies). No two policies can have the same priority, and policy processing stops after the first policy is applied. ++To change the priority of a policy, you click **Increase priority** or **Decrease priority** in the properties of the policy (you can't directly modify the **Priority** number in the Microsoft 365 Defender portal). Changing the priority of a policy only makes sense if you have multiple policies. ++ **Notes**: ++- In the Microsoft 365 Defender portal, you can only change the priority of the anti-malware policy after you create it. In PowerShell, you can override the default priority when you create the malware filter rule (which can affect the priority of existing rules). +- Anti-malware policies are processed in the order that they're displayed (the first policy has the **Priority** value 0). The default anti-malware policy has the priority value **Lowest**, and you can't change it. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see **Increase priority** or **Decrease priority** based on the current priority value and the number of custom policies: + - The policy with the **Priority** value **0** has only the **Decrease priority** option available. + - The policy with the lowest **Priority** value (for example, **3**) has only the **Increase priority** option available. + - If you have three or more policies, the policies between the highest and lowest priority values have both the **Increase priority** and **Decrease priority** options available. ++ Click  **Increase priority** or  **Decrease priority** to change the **Priority** value. ++4. When you're finished, click **Close** in the policy details flyout. ++## Use the Microsoft 365 Defender portal to remove custom anti-malware policies ++When you use the Microsoft 365 Defender portal to remove a custom anti-malware policy, the malware filter rule and the corresponding malware filter policy are both deleted. You can't remove the default anti-malware policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-Malware** in the **Policies** section. To go directly to the **Anti-malware** page, use <https://security.microsoft.com/antimalwarev2>. ++2. On the **Anti-malware page**, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, click  **More actions** \>  **Delete policy**. ++4. In the confirmation dialog that appears, click **Yes**. ++## Use Exchange Online PowerShell or standalone EOP PowerShell to configure anti-malware policies ++For more information about anti-spam policies in PowerShell, see [Anti-malware policies in the Microsoft 365 Defender portal vs PowerShell](anti-malware-protection.md#anti-malware-policies-in-the-microsoft-365-defender-portal-vs-powershell). ++### Use PowerShell to create anti-malware policies ++Creating an anti-malware policy in PowerShell is a two-step process: ++1. Create the malware filter policy. +2. Create the malware filter rule that specifies the malware filter policy that the rule applies to. ++ **Notes**: ++- You can create a new malware filter rule and assign an existing, unassociated malware filter policy to it. A malware filter rule can't be associated with more than one malware filter policy. +- There are two settings that you can configure on new anti-malware policies in PowerShell that aren't available in the Microsoft 365 Defender portal until after you create the policy: + - Create the new policy as disabled (_Enabled_ `$false` on the **New-MalwareFilterRule** cmdlet). + - Set the priority of the policy during creation (_Priority_ _\<Number\>_) on the **New-MalwareFilterRule** cmdlet). +- A new malware filter policy that you create in PowerShell isn't visible in the Microsoft 365 Defender portal until you assign the policy to a malware filter rule. ++#### Step 1: Use PowerShell to create a malware filter policy ++To create a malware filter policy, use this syntax: ++```PowerShell +New-MalwareFilterPolicy -Name "<PolicyName>" [-AdminDisplayName "<OptionalComments>"] [-CustomNotifications <$true | $false>] [<Inbound notification options>] [<Outbound notification options>] [-QuarantineTag <QuarantineTagName>] +``` ++This example creates a new malware filter policy named Contoso Malware Filter Policy with these settings: ++- Notify admin@contoso.com when malware is detected in a message from an internal sender. +- The default [quarantine policy](quarantine-policies.md) for malware detections is used (we aren't using the _QuarantineTag_ parameter). ++```PowerShell +New-MalwareFilterPolicy -Name "Contoso Malware Filter Policy" -EnableInternalSenderAdminNotifications $true -InternalSenderAdminAddress admin@contoso.com +``` ++For detailed syntax and parameter information, see [New-MalwareFilterPolicy](/powershell/module/exchange/new-malwarefilterpolicy). ++#### Step 2: Use PowerShell to create a malware filter rule ++To create a malware filter rule, use this syntax: ++```PowerShell +New-MalwareFilterRule -Name "<RuleName>" -MalwareFilterPolicy "<PolicyName>" <Recipient filters> [<Recipient filter exceptions>] [-Comments "<OptionalComments>"] +``` ++This example creates a new malware filter rule named Contoso Recipients with these settings: ++- The malware filter policy named Contoso Malware Filter Policy is associated with the rule. +- The rule applies to recipients in the contoso.com domain. ++```PowerShell +New-MalwareFilterRule -Name "Contoso Recipients" -MalwareFilterPolicy "Contoso Malware Filter Policy" -RecipientDomainIs contoso.com +``` ++For detailed syntax and parameter information, see [New-MalwareFilterRule](/powershell/module/exchange/new-malwarefilterrule). ++### Use PowerShell to view malware filter policies ++To return a summary list of all malware filter policies, run this command: ++```PowerShell +Get-MalwareFilterPolicy +``` ++To return detailed information about a specific malware filter policy, use this syntax: ++```PowerShell +Get-MalwareFilterPolicy -Identity "<PolicyName>" | Format-List [<Specific properties to view>] +``` ++This example returns all the property values for the malware filter policy named Executives. ++```PowerShell +Get-MalwareFilterPolicy -Identity "Executives" | Format-List +``` ++This example returns only the specified properties for the same policy. ++```PowerShell +Get-MalwareFilterPolicy -Identity "Executives" | Format-List Action,AdminDisplayName,CustomNotifications,Enable*Notifications +``` ++For detailed syntax and parameter information, see [Get-MalwareFilterPolicy](/powershell/module/exchange/get-malwarefilterpolicy). ++### Use PowerShell to view malware filter rules ++To return a summary list of all malware filter rules, run this command: ++```PowerShell +Get-MalwareFilterRule +``` ++To filter the list by enabled or disabled rules, run the following commands: ++```PowerShell +Get-MalwareFilterRule -State Disabled +``` ++```PowerShell +Get-MalwareFilterRule -State Enabled +``` ++To return detailed information about a specific malware filter rule, use this syntax: ++```PowerShell +Get-MalwareFilterRule -Identity "<RuleName>" | Format-List [<Specific properties to view>] +``` ++This example returns all the property values for the malware filter rule named Executives. ++```PowerShell +Get-MalwareFilterRule -Identity "Executives" | Format-List +``` ++This example returns only the specified properties for the same rule. ++```PowerShell +Get-MalwareFilterRule -Identity "Executives" | Format-List Name,Priority,State,MalwareFilterPolicy,*Is,*SentTo,*MemberOf +``` ++For detailed syntax and parameter information, see [Get-MalwareFilterRule](/powershell/module/exchange/get-malwarefilterrule). ++### Use PowerShell to modify malware filter policies ++Other than the following items, the same settings are available when you modify a malware filter policy in PowerShell as when you create the policy as described in the [Step 1: Use PowerShell to create a malware filter policy](#step-1-use-powershell-to-create-a-malware-filter-policy) section earlier in this article. ++- The _MakeDefault_ switch that turns the specified policy into the default policy (applied to everyone, unmodifiable **Lowest** priority, and you can't delete it) is only available when you modify a malware filter policy in PowerShell. +- You can't rename a malware filter policy (the **Set-MalwareFilterPolicy** cmdlet has no _Name_ parameter). When you rename an anti-malware policy in the Microsoft 365 Defender portal, you're only renaming the malware filter _rule_. ++To modify a malware filter policy, use this syntax: ++```PowerShell +Set-MalwareFilterPolicy -Identity "<PolicyName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-MalwareFilterPolicy](/powershell/module/exchange/set-malwarefilterpolicy). ++> [!NOTE] +> For detailed instructions to specify the [quarantine policy](quarantine-policies.md) to use in a malware filter policy, see [Use PowerShell to specify the quarantine policy in anti-malware policies](quarantine-policies.md#anti-malware-policies-in-powershell). ++### Use PowerShell to modify malware filter rules ++The only setting that isn't available when you modify a malware filter rule in PowerShell is the _Enabled_ parameter that allows you to create a disabled rule. To enable or disable existing malware filter rules, see the next section. ++Otherwise, no additional settings are available when you modify a malware filter rule in PowerShell. The same settings are available when you create a rule as described in the [Step 2: Use PowerShell to create a malware filter rule](#step-2-use-powershell-to-create-a-malware-filter-rule) section earlier in this article. ++To modify a malware filter rule, use this syntax: ++```PowerShell +Set-MalwareFilterRule -Identity "<RuleName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-MalwareFilterRule](/powershell/module/exchange/set-malwarefilterrule). ++### Use PowerShell to enable or disable malware filter rules ++Enabling or disabling a malware filter rule in PowerShell enables or disables the whole anti-malware policy (the malware filter rule and the assigned malware filter policy). You can't enable or disable the default anti-malware policy (it's always applied to all recipients). ++To enable or disable a malware filter rule in PowerShell, use this syntax: ++```PowerShell +<Enable-MalwareFilterRule | Disable-MalwareFilterRule> -Identity "<RuleName>" +``` ++This example disables the malware filter rule named Marketing Department. ++```PowerShell +Disable-MalwareFilterRule -Identity "Marketing Department" +``` ++This example enables same rule. ++```PowerShell +Enable-MalwareFilterRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Enable-MalwareFilterRule](/powershell/module/exchange/enable-malwarefilterrule) and [Disable-MalwareFilterRule](/powershell/module/exchange/disable-malwarefilterrule). ++### Use PowerShell to set the priority of malware filter rules ++The highest priority value you can set on a rule is 0. The lowest value you can set depends on the number of rules. For example, if you have five rules, you can use the priority values 0 through 4. Changing the priority of an existing rule can have a cascading effect on other rules. For example, if you have five custom rules (priorities 0 through 4), and you change the priority of a rule to 2, the existing rule with priority 2 is changed to priority 3, and the rule with priority 3 is changed to priority 4. ++To set the priority of a malware filter rule in PowerShell, use the following syntax: ++```PowerShell +Set-MalwareFilterRule -Identity "<RuleName>" -Priority <Number> +``` ++This example sets the priority of the rule named Marketing Department to 2. All existing rules that have a priority less than or equal to 2 are decreased by 1 (their priority numbers are increased by 1). ++```PowerShell +Set-MalwareFilterRule -Identity "Marketing Department" -Priority 2 +``` ++**Notes**: ++- To set the priority of a new rule when you create it, use the _Priority_ parameter on the **New-MalwareFilterRule** cmdlet instead. +- The default malware filter policy doesn't have a corresponding malware filter rule, and it always has the unmodifiable priority value **Lowest**. ++### Use PowerShell to remove malware filter policies ++When you use PowerShell to remove a malware filter policy, the corresponding malware filter rule isn't removed. ++To remove a malware filter policy in PowerShell, use this syntax: ++```PowerShell +Remove-MalwareFilterPolicy -Identity "<PolicyName>" +``` ++This example removes the malware filter policy named Marketing Department. ++```PowerShell +Remove-MalwareFilterPolicy -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-MalwareFilterPolicy](/powershell/module/exchange/remove-malwarefilterpolicy). ++### Use PowerShell to remove malware filter rules ++When you use PowerShell to remove a malware filter rule, the corresponding malware filter policy isn't removed. ++To remove a malware filter rule in PowerShell, use this syntax: ++```PowerShell +Remove-MalwareFilterRule -Identity "<PolicyName>" +``` ++This example removes the malware filter rule named Marketing Department. ++```PowerShell +Remove-MalwareFilterRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-MalwareFilterRule](/powershell/module/exchange/remove-malwarefilterrule). ++## How do you know these procedures worked? ++### Use the EICAR.TXT file to verify your anti-malware policy settings ++> [!IMPORTANT] +> The EICAR.TXT file is not a virus. The European Institute for Computer Antivirus Research (EICAR) developed this file to safely test anti-virus installations and settings. ++1. Open Notepad and paste the following text into an empty file: ++ ```Text + X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* + ``` ++ Be sure that these are the only text characters in the file. The file size should be 68 bytes. ++2. Save the file as EICAR.TXT ++ In your desktop anti-virus program, be sure to exclude the EICAR.TXT from scanning (otherwise, the file will be quarantined). ++3. Send an email message that contains the EICAR.TXT file as an attachment, using an email client that won't automatically block the file, and using an email service that doesn't automatically block outbound spam. Use your anti-malware policy settings to determine the following scenarios to test: + - Email from an internal mailbox to an internal recipient. + - Email from an internal mailbox to an external recipient. + - Email from an external mailbox to an internal recipient. ++4. Verify that the message was quarantined, and verify the admin notification results based on your anti-malware policy settings. For example, the admin email address that you specified is notified for internal or external message senders, with the default or customized notification messages. ++5. Delete the EICAR.TXT file after your testing is complete (so other users aren't unnecessarily alarmed by it). |
| security | Anti Malware Protection About | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-malware-protection-about.md | + + Title: Anti-malware protection +f1.keywords: + - NOCSH +++ Last updated : +audience: ITPro +++ms.localizationpriority: medium +search.appverid: + - MET150 +ms.assetid: 0e39a0ce-ab8b-4820-8b5e-93fbe1cc11e8 ++ - m365-security + - m365initiative-defender-office365 +description: Admins can learn about anti-malware protection and anti-malware policies that protect against viruses, spyware, and ransomware in Exchange Online Protection (EOP). ++++++# Anti-malware protection in EOP +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, email messages are automatically protected against malware by EOP. Some of the major categories of malware are: ++- **Viruses** that infect other programs and data, and spread through your computer or network looking for programs to infect. +- **Spyware** that gathers your personal information, such as sign-in information and personal data, and sends it back to its author. +- **Ransomware** that encrypts your data and demands payment to decrypt it. Anti-malware software doesn't help you decrypt encrypted files, but it can detect the malware payload that's associated with the ransomware. ++EOP offers multi-layered malware protection that's designed to catch all known malware in Windows, Linux, and Mac that travels into or out of your organization. The following options help provide anti-malware protection: ++- **Layered defenses against malware**: Multiple anti-malware scan engines help protect against both known and unknown threats. These engines include powerful heuristic detection to provide protection even during the early stages of a malware outbreak. This multi-engine approach has been shown to provide significantly more protection than using just one anti-malware engine. +- **Real-time threat response**: During some outbreaks, the anti-malware team may have enough information about a virus or other form of malware to write sophisticated policy rules that detect the threat, even before a definition is available from any of the scan engines used by the service. These rules are published to the global network every 2 hours to provide your organization with an extra layer of protection against attacks. +- **Fast anti-malware definition deployment**: The anti-malware team maintains close relationships with partners who develop anti-malware engines. As a result, the service can receive and integrate malware definitions and patches before they're publicly released. Our connection with these partners often allows us to develop our own remedies as well. The service checks for updated definitions for all anti-malware engines every hour. ++In EOP, messages that are found to contain malware in _any_ attachments are quarantined. Whether the recipients can view or otherwise interact with the quarantined messages is controlled by _quarantine policies_. By default, messages that were quarantined due to malware can only be viewed and released by admins. For more information, see the following topics: ++- [Quarantine policies](quarantine-policies.md) +- [Manage quarantined messages and files as an admin in EOP](manage-quarantined-messages-and-files.md). ++For more information about anti-malware protection, see the [Anti-malware protection FAQ](anti-malware-protection-faq-eop.yml). ++To configure anti-malware policies, see [Configure anti-malware policies](configure-anti-malware-policies.md). ++To submit malware to Microsoft, see [Report messages and files to Microsoft](report-junk-email-messages-to-microsoft.md). ++## Anti-malware policies ++Anti-malware policies control the settings and notification options for malware detections. The important settings in anti-malware policies are: ++- **Recipient filters**: For custom anti-malware policies, you can specify recipient conditions and exceptions that determine who the policy applies to. You can use these properties for conditions and exceptions: ++ - **Users** + - **Groups** + - **Domains** ++ You can only use a condition or exception once, but the condition or exception can contain multiple values. Multiple values of the same condition or exception use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). Different conditions or exceptions use AND logic (for example, _\<recipient1\>_ and _\<member of group 1\>_). ++ > [!IMPORTANT] + > Multiple different types of conditions or exceptions are not additive; they're inclusive. The policy is applied _only_ to those recipients that match _all_ of the specified recipient filters. For example, you configure a recipient filter condition in the policy with the following values: + > + > - Users: romain@contoso.com + > - Groups: Executives + > + > The policy is applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy is not applied to him. + > + > Likewise, if you use the same recipient filter as an exception to the policy, the policy is not applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy still applies to him. ++- **Enable the common attachments filter**: There are certain types of files that you really shouldn't send via email (for example, executable files). Why bother scanning these types of files for malware, when you should probably block them all, anyway? That's where the common attachments filter comes in. The file types that you specify are automatically treated as malware. ++ - The default file types: `ace, apk, app, appx, ani, arj, bat, cab, cmd,com, deb, dex, dll, docm, elf, exe, hta, img, iso, jar, jnlp, kext, lha, lib, library, lnk, lzh, macho, msc, msi, msix, msp, mst, pif, ppa, ppam, reg, rev, scf, scr, sct, sys, uif, vb, vbe, vbs, vxd, wsc, wsf, wsh, xll, xz, z`. + + - Additional predefined file types that you can select from in the Microsoft 365 Defender portal<sup>\*</sup>: `7z, 7zip, a, accdb, accde, action, ade, adp, appxbundle, asf, asp, aspx, avi, bin, bundle, bz, bz2, bzip2, cab, caction, cer, chm, command, cpl, crt, csh, css, der, dgz, dmg, doc, docx, dot, dotm, dtox, dylib, font, gz, gzip, hlp, htm, html, imp, inf, ins, ipa, isp, its, jnlp, js, jse, ksh, lqy, mad, maf, mag, mam, maq, mar, mas, mat, mav, maw, mda, mdb, mde, mdt, mdw, mdz, mht, mhtml, mscompress, msh, msh1, msh1xml, msh2, msh2xml, mshxml, msixbundle, o, obj, odp, ods, odt, one, onenote, ops, package, pages, pbix, pdb, pdf, php, pkg, plugin, pps, ppsm, ppsx, ppt, pptm, pptx, prf, prg, ps1, ps1xml, ps2, ps2xml, psc1, psc2, pst, pub, py, rar, rpm, rtf, scpt, service, sh, shb, shtm, shx, so, tar, tarz, terminal, tgz, tool, url, vhd, vsd, vsdm, vsdx, vsmacros, vss, vssx, vst, vstm, vstx, vsw, workflow, ws, xhtml, xla, xlam, xls, xlsb, xlsm, xlsx, xlt, xltm, xltx, zi, zip, zipx`. ++ <sup>\*</sup> You can enter any text value in the Defender portal or using the _FileTypes_ parameter in the [New-MalwareFilterPolicy](/powershell/module/exchange/new-malwarefilterpolicy) or [Set-MalwareFilterPolicy](/powershell/module/exchange/set-malwarefilterpolicy) cmdlets in Exchange Online PowerShell. ++ The common attachments filter uses best effort true-typing to detect the file type regardless of the filename extension. If true-typing fails or isn't supported for the specified file type, then simple extension matching is used. ++ - **When these file types are found**: When files are detected by the common attachments filter, you can choose to **Reject the message with a non-delivery report (NDR)** or **Quarantine the message**. ++- **Zero-hour auto purge (ZAP) for malware**: ZAP for malware quarantines messages that are found to contain malware _after_ they've been delivered to Exchange Online mailboxes. By default, ZAP for malware is turned on, and we recommend that you leave it on. ++- **Quarantine policy**: Select the quarantine policy that applies to messages that are quarantined as malware. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. By default, recipients don't receive notifications for messages that were quarantined as malware. For more information, see [Quarantine policies](quarantine-policies.md). ++- **Admin notifications**: You can specify an additional recipient (an admin) to receive notifications for malware detected in messages from internal or external senders. You can customize the **From address**, **subject**, and **message text** for internal and external notifications. ++ > [!NOTE] + > Admin notifications are sent only for _attachments_ that are classified as malware. + > + > The quarantine policy that's assigned to the anti-malware policy determines whether recipients receive email notifications for messages that were quarantined as malware. ++- **Priority**: If you create multiple custom anti-malware policies, you can specify the order that they're applied. No two policies can have the same priority, and policy processing stops after the first policy is applied. ++ For more information about the order of precedence and how multiple policies are evaluated and applied, see [Order and precedence of email protection](how-policies-and-protections-are-combined.md). ++### Anti-malware policies in the Microsoft 365 Defender portal vs PowerShell ++The basic elements of an anti-malware policy are: ++- **The malware filter policy**: Specifies the recipient notification, sender and admin notification, ZAP, and the common attachments filter settings. +- **The malware filter rule**: Specifies the priority and recipient filters (who the policy applies to) for a malware filter policy. ++The difference between these two elements isn't obvious when you manage anti-malware policies in the Microsoft 365 Defender portal: ++- When you create an anti-malware policy, you're actually creating a malware filter rule and the associated malware filter policy at the same time using the same name for both. +- When you modify an anti-malware policy, settings related to the name, priority, enabled or disabled, and recipient filters modify the malware filter rule. Other settings (recipient notification, sender and admin notification, ZAP, and the common attachments filter) modify the associated malware filter policy. +- When you remove an anti-malware policy, the malware filter rule and the associated malware filter policy are removed. ++In Exchange Online PowerShell or standalone EOP PowerShell, the difference between malware filter policies and malware filter rules is apparent. You manage malware filter policies by using the **\*-MalwareFilterPolicy** cmdlets, and you manage malware filter rules by using the **\*-MalwareFilterRule** cmdlets. ++- In PowerShell, you create the malware filter policy first, then you create the malware filter rule that identifies the policy that the rule applies to. +- In PowerShell, you modify the settings in the malware filter policy and the malware filter rule separately. +- When you remove a malware filter policy from PowerShell, the corresponding malware filter rule isn't automatically removed, and vice versa. ++### Default anti-malware policy ++Every organization has a built-in anti-malware policy named Default that has these properties: ++- The policy is applied to all recipients in the organization, even though there's no malware filter rule (recipient filters) associated with the policy. +- The policy has the custom priority value **Lowest** that you can't modify (the policy is always applied last). Any custom anti-malware policies that you create always have a higher priority than the policy named Default. +- The policy is the default policy (the **IsDefault** property has the value `True`), and you can't delete the default policy. |
| security | Anti Malware Protection For Spo Odfb Teams About | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-malware-protection-for-spo-odfb-teams-about.md | + + Title: Built-in virus protection in SharePoint Online, OneDrive, and Microsoft Teams +f1.keywords: + - NOCSH +++ Last updated : +audience: Admin +++ms.localizationpriority: medium +search.appverid: + - SPO160 + - MOE150 + - MET150 +ms.assetid: e3c6df61-8513-499d-ad8e-8a91770bff63 ++ - m365-security +description: Learn about how SharePoint Online detects viruses in files that users upload and prevents users from downloading or syncing the files. ++++++# Built-in virus protection in SharePoint Online, OneDrive, and Microsoft Teams +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) ++Microsoft 365 uses a common virus detection engine for scanning files that users upload to SharePoint Online, OneDrive, and Microsoft Teams. This protection is included with all subscriptions that include SharePoint Online, OneDrive, and Microsoft Teams. ++> [!IMPORTANT] +> The built-in anti-virus capabilities are a way to help contain viruses. They aren't intended as a single point of defense against malware for your environment. We encourage all customers to investigate and implement anti-malware protection at various layers and apply best practices for securing their enterprise infrastructure. ++## What happens if an infected file is uploaded to SharePoint Online? ++The Microsoft 365 virus detection engine scans files asynchronously (at some time after upload). If a file has not yet been scanned by the asynchronous virus detection process, and a user tries to download the file from the browser or from Teams, a scan on download is triggered by SharePoint before the download is allowed. **All file types are not automatically scanned**. Heuristics determine the files to scan. When a file is found to contain a virus, the file is flagged. ++Here's what happens: ++1. A user uploads a file to SharePoint Online. +2. SharePoint Online, as part of its virus scanning processes, later determines if the file meets the criteria for a scan. +3. If the file meets the criteria for a scan, the virus detection engine scans the file. +4. If a virus is found within the scanned file, the virus engine sets a property on the file that indicates the file is infected. ++## What happens when a user tries to download an infected file by using the browser? ++By default, users can download infected files from SharePoint Online. Here's what happens: ++1. In a web browser, a user tries to download a file from SharePoint Online that happens to be infected. +2. The user is shown a warning that a virus has been detected in the file. The user is given the option to proceed with the download and attempt to clean it using anti-virus software on their device. ++To change this behavior so users can't download infected files, even from the anti-virus warning window, admins can use the *DisallowInfectedFileDownload* parameter on the **[Set-SPOTenant](/powershell/module/sharepoint-online/Set-SPOTenant)** cmdlet in SharePoint Online PowerShell. The value $true for the *DisallowInfectedFileDownload* parameter completely blocks access to detected/blocked files for users. ++For instructions, see [Use SharePoint Online PowerShell to prevent users from downloading malicious files](turn-on-mdo-for-spo-odb-and-teams.md#step-2-recommended-use-sharepoint-online-powershell-to-prevent-users-from-downloading-malicious-files). ++## Can admins bypass *DisallowInfectedFileDownload* and extract infected files? ++SharePoint admins and global admins are allowed to do forensic file extractions of malware-infected files in SharePoint Online PowerShell with the [Get-SPOMalwareFileContent](/powershell/module/sharepoint-online/get-spomalwarefilecontent) cmdlet. Admins don't need access to the site that hosts the infected content. As long as the file has been marked as malware, admins can use **Get-SPOMalwareFileContent** to extract the file. ++For more information about the infected file, admins can use the **[Get-SPOMalwareFile](/powershell/module/sharepoint-online/get-spomalwarefile)** cmdlet to see the type of malware that was detected and the status of the infection. ++## What happens when the OneDrive sync client tries to sync an infected file? ++When a malicious file is uploaded to OneDrive, it will be synced to the local machine before it's marked as malware. After it's marked as malware, the user can't open the synced file anymore from their local machine. ++## Extended capabilities with Microsoft Defender for Office 365 ++Microsoft 365 organizations that have [Microsoft Defender for Office 365](defender-for-office-365.md) included in their subscription or purchased as an add-on can enable Safe Attachments for SharePoint, OneDrive, and Microsoft Teams for enhanced reporting and protection. For more information, see [Safe Attachments for SharePoint, OneDrive, and Microsoft Teams](mdo-for-spo-odb-and-teams.md). ++## Related articles ++[Malware and ransomware protection in Microsoft 365](/compliance/assurance/assurance-malware-and-ransomware-protection) ++For more information about anti-virus in SharePoint Online, OneDrive, and Microsoft Teams, see [Protect against threats](protect-against-threats.md) and [Turn on Safe Attachments for SharePoint, OneDrive, and Microsoft Teams](turn-on-mdo-for-spo-odb-and-teams.md). |
| security | Anti Phishing From Email Address Validation | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-from-email-address-validation.md | + + Title: How EOP validates the From address to prevent phishing +f1.keywords: + - NOCSH +++ Last updated : +audience: ITPro +++ms.localizationpriority: medium +search.appverid: + - OWC150 + - MET150 +ms.assetid: eef8408b-54d3-4d7d-9cf7-ad2af10b2e0e ++ - m365-security +description: Admins can learn about the types of email addresses that are accepted or rejected by Exchange Online Protection (EOP) and Outlook.com to help prevent phishing. ++++++# How EOP validates the From address to prevent phishing +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++Phishing attacks are a constant threat to any email organization. In addition to using [spoofed (forged) sender email addresses](anti-spoofing-protection.md), attackers often use values in the From address that violate internet standards. To help prevent this type of phishing, Exchange Online Protection (EOP) and Outlook.com now require inbound messages to include an RFC-compliant From address as described in this article. This enforcement was enabled in November 2017. ++**Notes**: ++- If you regularly receive email from organizations that have malformed From addresses as described in this article, encourage these organizations to update their email servers to comply with modern security standards. ++- The related Sender field (used by Send on Behalf and mailing lists) isn't affected by these requirements. For more information, see the following blog post: [What do we mean when we refer to the 'sender' of an email?](/archive/blogs/tzink/what-do-we-mean-when-we-refer-to-the-sender-of-an-email). ++## An overview of email message standards ++A standard SMTP email message consists of a *message envelope* and message content. The message envelope contains information that's required for transmitting and delivering the message between SMTP servers. The message content contains message header fields (collectively called the *message header*) and the message body. The message envelope is described in [RFC 5321](https://tools.ietf.org/html/rfc5321), and the message header is described in [RFC 5322](https://tools.ietf.org/html/rfc5322). Recipients never see the actual message envelope because it's generated by the message transmission process, and it isn't actually part of the message. ++- The `5321.MailFrom` address (also known as the **MAIL FROM** address, P1 sender, or envelope sender) is the email address that's used in the SMTP transmission of the message. This email address is typically recorded in the **Return-Path** header field in the message header (although it's possible for the sender to designate a different **Return-Path** email address). ++- The `5322.From` (also known as the From address or P2 sender) is the email address in the **From** header field, and is the sender's email address that's displayed in email clients. The From address is the focus of the requirements in this article. ++The From address is defined in detail across several RFCs (for example, RFC 5322 sections 3.2.3, 3.4, and 3.4.1, and [RFC 3696](https://tools.ietf.org/html/rfc3696)). There are many variations on addressing and what's considered valid or invalid. To keep it simple, we recommend the following format and definitions: ++`From: "Display Name" <EmailAddress>` ++- **Display Name**: An optional phrase that describes the owner of the email address. ++ - We recommend that you always enclose the display name in double quotation marks (") as shown. If the display name contains a comma, you *must* enclose the string in double quotation marks per RFC 5322. + - If the From address includes a display name, the EmailAddress value must be enclosed in angle brackets (< >) as shown. + - Microsoft strongly recommends that you insert a space between the display name and the email address. ++- **EmailAddress**: An email address uses the format `local-part@domain`: ++ - **local-part**: A string that identifies the mailbox associated with the address. This value is unique within the domain. Often, the mailbox owner's username or GUID is used. + - **domain**: The fully qualified domain name (FQDN) of the email server that hosts the mailbox identified by the local-part of the email address. ++ These are some additional considerations for the EmailAddress value: ++ - Only one email address. + - We recommend that you do not separate the angle brackets with spaces. + - Don't include additional text after the email address. ++## Examples of valid and invalid From addresses ++The following From email addresses are valid: ++- `From: sender@contoso.com` ++- `From: <sender@contoso.com>` ++- `From: < sender@contoso.com >` (Not recommended because there are spaces between the angle brackets and the email address.) ++- `From: "Sender, Example" <sender.example@contoso.com>` ++- `From: "Microsoft 365" <sender@contoso.com>` ++- `From: Microsoft 365 <sender@contoso.com>` (Not recommended because the display name is not enclosed in double quotation marks.) ++The following From email addresses are invalid: ++- `From: <firstname lastname@contoso.com>` (The email address contains a space.) ++- **No From address**: Some automated messages don't include a From address. In the past, when Microsoft 365 or Outlook.com received a message without a From address, the service added the following default From: address to make the message deliverable: ++ `From: <>` ++ Now, messages with a blank From address are no longer accepted. ++- `From: Microsoft 365 sender@contoso.com` (The display name is present, but the email address is not enclosed in angle brackets.) ++- `From: "Microsoft 365" <sender@contoso.com> (Sent by a process)` (Text after the email address.) ++- `From: Sender, Example <sender.example@contoso.com>` (The display name contains a comma, but is not enclosed in double quotation marks.) ++- `From: "Microsoft 365 <sender@contoso.com>"` (The whole value is incorrectly enclosed in double quotation marks.) ++- `From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com` (The display name is present, but the email address is not enclosed in angle brackets.) ++- `From: Microsoft 365<sender@contoso.com>` (No space between the display name and the left angle bracket.) ++- `From: "Microsoft 365"<sender@contoso.com>` (No space between the closing double quotation mark and the left angle bracket.) ++## Suppress auto-replies to your custom domain ++You can't use the value `From: <>` to suppress auto-replies. Instead, you need to set up a null MX record for your custom domain. Auto-replies (and all replies) are naturally suppressed because there is no published address that the responding server can send messages to. ++- Choose an email domain that can't receive email. For example, if your primary domain is contoso.com, you might choose noreply.contoso.com. ++- The null MX record for this domain consists of a single period. ++For example: ++```text +noreply.contoso.com IN MX . +``` ++For more information about setting up MX records, see [Create DNS records at any DNS hosting provider for Microsoft 365](../../admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider.md). ++For more information about publishing a null MX, see [RFC 7505](https://tools.ietf.org/html/rfc7505). ++## Override From address enforcement ++To bypass the From address requirements for inbound email, you can use the IP Allow List (connection filtering) or mail flow rules (also known as transport rules) as described in [Create safe sender lists in Microsoft 365](create-safe-sender-lists-in-office-365.md). ++You can't override the From address requirements for outbound email that you send from Microsoft 365. In addition, Outlook.com will not allow overrides of any kind, even through support. ++## Other ways to prevent and protect against cybercrimes in Microsoft 365 ++For more information on how you can strengthen your organization against phishing, spam, data breaches, and other threats, see [Best practices for securing Microsoft 365 for business plans](../../admin/security-and-compliance/secure-your-business-data.md). |
| security | Anti Phishing Mdo Impersonation Insight | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-mdo-impersonation-insight.md | + + Title: Impersonation insight +f1.keywords: + - NOCSH +++ Last updated :+audience: ITPro +++ms.localizationpriority: medium +search.appverid: + - MET150 + - MOE150 +ms.assetid: ++ - m365-security +description: Admins can learn how the impersonation insight works. They can quickly determine which senders are legitimately sending email into their organizations from domains that don't pass email authentication checks (SPF, DKIM, or DMARC). ++- seo-marvel-apr2020 +++++# Impersonation insight in Defender for Office 365 +++**Applies to** +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++Impersonation is where the sender of an email message looks very similar to a real or expected sender email address. Attackers often user impersonated sender email addresses in phishing or other types of attacks in an effort to gain the trust of the recipient. There are basically two types of impersonation: ++- **Domain impersonation**: Instead of lila@contoso.com, the impersonated sender's email address is lila@ćóntoso.com. +- **User impersonation**: Instead of michelle@contoso.com, the impersonated sender's email address is rnichell@contoso.com. ++Domain impersonation is different from [domain spoofing](anti-spoofing-protection.md), because the impersonated domain is typically a real, registered domain. Messages from senders in the impersonated domain can and often do pass regular email authentication checks that would otherwise identify spoofing attempts (SPF, DKIM, and DMARC). ++Impersonation protection is part of the anti-phishing policy settings that are exclusive to Microsoft Defender for Office 365. For more information about these settings, see [Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365](set-up-anti-phishing-policies.md#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365). ++You can use the impersonation insight in the Microsoft 365 Defender portal to quickly identify messages from impersonated senders or sender domains that you've configured for impersonation protection. ++## What do you need to know before you begin? ++- You open the Microsoft 365 Defender portal at <https://security.microsoft.com>. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. To go directly to the **Impersonation insight** page, use <https://security.microsoft.com/impersonationinsight>. ++- You need to be assigned permissions in the Microsoft 365 Defender portal before you can do the procedures in this article: + - **Organization Management** + - **Security Administrator** + - **Security Reader** + - **Global Reader** ++ For more information, see [Permissions in the Microsoft 365 Defender portal](permissions-microsoft-365-security-center.md). ++ **Note**: Adding users to the corresponding Azure Active Directory role in the Microsoft 365 admin center gives users the required permissions in the Microsoft 365 Defender portal _and_ permissions for other features in Microsoft 365. For more information, see [About admin roles](../../admin/add-users/about-admin-roles.md). ++- You enable and configure impersonation protection in anti-phishing policies in Microsoft Defender for Office 365. Impersonation protection is not enabled by default. For more information, see [Configure anti-phishing policies in Microsoft Defender for Office 365](configure-mdo-anti-phishing-policies.md). ++## Open the impersonation insight in the Microsoft 365 Defender portal ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, the impersonation insight looks like this: ++ :::image type="content" source="../../media/m365-sc-impersonation-insight.png" alt-text="The impersonation insight on the Anti-phishing policy page in the Microsoft 365 Defender portal." lightbox="../../media/m365-sc-impersonation-insight.png"::: ++ The insight has two modes: ++ - **Insight mode**: If impersonation protection is enabled and configured in any anti-phishing policies, the insight shows the number of detected messages from impersonated domains and impersonated users (senders) over the past seven days. This is the total of all detected impersonated senders from all anti-phishing policies. + - **What if mode**: If impersonation protection is not enabled and configured in any active anti-phishing policies, the insight shows you how many messages *would* have been detected by our impersonation protection capabilities over the past seven days. ++To view information about the impersonation detections, click **View impersonations** in the impersonation insight. ++## View information about messages from senders in impersonated domains ++On the **Impersonation insight** page that appears after you click **View impersonations** in the impersonation insight, verify that the **Domains** tab is selected. The **Domains** tab contains the following information: ++- **Sender Domain**: The impersonating domain, which is the domain that was used to send the email message. +- **Message count**: The number of messages from impersonating sender domain over the last 7 days. +- **Impersonation type**: This value shows the detected location of the impersonation (for example, **Domain in address**). +- **Impersonated domain(s)**: The impersonated domain, which should closely resemble the domain that's configured for impersonation protection in the anti-phishing policy. +- **Domain type**: This value is **Company domain** for internal domains or **Custom domain** for custom domains. +- **Policy**: The anti-phishing policy that detected the impersonated domain. +- **Allowed to impersonate**: One of the following values: + - **Yes**: The domain was configured as trusted domain (an exception for impersonation protection) in the anti-phishing policy. Messages from senders in the impersonated domain were detected, but allowed. + - **No**: The domain was configured for impersonation protection in the anti-phishing policy. Messages from senders in the impersonated domain were detected and acted upon based on the action for impersonated domains in the anti-phishing policy. ++You can click selected column headings to sort the results. ++To filter the results, you can use the  **Search** box to enter a comma-separated list of values to filter the results. ++### View details about messages from senders in impersonated domains ++On the **Domains** tab on the **Impersonation insight** page, select one of the available impersonation detections. The details flyout that appears contains the following information and features: ++- **Selection impersonation policy to modify**: Select the affected anti-phishing policy that you want to modify. Only polices where the impersonated domain is defined in the policy are available. Refer to the previous page to see which policy was actually responsible for detecting the impersonated domain (likely based on the recipient and the priority of the policy). +- **Add to the allowed to impersonation list**: Use this toggle to add or remove the sender from the **Trusted senders and domains** (impersonation exceptions) for the anti-phishing policy that you selected: + - If the **Allowed to impersonate** value for this entry was **No**, the toggle is off. To exempt all senders in this domain from evaluation by impersonation protection, slide the toggle to on: . The domain is added to the **Trusted domains** list in the impersonation protection settings of the anti-phishing policy. + - If the **Allowed to impersonate** value for this entry was **Yes**, the toggle is on. To return all senders in this domain to evaluation by impersonation protection, slide the toggle to off: . The domain is removed from the **Trusted domains** list in the impersonation protection settings of the anti-phishing policy. +- Why we caught this. +- What you need to do. +- A domain summary that list the impersonated domain. +- WhoIs data about the sender. +- A link to open [Threat Explorer](threat-explorer.md) to see additional details about the sender. +- Similar messages from the same sender that were delivered to your organization. ++## View information about messages from impersonated senders ++On the **Impersonation insight** page that appears after you click **View impersonations** in the impersonation insight, click the **Users** tab. The **Users** tab contains the following information: ++- **Sender**: The email address of the impersonating sender that sent the email message. +- **Message count**: The number of messages from the impersonating sender over the last 7 days. +- **Impersonation type**: This value is **User in display name**. +- **Impersonated user(s)**: The email address of the impersonated sender, which should closely resemble the user that's configured for impersonation protection in the anti-phishing policy. +- **User type**: This value shows the type of protection applied (for example, **Protected user** or **Mailbox Intelligence**). +- **Policy**: The anti-phishing policy that detected the impersonated sender. +- **Allowed to impersonate**: One of the following values: + - **Yes**: The sender was configured as trusted user (an exception for impersonation protection) in the anti-phishing policy. Messages from the impersonated sender were detected, but allowed. + - **No**: The sender was configured for impersonation protection in the anti-phishing policy. Messages from the impersonated sender were detected and acted upon based on the action for impersonated users in the anti-phishing policy. ++You can click selected column headings to sort the results. ++To filter the results, you can use the **Filter sender** box to enter a comma-separated list of values to filter the results. ++### View details about messages from impersonated senders ++On the **Users** tab on the **Impersonation insight** page, select one of the available impersonation detections. The details flyout that appears contains the following information and features: ++- **Selection impersonation policy to modify**: Select the affected anti-phishing policy that you want to modify. Only polices where the impersonated sender is defined in the policy are available. Refer to the previous page to see which policy was actually responsible for detecting the impersonated sender (likely based on the recipient and the priority of the policy). +- **Add to the allowed to impersonation list**: Use this toggle to add or remove the sender from the **Trusted senders and domains** (impersonation exceptions) for the anti-phishing policy that you selected: + - If the **Allowed to impersonate** value for this entry was **No**, the toggle is off. To exempt the sender from evaluation by impersonation protection, slide the toggle to on: . The sender is added to the **Trusted users** list in the impersonation protection settings of the anti-phishing policy. + - If the **Allowed to impersonate** value for this entry was **Yes**, the toggle is on. To return the sender to evaluation by impersonation protection, slide the toggle to off: . The sender is removed from the **Trusted users** list in the impersonation protection settings of the anti-phishing policy. +- Why we caught this. +- What you need to do. +- A sender summary that list the impersonated sender. +- WhoIs data about the sender. +- A link to open [Threat Explorer](threat-explorer.md) to see additional details about the sender. +- Similar messages from the same sender that were delivered to your organization. |
| security | Anti Phishing Policies About | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-policies-about.md | + + Title: Anti-phishing policies +f1.keywords: + - NOCSH ++++audience: ITPro + Last updated : ++ms.localizationpriority: medium +ms.assetid: 5a6f2d7f-d998-4f31-b4f5-f7cbf6f38578 ++ - m365-security ++ - seo-marvel-apr2020 +description: Admins can learn about the anti-phishing policies that are available in Exchange Online Protection (EOP) and Microsoft Defender for Office 365. +++search.appverid: met150 +++# Anti-phishing policies in Microsoft 365 +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++Policies to configure anti-phishing protection settings are available in Microsoft 365 organizations with Exchange Online mailboxes, standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, and Microsoft Defender for Office 365 organizations. ++Examples of Microsoft Defender for Office 365 organizations include: ++- Microsoft 365 Enterprise E5, Microsoft 365 Education A5, etc. +- [Microsoft 365 Enterprise](https://www.microsoft.com/microsoft-365/enterprise/home) +- [Microsoft 365 Business](https://www.microsoft.com/microsoft-365/business) +- [Microsoft Defender for Office 365 as an add-on](https://products.office.com/exchange/advance-threat-protection) ++The high-level differences between anti-phishing policies in EOP and anti-phishing policies in Defender for Office 365 are described in the following table: ++|Feature|Anti-phishing policies in EOP|Anti-phishing policies in Defender for Office 365| +||::|::| +|Automatically created default policy||| +|Create custom policies||| +|Common policy settings<sup>\*</sup>||| +|Spoof settings||| +|First contact safety tip||| +|Impersonation settings||| +|Advanced phishing thresholds||| ++<sup>\*</sup> In the default policy, the policy name, and description are read-only (the description is blank), and you can't specify who the policy applies to (the default policy applies to all recipients). ++To configure anti-phishing policies, see the following articles: ++- [Configure anti-phishing policies in EOP](configure-anti-phishing-policies-eop.md) +- [Configure anti-phishing policies in Microsoft Defender for Office 365](configure-mdo-anti-phishing-policies.md) ++The rest of this article describes the settings that are available in anti-phishing policies in EOP and Defender for Office 365. ++## Common policy settings ++The following policy settings are available in anti-phishing policies in EOP and Defender for Office 365: ++- **Name**: You can't rename the default anti-phishing policy. After you create a custom anti-phishing policy, you can't rename the policy in the Microsoft 365 Defender portal. ++- **Description** You can't add a description to the default anti-phishing policy, but you can add and change the description for custom policies that you create. ++- **Users, groups, and domains**: Identifies internal recipients that the anti-phishing policy applies to. This value is required in custom policies, and not available in the default policy (the default policy applies to all recipients). ++ You can only use a condition or exception once, but you can specify multiple values for the condition or exception. Multiple values of the same condition or exception use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). Different conditions or exceptions use AND logic (for example, _\<recipient1\>_ and _\<member of group 1\>_). ++ - **Users**: One or more mailboxes, mail users, or mail contacts in your organization. + - **Groups**: One or more groups in your organization. + - **Domains**: One or more of the configured [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in Microsoft 365. ++ - **Exclude these users, groups, and domains**: Exceptions for the policy. The settings and behavior are exactly like the conditions: + - **Users** + - **Groups** + - **Domains** ++ > [!NOTE] + > At least one selection in the **Users, groups, and domains** settings is required in custom anti-phishing policies to identify the message **recipients** <u>that the policy applies to</u>. Anti-phishing policies in Defender for Office 365 also have [impersonation settings](#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) where you can specify individual sender email addresses or sender domains <u>that will receive impersonation protection</u> as described later in this article. + > + > Multiple different types of conditions or exceptions are not additive; they're inclusive. The policy is applied _only_ to those recipients that match _all_ of the specified recipient filters. For example, you configure a recipient filter condition in the policy with the following values: + > + > - Users: romain@contoso.com + > - Groups: Executives + > + > The policy is applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy is not applied to him. + > + > Likewise, if you use the same recipient filter as an exception to the policy, the policy is not applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy still applies to him. ++## Spoof settings ++Spoofing is when the From address in an email message (the sender address that's shown in email clients) doesn't match the domain of the email source. For more information about spoofing, see [Anti-spoofing protection in Microsoft 365](anti-spoofing-protection.md). ++The following spoof settings are available in anti-phishing policies in EOP and Defender for Office 365: ++- **Enable spoof intelligence**: Turns spoof intelligence on or off. We recommend that you leave it turned on. ++ When spoof intelligence is enabled, the **spoof intelligence insight** shows spoofed senders that were automatically detected and allowed or blocked by spoof intelligence. You can manually override the spoof intelligence verdict to allow or block the detected spoofed senders from within the insight. But when you do, the spoofed sender disappears from the spoof intelligence insight, and is now visible only on the **Spoofed senders** tab in the Tenant Allow/Block List. You can also manually create allow or block entries for spoofed senders in the Tenant Allow/Block List. For more information, see the following articles: ++ - [Spoof intelligence insight in EOP](learn-about-spoof-intelligence.md) + - [Manage the Tenant Allow/Block List in EOP](manage-tenant-allow-block-list.md) ++ > [!NOTE] + > + > - Anti-spoofing protection is enabled by default in the default anti-phishing policy and in any new custom anti-phishing policies that you create. + > - You don't need to disable anti-spoofing protection if your MX record doesn't point to Microsoft 365; you enable Enhanced Filtering for Connectors instead. For instructions, see [Enhanced Filtering for Connectors in Exchange Online](/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors). + > - Disabling anti-spoofing protection only disables _implicit_ spoofing protection from [composite authentication](email-validation-and-authentication.md#composite-authentication) checks. If the sender fails _explicit_ [DMARC](use-dmarc-to-validate-email.md) checks where the policy is set to quarantine or reject, the message is still quarantined or rejected. ++- **Unauthenticated sender indicators**: Available in the **Safety tips & indicators** section only when spoof intelligence is turned on. See the details in the next section. +- **Actions**: For messages from blocked spoofed senders (automatically blocked by spoof intelligence or manually blocked in the Tenant Allow/Block list), you can also specify the action to take on the messages: + - **Move messages to the recipients' Junk Email folders**: This is the default value. The message is delivered to the mailbox and moved to the Junk Email folder. For more information, see [Configure junk email settings on Exchange Online mailboxes in Microsoft 365](configure-junk-email-settings-on-exo-mailboxes.md). + - **Quarantine the message**: Sends the message to quarantine instead of the intended recipients. For information about quarantine, see the following articles: + - [Quarantine in Microsoft 365](quarantine-email-messages.md) + - [Manage quarantined messages and files as an admin in Microsoft 365](manage-quarantined-messages-and-files.md) + - [Find and release quarantined messages as a user in Microsoft 365](find-and-release-quarantined-messages-as-a-user.md) ++ If you select **Quarantine the message**, you can also select the quarantine policy that applies to messages that were quarantined by spoof intelligence protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++### Unauthenticated sender indicators ++Unauthenticated sender indicators are part of the [Spoof settings](#spoof-settings) that are available in the **Safety tips & indicators** section in anti-phishing policies in both EOP and Defender for Office 365. The following settings are available only when spoof intelligence is turned on: ++- **Show (?) for unauthenticated senders for spoof**: Adds a question mark to the sender's photo in the From box if the message does not pass SPF or DKIM checks **and** the message does not pass DMARC or [composite authentication](email-validation-and-authentication.md#composite-authentication). When this setting is turned off, the question mark isn't added to the sender's photo. ++- **Show "via" tag**: Adds the via tag (chris@contoso.com <u>via</u> fabrikam.com) in the From box if the domain in the From address (the message sender that's displayed in email clients) is different from the domain in the DKIM signature or the **MAIL FROM** address. For more information about these addresses, see [An overview of email message standards](anti-phishing-from-email-address-validation.md#an-overview-of-email-message-standards). ++To prevent the question mark or via tag from being added to messages from specific senders, you have the following options: ++- Allow the spoofed sender in the [spoof intelligence insight](learn-about-spoof-intelligence.md) or manually in the [Tenant Allow/Block List](manage-tenant-allow-block-list.md). Allowing the spoofed sender will prevent the via tag from appearing in messages from the sender, even if the **Show "via" tag** setting is turned on in the policy. +- [Configure email authentication](email-validation-and-authentication.md#configure-email-authentication-for-domains-you-own) for the sender domain. + - For the question mark in the sender's photo, SPF or DKIM are the most important. + - For the via tag, confirm the domain in the DKIM signature or the **MAIL FROM** address matches (or is a subdomain of) the domain in the From address. ++For more information, see [Identify suspicious messages in Outlook.com and Outlook on the web](https://support.microsoft.com/office/3d44102b-6ce3-4f7c-a359-b623bec82206) ++## First contact safety tip ++The **Show first contact safety tip** settings is available in EOP and Defender for Office 365 organizations, and has no dependency on spoof intelligence or impersonation protection settings. The safety tip is shown to recipients in the following scenarios: ++- The first time they get a message from a sender +- They don't often get messages from the sender. ++++This capability adds an extra layer of security protection against potential impersonation attacks, so we recommend that you turn it on. ++The first contact safety tip also replaces the need to create mail flow rules (also known as transport rules) that add the header named **X-MS-Exchange-EnableFirstContactSafetyTip** with the value **Enable** to messages (although this capability is still available). ++> [!NOTE] +> If the message has multiple recipients, whether the tip is shown and to whom is based on a majority model. If the majority of recipients have never or don't often receive messages from the sender, then the affected recipients will receive the **Some people who received this message...** tip. If you're concerned that this behavior exposes the communication habits of one recipient to another, you should not enable the first contact safety tip and continue to use mail flow rules instead. ++## Exclusive settings in anti-phishing policies in Microsoft Defender for Office 365 ++This section describes the policy settings that are only available in anti-phishing policies in Defender for Office 365. ++> [!NOTE] +> The default anti-phishing policy in Defender for Office 365 provides [spoof protection](set-up-anti-phishing-policies.md#spoof-settings) and mailbox intelligence for all recipients. However, the other available [impersonation protection](#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) features and [advanced settings](set-up-anti-phishing-policies.md#advanced-phishing-thresholds-in-anti-phishing-policies-in-microsoft-defender-for-office-365) are not configured or enabled in the default policy. To enable all protection features, modify the default anti-phishing policy or create additional anti-phishing policies. ++### Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365 ++Impersonation is where the sender or the sender's email domain in a message looks similar to a real sender or domain: ++- An example impersonation of the domain contoso.com is ćóntoso.com. +- User impersonation is the combination of the user's display name and email address. For example, Valeria Barrios (vbarrios@contoso.com) might be impersonated as Valeria Barrios, but with a completely different email address. ++> [!NOTE] +> Impersonation protection looks for domains that are similar. For example, if your domain is contoso.com, we check for different top-level domains (.com, .biz, etc.) as impersonation attempts, but also domains that are even somewhat similar. For example, contosososo.com or contoabcdef.com might be seen as impersonation attempts of contoso.com. ++An impersonated domain might otherwise be considered legitimate (registered domain, configured email authentication records, etc.), except its intent is to deceive recipients. ++The following impersonation settings are only available in anti-phishing policies in Defender for Office 365: ++- **Enable users to protect**: Prevents the specified internal or external email addresses from being impersonated **as message senders**. For example, you receive an email message from the Vice President of your company asking you to send her some internal company information. Would you do it? Many people would send the reply without thinking. ++ You can use protected users to add internal and external sender email addresses to protect from impersonation. This list of **senders** that are protected from user impersonation is different from the list of **recipients** that the policy applies to (all recipients for the default policy; specific recipients as configured in the **Users, groups, and domains** setting in the [Common policy settings](#common-policy-settings) section). ++ > [!NOTE] + > + > - In each anti-phishing policy, you can specify a maximum of 350 protected users (sender email addresses). You can't specify the same protected user in multiple policies. So, regardless of how many policies apply to a recipient, the maximum number of protected users (sender email addresses) for each individual recipient is 350. For more information about policy priority and how policy processing stops after the first policy is applied, see [Order and precedence of email protection](how-policies-and-protections-are-combined.md). + > - User impersonation protection does not work if the sender and recipient have previously communicated via email. If the sender and recipient have never communicated via email, the message will be identified as an impersonation attempt. ++ By default, no sender email addresses are configured for impersonation protection in **Users to protect**. Therefore, by default, no sender email addresses are covered by impersonation protection, either in the default policy or in custom policies. ++ When you add internal or external email addresses to the **Users to protect** list, messages from those **senders** are subject to impersonation protection checks. The message is checked for impersonation **if** the message is sent to a **recipient** that the policy applies to (all recipients for the default policy; **Users, groups, and domains** recipients in custom policies). If impersonation is detected in the sender's email address, the impersonation protections actions for users are applied to the message (what to do with the message, whether to show impersonated users safety tips, etc.). ++- **Enable domains to protect**: Prevents the specified domains from being impersonated **in the message sender's domain**. For example, all domains that you own ([accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains)) or specific custom domains (domains you own or partner domains). This list of **sender domains** that are protected from impersonation is different from the list of **recipients** that the policy applies to (all recipients for the default policy; specific recipients as configured in the **Users, groups, and domains** setting in the [Common policy settings](#common-policy-settings) section). ++ > [!NOTE] + > You can specify a maximum of 50 custom domains in each anti-phishing policy. ++ By default, no sender domains are configured for impersonation protection in **Enable domains to protect**. Therefore, by default, no sender domains are covered by impersonation protection, either in the default policy or in custom policies. ++ When you add domains to the **Enable domains to protect** list, messages from **senders in those domains** are subject to impersonation protection checks. The message is checked for impersonation **if** the message is sent to a **recipient** that the policy applies to (all recipients for the default policy; **Users, groups, and domains** recipients in custom policies). If impersonation is detected in the sender's domain, the impersonation protection actions for domains are applied to the message (what to do with the message, whether to show impersonated users safety tips, etc.). ++- **Actions**: Choose the action to take on inbound messages that contain impersonation attempts against the protected users and protected domains in the policy. You can specify different actions for impersonation of protected users vs. impersonation of protected domains: + - **Don't apply any action** + - **Redirect message to other email addresses**: Sends the message to the specified recipients instead of the intended recipients. + - **Move messages to the recipients' Junk Email folders**: The message is delivered to the mailbox and moved to the Junk Email folder. For more information, see [Configure junk email settings on Exchange Online mailboxes in Microsoft 365](configure-junk-email-settings-on-exo-mailboxes.md). + - **Quarantine the message**: Sends the message to quarantine instead of the intended recipients. For information about quarantine, see the following articles: + - [Quarantine in Microsoft 365](quarantine-email-messages.md) + - [Manage quarantined messages and files as an admin in Microsoft 365](manage-quarantined-messages-and-files.md) + - [Find and release quarantined messages as a user in Microsoft 365](find-and-release-quarantined-messages-as-a-user.md) ++ If you select **Quarantine the message**, you can also select the quarantine policy that applies to messages that are quarantined by user impersonation or domain impersonation protection. Quarantine policies define what users are able to do to quarantined messages. For more information, see [Quarantine policies](quarantine-policies.md). ++ - **Deliver the message and add other addresses to the Bcc line**: Deliver the message to the intended recipients and silently deliver the message to the specified recipients. + - **Delete the message before it's delivered**: Silently deletes the entire message, including all attachments. ++- **Impersonation safety tips**: Turn on or turn off the following impersonation safety tips that will appear messages that fail impersonation checks: + - **Show tip for impersonated users**: The From address contains an **Enable users to protect** user. Available only if **Enable users to protect** is turned on and configured. + - **Show tip for impersonated domains**: The From address contains an **Enable domains to protect** domain. Available only if **Enable domains to protect** is turned on and configured. + - **Show tip for unusual characters**: The From address contains unusual character sets (for example, mathematical symbols and text or a mix of uppercase and lowercase letters) in an **Enable users to protect** sender or an **Enable domains to protect** sender domain. Available only if **Enable users to protect** _or_ **Enable domains to protect** is turned on and configured. ++- **Enable mailbox intelligence**: Enables or disables artificial intelligence (AI) that determines user email patterns with their frequent contacts. This setting helps the AI distinguish between messages from legitimate and impersonated senders. ++ For example, Gabriela Laureano (glaureano@contoso.com) is the CEO of your company, so you add her as a protected sender in the **Enable users to protect** settings of the policy. But, some of the recipients that the policy applies to communicate regularly with a vendor who is also named Gabriela Laureano (glaureano@fabrikam.com). Because those recipients have a communication history with glaureano@fabrikam.com, mailbox intelligence will not identify messages from glaureano@fabrikam.com as an impersonation attempt of glaureano@contoso.com for those recipients. ++ To use frequent contacts that were learned by mailbox intelligence (and lack thereof) to help protect users from impersonation attacks, you can turn on **Enable intelligence impersonation protection** after you turn on **Enable mailbox intelligence**. ++- **Enable intelligence impersonation protection**: Turn on this setting to specify the action to take on messages for impersonation detections from mailbox intelligence results: + - **Don't apply any action**: Note that this value has the same result as turning on **Mailbox intelligence** but turning off **Enable intelligence impersonation protection**. + - **Redirect message to other email addresses** + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, you can also select the quarantine policy that applies to messages that are quarantined by mailbox intelligence protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). + - **Deliver the message and add other addresses to the Bcc line** + - **Delete the message before it's delivered** ++- **Add trusted senders and domains**: Exceptions to the impersonation protection settings. Messages from the specified senders and sender domains are never classified as impersonation-based attacks by the policy. In other words, the action for protected senders, protected domains, or mailbox intelligence protection aren't applied to these trusted senders or sender domains. The maximum limit for these lists is 1024 entries. ++ > [!NOTE] + > + > - If Microsoft 365 system messages from the following senders are identified as impersonation attempts, you can add the senders to the trusted senders list: + > - `noreply@email.teams.microsoft.com` + > - `noreply@emeaemail.teams.microsoft.com` + > - `no-reply@sharepointonline.com` + > + > - Trusted domain entries don't include subdomains of the specified domain. You need to add an entry for each subdomain. ++### Advanced phishing thresholds in anti-phishing policies in Microsoft Defender for Office 365 ++The following advanced phishing thresholds are only available in anti-phishing policies in Defender for Office 365. These thresholds control the sensitivity for applying machine learning models to messages to determine a phishing verdict: ++- **1 - Standard**: This is the default value. The severity of the action that's taken on the message depends on the degree of confidence that the message is phishing (low, medium, high, or very high confidence). For example, messages that are identified as phishing with a very high degree of confidence have the most severe actions applied, while messages that are identified as phishing with a low degree of confidence have less severe actions applied. +- **2 - Aggressive**: Messages that are identified as phishing with a high degree of confidence are treated as if they were identified with a very high degree of confidence. +- **3 - More aggressive**: Messages that are identified as phishing with a medium or high degree of confidence are treated as if they were identified with a very high degree of confidence. +- **4 - Most aggressive**: Messages that are identified as phishing with a low, medium, or high degree of confidence are treated as if they were identified with a very high degree of confidence. ++The chance of false positives (good messages marked as bad) increases as you increase this setting. For information about the recommended settings, see [anti-phishing policy in Microsoft Defender for Office 365 settings](recommended-settings-for-eop-and-office365.md#anti-phishing-policy-settings-in-microsoft-defender-for-office-365). |
| security | Anti Phishing Policies Eop Configure | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-policies-eop-configure.md | + + Title: Configure anti-phishing policies in EOP +f1.keywords: + - NOCSH ++++audience: ITPro + Last updated :++ms.localizationpriority: medium +ms.assetid: ++ - m365-security ++description: Admins can learn how to create, modify, and delete the anti-phishing policies that are available in Exchange Online Protection (EOP) organizations with or without Exchange Online mailboxes. +++search.appverid: met150 +++# Configure anti-phishing policies in EOP +++**Applies to** +- [Exchange Online Protection](exchange-online-protection-overview.md) ++In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, there's a default anti-phishing policy that contains a limited number of anti-spoofing features that are enabled by default. For more information, see [Spoof settings in anti-phishing policies](set-up-anti-phishing-policies.md#spoof-settings). ++Admins can view, edit, and configure (but not delete) the default anti-phishing policy. For greater granularity, you can also create custom anti-phishing policies that apply to specific users, groups, or domains in your organization. Custom policies always take precedence over the default policy, but you can change the priority (running order) of your custom policies. ++Organizations with Exchange Online mailboxes can configure anti-phishing policies in the Microsoft 365 Defender portal or in Exchange Online PowerShell. Standalone EOP organizations can only use the Microsoft 365 Defender portal. ++For information about creating and modifying the more advanced anti-phishing policies that are available in Microsoft Defender for Office 365, see [Configure anti-phishing policies in Microsoft Defender for Office 365](configure-mdo-anti-phishing-policies.md). ++The basic elements of an anti-phishing policy are: ++- **The anti-phish policy**: Specifies the phishing protections to enable or disable, and the actions to apply options. +- **The anti-phish rule**: Specifies the priority and recipient filters (who the policy applies to) for an anti-phish policy. ++The difference between these two elements isn't obvious when you manage anti-phishing policies in the Microsoft 365 Defender portal: ++- When you create an anti-phishing policy, you're actually creating an anti-phish rule and the associated anti-phish policy at the same time using the same name for both. +- When you modify an anti-phishing policy, settings related to the name, priority, enabled or disabled, and recipient filters modify the anti-phish rule. All other settings modify the associated anti-phish policy. +- When you remove an anti-phishing policy, the anti-phish rule and the associated anti-phish policy are removed. ++In Exchange Online PowerShell, you manage the policy and the rule separately. For more information, see the [Use Exchange Online PowerShell to configure anti-phishing policies](#use-exchange-online-powershell-to-configure-anti-phishing-policies) section later in this article. ++Every organization has a built-in anti-phishing policy named Office365 AntiPhish Default that has these properties: ++- The policy is applied to all recipients in the organization, even though there's no anti-phish rule (recipient filters) associated with the policy. +- The policy has the custom priority value **Lowest** that you can't modify (the policy is always applied last). Any custom policies that you create always have a higher priority. +- The policy is the default policy (the **IsDefault** property has the value `True`), and you can't delete the default policy. ++To increase the effectiveness of anti-phishing protection, you can create custom anti-phishing policies with stricter settings that are applied to specific users or groups of users. ++## What do you need to know before you begin? ++- You open the Microsoft 365 Defender portal at <https://security.microsoft.com>. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++- To connect to Exchange Online PowerShell, see [Connect to Exchange Online PowerShell](/powershell/exchange/connect-to-exchange-online-powershell). ++ You can't manage anti-phishing policies in standalone EOP PowerShell. ++- You need to be assigned permissions in **Exchange Online** before you can do the procedures in this article: + - To add, modify, and delete anti-phishing policies, you need to be a member of the **Organization Management** or **Security Administrator** role groups. + - For read-only access to anti-phishing policies, you need to be a member of the **Global Reader** or **Security Reader** role groups. ++ For more information, see [Permissions in Exchange Online](/exchange/permissions-exo/permissions-exo). ++ **Notes**: ++ - Adding users to the corresponding Azure Active Directory role in the Microsoft 365 admin center gives users the required permissions _and_ permissions for other features in Microsoft 365. For more information, see [About admin roles](../../admin/add-users/about-admin-roles.md). + - The **View-Only Organization Management** role group in [Exchange Online](/Exchange/permissions-exo/permissions-exo#role-groups) also gives read-only access to the feature<sup>\*</sup>. ++- For our recommended settings for anti-phishing policies, see [EOP anti-phishing policy settings](recommended-settings-for-eop-and-office365.md#eop-anti-phishing-policy-settings). ++- Allow up to 30 minutes for the updated policy to be applied. ++- For information about where anti-phishing policies are applied in the filtering pipeline, see [Order and precedence of email protection](how-policies-and-protections-are-combined.md). ++## Use the Microsoft 365 Defender portal to create anti-phishing policies ++Creating a custom anti-phishing policy in the Microsoft 365 Defender portal creates the anti-phish rule and the associated anti-phish policy at the same time using the same name for both. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, click  **Create**. ++3. The policy wizard opens. On the **Policy name** page, configure these settings: + - **Name**: Enter a unique, descriptive name for the policy. + - **Description**: Enter an optional description for the policy. ++ When you're finished, click **Next**. ++4. On the **Users, groups, and domains** page that appears, identify the internal recipients that the policy applies to (recipient conditions): + - **Users**: The specified mailboxes, mail users, or mail contacts. + - **Groups**: + - Members of the specified distribution groups or mail-enabled security groups. + - The specified Microsoft 365 Groups. + - **Domains**: All recipients in the specified [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in your organization. ++ Click in the appropriate box, start typing a value, and select the value that you want from the results. Repeat this process as many times as necessary. To remove an existing value, click remove  next to the value. ++ For users or groups, you can use most identifiers (name, display name, alias, email address, account name, etc.), but the corresponding display name is shown in the results. For users, enter an asterisk (\*) by itself to see all available values. ++ Multiple values in the same condition use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). Different conditions use AND logic (for example, _\<recipient1\>_ and _\<member of group 1\>_). ++ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions. The settings and behavior are exactly like the conditions. ++ > [!IMPORTANT] + > Multiple different types of conditions or exceptions are not additive; they're inclusive. The policy is applied _only_ to those recipients that match _all_ of the specified recipient filters. For example, you configure a recipient filter condition in the policy with the following values: + > + > - Users: romain@contoso.com + > - Groups: Executives + > + > The policy is applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy is not applied to him. + > + > Likewise, if you use the same recipient filter as an exception to the policy, the policy is not applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy still applies to him. ++ When you're finished, click **Next**. ++5. On the **Phishing threshold & protection** page that appears, use the **Enable spoof intelligence** check box to turn spoof intelligence on or off. The default value is on (selected), and we recommend that you leave it on. You configure the action to take on blocked spoofed messages on the next page. ++ To turn off spoof intelligence, clear the check box. ++ > [!NOTE] + > You don't need to turn off anti-spoofing protection if your MX record doesn't point to Microsoft 365; you enable Enhanced Filtering for Connectors instead. For instructions, see [Enhanced Filtering for Connectors in Exchange Online](/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors). ++ When you're finished, click **Next**. ++6. On the **Actions** page that appears, configure the following settings: + - **If message is detected as spoof**: This setting is available only if you selected **Enable spoof intelligence** on the previous page. Select one of the following actions in the drop down list for messages from blocked spoofed senders: + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, an **Apply quarantine policy** box appears where you select the quarantine policy that applies to messages that are quarantined by spoof intelligence protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++ A blank **Apply quarantine policy** value means the default quarantine policy is used (DefaultFullAccessPolicy for spoof intelligence detections). When you later edit the anti-phishing policy or view the settings, the default quarantine policy name is shown. For more information about default quarantine policies that are used for supported protection filtering verdicts, see [this table](quarantine-policies.md#step-2-assign-a-quarantine-policy-to-supported-features). ++ - **Safety tips & indicators**: + - **Show first contact safety tip**: For more information, see [First contact safety tip](set-up-anti-phishing-policies.md#first-contact-safety-tip). + - **Show (?) for unauthenticated senders for spoof**<sup>\*</sup>: Adds a question mark (?) to the sender's photo in the From box in Outlook if the message does not pass SPF or DKIM checks **and** the message does not pass DMARC or [composite authentication](email-validation-and-authentication.md#composite-authentication). + - **Show "via" tag**<sup>\*</sup>: Adds a via tag (chris@contoso.com via fabrikam.com) to the From address if it's different from the domain in the DKIM signature or the **MAIL FROM** address. ++ To turn on a setting, select the check box. To turn it off, clear the check box. ++ <sup>\*</sup> This setting is available only if you selected **Enable spoof intelligence** on the previous page. For more information, see [Unauthenticated sender indicators](set-up-anti-phishing-policies.md#unauthenticated-sender-indicators). ++ When you're finished, click **Next**. ++7. On the **Review** page that appears, review your settings. You can select **Edit** in each section to modify the settings within the section. Or you can click **Back** or select the specific page in the wizard. ++ When you're finished, click **Submit**. ++8. On the confirmation page that appears, click **Done**. ++## Use the Microsoft 365 Defender portal to view anti-phishing policies ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, the following properties are displayed in the list of policies: ++ - **Name** + - **Status** + - **Priority** + - **Last modified** ++3. When you select a policy by clicking on the name, the policy settings are displayed in a flyout. ++## Use the Microsoft 365 Defender portal to modify anti-phishing policies ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a policy from the list by clicking on the name. ++3. In the policy details flyout that appears, select **Edit** in each section to modify the settings within the section. For more information about the settings, see the [Use the Microsoft 365 Defender portal to create anti-phishing policies](#use-the-microsoft-365-defender-portal-to-create-anti-phishing-policies) section earlier in this article. ++ For the default anti-phishing policy, the **Users, groups, and domains** section isn't available (the policy applies to everyone), and you can't rename the policy. ++To enable or disable a policy or set the policy priority order, see the following sections. ++### Enable or disable custom anti-phishing policies ++You can't disable the default anti-phishing policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see one of the following values: + - **Policy off**: To turn on the policy, click  **Turn on** . + - **Policy on**: To turn off the policy, click  **Turn off**. ++4. In the confirmation dialog that appears, click **Turn on** or **Turn off**. ++5. Click **Close** in the policy details flyout. ++Back on the main policy page, the **Status** value of the policy will be **On** or **Off**. ++### Set the priority of custom anti-phishing policies ++By default, anti-phishing policies are given a priority that's based on the order they were created in (newer policies are lower priority than older policies). A lower priority number indicates a higher priority for the policy (0 is the highest), and policies are processed in priority order (higher priority policies are processed before lower priority policies). No two policies can have the same priority, and policy processing stops after the first policy is applied. ++To change the priority of a policy, you click **Increase priority** or **Decrease priority** in the properties of the policy (you can't directly modify the **Priority** number in the Microsoft 365 Defender portal). Changing the priority of a policy only makes sense if you have multiple policies. ++ **Notes**: ++- In the Microsoft 365 Defender portal, you can only change the priority of the anti-phishing policy after you create it. In PowerShell, you can override the default priority when you create the anti-phish rule (which can affect the priority of existing rules). +- Anti-phishing policies are processed in the order that they're displayed (the first policy has the **Priority** value 0). The default anti-phishing policy has the priority value **Lowest**, and you can't change it. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see **Increase priority** or **Decrease priority** based on the current priority value and the number of custom policies: + - The policy with the **Priority** value **0** has only the **Decrease priority** option available. + - The policy with the lowest **Priority** value (for example, **3**) has only the **Increase priority** option available. + - If you have three or more policies, the policies between the highest and lowest priority values have both the **Increase priority** and **Decrease priority** options available. ++ Click  **Increase priority** or  **Decrease priority** to change the **Priority** value. ++4. When you're finished, click **Close** in the policy details flyout. ++## Use the Microsoft 365 Defender portal to remove custom anti-phishing policies ++When you use the Microsoft 365 Defender portal to remove a custom anti-phishing policy, the anti-phish rule and the corresponding anti-phish policy are both deleted. You can't remove the default anti-phishing policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, click  **More actions** \>  **Delete policy**. ++4. In the confirmation dialog that appears, click **Yes**. ++## Use Exchange Online PowerShell to configure anti-phishing policies ++As previously described, an anti-phishing policy consists of an anti-phish policy and an anti-phish rule. ++In Exchange Online PowerShell, the difference between anti-phish policies and anti-phish rules is apparent. You manage anti-phish policies by using the **\*-AntiPhishPolicy** cmdlets, and you manage anti-phish rules by using the **\*-AntiPhishRule** cmdlets. ++- In PowerShell, you create the anti-phish policy first, then you create the anti-phish rule that identifies the policy that the rule applies to. +- In PowerShell, you modify the settings in the anti-phish policy and the anti-phish rule separately. +- When you remove an anti-phish policy from PowerShell, the corresponding anti-phish rule isn't automatically removed, and vice versa. ++> [!NOTE] +> The following PowerShell procedures aren't available in standalone EOP organizations using Exchange Online Protection PowerShell. ++### Use PowerShell to create anti-phishing policies ++Creating an anti-phishing policy in PowerShell is a two-step process: ++1. Create the anti-phish policy. +2. Create the anti-phish rule that specifies the anti-phish policy that the rule applies to. ++ **Notes**: ++- You can create a new anti-phish rule and assign an existing, unassociated anti-phish policy to it. An anti-phish rule can't be associated with more than one anti-phish policy. ++- You can configure the following settings on new anti-phish policies in PowerShell that aren't available in the Microsoft 365 Defender portal until after you create the policy: ++ - Create the new policy as disabled (_Enabled_ `$false` on the **New-AntiPhishRule** cmdlet). + - Set the priority of the policy during creation (_Priority_ _\<Number\>_) on the **New-AntiPhishRule** cmdlet). ++- A new anti-phish policy that you create in PowerShell isn't visible in the Microsoft 365 Defender portal until you assign the policy to an anti-phish rule. ++#### Step 1: Use PowerShell to create an anti-phish policy ++To create an anti-phish policy, use this syntax: ++```PowerShell +New-AntiPhishPolicy -Name "<PolicyName>" [-AdminDisplayName "<Comments>"] [-EnableSpoofIntelligence <$true | $false>] [-AuthenticationFailAction <MoveToJmf | Quarantine>] [-EnableUnauthenticatedSender <$true | $false>] [-EnableViaTag <$true | $false>] [-SpoofQuarantineTag <QuarantineTagName>] +``` ++This example creates an anti-phish policy named Research Quarantine with the following settings: ++- The description is: Research department policy. +- Changes the default action for spoofing detections to Quarantine and uses the default [quarantine policy](quarantine-policies.md) for the quarantined messages (we aren't using the _SpoofQuarantineTag_ parameter). ++```powershell +New-AntiPhishPolicy -Name "Monitor Policy" -AdminDisplayName "Research department policy" -AuthenticationFailAction Quarantine +``` ++For detailed syntax and parameter information, see [New-AntiPhishPolicy](/powershell/module/exchange/New-AntiPhishPolicy). ++> [!NOTE] +> For detailed instructions to specify the [quarantine policies](quarantine-policies.md) to use in an anti-phish policy, see [Use PowerShell to specify the quarantine policy in anti-phishing policies](quarantine-policies.md#anti-phishing-policies). ++#### Step 2: Use PowerShell to create an anti-phish rule ++To create an anti-phish rule, use this syntax: ++```PowerShell +New-AntiPhishRule -Name "<RuleName>" -AntiPhishPolicy "<PolicyName>" <Recipient filters> [<Recipient filter exceptions>] [-Comments "<OptionalComments>"] +``` ++This example creates an anti-phish rule named Research Department with the following conditions: ++- The rule is associated with the anti-phish policy named Research Quarantine. +- The rule applies to members of the group named Research Department. +- Because we aren't using the _Priority_ parameter, the default priority is used. ++```powershell +New-AntiPhishRule -Name "Research Department" -AntiPhishPolicy "Research Quarantine" -SentToMemberOf "Research Department" +``` ++For detailed syntax and parameter information, see [New-AntiPhishRule](/powershell/module/exchange/New-AntiPhishRule). ++### Use PowerShell to view anti-phish policies ++To view existing anti-phish policies, use the following syntax: ++```PowerShell +Get-AntiPhishPolicy [-Identity "<PolicyIdentity>"] [| <Format-Table | Format-List> <Property1,Property2,...>] +``` ++This example returns a summary list of all anti-phish policies along with the specified properties. ++```PowerShell +Get-AntiPhishPolicy | Format-Table Name,IsDefault +``` ++This example returns all the property values for the anti-phish policy named Executives. ++```PowerShell +Get-AntiPhishPolicy -Identity "Executives" +``` ++For detailed syntax and parameter information, see [Get-AntiPhishPolicy](/powershell/module/exchange/Get-AntiPhishPolicy). ++### Use PowerShell to view anti-phish rules ++To view existing anti-phish rules, use the following syntax: ++```PowerShell +Get-AntiPhishRule [-Identity "<RuleIdentity>"] [-State <Enabled | Disabled] [| <Format-Table | Format-List> <Property1,Property2,...>] +``` ++This example returns a summary list of all anti-phish rules along with the specified properties. ++```PowerShell +Get-AntiPhishRule | Format-Table Name,Priority,State +``` ++To filter the list by enabled or disabled rules, run the following commands: ++```PowerShell +Get-AntiPhishRule -State Disabled | Format-Table Name,Priority +``` ++```PowerShell +Get-AntiPhishRule -State Enabled | Format-Table Name,Priority +``` ++This example returns all the property values for the anti-phish rule named Contoso Executives. ++```PowerShell +Get-AntiPhishRule -Identity "Contoso Executives" +``` ++For detailed syntax and parameter information, see [Get-AntiPhishRule](/powershell/module/exchange/Get-AntiPhishrule). ++### Use PowerShell to modify anti-phish policies ++Other than the following items, the same settings are available when you modify an anti-phish policy in PowerShell as when you create a policy as described in [Step 1: Use PowerShell to create an anti-phish policy](#step-1-use-powershell-to-create-an-anti-phish-policy) earlier in this article. ++- The _MakeDefault_ switch that turns the specified policy into the default policy (applied to everyone, always **Lowest** priority, and you can't delete it) is only available when you modify an anti-phish policy in PowerShell. +- You can't rename an anti-phish policy (the **Set-AntiPhishPolicy** cmdlet has no _Name_ parameter). When you rename an anti-phishing policy in the Microsoft 365 Defender portal, you're only renaming the anti-phish _rule_. ++To modify an anti-phish policy, use this syntax: ++```PowerShell +Set-AntiPhishPolicy -Identity "<PolicyName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-AntiPhishPolicy](/powershell/module/exchange/Set-AntiPhishPolicy). ++> [!NOTE] +> For detailed instructions to specify the [quarantine policy](quarantine-policies.md) to use in an anti-phish policy, see [Use PowerShell to specify the quarantine policy in anti-phishing policies](quarantine-policies.md#anti-phishing-policies). ++### Use PowerShell to modify anti-phish rules ++The only setting that's not available when you modify an anti-phish rule in PowerShell is the _Enabled_ parameter that allows you to create a disabled rule. To enable or disable existing anti-phish rules, see the next section. ++Otherwise, the same settings are available when you create a rule as described in the [Step 2: Use PowerShell to create an anti-phish rule](#step-2-use-powershell-to-create-an-anti-phish-rule) section earlier in this article. ++To modify an anti-phish rule, use this syntax: ++```PowerShell +Set-AntiPhishRule -Identity "<RuleName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-AntiPhishRule](/powershell/module/exchange/set-antiphishrule). ++### Use PowerShell to enable or disable anti-phish rules ++Enabling or disabling an anti-phish rule in PowerShell enables or disables the whole anti-phishing policy (the anti-phish rule and the assigned anti-phish policy). You can't enable or disable the default anti-phishing policy (it's always applied to all recipients). ++To enable or disable an anti-phish rule in PowerShell, use this syntax: ++```PowerShell +<Enable-AntiPhishRule | Disable-AntiPhishRule> -Identity "<RuleName>" +``` ++This example disables the anti-phish rule named Marketing Department. ++```PowerShell +Disable-AntiPhishRule -Identity "Marketing Department" +``` ++This example enables same rule. ++```PowerShell +Enable-AntiPhishRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Enable-AntiPhishRule](/powershell/module/exchange/enable-antiphishrule) and [Disable-AntiPhishRule](/powershell/module/exchange/disable-antiphishrule). ++### Use PowerShell to set the priority of anti-phish rules ++The highest priority value you can set on a rule is 0. The lowest value you can set depends on the number of rules. For example, if you have five rules, you can use the priority values 0 through 4. Changing the priority of an existing rule can have a cascading effect on other rules. For example, if you have five custom rules (priorities 0 through 4), and you change the priority of a rule to 2, the existing rule with priority 2 is changed to priority 3, and the rule with priority 3 is changed to priority 4. ++To set the priority of an anti-phish rule in PowerShell, use the following syntax: ++```PowerShell +Set-AntiPhishRule -Identity "<RuleName>" -Priority <Number> +``` ++This example sets the priority of the rule named Marketing Department to 2. All existing rules that have a priority less than or equal to 2 are decreased by 1 (their priority numbers are increased by 1). ++```PowerShell +Set-AntiPhishRule -Identity "Marketing Department" -Priority 2 +``` ++**Notes**: ++- To set the priority of a new rule when you create it, use the _Priority_ parameter on the **New-AntiPhishRule** cmdlet instead. +- The default anti-phish policy doesn't have a corresponding anti-phish rule, and it always has the unmodifiable priority value **Lowest**. ++### Use PowerShell to remove anti-phish policies ++When you use PowerShell to remove an anti-phish policy, the corresponding anti-phish rule isn't removed. ++To remove an anti-phish policy in PowerShell, use this syntax: ++```PowerShell +Remove-AntiPhishPolicy -Identity "<PolicyName>" +``` ++This example removes the anti-phish policy named Marketing Department. ++```PowerShell +Remove-AntiPhishPolicy -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-AntiPhishPolicy](/powershell/module/exchange/Remove-AntiPhishPolicy). ++### Use PowerShell to remove anti-phish rules ++When you use PowerShell to remove an anti-phish rule, the corresponding anti-phish policy isn't removed. ++To remove an anti-phish rule in PowerShell, use this syntax: ++```PowerShell +Remove-AntiPhishRule -Identity "<PolicyName>" +``` ++This example removes the anti-phish rule named Marketing Department. ++```PowerShell +Remove-AntiPhishRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-AntiPhishRule](/powershell/module/exchange/Remove-AntiPhishRule). ++## How do you know these procedures worked? ++To verify that you've successfully configured anti-phishing policies in EOP, do any of the following steps: ++- On the **Anti-phishing** page in the Microsoft 365 Defender portal at <https://security.microsoft.com/antiphishing>, verify the list of policies, their **Status** values, and their **Priority** values. To view more details, select the policy from the list by clicking on the name and viewing the details in the flyout that appears. ++- In Exchange Online PowerShell, replace \<Name\> with the name of the policy or rule, run the following command, and verify the settings: ++ ```PowerShell + Get-AntiPhishPolicy -Identity "<Name>" + ``` ++ ```PowerShell + Get-AntiPhishRule -Identity "<Name>" + ``` |
| security | Anti Phishing Policies Mdo Configure | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-policies-mdo-configure.md | + + Title: Configure anti-phishing policies in Microsoft Defender for Office 365 +f1.keywords: + - NOCSH ++++audience: ITPro + Last updated :++ms.localizationpriority: medium +ms.assetid: ++ - m365-security ++description: Admins can learn how to create, modify, and delete the advanced anti-phishing policies that are available in organizations with Microsoft Defender for Office 365. +++search.appverid: met150 +++# Configure anti-phishing policies in Microsoft Defender for Office 365 +++**Applies to** +- [Microsoft Defender for Office 365 plan 1 and plan 2](defender-for-office-365.md) +- [Microsoft 365 Defender](../defender/microsoft-365-defender.md) ++Anti-phishing policies in [Microsoft Defender for Office 365](defender-for-office-365.md) can help protect your organization from malicious impersonation-based phishing attacks and other types of phishing attacks. For more information about the differences between anti-phishing policies in Exchange Online Protection (EOP) and anti-phishing policies in Microsoft Defender for Office 365, see [Anti-phishing protection](anti-phishing-protection.md). ++Admins can view, edit, and configure (but not delete) the default anti-phishing policy. For greater granularity, you can also create custom anti-phishing policies that apply to specific users, groups, or domains in your organization. Custom policies always take precedence over the default policy, but you can change the priority (running order) of your custom policies. ++You can configure anti-phishing policies in Defender for Office 365 in the Microsoft 365 Defender portal or in Exchange Online PowerShell. ++For information about configuring the more limited in anti-phishing policies that are available in Exchange Online Protection (that is, organizations without Defender for Office 365), see [Configure anti-phishing policies in EOP](configure-anti-phishing-policies-eop.md). ++The basic elements of an anti-phishing policy are: ++- **The anti-phish policy**: Specifies the phishing protections to enable or disable, and the actions to apply options. +- **The anti-phish rule**: Specifies the priority and recipient filters (who the policy applies to) for an anti-phish policy. ++The difference between these two elements isn't obvious when you manage anti-phishing policies in the Microsoft 365 Defender portal: ++- When you create a policy, you're actually creating an anti-phish rule and the associated anti-phish policy at the same time using the same name for both. +- When you modify a policy, settings related to the name, priority, enabled or disabled, and recipient filters modify the anti-phish rule. All other settings modify the associated anti-phish policy. +- When you remove a policy, the anti-phish rule and the associated anti-phish policy are removed. ++In Exchange Online PowerShell, you manage the policy and the rule separately. For more information, see the [Use Exchange Online PowerShell to configure anti-phishing policies](#use-exchange-online-powershell-to-configure-anti-phishing-policies) section later in this article. ++Every Defender for Office 365 organization has a built-in anti-phishing policy named Office 365 AntiPhish Default that has these properties: ++- The policy is applied to all recipients in the organization, even though there's no anti-phish rule (recipient filters) associated with the policy. +- The policy has the custom priority value **Lowest** that you can't modify (the policy is always applied last). Any custom policies that you create always have a higher priority. +- The policy is the default policy (the **IsDefault** property has the value `True`), and you can't delete the default policy. ++To increase the effectiveness of anti-phishing protection in Defender for Office 365, you can create custom anti-phishing policies with stricter settings that are applied to specific users or groups of users. ++## What do you need to know before you begin? ++- You open the Microsoft 365 Defender portal at <https://security.microsoft.com>. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++- To connect to Exchange Online PowerShell, see [Connect to Exchange Online PowerShell](/powershell/exchange/connect-to-exchange-online-powershell). ++- You need to be assigned permissions in **Exchange Online** before you can do the procedures in this article: + - To add, modify, and delete anti-phishing policies, you need to be a member of the **Organization Management** or **Security Administrator** role groups. + - For read-only access to anti-phishing policies, you need to be a member of the **Global Reader** or **Security Reader** role groups<sup>\*</sup>. ++ For more information, see [Permissions in Exchange Online](/exchange/permissions-exo/permissions-exo). ++ **Notes**: ++ - Adding users to the corresponding Azure Active Directory role in the Microsoft 365 admin center gives users the required permissions _and_ permissions for other features in Microsoft 365. For more information, see [About admin roles](../../admin/add-users/about-admin-roles.md). + - The **View-Only Organization Management** role group in [Exchange Online](/Exchange/permissions-exo/permissions-exo#role-groups) also gives read-only access to the feature. ++- For our recommended settings for anti-phishing policies in Defender for Office 365, see [Anti-phishing policy in Defender for Office 365 settings](recommended-settings-for-eop-and-office365.md#anti-phishing-policy-settings-in-microsoft-defender-for-office-365). ++- Allow up to 30 minutes for a new or updated policy to be applied. ++- For information about where anti-phishing policies are applied in the filtering pipeline, see [Order and precedence of email protection](how-policies-and-protections-are-combined.md). ++## Use the Microsoft 365 Defender portal to create anti-phishing policies ++Creating a custom anti-phishing policy in the Microsoft 365 Defender portal creates the anti-phish rule and the associated anti-phish policy at the same time using the same name for both. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, click  **Create**. ++3. The policy wizard opens. On the **Policy name** page, configure these settings: + - **Name**: Enter a unique, descriptive name for the policy. + - **Description**: Enter an optional description for the policy. ++ When you're finished, click **Next**. ++4. On the **Users, groups, and domains** page that appears, identify the internal recipients that the policy applies to (recipient conditions): + - **Users**: The specified mailboxes, mail users, or mail contacts. + - **Groups**: + - Members of the specified distribution groups or mail-enabled security groups. + - The specified Microsoft 365 Groups. + - **Domains**: All recipients in the specified [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in your organization. ++ Click in the appropriate box, start typing a value, and select the value that you want from the results. Repeat this process as many times as necessary. To remove an existing value, click remove  next to the value. ++ For users or groups, you can use most identifiers (name, display name, alias, email address, account name, etc.), but the corresponding display name is shown in the results. For users, enter an asterisk (\*) by itself to see all available values. ++ Multiple values in the same condition use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). Different conditions use AND logic (for example, _\<recipient1\>_ and _\<member of group 1\>_). ++ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions. The settings and behavior are exactly like the conditions. ++ > [!IMPORTANT] + > Multiple different types of conditions or exceptions are not additive; they're inclusive. The policy is applied _only_ to those recipients that match _all_ of the specified recipient filters. For example, you configure a recipient filter condition in the policy with the following values: + > + > - Users: romain@contoso.com + > - Groups: Executives + > + > The policy is applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy is not applied to him. + > + > Likewise, if you use the same recipient filter as an exception to the policy, the policy is not applied to romain@contoso.com _only_ if he's also a member of the Executives group. If he's not a member of the group, then the policy still applies to him. ++ When you're finished, click **Next**. ++5. On the **Phishing threshold & protection** page that appears, configure the following settings: ++ - **Phishing email threshold**: Use the slider to select one of the following values: + - **1 - Standard** (This is the default value.) + - **2 - Aggressive** + - **3 - More aggressive** + - **4 - Most aggressive** ++ For more information, see [Advanced phishing thresholds in anti-phishing policies in Microsoft Defender for Office 365](set-up-anti-phishing-policies.md#advanced-phishing-thresholds-in-anti-phishing-policies-in-microsoft-defender-for-office-365). ++ - **Impersonation**: These settings are a condition for the policy that identifies specific senders to look for (individually or by domain) in the From address of inbound messages. For more information, see [Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365](set-up-anti-phishing-policies.md#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365). ++ > [!NOTE] + > + > - In each anti-phishing policy, you can specify a maximum of 350 protected users (sender email addresses). You can't specify the same protected user in multiple policies. + > - User impersonation protection does not work if the sender and recipient have previously communicated via email. If the sender and recipient have never communicated via email, the message will be identified as an impersonation attempt. ++ - **Enable users to protect**: The default value is off (not selected). To turn it on, select the check box, and then click the **Manage (nn) sender(s)** link that appears. ++ In the **Manage senders for impersonation protection** flyout that appears, do the following steps: ++ - **Internal senders**: Click  **Select internal**. In the **Add internal senders** flyout that appears, click in the box and select an internal user from the list. You can filter the list by typing the user, and then selecting the user from the results. You can use most identifiers (name, display name, alias, email address, account name, etc.), but the corresponding display name is shown in the results. ++ Repeat this step as many times as necessary. To remove an existing value, click remove  next to the value. ++ When you're finished, click **Add** ++ - **External senders**: Click  **Select external**. In the **Add external senders** flyout that appears, enter a display name in the **Add a name** box and an email address in the **Add a vaild email** box, and then click **Add**. ++ Repeat this step as many times as necessary. To remove an existing value, click remove  next to the value. ++ When you're finished, click **Add** ++ Back on the **Manage senders for impersonation** flyout, you can remove entries by selecting one or more entries from the list. You can search for entries using the  **Search** box. ++ After you select at least one entry, the  **Remove selected users** icon appears, which you can use to remove the selected entries. ++ When you're finished, click **Done**. ++ - **Enable domains to protect**: The default value is off (not selected). To turn it on, select the check box, and then configure one or both of the following settings that appear: + - **Include the domains I own**: To turn this setting on, select the check box. To view the domains that you own, click **View my domains**. + - **Include custom domains**: To turn this setting on, select the check box, and then click the **Manage (nn) custom domain(s)** link that appears. In the **Manage custom domains for impersonation protection** flyout that appears, click  **Add domains**. ++ In the **Add custom domains** flyout that appears, click in the **Domain** box, enter a value, and then press Enter or select the value that's displayed below the box. Repeat this step as many times as necessary. To remove an existing value, click remove  next to the value. ++ When you're finished, click **Add domains** ++ > [!NOTE] + > You can have a maximum of 50 domains in all anti-phishing policies. ++ Back on the **Manage custom domains for impersonation** flyout, you can remove entries by selecting one or more entries from the list. You can search for entries using the  **Search** box. ++ After you select at least one entry, the  **Delete** icon appears, which you can use to remove the selected entries. ++ - **Add trusted senders and domains**: Specify impersonation protection exceptions for the policy by clicking on **Manage (nn) trusted sender(s) and domain(s)**. In the **Manage custom domains for impersonation protection** flyout that appears, configure the following settings: + - **Senders**: Verify the **Sender** tab is selected and click . In the **Add trusted senders** flyout that appears, enter an email address in the box and then click **Add**. Repeat this step as many times as necessary. To remove an existing entry, click  for the entry. ++ When you're finished, click **Add**. ++ - **Domains**: Select the **Domain** tab and click . ++ In the **Add trusted domains** flyout that appears, click in the **Domain** box, enter a value, and then press Enter or select the value that's displayed below the box. Repeat this step as many times as necessary. To remove an existing value, click remove  next to the value. ++ When you're finished, click **Add**. ++ > [!NOTE] + > + > - If Microsoft 365 system messages from the following senders are identified as impersonation attempts, you can add the senders to the trusted senders list: + > - `noreply@email.teams.microsoft.com` + > - `noreply@emeaemail.teams.microsoft.com` + > - `no-reply@sharepointonline.com` + > + > - Trusted domain entries don't include subdomains of the specified domain. You need to add an entry for each subdomain. ++ Back on the **Manage custom domains for impersonation** flyout, you can remove entries from the **Sender** and **Domain** tabs by selecting one or more entries from the list. You can search for entries using the  **Search** box. ++ After you select at least one entry, the **Delete** icon appears, which you can use to remove the selected entries. ++ When you're finished, click **Done**. ++ > [!NOTE] + > The maximum number of sender and domain entries is 1024. ++ - **Enable mailbox intelligence**: The default value is on (selected), and we recommend that you leave it on. To turn it off, clear the check box. ++ - **Enable intelligence based impersonation protection**: This setting is available only if **Enable mailbox intelligence** is on (selected). This setting allows mailbox intelligence to take action on messages that are identified as impersonation attempts. You specify the action to take in the **If mailbox intelligence detects an impersonated user** setting on the next page. ++ We recommend that you turn this setting on by selecting the check box. To turn this setting off, clear the check box. ++ - **Spoof**: In this section, use the **Enable spoof intelligence** check box to turn spoof intelligence on or off. The default value is on (selected), and we recommend that you leave it on. You specify the action to take on messages from blocked spoofed senders in the **If message is detected as spoof** setting on the next page. ++ To turn off spoof intelligence, clear the check box. ++ > [!NOTE] + > You don't need to turn off anti-spoofing protection if your MX record doesn't point to Microsoft 365; you enable Enhanced Filtering for Connectors instead. For instructions, see [Enhanced Filtering for Connectors in Exchange Online](/Exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors). ++ When you're finished, click **Next**. ++6. On the **Actions** page that appears, configure the following settings: ++ - **Message actions**: Configure the following actions in this section: + - **If message is detected as an impersonated user**: This setting is available only if you selected **Enable users to protect** on the previous page. Select one of the following actions in the drop down list for messages where the sender is one of the protected users that you specified on the previous page: + - **Don't apply any action** + - **Redirect message to other email addresses** + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, an **Apply quarantine policy** box appears where you select the quarantine policy that applies to messages that are quarantined by user impersonation protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++ A blank **Apply quarantine policy** value means the default quarantine policy is used (DefaultFullAccessPolicy for user impersonation detections). When you later edit the anti-phishing policy or view the settings, the default quarantine policy name is shown. + + - **Deliver the message and add other addresses to the Bcc line** + - **Delete the message before it's delivered** ++ - **If the message is detected as an impersonated domain**: This setting is available only if you selected **Enable domains to protect** on the previous page. Select one of the following actions in the drop down list for messages where the sender's email address is in one of the protected domains that you specified on the previous page: + - **Don't apply any action** + - **Redirect message to other email addresses** + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, an **Apply quarantine policy** box appears where you select the quarantine policy that applies to messages that are quarantined by domain impersonation protection. ++ A blank **Apply quarantine policy** value means the default quarantine policy is used (DefaultFullAccessPolicy for domain impersonation detections). When you later edit the anti-phishing policy or view the settings, the default quarantine policy name is shown. ++ - **Deliver the message and add other addresses to the Bcc line** + - **Delete the message before it's delivered** ++ - **If mailbox intelligence detects an impersonated user**: This setting is available only if you selected **Enable intelligence for impersonation protection** on the previous page. Select one of the following actions in the drop down list for messages that were identified as impersonation attempts by mailbox intelligence: + - **Don't apply any action** + - **Redirect message to other email addresses** + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, an **Apply quarantine policy** box appears where you select the quarantine policy that applies to messages that are quarantined by mailbox intelligence protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++ A blank **Apply quarantine policy** value means the default quarantine policy is used (DefaultFullAccessPolicy for mailbox intelligence detections). When you later edit the anti-phishing policy or view the settings, the default quarantine policy name is shown. ++ - **Deliver the message and add other addresses to the Bcc line** + - **Delete the message before it's delivered** ++ - **If message is detected as spoof**: This setting is available only if you selected **Enable spoof intelligence** on the previous page. Select one of the following actions in the drop down list for messages from blocked spoofed senders: + - **Move message to the recipients' Junk Email folders** + - **Quarantine the message**: If you select this action, an **Apply quarantine policy** box appears where you select the quarantine policy that applies to messages that are quarantined by spoof intelligence protection. Quarantine policies define what users are able to do to quarantined messages, and whether users receive quarantine notifications. For more information, see [Quarantine policies](quarantine-policies.md). ++ A blank **Apply quarantine policy** value means the default quarantine policy is used (DefaultFullAccessPolicy for spoof intelligence detections). When you later edit the anti-phishing policy or view the settings, the default quarantine policy name is shown. ++ - **Safety tips & indicators**: Configure the following settings: + - **Show first contact safety tip**: For more information, see [First contact safety tip](set-up-anti-phishing-policies.md#first-contact-safety-tip). + - **Show user impersonation safety tip**: This setting is available only if you selected **Enable users to protect** on the previous page. + - **Show domain impersonation safety tip**: This setting is available only if you selected **Enable domains to protect** on the previous page. + - **Show user impersonation unusual characters safety tip** This setting is available only if you selected **Enable users to protect** or **Enable domains to protect** on the previous page. + - **Show (?) for unauthenticated senders for spoof**: This setting is available only if you selected **Enable spoof intelligence** on the previous page. Adds a question mark (?) to the sender's photo in the From box in Outlook if the message does not pass SPF or DKIM checks **and** the message does not pass DMARC or [composite authentication](email-validation-and-authentication.md#composite-authentication). + - **Show "via" tag**: This setting is available only if you selected **Enable spoof intelligence** on the previous page. Adds a via tag (chris@contoso.com via fabrikam.com) to the From address if it's different from the domain in the DKIM signature or the **MAIL FROM** address. The default value is on (selected). To turn it off, clear the check box. ++ To turn on a setting, select the check box. To turn it off, clear the check box. ++ When you're finished, click **Next**. ++7. On the **Review** page that appears, review your settings. You can select **Edit** in each section to modify the settings within the section. Or you can click **Back** or select the specific page in the wizard. ++ When you're finished, click **Submit**. ++8. On the confirmation page that appears, click **Done**. ++## Use the Microsoft 365 Defender portal to view anti-phishing policies ++1. In the Microsoft 365 Defender portal, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. ++2. On the **Anti-phishing** page, the following properties are displayed in the list of anti-phishing policies: ++ - **Name** + - **Status** + - **Priority** + - **Last modified** ++3. When you select a policy by clicking on the name, the policy settings are displayed in a flyout. ++## Use the Microsoft 365 Defender portal to modify anti-phishing policies ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a policy from the list by clicking on the name. ++3. In the policy details flyout that appears, select **Edit** in each section to modify the settings within the section. For more information about the settings, see the [Use the Microsoft 365 Defender portal to create anti-phishing policies](#use-the-microsoft-365-defender-portal-to-create-anti-phishing-policies) section earlier in this article. ++ For the default anti-phishing policy, the **Users, groups, and domains** section isn't available (the policy applies to everyone), and you can't rename the policy. ++To enable or disable a policy or set the policy priority order, see the following sections. ++### Enable or disable custom anti-phishing policies ++You can't disable the default anti-phishing policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see one of the following values: + - **Policy off**: To turn on the policy, click  **Turn on** . + - **Policy on**: To turn off the policy, click  **Turn off**. ++4. In the confirmation dialog that appears, click **Turn on** or **Turn off**. ++5. Click **Close** in the policy details flyout. ++Back on the main policy page, the **Status** value of the policy will be **On** or **Off**. ++### Set the priority of custom anti-phishing policies ++By default, anti-phishing policies are given a priority that's based on the order they were created in (newer policies are lower priority than older policies). A lower priority number indicates a higher priority for the policy (0 is the highest), and policies are processed in priority order (higher priority policies are processed before lower priority policies). No two policies can have the same priority, and policy processing stops after the first policy is applied. ++To change the priority of a policy, you click **Increase priority** or **Decrease priority** in the properties of the policy (you can't directly modify the **Priority** number in the Microsoft 365 Defender portal). Changing the priority of a policy only makes sense if you have multiple policies. ++ **Notes**: ++- In the Microsoft 365 Defender portal, you can only change the priority of the anti-phishing policy after you create it. In PowerShell, you can override the default priority when you create the anti-phish rule (which can affect the priority of existing rules). +- Anti-phishing policies are processed in the order that they're displayed (the first policy has the **Priority** value 0). The default anti-phishing policy has the priority value **Lowest**, and you can't change it. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name. ++3. At the top of the policy details flyout that appears, you'll see **Increase priority** or **Decrease priority** based on the current priority value and the number of custom policies: + - The policy with the **Priority** value **0** has only the **Decrease priority** option available. + - The policy with the lowest **Priority** value (for example, **3**) has only the **Increase priority** option available. + - If you have three or more policies, the policies between the highest and lowest priority values have both the **Increase priority** and **Decrease priority** options available. ++ Click  **Increase priority** or  **Decrease priority** to change the **Priority** value. ++4. When you're finished, click **Close** in the policy details flyout. ++## Use the Microsoft 365 Defender portal to remove custom anti-phishing policies ++When you use the Microsoft 365 Defender portal to remove a custom anti-phishing policy, the anti-phish rule and the corresponding anti-phish policy are both deleted. You can't remove the default anti-phishing policy. ++1. In the Microsoft 365 Defender portal at <https://security.microsoft.com>, go to **Email & Collaboration** \> **Policies & Rules** \> **Threat policies** \> **Anti-phishing** in the **Policies** section. To go directly to the **Anti-phishing** page, use <https://security.microsoft.com/antiphishing>. ++2. On the **Anti-phishing** page, select a custom policy from the list by clicking on the name of the policy. ++3. At the top of the policy details flyout that appears, click  **More actions** \>  **Delete policy**. ++4. In the confirmation dialog that appears, click **Yes**. ++## Use Exchange Online PowerShell to configure anti-phishing policies ++As previously described, an anti-spam policy consists of an anti-phish policy and an anti-phish rule. ++In Exchange Online PowerShell, the difference between anti-phish policies and anti-phish rules is apparent. You manage anti-phish policies by using the **\*-AntiPhishPolicy** cmdlets, and you manage anti-phish rules by using the **\*-AntiPhishRule** cmdlets. ++- In PowerShell, you create the anti-phish policy first, then you create the anti-phish rule that identifies the policy that the rule applies to. +- In PowerShell, you modify the settings in the anti-phish policy and the anti-phish rule separately. +- When you remove an anti-phish policy from PowerShell, the corresponding anti-phish rule isn't automatically removed, and vice versa. ++### Use PowerShell to create anti-phishing policies ++Creating an anti-phishing policy in PowerShell is a two-step process: ++1. Create the anti-phish policy. +2. Create the anti-phish rule that specifies the anti-phish policy that the rule applies to. ++ **Notes**: ++- You can create a new anti-phish rule and assign an existing, unassociated anti-phish policy to it. An anti-phish rule can't be associated with more than one anti-phish policy. +- You can configure the following settings on new anti-phish policies in PowerShell that aren't available in the Microsoft 365 Defender portal until after you create the policy: + - Create the new policy as disabled (_Enabled_ `$false` on the **New-AntiPhishRule** cmdlet). + - Set the priority of the policy during creation (_Priority_ _\<Number\>_) on the **New-AntiPhishRule** cmdlet). +- A new anti-phish policy that you create in PowerShell isn't visible in the Microsoft 365 Defender portal until you assign the policy to an anti-phish rule. ++#### Step 1: Use PowerShell to create an anti-phish policy ++To create an anti-phish policy, use this syntax: ++```PowerShell +New-AntiPhishPolicy -Name "<PolicyName>" [-AdminDisplayName "<Comments>"] <Additional Settings> +``` ++This example creates an anti-phish policy named Research Quarantine with the following settings: ++- The policy is enabled (we aren't using the _Enabled_ parameter, and the default value is `$true`). +- The description is: Research department policy. +- Changes the default action for spoofing detections to Quarantine, and uses the default [quarantine policy](quarantine-policies.md) for the quarantined messages (we aren't using the _SpoofQuarantineTag_ parameter). +- Enables organization domains protection for all accepted domains, and targeted domains protection for fabrikam.com. +- Specifies Quarantine as the action for domain impersonation detections, and uses the default [quarantine policy](quarantine-policies.md) for the quarantined messages (we aren't using the _TargetedDomainQuarantineTag_ parameter). +- Specifies Mai Fujito (mfujito@fabrikam.com) as the user to protect from impersonation. +- Specifies Quarantine as the action for user impersonation detections, and uses the default [quarantine policy](quarantine-policies.md) for the quarantined messages (we aren't using the _TargetedUserQuarantineTag_ parameter). +- Enables mailbox intelligence (_EnableMailboxIntelligence_), allows mailbox intelligence protection to take action on messages (_EnableMailboxIntelligenceProtection_), specifies Quarantine as the action for detected messages, and uses the default [quarantine policy](quarantine-policies.md) for the quarantined messages (we aren't using the _MailboxIntelligenceQuarantineTag_ parameter). +- Enables all safety tips. ++```powershell +New-AntiPhishPolicy -Name "Monitor Policy" -AdminDisplayName "Research department policy" -AuthenticationFailAction Quarantine -EnableOrganizationDomainsProtection $true -EnableTargetedDomainsProtection $true -TargetedDomainsToProtect fabrikam.com -TargetedDomainProtectionAction Quarantine -EnableTargetedUserProtection $true -TargetedUsersToProtect "Mai Fujito;mfujito@fabrikam.com" -TargetedUserProtectionAction Quarantine -EnableMailboxIntelligence $true -EnableMailboxIntelligenceProtection $true -MailboxIntelligenceProtectionAction Quarantine -EnableSimilarUsersSafetyTips $true -EnableSimilarDomainsSafetyTips $true -EnableUnusualCharactersSafetyTips $true +``` ++For detailed syntax and parameter information, see [New-AntiPhishPolicy](/powershell/module/exchange/New-AntiPhishPolicy). ++> [!NOTE] +> For detailed instructions to specify the [quarantine policies](quarantine-policies.md) to use in an anti-phish policy, see [Use PowerShell to specify the quarantine policy in anti-phishing policies](quarantine-policies.md#anti-phishing-policies). ++#### Step 2: Use PowerShell to create an anti-phish rule ++To create an anti-phish rule, use this syntax: ++```PowerShell +New-AntiPhishRule -Name "<RuleName>" -AntiPhishPolicy "<PolicyName>" <Recipient filters> [<Recipient filter exceptions>] [-Comments "<OptionalComments>"] +``` ++This example creates an anti-phish rule named Research Department with the following conditions: ++- The rule is associated with the anti-phish policy named Research Quarantine. +- The rule applies to members of the group named Research Department. +- Because we aren't using the _Priority_ parameter, the default priority is used. ++```powershell +New-AntiPhishRule -Name "Research Department" -AntiPhishPolicy "Research Quarantine" -SentToMemberOf "Research Department" +``` ++For detailed syntax and parameter information, see [New-AntiPhishRule](/powershell/module/exchange/New-AntiPhishRule). ++### Use PowerShell to view anti-phish policies ++To view existing anti-phish policies, use the following syntax: ++```PowerShell +Get-AntiPhishPolicy [-Identity "<PolicyIdentity>"] [| <Format-Table | Format-List> <Property1,Property2,...>] +``` ++This example returns a summary list of all anti-phish policies along with the specified properties. ++```PowerShell +Get-AntiPhishPolicy | Format-Table Name,IsDefault +``` ++This example returns all the property values for the anti-phish policy named Executives. ++```PowerShell +Get-AntiPhishPolicy -Identity "Executives" +``` ++For detailed syntax and parameter information, see [Get-AntiPhishPolicy](/powershell/module/exchange/Get-AntiPhishPolicy). ++### Use PowerShell to view anti-phish rules ++To view existing anti-phish rules, use the following syntax: ++```PowerShell +Get-AntiPhishRule [-Identity "<RuleIdentity>"] [-State <Enabled | Disabled] [| <Format-Table | Format-List> <Property1,Property2,...>] +``` ++This example returns a summary list of all anti-phish rules along with the specified properties. ++```PowerShell +Get-AntiPhishRule | Format-Table Name,Priority,State +``` ++To filter the list by enabled or disabled rules, run the following commands: ++```PowerShell +Get-AntiPhishRule -State Disabled | Format-Table Name,Priority +``` ++```PowerShell +Get-AntiPhishRule -State Enabled | Format-Table Name,Priority +``` ++This example returns all the property values for the anti-phish rule named Contoso Executives. ++```PowerShell +Get-AntiPhishRule -Identity "Contoso Executives" +``` ++For detailed syntax and parameter information, see [Get-AntiPhishRule](/powershell/module/exchange/Get-AntiPhishrule). ++### Use PowerShell to modify anti-phish policies ++Other than the following items, the same settings are available when you modify an anti-phish policy in PowerShell as when you create the policy as described in the [Step 1: Use PowerShell to create an anti-phish policy](#step-1-use-powershell-to-create-an-anti-phish-policy) section earlier in this article. ++- The _MakeDefault_ switch that turns the specified policy into the default policy (applied to everyone, always **Lowest** priority, and you can't delete it) is only available when you modify an anti-phish policy in PowerShell. ++- You can't rename an anti-phish policy (the **Set-AntiPhishPolicy** cmdlet has no _Name_ parameter). When you rename an anti-phishing policy in the Microsoft 365 Defender portal, you're only renaming the anti-phish _rule_. ++To modify an anti-phish policy, use this syntax: ++```PowerShell +Set-AntiPhishPolicy -Identity "<PolicyName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-AntiPhishPolicy](/powershell/module/exchange/Set-AntiPhishPolicy). ++> [!NOTE] +> For detailed instructions to specify the [quarantine policies](quarantine-policies.md) to use in an anti-phish policy, see [Use PowerShell to specify the quarantine policy in anti-phishing policies](quarantine-policies.md#anti-phishing-policies). ++### Use PowerShell to modify anti-phish rules ++The only setting that isn't available when you modify an anti-phish rule in PowerShell is the _Enabled_ parameter that allows you to create a disabled rule. To enable or disable existing anti-phish rules, see the next section. ++Otherwise, no additional settings are available when you modify an anti-phish rule in PowerShell. The same settings are available when you create a rule as described in the [Step 2: Use PowerShell to create an anti-phish rule](#step-2-use-powershell-to-create-an-anti-phish-rule) section earlier in this article. ++To modify an anti-phish rule, use this syntax: ++```PowerShell +Set-AntiPhishRule -Identity "<RuleName>" <Settings> +``` ++For detailed syntax and parameter information, see [Set-AntiPhishRule](/powershell/module/exchange/set-antiphishrule). ++### Use PowerShell to enable or disable anti-phish rules ++Enabling or disabling an anti-phish rule in PowerShell enables or disables the whole anti-phishing policy (the anti-phish rule and the assigned anti-phish policy). You can't enable or disable the default anti-phishing policy (it's always applied to all recipients). ++To enable or disable an anti-phish rule in PowerShell, use this syntax: ++```PowerShell +<Enable-AntiPhishRule | Disable-AntiPhishRule> -Identity "<RuleName>" +``` ++This example disables the anti-phish rule named Marketing Department. ++```PowerShell +Disable-AntiPhishRule -Identity "Marketing Department" +``` ++This example enables same rule. ++```PowerShell +Enable-AntiPhishRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Enable-AntiPhishRule](/powershell/module/exchange/enable-antiphishrule) and [Disable-AntiPhishRule](/powershell/module/exchange/disable-antiphishrule). ++### Use PowerShell to set the priority of anti-phish rules ++The highest priority value you can set on a rule is 0. The lowest value you can set depends on the number of rules. For example, if you have five rules, you can use the priority values 0 through 4. Changing the priority of an existing rule can have a cascading effect on other rules. For example, if you have five custom rules (priorities 0 through 4), and you change the priority of a rule to 2, the existing rule with priority 2 is changed to priority 3, and the rule with priority 3 is changed to priority 4. ++To set the priority of an anti-phish rule in PowerShell, use the following syntax: ++```PowerShell +Set-AntiPhishRule -Identity "<RuleName>" -Priority <Number> +``` ++This example sets the priority of the rule named Marketing Department to 2. All existing rules that have a priority less than or equal to 2 are decreased by 1 (their priority numbers are increased by 1). ++```PowerShell +Set-AntiPhishRule -Identity "Marketing Department" -Priority 2 +``` ++**Notes**: ++- To set the priority of a new rule when you create it, use the _Priority_ parameter on the **New-AntiPhishRule** cmdlet instead. ++- The default anti-phish policy doesn't have a corresponding anti-phish rule, and it always has the unmodifiable priority value **Lowest**. ++### Use PowerShell to remove anti-phish policies ++When you use PowerShell to remove an anti-phish policy, the corresponding anti-phish rule isn't removed. ++To remove an anti-phish policy in PowerShell, use this syntax: ++```PowerShell +Remove-AntiPhishPolicy -Identity "<PolicyName>" +``` ++This example removes the anti-phish policy named Marketing Department. ++```PowerShell +Remove-AntiPhishPolicy -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-AntiPhishPolicy](/powershell/module/exchange/Remove-AntiPhishPolicy). ++### Use PowerShell to remove anti-phish rules ++When you use PowerShell to remove an anti-phish rule, the corresponding anti-phish policy isn't removed. ++To remove an anti-phish rule in PowerShell, use this syntax: ++```PowerShell +Remove-AntiPhishRule -Identity "<PolicyName>" +``` ++This example removes the anti-phish rule named Marketing Department. ++```PowerShell +Remove-AntiPhishRule -Identity "Marketing Department" +``` ++For detailed syntax and parameter information, see [Remove-AntiPhishRule](/powershell/module/exchange/Remove-AntiPhishRule). ++## How do you know these procedures worked? ++To verify that you've successfully configured anti-phishing policies in Defender for Office 365, do any of the following steps: ++- On the **Anti-phishing** page in the Microsoft 365 Defender portal at <https://security.microsoft.com/antiphishing>, verify the list of policies, their **Status** values, and their **Priority** values. To view more details, select the policy from the list by clicking on the name and viewing the details in the flyout that appears. ++- In Exchange Online PowerShell, replace \<Name\> with the name of the policy or rule, and run the following command and verify the settings: ++ ```PowerShell + Get-AntiPhishPolicy -Identity "<Name>" + ``` ++ ```PowerShell + Get-AntiPhishRule -Identity "<Name>" + ``` |
| security | Anti Phishing Protection | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/anti-phishing-protection.md | Microsoft Defender for Office 365 contains additional and more advanced anti-phi - For end users: [Protect yourself from phishing schemes and other forms of online fraud](https://support.microsoft.com/office/be0de46a-29cd-4c59-aaaf-136cf177d593). -- [How Microsoft 365 validates the From address to prevent phishing](how-office-365-validates-the-from-address.md).+- [How Microsoft 365 validates the From address to prevent phishing](anti-phishing-from-email-address-validation.md). |
| security | Mdo For Spo Odb And Teams | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/mdo-for-spo-odb-and-teams.md | -Safe Attachments for SharePoint, OneDrive, and Microsoft Teams in [Microsoft Defender for Office 365](whats-new-in-defender-for-office-365.md) provides an additional layer of protection for files that have already been scanned asynchronously by the [common virus detection engine in Microsoft 365](virus-detection-in-spo.md). Safe Attachments for SharePoint, OneDrive, and Microsoft Teams helps detect and block existing files that are identified as malicious in team sites and document libraries. +Safe Attachments for SharePoint, OneDrive, and Microsoft Teams in [Microsoft Defender for Office 365](whats-new-in-defender-for-office-365.md) provides an additional layer of protection for files that have already been scanned asynchronously by the [common virus detection engine in Microsoft 365](anti-malware-protection-for-spo-odfb-teams-about.md). Safe Attachments for SharePoint, OneDrive, and Microsoft Teams helps detect and block existing files that are identified as malicious in team sites and document libraries. Safe Attachments for SharePoint, OneDrive, and Microsoft Teams is not enabled by default. To turn it on, see [Turn on Safe Attachments for SharePoint, OneDrive, and Microsoft Teams](turn-on-mdo-for-spo-odb-and-teams.md). |
| security | Mdo Sec Ops Guide | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/mdo-sec-ops-guide.md | Campaign Views reveals malware and phishing attacks against your organization. F |Activity|Cadence|Description|Persona| |||||-|Review the **Spoof intelligence insight** and the **Impersonation detection insights** at <ul><li><<https://security.microsoft.com/spoofintelligence>></li><li><https://security.microsoft.com/impersonationinsight></li></ul>.|Ad-hoc <br/><br/> Monthly|Use the [spoof intelligence insight](learn-about-spoof-intelligence.md) and the [impersonation insight](impersonation-insight.md) to adjust filtering for spoof and impersonation detections.|Security Administration <br/><br/> Messaging Team| +|Review the **Spoof intelligence insight** and the **Impersonation detection insights** at <ul><li><<https://security.microsoft.com/spoofintelligence>></li><li><https://security.microsoft.com/impersonationinsight></li></ul>.|Ad-hoc <br/><br/> Monthly|Use the [spoof intelligence insight](learn-about-spoof-intelligence.md) and the [impersonation insight](anti-phishing-mdo-impersonation-insight.md) to adjust filtering for spoof and impersonation detections.|Security Administration <br/><br/> Messaging Team| ### Review priority account membership |
| security | Migrate To Defender For Office 365 Onboard | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/migrate-to-defender-for-office-365-onboard.md | The longer you monitor the impersonation protection results without acting on th ### Tune mailbox intelligence -Although mailbox intelligence has been configured to take no action on messages that were [determined to be impersonation attempts](impersonation-insight.md), it has been on and learning the email sending and receiving patterns of the pilot users. If an external user is in contact with one your pilot users, messages from that external user won't be identified as impersonation attempts by mailbox intelligence (thus reducing false positives). +Although mailbox intelligence has been configured to take no action on messages that were [determined to be impersonation attempts](anti-phishing-mdo-impersonation-insight.md), it has been on and learning the email sending and receiving patterns of the pilot users. If an external user is in contact with one your pilot users, messages from that external user won't be identified as impersonation attempts by mailbox intelligence (thus reducing false positives). When you're ready, do the following steps to allow mailbox intelligence to act on messages that are detected as impersonation attempts: After you've observed the results and made any adjustments, proceed to the next In both of your anti-phishing policies based on Standard and Strict settings, change the value of **If message is detected as an impersonated user** to **Quarantine the message**. -Check the [impersonation insight](impersonation-insight.md) to see what's being blocked as user impersonation attempts. +Check the [impersonation insight](anti-phishing-mdo-impersonation-insight.md) to see what's being blocked as user impersonation attempts. To modify the policies, see [Configure anti-phishing policies in Defender for Office 365](configure-mdo-anti-phishing-policies.md). After you've observed the results and made any adjustments, proceed to the next In both of your anti-phishing policies based on Standard and Strict settings, change the value of **If message is detected as an impersonated domain** to **Quarantine the message**. -Check the [impersonation insight](impersonation-insight.md) to see what's being blocked as domain impersonation attempts. +Check the [impersonation insight](anti-phishing-mdo-impersonation-insight.md) to see what's being blocked as domain impersonation attempts. To modify the policies, see [Configure anti-phishing policies in Defender for Office 365](configure-mdo-anti-phishing-policies.md). Feel free to pause and evaluate here at any point. But, remember: once you turn Congratulations! You have completed your [migration to Microsoft Defender for Office 365](migrate-to-defender-for-office-365.md#the-migration-process)! Because you followed the steps in this migration guide, the first few days where mail is delivered directly into Microsoft 365 should be much smoother. -Now you begin the normal operation and maintenance of Defender for Office 365. Monitor and watch for issues that are similar to what you experienced during the pilot, but on a larger scale. The [spoof intelligence insight](learn-about-spoof-intelligence.md) and the [impersonation insight](impersonation-insight.md) will be most helpful, but consider making the following activities a regular occurrence: +Now you begin the normal operation and maintenance of Defender for Office 365. Monitor and watch for issues that are similar to what you experienced during the pilot, but on a larger scale. The [spoof intelligence insight](learn-about-spoof-intelligence.md) and the [impersonation insight](anti-phishing-mdo-impersonation-insight.md) will be most helpful, but consider making the following activities a regular occurrence: - Review user submissions, especially [user-reported phishing messages](automated-investigation-response-office.md) - Review overrides in the [Threat protection status report](view-email-security-reports.md#threat-protection-status-report). |
| security | Migrate To Defender For Office 365 Setup | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/migrate-to-defender-for-office-365-setup.md | For impersonation detections, ignore the recommended Standard and Strict actions - **If message is detected as impersonated domain** - **If mailbox intelligence detects an impersonated user** -Use the impersonation insight to observe the results. For more information, see [Impersonation insight in Defender for Office 365](impersonation-insight.md). +Use the impersonation insight to observe the results. For more information, see [Impersonation insight in Defender for Office 365](anti-phishing-mdo-impersonation-insight.md). You'll tune spoofing protection (adjust allows and blocks) and turn on each impersonation protection action to quarantine or move the messages to the Junk Email folder (based on the Standard or Strict recommendations). You can observe the results and adjust their settings as necessary. |
| security | Permissions Microsoft 365 Security Center | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/permissions-microsoft-365-security-center.md | Title: Permissions in the Microsoft 365 Defender portal + Title: Microsoft Defender for Office 365 permissions in the Microsoft 365 Defender portal f1.keywords: - NOCSH -description: Admins can learn how to manage permissions in the Microsoft 365 Defender portal for all tasks related to security. +description: Admins can learn how to manage Microsoft Defender for Office 365 (Email & collaboration) permissions in the Microsoft 365 Defender portal for all tasks related to Defender for Office 365 security features. - seo-marvel-apr2020 -# Permissions in the Microsoft 365 Defender portal +# Microsoft Defender for Office 365 permissions in the Microsoft 365 Defender portal [!INCLUDE [MDO Trial banner](../includes/mdo-trial-banner.md)] -Global roles in Azure Active Directory (Azure AD) allow you to manage permissions and access to capabilities in Microsoft 365, which also includes Microsoft Defender for Office 365. But, if you need to limit permissions and capabilities to security features in Defender for Office 365 only, you can assign permissions in the Microsoft 365 Defender portal. +Global roles in Azure Active Directory (Azure AD) allow you to manage permissions and access to capabilities in all of Microsoft 365, which also includes Microsoft Defender for Office 365. But, if you need to limit permissions and capabilities to security features in Defender for Office 365 only, you can assign **Email & collaboration** permissions in the Microsoft 365 Defender portal. -To manage permissions in the Microsoft 365 Defender portal, go to **Permissions & roles** > **Email & collaboration roles** or <https://security.microsoft.com/securitypermissions>. You need to be a **Global administrator** or a member of the **Organization Management** role group in the Microsoft 365 Defender portal. Specifically, the **Role Management** role allows users to view, create, and modify role groups in the Microsoft 365 Defender portal, and by default, that role is assigned only to the **Organization Management** role group. +To manage Defender for Office 365 permissions in the Microsoft 365 Defender portal, go to **Permissions & roles** \> expand **Email & collaboration roles** \> select **Roles** or go directly to <https://security.microsoft.com/securitypermissions>. You need to be a **Global administrator** or a member of the **Organization Management** role group in Defender for Office 365 permissions. Specifically, the **Role Management** role in Defender for Office 365 allows users to view, create, and modify Defender for Office 365 role groups. By default, that role is assigned only to the **Organization Management** role group (and by extension, global administrators). > [!NOTE]-> Some capabilities of Microsoft Defender for Office require additional permissions in the Exchange admin center. For more information, see [Permissions in Exchange Online](/exchange/permissions-exo/permissions-exo). +> Some Defender for Office 365 features require additional permissions in Exchange Online. For more information, see [Permissions in Exchange Online](/exchange/permissions-exo/permissions-exo). > > For information about permissions in the Microsoft Purview compliance portal, see [Permissions in the Microsoft Purview compliance portal](../../compliance/microsoft-365-compliance-center-permissions.md). ## Relationship of members, roles, and role groups -Permissions in the Microsoft 365 Defender portal are based on the role-based access control (RBAC) permissions model. RBAC is the same permissions model that's used by most Microsoft 365 services, so if you're familiar with the permission structure in these services, granting permissions in the Microsoft 365 Defender portal will be very familiar. +Defender for Office 365 permissions in the Microsoft 365 Defender portal are based on the role-based access control (RBAC) permissions model. RBAC is the same permissions model that's used by most Microsoft 365 services, so if you're familiar with the permission structure in these services, granting permissions in the Microsoft 365 Defender portal will be very familiar. A **role** grants the permissions to do a set of tasks. A **role group** is a set of roles that lets people do their jobs in the Microsoft 365 Defender portal. -The Microsoft 365 Defender portal> includes default role groups for the most common tasks and functions that you'll need to assign. Generally, we recommend simply adding individual users as **members** to the default role groups. +Defender for Office 365 permissions in the Microsoft 365 Defender portal includes default role groups for the most common tasks and functions that you'll need to assign. Generally, we recommend simply adding individual users as **members** to the default role groups. :::image type="content" source="../../media/2a16d200-968c-4755-98ec-f1862d58cb8b.png" alt-text="The relationship of a role group to its roles and members" lightbox="../../media/2a16d200-968c-4755-98ec-f1862d58cb8b.png"::: |
| security | Respond Compromised Connector | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/respond-compromised-connector.md | Here are some of the characteristics of a compromised connector: - Sudden spike in outbound mail volume. -- Mismatch between P1 and P2 senders in outbound mails. For more information on P1 and P2 senders, see [How EOP validates the From address to prevent phishing](how-office-365-validates-the-from-address.md#an-overview-of-email-message-standards).+- Mismatch between P1 and P2 senders in outbound mails. For more information on P1 and P2 senders, see [How EOP validates the From address to prevent phishing](anti-phishing-from-email-address-validation.md#an-overview-of-email-message-standards). - Outbound mails sent from a domain that is not provisioned or registered. |
| security | Tenant Wide Setup For Increased Security | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/tenant-wide-setup-for-increased-security.md | To automate your setup of Microsoft Defender for Office 365 visit the Standard a |Area|Default policy?|Recommendation| ||||-|**Anti-phishing**|Yes|Configure the default anti-phishing policy as described here: [Configure anti-phishing protection settings in EOP and Defender for Office 365](protect-against-threats.md#part-2anti-phishing-protection-in-eop-and-defender-for-office-365). <p> More information: <ul><li>[Anti-phishing policies in Microsoft 365](set-up-anti-phishing-policies.md)</li><li>[Recommended anti-phishing policy settings in Microsoft Defender for Office 365](recommended-settings-for-eop-and-office365.md#anti-phishing-policy-settings-in-microsoft-defender-for-office-365)</li><li> [Impersonation insight](impersonation-insight.md)</li><li>[Spoof intelligence insight in EOP](learn-about-spoof-intelligence.md)</li><li>[Manage the Tenant Allow/Block List](manage-tenant-allow-block-list.md).</li></ul>| +|**Anti-phishing**|Yes|Configure the default anti-phishing policy as described here: [Configure anti-phishing protection settings in EOP and Defender for Office 365](protect-against-threats.md#part-2anti-phishing-protection-in-eop-and-defender-for-office-365). <p> More information: <ul><li>[Anti-phishing policies in Microsoft 365](set-up-anti-phishing-policies.md)</li><li>[Recommended anti-phishing policy settings in Microsoft Defender for Office 365](recommended-settings-for-eop-and-office365.md#anti-phishing-policy-settings-in-microsoft-defender-for-office-365)</li><li> [Impersonation insight](anti-phishing-mdo-impersonation-insight.md)</li><li>[Spoof intelligence insight in EOP](learn-about-spoof-intelligence.md)</li><li>[Manage the Tenant Allow/Block List](manage-tenant-allow-block-list.md).</li></ul>| |**Anti-Malware Engine**|Yes|Configure the default anti-malware policy as described here: [Configure anti-malware protection settings in EOP](protect-against-threats.md#part-1anti-malware-protection-in-eop). <p> More information: <ul><li>[Anti-malware protection](anti-malware-protection.md)</li><li>[Recommended anti-malware policy settings](recommended-settings-for-eop-and-office365.md#eop-anti-malware-policy-settings)</li><li>[Configure anti-malware policies](configure-anti-malware-policies.md)</li></ul>| |**Safe Attachments in Defender for Office 365**|No|Configure the global settings for Safe Attachments and create a Safe Attachments policy as described here: [Configure Safe Attachments settings in Microsoft Defender for Office 365](protect-against-threats.md#safe-attachments-policies-in-microsoft-defender-for-office-365). <p> More information: <ul><li>[Recommended Safe Attachments settings](recommended-settings-for-eop-and-office365.md#safe-attachments-settings)</li><li>[Safe Attachments in Microsoft Defender for Office 365](safe-attachments.md)</li><li>[Set up Safe Attachments policies](set-up-safe-attachments-policies.md)</li><li>[Safe Attachments for SharePoint, OneDrive, and Microsoft Teams](mdo-for-spo-odb-and-teams.md)</li><li>[Safe Documents in Microsoft 365 E5](safe-docs.md)</li></ul>| |**Safe Links in Microsoft Defender for Office 365**|No|Create a Safe Links policy as described here: [Configure Safe Links settings in Microsoft Defender for Office 365](protect-against-threats.md#safe-links-policies-in-microsoft-defender-for-office-365). <p> More information: <ul><li>[Recommended Safe Links settings](recommended-settings-for-eop-and-office365.md#safe-links-settings)</li><li>[Set up Safe Links policies](set-up-safe-links-policies.md)</li><li>[Safe Links in Microsoft Defender for Office 365](safe-links.md)</li></ul>| |
| security | View Email Security Reports | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/security/office-365-security/view-email-security-reports.md | On the **Threat protection status** page, the .+- **Anti-malware engine**: Malicious files detected in SharePoint, OneDrive, and Microsoft Teams by the [built-in virus detection in Microsoft 365](anti-malware-protection-for-spo-odfb-teams-about.md). - **MDO detonation**: Malicious files detected by [Safe Attachments for SharePoint, OneDrive, and Microsoft Teams](mdo-for-spo-odb-and-teams.md). - **File reputation**: The message contains a file that was previously identified as malicious in other Microsoft 365 organizations. |
| solutions | Collaborate As Team | https://github.com/MicrosoftDocs/microsoft-365-docs/commits/public/microsoft-365/solutions/collaborate-as-team.md | +- chat-teams-channels-revamp - seo-marvel-apr2020 - admindeeplinkMAC - admindeeplinkTEAMS This video shows the configuration steps described in this document.</br> Sharing in Microsoft 365 is governed at its highest level by the [B2B external collaboration settings in Azure Active Directory](/azure/active-directory/external-identities/delegate-invitations). If guest sharing is disabled or restricted in Azure AD, this setting overrides any sharing settings that you configure in Microsoft 365. -Check the B2B external collaboration settings to ensure that sharing with guests is not blocked. +Check the B2B external collaboration settings to ensure that sharing with guests isn't blocked.  |