Material Type - Authorization Group - Not working

[Former Member]

Hello,

For all of the postings I've read, it seems like if we want to restrict a user from creating or changing a certain material type (MM01/MM02), we can use the authorization group field in the material type configuration (OMS2)

I made this change last week in our system, and when I attempted to create a ZMRO material type via MM01- it basically wont allow me to (the material type field would actually change to a different material type).

However, this week, I am now able to create a ZMRO material type.... I  rechecked the config, and also checked all of the roles I have (pfcg) and made sure any that has MM01 tied to it not have ZMRO listed in the authorization group, and I also had another user attempt to create a ZMRO material type and they are able too.

I then used a different material type, and added something in the authorization group field for that.... Same result ( I can still create that material type)...

Is there another place I need to check to see why the authorization group check isnt happening now, or any ideas as to why suddenly it may not be working?

[Former Member]

Hi,

Why not you put the trace and check the same for that user id by using t-code ST01.

[Former Member]

I tried this (all though I normally dont setup traces) .... I dont see anything that is telling me anything except BEGRU = ZMRO (material type)... My authorization group listed is " * " ... My assumption would be I should only be able to create a ZMRO material type if ZMRO was listed under the authorization group (since thats why I listed in the authorization group in the material type configuration)

Can you make out anything from the results...? 

(note - if you click on screen shot is should get bigger for better visablity)

[Former Member]

Hi James,

The above trace shows that you can able to edit the ZMRO material type rite ?

So what you need to be do ? can you explain little bit clearly

[Former Member]

Hi James,

Answer for your query ,

The M_MATE_MAR authorization object is checked in the MM01/MM02/MM03 transactions.  However, SAP will only do the authorization check for a material which has an Authorization Group assigned in table T134 (configurable in SPRO txn OMS2). Table T134 defines material types (T134-MTART) and the related authorization group (T134-BEGRU).   If an authorization group is assigned for your material type 'ZABC' in T134, and the user has authorization for that auth group, the auth check will be successful. 

You cannot assign an authorization group just to material type 'ZABC' and ignore the other material types.  If you do, a user authorized for MTART='ZABC' can also create materials with all the other material types because for those materials (which have no authorization group), no authorization check will be done when the user attempts to create/change/display those materials.  I believe you must assign auth groups to all material types in T134 and assign the M_MATE_MAR auth object to all users with appropriate authorization levels.

Hope this helps.

[Former Member]

Thanks for your reply...

I've read in a few other places on this topic, in which they dont mention thi T134 assignment... It seems like a big effort to go through all material types and change them etc.... I thought, based on what I read, that by entering an authorization group in the material type, that the check would only go to that material type (so no one could create it)

All we need is to

1) Restrict all users from being able to create a material type "ZABC" through mm01 and mm02

2) Create a new role which will allow a user to create a ZABC material type via mm01 and mm02...

What is the best approach for that?

http://sapsecurityguide.com/security/restrict-material-type-creation-and-change-in-mm01-and-mm02/

http://scn.sap.com/thread/1729357

[Former Member]

Also - for your T134 comment - this has been done from the very beginning - (see my screen shot in the first posting).

I maintained a value in that table, and when I went to MM01 it wouldnt let me create that material type... Now suddenly, its not working and I have no idea why or where to start etc...

[Former Member]

Hi James,

Yes the point of assigin the authorization group is more better than other value maintain like T134.So that we can avoid the user to create the same for thier own.

Thanks for sharing too...............

Cheers,

Simbhu

[Former Member]

Sorry - I didnt get what you're saying there...     I'm still unclear as to why when assigning the value in OMS2 ( which is config table T134) , user can still create that particular material type... I have no issues with them being able to create any other material type, but want to restrict the one I've mentioned above, and then create a new authorization which will allow the creation that material type (assigning that value, which matches the same value in OMS2, in PFCG)

[Former Member]

Hi James,

I am making the assumption that config screen from above and the trace are from the same system & that the config is current.  You can see from the trace that the check on auth group is being performed (last line on the second block).  It has an RC=0 which is the check being satisfied so first thing to check is that the user isn't picking up the auths from somewhere else (use SU56 to view the user auth buffer & search for the instances of M_MATE_MAR).  Second thing is to check in SU24 to see if the auth check hasn't been disabled for M_MATE_MAR on MM01.

I have seen occasions where on creation of records the auth group can be entered without any problems (even when not authorised) but I don't think this applies in this instance.

Let us know how you get on.

Cheers

[Former Member]

Hi James,

