Forum Discussion
Workaround for signing in to AADJ devices with an expired password when using PTA
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 Learn, 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?
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.
11 Replies
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.
- Thanks for getting back to my response. All the best!
- 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?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.
- 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-registration/
