Password reset when adding Business Role

[Former Member]

In IDM, a user A has auth to SAP System S with role R, and only this one.

When I add the user A an IDM Privilege containing R in S, IDM reassign the auth in SAP but remove the password ?!

They are no password set in IDM, the user still has the one set in SAP before.

So when I add the Privilege then I have to reset the password in IDM and the user has to change it.

I’ve set the Identity Store : “Enable Password provisioning”

Business Role settings :

Always reconcile: YES

Reconcile is Pending : YES

Allowed Entries Reserved : NO

How can I avoid this issue ?

Thx for your help,

Nicolas.

[former_member2987]

Nicolas,

I'd recommend setting up a test case with TRACE and extended audit (I can't remember the exact term but you can turn if on from the MMC) turned on, this way you can see what tasks executed.  This will give you an idea where the issue is occurring and what is triggering it.

Matt

[keith_zhang]

Hello Nicolas,

What is the SP version of your IDM and imported provisioning framework?

There is indeed one known issue for SP4, that is the modify action will deactive the ABAP user password, and there is no password actually stored in IDM DB. I just found the note number is 1738834. Please you can have a look.

Hope it helps.

BR, Keith

[Former Member]

Hi Keith,

Thanks for your reply.

I have the Prov Framework from SP8, so I hope on that part it should be ok.

Nicolas.

[keith_zhang]

Hi Nicolas,

Then, in SAP provisioning framework, the password value provisioning is based on attribute MX_ENCRYPTED_PASSWORD, and if the password is disabled or not depends on attribute MX_PASSWORD_DISABLED. Please you can check one MX_PERSON entry's attributes with sql like:

select * from idmv_value_basic_all where mskey=<user's mskey>

So if MX_PASSWORD_DISABLED is set for the user, the password will be disabled.

BR, Keith

[Former Member]

Is the password diabled or removed?  If disabled, do you have MX_PASSWORD_DISABLED set on the user in question?  If its set to ... pretty much anything really ... it disables the password in SAP.

Peter

[Former Member]

Hi Peter,

In IDM none of the flags (user disabled, password disabled,...) are set.

In SAP the password is set to Deactivated.

I'm sorry, I don't understand that sentence :"If disabled, do you have MX_PASSWORD_DISABLED set on the user in question?"

Nicolas.

[terovirta]

Nicolas Varga wrote:
I'm sorry, I don't understand that sentence :"If disabled, do you have MX_PASSWORD_DISABLED set on the user in question?"

Do you users login with password or via SSO? If via SSO then MX_PASSWORD_DISABLED should be 1.

[former_member190695]

Hi Nicolas,

First of all, you should have a password set for users in IdM.

Second, "Enable Password Provisioning" option is used in combination with the Guided Password Reset Task in case a user forgot it's password for e.g. AD. The task should normally be accessible to anonymous users.

SAP IdM by default will only set a password when creating a user (dot operator in front of password).

You need to write a simple script that in case of technical role (privilge in role R), you need to trigger the password reset task (MX_HOOK8_TASK) in the Role Assignment provisioning workflow.

I hope I understood your question!.

An advanced scenario is available in the SAP IdM RDS which is available for download.

Happy coding!.

Regards,

Ridouan

[Former Member]

Hello Ridouan,

Thanks for your reply.

Users have been imported from SAP and I don't want to oblige them to change their password, so they are still working with the password the set in SAP before.

I just would like to avoid password de-activation when I add the business role, maybe it's not trigerred, but I think well.

Self-service for reset password works, I don't think it's related to de-activation.

Nicolas.

[terovirta]

You can still generate the password for the users when loading them but as long as the password is not changed in IdM the change is not replicated to target systems.

Do you have your system privilege modify task trigger attributes correctly set? Provisioning shouldn't trigger the repository's modify workflow (which then executes the change password plugin) to be run.

The early 7.2s in ramp-up had an issue where every time repository's modify task was ran the passwords were reset. But that was fixed two years ago. The procedure that detects the password change is simple enough to read, maybe worth your while to check that. It would tell you whether the password actually is mandatory information.