The yellow traffic lights in PFCG

[Former Member]

Hello security gurus,

would someone tell me why the best practices is that all authorization objects in PFCG should be maintained and get green? Are there some real reasons?

Seen from technical side, the authorization-check works fine, no matter if the field of a authorization objects are maintained with ' ' (with green traffic lights) or stay empty (with yellow traffic lights).

Thanks a lot!

Ying

[jurjen_heeck]

There is a difference between ' ' , the DUMMY value, and empty fields. I usually disable authorizations I do not want to maintain.

[Former Member]

Hello Ying,

All objects that are read into a role are there because they are proposed in SU24 (either by the standard SAP defaults, or because someone in your business has updated SU24 with customer specific values). This means that either SAP (SAP default values) or your business (customer specified values) believe that these objects are required in order for the transactions within your role to be executed* without encountering authorization errors.

Therefore it is logical that as long as your proposed objects are correct, then it is best practice to maintain all of the objects in the role.

* It may be that you do not use all of the functionality of some transactions, in which case some of the proposed objects might not be necessary. If this is the case, then it would be better to inactivate the objects you do not require, or perhaps update SU24 to remove the proposal of you feel you will never need those objects.

It may also be that some of the objects that you feel are not needed are actually required, but that the authority checks are not looking for a specific field value. To be safe, you could maintain the yellow fields with dummy values.

Or lastly, it may be that the objects you feel are not required are actually required, but that the objects are maintained in other roles assigned to the users. whilst this allows the user to pass the authority checks, it means that your roles do not work in isolation, which they should do.

[Former Member]

Hi Ying,

Practically, the real answer for your query is, we have three lights red,green and yellow.

1. Red - It is not a problem that the authorization objects are in inactive state and it is not consider in the user profile.

2. Green - If you provide a value to the relevant field of a particular object it is consider as an active object. Whenever a transaction is call the relevant authorization object has been checked which was assigned to the user profile ( Note : The relevant authorization object for a transaction is check by using the transaction code su24 )

3. Yellow - Confused one!!! lets us consider if you adding an authorization object P_ORGIN in role 1 and we leave the relevant auth field as empty ( only activity as * ) and in yellow state and it is assigned to the user called James.Later we will create an another role and we will add the same auth object to this role 2 and provide activity as R ( read only ) and provide some personal areas.

In that case SAP will work in combination. ( Please note that normally sap work in auth objects in combination but not in HR auth objects ). Here it take the activity field from role 1 and remaining from role 2. So it ends up in an error.

Whether we will leave the role as an yellow ?

Some times there is a requirement will raise, the user can able to access some sales area which he already have. In this case, already the role 1 which was assigned to the user have sales area and we will provide only the activity in the new role 2 so that the user can able to access in a combination way.

But as per the recommendation of SAP it is not advisable to leave the role as Yellow we need to create a role in active state or in inactive.we will create a separate role for this kind of scenario to satisfy the requirement. Since whenever the business extends we can't able to manage the roles and profile assignment.

let me know if you have any queries and appreciate me if it helps.

[Former Member]

Hi

"1. Red - It is not a problem that the authorization objects are in inactive state and it is not consider in the user profile"

As already stated, red = missing org level so they will cause problems if checked

Personnally, I deactivate incomplete (yellow) auth objects until testing provides the correct entries - I find open yellow auth objects confusing and start searching for bolt-on roles 🙂

Cheers

David

[paula_w_arnold]

Hello Ying

SAP considers the traffic lights to be one of the most important icons for authorization administration as they quickly give an overview of the maintenance status of the authorizations.

Green being that all fields have been filled in with values.

Yellow being that at least one field is empty (a non organizational level field)

Red being that at least one organizational level field is empty

As J. Heeck has already stated, the values ' ', DUMMY and empty do have different meanings to the system.

If you are not sure about the values needed, you can always inactivate the the authorization object to see if any authorization failures are reported during testing.  Or if there are no concerns about the authorization object, you can add * to the empty fields.  Either one of these options can be done with just a click.  It would be better to inactivate the authorization object instead of deleting it because otherwise the next time you update the role and go into it via Expert Mode for Profile Generation, it will pull in the deleted authorizaton objects again (unless you have also updated USOBT_C via SU24).

