If you have not considered how your password policy is effectuated in Azure AD, read on…
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 the helpdesk.
So I bet many 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?
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.
It’s available now for anyone to implement, but be aware that it is in preview. A service from Microsoft in preview holds no obligations, so they can take it away or reshape it in any way they see fit, without considering how it may impact customers who 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!
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”.
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 use user account expiration but just plain disable terminated user, 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"
Password policy misalignment
Your local password policy will NOT be synced to Azure AD.
So if you have a local password policy that expires a 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 its 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.