Forum Discussion
Passwords that include ( # and or ! ) not working on mobile devices, but work on Windows or PCs
We are experiencing issues with some of our users where they have a # and or a ! in their password. when they use SSPR, to create a new PW, the passwords seem to work fine on their work station endpo...
What characters allowed for user's password is documented here https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#:~:text=the%20%22%40%22%20symbol-,Azure%20AD%20password%20policies,managed%20directly%20in%20Azure%20AD.&text=By%20default%2C%20an%20account%20is,locked%20out%20for%20one%20minute.
I see both ! and # characters are allowed.
My understanding is that when they type the password on login screen from PC/Laptop it is accepted but the same password is not accepted when supplied from Mobile phone.
If your users are cloud only Azure AD collect and validate the password and users are federated, password is collected by ADFS and verified by on-premise AD. You need to look which authority is collecting the password and trying to verify. Either the one who is collecting(ADFS form based page or Azure AD login page) is not able to pass it forward to proper authentication. However, if it can not forward then, I am expecting the authority to return error in response, which in your case no error. let us examine in little more detail
- User goes to Application (portal.office.com for example)
- User type username and redirected to Federation server, if federated else prompt for password. What is your scenario?
- User types the password and click on sign in button
- What do they see on the mobile screen next?
I see both ! and # characters are allowed.
My understanding is that when they type the password on login screen from PC/Laptop it is accepted but the same password is not accepted when supplied from Mobile phone.
If your users are cloud only Azure AD collect and validate the password and users are federated, password is collected by ADFS and verified by on-premise AD. You need to look which authority is collecting the password and trying to verify. Either the one who is collecting(ADFS form based page or Azure AD login page) is not able to pass it forward to proper authentication. However, if it can not forward then, I am expecting the authority to return error in response, which in your case no error. let us examine in little more detail
- User goes to Application (portal.office.com for example)
- User type username and redirected to Federation server, if federated else prompt for password. What is your scenario?
- User types the password and click on sign in button
- What do they see on the mobile screen next?
Jai Verma This seems to have been a one-off scenario and we have gone away from ADFS.