Authorization check failed Auth. Obj. M_MSEG_LGO Goods Movements

[Former Member]

Hello security team.

We are using two roles for one authorization object to be checked in the MIRO transaction. One role (1) checks the S_TCODE and the authorization object M_MSEG_LGO for ACTVT and BWART fields. The other role (2) checks for the same authorization object M_MSEG_LGO for LGORT and WERKS fields. I mean that the complementary effect between the two profiles attached to one and only user and employing the same authorization object M_MSEG_LGO could satisfy the return code SY-SUBRC = 0.

I have the detailed error message in a file. Please let me know if the issue is clear enough.

Best Regards,

Victor Sarabia

Edited by: Victor Sarabia Rangel on Mar 16, 2010 2:16 PM

[sdipanjan]

I must say this is very strange to see such a separation of Authorization Fields of same authorization object in two different roles. Please do not follow this and maintain all fields in only role for a particular Object. What you can do is to separate the maintenance of Organization Level fields in different roles iff you are using Master - Derive role concept.

I am very eager to know the reason of such kind of usage of authorization fields.

Regards,

Dipanjan

[Former Member]

Hallo Dipanjam, do not misunderstand me, I am not separating the authorization object. I intend to obtain the complementary effect with the same object in two different roles due the bolt-on role design that we implemented last year in the firma.

Best regards,

Victor Sarabia.

[sdipanjan]

Please do not maintain a particular Object for a particular TCode in two different roles by separating the maintenance activity for the Fields of that Object. It's not at all at per the process.

regards,

Dipanjan

[Former Member]

Dear Dipanjam.

Last year we made use of the proposed bolt on concept of Raghu Boddu. And worked fine.

Please follow this link

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/506d3329-630c-2b10-31a7-82ab4e478...

[Former Member]

> I intend to obtain the complementary effect with the same object in two different roles due the bolt-on role design that we implemented last year in the firma.

There is a big difference between data used to build a role when designing it (also with bolt-on tools) and the actual generated profiles and authorizations themselves which the system needs at runtime.

It is easy to make mistakes and there are no released APIs to do it directly into the role data of PFCG and subsequent generation.

Believe me I have looked long and hard, and there is none which I would with a good conscience recommend to a customer. Even the GRC suite's Enterprize Role Management component suffers from the same fate.

Cheers,

Julius

[Former Member]

I remember some flamewars in the past about this bolt-on topic and it's predecesor.

SAP also has its own tool which is along similar lines addressing similar issues: The "Role Generator".

Each to their own devices and all the consequences. At runtime there are only 3 key fields to work with (USER, OBJECT, AUTHORIZATION (instance)), and that is that...

Cheers,

Julius

[Former Member]

I must say, I never read that paper before 8=) - if I were to follow that naming convention, I'd be lost within 1 week with my CUA's that have children with several clients which have exactly the same roles - plus: since we use positioned based roles, I'd have several roles (separated by transaction type - of all things!) per position, where I always understood the philosophy here to be: one role per position, describing the position in all its glory and detail ... but I am derailing this topic!

M_MSEG_LGO: Victor, what exactly do you think you can achieve by spreading that object over more than one role? Can you describe the business process behind that?

[Former Member]

Hello Victor,

Gone thorough the link you provided that to Ragu regarding Bolt on ...

This is only help under certain scenario not everywhere.., could you pste the error or you requirement to be more clear and provide you approprite solution or would you let us know your business requiremnt ..

As i do not see any magic solution is provided by Bolton when it come to controls in security.

Thanks,

Prasant K paichha

[Former Member]

Hello Prasant and Julius.

When you enter a goods movement using transaction MIGO I use the movement type values for a good movement. vgr. movement type 987 - Init. entry of state balance or movement types 101,102 GR goods receipt & GR PO reversal BWART field from the authorization object M_MSEG_LGO. We gather the movement type values into groups that represents the structural basis that distinguish between , for example: Goods Receipt with Outbound delivery or Place in Storage with Material Document .

-

---

Authorization profile 1 for Outbound Delivery with transaction MIRO.

S_TCODE: MIRO

M_MSEG_LGO: Inactive

Authorizat. T-C161126200

Profl. T-C1611262

