There is section under settings for Tokens, I.e. Length, allowed characters, etc.

There is a section for SMS which I think you have called out.

There is a section in forgot password where you select SMS ONLY and I think you got that one.

I think the token is saved in the directory in pwmOTP or the like.  And the user needs permissions to read theirs as well as the Proxy user needs permissions to write it.

Hmm, as far as I understood, the token is not stored in a directory attribute, if one sticks to the LocalDB as we do for the time being. Moreover, the error message stays the same, if we delete "%TOKEN%" from "Forgotten Password SMS Text" (checked out after reading your answer).

We have succeeded in letting users update their profile data like "phoneNumber", "mail" and even customary attributes ment to store phone numbers used for receiving SMS messages. Users are stored in eDirectory and apparently SSPR can read and write those attributes.

I still wonder, if the "%TO%" code is really populated from "phoneNumber" or if a different attribute might be used. "Test SMS Setting" does work with a "SMS request data" string containing an authorisation sequence required by our SMS gateway and the two codes "%TO%" and "%MESSAGE%". These two codes are obviously correctly substituted from the "Testing SMS connection" popup window asking for "to" and, well, "message". Even adding "...%TOKEN%..." to the message specified in the test popup works (though with an empty token string in the SMS message sent).

Consulting /var/log/messages, even with file log level set to "6" didn't produce much more insight compared to the error message returned by the SSPR GUI. It's servlet.AbstractPwmServlet that throws a fatal 5036 "no available contact methods of type SMSONLY available" error, joined by http.PwmResponse.

Axel

There should also be a setting to define which attribute is used to send SMS based upon.  Good news, is try the search option in the config edtory, very helpful to find things by keyword.

Thanks Geoff,

I had done an eDir LDAP trace, revealing SSPR is querying for attribute "personalMobile" before throwing the error. Testing with "personalMobile" succeeded.

Only afterwards I found the input field under "LDAP settings" allowing you to specify a different attribute to be used for sending SMS, which comes in handy, because we want our users to explicitly enter this piece of information. Our user's mobile numbers are transferred automatically to our IDMS and stored in attributes as designed by Novell and successors. These numbers are often outdated, however. Using a specific attribute for this piece of information makes the user's responsible for keeping it up to date or to leave it blank, if they are so inclined. They won't be able to reset forgotten passwords themselves, but it's their decision.

Axel

For the record can you post the name of the setting from the config?  I always forget and need to find a live system to go look it up.  Be nice if they were all listed in a doc somewhere we could search, without a working system.

LDAP ⇨ LDAP Directories ⇨ default ⇨ User Attributes ⇨ SMS Destination Address LDAP Attribute

There are quite a few more attributes listed. The last one at the bottom of the list might be interesting, if you happen to stumble across the issue we had: The standard SMS attribute "personalMobile" does not belong to any class our user's were equipped with by our IDMS, unfortunately. Trying to populate it to further test the forgotten password method consequently produces eDir errors. Before realising the opportunity to specify a custom attribute (the class of which _was_ available to our user objects) I had crafted a small LDIF to maintain the required class "homeInfo". I guess using the setting "Auto Add Object Classes" might have helped. However, I didn't test this. The class is required when user's log in to update their account with the phone number to be used by the forgotten password module.