08-16-2016 2:37 PM
Hi everyone,
I've faced with strange bug when I created user in the a system from CUA.
The password in the child system was set as deactivated though I set it in CUA.
Here is the logs of my actions:
CUA system log
Child system log
Unfortunately, I couldn't repeat the problem it occurred just once today. However, I suspect that it happens time after time, we just cannot see it because create users through GRC.
I also couldn't find any note describing this problem. Could someone tell me if he faced with the same issue?
SCUL green, SM21 has no problem regarding the user, IDoc contained password infromation:
in the child system
So I don't know what could case so strange behaviour. If this is a bug, it could be the sicurity issue in SAPBASIS component. Do you agree?
Our SP level of CUA system attached
Regards,
Artem
08-16-2016 4:51 PM
This would happen when CUA distributes the user with a password to the local system. Locally, the system parameter login/password_change_for_SSO is activated that the user can or automatically has their expired or initial password deleted when logging on via a SSO solution.
Eg. trusted RFC from SOLMAN or logon to Portal with SSO2 ticket to backend.
Cheers,
Julius
08-16-2016 4:51 PM
This would happen when CUA distributes the user with a password to the local system. Locally, the system parameter login/password_change_for_SSO is activated that the user can or automatically has their expired or initial password deleted when logging on via a SSO solution.
Eg. trusted RFC from SOLMAN or logon to Portal with SSO2 ticket to backend.
Cheers,
Julius
08-17-2016 7:29 AM
Hello Julius,
Thank you for the suggestion. I've checked the parameter and it's set to 1 (not to 3 for password deactivation). And by the way, when I tried to replicate the problem I didn't face with the issue again. Seems that it will be a detective story for a long time . I will keep an eye on the issue and let know here how it goes.
Regards,
Artem
08-17-2016 7:56 AM
Hi
Did you check what value 1 do?
From logs is clear that password deactivation was done 2 hours after change from CUA.
If you care about privacy by clearing screens, you should clear BCODE value too.
It's your password in downwards compatibility format.
Regards
Przemek
08-17-2016 8:19 AM
Hi Przemek,
Yes, I checked. In our the value determines whether we get dialog box for changing (init/expired password) or deactivating appears. But the password was delivered deactivated. When I got the first claim from the colleague (after 2hours) I set it manually directly in the system.
Thanks for you notice regarding the BCODE, unfortunately, I cannot change the picture any more.
Regards,
Artem
08-17-2016 8:35 AM
08-17-2016 9:36 AM
08-17-2016 9:51 AM
CUA is too old.
Child expect IDOC with field PWDSALTEDHASH, but CUA don't know how to create it.
Check:
1300104 - CUA|new password hash procedures: Background information
08-17-2016 11:56 AM
Hmm.. the plot thickens 🙂
But it only happened on isolated cases. If is was the password compatibility then it should happen always (I would think).
In the screenshot I see CodeVersion G (old and new hashes) and there is a delay of 2 hours before the deactivation -> user got his initial password and then deactivated it (either himself or by not using it). I still place my bets on that.
Cheers,
Julius
08-17-2016 12:09 PM
enlarge screenshots
I did the same mistake with 2 hours gap
the password had been deactivated immediately then admin used su01 in child
08-17-2016 12:30 PM
Ok, now I see that as well. Got it (and lots a bet against myself 🙂
Another possibility which would also explain the inconsistent behavior is that the child system has a login/password* policy which is stricter than that of the master system and the password wizard generator maximum settings -> so sometimes the password sent from the CUA master is compliant with the child policy (password is set) and sometimes it is not (no password = code version is deactivated).
@ Artem: compare the system parameters of the master and child and try to set an as weak as permitted password in the master system for a test user and send it to the child. Does the behavior repeat itself?
Cheers,
Julius
08-17-2016 2:37 PM
Hi Julius,
Thank you for the reply!
Saying truly, I also thought in the same direction, so that, I created new user with the same password that was generated to the 'problem' user. I knew it because I sent it to the colleague. And as I wrote before the new user was created without any problem. However, I checked parameters you recommended and found that password policy in CUA is stricter that in the child.
I've attached xls with the parameters.
I could have set the same password policy in the child system, but it will be hard to ensure that it helped since the problem is hard-to-catch
Regards,
Artem
08-17-2016 1:20 PM
the cvers zip files provide only scrap for me.
no notes found???
whats about: 1022812 , 1797737, etc.?
b.rgds, bernhard
08-17-2016 4:02 PM
Hi Bernhard,
I meant that I couldn't find note related to my SP level. You also provided notes that are not related to my SP level, as you said because of scrap. Seems SCN packs files in ZIP, so you need to unzip, then delete extension .txt (I attached html and xls because these formats are more convenient for reading).
However, note 1778007 seems applicable to my child system. But it does not describe exact my problem, unfortunately, other notes I could not find again.
This note 1022812 describes the situation enough close to my issue. But I have higher SP level.
Regards,
Artem