AzureAD Password Policy impact after moving from AADConnec sync to Full cloud

[SRPfr]

Hi  all,

We plan to disable AADconnect dirsync to go full cloud and use only Azure AD.

AD OnPrem domain use a very "light" password policy, less restrictive than Azure AD.

AD OnPrem:

- Complexity : Disabled

- Minimum password lenght : 6 characters

On Azure AD:

- Complexity : Enabled

- Minimum password lenght : 8 characters

- We use the global setting "password never expire" and default settings.

Question:

With the Azure AD global setting "password never expire" : when all users go "Cloud Only" there will be no impact, right ?

Even if they have only a 6 characters password without complexity, they can continue to use this password with an Azure AD cloud only account?

Thanks !

[SRPfr]

We plan to disable AADconnect dirsync to go full cloud and use only Azure AD.

AD OnPrem domain use a very "light" password policy, less restrictive than Azure AD.

AD OnPrem:

- Complexity : Disabled

- Minimum password lenght : 6 characters

On Azure AD:

- Complexity : Enabled

- Minimum password lenght : 8 characters

- We use the global setting "password never expire" and default settings.

Question:

With the Azure AD global setting "password never expire" : when all users go "Cloud Only" there will be no impact, right ?

Even if they have only a 6 characters password without complexity, they can continue to use this password with an Azure AD cloud only account?

Thanks !

[#3]

Hi, when leaving AAD Connect and being cloud-only the Azure AD password policy is applied (to all user accounts that are created and managed directly in Azure AD). That is, it will take precedence and you must meet the policy requirements minimum of 8 characters.

[#4]

Yes, it forces them to change to at least 8 to comply with AAD.

Good luck!
Moe

[#5]

Yes this is right, but :
- what will be the impact for user when he connect the first time with the cloud-only the Azure AD account, with a 6 characters password and the Tenant set with « password never expire » ?

It’s like an AD Onprem password policy ? : Password Policy only evaluated when the password is changed or expired ?
-> so no impact for user connexion even if the current password don’t meet the AzureAD password policy ?

[#6]

Yes but when they will be forced to change the password if Tenant is set with « password never expire » ?

- what will be the impact for user when he connect the first time with the cloud-only the Azure AD account, with a 6 characters password and the Tenant set with « password never expire » ?

It’s like an AD Onprem password policy ? : Password Policy only evaluated when the password is changed or expired ?
-> so no impact for user connexion even if the current password don’t meet the AzureAD password policy ?

[#7]

Hi, enable SSPR while you’re at it. As for the password if it doesn't meet the policy requirements, the user is prompted to try again.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy

[#8]

Thanks @ChristianBergstrom for your answer.

Do you meen "If the password doesn't meet the policy requirements, the user is prompted to try again " : at the user connexion ?

My question is only related to user connexion, because password policy is set to never expire.

I haven't seen any Microsoft document that indicates that the password need to meet the AzureAD password policy at the user connexion.

For me the AAD password policy work like AD password policy : the password policy evaluation is made only when a user change the password, not at the connexion.

Did you have perhaps a reference?

We will activate SSPR only after the Tenant will be full cloud, but all users will not be complient, and want to minimize the impact when Tenant will switch to full cloud.

[#9]

As far as I know it doesn’t matter if it’s set to never expire if the password doesn’t comply with the Azure AD password policy character requirements that’s assigned to all users being created in Azure AD. Even at the first connection, as the user objects are already there with the policy assigned.

How about opening a ticket with Microsoft support for an official response to ease your mind?