BW Password reset in BW 7.0

[Former Member]

I feel lame asking this question, but i seriously can't find anything on this topic. We have BW 7.0 and when you are in SU01 and press the change password icon you can type in the password. Once you press the green check mark, the screen will not close. So then you press the X and the password reset is cancelled. No matter what you press check mark, activate/deactive, random password, the screen can not be closed unless you press the red check mark. The best way to reset the password right now is by going into SU01 and doing it.

Has this happened to anyone else?

[Former Member]

Try Start => Control Panel => Mouse => Button configuration => Switch primary buttons.

Other than that, I can't see this problem.

Cheers,

Julius

[Former Member]

Unfortunately, the mouse settings has nothing to do with this.

[Former Member]

Is it possible that what you meant to say was:

"We have BW 7.0 and when you are in SU3 and press the change password icon you can type in the password..."

In which case, are you using Single-Sign-On or Trusted RFC to connect to the BI system from the ERP?

Cheers,

Julius

[Former Member]

No, this is the administrator job. When in SU01, the password reset will not take on the additional screen.

We do have single sign on in production, but this is an issue in all environments, not just production.

Steps: go to SU01

Enter in User ID

Press Change Password

Type password twice

Press green check mark or enter and nothing happens.

[Former Member]

Is this in the initial SU01 screen, or on the logon data tab in change mode?

[Former Member]

Does not seem to be issue with Security authorization. I have worked on BW 3.5 and I am pretty much sure it is not because of authorization issues. Why will password reset icon not work for any system. And I agree its really irritating to do a password reset every time going into logon data tab in SU01

Is it possible that somehow there was a code change done to SU01 which has disabled this password reset icon. Can somebody debug for you.

I would love to know what caused this problem. If somebody can advise.

[Former Member]

What ever it is, is sounds illogical to me.

When strange stuff happens, it is usually best to first eliminate some local adaptations (or interpretations) of single fields of the USR tables which someone with developer access thought they were being clever about, with resultant updates.

Please go to table USR02 in SE11 and do a Where-Used-List search on it. Do any custom programs show up?

Cheers,

Julius

[Former Member]

The code has not changed and debug actually cancelled itself before it got to that screen. I will create an OSS message.

[WolfgangJanzen]

Sounds like a bug in the UI.

Did you file a bug report, already? Do not forget to add the information regarding your ABAP release (incl. Support Package for component SAP_BASIS).

[Former Member]

>

> Sounds like a bug in the UI.
>

That, or an SHDO transaction variant would actually have been my second guess.

@ Bree: Take a look in tcode SPAU to see whether any modifications are recorded for SU01?

Cheers,

Julius

[Former Member]

I will create the OSS message.

Information was:

SAP_BASIS 700

SAP_BW SAP NetWeaver BI 7.0

[Former Member]

No objects were changed in SPAU.

It just seems weird that Password resets wouldn't work...

[fredrik_borlie]

Will it work if you start changing the user and then go for the logon tab, change the password and then press save?

To analyse your error you can try checking with an abapper if he/she can help you trace.

And to save time with the trace what you can do is to create a shortcut on your desktop containing instant debug.

In SAP gui, click Generate Shortcut. Icon just beside the Create Session Icon.

Save it on the desktop, and open it in via right click and Edit.

Then change Type to System Command and set the command to /h

Save by pressing OK.

Make sure you see the Shortcut icon on your desktop, kick off the change process and when you are to press the green check mark. Drag the SAP shortcut and drop it on the open window. Now you have enabled the debug and when you press the green check mark your debug session will start immediately in the right place.

Another way of making this debug file is to take the following code and create a text file on the desktop.

