Lock Role for Changes till the transport is released

[Former Member]

Issue : since roles are managed by multiple security administrators, changes are moving against the sequence.

We have multiple security administrators, is there a way to lock a role for changes until the task/ req is released.

Example Scenario :

Security admin 1 : if there is a change request to add SU01 to the role: Z_TESTROLE, Security admin adds it and creates a Change request but does not release it.

Security Admin 2 : the security admin 2 will get a Change req for the same role Z_TESTROLE to add a tcode PFCG to it. Security admin 2 does his job and moves his transport now even though the first transport does not move the change made by the first security admin moves with the transport for the second admin.

We have multiple security administrators, is there a way to lock a role for changes until the task/ req is released.

[Former Member]

Hello Salman,

No, unlike the repository obejects which are locked by a single developer until the request is released:

the same is not possible for roles as they come under customizing changes.

For the client that i work for, there are multiple security consultants too. To overcome this problem, we maintain details of change made, by whom, date and description in the DESCRIPTION tab in the role.

Probably something like this would help you.

Regards,

Prashant

[Former Member]

Prashant ,

Thanks for your reply. Actually we also follow the same procedure but the problems occured in cases where in the data was erased from the description tab (as it is modifiable).

Just in case you come across any alternate solution kindly let me know.

I appreciate your response.

thanks,

Salman.

[Former Member]

> Salman Mohammed wrote:

> Actually we also follow the same procedure but the problems occured in cases where in the data was erased from the description tab (as it is modifiable).

> Just in case you come across any alternate solution kindly let me know.

Hmmm... sounds like an organizational problem. What Prashant described is what I have seen as well.

Could you clarify something for me?

If the first change is released before the second change is made, then the second change when transported will add the second change as well = so if both changes are approved, then you got what you wanted in the end.

If the first change is released after the second change is made, then the first change when transported will add the second change as well = so if both changes are approved, then you got what you wanted in the first transport already.

So... if the owner of the role is involved in the QA of the change and approval of it, where is the problem (other than admins deleting modifiable fields)?

Or is the second change not authorized / approved?

Regards,

Julius

[Former Member]

Hi Salman,

As per my knowledge,

-> Every role will have a role owner and every system/ landscape will have a owner.

-> When ever we want to make changes to the data, it should be approved by the respected owner.

-> Normally we also maintain the change information in the description tab.

-> all the changes/updates will be communicated to one of the owner.

the owner will have the track about his roles (because he will have the latest communication from the Security admin. )

in general, when ever role modification work is identified, the Security team/ functional team will also think about the near future requirements and include that one also.

in your case ....

if any one of the transport moved.......all the changes will be moved.

With out proper approvals Security team does not start the work ...right?

in case of detailed change info lost at description tab, we can get the change track from SUIM change information.

or else ....obviously we have to depend on the third party tools.

[Former Member]

there are two things to be said here:

A this is something one should not try to solve technically, but in procedures

B make sure that transports are imported in release date sequence or later changes will be overwritten by older versions.

On the procedural point: make sure that all will ONLY change when errors are found and NOT make changes to the process, as for that a change request should be made togheter with or by a functional consultant.

And so teh examples are not good: a change in TRX to a role is a change in process, so can not be done just on request of every Tom, Dick or Harry as it has impact on how the business is run, on SoD, might need training etc.

to help making the right decision here:

A an error is when the role is not working as described, so objects and or objects values need to be added/changed.

B a procedural change is when the business wants(is ordered) to do their tasks in a different manner from the way it is currently described.

I am aware that a lot of companies lack a proper description of their processes, in such cases there should be a functional consultant (expert) that can decide about the change.

[Former Member]

Hi all,

Thanks for your responses.we follow a change procedure but I guess its just needs to be refined. Everybody figured out that this is a coordination issue but I was asked to research on any technical ability to handle this.

Here is a brief overview of our process :

1) BPO approves the change

2) Role owner support manager approves the change

then the Change request comes to 3)Security Manager for her approval.

I feel from Sox prespective the 3rd approval in not manadatory.

I'm I correct ??? where can I find Sox guide for SAP ?

Recap of the incident:

1)A change ticket is created for the t-code creation and a task is created for the role in which this report is to be added.

State I role Z_TESTROLE is with ZMMR0025

After adding the new report ZMMR0055 the old report ZMMR0025 is removed.

State II

The role Z_TESTROLE has tcode ZMMR0055

now this is tested in development system by the requestor.

Before this goes into PRD via QA a newsflash is sent to all the endusers (so that they know which t-code to use)

Meanwhile if another security administrator works (suppose adds a new tcode or changes an authorization) on this while the role is in state II changes made by Admin 1 are transported along with the second change.

State II + new changes = State III

When the role reaches PRD in state III result is the end user losses access to the required functionality ZMMR0025 before ZMMR0055 is made available.

I hope I’m clear , please let me know if I need to be more specific on any part.

I appreciate your help.

regards,

Salman.

[Former Member]

I have worked in many organisations were a similar process was followed. this goes right for 99% of teh situations, the only error can be the human error and i have been tought that one should never blame a whole organization if a single human make mistakes, just talk to the person who made the mistake and make him/her aware of the problems created.

[Former Member]

I'm impressed with what you have been taught, but here my issue is for a technical solution and also that the role owners and security manager are too busy to keep track of multiple changes to the roles.

No one is blaming the "whole organization" if you read carefully I said refine.

Your suggestions will be appreciated.

Thanks for your help.

[Former Member]

I have to agree with Auke. This is more of a procedure issue. There is nothing I can think of technically to address this issue. However, I can add some of the procedure we have that might be helpful.

On the security role in the "Description" tab we enter the recent change and reference a change control number and the security admin initials. Our security administrator usually look at this information before making any change to a security role. If they noticed there is an open issue for this role, they will defer to the other security administrator.

[jurjen_heeck]

Depending on how many security administrators you have (and assuming your naming convention does not interact with profile names) you could try setting up the following to control changes in single roles:

Each security administrator is assigned a letter (or combination of letters) to identify him/her.

They all get rights to change only profiles that begin either with T-* or their own letter(combination). (object S_USER_PRO)

As soon as a security administrator edits a role he/she is obliged (by the procedure) to store the original profile name in the comment field or in your change management system and replace it with a new (temporary) profilename beginning with his/her assigned letter(s).

Now none of the other admins can change this profile. So if a second change comes in for this same role it'll have to wait or go to the same administrator.

Once the change has been signed off the original profile name is restored and the profile is open to changes by others again.

Never tried this, but maybe it works.....

[Former Member]

Hi Jurjen,

Again this will create lot of issues,

Ex.:

-> we have to wait for the same consultant to complete it.

-> or there should be one or two shadow consultants for each.

the better idea is

-> maintain proper documentation/ communication in the role description tab, Transport request documentation and general communications.

-> there should be a integrated communication with in the security team. Like creating a mail group alias for security team along with approvers, then all the in& out communication should be marked to the group mail. so that all security consultants will have the updated info.

[jurjen_heeck]

>

> Hi Jurjen,

>

> Again this will create lot of issues,

>

> Ex.:

> -> we have to wait for the same consultant to complete it.

I know. But OP was looking for a locking mechanism. Locking mechanisms in general are notorious for creating workflow issues. Other posters already suggested that he procedural way is the better one. I agree but though it was plain fun to figure out some sort of locking. Your statement about the possible issues tells me I've succeeded