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 two new features that have been introduced into public preview, are:
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.
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!
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
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.
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.
As with preview features, this one is far from perfect, so please mind the gap!
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”.
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 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"
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.
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.
After a few months away from bloggin because family and holiday and one self is important to tend to, I…
Conditional Access and multi tenancy can be tough on anyone... (more…)
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/
Passwordless with FIDO2 is becoming a real option for enterprises that are adopting the cloud. In this guest blog post…
I published a PowerShell Gallery script, that will get you through this headache in a jiffy. (more…)
I was once again fortunate enough to be invited to write another article on how to interact with Intune via…
This website uses cookies to track views anonymously with analytics.