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/authentication/concept-sspr-policy.md
+16-16Lines changed: 16 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,30 +1,30 @@
1
1
---
2
2
title: Self-service password reset policies - Azure Active Directory
3
-
description: Configure Azure AD self-service password reset policy options
3
+
description: Learn about the different Azure Active Directory self-service password reset policy options
4
4
5
5
services: active-directory
6
6
ms.service: active-directory
7
7
ms.subservice: authentication
8
8
ms.topic: conceptual
9
-
ms.date: 11/21/2019
9
+
ms.date: 03/20/2020
10
10
11
11
ms.author: iainfou
12
12
author: iainfoulds
13
13
manager: daveba
14
14
ms.reviewer: sahenry
15
15
ms.collection: M365-identity-device-management
16
16
---
17
-
# Password policies and restrictions in Azure Active Directory
17
+
# Self-service password reset policies and restrictions in Azure Active Directory
18
18
19
19
This article describes the password policies and complexity requirements associated with user accounts in your Azure Active Directory (Azure AD) tenant.
20
20
21
21
## Administrator reset policy differences
22
22
23
-
**Microsoft enforces a strong default *two-gate* password reset policy for any Azure administrator role** this policy may be different from the one you have defined for your users and cannot be changed. You should always test password reset functionality as a user without any Azure administrator roles assigned.
23
+
**Microsoft enforces a strong default *two-gate* password reset policy for any Azure administrator role**. This policy may be different from the one you have defined for your users, and this policy can't be changed. You should always test password reset functionality as a user without any Azure administrator roles assigned.
24
24
25
25
With a two-gate policy, **administrators don't have the ability to use security questions**.
26
26
27
-
The two-gate policy requires two pieces of authentication data, such as an **email address**, **authenticator app**, or a **phone number**. A two-gate policy applies in the following circumstances:
27
+
The two-gate policy requires two pieces of authentication data, such as an *email address*, *authenticator app*, or a *phone number*. A two-gate policy applies in the following circumstances:
28
28
29
29
* All the following Azure administrator roles are affected:
30
30
* Helpdesk administrator
@@ -55,15 +55,15 @@ The two-gate policy requires two pieces of authentication data, such as an **ema
55
55
56
56
### Exceptions
57
57
58
-
A one-gate policy requires one piece of authentication data, such as an email address *or* phone number. A one-gate policy applies in the following circumstances:
58
+
A one-gate policy requires one piece of authentication data, such as an email address or phone number. A one-gate policy applies in the following circumstances:
59
59
60
60
* It's within the first 30 days of a trial subscription; or
61
-
* A custom domain hasn't been configured for your Azure AD tenant so is using the default **.onmicrosoft.com*. Note that the default **.onmicrosoft.com* domain isn't recommended for production use; and
61
+
* A custom domain hasn't been configured for your Azure AD tenant so is using the default **.onmicrosoft.com*. The default **.onmicrosoft.com* domain isn't recommended for production use; and
62
62
* Azure AD Connect isn't synchronizing identities
63
63
64
64
## UserPrincipalName policies that apply to all user accounts
65
65
66
-
Every user account that needs to sign in to Azure AD must have a unique user principal name (UPN) attribute value associated with their account. The following table outlines the policies that apply to both on-premises Active Directory user accounts that are synchronized to the cloud and to cloud-only user accounts:
66
+
Every user account that needs to sign in to Azure AD must have a unique user principal name (UPN) attribute value associated with their account. The following table outlines the policies that apply to both on-premises Active Directory Domain Services user accounts that are synchronized to the cloud and to cloud-only user accounts:
67
67
68
68
| Property | UserPrincipalName requirements |
69
69
| --- | --- |
@@ -77,19 +77,19 @@ The following table describes the password policy settings applied to user accou
| Password restrictions |<ul><li>A minimum of 8 characters and a maximum of 256 characters.</li><li>Requires three out of four of the following:<ul><li>Lowercase characters.</li><li>Uppercase characters.</li><li>Numbers (0-9).</li><li>Symbols (see the previous password restrictions).</li></ul></li></ul> |
83
83
| Password expiry duration (Maximum password age) |<ul><li>Default value: **90** days.</li><li>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Azure Active Directory Module for Windows PowerShell.</li></ul> |
84
84
| Password expiry notification (When users are notified of password expiration) |<ul><li>Default value: **14** days (before password expires).</li><li>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet.</li></ul> |
85
-
| Password expiry (Let password's never expire) |<ul><li>Default value: **false** (indicates that password's have an expiration date).</li><li>The value can be configured for individual user accounts by using the `Set-MsolUser` cmdlet.</li></ul> |
85
+
| Password expiry (Let passwords never expire) |<ul><li>Default value: **false** (indicates that password's have an expiration date).</li><li>The value can be configured for individual user accounts by using the `Set-MsolUser` cmdlet.</li></ul> |
86
86
| Password change history | The last password *can't* be used again when the user changes a password. |
87
87
| Password reset history | The last password *can* be used again when the user resets a forgotten password. |
88
-
| Account lockout | After 10 unsuccessful sign-in attempts with the wrong password, the user is locked out for one minute. Further incorrect sign-in attempts lock out the user for increasing durations of time. [Smart lockout](howto-password-smart-lockout.md) tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lockout. |
88
+
| Account lockout | After 10 unsuccessful sign-in attempts with the wrong password, the user is locked out for one minute. Further incorrect sign-in attempts lock out the user for increasing durations of time. [Smart lockout](howto-password-smart-lockout.md) tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lock out. |
89
89
90
90
## Set password expiration policies in Azure AD
91
91
92
-
A global administrator or user administrator for a Microsoft cloud service can use the Microsoft Azure AD Module for Windows PowerShell to set user passwords not to expire. You can also use Windows PowerShell cmdlets to remove the never-expires configuration or to see which user passwords are set to never expire.
92
+
A *global administrator* or *user administrator* for a Microsoft cloud service can use the *Microsoft Azure AD Module for Windows PowerShell* to set user passwords not to expire. You can also use Windows PowerShell cmdlets to remove the never-expires configuration or to see which user passwords are set to never expire.
93
93
94
94
This guidance applies to other providers, such as Intune and Office 365, which also rely on Azure AD for identity and directory services. Password expiration is the only part of the policy that can be changed.
95
95
@@ -98,14 +98,14 @@ This guidance applies to other providers, such as Intune and Office 365, which a
98
98
99
99
## Set or check the password policies by using PowerShell
100
100
101
-
To get started, you need to [download and install the Azure AD PowerShell module](https://docs.microsoft.com/powershell/module/Azuread/?view=azureadps-2.0). After you have it installed, you can use the following steps to configure each field.
101
+
To get started, [download and install the Azure AD PowerShell module](https://docs.microsoft.com/powershell/module/Azuread/?view=azureadps-2.0). After the module is installed, use the following steps to configure each field.
102
102
103
103
### Check the expiration policy for a password
104
104
105
105
1. Connect to Windows PowerShell by using your user administrator or company administrator credentials.
106
-
1.Execute one of the following commands:
106
+
1.Run one of the following commands:
107
107
108
-
* To see if a single user’s password is set to never expire, run the following cmdlet by using the UPN (for example, *aprilr\@contoso.onmicrosoft.com*) or the user ID of the user you want to check:
108
+
* To see if a single user's password is set to never expire, run the following cmdlet by using the UPN (for example, *aprilr\@contoso.onmicrosoft.com*) or the user ID of the user you want to check:
@@ -152,7 +152,7 @@ To get started, you need to [download and install the Azure AD PowerShell module
152
152
```
153
153
154
154
> [!WARNING]
155
-
> Passwords set to `-PasswordPolicies DisablePasswordExpiration` still age based on the `pwdLastSet` attribute. If you set the user passwords to never expire and then 90+ days go by, the passwords expire. Based on the `pwdLastSet` attribute, if you change the expiration to `-PasswordPolicies None`, all passwords that have a `pwdLastSet` older than 90 days require the user to change them the next time they sign in. This change can affect a large number of users.
155
+
> Passwords set to `-PasswordPolicies DisablePasswordExpiration` still age based on the `pwdLastSet` attribute. Based on the `pwdLastSet` attribute, if you change the expiration to `-PasswordPolicies None`, all passwords that have a `pwdLastSet` older than 90 days require the user to change them the next time they sign in. This change can affect a large number of users.
Copy file name to clipboardExpand all lines: articles/active-directory/authentication/howto-mfa-reporting.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -123,13 +123,13 @@ The sign-in activity reports for MFA give you access to the following informatio
123
123
124
124
First, ensure that you have the [MSOnline V1 PowerShell module](https://docs.microsoft.com/powershell/azure/active-directory/overview?view=azureadps-1.0) installed.
125
125
126
-
Identify users who have registered for MFA using the PowerShell that follows.
126
+
Identify users who have registered for MFA using the PowerShell that follows. This set of commands excludes disabled users since these accounts cannot authenticate against Azure AD.
Identify users who have not registered for MFA using the PowerShell that follows.
130
+
Identify users who have not registered for MFA using the PowerShell that follows. This set of commands excludes disabled users since these accounts cannot authenticate against Azure AD.
Copy file name to clipboardExpand all lines: articles/active-directory/conditional-access/block-legacy-authentication.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ services: active-directory
6
6
ms.service: active-directory
7
7
ms.subservice: conditional-access
8
8
ms.topic: conceptual
9
-
ms.date: 02/25/2020
9
+
ms.date: 03/20/2020
10
10
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
@@ -104,6 +104,8 @@ The safety feature is necessary because *block all users and all cloud apps* has
104
104
105
105
You can satisfy this safety feature by excluding one user from your policy. Ideally, you should define a few [emergency-access administrative accounts in Azure AD](../users-groups-roles/directory-emergency-access.md) and exclude them from your policy.
106
106
107
+
Using [report-only mode](concept-conditional-access-report-only.md) when enabling your policy to block legacy authentication provides your organization an opportunity to monitor what the impact of the policy would be.
108
+
107
109
## Policy deployment
108
110
109
111
Before you put your policy into production, take care of:
@@ -133,5 +135,6 @@ If you block legacy authentication using the **Other clients** condition, you ca
133
135
134
136
## Next steps
135
137
138
+
-[Determine impact using Conditional Access report-only mode](howto-conditional-access-report-only.md)
136
139
- If you are not familiar with configuring Conditional Access policies yet, see [require MFA for specific apps with Azure Active Directory Conditional Access](app-based-mfa.md) for an example.
137
140
- For more information about modern authentication support, see [How modern authentication works for Office 2013 and Office 2016 client apps](/office365/enterprise/modern-auth-for-office-2013-and-2016)
To configure a Conditional Access policy in report-only mode:
21
21
22
+
> [!IMPORTANT]
23
+
> If your organization has not already, [Set up Azure Monitor integration with Azure AD](#set-up-azure-monitor-integration-with-azure-ad). This process must take place before data will be available to review.
24
+
22
25
1. Sign into the **Azure portal** as a Conditional Access administrator, security administrator, or global administrator.
23
26
1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
24
27
1. Select **New policy**.
@@ -52,7 +55,7 @@ More information about Azure Monitor pricing can be found on the [Azure Monitor
52
55
53
56
## View Conditional Access Insights workbook
54
57
55
-
Once you’ve integrated your Azure AD logs with Azure Monitor, you can monitor the impact of Conditional Access policies using the new Conditional Access insights workbooks.
58
+
Once you've integrated your Azure AD logs with Azure Monitor, you can monitor the impact of Conditional Access policies using the new Conditional Access insights workbooks.
56
59
57
60
1. Sign into the **Azure portal** as a security administrator or global administrator.
58
61
1. Browse to **Azure Active Directory** > **Workbooks**.
@@ -75,9 +78,9 @@ Once you’ve integrated your Azure AD logs with Azure Monitor, you can monitor
75
78
76
79
Customers have noticed that queries sometimes fail if the wrong or multiple workspaces are associated with the workbook. To fix this problem, click **Edit** at the top of the workbook and then the Settings gear. Select and then remove workspaces that are not associated with the workbook. There should be only one workspace associated with each workbook.
77
80
78
-
### Why doesn’t the Conditional Access Policies dropdown parameter contain my policies?
81
+
### Why doesn't the Conditional Access Policies dropdown parameter contain my policies?
79
82
80
-
The Conditional Access Policies dropdown is populated by querying the most recent sign-ins over a period of 4 hours. If a tenant doesn’t have any sign-ins in the past 4 hours, it is possible that the dropdown will be empty. If this delay is a persistent problem, such as in small tenants with infrequent sign-ins, admins can edit the query for the Conditional Access Policies dropdown and extend the time for the query to a time longer than 4 hours.
83
+
The Conditional Access Policies dropdown is populated by querying the most recent sign-ins over a period of 4 hours. If a tenant doesn't have any sign-ins in the past 4 hours, it is possible that the dropdown will be empty. If this delay is a persistent problem, such as in small tenants with infrequent sign-ins, admins can edit the query for the Conditional Access Policies dropdown and extend the time for the query to a time longer than 4 hours.
Copy file name to clipboardExpand all lines: articles/active-directory/develop/authentication-scenarios.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,6 +74,23 @@ Tokens are only valid for a limited amount of time. Usually the STS provides a p
74
74
75
75
Access tokens are passed to a Web API as the bearer token in the `Authorization` header. An app can provide a refresh token to the STS, and if the user access to the app wasn't revoked, it will get back a new access token and a new refresh token. This is how the scenario of someone leaving the enterprise is handled. When the STS receives the refresh token, it won't issue another valid access token if the user is no longer authorized.
76
76
77
+
### How each flow emits tokens and codes
78
+
79
+
Depending on how your client is built, it can use one (or several) of the authentication flows supported by Azure AD. These flows can produce a variety of tokens (id_tokens, refresh tokens, access tokens) as well as authorization codes, and require different tokens to make them work. This chart provides an overview:
|[Client credentials](v2-oauth2-client-creds-grant-flow.md)||| x (app-only)|||
89
+
90
+
Tokens issued via the implicit mode have a length limitation due to being passed back to the browser via the URL (where `response_mode` is `query` or `fragment`). Some browsers have a limit on the size of the URL that can be put in the browser bar and fail when it is too long. Thus, these tokens do not have `groups` or `wids` claims.
91
+
92
+
Now that you have an overview of the basics, read on to understand the identity app model and API, learn how provisioning works in Azure AD, and get links to detailed information about common scenarios Azure AD supports.
93
+
77
94
## Application model
78
95
79
96
Applications can sign in users themselves or delegate sign-in to an identity provider. See [Authentication flows and app scenarios](authentication-flows-app-scenarios.md) to learn about sign-in scenarios supported by Azure AD.
0 commit comments