Restrict providing DEBUG access

[Former Member]

Hi All,

We need to prevent the security team to enable debug access via role modifications (pfcg) as well as user changes (e.g. su01/pfcg -> assign roles). Could you suggest ways of achieving this restriction?

Thanks,

Vijaya

[jurjen_heeck]

For the role-to-user assigment part I suggest you put your 'dangerous' roles in a different namespace so you can restrict assignment through S_USER_AGR.

To avoid them putting dangerous objects/values in the roles themselves I'd suggest training.

[Former Member]

Hi Vijaya,

You can restrict role modification access and user maintainance access by giving only display to below authorization objetcs :-

For PFCG/Su01 - S_USER_PRO

S_USER_AUT

S_USER_GRP

S_USER_AGR Give actvt field as 03 and 08 only.

Regards,

Sneha

[jurjen_heeck]

> You can restrict role modification access and user maintainance access by giving only display to below authorization objetcs :-

And afterwards, what do you pay them for? That'll block them from doing their job alltogether......

In addition to my earlier reply, S_USER_AUT makes it possible to restrict the entering of S_DEVELOP alltogether. Unfortunately this blocks more that just debug rights.

Edited by: Jurjen Heeck on Dec 8, 2008 10:32 AM

[Former Member]

>

> In addition to my earlier reply, S_USER_AUT makes it possible to restrict the entering of S_DEVELOP alltogether. Unfortunately this blocks more that just debug rights.
> 

S_USER_VAL could be used I suppose, it would be a nightmare to get it working to exclude just debug access though

[jurjen_heeck]

> S_USER_VAL could be used I suppose, it would be a nightmare to get it working to exclude just debug access though

Thanks for that.

I agree on the nightmare remark.

[Former Member]

I think you should be able to restrict the Object Type field without too much effort, and removing it completely may be advisable anyway. Combining it with more granular activity field values would probably not work though (because of the combination and use in many other objects as well).

Cheers,

Julius

[morten_nielsen]

Hi

S_USER_VAL could be used I suppose

This is correct if your are facing are "training" issue here, but if you want to secure it, you will need to control SU24 as well.

The S_USER_VAL is only checked if the object is maintained manually, not if it's granted through the default values for a transaction in SU24. And it is not checked when maintaining default values in SU24.

This might ofcourse be a bug - I haven't checked the OSS for this

Regards

Morten Nielsen

[Former Member]

Hello Morten,

Should this not be the case for S_USER_AUT as well, i.e. if the object S_DEVELOP is defaulted by SU24 by addition of a transaction in the role it is not going to restrict the security admin from generating the role?

[morten_nielsen]

Hi

Well S_USER_AUT controls SU02 and SU03, and deals with the profiles directly, and not the roles, S_USER_VAL controls role maintenance.

But of course if you need to secure your landscape from given debug access this object should be controlled to.

But I'm not sure on the "how-to-control-this-in-SU24" - this would, I guess, require a trace, unless somebody else can provide this little detail

Regards

Morten Nielsen

[Former Member]

> But I'm not sure on the "how-to-control-this-in-SU24" - this would, I guess, require a trace, unless somebody else can provide this little detail.

It looks like the concept was revised a while back already, and the maintenance checks in SU24 were replaced by S_DEVELOP checks (for object types SUSK and SUST).

According to SAP notes, the checks on S_USER_VAL are intentionally not included in the maintenance.

So... if you restrict S_USER_VAL to exclude the debugging and remove it from the "Proposal" indicators and do not assign S_USER_AGR authority for the role(s) which do have the debugging in them - then it might work (unless the user has even stronger authority to create programs of their own).

Cheers,

Julius

Edited by: Julius Bussche on Dec 10, 2008 11:12 AM

[Former Member]

This message was moderated.