Lock the roles for modification in Production System

[former_member541772]

Hello All,

I need to lock the roles for modification in Production system. Even though user may have sufficient access, the roles should be non-modifiable.

Regards

[Former Member]

What constitutes "sufficient authorization"?

Perhaps you only want to distinguish between actvt '02' and '22'. This is possible.

Cheers,

Julius

[Former Member]

Remove the access, don't change the roles. It is illogical to change the object rather than use the concept which is designed to do this for you.

[Former Member]

Well its like giving the keys of your safe to someone and then trying to find a way to secure your safe..... !!

Cheers !!

Zaheer

[Former Member]

> Total Questions: 8 (8 unresolved)

We might as well discuss soccer... or more likely tennis: today being the day after yesterday...

Of course in a few weeks time no one will understand that comment, but perhaps Alex's post will?

Cheers,

Julius

[Former Member]

Hello Julius,

Haha, at last i saw you in good mood,, i do understand Alex..

Thanks,

Prasant K Paichha

[Former Member]

Sometimes you have to trust the people that you entrusted to administer your security roles. Perhaps you should get a report to compare the roles from Production to your golden security roles client.

[Former Member]

could you please provide information why you need to provide them change access in PRD??

Let them have it in DEV only

Thanks,

Prasant K paichha

Edited by: Prasant K Paichha on Sep 15, 2009 5:08 PM

[sdipanjan]

Hi All,

i have one suggestion. Recently in our project, the Auditor's suggested to set the parameter auth/no_check_in_some_cases to N in Prod system to Lock the role maintenance. Theoretically, it will deactivate the Profile generator tool but i am not sure about the other consequences specially in Authorization checks as per AS ABAP Authorization concept.

So I can't suggest you to do so currently. Just sharing this here so that I can also check the review of the other members.

Theoretically, it will Lock the role maintenance functionality in Prod system of course.

regards,

Dipanjan

[Former Member]

This parameter needs to be set to u2018Yu2019 for installation of the profile generator. It defines the use of table USOBT in the authority checks undertaken and allows authority checks to be disabled in individual transactions

Authorization checks can be suppressed with the AUTH/NO_CHECK_IN_SOME_CASES parameter. The number of authorization checks proposed by SAP can be reduced by using transaction SU24. This presupposes that the parameter is set to u201CYu201D for deactivating the authorization checks. The value must be set to u201CYu201D if the profile generator is used.

Recommended parameter value: u201CNu201D or u201CYu201C if the profile generator is used

Authorization checks are not deactivated if the parameter value is set to u201CNu201D. If the parameter value setting is u201CYu201D, regular checks should be performed to determine whether the authorization checks have been deactivated in order to maintain access protection

Thanks,

Prasant K paichha

[sdipanjan]

>

> This parameter needs to be set to u2018Yu2019 for installation of the profile generator. It defines the use of table USOBT in the authority checks undertaken and allows authority checks to be disabled in individual transactions
> Authorization checks can be suppressed with the AUTH/NO_CHECK_IN_SOME_CASES parameter. The number of authorization checks proposed by SAP can be reduced by using transaction SU24. This presupposes that the parameter is set to u201CYu201D for deactivating the authorization checks. The value must be set to u201CYu201D if the profile generator is used. 
> Recommended parameter value: u201CNu201D or u201CYu201C if the profile generator is used 
> Authorization checks are not deactivated if the parameter value is set to u201CNu201D. If the parameter value setting is u201CYu201D, regular checks should be performed to determine whether the authorization checks have been deactivated in order to maintain access protection 
> 
> 
> Thanks,
> Prasant K paichha

I am aware of the usage and meaning of these parameters. But I am waiting to see, what would be consequence if it is set to N in Prod specially. For such cases, where rdisp/max_wprun_time threashold value is reached and thus how many users are going to be affected during the pick usage of the system resources. Also a practical assessment is pending for the new Authorization proposals and changes of existing one if they are Transported from a system having Y to a system having N. Hope u understand, what these means.

Regards,

Dipanjan

[Former Member]

Prasant,

