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: 

Exceptions to the rule... idle users who are expected to be idle?

Former Member
0 Kudos

Dear gurus,

I have a question, on which I would appreciate any input (I just give the facts, and would appreciate any comments):

A policy is in place and implemented in SAP (slightly different releases, but all BW's).

Dialog users with new initial passwords are locked very soon if idle.

Dialog users with reset initial passwords are locked very soon if idle.

Dialog users with idle login habits but not initial passwords, are locked (account) after 60 days of inactivity (automatic... and company policy!).

The reason for the policy is that users are mostly decentral, but the systems are not. Users are required to logon to the BW'a every 3 months (quarterly!) to enter plan data.

So.... (the "mime in a forest" happens...) which is what the policy intended to prevent...

The users can be identified and placed in a user group (S_USER_GRP) and there is no decentral user administration in the BW's.

Question: Why not exempt those quarterly planners from the "global" 60 day idle user lock rule?

Any experiences or opinions would be appreciated.

Kind regards,

Julius

1 ACCEPTED SOLUTION

Former Member
0 Kudos

please provide a bit more information.

1.) how many users all in all and planners specifically are you talking about?

2.) how's the whole thing set up? CUA+HR? i ask this in order to get an information about the rules that apply if one/more of the planners are on a vacancy or ill when their planning-time comes ... is it clear for the system which IDs will do the work then?

3.) how's the planning designed. one step or more connected via workflow? if yes, how's the workflow set up in case its possible agent is locked?

Edited by: Mylene Euridice Dorias on Feb 26, 2008 12:40 PM - those typos ...

17 REPLIES 17

Former Member
0 Kudos

please provide a bit more information.

1.) how many users all in all and planners specifically are you talking about?

2.) how's the whole thing set up? CUA+HR? i ask this in order to get an information about the rules that apply if one/more of the planners are on a vacancy or ill when their planning-time comes ... is it clear for the system which IDs will do the work then?

3.) how's the planning designed. one step or more connected via workflow? if yes, how's the workflow set up in case its possible agent is locked?

Edited by: Mylene Euridice Dorias on Feb 26, 2008 12:40 PM - those typos ...

0 Kudos

Thanks Mylene,

I don't know the exact figures, but total users are > 1000 and these quarterly planners are ~ 100.

There is no CUA, or HR involved. They are known (also to the system via the user group) and they know that there are these deadlines for entering plan data. There is no workflow or the likes involved. When the plan data is entered and reviewed, it is pushed back out - but that is after a review which checks the plan data anyway.

If the planner does not enter their data, then AFAIK the company they are planning for does not get a budget. So they will logon... but only quarterly and in some cases half year.

Personally, I don't see a problem (actually, I think it is a silly question but wanted to check how others handle these known / expected exceptions.

Kind regards,

Julius

0 Kudos

>

> Personally, I don't see a problem (actually, I think it is a silly question but wanted to check how others handle these known / expected exceptions.

Well, I remember a similar situation at a previous employer where our account managers had to log on once a month but not on a specific date. That meant there could be more than 30 days between two logons and that exceeded the password expiry period.

There was nothing easy to do about it (someone held on to the password period of 30 days with his life) and rest assured, out of all staff the account managers hated the system the most I spoke to allmost all of them every other month.

0 Kudos

Hi Jurjen,

Indeed, using account locks could be an innovative way of establishing contact with people whom I would otherwise not get to meet, and then ask them what they think of the system...

Cheers,

Julius

0 Kudos

the background of all my silly questions is this: we have a CUA + HR and a workflow established that forwards service-entry sheets exceeding a specified amount (using MM-SRV release strategy) from a service assistant to her/his manager. of course they get that thing in their outlook otherwise the whole concept would be doomed - because there's no need to logon for a service manager, except this special one.

however: this amount is not often exceeded, so i have loads of inactive and locked service managers ... nice talking to them ... really: they have that quiet attitude around them ...

