Mass user password change

[Former Member]

Dear All,

I checked on net regarding setting initial password or reseting for mass users but didn't see a solution. When using CATT script, it does not allow us to map password field either

Has anyone found a solution to this.

regards, Sean.

[jurjen_heeck]

> When using CATT script, it does not allow us to map password field either

Are you using CATT or ECATT?

[RainerKunert]

There is no solution in the SAP standard.

You have to develop your own program. You may use the user management APIs (BAPIs for user administration).

[morten_nielsen]

>

> You have to develop your own program. You may use the user management APIs (BAPIs for user administration).

Hi

I aggree with Rainer on this. The best way to do this is through an ABAP developped for this purpose using the delivered BAPI's, I have used the one posted below on several occasions. The sourcecode could be more elegant, but it will do the trick.

But as always, test first and use at own risk !

Regards

Morten Nielsen

*&---------------------------------------------------------------------*
*& Report  Z_MASS_CHANGE_PASSWORD
*&
*&---------------------------------------------------------------------*
*& Mass Change of Password
*&
*&---------------------------------------------------------------------*

REPORT  z_mass_change_password.

TABLES: usr02.

DATA: lt_usr_list  TYPE TABLE OF bapiusname,
      wa_usr_list  TYPE bapiusname,
      l_user       TYPE bapibname-bapibname,
      wa_logondata TYPE bapilogond,
      lt_return    TYPE TABLE OF bapiret2,
      wa_return    TYPE bapiret2.

CONSTANTS: c_pwdx TYPE bapipwdx VALUE 'X'.


DATA: lt_usr_range TYPE TABLE OF bapiussrge,
      wa_usr_range TYPE bapiussrge.

SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME
                                   TITLE text-001. "Users and New password
SELECT-OPTIONS:  s_user FOR usr02-bname,
                 s_class FOR usr02-class.
PARAMETERS:      p_pwd TYPE bapipwd LOWER CASE OBLIGATORY.
SELECTION-SCREEN BEGIN OF BLOCK b11 WITH FRAME
                                    TITLE text-002. "User types
PARAMETERS: p_dia AS CHECKBOX DEFAULT 'X',
            p_sys AS CHECKBOX,
            p_com AS CHECKBOX,
            p_ser AS CHECKBOX,
            p_ref AS CHECKBOX.
SELECTION-SCREEN END OF BLOCK b11.
SELECTION-SCREEN END OF BLOCK b1.

START-OF-SELECTION.

  BREAK-POINT.

*--- Create Selection range for BAPI_USER_GETLIST
  REFRESH lt_usr_range.
  LOOP AT s_user.
    CLEAR wa_usr_range.
    wa_usr_range-parameter = 'USERNAME'.
* wa_usr_range-FIELD =
    wa_usr_range-sign      = s_user-sign.
    wa_usr_range-option    = s_user-option.
    wa_usr_range-low       = s_user-low.
    wa_usr_range-high      = s_user-high.
    APPEND wa_usr_range TO lt_usr_range.
  ENDLOOP.

  CALL FUNCTION 'BAPI_USER_GETLIST'
    TABLES
      selection_range = lt_usr_range
      userlist        = lt_usr_list.

  LOOP AT lt_usr_list INTO wa_usr_list.

    l_user = wa_usr_list-username.
    CLEAR wa_logondata.

    CALL FUNCTION 'BAPI_USER_GET_DETAIL'
      EXPORTING
        username  = l_user
      IMPORTING
        logondata = wa_logondata
      TABLES
        return    = lt_return.

*--- Dialog Users
    IF p_dia EQ 'X' AND wa_logondata-ustyp EQ 'A'
                    AND wa_logondata-class IN s_class.
      PERFORM set_password USING l_user p_pwd.
    ENDIF.

*--- System Users
    IF p_sys EQ 'X' AND wa_logondata-ustyp EQ 'B'
                AND wa_logondata-class IN s_class.
      PERFORM set_password USING l_user p_pwd.
    ENDIF.

*--- Communication Users
    IF p_com EQ 'X' AND wa_logondata-ustyp EQ 'C'
                AND wa_logondata-class IN s_class.
      PERFORM set_password USING l_user p_pwd.
    ENDIF.

