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: 

Password Deactivated for a Dialog user

former_member218393
Participant
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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    

31 REPLIES 31

Former Member
0 Kudos

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    

0 Kudos

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

0 Kudos

Hi Sahoo,

Which kernel what version of SAP do you have ?

Regards,

Deepanshu Sharma    

0 Kudos

Hi Sahoo,

Please check out the below SAP note. This might help you.

495911 - Trace analysis for logon problems

Regards,

Madhu.

0 Kudos

Hi Deepanshu,

Its a validation system. Version is  R/3 release 4.6C. OS is Linux.

Regards,

Biswaranjan

0 Kudos

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

0 Kudos

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

0 Kudos

it also simply might be some rfc calling into the system at a high frequency.

0 Kudos

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

0 Kudos

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

0 Kudos

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.

0 Kudos

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

0 Kudos

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...  🙂

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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.

0 Kudos

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

0 Kudos

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

0 Kudos

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.

NameAttributes
DUP_REPORT_OFFYES
HIDE_START_IMAGEYES
PFCG_CONSIST_CHECKNO
RESIZE_IMAGEYES
START_IMAGE

Z_FILONE_GO_LIVE

Regards,

Biswaranjan

0 Kudos

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

0 Kudos

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

0 Kudos

Hello Bernhard,

Thanks for the reply. i have checked above program doesn't exist in the system.

Regards,

Biswaranjan

Former Member
0 Kudos

I discussed this with some SAP internal gurus and you should open a customer message.

Cheers,

Julius

0 Kudos

Hi Julius,

I have raised a message to SAP, Let see what SAP replies.

Thanks so far for the findings.

Regards,

Biswaranjan

0 Kudos

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.

former_member218393
Participant
0 Kudos

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.

0 Kudos

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

0 Kudos

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

0 Kudos

Highly unlikely..

Post the code of the program in the background job to take a look at what that does...

Cheers,

Julius

0 Kudos

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