anyway: i'm good for my word - no exceptions. expired users get locked.

0 Kudos

Thank you for the infos and comparison to your similar scenario.

Mylene Euridice Dorias wrote:

> however: this amount is not often exceeded, so i have loads of inactive and locked service managers ... nice talking to them ... really: they have that quiet attitude around them ...

The difference here, is that it is always exceeded by the same period of days by the same user group. It is in fact expected.

If they were to logon each month with nothing to do in the system, it would be suspect, also for quiet spoken folks...

So I think, if the company existed only of these folks, the policy would be different...

Julius

Edited by: Julius Bussche on Feb 26, 2008 2:08 PM

0 Kudos

Hi Julius,

I always keep wondering, and dont know if one is already in place:

It would be greta to a user group (SUGR) to which we can assign certain users who login only once in a "blue moon" but do definitely require their access.

One example could be auditors in the company, (who are caught up with other work) that only login after a long gap.

We could then have users of this group exempt from the password/ expiry policies.

(i do agree that this might mean compromising suystem security a little though) but i, as a system administrator can do without the tantrums that the high and mighty in the organization throw up when they fin their access gone.

Obviously i stick to my guns and ask them to follow the standard procedures in compliance with the company and SOX policies but that make me the bad guy

Regards,

Prashant

0 Kudos

>

>

> Obviously i stick to my guns and ask them to follow the standard procedures in compliance with the company and SOX policies but that make me the bad guy

>

you are the bad guy - better get used to it ) the only reason for my continued existence is that burning witches is no longer legal

0 Kudos

Mylene, the way i see it, the system is my child, so i wouldn't allow anyone to mess with it, because if they do thats a lot of pain for me (interpret as " cleaning up work" / glitches),

Regards,

Prashant

0 Kudos

Thanks Prashant!

Prashant Pasala wrote:

> One example could be auditors in the company, (who are caught up with other work) that only login after a long gap.

Yes, that would be the same scenario. Annual audits, which may or may not be performed by the same auditor. Auditors might also share their passwords to avoid user registration problems, or generic IDs are used for them each time... but in this case the budget planner has a named user and has little insentive to let someone else do their planning for them.

I was thinking to myself: even if I did not extend the idle login period, any user in the system could just continue to logon for the sake of keeping the account unlocked (only for that reason - to remain "invisible" to the 60 day idle user checks). That risk is the same for all dialog users subject to password validity period rules.

If we are going to do something to them, then an idea I had was to restrict via the "planning role" a validity inteval for the user assignment to only the next planning dates - 3 months away. But the user ID could still continue to logon (but without this access). That can be done quite easily in PFCG with 2 or 3 mouse-clicks.

Perhaps a better idea would be to restrict the validity of the user ID's in the user group to logon only during the interval of the next planning activities only. This can be done in advance when the dates are known.

If someone shared their password or it was found (like on a post-it!) then preventing the logon sounds like a good idea to me. When the validity date is reached, the user will be forced to change the password right away (making the post-it! less usefull). If someone changed it for them, they would notice quite soon as they should be logging on on that day (or week) anyway...

Thanks Prashant! Your comment about the auditors gave me that idea!!

Or do you still think that locking after 60 days has an additional advantage?

Thanks to all,

Julius

0 Kudos

Mylene Euridice Dorias wrote:

> the background of all my silly questions is...

I meant that I found my own question a bit silly...

Yours where good!

0 Kudos

Well, Julius, Your idea of locking the users after 60 days is any a good idea... in a way, this would ensure that people who have left the organization or have moved on to other jobs withinthe organization dont have access to the system anymore This has to be in place.

My idea of having a separate user group stemmed from another aspect os SAP where users belonging to a particular group are allowed multiple logins in PRD environment. This is done through an SAP standard profile parameter (which i cant seem to remember off hand)

Regards,

Prashant

0 Kudos