*--- Reference Users
    IF p_ref EQ 'X' AND wa_logondata-ustyp EQ 'L'
                AND wa_logondata-class IN s_class.
      PERFORM set_password USING l_user p_pwd.
    ENDIF.

*--- Service Users
    IF p_ser EQ 'X' AND wa_logondata-ustyp EQ 'S'
                AND wa_logondata-class IN s_class.
      PERFORM set_password USING l_user p_pwd.
    ENDIF.

    CLEAR wa_usr_list.
  ENDLOOP.


*&---------------------------------------------------------------------*
*&      Form  SET_PASSWORD
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_L_USER  text
*      -->P_P_PWD  text
*----------------------------------------------------------------------*
FORM set_password  USING    p_l_user
                            p_p_pwd.
*--- Change the Password
  REFRESH lt_return.
  CALL FUNCTION 'BAPI_USER_CHANGE'
    EXPORTING
      username  = p_l_user
      password  = p_p_pwd
      passwordx = c_pwdx
    TABLES
      return    = lt_return.

  COMMIT WORK AND WAIT.

*--- And write out the result
  LOOP AT lt_return INTO wa_return.
    WRITE: / wa_return-message.
    CLEAR wa_return.
  ENDLOOP.

ENDFORM.                    " SET_PASSWORD

[Former Member]

Thanks for sharing Morten!

From a first glance, a little comment that there is not much use in resetting the password of a reference user. You don't even have to give them an initial password in SU01 anymore.

Cheers,

Julius

[morten_nielsen]

Hi Julius

Yeah your absolutely right, it doesn't make much sense - I not quite sure anymore why it's there, the origin of the code goes way back, and the code could need a bit of a clean up - but it will do the trick

Regards

Morten

[Former Member]

I did it with SECATT.I didn't had any problem.

[Former Member]

> Yeah your absolutely right, it doesn't make much sense - I not quite sure anymore why it's there, the origin of the code goes way back, and the code could need a bit of a clean up ...

The COMMIT WORK AND WAIT is also interesting... unless your server is very slow...

Anmass resest of SYSTEM and SERVICE type user is also a bit questionable in my opinion. It contradicts the password requirement of the user types. In my opinion it is best to define downward compatable PASSCODES manually (8 char, 1 special, 1 digit, all UPPERCASE), and let it be with the correct server and client side security. The password is then (for those user types...) seldom relevant, so why reset it?

The bigger bugger is when the system fallout was only temporary, and you (in "emergency" mode) reset all passwords.... have fun on the helpdesk after than when you have many users...

There was an interesting discussion a while back about failover mechanisms for temporary authentication, without creating a mess for all other users who are on vacation.

Are you aware of it?

Cheers,

Julius

[morten_nielsen]

Hi

Thanks for your comment

> Anmass resest of SYSTEM and SERVICE type user is also a bit questionable in my opinion. It contradicts the password requirement of the user types. In my opinion it is best to define downward compatable PASSCODES manually (8 char, 1 special, 1 digit, all UPPERCASE), and let it be with the correct server and client side security. The password is then (for those user types...) seldom relevant, so why reset it?

Mass Reset of password for reference, communication and reference user isn't very relevant, I aggree.

Mass change of service users might be - I often use the service user type for test users on the QA system. And i'm often in a situation where I want to reset them to a password that I can communicate to the testers.

But if I were to rewrite the program today I think I would skip the selection parameters for user type, and maybe hardcode the dialog and service user types. I think i might put a warning and maybe an entry in the system log in there as well.

>The bigger bugger is when the system fallout was only temporary, and you (in "emergency" mode) reset all passwords.... have fun on the helpdesk after than when you have many users...

That's correct, with this report, as with a lot of other SAP Standard Mass Change Functionality, CATT Script, LSMW etc you can f... up your system totaly (Just think about the mess in your helpdesk situation if you accedentialy deletes all your users in SU12 ! ), this kind of functionality should always be used very carefully.

And the purpose of the report isn't and has never been the daily use in user administration. It's simply a piece of source code that can help in those very special system administration situations where you have to do a mass reset of the password, and it should always be used with care!

