You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/partner-dynamics-365-fraud-protection.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ ms.subservice: B2C
17
17
18
18
# Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C
19
19
20
-
In this sample tutorial, learn how to integrate [Microsoft Dynamics 365 Fraud Protection](/dynamics365/fraud-protection) (DFP) with Azure Active Directory (AD) B2C.
20
+
In this sample tutorial, learn how to integrate [Microsoft Dynamics 365 Fraud Protection](/dynamics365/fraud-protection/ap-overview) (DFP) with Azure Active Directory (AD) B2C.
21
21
22
22
Microsoft DFP provides organizations with the capability to assess the risk of attempts to create fraudulent accounts and log-ins. Microsoft DFP assessment can be used by the customer to block or challenge suspicious attempts to create new fake accounts or to compromise existing accounts.
For more information, see [New-MgUserAuthenticationTemporaryAccessPassMethod](/powershell/module/microsoft.graph.identity.signins/new-mguserauthenticationtemporaryaccesspassmethod&preserve-view=true) and [Get-MgUserAuthenticationTemporaryAccessPassMethod](/powershell/module/microsoft.graph.identity.signins/get-mguserauthenticationtemporaryaccesspassmethod?view=graph-powershell-beta&preserve-view=true).
116
+
For more information, see [New-MgUserAuthenticationTemporaryAccessPassMethod](/powershell/module/microsoft.graph.identity.signins/new-mguserauthenticationtemporaryaccesspassmethod) and [Get-MgUserAuthenticationTemporaryAccessPassMethod](/powershell/module/microsoft.graph.identity.signins/get-mguserauthenticationtemporaryaccesspassmethod?view=graph-powershell-beta&preserve-view=true).
Microsoft works with researchers, law enforcement, various security teams at Microsoft, and other trusted sources to find leaked username and password pairs. Organizations with Azure AD Premium P2 licenses can create Conditional Access policies incorporating [Azure AD Identity Protection user risk detections](../identity-protection/concept-identity-protection-risks.md).
21
21
22
-
There are two locations where this policy may be configured, Conditional Access and Identity Protection. Configuration using a Conditional Access policy is the preferred method providing more context including enhanced diagnostic data, report-only mode integration, Graph API support, and the ability to utilize other Conditional Access attributes in the policy.
22
+
There are two locations where this policy may be configured, Conditional Access and Identity Protection. Configuration using a Conditional Access policy is the preferred method providing more context including enhanced diagnostic data, report-only mode integration, Graph API support, and the ability to utilize other Conditional Access attributes like sign-in frequency in the policy.
23
23
24
24
## Template deployment
25
25
@@ -41,21 +41,21 @@ Organizations can choose to deploy this policy using the steps outlined below or
1. Confirm your settings, and set **Enable policy** to **Report-only**.
45
49
1. Select **Create** to create to enable your policy.
46
50
47
-
After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.
51
+
After administrators confirm the settings using [report-only mode](howto-conditional-access-insights-reporting.md), they can move the **Enable policy** toggle from **Report-only** to **On**.
48
52
49
53
## Next steps
50
54
51
-
[Remediate risks and unblock users](../identity-protection/howto-identity-protection-remediate-unblock.md)
52
-
53
-
[Conditional Access common policies](concept-conditional-access-policy-common.md)
Copy file name to clipboardExpand all lines: articles/active-directory/conditional-access/howto-conditional-access-policy-risk.md
+14-14Lines changed: 14 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,9 +21,9 @@ Most users have a normal behavior that can be tracked, when they fall outside of
21
21
22
22
A sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner. Organizations with Azure AD Premium P2 licenses can create Conditional Access policies incorporating [Azure AD Identity Protection sign-in risk detections](../identity-protection/concept-identity-protection-risks.md#sign-in-risk).
23
23
24
-
There are two locations where this policy may be configured, Conditional Access and Identity Protection. Configuration using a Conditional Access policy is the preferred method providing more context including enhanced diagnostic data, report-only mode integration, Graph API support, and the ability to utilize other Conditional Access attributes in the policy.
24
+
There are two locations where this policy may be configured, Conditional Access and Identity Protection. Configuration using a Conditional Access policy is the preferred method providing more context including enhanced diagnostic data, report-only mode integration, Graph API support, and the ability to utilize other Conditional Access attributes like sign-in frequency in the policy.
25
25
26
-
The Sign-in risk-based policy protects users from registering MFA in risky sessions. If users aren't registered for MFA, their risky sign-ins will get blocked, and they see an AADSTS53004 error.
26
+
The Sign-in risk-based policy protects users from registering MFA in risky sessions. If users aren't registered for MFA, their risky sign-ins are blocked, and they see an AADSTS53004 error.
27
27
28
28
## Template deployment
29
29
@@ -45,21 +45,21 @@ Organizations can choose to deploy this policy using the steps outlined below or
1. Confirm your settings and set **Enable policy** to **Report-only**.
49
53
1. Select **Create** to create to enable your policy.
50
54
51
-
After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.
55
+
After administrators confirm the settings using [report-only mode](howto-conditional-access-insights-reporting.md), they can move the **Enable policy** toggle from **Report-only** to **On**.
52
56
53
57
## Next steps
54
58
55
-
[Remediate risks and unblock users](../identity-protection/howto-identity-protection-remediate-unblock.md)
56
-
57
-
[Conditional Access common policies](concept-conditional-access-policy-common.md)
Copy file name to clipboardExpand all lines: articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md
+17-28Lines changed: 17 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.date: 08/22/2022
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
13
13
manager: amycolannino
14
-
ms.reviewer: jlu, calebb, ripull
14
+
ms.reviewer: calebb, ripull, inbarc
15
15
16
16
ms.collection: M365-identity-device-management
17
17
---
@@ -58,7 +58,7 @@ Sign-in frequency previously applied to only to the first factor authentication
58
58
59
59
### User sign-in frequency and device identities
60
60
61
-
If you have Azure AD joined, hybrid Azure AD joined, or Azure AD registered devices, when a user unlocks their device or signs in interactively, this event will satisfy the sign-in frequency policy as well. In the following two examples user sign-in frequency is set to 1 hour:
61
+
On Azure AD joined, hybrid Azure AD joined, or Azure AD registered devices, unlocking the device or signing in interactivelywill satisfy the sign-in frequency policy. In the following two examples user sign-in frequency is set to 1 hour:
62
62
63
63
Example 1:
64
64
@@ -73,29 +73,23 @@ Example 2:
73
73
- At 00:45, the user returns from their break and unlocks the device.
74
74
- At 01:45, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:45.
75
75
76
-
### Require reauthentication every time (preview)
76
+
### Require reauthentication every time
77
77
78
78
There are scenarios where customers may want to require a fresh authentication, every time before a user performs specific actions. Sign-in frequency has a new option for **Every time** in addition to hours or days.
79
79
80
-
The public preview supports the following scenarios:
80
+
Supported scenarios:
81
81
82
82
- Require user reauthentication during [Intune device enrollment](/mem/intune/fundamentals/deployment-guide-enrollment), regardless of their current MFA status.
83
83
- Require user reauthentication for risky users with the [require password change](concept-conditional-access-grant.md#require-password-change) grant control.
84
84
- Require user reauthentication for risky sign-ins with the [require multifactor authentication](concept-conditional-access-grant.md#require-multi-factor-authentication) grant control.
85
85
86
86
When administrators select **Every time**, it will require full reauthentication when the session is evaluated.
87
87
88
-
> [!NOTE]
89
-
> An early preview version included the option to prompt for Secondary authentication methods only at reauthentication. This option is no longer supported and should not be used.
90
-
91
-
> [!WARNING]
92
-
> Using require reauthentication every time with the sign-in risk grant control set to **No risk** isn’t supported and will result in poor user experience.
93
-
94
88
## Persistence of browsing sessions
95
89
96
90
A persistent browser session allows users to remain signed in after closing and reopening their browser window.
97
91
98
-
The Azure AD default for browser session persistence allows users on personal devices to choose whether to persist the session by showing a “Stay signed in?” prompt after successful authentication. If browser persistence is configured in AD FS using the guidance in the article [AD FS Single Sign-On Settings](/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-settings#enable-psso-for-office-365-users-to-access-sharepoint-online), we'll comply with that policy and persist the Azure AD session as well. You can also configure whether users in your tenant see the “Stay signed in?” prompt by changing the appropriate setting in the company branding pane in Azure portal using the guidance in the article [Customize your Azure AD sign-in page](../fundamentals/customize-branding.md).
92
+
The Azure AD default for browser session persistence allows users on personal devices to choose whether to persist the session by showing a “Stay signed in?” prompt after successful authentication. If browser persistence is configured in AD FS using the guidance in the article [AD FS single sign-on settings](/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-settings#enable-psso-for-office-365-users-to-access-sharepoint-online), we'll comply with that policy and persist the Azure AD session as well. You can also configure whether users in your tenant see the “Stay signed in?” prompt by changing the appropriate setting in the [company branding pane](../fundamentals/customize-branding.md).
99
93
100
94
## Configuring authentication session controls
101
95
@@ -123,13 +117,10 @@ To make sure that your policy works as expected, the recommended best practice i
123
117
124
118
1. Under **Access controls** > **Session**.
125
119
1. Select **Sign-in frequency**.
126
-
1. Enter the required value of days or hours in the first text box.
127
-
1. Select a value of **Hours** or **Days** from dropdown.
120
+
1. Choose **Periodic reauthentication** and enter a value of hours or days or select **Every time**.
128
121
1. Save your policy.
129
122
130
-
131
-
132
-
On Azure AD registered Windows devices, sign in to the device is considered a prompt. For example, if you've configured the sign-in frequency to 24 hours for Office apps, users on Azure AD registered Windows devices will satisfy the sign-in frequency policy by signing in to the device and will be not prompted again when opening Office apps.
123
+
> 
133
124
134
125
### Policy 2: Persistent browser session
135
126
@@ -144,13 +135,12 @@ On Azure AD registered Windows devices, sign in to the device is considered a pr
144
135
145
136
1. Under **Access controls** > **Session**.
146
137
1. Select **Persistent browser session**.
147
-
1. Select a value from dropdown.
148
-
1. Save your policy.
149
138
150
-
139
+
> [!NOTE]
140
+
> Persistent Browser Session configuration in Azure AD Conditional Access overrides the “Stay signed in?” setting in the company branding pane in the Azure portal for the same user if you have configured both policies.
151
141
152
-
> [!NOTE]
153
-
> Persistent Browser Session configuration in Azure AD Conditional Access will overwrite the “Stay signed in?” setting in the company branding pane in the Azure portal for the same user if you have configured both policies.
142
+
1. Select a value from dropdown.
143
+
1. Save your policy.
154
144
155
145
### Policy 3: Sign-in frequency control every time risky user
156
146
@@ -165,25 +155,24 @@ On Azure AD registered Windows devices, sign in to the device is considered a pr
165
155
1. Under **Cloud apps or actions** > **Include**, select **All cloud apps**.
166
156
1. Under **Conditions** > **User risk**, set **Configure** to **Yes**. Under **Configure user risk levels needed for policy to be enforced** select **High**, then select **Done**.
167
157
1. Under **Access controls** > **Grant**, select **Grant access**, **Require password change**, and select **Select**.
168
-
1. Under **Session controls** > **Sign-in frequency**, select **Every time (preview)**.
158
+
1. Under **Session controls** > **Sign-in frequency**, select **Every time**.
169
159
1. Confirm your settings and set **Enable policy** to **Report-only**.
170
160
1. Select **Create** to create to enable your policy.
171
161
172
162
After administrators confirm your settings using [report-only mode](howto-conditional-access-insights-reporting.md), they can move the **Enable policy** toggle from **Report-only** to **On**.
173
163
174
164
### Validation
175
165
176
-
Use the What-If tool to simulate a sign-in from the user to the target application and other conditions based on how you configured your policy. The authentication session management controls show up in the result of the tool.
177
-
178
-
166
+
Use the [What If tool](what-if-tool.md) to simulate a sign-in from the user to the target application and other conditions based on how you configured your policy. The authentication session management controls show up in the result of the tool.
179
167
180
168
## Prompt tolerance
181
169
182
-
We factor for five minutes of clock skew, so that we don’t prompt users more often than once every five minutes. If the user has done MFA in the last 5 minutes, and they hit another Conditional Access policy that requires reauthentication, we won't prompt the user. Over-promoting users for reauthentication can impact their productivity and increase the risk of users approving MFA requests they didn’t initiate. We highly recommend using “Sign-in frequency – every time” only for specific business needs.
170
+
We factor for five minutes of clock skew, so that we don’t prompt users more often than once every five minutes. If the user has done MFA in the last 5 minutes, and they hit another Conditional Access policy that requires reauthentication, we won't prompt the user. Over-promoting users for reauthentication can impact their productivity and increase the risk of users approving MFA requests they didn’t initiate. Use “Sign-in frequency – every time” only for specific business needs.
183
171
184
172
## Known issues
185
-
- If you configure sign-in frequency for mobile devices, authentication after each sign-in frequency interval could be slow (it can take 30 seconds on average). Also, it could happen across various apps at the same time.
186
-
- In iOS devices, if an app configures certificates as the first authentication factor and the app has both Sign-in frequency and [Intune mobile application management](/mem/intune/apps/app-lifecycle) policies applied, the end-users will be blocked from signing in to the app when the policy is triggered.
173
+
174
+
- If you configure sign-in frequency for mobile devices: Authentication after each sign-in frequency interval could be slow, it can take 30 seconds on average. Also, it could happen across various apps at the same time.
175
+
- On iOS devices: If an app configures certificates as the first authentication factor and the app has both Sign-in frequency and [Intune mobile application management policies](/mem/intune/apps/app-lifecycle) applied, end-users are blocked from signing in to the app when the policy triggers.
0 commit comments