Have you ever ran into a situation where you think everything is in place and ready to go only to run into an unexpected error? Sure you have, we all have. And the other day was no different for me. After performing an install and configuration of SSPR 3.3 in a new environment, I thought I had taken care of everything and was ready for testing.
The first test I wanted to run was to make sure that my new SSPR instance could read my existing challenge data in eDirectory. I pulled up the SSPR login page without any issues, clicked the Forgotten Password link, and entered my test user ID. And that is when things went sideways.
I expected SSPR to read my existing challenge data out of eDirectory from the sASLoginSecret attribute (you know, where NMAS sticks challenge data) since SSPR is capable of reading/writing challenge data to its own eDir attribute set (pwmResponseSet) and the NMAS attribute set. How wrong I was. Instead of getting back my challenge data I was greeted with the SSPR 5006: username is not valid or does not have a configured response” error.
This error immediately baffled me. The user ID entered was correct and I know for a fact that the user had challenge data stored in eDirectory. I even used an LDAP browser to verify it before starting the test. After doing some quick searches I came across some KB articles hosted by NetIQ that talks about some potential causes of this error on older versions of SSPR (https://www.novell.com/support/kb/doc.php?id=7011266) but that didn’t really pan out for me in my configuration.
What else could it be?
And then it dawned on me. In order for SSPR to leverage NMAS stored values, it has to be enabled within the SSPR configuration. Immediately, I went into the SSPR settings and began to look for the proper configuration. After a few seconds I found it, and sure enough, I had not enabled the NMAS option needed to read that data.
Right there, under eDirectory Settings was the unchecked box for “Enable NMAS Responses for Forgotten Password”. Obviously, with that option turned off SSPR would not attempt to read the NMAS data and would ONLY look at the SSPR attribute set. Now, the error was beginning to make sense.
Yes, the user had challenge data configured but not where SSPR could see it so in a sense, the error was accurate; only the configuration was not. In order to leverage the existing NMAS challenge data I simply needed to check this box and save my changes to the SSPR configuration. Once SSPR had restarted I was able to successfully test Forgotten Password using existing NMAS challenge data.
The moral to this story: If you want to use NMAS data with SSPR, enable NMAS data within SSPR.
An alternate moral: This error may tell you that the user does not have challenge data configured but the actual issue may be deeper than that. Do not always judge an error solely on its message.