Yes, we will definately keep the 60 days no logon = lock rule.

This one is perhaps a tad better: 5 days after validity date start no logon = lock (because the expected idle period is expected to have ended, but has not).

> My idea of having a separate user group stemmed from another aspect os SAP where users belonging to a particular group are allowed multiple logins in PRD environment. This is done through an SAP standard profile parameter (which i cant seem to remember off hand)

If I remember, there are 2 parameters for SAPGUI (if that is what you are refering to):

login/disable_multi_gui_login, which is system wide for all dialog users.

login/multi_gui_login_users, which is a list of exceptions to the above parameter.

I cannot imagine that user groups can be entered into the second one (only single user ID's with some limit of sorts). We also would not want to, as an active user would not notice when another person opens a new successfull logon session with their ID...

Kind regards and thanks again to all,

Julius

Former Member
0 Kudos

Hi Julius,

how exactly do you need to interpret the 60 day rule ?

Maybe those 60 days can be interupted (legally) - e.g by a period during which the user is locked by other means.

If that's the case you could lock these special users after 30 days of inactivity, but unlock them automatically when the next quarterly activity is about to start. If the user logs on to the system, the cycle is restarted. If the user does not log on - he will be finally locked after another 30 days of inactivity (60 days of inactivity in total).

Users regularily (every 30 days) logging on to the system would never be locked. Users regularily (once every quarter) logging on to the system would not notice they are being locked.

In the unlikely case that someone likes this approach:

In my view its main problem is the initial question.

It would be possible to answer this question if you assume that their is a stringent logic behind the password expiration time that could be challenged. There could be such logic - but the typical ABAP implementations are usually much more strict then required (standard logic: period short enough to make it very unlikely that a password can be guessed and tried out. Period depends on password complexity and the maximal frequency for trying out guessed passwords. In SAP that frequency is typically extremly low.).

If your compliance guys would be willing to give in to "logic" - the whole 60 days rule could disappear. That's pretty unlikely

And then - you need to find a way to implement the approach. Should be possible though ...

Best regards,

Ralf

0 Kudos

Thanks Ralf!

Under the current environment for these systems, we would want to keep the 60 day rule anyway.

I agree with you that if the pw is shared, compromized or written down and found in time, then the 15 minute screensaver, 2 / 5 day initial password, 60 day policy (this one) and any other "hardening" of the password are all toasted.

Yes, under a different environment which managed the access itself and the identity of the person accessing the user ID (you can purchase boimetric devices for around 30 Euros already...) this policy would need a serious re-think based on why it was required in the first place...

> That's pretty unlikely

> ...

> ... Should be possible though ...

AFAIK, the validity (FROM / TO ) is a key factor for IdM's as well.

Our idea (after discussing it a bit internally) will be to try to get it right manually first (also investigating calendar options) before automating the whole lot.

Kind regards and nice to hear from you again,

Julius

Former Member
0 Kudos

IF I understand your question right,

Yes you need to exempt the quarterly planners from the 60 day rule due to the following :

1. Their function in the corporation needs their presence in the system quarterly -hence they are Not an IDLE user at all.

Now from a business stand point -Licencing fees to be preceise - it makes sense to lock them out till they are just needed to be presented to the system.

Juluis, If I am not clear, i am willing to come over !

Thx

0 Kudos

Thanks George...

> 1. Their function in the corporation needs their presence in the system quarterly -hence they are Not an IDLE user at all.

I know what you mean. They are not idle people at all. But they are idle users in the system.

> Now from a business stand point -Licencing fees to be preceise - it makes sense to lock them out till they are just needed to be presented to the system.

We have an Enterprise License: No security problems with number of users and license measurement which I am aware of.

> Juluis, If I am not clear, i am willing to come over !

Goreg, I sent you a Christmas card and you never responded.

Are your contact details correct? Or can your email not handle 20 MB Christmas Card attachments?

Kind regards,

Julius