I've recently discovered a bug in SSPR version where passwords generated by the random passwords function that contain an ampersand are not properly encoded. In the randomly generated password, the "&" gets expanded to "&" in the final password. I've already contacted support and they are filing a bug report, but I wanted to share my findings and my current workaround as this issue had been generating a lot of user support tickets for us.

The behavior occurs in both the normal Change Password module and in the Service Desk module. The encoding is visible in the Change Password module, but is invisible in the Service Desk module.

For example, if a service desk technician selects the password "Test&" from the list of randomly generated passwords, they will receive the normal dialog that states the user's password has been changed to "Test&". However, the password that actually gets pushed into the downstream directory is "Test&"

In the Change Password module, selecting the randomly generated password "Test&" from the list will insert "Test&" into the password box and the user would have to enter the password a second time to confirm, so at least what is happening is visible to the user in this case.

To work around this issue, we've added "&" to the disallowed values in each of our password policies defined in SSPR. This prevents the random password generator from generating passwords containing the symbol.

Per MicroFocus support, the bug is also present in the latest patch as well.