Profiles created with SU02 and transporting them

[Former Member]

We have a lot of profiles that were created with SU02.

When I change them in our Development system and then create a transport and move the transport to our quality system and our production system the changes do not get updated.

I manually go to each system with SU02 and make the changes again and activate them.

Is there another way or am I missing something.

Thanks

Joe

[Former Member]

>

> We have a lot of profiles that were created with SU02.
> When I change them in our Development system and then create a transport and move the transport to our quality system and our production system the changes do not get updated.
> I manually go to each system with SU02 and make the changes again and activate them.
> 
> Is there another way or am I missing something.
> 
> Thanks
> Joe

Use PFCG and transport the security role instead.

[Former Member]

There are no roles associated with profiles that were created with SU02

thanks

Joe

[Former Member]

You can convert them though. See transaction SU25 step 6.

Cheers,

Julius

[sdipanjan]

what is the version of your system?

[Former Member]

We're currently on 4.6c.

But they were created under 3.1H before my time.

Thanks

Joe

[sdipanjan]

Ok. You should convert them to role by using SU25 (as mention by Julius already). Because SAP has stopped supporting such ancient things. Also you probably need an Upgrade in very near future as 4.* are going to be obsolete from SAP support cycle. It's more convenient, scalable, easy to administer and above all more secure to maintain from SOD point of view now-a-days.

This is the only suggestion I can give from my point of view.

Regards,

Dipanjan

[Former Member]

Actually Su02 is still quite popular in BW systems...

In higher releases, you can now also use "Authorization Defaults" to maintain authorizations via SU24. This means that you are no longer limited to menu transactions, but can also use other object types which are visible (or not) in the menu to propose authorization data from.

The advantage is that it is clearer why the authorization is in the role, and the consideration of removing or changing it can easily (relatively speaking... be tracked down to the functionality which will be impacted by the change.

The alternative is to change a manual authorization, and go looking on the file server for the project documentation or the telephone number of the consultant way back when in 3.0H...

Cheers,

Julius

[Former Member]

Julius,

I need your assistance on this point. I have run SU25 step 6 and all the auth profiles in my 3.1h system have been converted to corresponding roles.

Having done that without errors, I wanted to go in and validate that all the transaction ranges from the profiles have been properly converted, and am having some issues in reading the data that I've downloaded from the table. Here's a small example. The below rows are from table AGR_1251, filtered for field TCD. As you can see, the first item is the role name, the third item is an authorization, and so on. It appears to me that the transaction entries in the profile were converted to distinct objects per transaction, rather than being put into S_TCODE.

X:ACT:ALL____T-DC800001 1094 Z:MC40 T-DC80000100 TCD MC40

X:ACT:ALL____T-DC800001 1095 Z:MC41 T-DC80000100 TCD MC41

X:ACT:ALL____T-DC800001 1096 Z:MC42 T-DC80000100 TCD MC42

Basically, I haven't seen these types of entries before and wanted to know how you'd approach this step of the profile to role conversion.

Thanks,

Santosh

[Former Member]

I dont see the problem in the TCD field, at first...

Take a look in PFCG at S_TCODE if you are uncertain about single fields of tables - you should not be alone on this.

Example: enter S_TCODE into the object field as well and see what happens to TCD = xxxx.

To be honest, I have not seen such a botched concept as this in the wild before...

Cheers,

Julius

Edited by: Julius Bussche on Jun 30, 2010 10:11 PM

[Former Member]

Julius,

The TCD field isn't causing confusion. Look to the left at that Z:MC40 or whatever. That's the auth object, which has a field called TCD. In other words, there isn't S_TCODE with field TCD, there's this Z:MC40 or whatever, with field TCD and the tcode in that filed is MC40 or whatever.

Anyway, if I go through my data for S_TCODE, then I find that in the profile, it refers to the following. Note that these are the only two profiles in my UST10S table that refers to S_TCODE. I need to figure out how to reconstruct the rest of the profiles into roles so that the unlimited access in these profiles below can be removed and the balance of the profiles can be given relevant transactions.

X:TCODE   	S_TCODE	&_SAP_ALL
X:TCODE	        S_TCODE	S_TCD_ALL
X:TCODE	        S_TCODE	S_TCD_ANW
X:TCODE	        S_TCODE	S_TCD_BC
X:TCODE	        S_TCODE	S_TCD_CUST
X:TCODE:ALL	S_TCODE	&_SAP_ALL
X:TCODE:ALL	S_TCODE	S_TCD_ALL
X:TCODE:ALL	S_TCODE	S_TCD_ANW
X:TCODE:ALL	S_TCODE	S_TCD_BC
X:TCODE:ALL	S_TCODE	S_TCD_CUST

Edited by: Santosh Krishnan on Jun 30, 2010 1:23 PM

Edited by: Santosh Krishnan on Jun 30, 2010 1:24 PM

[Former Member]

Yep, I realized that. You are dealing with an authorization object per "TCD" and not just a field value...

That is not scalable and makes no sense.

How many Z-objects are there in SU21 (table TOBJ)?

I have used SU25 step 6 but am not aware of a manual authorizations concept which was worth keeping when converting to roles and SU24 proposals. You should end up throwing most of them away anyway, so rather try to use them as information value to build roles for groups of users, or "double-check" against for proposals when no one has a clue about what value might be needed, if at all.

If the concept was still slightly intact then composite profiles might be your best friend here for such Z-objects if it was used as a blunt tool in SE93 (table TCTCA) and they tried to rely on that.

Again, that is a plausibility check and not scalable.

Cheers,

Julius

Edited by: Julius Bussche on Jun 30, 2010 10:52 PM

[Former Member]

To your question, there are 51 entries.