2 Cool new password policy features in Azure AD Connect

4 min read

Enabling preview features in Azure AD to extend your on-prem password policy to Azure AD.

A long-anticipated enhancement to Azure AD has finally entered public preview, and it kills off one of the last arguments I can think of, to stay on AD FS or Pass-Through authentication (not all though).

The what

The two new features that have been introduced into public preview, are:

The why

Well it really makes little to no sense to enforce password expiration for users on-prem accounts and then sync them straight into Azure AD and have all that go away, now does it?

The same goes for enforcing a temporary password the first time a user signs in, or after a password reset by helpdesk.

So I bet a lot of admins out there have been using PowerShell workarounds to overcome this issue, or have stuck with AD FS or Pass Through Authentication.

So it’s great the Microsoft is finally tying up some of the loose ends of Azure AD Connect.

If this misalignment of features havs never crossed your mind, then you might want to re-consider why you even have a password expiration policy in the first place?

A more modern approach that Microsoft and NIST have been advocating lately, is going for longer passwords that don’t expire, but instead rely on a good MFA implementation.

The how

All you need to do in order to enable these new features, is just run a few PowerShell commands with an account that has the required permissions.

Just be sure to read the section on caveats!

Enforce a password policy for cloud synced accounts

The following command will disable the regular behaviour in Azure AD, that will set the password policy on the users cloud identity to never expire.

This command should be run against Azure AD, I personally prefer using the Azure Cloud Shell.

Set-MsolDirSyncFeature -feature EnforceCloudPasswordPolicyForPasswordSyncedUsers $true

Syncing a temporary password

To enable the “ForcePasswordResetOnLogonFeature”, you simply execute the following command on your Azure AD Connect server:

Set-ADSyncAADCompanyFeature -ForcePasswordResetOnLogonFeature $true

Now the DOCS got me a bit confused on this one, so maybe someone can explain to me why they specify the following command:

Set-ADSyncAADCompanyFeature -ConnectorName -ForcePasswordResetOnLogonFeature $true

Because the parameter “ConnectorName” does not exist on this Cmdlet, and I tested on the latest auto updated version.

The when

It’s available now for anyone to implement, but just be aware that it is in preview. A service from Microsoft that is in preview holds no obligations, so they can take it away or reshape it in any way they see fit, without any consideration to how it may impact customers that have deployed it.

But I have never seen Microsoft abuse this right, so my vote is to enable this and get some proper testing done. It is sure to reach GA at some point in the future.

The caveats

As with preview features, this one is far from perfect, so please mind the gap!

Setting a permanent password from the cloud

Users that sign in with their temporary password through a cloud service, will be asked to set their permanent password, this will be set in Azure AD, but not directly back to your on-prem AD.

This is unless you have password writeback and self service password reset (SSPR) enabled for your tenant. @modaly_it has got you covered on how to implement this service – it’s in part four of his series on “Implementing modern security tools”.

Expired users

There is still the issue of disabled accounts being able to sign in to their could services, even though IT has set the account expiration attribute on their on-prem account.

My colleague @peterselchdahl has got you covered if you need a detailed explanation, in his article “Block sign in for accounts with password hash sync”.

If you don’t user account expiration, but just plain disable terminated user, then you are golden. Azure AD Connect will sync the “disabled” state to Azure AD.

Service accounts

Service accounts will now get their password expired, which might be less than desirable.

This is easily fixed by overwriting the accounts password policy in Azure AD with the following bit of  PowerShell through Azure Cloud Shell:

Get-AzureADUser <Service Account UPN> | Set-AzureADUser -PasswordPolicies "DisablePasswordExpiration"

Password policy misalignment

Your local password policy will NOT be synced to Azure AD.

So if you have a local password policy that expires users password after, let’s say 120 days, and you never aligned the Azure AD policy to match that. Then the Azure AD policy will still be at it’s default of 90 days, which will confuse the heck out of users, because they might get prompted to change their password after accessing a cloud resource, but not an on-prem resource.

So bottom line, make sure to align these, and read the docs for further information on this.

Final words

As always, use new knowledge responsibly, and remember to share.

I encourage you to peak through my GitHub account and follow me on Twitter for more community sharing.

Michael Mardahl

Michael works as a Cloud Architect with APENTO in Denmark. Specializing in customer journeys from classic Infrastructure to Cloud consumption. He has been in the IT industry for more than 20 years, and has experience from a broad range of IT projects. When not at work, Michael enjoys the value of spending time with family and friends, and BLOG's passionately about Enterprise Mobility whenever he has time to spare.

Recent Posts

Passwordless journey with FIDO2 – Part 3 – Engine troubles

After a few months away from bloggin because family and holiday and one self is important to tend to, I…

5 years ago

Conditional Access and the woes of being an external user

Conditional Access and multi tenancy can be tough on anyone... (more…)

5 years ago

Passwordless journey with FIDO2 – Part 2 – Usage experiences

Continuing my ongoing series on passwordless with Azure AD and FIDO2... The story continues on SCConfigMgr.com... :) https://www.scconfigmgr.com/2019/11/18/passwordless-journey-with-fido2-part-2-usage-experiences/

5 years ago

Passwordless journey with FIDO2 – Part 1 – Getting started with security keys

Passwordless with FIDO2 is becoming a real option for enterprises that are adopting the cloud. In this guest blog post…

5 years ago

Unattended access to Exchange Online using a privileged account with MFA enforced

I published a PowerShell Gallery script, that will get you through this headache in a jiffy. (more…)

5 years ago

Scripting an Intune policy sync from a Windows client

I was once again fortunate enough to be invited to write another article on how to interact with Intune via…

5 years ago

This website uses cookies to track views anonymously with analytics.