login/password_expiration_time for specified users

[Former Member]

Dear Members,

The proflie paramter login/password_expiration_time has been set globally for all users to 30.

Can this paramter be set to 0 (never expires) for some specified users (like Administrator, SAP* or DDIC)?

If yes kindly let us know the procedure (we are using ECC 6.0).

Thanks in advance.

--

Regards,

OsTrY

[mvoros]

Hi,

the parameter is ignored for user types SERVICE and SYSTEM. But you can't use these types for administrators. What is your motivation for turning off this feature for particular users? I don't see a reason why administrator's password should have unlimited validity.

Cheers

[Former Member]

convenience ?

Besides, users SAP* and DDIC can not be a 'system'.

I understand that is impossible?

And how to change a setting: "remember 5 previously entered passwords" for specified users?

[Former Member]

> Besides, users SAP* and DDIC can not be a 'system'.

Yes they can. You can also take all their authorizations away from them and lock them... BUT you first have to stop using them, in which case this special password treatment is not required either.

A use case for it is to be able to assign different password policies to different groups of users in different clients. That is now possible as of ABAP release 7.02, but the intention is flexibility within groups of users (e.g. internal vs. external, active users vs. annual planners, etc).

Cheers,

Julius

[mvoros]

Yes, you are right. Currently, it's impossible. I don't know about new functionality in enhancement pack 2 mentioned by Julius but I know that EP2 is in ramp up right now. The expected end of ramp up is in 6 to 8 months. Direct change of tables is a risky idea. I wouldn't go that way. What about convenient SSO for administrators or replacing passwords with certificates?

Cheers

[Former Member]

> What about convenient SSO for administrators or replacing passwords with certificates?

That is the best option along with system users for basis jobs so that you do not immortalize yourself in the system.

You only need DDIC for upgrades now since 7.00. The hardcoding has been removed.

You do not need SAP* for anything other than the master record in each client.

You can normally delete SAPCPIC quite safely and EARLYWATCH as well if you have central SolMan support.

That leaves TMSADM and WF-BATCH... (both SYSTEM type users for good reasons).

Cheers,

Julius

[WolfgangJanzen]

convenience  ?

In that case consider to use SSO (Single Sign-On) solutions.

They are very convenient.

[WolfgangJanzen]

A use case for it is to be able to assign different password policies to different groups of users in different clients. That is now possible as of ABAP release 7.02, but the intention is flexibility within groups of users (e.g. internal vs. external, active users vs. annual planners, etc).

Sorry, Julius - but that's not true.

The feature (Security Policies) will only come with a later feature pack, not with 7.02.

[Former Member]

Ooh! Thanks for the correction.

I am regularly asked about this via the wiki entry and on training courses. There are a lot of fans waiting

[WolfgangJanzen]

>

> Ooh! Thanks for the correction.
> 
> I am regularly asked about this via the wiki entry and on training courses. There are a lot of fans waiting 

Well, but it's not on the [Security Functionality Wishlist|http://wiki.sdn.sap.com/wiki/display/Security/SecurityFunctionalityWishlist-Topics], yet.

[Former Member]

Today is not getting off to a good start for me..

I now added the [original thread|; to the wiki and labelled it for the "wish list": [Ability to assign security policies to specific users|http://wiki.sdn.sap.com/wiki/display/Security/Abilitytoassignsecuritypoliciestospecific+users]

Cheers,

Julius

[Former Member]

We're thinking over to set password rules in a system, too. My question is now: what happens with dialog users sap* and ddic if profile parameter login/password_expiration_time is set and password has to be changed every 90 days and login with sap* is not possible because profile parameter login/no_automatic_user_sapstar is set to 1?

Assumed anybody needed sap* for more than 90 days. Will logon with this user be possible after 40 days with the password stored in the safe after resetting parameter login/no_automatic_user_sapstar to 0?

Regards,

Julia

[mvoros]

Hi,

I would suggest to read documentation for those two paramters in RZ11. The paramter login/no_automatic_user_sapstar set to 1 does not mean that you can't logon with SAP. If there is valid user master record for SAP then this paramter is ignored. The paramteer login/password_expiration_time just forces user to change password. So users can logon after 90 days with old password but they need to change it after logon.

Cheers

[WolfgangJanzen]

>

> We're thinking over to set password rules in a system, too. My question is now: what happens with dialog users sap* and ddic if profile parameter login/password_expiration_time is set and password has to be changed every 90 days and login with sap* is not possible because profile parameter login/no_automatic_user_sapstar is set to 1?
> Assumed anybody needed sap* for more than 90 days. Will logon with this user be possible after 40 days with the password stored in the safe after resetting parameter login/no_automatic_user_sapstar  to 0?
> 
> Regards,
> Julia

Please do not mix up the two different issues:

- password policy (regarding frequency of system-enforced password changes)

- emergency user account activation

For the first part of your question:

yes, DDIC and SAP* are dialog users and thus also effected by profile parameter login/password_expiration_time.

Currently, there's no way to define a different interval for them.

For the 2nd part of your question:

the emergency user account can always be activated (otherwise it would not be suitable for emergency cases). In that case you have to change the profile parameter value, delete the user master record (using DBMS tools) and restart the server (or at least one server instance - the rest of the system could continue to run undisturbed).

But don't worry: login/password_expiration_time only controls the password changes - you will still be able to logon to the system (unless you have also set login/password_max_idle_productive, see [SAP note 862989|https://service.sap.com/sap/support/notes/862989]).

Best regards,

Wolfgang

[Former Member]

Hi,

The setting being system-wide can not be changed for a specific set of users . Maybe you can work with ABAPpers to write a program which can be executed every month to keep on changing the value for the field " password last change" which is found in USR02 , Field BCDA1, User Name in BNAME.

Hope that helps.

Regards,

Manisha

[Former Member]

> The setting being system-wide can not be changed for a specific set of users .

Yes it can, but only since recently.

> Maybe you can work with ABAPpers to write a program which can be executed every month to keep on changing the value for the field " password last change" which is found in USR02 , Field BCDA1, User Name in BNAME.

If an auditor finds that you will be in big trouble...

If they think a step further and start comparing the password hash histories accross system boundaries then all your systems are in big trouble as well...

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for pointing that out. Maybe I took it as being " well understoond" but yeah , it definitely needs to be first checked with your auditors before implementing it in the system.

Regards,

Manisha

[Former Member]

Hi OsTrY

Please check with your auditors if they would allow the situation wherein password for specified user's(like Administrator, SAP* or DDIC) should not be changed. Once they allow this you can proceed to explore for options.

Thanks.

Anjan

Edited by: anjanpandey on May 31, 2010 10:09 AM

[Former Member]

What you think about changing the date fields PWDCHGDATE in the future ?

if this works?

[Former Member]

> What you think about changing the date fields PWDCHGDATE in the future ?

> if this works?

As already stated by Julius, It will be an audit issue. Auditors always want to ensure that password for superuser ids(User ids with wide access like SAP_ALl, SAP_NEW, S_A.SYSTEM etc..) is being monitored & changed periodically. They might even request you to show the logs for the password change being done.

Thanks.

Anjan

Edited by: anjanpandey on May 31, 2010 10:23 AM

[Former Member]

> They might even request you to show the logs for the password change being done.

That's one of the important points. The change documents will no longer match the BCDA1 field, or is it the PWDCHGDATE field, or both, or more than just these two ...

Cheers,

Julius