Role MM_AL_OPERACION_ENTRADAS MMA_GRC: OPERACIONES ALMACENES

-

---

Authorization profile 2 Bolton

M_MSEG_LGO maintained

Authorizat. T-C161137500

Profl. T-C1611375

Role NIVORG_ALMACENENTRADAS_4515 BOLTON: PLANT ORG LEVEL

Authorization Field ACTVT Activity

01, 02, 03

Authorization Field BWART Movement Type (Inventory Management) 101, 102, 103, 104, 105, 122, 123, 543, 544, 901, 902, 903, 904, 905, 906, 915, 916, 925, 926, 947, 948, 979, 980, 981, 982, 987, 988, DMS, RMS

Authorization Field LGORT Storage location

1000-1100, 1071, 1CBE, 2000, 3000, 3500, 4000, 5000, 6000, 7000, REHA, T000

Authorization Field WERKS Plant

4013-4019

-

---

Profile 1: transaction_code MIRO binds with Profile 2: M_MSEG_LGO, movement type 987 and Authorization Field WERKS Plant 4013 and Storage Location 3000 to satisfy the return code SY-SUBRC = 0 for Goods recepit&Oubound Delivery position in the organization

The binding between master profile 1 and the bolton profiles 2,3,4u2026u2026.n results in an organized role framework and greater specificity for handling different positions in the organization.

Thank you.

Victor Sarabia

[Former Member]

One can immediately see that you have lost the connection between the menu of the role (to start the transaction) and the authorizations needed to use it (specificity of re-usable proposals). Yet the object in profile 2 was still pulled from somewhere:

> M_MSEG_LGO maintained

Where is the " maintained " coming from?

Sure, you can even go back to using SU03 and then manually building profiles in SU02 if you want to but you will be increasingly on your own.

Cheers,

Julius

[Former Member]

>

> The  binding between master profile 1 and the bolton profiles 2,3,4u2026u2026.n  results  in an  organized role framework and greater specificity for handling different positions in the organization.
> 
> Thank you.
> Victor Sarabia

Around 90% of implementations I have audited using the bolt on principle have had significant deficiencies in their ability to provide access in a secure manner. The bolt on/value principle can be used very effectively in some situations but cause chaos if not controlled properly.

The article by Raghu uses a very specific scenario to illustrate how bolt on's can help. That is a very particular specific scenario where it is common to use this approach for release codes/strategies. The Purch Org info is stored in 1 auth object, the release strategy is in another. By modularising them, you can assign in a flexible manner. This is absolutely not supported if you are looking to achieve a similar split between authorisation fields in a single auth object.

You are getting the problem because in this case your design breaks a basic principle of SAP authorisations. An authorisation is an instance of an auth object + it's values. Each authorisation is evaluated for a check. As others have said if you are splitting activities from org levels that reside within a single auth object then you will never be passing the full data into the check and as expected, it will fail.

It is exactly for this type of reasons that these deviations from standard must be very, very carefully evaluated and understood before designing using this method. If you are the originating designer and are struggling, pay some thought to the people who will have to support this. As much as I hate this method of design, I have to say that it is good business to be paid to clean it up when it (more often than not) goes wrong.

[Former Member]

>

> The article by Raghu uses a very specific scenario to illustrate how bolt on's can help.  That is a very particular specific scenario where it is common to use this approach for release codes/strategies.  

This.

I have been contacting Kristian Lehment via E-Mail to have this 'paper' withdrawn from SDN, giving him these very reasons - the area of SAP-solutions where the recommendations of that 'paper' could be sufficient, is incredibly small and rapidly diminishing to nothing. Kristian agrees.

I am going to make a nuisance of myself for the second time in as many days, but I say: with goods movements especially this design is not a good idea. Sooner or later you will struggle with it and maintenance of this construct will take more time = cost your customer more money! Consider re-designing it - advise your customer accordingly - it will ultimately benefit him.

[Former Member]

Thank you. I would like to thank everybody who read or posted any comments, It was very helpful to read so many valuable recommendations from the experts to the issue.

Best Regards,

Victor Sarabia Rangel

[Former Member]

Dear Victor,

Could you explain the Bolt-on Method.I was confused i the above thread, splitting of a single auth. object in 2 roles , has not been mentioned