Question:
When adding a transaction to a Role why doesn't PFCG check before inserting the auths? Instead it brings in the authorization with the exact same field values that are already there. Why couldn't it simply read the USOB* tables to determine the objects and default values and then scan the Role to see if there is a match. Then if there was a match already in the role it could prompt you with a choice of keeping and inserting it or using the existing one. I could see a scenario where you would want to keep it and then change some or all of the field values.
Am I missing something here? I learned Auths pretty much on my own "on the job" and sometimes find I have missed something that would be fundemental to auths and if I had been formally trained I would know.
Answer:
A program can only do what it's programmed to do!
Answer:
This can be useful if you want, let's say, display an org code 1000 but have change permission on org code 2000.
But I agree, this is usually unnecessary and SAP just does it that way.
Snowy
Answer:
Can someone help me get comfortable with the Merge function? This appears to remedy the issue in a reactive way. After the fact. But I'm not sure what all the caveats of this function are.
Answer:
The merge function merges auths that have the same values.
Eg, V_VTTK_TDS with ACTVT 01, 03 and TPLST 3000
V_VTTK_TDS with ACTVT 02 and TPLST 3000
Would merge to V_VTTK_TDS with ACTVT 01, 02, 03 and TPLST 3000
But if the planning point was different they would not merge at all.
I don't merge my self that often as the SU24 table is so out of whack (until you fix it up yourself) that every time you go back into the role through "Read old status and merge with new data"
(which you should always do in DEV to kept the role current) it will bring in new auths that were merged before.
I think the original question is a good one, but if you made sure the SU24 table is has the correct values
this problem would not occur 95% of the time.
Cheers
Answer:
PFCG is working as designed and you have configured..
When you add a transaction code SAP does not look at what is in the role it compares the ORIGINAL values brought in before you added or changed anything and if it cannot find a match with the ORIGINAL Auth object values or if it feel that combining access with something that is present might leed to more access , it brings in the new authorization object.
SAP will always defer to the "less" access.
If you configue SU24 to be consistent Then SAP will "merge" when it needs to and do it correctly, IF it finds discrepencies it will always add. If you use the MERGE it will almost always bring in new auth objects when you add a tcode or perform a MERGE-olD and New.
Answer:
Ronbon,
If you merge or delete auths, the SU24 default values will be imported again the next time you make a change. If you inactivate those auths they will not be imported again. That is what we do. Perform a merge and generate the profile. Go back out, do "read old status and merge with new data". Anything with a "new" status is a candidate to be inactivated. Now the next time you add a new transaction to a role you'll know the new auths came from the transaction you added and not for other reasons (previous merge, etc.).
Answer:
So the concept here is using SU24 to associate authorization objects and values we decide on, with the transaction. Then PFCG is going to seem like it is making work for us but in reality it is helping remind us ""THIS IS WHAT YOU HAVE SET UP IN SU24 TO BE ASSOCIATED WITH THIS TRANSACTION" And we can compare it (NEW) to the OLD set of authorizations and determine if we were correct in having changed the OLD authorization in the past. Most people will not know the answer to this, but what if we notice that there is a * in S_DEVELOP and that our NEW instance of S_DEVELOP is suggesting 03. We can then be prompted to consider the wisdom of * in this instance. The purpose of PFCG is to REMIND you what you have determined to be logical, safe and secure authorizations, If you let PFCG skip this step and read the current state of your profile then you are missing the value of PFCG. You would be allowing PFCG to be over ridden by some previous configuration of the profile that someone might have messed up. What if they assigned * to S_* objects and should not have. PFCG if it did what you suggested would not bring in another instance of the S_* object with lesser values. And so you would not notice the glaring discrepancies. Or, even if it did bring in another instance of the exact object and value, at least you know what should be there. PFCG is not an automatic security configurator. And if anyone thinks it is, then they are going to have problems passing audits.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
Reply to John, et al,
Maybe I should explain further...
What I was referring to was when adding a transaction that brings in an object containing empty fields to be maintained.
We have some occassions where the vaules will be different for nearly every user.
My thought was why can't SAP look at the existing values in the existing object and at least ask(prompt) you to except the existing values or insert the object again and maintain a different set of values? Remember SU24 would be useless in this case because nearly every user requires different values. Setting SU24 defaults is virtually useless.
The rule could be written something like this:
If inserting object are all fields maintained?
Yes -> Insert object
No -> Scan role for existence of object?
--------------->No -> Insert object -> Maintain Values
--------------->Yes -> Prompt user for use of existing values?
------------------------>No -> Insert object -> Maintain Values
------------------------>Yes -> Do nothing, no insert.
They are already doing some of this because if the vaules are the same in SU24 and the role it will not bring in another. So why can't they just modify their program to include another check?
I know that is basically a rhetorical question but I just have to ask it.
Anyone know if there is a user exit or some other hook into the PFCG programs where we could add this check?
I see this as two different methods:
1. "Global" -> Use SU24 to maintain values for the entire system. Every role will use these same values.
2. "User" -> Leave SU24 values blank and prompt at the time of insertion.
This would allow you to add and maintain the object once per role. Once it is maintained you can skip it for each supsequent transaction selection.
I think both would be useful.
Answer:
Can someone put it in simple terms for me.
Here is what happens to me:
1. Role with 8 of the same object.
2. Add transaction
3. Read and merge
4. Role with 9 of the same object.
5. Merge authorizations (or do some deletions)
6. Role with 1 object.
Now the next time I add a transaction and read and merge all 9 authorizations are back.
How can I stop the madness!
Answer:
PFCG will always use the list of transactions in the auth objects associated from the USB* tables and repopulate the list again. you have to select the EXPERT maintenance option when you are going into the change mode of the auth tab. Expert as in (ok you know what you want cause your like and expert or something and I am not going to pull in the objects that are related to the transactions, your on your own buddy but dont come crying to me if you are missing and object) mode.
I use it all the time. This will just skip the pull in of the objects and give you what you already have maintained in the role with all the lights green becuase nothing was changed or suggested. Except the new Transaction you might have added in the S_TCODE list. So next time add the transaction then when you navigate to the authorization tab, dont forget to to use the EXPERT* (whatever)* radio button in the dialogue box that pops up.
_________________
Gary Morris
SAP Security Analyst/Developer
garymorris@sapsecurity.net
Answer:
I do a merge and reorganize everytime I change a role. It just seems to keep memory consumption down to a minimum. Some roles, like R/3 roles, can really get big.