The scenario is this: A temporary SUS
user that was previously created through the self-registration process logs in
and creates his permanent SUS user ID. At that point, the SUS user is created
and it is synchronized to SRM, with an identical initial password. When the SUS user logs in for the first time,
he is prompted to change his password.
This is fine, and operates as expected. However, once this same user
attempts RFx functionality (or any other function that makes a call to the SRM
backend) the user is prompted again to change his password. The confusion caused here is the password
that needs to be changed is the original initial password from the SUS user
creation, not the current SUS user password. From the user standpoint, they do
not know this because it is not intuitive that they are passing from one system
to another.
SAP has come out and said in note
1802240 that the password is not synchronized by design. I will not venture to guess as to the
reasoning behind this, however in researching ways to fix this from a
functional standpoint for my customer I came across a very simple solution.
I was looking at our options, and came
up with these:
1.
We could change the creation logic
with a Z program to force the password to be deactivated in the SRM system when
the user is created.
2.
We could change the synchronization
function modules with a Z program that includes the logic to force the password
change to be included with other user details when the synchronization occurs.
3.
We could just do nothing and provide
detailed instructions for the customers on how to work with this design defect.
Each of these potential solutions also
brought with them their own drawbacks, especially option 3, but each are valid
solutions. However, I ran across am
option 4 that never occurred to me before.
I came across the following profile parameter
login/password_change_for_SSO
This profile parameter determines
precisely how the system will react in the situation in which a user accesses
the system through SSO and their password is expired (or initial). Here are the values:
0 = Ignore password change request, and allow access
1 = Present a pop-up window with options 2 and 3 below
2 = Require the password be changed, including old password and new
password
3 = Deactivate the password
So, the solution that was best for
this customer was to choose option 0, which will allow the user access through
SSO and not prompt for the password to be changed. The customer loved the solution, and I will
certainly add it to my bag of tricks.
Hope this helps…
