The password set to never expire field can only be set for cloud based accounts: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy
We did a big O365 update in March which linked on-prem AD to Azure AD, which is why you now see the Subscription AD Linked option on the O365 User Activity view:
We’ve already had several customers comment on how powerful this link is, and it avoids confusion as to why the Password Never Expires field is set to true because this isn’t possible. Having said that, you can set this field to false, but the next time the user resets their password, Microsoft switches it back to true. Now on the flip side of this, if the O365 account only exists in the cloud, then having this field can be useful as these account should be configured to expire their password. As you can see in the Movere demo account, I have set this flag for some of the accounts to demonstrate the difference when we do training. You can find these by filtering on DirSync Enabled then Password Never Expires = TRUE:
You then need to set the Password Expiration days in O365 for these users, but of course this doesn’t impact on-prem synced users as their password reset policy to controlled via GPO, but this explains why Microsoft sets this field to FALSE by default because O365 has no control of it. Here’s where it is set in O365, but you can see why it was such a big update i.e. Movere linking on-prem AD to Azure AD.
In terms of password replication, the key item is where their account resides i.e. in the cloud only or on-prem then replicated into Azure AD / O365. If they only have a cloud based account then the Password Last Set AD should be blank and the Password Last Set O365 should be populated, assuming of course they reset their password at least once, we see lots of customer bulk import accounts that are never assigned a subscription or get logged into. Notice how Password last set AD for DirSync Enabled accounts is blank.
Now let’s look at the DirSync’ed accounts. We reset all of these accounts in AD on Feb 19, but look at the O365 dates. This is why the AD integration was such an important feature for us to release.
Comments
0 comments
Please sign in to leave a comment.