Passwords that include ( # and or ! ) not working on mobile devices, but work on Windows or PCs

[DianaLAyala]

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 endpoints but they are having issues accessing applications with the new PW on their mobile devices. 

Is there any documentation that discusses the complexities of # ! contained in a PW? 

Is there any conflict when I select 'SHIFT +3' to get the # symbol as opposed to my onboard, digital keyboard on my phone where 'Shift +3' is not needed and I can simply select the #. Same with selecting 'Shift +1' for !. 

I'm looking for any documentation to elaborate on this scenario. Thank you kindly!

[#2]

I have seen similar problem where one of the customer was using WAF(Azure Firewall) and it was WAF which was rejecting requests.
What is the error message you receieved from SSPR on mobile?

[#3]

@Jai Verma I connected with my colleague, and it seems there is no error. his response is. It's not an SSPR or mobile issue: but seems to be something connected to O365 Apps authentication.

[#4]

What characters allowed for user's password is documented here https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#:~:text=t....
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?

[#5]

@Jai Verma Thank you this is great information and I'm sharing it. However to note; we have removed ADFS from our environment. So i'll need to confirm the age of the INCs with this issue and verify if they align to ADFS.

[#6]

@Jai Verma This seems to have been a one-off scenario and we have gone away from ADFS.