Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Strange behaviour of delivering password

former_member182655
Contributor
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

13 REPLIES 13

Former Member
0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

what is your child basis version?

0 Kudos

Please find the file enclosed

Regards,

Artem

0 Kudos

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

0 Kudos

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

0 Kudos

enlarge screenshots

I did the same mistake with 2 hours gap

the password had been deactivated immediately then admin used su01 in child

0 Kudos

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

0 Kudos

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

Bernhard_SAP
Employee
Employee
0 Kudos

the cvers zip files provide only scrap for me.

no notes found???

whats about: 1022812 , 1797737, etc.?

b.rgds, bernhard

0 Kudos

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