EHP5 upgrade completed successfully, but can't login with user password!!

[nicholas_chang]

Hi All,

Sorry as this is a duplicate post when i've posted one in Upgrade space ealier, and hopefully i can get more advice on security space.

Is anyone encounter any weird issue after ugprade completed sucessfully, I can't login via sapgui with all user and their password. All the users tried with their correct username and password, but return with "name or password is incorrect (repeat logon)"

This is very weird. I can only login via sap* and password pass. Once i reset password of few users, and they manage to login again. I don't want to reset ALL user and would want to solve this.

FYI, there's no licensing issue. Appreciate if someone can shed some light on this as this is our production upgrade. We dont hit this is sandbox upgrade.

This is weird, i believe is something to do with the password backward compatible bugs/thingy. The value is set to 1 which is should allow password more than 8 characters to access.

and i found out, for eg: user "sapadmin" with password "abcd123456" failed to login to the system but able to login with 'sapadmin' password "abcd1234' which is 8 character..

I've created a message to SAP but resolution given are not helpful.

many thanks,

Nicholas chang

[Former Member]

Sounds like your system had the default compatibility of both old and new hashes but only checked the new one (login/password_downwards_compatibility = 1.

Then restarting the system pulled a default profile in which is now only respecting the old hash (login/password_downwards_compatibility = 5) or some idiot changed it dynamically in RZ11 to the value 5.

You can change it temporarily to '3' and also do this dynamically (see docs in Rz11). That will make the problem go away. Then make sure that the default profile is set correctly again.

Tip: via transaction TU02 you can find the change document (history of file button) of who toasted the profile parameter...

Cheers,

Julius

[nicholas_chang]

Hi Julius,

Thanks for your prompt reply. FYI, i've tried with login/password_downwards_compatibility =1, 2, 3, 4, 5 in RZ11..... but all returned negative result.

How to ensure and check which hash are the system checking now?

Thanks,

Nicholas Chang

[Former Member]

During the time of login/password_downwards_compatibility = 5, the users who's passwords were reset will only have a downward compatible password. Setting the value back to create both hashes will require a password reset for them.

Yes, you will have to work out who they are.

USR02-BCODE with a value NE 0000000000000000 will indicate that the old 8 character upper-case password is available still if the user knows it.

USR02-PASSCODE with a value EQ 00000000000000000000000000000000 will indicate that they dont have a new 40 character case-sensitive password. You will have to reset these.

But you should please post your login* params to see what is going on there and also what the change docs say (assuming that the params were changed from RZ11 / RZ10 and therefore populated the PAHI table for the history of file. If someone fiddled at the OS layer in the files then there are no change docs at the application layer. Other parameters also influence the "code versions" of the hashing into the 2 fields (see USR02-CODVN for those with problematic passwords).

If you give us a bit more infos, we might be able to help you before Monday morning...  🙂

Cheers,

Julius

[nicholas_chang]

Hi Julius,

Again, thanks for your reply and is very helpful for me to understand.

This is all the *login* parameter. FYI, those parameters are identical with my sandbox (copied from prod) which i didnt encounter this problem.

geasing my elbow to find out why login/password_downwards_compatibility =1 didn't evaluate password more than 8 length character after upgrade without reseting the password.

login/accept_sso2_ticket	1	0
login/certificate_mapping_rulebased		0
login/certificate_request_ca_url		https://tcs.mySAP.com/invoke/tc/usercert
login/certificate_request_subject		CN=&UNAME, OU=&WPOU, O=mySAP.com User, C=DE
login/create_sso2_ticket	2	0
login/disable_cpic		0
login/disable_multi_gui_login	1	0
login/disable_password_logon		0
login/failed_user_auto_unlock	1	0
login/fails_to_session_end		3
login/fails_to_user_lock		5
login/isolate_rfc_system_calls		0
login/min_password_diff		1
login/min_password_digits		0
login/min_password_letters		0
login/min_password_lng		6
login/min_password_lowercase		0
login/min_password_specials		0
login/min_password_uppercase		0
login/multi_login_users
login/no_automatic_user_sapstar	0	1
login/password_change_for_SSO		1
login/password_change_waittime		1
login/password_charset		1
login/password_compliance_to_current_policy		0
login/password_downwards_compatibility		1
login/password_expiration_time	90	0
login/password_hash_algorithm		encoding=RFC2307, algorithm=iSSHA-1, iterations=1024, saltsi
login/password_history_size		5
login/password_logon_usergroup
login/password_max_idle_initial		0
login/password_max_idle_productive		0
login/system_client	800	800
login/ticket_expiration_time		8:00
login/ticket_only_by_https		0
login/ticket_only_to_host		0
login/ticketcache_entries_max		1000
login/ticketcache_off		0
login/update_logon_timestamp		m

Your kind advice is very much appreciated.

Thanks,

Nicholas Chang

[nicholas_chang]

Seem like after upgrade, all the users are having the new downward-incompatible password

USR02-PASSCODE with a value EQ 00000000000000000000000000000000

The value for USR02-PASSCODE is only change to random after it was reset.

ANy idea what cause this? I reckon after upgrade, SAP should support downward compatible and incompatible with the parameter value = 1?

[Former Member]

Params look fine, so if there are no change documents in Tu02 and a subsequent reset while the param was set to '5', then there is for me only one logical explanation available still for the PASSCODE being initialized again:

Go to SE11 and display table USR02. Then click on the where-used-list button and take a look at the custom programs which are accessing the table. Somewhere there of possibly directly at the DB level someone tried to lock and then again unlock the users by setting USR02-UFLAG with a direct update to the table, but they hit the wrong field or other single fields with dependencies for the PASSCODE (also check what the value is on CODVN please!!).

This would also explain why SAP support gave you an "unsatisfactory" answer that you need consulting support and not product support...?

What you are going to have to do is eliminate that program and use an API respecting tool for such changes in future (this happens often enough that I offer a free tool for this on our website). Then you will also need a program which is going to correct the corrupted data. Best way will be to reset the password and mail it to the users smtp address - and do that on-mass. I generally advise customers to have something like this ready for eventualities such as yours or when SSO fails for some reason and you need to reactivate deactivated passwords.

Let us know whether that diagnosis helps.

Cheers,

Julius

[Former Member]

I seem to have hit a nerve...

How was your Monday?  🙂

Did you fix the root cause of the problem? Did you reset the passwords? Or implement SSO in 24 hours?

Just curious... Let us know if you need more help.

Cheers,

Julius

[nicholas_chang]

Hi Julius,

Sadly, gease my elbow but to no avail, couldn't find any root cause. Check where-used list for table USR02, but no customize program accessing this table.

We stick the last option, is to reset any user with password more than 8 characters.... The only suspect for the root cause probably due to CUA was configured but was cleared, incompletely.

Thanks for your precious advice!

Appreciate.

Thanks,

Nicholas Chang

[Former Member]

Hi Nicholas,

Check in BD87 and SCUL whether generally there are old idocs not processed?

Someone performing the upgrade might have pushed ancient idocs through or (worse...) they detatched the system in the CUA master during the upgrade and then ran SCUG again to transfer them with their proposed passwords.

Please check in SCUM what the setting is for passwords? (to avoid the same in future).

Cheers,

Julius