Call it SAPdebug.sap (or what you want, but it must end with .sap

Make sure it is not called SAPdebug.sap.txt !!!

[System]
[Function]
Command=/h
Type=SystemCommand

Good luck!

/fredrik

[Former Member]

Yes, I can reset the password on the Logon tab, just not on the initial screen.

We did a trace and a debug and came up with no results.

thanks for the comments.

[Former Member]

Hi Bree...

I'm not sure this would work .. agar hogaya tou ek TARA dena.

Table USR40 contains the exception list of passwords that can't be used...

OR

Clone a copy of the USER (it will prompt for anew p/w when doing that) and then delete the original 1

OR

Execute this code in the client where the user is defined, and then reset his password

TABLES: usr02.

UPDATE usr02 SET codvn = 'B' WHERE bname EQ 'USER_NAME'.

OR

May be u have deactivated the PW N SAP keeps a list of passwords previously used. This means

that the user can no longer log on using a password, but only with Single Sign-On variants (X.509 certificate, logon ticket).

If still .... getting the same try again as Julius said before.

regards,

[Former Member]

> .. agar hogaya tou ek TARA dena.

Please keep to English in the forums.

> May be u have deactivated the PW N SAP keeps a list of passwords previously used. This means

> that the user can no longer log on using a password, but only with Single Sign-On variants (X.509 certificate, logon ticket).

Ahh yes, that might possibly be the explanation. That also rings a bell now for me.

About a year ago, there was a "bug" in that setting an initial password had to be different from the previous passwords as well. I cannot remember the solution exactly, but I think this could however be over-ridden by an administrator with change authority (actvt 02) but not the ability to reset the password only (actvt 05). This might cause similar behaviour as described by Bree as a side effect....

I'll see if I can find the reference => here it is: SAP Note 1026425.

Cheers,

Julius

ps: Your update USR02 option is not a good one...

pps: Cloning the user to fix this problem is probably not a good one either (see SAP Note 1222807)

Edited by: Julius Bussche on Jan 31, 2009 11:59 PM

[WolfgangJanzen]

> > May be u have deactivated the PW N SAP keeps a list of passwords previously used. This means

> > that the user can no longer log on using a password, but only with Single Sign-On variants (X.509 certificate, logon ticket).

> Ahh yes, that might possibly be the explanation. That also rings a bell now for me.

No, this check is only performed when the user is changing his own password.

When an administrator is setting a new password, this check is skipped (to prevent that the system discloses information such as "that password was previously chosen by the user").

> ps: Your update USR02 option is not a good one...

> pps: Cloning the user to fix this problem is probably not a good one either (see SAP Note 1222807)

I fully agree. Direct table manipulations are harmful - please use the provided APIs, only.

[Former Member]

> Wolfgang Janzen wrote:

> No, this check is only performed when the user is changing his own password.

> When an administrator is setting a new password, this check is skipped (to prevent that the system discloses information such as "that password was previously chosen by the user").

Now that is a truth which hurts. Whoever thought of that idea, probably does not use "INIT1234" and "Winter09" either...

I guess that is what the USR40 warning is for, and should be combined with security awareness training, as also indicated in the previous note I mentioned:

> SAP Note 1026425 wrote:

>For security reasons, we recommend that you do not use standard passwords but that you use the function to create passwords in transaction SU01.

But So re-using the same initial password twice can should be avoided, according to this note.

> If you define initial passwords, you have to make sure that you do not define the same password twice in a row.

Cheers,

Julius

Edited by: Julius Bussche on Feb 2, 2009 10:36 AM

[WolfgangJanzen]

>

> > Wolfgang Janzen wrote:

> > No, this check is only performed when the user is changing his own password.

> > When an administrator is setting a new password, this check is skipped (to prevent that the system discloses information such as "that password was previously chosen by the user").

> Now that is a truth which hurts. Whoever thought of that idea, probably does not use "INIT1234" and "Winter09" either...

Well, guess who ...

But maybe we talk of different subjects:

> I guess that is what the USR40 warning is for, and should be combined with security awareness training, as also indicated in the previous note I mentioned:

USR40 contains the "negative password dictionary" (patterns of "forbidden passwords").

That's different from the password history I was referring to in my previous statement.

The password history only contains those passwords that have been chosen by the user - but not those passwords that have been set by the admin. And consequently, the system should not inform the admin that the password he has chosen is identical to one of the passwords in the password history ...

The administrator is allowed to violate the "USR40 password rule".

The system will only display a warning - but the admin can overrule it (since the admin could also change the USR40 content which then, however, would also allow the endusers to violate the USR40 rule).

> > SAP Note 1026425 wrote:

> >For security reasons, we recommend that you do not use standard passwords but that you use the function to create passwords in transaction SU01.

>

> But So re-using the same initial password twice can should be avoided, according to this note.

> > If you define initial passwords, you have to make sure that you do not define the same password twice in a row.

That note is describing a bug; the recommendation is a workaround solution, nothing more.

But in general it's true: the system's capabilities to generate (fairly) random passwords is superior to the capabilities of human beings to "fantasize" new passwords.

[Former Member]

Whether typing in a standard password or using the random generate icon, the password will not accept. It seems like the green check mark is just not functioning. It won't accept the password.

[Former Member]

Did you try Bernhard's suggestion to activate the GUI status?

[WolfgangJanzen]

>

> Whether typing in a standard password or using the random generate icon, the password will not accept.  It seems like the green check mark is just not functioning.  It won't accept the password.

That's a bug - unless you've customized your system for unfulfillable password rules ...

Did you already obtain any response to your problem report?

[Former Member]

Just an update:

In regards to the Function Group Suu5, I don't want to make any changes until SAP comes back, because it would require us to register the object.

We are still waiting on the OSS message response.

If you are wondering about the Gui, whether we have a 640 gui or 710, it doesn't make a difference.

I've done security for 8 years, this is just stumping me.

[Bernhard_SAP]

Hi Bree,

I don't believe, that you need an access key for simply reactivating the GUI status PASSWORD in SE80....

It's worth a try...

b.rgds,

Bernhard

[Former Member]

SUU5 changes did make this work. The note is misleading because it mentions CUA which is not installed. We tried it in the Sandbox and it was resolved. We will not do these changes in the development client.

[Former Member]

hi bree

can you tell me what was the solution to your problem, as I am facing same issue now, not in bw but in R/3

Regards

Tarun

[Former Member]

We had this same issue after upgrading to BW7.0 (NW2004S).

The information in the thread is correct, but specifically you need to do the following:

Go into transaction SE80.

Enter "Function Group" and "SUU5", hit enter.

Under the "Object Name" locate the "GUI STATUS" folder and expand it.

Double click on the GUI Status of "PASSWORD"

Single click on the Activate Button (matchstick).

This will reactivate that GUI status.

[Former Member]

Thanks for confirming what is already stated...

And welcome to SDN.

ps: Please try to avoid bouncing old threads too often as they might obscure other more current questions, even if you are very delighted to have solved your problem

Cheers,

Julius

[Bernhard_SAP]

Hi Bree,

if the 'check'-button does not work as expected, this could be because of the implementation of note

#1166395. In some cases it happened, that after implementation of the corresponding supportpackage, the change of status has not been performed.

Please try the following:

-->(re)activate the GUI-status PASSWORD in the function group SUU5 (or the complete function group).

After that restart SU01. The check-button should work again then.

b.rgds,

Bernhard