Enabling Managed Authentication - Password Hash Sync

[HungryMoo]

Hi,

We're planning on enabling Azure Seamless SSO. Currently, we use ADFS on 2012 R2. We've enabled Password Hash Sync a few months ago and we've piloted a staged rollout for a small group of users. When moving from ADFS to PHS for authentication with our test users, we noticed a small behaviour change in our Citrix environment whereby users are prompted to enter their username for the first login post-change.

We want to migrate all users to PHS and are planning on running the following:

Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com

Is there any downtime associated with this?

If there are problems is the change easy to roll back with the below?

Set-MsolDomainAuthentication -Authentication Federated -DomainName contoso.com

Thanks in advance

P

[#2]

Hi @HungryMoo,

You shouldn't expect any downtime when changing the federation from ADFS as an Identity Provider to Azure AD with the mentioned method. But keep in mind (officially) it could take up to 24 hours before the change has been implemented. So I would recommend you implement this on the weekend.

Don't forget to change the User sign-in from Federation with AD FS to Azure AD Password Hash Synchronization, enable single sign-on within Azure AD Connect configuration, and besides this ensure that all the essential features you had before (logon hours, account lockout, password/account expiration, etc.) are configured/complied in Azure AD.

You could do a rollback with the mentioned command, but again, keep in mind that this change can take up to 24 hours. I have never experienced that it took 24 hours. It should change instantly.

[#3]

Hi,

Why do you recommend making the change over the weekend?

If a user is already logged in, then presumably they'll have a valid access token. If the change kicks in straight away, then users will be authenticated via PHS and if it doesn't kick in straight away, the user will be authenticated via ADFS.

[#4]

Hi HungryMoo,

Migrating during the weekend isn't mandatory. You could also migrate during work hours if downtime is permissible. The migration moment also relies on the company size. In case of a service-outage of rollback scenario, you always want to have some space without feeling rushed.

I have also published some blog posts about some features you manually need to activate when migrating from ADFS to Azure AD as an Identity Provider. Password expiration is one of them: https://www.bilalelhaddouchi.nl/index.php/2020/09/24/comply-your-ad-password-expiration-policy-with-...

The blog post is just an example of one of the features you need to enable/configure.

[#5]

Hi Bile,
Thanks for that - a really interesting link, a great write up as I haven't seen that information anywhere else. I've checked our Azure AD and I've got some questions around what needs to be done to ensure that Azure AD password policy matches our on premise password policy for synced accounts.

Our Azure AD password expiration policy in O365 is 400 days. Our on premise AD password policy is 30 days.

AD Connect has EnforeceCloudPasswordPolicyForPasswordSyncedUsers set to true

Examining our synced accounts (Get-AzureADUser -all $true | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled ) reveals:

18,108 users enabled for dirsync
2 accounts have disablepasswordexpiration (AD Connect accounts)
2 accounts have a passwordpolicy of "None"
18,104 accounts have a blank or null for the password policy

To ensure that the synced accounts have password policy expiry set to reflect the 30 days on premise password expiry, do I need to run the command below on all of the blank\null accounts?

Set-AzureADUser -ObjectId <user ID> -PasswordPolicies None

In addition, newly created AD accounts that sync to Azure AD have a blank\null password policy. How can I set the default for new accounts to have "None" as a password policy?

Thanks

[#6]

Enabling PHS is a painful experience, unless you're running a well maintained vanilla AD. There are 2 big issues for us:

1. Synced accounts with AD "password never expires" need to be manually updated (see link below - unfortunately the PowerShell cmdlet doesn't work for us, see attachment).

2. If an account on-premise with password never expires set changes their password, we then need to manually update that account in Azure AD (see note "For hybrid users that have a PasswordPolicies value set to DisablePassordExpiration, this value switches to None after a password change is executed on-premises").

We have over 800 enabled synced accounts with password never expires :-(. Architecturally, this seems like a poor solution, why couldn't Microsoft just sync the password never expires flag as an attribute?

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchron...

[#7 · Accepted solution]

First of all, sorry for the late response. I have been ill for a week.

1. I suggest you export all the passwordpolicies per user (the commend per user is available in the Microsoft docs link). You should be able to script this for all users with PowerShell. As soon as you have a CSV export, I would filter out the accounts that don't need a password expiration policy set (Service accounts, for example). When you have a new CSV file with all these filtered out. You should set the PasswordExpiration policy to None for the imported CSV file. Again, this should be scriptable via PowerShell.

2. Indeed, when you create a new user, you should initiate a password change on-premise and run an initial sync before the attribute changes. I would, in that case, always check the box that says, "User must change password at next logon."

Regarding your command that can't be set, I would suggest you contact Microsoft support. When running the command it shows you are warning "Unable to update the specified properties for on-premises mastered directory sync object or object currently undergoing migration." I have just run the command, and it was successfully configured. Good luck!
Regarding your suggestion, I would also love to see this attribute synced to Azure AD. Hopefully, in the future.

[#8]

Hi BilalelHadd,
Thanks for the reply.. I heard back from Microsoft - the PowerShell script isn't working as we need to unfederate the domain first.

We're looking to implement a script which monitors for password changes on a daily basis and then update the Azure AD user object with the appropriate password policy.

Thanks