How to compare the Roles

How to compare the roles where created or defined in two different systems?

For role comparision both the roles must be in the same system, in same client

Transaction code SUIM -> Comparision-> Roles

If the roles are in different system, then tranport the role into one of the system and do comparision. If no transport connection defined then, you can use the upload and download option in the PFCG

Steps for Role Comparing:

1. Run the t-code SUIM

2. Go To Comparison and select the option of roles

3. Click on Across systems option it will give option to select the sys name under Remote Comparison there enter the SYS ID between which system you want to do comparison and put the role name in compare role section then execute it will give you the result.

4. If there is any difference b/wn the t-codes it will b in red colour otherwisein yellow.

Query About tcode PFCG
1. How to check the name of all users who has been authorised to use a particular transaction? I am trying to find through SUIM, but failing to find the name or total number of users of a particular t-code say SPRO.

2. I know that a particular transaction say SPRO is available in a particular role and I want to remove that t-code from that role. But I am unable to find that node through PFCG. If I am using the search for a t-code inside menu tab after putting the edit mode it is not coming in PFCG, but through SUIM its existence is coming in that role. That particular role contains a lot of t-code and reports, say about 2000.

1. Goto SUIM and select USER node, then select USERS BY COMPLEX SELECTION CRITERIA node then execute BY TRANSACTION AUTHORIZATION report then give the Tran. code and it will return you the number of users having that trans with relevatn details.

Follows these steps :-

- Go to SUIM .
- Choose Roles --> By Transaction assignment.
- Enter Transaction : "SPRO"
- Choose execute.
- Double click on a role in which you want to remove "SPRO" authorisation.
- Click on pen mark to change into change mode.
- Go to tab "Authorization"
- Choose change authorization data.
- Choose Utilities --> Technical names on .
- Choose --> cross application authorization objects-->
- Expand the selection for Object "s_tcode" , under the corresponding profile look the values maintained for "TCD" and remove value "SPRO" from the list to eliminate the authorization.
- Don't forget to regenerate profiles.

2. You should able to find this via menu tab otherwise try to do this in authorization tab --> change authorization data by search.

Sap Profile Generator Tables
---Original Message-----
Subject: Profile Generator tables?
From: Paul Ellis

We maintain profiles in a Development system using Profile Generator, but only transport the authorisation profile and not the activity group to Staging/Production.

We are about to refresh the Development system with a copy of Production. What tables do I need to export from Development prior to the refresh, and later re-import, to ensure that Profile Generator is able to maintain the activity groups created in Development?

Thanks in advance.

Paul Ellis

-----Reply Message-----
Subject: Re: Profile Generator tables? - more
From: Mike O'Carroll

oh, and maybe these tables for profile genrator stuff......
(from top include for PFCG)
000010 function-pool rhum.
000020
000030 tables: hrv1220, hrp1001, hrp1000.
000040 tables: pchdy, pphdx, p1000,
000050 pt1220, t77fc, t77fd.
000060 tables: *objec, objec, *p1000.
000070 tables: pdrhum, t77aw, t777o.
000080 tables: xu213.
000090 tables: t777e, usr05, tprprof.

and you may need to do the same with menu tables - I'm not sure which ones
-
(from top include from SSM1)
000010 function-pool smnu. "MESSAGE-ID ...
000020 *
000030 tables: indx, tstct, dsyax,
000040 smenca_new, smen_obnew, smen_conew,
000050 smenusenew, smenentnew,
000060 smen_dates, ssm_stat, ssm_start, ssm_langu,
000070 smensapt, smencust, smenentt,
000080 smensapnew, smencusnew,
000090 smenselect, t002t,
000100 ssm_rele, smenintnew, smenintt.

--------------------------------------------------------------------------------

Regards,
Mike O'Carroll

-----Reply Message-----
Subject: Re: Profile Generator tables? (Document link: Michael O'Carroll)
From: Michael O'Carroll/UK

user masters: USR01 to 09, UST04,
profiles: USR10, USR11, UST10S, UST10C,
authorisations: USR12, USR13, UST12.
password exceptions USR40.
History tables(may not be applicable but FYI): users: USH02, USH04,
profiles: USH10, auths USH12.

activity groups are stored in table PLOGI along with loads of other object types. the activity groups are object type T.
You could export the table data with a manual transport request via SE01, using R3TR TABU and specify the keys to use for all objects of type T(ie all activity groups). Remember to include all clients in the selection.

OR, if you are using the client copy functions to refresh you DEV from PROD, then you could use the RSCCEXCT (see OSS note 70290) to list all these tables and exclude them from the copy, hence the corresponding original DEV tables should not be overwritten in DEV.
I suggest you export a transport request with with all these tables from DEV just in case, so you can re-import them again if it goes pear shaped.
In 3.x I don't think the activity group names involve client number or SID, but I've heard some differences in 4.6 - Guy Holchester has sent many notes to the list about it - have a look at the archives, but I think as long as you aren't copying between different versions (eg from Prod 4.6 to Dev 3.x, or vice versa) then it should be OK.

If you choose to re-import the tables from transport requests, you might want to run the sync tool in the target client (DEV) afterwards - ie run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any dodgy links or inconsistencies.

Also, if you are re-importing user masters too, run RSSODELT and RSSOUSER to recreate all SAPOffice mailboxes and link them to the new user IDs in the target client.

hope this helps.
cheers,
Mike

-----Reply Message-----
Subject: Re: Profile Generator tables?
From: Kenneth Marquardt

I would use RHMOVE30 and create a transport of your activity groups. To be safe test import the activity groups to QAS prior to refreshing DEV with PRD. Then once you have completed the refresh import the transport you created. For more info on this look at the Authorization is made easy guide available online on page 11-6 release 4.0b.

Remember to run SUPC after you import to regenerate the profiles.

-----End of Reply Message-----

How to check missing authorizations for user
How to check the missing authorisation for the user not having the option "/nsu53 ?"

You can use the following procedures to determine which authorizations a user requires to carry out a transaction:

You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing.

Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked.

This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check.

Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior.

Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts.

Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).