If you are going to copy chunks of text then it helps if you reference your source & also make sure what you are pasting answers the question

[Former Member]

Hi Dipanjan,

One of my clients has AUTH/NO_CHECK_IN_SOME_CASES = N in their prod box and they have no problem with roles transported from systems with the param set to Y. I believe that they also can maintain roles in prod. They are on 4.6C so maybe it is different to other systems.

Ultimately there is the question why this workaround is needed when we have the auth concept which will do it.

[sdipanjan]

>

> Ultimately there is the question why this workaround is needed when we have the auth concept which will do it.

Exactly So !! ... I also believe this and tried to convince them of checking the current Authorization structure. But of no use.

Many thanks Alex for sharing your experience on this.

So, this may be one option can be treated for this thread but should be the last one.

Premanand: It would be great if you go for restricting users from modifying Roles and profiles by using Authorization concept as you have seen all the posts here. Which means, user should not have sufficient access for these changes in Prod.. this is the outcome of this discussion as I can see.

regards,

Dipanjan

[Former Member]

> One of my clients has AUTH/NO_CHECK_IN_SOME_CASES = N in their prod box and they have no problem with roles transported from systems with the param set to Y.

What it will do is that your "NoCheck" indicators will also not work, along with all the PFCG related functions you loose.

But you won't loose a whole fleet of other transactions, reports and function modules which will make changes to roles or profiles or authorizations if the user is authorized for this.

Having read Alex's original post more carefully now - I would agree with you all that it is development system roles in production which are the problem -> because you can be fairly sure that someone will use them if they are there.

Of course in a BW system it is arguably different - and the reason why the OP's questions all remain unanswered is probably also because not enough information is supplied, in addition to not following up on them.

These are the sorts of questions which invoke flamewars and copy&pasting. I regret not having deleted it on sight, because now it is turning interesting so can't be done anymore...

But please dont get your expectations high that there will be an answer, except perhaps for an "asdf" type post in a few weeks time when the maximum of 10 open questions is reached.

My 2 cents,

Julius

[Former Member]

>

> Hi Dipanjan,
> 
> One of my clients has AUTH/NO_CHECK_IN_SOME_CASES = N in their prod box and they have no problem with roles transported from systems with the param set to Y.  I believe that they also can maintain roles in prod.  They are on 4.6C so maybe it is different to other systems.
> 
> Ultimately there is the question why this workaround is needed when we have the auth concept which will do it.

My Client is on ECC 5 and the moment we made it N, we lost the Authorization tab itself from PFCG. you will see the Menu tab but no Authorization tab.

[former_member541772]

Hello,

Thank you for your input. All are maintained at that authorization leve lonly....but just to be extra cautious...i want to eliminate the sligtest possibility to deactivate the process of changing roles in production..

Regards

[Former Member]

Hi Premanand

Removing the users access is a strong preventative control which is sufficient for your requirements.

If you also tell them that changing the roles is a breach of procedure and will result in disciplinary actions being taken against them, then they are not left in any doubt how serious the issue is.

[Former Member]

>

> Hello All,
> I need to lock the roles for modification in Production system. Even though user may have sufficient access, the roles should be non-modifiable.
> Regards

Premanand,

Create two roles. One for User administrator and the other for Role administrator. Do not give the Role Administrator role in Production to your Security admin. In Development your Security Admin can have both roles.

If you want your security admin to just have Display access for Profile Generator PFCG in Production, you can do that by controlling S_USER_* auth objects like S_USER_AGR, S_USER_PRO and S_USER_AUT etc.

Now coming to your question I think if you get the parameter auth/no_check_in_some_cases = N, this will gray out/remove change authorization data or disable generation of profiles. You can test this in your sandbox. Get your Basis Admin to change this parameter and bounce the system as this is static parameter and test it. You will see that you do not see the Authorization tab in PFCG.

[sdipanjan]

Name: Premanand Seshadri - View user's Business Card

Registered: Jun 19, 2009

Total Posts: 13

Total Questions: 8 (8 unresolved)

Forum Points: 0

may be we all are throwing stones in Desert.

regards,

Dipanjan