Enable deactivated productiove password from the backend

[Former Member]

Hi Experts,

Does any one know how to enable deactivated productive password from the back end. The scenario is administrator him self not logged in continuously for 90 days and the login/max_idle_productive is set to 90 days and login/password_expiration_time set to 60days and the productive password got deactivated.

We can do this by deleting sap* and relogin sap* and reset the password. But I want to know how to do from the backend.

I tried this.

updated schemaname.usr02

set pwdstate=0 where bname='XXXX' and mandt='000';

commit,

But this didn't work. I know the id is not locked. Thatswhy I didn't set uflag to 0.

Appreciate if anyone could help on this?

Thank you

Venkat

Edited by: Venkat Battula on Aug 18, 2010 7:22 PM

[sreekanth_sunkara]

Venkat,

Administrator password in the sense are you talking about your SAP Security Admin or SAP* and DDIC user ID's. more over i dont think your admin password will be deactivated after the max time. it just gets locked but wont be deactivated. please reset the password and you will be good.

Thanks,

SS

[Former Member]

SAP* is the intended way, but there are others.

Look in SM21 to see which other users are in 000 and try to RFC into the client --> BAPI_USER_CHANGE can reset and reactivate the password.

Or, transport a role with user assignment into the system and include object S_RFCACL in it. Then perform a trusted logon to it from another client.

Another way is to look for a job running in 000 and intercept it with a new step (into the debugger?)

The dirtiest trick is to set usr02-codvn = 'G' and copy the passcode over - but that does not work reliably, depending on your config. SAP might also get upset and charge you lots of money to fix the problem if it goes wrong.

But if your security is tight then none of these will work easily and deleting SAP* is the correct approach. Don't forget to create the user again in SU01!

Cheers,

Julius

[Former Member]

I thought the question was in productive client the administrator account is locked/deactivated , resetting SAP* in client 000 of the productive system?

[Former Member]

Looking at the attempted SQL statement I interpret it as:

pwdstate ='0'

A password with the status "productive"...

mandt='000'

In client 000.

But okay... the user's name is probably not "xxxx" either..

Cheers,

Julius

[Former Member]

He was executing the script on the client 000.

Julius,

But the answer you have given will surely give us in depth knowledge and good meaning to your interpretation of your findings

Thank you.

[Former Member]

You don't execute an SQL statement in a client. You execute it on the database...

The client is a logical system in the application. From the perspective of the database it is just a field.

Cheers,

Julius

[Former Member]

Julius,

I have mistyped it should be read as " for Client 000" on Production system.

will be alert!

I knew scripts are to be run at the database level.

Regards

[Former Member]

Hi,

Here I am talking about user administrators not SAP* or DDIC or any super user ids. I mean some id with SU01 full access.

Thanks,

Venkat

[sreekanth_sunkara]

Venkat,

ok, then you can login with SAP * or DDIC user id's and reset the password right?

thanks,

SS

[Former Member]

Why not he as a security admin login and do whatever is required like copying the Basis admin user, unlocking or whatever.

[Former Member]

> ok, then you can login with SAP * or DDIC user id's and reset the password right?

Well hackers might also make those same assumptions. SAP* and DDIC do not need any authorizations (except during upgrade tasks in client 000) because the hardcoding has been removed...

[Former Member]

Also I executed the script from backend only I mean from database login as sidadm.

Thanks,

Venkat

[Former Member]

Thanks Juluis for your valuable suggestions. Unfortunately all the customer defined ids got deactivated in 000 as generally we don't login for every 3 months to 000. Do you know by any chance the table name and associted field name in SU01 logon tab field "Password Status' and values for that like "productive password". Even I tried with debug but came to know they coming from some constant "F". I am not sure what that is.

Thanks

Venkat

[Former Member]

Hi Julius,

Even all the sap super ids sap* and DDIC also got deactivated because of the login/max_idle_productive_password parameter set for 90 days and any id doesn't login within 90 days.

thanks,

Venkat

[Former Member]

Can you login ?

Oki got it now you are talking about users in Client "000"

its better for someone who knows correctly to answer regarding reset of the user SAP* and DDIC but lot of scripts are available on the internet you can work with your DBA .

Or may be someone else who has recent exposure to this with database knowledge can give you the correct steps.

Edited by: Franklin Jayasim on Aug 18, 2010 10:46 PM

[sreekanth_sunkara]

ok Venkat,

i think then if you try to delete the SAP* and DDIC user ids from Database level then it wont delete the ids but reset the password to standard ones for SAP* and DDIC.

let me know if i am wrong.

Thanks,

SS

[Former Member]

So you have a password based "lockout" in a client...

See my first post. Those are your obvious options.

Personally I prefer the trusted-RFC option if you are already on the "inside" of the SID and want to avoid direct DB updates. It should also be supported by your emergency user procedure and logged at the application layer. After all, you have not done anything wrong (necessarily) in this client.

As you have already learnt, these DB updates do not work unless you are very intimate with the application and the config scenario and not just the DB...

Please do not update single fields of SAP tables based on "guess work"...

Cheers,

Julius

[Former Member]

> let me know if i am wrong.

You are wrong.

[Former Member]

> Can you login ?

I don't want to answer for Venkat, but think it is a safe bet to say "No, not yet" ...

[sreekanth_sunkara]

Julius,

what will happen if we try to delete SAP* and DDIC from database level? will they get deleted?

Thanks in Advance,

SS

Edited by: sun on Aug 18, 2010 11:43 PM

[Former Member]

It depends, but yes you are correct if you only delete SAP* from USR02 then it is still "there" if it already existed.

Alternately, if you never create it in Su01 then it is not "there" even if you are logged on with it.

--> If the user is there and only the password is locked or in this case deleted at next logon after being too idle, then the easiest way to get back in is to use an authentication mechanism which does not use passwords...

Cheers,

Julius

[Former Member]

Logon to your database with orasid as user id and run this sql

delete from sapSID.usr02 where bname='SAP*' and mandt='XXX';

commit;

SO this SQL will delete SAP* user id.

Where mandt is the client.

Now you can login to the client using sap* and password pass

[sreekanth_sunkara]

Ok Thanks Julius.

Thanks,

SS

[Former Member]

Looks like even trusted connection and RFC also doesn't work as all ids got disabled because of the productive password parameter set. I see only alternative for me is delete sap* and activate all the ids.

Thank you all very much for sharing your thoughts and really appreciate your prompt response with great suggestions.

Thank you all once again,

Venkat

[WolfgangJanzen]

>

> Looks like even trusted connection and RFC also doesn't work as all ids got disabled because of the productive password parameter set. I see only alternative for me is delete sap* and activate all the ids.
> 
> Thank you all very much for sharing your thoughts and really appreciate your prompt response with great suggestions.
> 
> Thank you all once again,
> Venkat

Sorry, but this is a wrong assumption.

Only password-based authentication is effected by passwords and their status (locked, expired, ...).

In any case you experience problems to logon to an ABAP server, kindly use the tracing approach described in [SAP Note 495911 |https://service.sap.com/sap/support/notes/495911]to analyse the cause.

By the way: the trigger for this feature (to specify after which time of not using a password it shall no longer be usable for authentication) is an Italian law. So, it's mandatory for Italian customers but optional for all others to make use of that feature.

[Former Member]

This message was moderated.