Workaround for signing in to AADJ devices with an expired password when using PTA

[Ryan Steele]

We are using Azure AD Connect with Pass-Through Authentication enabled. We're having an issue where users are getting an error saying "The sign-in method you're trying to use isn't allowed" if they attempt to sign in to an Azure AD-joined device with an expired password.

This is listed as an "Unsupported scenario" at Azure AD Connect: Pass-through Authentication - Current limitations - Microsoft Entra | Microsoft Le..., but the article also says that enabling password hash synchronization is a workaround for all unsupported scenarios (except integration with AAD Connect Health), and I can confirm we do have PHS enabled.

Is this an error in the document, or should this be working? If it is an error in the document, is there another workaround for this issue?

[#2]

I know it's not the question you asked, but have you considered not expiring passwords in Azure AD. This has been Microsoft's recommendation for some time now since modern authentication options have developed and improved.

Secondly, in this scenario - can the users not reset their passwords from the login prompt using SSPR? Or have you not enabled that option from login?

[#3]

Hi @PeterRising, and thanks for your response. The primary use case here is for newly created user accounts. When a new account is created, we set a temporary password and provide it to the user for them to use to sign in for the first time, but we want to ensure that the user does not continue to use that password.

I suppose we could either a.) not provide the end user with the temporary password and force them to use SSPR at first sign-in, or b.) leave the "User must change password" flag unset, provide the temporary password to the user, and enforce the password change through some other mechanism.

I'm interested to hear how other organizations are handling this.

[#4]

Hi Ryan,

We are in the exact same scenario here. Both with Newly created and expired passwords.

Our current on prem devices obviously prompt up to update the password, we obviously assumed this would work in the same way. We started rolling out some devices on Azure AD only before moving everything.

We are currently implementing the Password Hash Sync to see whether this helps. Happy to feed back on how it went! It would be interesting to hear if you managed to get around this?

[#5]

Whilst looking into this further, have you ensured the -forcepasswordchangeonlogon is enabled? I see you mention you have PHS enabled which seems to be half the answer?

[#6]

Hi @Dipl0,

Thanks for the pointer regarding the -ForcePasswordChangeAtLogOn setting; I did not have it enabled. However, after enabling it, setting the "User must change password" flag on a user, and initiating an AD Connect sync, I'm still seeing the same error.

I suspect that when @Jason Fritts added this known limitation to the article, he simply failed to update the paragraph following, and that PHS is not in fact a workaround for this issue.

I do have a case open with Microsoft Support, so we'll see what comes of that.

[#7]

Hi @Ryan Steele,

Are you aware of the new Microsoft Entra feature called Lifecycle workflows? It's currently in preview, but this should help you in the future with the joiner-mover and leaver process. It can automate tasks like sending an e-mail before the start date of a new hire with a Temporary Access Pass which will be activated on a specific date you configure. This can help a user massively in the onboarding process.

My recommendation, for now, would be, as you already mentioned in an earlier comment, option A. Always let the users configure their authentication methods when they use their new accounts. This will combine configuring the authentication methods and help change the passwords for users. Since your devices are AADJ joined, There is also a possibility to log in with a Temporary Access Pass on AADJ joined device. I have written a blog post about it. You can search on Google for Temporary Access Pass (bilalelhaddouchi). I am not allowed to share any external blog posts.

Good luck!

[#8 · Accepted solution]

In the absence of any feedback from Microsoft (either here or from the support technician I've been working with), I think it is safe to assume that the documentation is incorrect and there is no "direct" workaround for the issue.

However, this blog post by @BilalelHadd is an excellent summary of the Temporary Access Pass feature, which may be a suitable workaround depending on your requirements.

[#9]

Thanks for getting back to my response. All the best!

[#10]

Did you also change the PW at time of setting the flag? See the purple note here. https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchro...

[#11]

@Jeff Johnson Yes, I did see that note, and the password is being changed at the same time the flag is being set. Thanks for checking.

[#12]

Ryan, have you considered setting Authentication Methods on new users? I have multiple clients that set a mobile phone and personal email address as Authentication Methods and only send the new user their company userPrincipalName. When a user logs on the Azure/M365 the first time, the enter their UPN and click forgot password. From there,t hey can reset their password to a new value consistent with company policy without ever knowing their initial password. I blogged about this recently with some samples to get you started: https://oxfordcomputergroup.com/resources/securely-onboard-new-users-powershell-microsoft-graph-app-...