//Morten

[Former Member]

Completely agree with you.

A human mistake can always go "Bang". A computer program automated mistake goes "Bang, bang, bang, bang, bang, bang, bang, bang, bang....." ....

Another little side comment is that the same intial password (or a recognizable convention for them) communicated to all the testers can create a mess as well, if they want to be naughty.

So what one could also do to prevent this is call function SUSR_GENERATE_PASSWORD to make it cryptic for the mass reset, and then either mail it to them (if the address data is known) or else give them all a generic service user's password which when logging on calls the BAPI_USER_CHANGE again (either from the logon exit or the forced start transaction) to reset the password for the next available user ID, this time letting the person enter the password into the parameter themselves and then logon as their "own" user.

Cheers,

Julius

[jurjen_heeck]

Just tried with ECATT, no problemo. Which version are you on?

[Former Member]

Are you using CUA and trying to make the change in the central system?

[jurjen_heeck]

> Are you using CUA and trying to make the change in the central system?

I did and it worked fine. But my testuser only exists in one client, which was automatically selected. So still no problem on Netweaver 2004s.

[Former Member]

>

> > Are you using CUA and trying to make the change in the central system?
> I did and it worked fine.  But my testuser only exists in one client, which was automatically selected. So still no problem on Netweaver 2004s.

Sometimes I've seen CUA cause problems but usually due to the usual idoc overflow in the targets. I can't say I've ever had problems using CATTS (4.6/7) or eCATTS ECC5+ to reset passwords either

[Former Member]

We use SECATT without any problems. We are in ECC 6.0 with CUA.

[Former Member]

Dear All,

Thanks for your replies.

We used SECATT too. All fields were mapped except password. We are on ECC 6.0 too, but not using CUA.

One thing though, during recording, am I supposed to use "initial password" on main screen of SU01 or the one inside user change??

regards, Sean.

[jurjen_heeck]

> One thing though, during recording, am I supposed to use "initial password" on main screen of SU01 or the one inside user change??

I tried and succeeded with the first one.

[Former Member]

Hi Sean,

You can use transaction LSMW to perform mass user changes. LSMW is a step basied process where you can use batch input recording option to create the recording for the change process. Input the excel file with complete input field details as a tab delimited file. Map the source structure to the input file fields. and execute thus created conversion to perform all the changes at one go.

<removed_by_moderator>

Thanks

Sandeep

Edited by: Julius Bussche on Feb 19, 2009 11:28 AM

[Former Member]

@Jurjen

Thanks for the answer. I'll try this option.

@Sandeep

Would really appreciate if you can. My id is in my business card.

regards, Sean.

[Former Member]

Please take note that sharing offline documents is not the purpose of these forums, and is at your own risk.

It has happened in the past that incorrect information has been shared (giving life to "urban legends") or people have been "baited" into disclosing their identities and possibly company problems.

In most cases, the thread turns into a long chain of "Send me the docs" posts.... If that happens here, the thread will be locked / deleted.

Hope you understand,

Julius

[Former Member]

>

> Dear All,
> 
> Thanks for your replies.
> 
> We used SECATT too. All fields were mapped except password. We are on ECC 6.0 too, but not using CUA.
> 
> One thing though, during recording, am I supposed to use "initial password" on main screen of SU01 or the one inside user change??
> 
> regards, Sean.

Both will work but I recommend the "initial password" on the main screen of SU01. There is less clicking on your SECATT recording.

[Former Member]

Dear Julius,

My sincere apologies for expecting document sharing here in forum. Thanks.

regards, Sean.

[Former Member]

Hi

through SU10 can we set mass users password

[jurjen_heeck]

> through SU10 can we set mass users password

If that was a question then the answer is NO.

If it was an answer then it is incorrect.

[WolfgangJanzen]

May I ask for the rational behind this requirement?

Do you intend to set the same password to many users (which is critical from a security point of view) or do you intend to set a new (generated) password (individually) to a number of users (forcing them to think of a new password on the next interactive logon)? Both does not make sense to me.

Regards, Wolfgang

[Former Member]

Dear All,

I believe this matter is closed.

Thanks for your replies.

regards, Sean.