It is never a good idea to move roles that have yellow or red lights to production. This could cause an audit comment by your company auditors.

[Former Member]

First of all, thank you very much for all your replies!!!

It is no problem for me to maintain SU24 or inactive the authorization object which is not concerned by authorization check at all.

However, there are some authorization objects which include more than one field, some field are considered by the authorization check, some not.

In this situation, I can't just inactive the whole authoriaztion object and I am wondering, it is perfer to leave the field empty to make sure the user doesn't get no wanted authorizations (but yellow traffic lights) or give the field a value like '' to make the traffic light green? 

Regards!

Ying

[Former Member]

Hi Ying,

If you are confusion what need to be provide in that role, there is a better way to create a role. Take a DEV system and create a test user ID. Assign the profile SAP_ALL and SAP_NEW and enable the trace with the help of transaction code ST01.

You will provide the same to functional team and check the trace what are all the authorization is needed for that activity and which are is not needed and checked.

But as my experience i didn't come across a situation that one field is checked and other not in an authorization object.

Let me know if you have any queries and appreciate if it helps.

[jurjen_heeck]

In that case I'd go for the DUMMY value. It looks better in the profile (green traffic lights) and it does not give additional authorizations other than access to blank fields as far as I know.

[Former Member]

Hi,

But be sure no high access have been provided to that authorization object for dummy value. Since the role not matter of fact for present it is also we used for future even though some enhancement happens in our landscape. So after enhancement it may open some security issues.

let me know if you have any concern and appreciate if it helps.

[Former Member]

It is quite common for some fields to be checked and not others. If you read the trace files carefully you will see where this happens.

I personally do not like tracing users with wide authorisations, because the user you are tracing may make many typing errors, or may execute the transaction with the wrong inputs. You will then enter a lot of incorrect field values in your roles.

As has been stated above and below, it is preferable to inactivate (or dummy where some fields are checked) and let testing indicate the missing values for you.

[Former Member]

Hi Will,

I agree with that point we can't waste out man hours for this tracing. But my point is we may use trace for doubtful objects.

I also agree with dummy value but be sure with that value. Let me know if you have any concerns.

[Former Member]

It looks better in the profile (green traffic lights) 

I appricate your suggesstions. But I want to know if there is a better reason as "It looks better..."

Regards.

[jurjen_heeck]

It actually saves on maintenance efforts and costs. If I open a profile and I see yellow traffic lights I'll start an investigation to find out why they're there. That's also what I expect from any security administrator I work with. Looking good in this context means 'all is well, no maintenance needed here, next case'.

[Former Member]

Completely agree with you.

Useful is also "place holders" which have no meaning until real values are needed. These are better than open field as you can search for them and use a naming convention for maintaining open fields which determine whether they are destined for:

D = deactivation of the object is probably OK as optional and not used.

4 = SU24 will come later, such as S_DATASET

2 = Reported to SAP as it alsways makes sense

5 = Available in next SP so accept in SU25 (successfull SAP Note)

@ = Leave like this forever. It is a banana until needed.

JBU = Julius Bussche needs to provide infos otherwise we * it

' ', stupid = Some stupid clown hardcoded a space by including the field type.

""""""" = Extreme stupid check

*, ' ' = Double extreme stupid check

....  etc

This way you can at least mark the fields as any value is sufficient usually, you can search for values which you know you still have work to do on, and when you process SU25 at upgrades (if you stick around...) or read traces then you can easily see what needs to be transfered to the roles or SU24.

In most cases I just use '@' and 'JBU'.

Cheers,

Julius

ps: Some fields have input validations. So you cannot use bananas.

pps: Some fields are correctly open in SU24, you need to choose in the role.

ppps: Some bananas persuaded SAP to maintain ACTVT field for transactions such as SU01 and PFCG although they are also display capable - shame on them!