Hi!

Based on error message, you might have two or more objects with same username in userstore configured in SSPR.

What might be going on:

- after authentication in AA, AA returns username to SSPR.

- SSPR tries to search for this username in configured user store

- SSPR finds two or more users with that specific username (multiple user matches found) and cannot know for which password needs to be changed, hence throws an error.

Kind regards,

Sebastijan

Hi Sebastijan,

I actually tried to search the CN in my ldap, it only return 1 value.

Now i update to remove duplicate,

It got new error where whichever UserID i use for forget password, it will use uaadmin instead. attached is the log.

At least with regards to the duplicate user situation.
It is quite possible you are seeing a similar issue to the one that I have raised a case for with SSPR support.

(+) Inconsistent behaviour across Forgotten Password Verification Methods regarding LDAP profile sticky affinity - SSPR User Discussions - OpenText NetIQ Self Service Password Reset (microfocus.com)

I suggest that you also raise a support case, the more customers who report an issue, the more chance a fix is prioritized in a timely fashion.

Hi Alex, its weird in the first case where i only have 1 LDAP configured, but it keep trying to search for 2 times with the same LDAP, which caused duplication in the first place. After i configured to pick whichever come first, then it hit the 2nd issue where it does not match the username even when i keyed in the cn as username.

There are several configuration steps that can be related to this.

1. You have more than 1 LDAP profile configured (SSPR allows you to configure a profile that points at the same underlying LDAP directory, but with different scoping and filtering).
2. You have a single LDAP profile (default) but have configured multiple search scopes, or your search scope is too broad.
3. The LDAP user name search filter might be wrong (Settings > LDAP -> LDAP directories - <profile>) it can be configured per-profile). Normally it should look like the screenshot below.
4. The setting for LDAP duplicate mode is unsuitable for your setup (Settings > LDAP -> Global -> LDAP Duplicate Mode) - I was unable to find a duplicate mode setting that worked for me. 
5. (unlikely) but maybe this is triggered by multiple forgotten user profiles.
6. I have also seen cases where SSPR config seems to forget which LDAP profile a specific feature should use. This is referenced in the following KB article, https://support.microfocus.com/kb/doc.php?id=7017729 sometimes just reverting the settings and then setting them anew can help (as mentioned in link above)
7. Have noticed that if you have more than one LDAP profile configured and you use the "browse" feature to navigate to an OU or object in the SSPR config UI, one needs to pay careful attention to which LDAP profile the browse feature is using, Often it is not the one you want and maybe it could break things later.

For item 1, if it is a test system, easy way to verify this is to temporarily disable all but one LDAP profile (the option to disable a profile is right at the bottom when you navigate to Settings > LDAP -> LDAP directories - <profile>

Item 2 relates to "LDAP Contextless Login Roots" and is a bit harder to deal with, can go back to your design. Right now I don't recommend creating multiple LDAP profiles to work around the configuration limitations here as that just triggers issue 1 with some forgotten password verification methods.

Item 3 can be confusing, because one might think it should read %user_name% in the LDAP search filter (because that is the name of the value that AA returns via OAuth). My understanding is that it should always be %USERNAME%.

In some case you might need to have a search filter that caters for searching for this value returned by AA in other atrributes.
At our some customers I have worked with, they have a search filter that looks like this. 
(&(objectClass=person)(|(cn=%USERNAME%)(attrX=%USERNAME%)))

Where attrX is the one that contains the value returned from the external OAuth validation process.

Item 4 As I mentioned, none of the options that could be chosen here have worked for our specific setup (due to bug I have reported to vendor).

Regarding point 5 You might have configured different verification methods for different user subsets. This  would necessitate multiple forgotten user profiles. It is my understanding that the LDAP profile listed under "forgotten password profile match" is the one used to identify which user the forgotten password process operates on. That assumption seems to break down after SSPR recieves a response from some verification methods. At this point, SSPR seems to search every LDAP profile and LDAP context configured under  Settings > LDAP -> LDAP directories for a match and that is what triggers the issue I have reported to engineering.

Items 6 and 7 are really subtle and easy to miss, sometimes it can help to inspect the underlying SSPR XML settings file to clarify if the correct LDAP profile is tied to each configuration item.

Suggest you search this XML for "ldapProfileID" and investigate any values that that don't match the following:

"ldapProfileID":"default"

Alex

Hi,

after delving into this a bit more, I think it might be scenario 2 that you encountered.

mentioned your case to the support engineer I am working with.They also agreed that a support case (SSPR, not IDM) is the way to go here 

Alex

Hi Alex,

Thank You! initially my seach filter is (&(objectClass=person)(cn=*))

where it will hit the duplicate user error, even i tried to use the filter in directory studio got return with non-duplicate result. After i see your sample, where i change cn=* to cn=%USERNAME% , then it solve the issue and im able to use 2fa to reset the password now.

Hi Alex,

Another side question if you could help, ive tried to set the password expired in edir, but in sspr im able to prompt reset password, in user application it still enable me to login after i have check password expiry enabled.