04-24-2014 5:56 AM
Hello,
User's (Dialog) password is getting deactivated in the very next second, after resetting , which does not allow the user to Login through GUI via the initial password.
If we are changing the user type from dialog to service (Productive Password) there is no issue, use able to login.
I have checked the RFCDES table, user is not maintained in any RFC Destination, but some jobs (EU_REORG and
EU_PUT) has been scheduled from users ID which runs everyday.
Can anyone please help, why password is getting deactivated.
Regards,
Biswaranjan
04-24-2014 6:04 AM
Hi Biswaranjan,
It could be of many reasons
Do you have some SSO or LDAP stuff configured ?
You can take help of some abaper and debug it probably.
Is your minimum password lenght and other stuff maintian correctly for user.
Can you create other user and check .. is it the same issue for other user.
Hope it helps.
Regards,
Deepanshu Sharma
04-24-2014 6:04 AM
Hi Biswaranjan,
It could be of many reasons
Do you have some SSO or LDAP stuff configured ?
You can take help of some abaper and debug it probably.
Is your minimum password lenght and other stuff maintian correctly for user.
Can you create other user and check .. is it the same issue for other user.
Hope it helps.
Regards,
Deepanshu Sharma
04-24-2014 7:42 AM
Thanks for the timely reply.
I will check for the SSO and LDAP , if this is configured or not.
Yes, password length is maintained correctly and the issue is with one specific user, for other users no issue.
I have deleted the user and recreated, but the issue still persist.
The moment, i am resetting the password of the user, its getting deactivated, before users can LOGIN.
In Change document it is showing password inactive by users own id at kernel level.
Regards,
Biswaranjan Sahoo
04-24-2014 7:51 AM
Hi Sahoo,
Which kernel what version of SAP do you have ?
Regards,
Deepanshu Sharma
04-24-2014 7:58 AM
Hi Sahoo,
Please check out the below SAP note. This might help you.
495911 - Trace analysis for logon problems
Regards,
Madhu.
04-24-2014 7:59 AM
Hi Deepanshu,
Its a validation system. Version is R/3 release 4.6C. OS is Linux.
Regards,
Biswaranjan
04-24-2014 8:14 AM
Thanks Madhu for the note.
But issue is before user trying to LOGIN, password getting deactivated.
Once i reset, and display the same user immediately its showing password deactivated.
In Change document it is showing password inactive by users own id at kernel level.
I also put SM19 trace, but no report.
Regards,
Biswaranjan
04-24-2014 8:22 AM
What is a "validation system"?
Is it possible that it is unlicenced and the system clock has been fiddled with? (set into the future during installation or "bought" as an image).
"Evaluation systems" in 2014 would be 7.41 not 4.6C...
Cheers,
Julius
04-24-2014 9:21 AM
it also simply might be some rfc calling into the system at a high frequency.
04-24-2014 9:30 AM
That would set UFLAG = 128 but not CODVN = X. The login/password_change_for_SSO also did not exist back then to declaratively deactivate the password even if the RFC call was not password based and this evaluation system comes with a portal for logon tickets or solman for trusted monitoring of it.
I wager a bet that something has been fiddled with and we are never going to find out what it was.
But hopefully I am wrong...
Cheers,
Julius
04-24-2014 10:37 AM
Hi Julius,
hmm, can't find the info on the contents of UFLAG and CODVN stated in this thread before. Do you have some secret access to the system 😉
@Sahoo, maybe you can check the values of UFLAG and CODVN in table USR02 and enable the SAL and check for entries for this user. This could give us a hint.
Regards,
Patrick
04-24-2014 11:00 AM
Hello Patrick,
I found the below values for the user in USR02, but sorry, didn't get you to enable the SAL.
Can you please let me know how to enable SAL for the user.
UFLAG = 0
CODVN = X
Regards,
Biswaranjan.
04-24-2014 11:09 AM
Hi Patrick and Julius,
I have checked the parameter login/password_change_for_SSO, Its value sets as 3 (Deactivation of password (automatic, no popup)). But the issue is for only one user, not for all the users in the system.
Regards,
Biswaranjan
04-24-2014 11:21 AM
That param was there already in 46C? Didn't know that...
What you have described would only be possible if the user is actually logging on without a password (SSO) immediately after you reset the password.
In theory (only) this could be in an exit in SU01 which on SAVE dynamically inserts the user into an RFC connection and then calls it using trusted RFC to logon with the initial password status which then deactivates itself. Also in theory, it could be a DB trigger on the field and nothing to do with the application actually.
In practice, it is much more likely that someone has fiddled with the system. Can you confirm that the license is valid and that the system clocks have not been doctored?
Cheers,
Julius
ps @ Patrick: I have been hanging around internet forums for long enough to have become clairvoyant about these things... 🙂
04-24-2014 11:41 AM
Hi Julius and Patrick,
I believe its due to CODVN = X. I have deleted the user completely and again recreate it. But the same issue and CODVN = X. I created a COPY of user and found that CODVN = B and no issue.
So i believe some where the user ID is maintained so that the CODVN values remains X., but i have checked the RFCDES, user is not maintained there.
Can you please check and suggest.
Regards,
Biswaranjan
04-24-2014 12:04 PM
Hi Sahoo,
you can try to check the ABAP Code with report RS_ABAP_SOURCE_SCAN and serach for the user ID. Maybe some program deactivate the userid.
Regards,
Bernhard
04-24-2014 12:17 PM
Yes, it must be hardcoded somewhere. What is strange however is that the user is deactivating their own password when the admin saves the new one in SU01.
In addition to an RFC connection, the possibility of a SICF service called by SU01 running under that user is also a possibility? But that call must be hardcoded in SU01 somewhere for this to be happening.
Cheers,
Julius
04-24-2014 12:30 PM
You could try applying an SQL trace to USR02, resetting the password again, and then see what programs are making updates to the tables. Might help, might not. Just an idea.
04-24-2014 1:03 PM
Hello Patrick,
I have checked the SQL trace, only got to know that its updating once again the value of CODVN = X.
SQL Statement
UPDATE
"USR02"
SET
"BCODE" = :A0 , "GLTGV" = :A1 , "GLTGB" = :A2 , "USTYP" = :A3 , "CLASS" =
:A4 , "LOCNT" = :A5 , "UFLAG" = :A6 , "ACCNT" = :A7 , "ANAME" = :A8 ,
"ERDAT" = :A9 , "TRDAT" = :A10 , "LTIME" = :A11 , "OCOD1" = :A12 , "BCDA1" =
:A13 , "CODV1" = :A14 , "OCOD2" = :A15 , "BCDA2" = :A16 , "CODV2" = :A17 ,
"OCOD3" = :A18 , "BCDA3" = :A19 , "CODV3" = :A20 , "OCOD4" = :A21 , "BCDA4" =
:A22 , "CODV4" = :A23 , "OCOD5" = :A24 , "BCDA5" = :A25 , "CODV5" = :A26 ,
"VERSN" = :A27 , "CODVN" = :A28 , "TZONE" = :A29 , "ZBVMASTER" = :A30
WHERE
"MANDT" = :A31 AND "BNAME" = :A32
Variables:
A0(RA,18) = 0x0000000000000000
A1(NU,8) = 2014****
A2(NU,8) = 999*****
A3(CH,1) = A
A4(CH,12) = FIL_**
A5(I1,1) = 0
A6(I1,1) = 0
A7(CH,12) =
A8(CH,12) = 310*****
A9(NU,8) = 2014****
A10(NU,8) = 2014***
A11(NU,6) = 13373*
A12(RA,18) = 0x0000000000000000
A13(NU,8) = 2014***
A14(CH,1) =
A15(RA,18) = 0x0000000000000000
A16(NU,8) = 00000000
A17(CH,1) =
A18(RA,18) = 0x0000000000000000
A19(NU,8) = 00000000
A20(CH,1) =
A21(RA,18) = 0x0000000000000000
A22(NU,8) = 00000000
A23(CH,1) =
A24(RA,18) = 0x0000000000000000
A25(NU,8) = 00000000
A26(CH,1) =
A27(CH,3) =
A28(CH,1) = X
A29(CH,6) =
A30(CH,1) =
A31(CH,3) = 402
A32(CH,12) = NLY*****
I have checked it once again, there are some users whose CODVN = X in USR02 table. All user's password has been deactivated and seems they are not able to login.
And its happening from some particular time period.
Please check and suggest.
Regards,
Biswaranjan
04-24-2014 1:32 PM
One can see from the timestamp that this is happening when the user logs on and not when saving in SU01 as admin otherwise LTIME would be 0x00000, unless saving as admin automatically logs the user on who was saved... which is illogical.
Or are you sure this is happening when you save in SU01? If yes, then please post the contents of table SSM_CUST here to check what custom function is active there.
If you can clarify where you downloaded this system from or where you got the image from (?) then that will also clarify several doubts about the strange behaviour...
Cheers,
Julius
04-24-2014 2:27 PM
Hi Julius,
Yes, its happening immediately after ADMIN saves the user in SU01. There is no chance for the user to LOGIN as before that only password got deactivated.
Find the table SSM_CUST content.
Name | Attributes |
DUP_REPORT_OFF | YES |
HIDE_START_IMAGE | YES |
PFCG_CONSIST_CHECK | NO |
RESIZE_IMAGE | YES |
START_IMAGE | Z_FILONE_GO_LIVE |
Regards,
Biswaranjan
04-24-2014 2:41 PM
Then there are no exits active.
That leaves only modification of SU01 left over (check tcode spau). Or your license has a problem - again, did you get this "validation system" as an image?
Cheers,
Julius
04-24-2014 10:45 PM
I am now 100% certain that there is some modification there for dialog type users which is attempting to set productive password status which was set by the admin.
The kernel used to tollerate that the first password change could be the same as the one set by the admin in 46C, but not subsequent passwords (4 of them).
This inability to set the password to something which the user(s) want is then deactivating the password due to license conflicts.
As a workaround you can choose a completely new password (back then the user ID was an attribute of the password hash - hence your copy worked...) but I guess that does not solve your problem that users are changing the password and your modification is trying to reset it.
I can help you solve this problem from a technical perspective, but you must be aware that you are asking this question on SAP's own website expecting support for something which is a breach of the license.
I will eat my hat if I am wrong...
Cheers,
Julius
04-28-2014 12:29 PM
Hello Bernhard,
Thanks for the reply. i have checked above program doesn't exist in the system.
Regards,
Biswaranjan
04-26-2014 10:36 PM
I discussed this with some SAP internal gurus and you should open a customer message.
Cheers,
Julius
04-28-2014 12:14 PM
Hi Julius,
I have raised a message to SAP, Let see what SAP replies.
Thanks so far for the findings.
Regards,
Biswaranjan
05-14-2014 6:00 PM
Hello Julius,
We didn't get any help via raising the OSS message, however we got the root cause and resolve the same . Now there is no issue. We are able to reset the password of the user.
Issue :
We found some RFC session and gateway session were active via that users ID.
In SM04 as well as SMGW , 2/3 RFC session were continuously running, which forced the user password to deactvate.
We kill all the session in SM04 via SM04 and the issue resolved.
Thanks all for your help.
Regards,
Biswaranjan.
05-14-2014 6:02 PM
Hello,
We got the issue and resolve as well.
Issue :
We found some RFC session and gateway session were active via that users ID.
In SM04 as well as SMGW , 2/3 RFC session were continuously running, which forced the user password to deactivate.
We kill all the session in SM04 via SM04 and the issue resolved.
Thanks everyone for your help.
Regards,
Biswaranjan.
05-14-2014 6:23 PM
You must still find the RFC client which triggered the connection to be opened using password authentication though and check the user type of the user, otherwise the lights might go out soon again... 🙂
Cheers,
Julius
05-14-2014 6:40 PM
I believe, the RFC connection established or the RFC session created due to the background job scheduled and was running via the same user id. Now the background job also deactivated.
let me know if you have any other thought or if my above statement is not correct. Also can you please let us know , how we can find out on your above statement.
Regards,
Biswaranjan
05-14-2014 6:48 PM
Highly unlikely..
Post the code of the program in the background job to take a look at what that does...
Cheers,
Julius
07-08-2015 12:41 PM
Hello
We had similar problem that the password was deactivated for dialog user in SU01 sometimes.
After reading this topic and some testing I found that the password is deactivated when it is reset to initial password in SAP and user before change to productive password logs in to the Portal system first (which is connected to this SAP system) and open some transactional iView there. Then the password deactivates in SAP.
So the solution in our case was that the user after password reset should change it in SAP first and then he can work in Portal.
Maybe this will be helpful for somebody.
Michal