Impact of Changing User Types

[former_member452198]

What is the impact of changing user types from 'service' user type to either a 'communication' or 'system' user type? Will the change stop authorizations or will it only affect administration? Is the change related to the available fields or locking security and not necessarily related to authorizations.

[Former Member]

It will not change the authorization the users has, however, the Service user is a Dialog user, so if you change it to System or communication, the ID will not be able to login through SAP GUI.

Why do you want to change the user type ?

Refer the types of user to have a clear idea.

http://help.sap.com/saphelp_nw04/helpdata/en/3d/3272396ace5534e10000000a11405a/content.htm

Cheers !!

Zaheer

[former_member452198]

Auditor has identified the service user type's ability to run as a dialog user as a risk.

[Former Member]

What was the purpose of those IDs ?

Just changing the user type, becasue auditor's didn't liked them, is not a good idea. (action though)

If no one is using is you should better end data / inactivate these IDs and delete them later on.

Cheers !!

Zaheer

[Former Member]

>

> What was the purpose of those IDs ?
> 

That is the important question.

If the user type and their authorizations are correct, then they don't need any S_TCODE authority.

Their entry points are S_RFC and S_SERVICE...

However, if the processing of the received data is automated anyway in the background... then there is no benefit in my opinion from seperating the authority in a correctly configured system.

More important is to get the cardinality of the connections right for the users (1 system : 1 client side business or technology scenario : 1 server side user context) and their user types. That is a prerequisite for restricting their authority, if you want to differentiate between users and user types and integration scenarios.

Cheers,

Julius

Edited by: Julius Bussche on Apr 9, 2009 10:51 PM

[Former Member]

Which release are you on?

It also depends on your config => rejecting expired passwords, compliance with current password policies (at logon...) and same user context for RFC calls.

You should first investigate why it is a "SERVICE" type user. If it is from a config wizard with a profile delivered by SAP, then there might be a good reason for this.

The authority checks on "SERVICE" and "SYSTEM" users are the same, except that "SYSTEM" users are not SAPGui capable. This is not only restricted to the SAPGui logon screen. And for all logon types, they are excempted from changing their password - both via the requirement to do so and the ability to do it voluntarily...

But if they can administrate themselves, then they can (authorization object S_USER_GRP).

The same cannot be said for "COMMUNICATION" type users. I recommend not using them at all and there are many SAP notes which correct standard config wizards to use the correct user type => SYSTEM.

"COMMUNICATION" users are "DIALOG" users, except that when you enter the correct password via the SAPGui logon screen, then a message is returned to inform you that the user type cannot logon from that screen. But other screens will work, if the first screen is skipped.

You can test this with transaction OBVU in the standard system, or any other Z-transaction of the same ilk.

Cheers,

Julius

[sdipanjan]

Before you question like this, you need to understand why SAP has come up with these 5 types of users. As Zaheer told, the purpose of each user types. If you are aware of these, then I hope you would not like to change the user types (except Dialog to Reference in special case - suppose one of your employee (suppose A) resigns and you didn't get someone who will be able to handle that Job perfectly. Still someone (suppose B) need to perform his Job. So you change the user type A to reference and assign to B in SU01 in Reference user field. B will be able to perform the actions of A without having Roles of A in the Role tab).

There are certain limitation as per licensing rules of SAP for communication and system user types.

Regards,

Dipanjan