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: 

Profile parameters controlling idle passwords

Former Member
0 Kudos

We are planning to activate the two profile parameters:

login/password_max_idle_initial

login/password_max_idle_productive

on our productive ERP system to control the validity of idle initial & productive passwords.

Our Basis-team are concerned about this, because the change will take effect on all clients on the system. Once in a while they need access to client 000, 001 & 066 and now they fear that the passwords on their personal accounts will be expired when they try log on to those clients (nobody, except the basis-guys have access to client 000,001 & 066)

I would like to hear from you, how you handle this issue in your installation.

Best regards,

Peter Jæger

1 ACCEPTED SOLUTION

Bernhard_SAP
Advisor
Advisor
0 Kudos

Hi,

simply change the user type in those clients for your admins to 'Service'. then their passwords won't expire.

b.rgds, Bernhard

11 REPLIES 11

Bernhard_SAP
Advisor
Advisor
0 Kudos

Hi,

simply change the user type in those clients for your admins to 'Service'. then their passwords won't expire.

b.rgds, Bernhard

0 Kudos

Hi Bernhard

We have discussed this option, but then these powerfull users would never be forced to change their password which neither is good.

Best regards,

Peter

Former Member
0 Kudos

passwords of super user like SAP* can be reset any time from DB....... running query for particular client...... and it will be set to 'pass'.

so don't worry..... system admins knows how to login into system

regards,

Surpreet

0 Kudos

Hi Surpreet

I get your point, but we are looking for a solution where we don't encourage the Basis-guys to mess around in the DB

Best regards,

Peter

0 Kudos

Hi,

It is not recommended to reset the password from DB and moreover it is more risky to take such a step.

The intention behind enabling these parameters is to keep the system more secure. If we recommend to have backdoor solutions, it may open more risks. aint'it?

My suggestion here would be to setup a process before implementing this solution. The passwords of the critical users should be reset at a regular intervals. If you set the parameter value to 15, set the process to change the password at an interval of 10 days. This is much appreciated by the audit teams and is also a good practice.

Hope it is clear.

Warm Regards,

Raghu

0 Kudos

Hi Raghu

I'm neither a supporter of changes made directly in DB...

We were just wondering if there was a more convinient way to do this without jeopardizing security - I know the basis-guys would dislike changing their password on a regular basis to change their password on these clients used very seldom.

Best regards,

Peter

0 Kudos

Hi Peter,

I understand. But, these parameters have both pros and cons. It is always better to implement when the advantages and more when compared to a few of its dis advantages. I personally feel that there should be another parameter, which excludes users in specific user groups, so that the implementation of these parameters will really help Isn't it??

Warm Regards,

Raghu

0 Kudos

Hi Raghu

Exclusion of either specific User Groups or maybe specific Clients would definitely be useful

Best regards,

Peter Jæger

0 Kudos

Luckily for you, people have thought this to be usefull before and it was added to the [SDN Security Funactionality Wishlist |https://wiki.sdn.sap.com/wiki/display/Security/Abilitytoassignsecuritypoliciestospecific+users] some time ago.

Last I heard, the status was that the code base for the feature was approved and already implemented. The application components to be able to use it will be delivered with a future release (so you are looking at sometime next year).

Anyway, why don't you give the basis folks the ability to logon to client 000 from their SolMan using trusted RFC? This was the local password can be deactivated without any interuptions and when the do need it for some reason, they go via the SolMan and reset the password in SU01.

Cheers,

Julius

0 Kudos

Hi Julius

Thank you for the interesting link.

We had not thought on the idea with accessing client 000 from Solution Manager, which I will discuss with the Basis-guys u2013 would it be possible to make a similar solution for client 001 & 066 ?

Best regards,

Peter

0 Kudos

If the connections are there (SLD?) and visible to the Solman application (CCMS?) then it would just be a mouse-click.

Cheers,

Julius