Two user with same profile and role having different authorization

[Former Member]

Dear All,

I have very strange case of authorization . We have a new abap developer in our company . Her profile as copied from an exiting abap developer's profile in Development system. But she don't have authorization for lot of transaction that the existing user have. I checked the profile tabs , role tabs . then done the user compare for all the roles , but of no use.

I did a compare of the two uses using S_BCE_68001430 and could see is that the existing abap user is having authorization starting with T_PXXXXXXXX that is giving him extra rights. These authorization is not present in any of the existing role he is assigned to (checked using S_BCE_68001396). The authirsaction in the roles start with T-DXXXXXXXX

Will appreciate if any one can give any input . The problem is i need to assign each authorisation the existing user having manually to the new user.

regards

Tony

[jurjen_heeck]

In the role tab, is there anything in the field "Reference User for Additional Rights" for the existing user?

[Former Member]

Strange. Are you always running PFUD?

Otherwise check table USR04 or anything strange and compare it to the entries in UST04 for this 1st developer and the 2nd developer.

Cheers,

Julius

[Former Member]

Thanks for the mail.

I check the "Reference User for Additional Rights" -- there is no refernce user assgined.

I checked the table USR04 the no. of Profle for the two users are diffrent and in the table UST04 also the the existing uer is having addtional profiles.

I like to add one more point Some of the roles of the two users are composite roles and both the composite and its orignial roles are included the profile of both users.

Does any one have idea of the authorisations starting with T_PXXXXXXXX

regards

tony

MANDT BNAME PROFILE

100 CHARLHO B_LSMW_ALL

100 CHARLHO T-D1780054

100 CHARLHO T-D1780057

100 CHARLHO T-D1780058

100 CHARLHO T-D17800581

100 CHARLHO T-D1780075

100 CHARLHO T-D17800751

100 CHARLHO T-D1780086

100 CHARLHO T-D17800861

100 CHARLHO T-D17800862

100 CHARLHO T-D17800863

100 CHARLHO T-D17800864

100 CHARLHO T-D1780087

100 CHARLHO T-D1780088

100 CHARLHO T-D1780247

100 CHARLHO T-D1780304

100 CHARLHO T-D1781182

100 CHARLHO T_P0920411

100 CHARLHO T_P09204111

100 CHARLHO T_P092041110

100 CHARLHO T_P09204112

100 CHARLHO T_P09204113

100 CHARLHO T_P09204114

100 CHARLHO T_P09204115

100 CHARLHO T_P09204116

100 CHARLHO T_P09204117

100 CHARLHO T_P09204118

100 CHARLHO T_P09204119

100 TESTUSER2 B_LSMW_ALL

100 TESTUSER2 T-D1780054

100 TESTUSER2 T-D1780057

100 TESTUSER2 T-D1780058

100 TESTUSER2 T-D17800581

100 TESTUSER2 T-D1780075

100 TESTUSER2 T-D17800751

100 TESTUSER2 T-D1780086

100 TESTUSER2 T-D17800861

100 TESTUSER2 T-D17800862

100 TESTUSER2 T-D17800863

100 TESTUSER2 T-D17800864

100 TESTUSER2 T-D1780087

100 TESTUSER2 T-D1780088

100 TESTUSER2 T-D1780247

100 TESTUSER2 T-D1780304

100 TESTUSER2 T-D1781182

[Former Member]

With LSMW anything can happen...

Please ask a developer to go to SE37 and run the function module SUSR_SYNC_USER_TABLES with the table type = 'X'. If you can still start transaction SUIM_OLD, then it will do the same.

=> This looks like "orphaned data" from migrating another production system client. Check in UST12 as well - the authorizations should be meaningless.

Cheers,

Julius

[Former Member]

The authorisation startong with T_PXXXXXXXX where orphened once.