As for as my concern is if we missed any of the material type to configure in the OSM2 the user can make it advantage can also create materials with all the other material types because for those materials (which have no authorization group), no authorization check will be done when the user attempts to create/change/display those materials.

So as per your point we need to check all the material type and assign in a authorization group to avoid errors.

For your issue, you said that the ZMRO is come under ZMRO authorization group and the trace shows that you have authorization to edit this. In the begining some might be change the config in the table.

Cheers,

Simbhu

[Former Member]

Hi James,

Added to this i found this one in net, which i tested and true

there is a subtle difference in M_MATE_MAR and M_MATE_MAT,

If we consider FInished goods as a Group of products that are "ready for sale" and if this is considered as group FGRP

you could also seggregation on materials that are finished products but have different attributes (it could be size, pattern or any other differences) - these are defined as material types. But these material types are still a sub set of the Finsihed Goods group

you can also have material groups created based on similar material attributes (all products that have a similar design pattern can be one material group, and this material group can be applicable to different group of products, this means a material group can belong to not only FGRP but also to FXXX)

Now, M_MATE_MAR will restrict on the material type you created (ZNBW)

M_MATE_MAT would restrict on the product group under which you have the material type and M_MATE_WRG will restrict on the material group in which you prefer to have this material type

Hope this also helps

[Former Member]

Hi Alex,

Thanks for your reply...

1) Yes that configuration and system trace was done in same system. 

2) SU56  - Note - all items/roles have the same value of * in authorization group except the first one listed which has PROD

3) SU24 - looks like check is on for MM01/MM02

[Former Member]

Hi Silam,

This is the same information which I provided in the link in my earlier post

http://scn.sap.com/thread/1729357

I'm not sure how that helps me in this situation, but if you could explain that would be great...

[Former Member]

Hi James, thanks for the screens.

Your problem is that the ID you are using has multiple instances of M_MATE_MAR which have * in auth group and the relevant activities (e.g. ACTVT=01, BEGRU=*).

By adding the auth group against the material type you are effectively switching on the auth check however the user also has the auths to pass the check by virtue of the combination of authorisations from the different role assignments under that user ID.  SAP doesn't care which role assigned to the user that it gets the authorisation from.

If you were to create a new user with only a role containing MM01 and an incorrect auth group (or none at all) then they would not be able to create a material with the protected auth group.

This (authorisation inheritance) is a common occurrance and your only remedy is to restrict the other roles which grant this access through that user ID.  The more roles assigned to a user, the more likely this is to happen.

I hope that helps.

Cheers

Alex

@ Silambharasan - it's generally good form to link to the referring source to avoid any misunderstanding.

[Former Member]

For this same reason any use of BEGRU type fields (authorization groups) will sooner of later create a headache and "base roles" will be * for them. Certainly it is not scalable.

A much better option is to consider security in the standard org level options and challenge silly master data level optional controls. I have never seen it work at a large scale for long enough to be able to conclude that it survived and was worth the effort.

Personally I set the benchmark at 1 exception which is industry related and preferably not an org field, and, one field which cannot be promoted to an org field but restrictions are needed (typically "type" fields in CO, PC, PS etc  where you can also automate the whole generation and most assignments via IdM rules anway).

@ James: You should not try to restrict the number of roles in the system. You should try to restrict the number of roles assigned to the users and make their search for a job role intuitive.

Cheers,

Julius

[Former Member]

Thanks Alex - that was the issue.... There is no exclusion to the authorization group, only includes... I had to configure authorization groups for all material types, and then in the material type authorization object, I had to assign all of the material type authorization groups I configured except the one I didnt want to use.

[Former Member]

Julius von dem Bussche wrote:
For this same reason any use of BEGRU type fields (authorization groups) will sooner of later create a headache and "base roles" will be * for them. Certainly it is not scalable.
A much better option is to consider security in the standard org level options and challenge silly master data level optional controls. I have never seen it work at a large scale for long enough to be able to conclude that it survived and was worth the effort.
Personally I set the benchmark at 1 exception which is industry related and preferably not an org field, and, one field which cannot be promoted to an org field but restrictions are needed (typically "type" fields in CO, PC, PS etc  where you can also automate the whole generation and most assignments via IdM rules anway).
@ James: You should not try to restrict the number of roles in the system. You should try to restrict the number of roles assigned to the users and make their search for a job role intuitive.
Cheers,
Julius

I can comfortably say that although a bit of a pain BEGRU, if designed properly and not reactive, is a perfectly usable and scale solution to some problems.  As a default position I would always avoid but use it with care (and don't be created to create $BEGRU 😉 ) then it is a useful tool in the armoury.

Cheers

A