User Type Communication

[chris_hall2]

We are currently reviewing the ID's that have been setup as Communication user type. What is the best way to complete an audit on these ID's. I need to identify the process they are related to and if they are still in use.

Thanks,

[Former Member]

That should be an easy audit...

--> Do not use Communication type users at all anymore. Use System type users only.

Cheers,

Julius

[chris_hall2]

Hi Julius, could you provide some background to your advise? Why should we stray from using communication id's?

[Former Member]

There are several reasons. The main ones are:

- They they can change their own passwords, so the client application in the exchange can be used for DoS attacks.

- They can issue logon tickets to the client, so the client application can use the target as a "stepping stone" to other systems.

- The authority-checks are slightly stricter for SYSTEM type users, so Communication users cannot be protected in the same way.

- Communication type users are not exempted from all of the (optional) password rules (validity, policy compliance) so will prevent you from using them.

In the security wiki there is infos for you on how to go about tracing, mapping and working out the "cardinality" of connections from and to your system (which was your real question).

Just do a search and feel welcome to contribute to the wiki if you have some good tips.

Cheers,

Julius

[Former Member]

Thanks Julius

I never really did understand the difference between those two apart from the password change.

And now I've forgotten where I live (new in - old out)... D'oh!

Kind regards

David

[sdipanjan]

> Thanks Julius

Me too!!

@David: You may not have seen the photo of Julius with his famous Hat but we all can say him..... "Hats off to you!!"

I would like to simplify one more difference of these two user types:

Communication type user is meant for SAP 's own usage .... like installation defaulted RFCs, background users for some SAP house keeping Jobs etc.

System type user id is a similar kind (not exactly) of user id for Customer 's own usage.

The exception is CUA where you should define the RFC users as Communication type (and from description of Julius it can be found why ALE environment seek for such things from security point of view).

Also there is a Licensing related dependencies exist for these two types. SAP would not charge for Comm. type (Barnherd need to confirm) but will charge for System types.

Regards,

Dipanjan

[Bernhard_SAP]

> The exception is CUA where you should define the RFC users as Communication type (and from description of Julius it can be found why ALE environment seek for such things from security point of view).

-->sorry, can't recommend this (think about password expiery...)

> Also there is a Licensing related dependencies exist for these two types.

--> sure? I thought non dialog users are not charged....(that is so in my 7.0 system....

b.rgds, Bernhard

[sdipanjan]

> > Also there is a Licensing related dependencies exist for these two types.

>

> --> sure? I thought non dialog users are not charged....(that is so in my 7.0 system....

>

Obviously I am not sure.. and so I mentioned that it would need confirmation from your end.

Regards,

Dipanjan

[Former Member]

> Communication type user is meant for SAP 's own usage .... like installation defaulted RFCs, background users for some SAP house keeping Jobs etc.

>

> System type user id is a similar kind (not exactly) of user id for Customer 's own usage.

Hmm... this looks very suspect to me. Can you reference an official source for it (because it should be changed).

I asked SAP to change the help.sap.com documentation some time ago and there are many SAP Notes which confirm that SAP only uses the SYSTEM type user now.

An exception in user SAPCPIC still, but for that one the recommendation is to delete the user ID completely if you are not using and have disabled CPIC calls.

If this is wrong... then I'll eat my hat...

Cheers,

Julius

[chris_hall2]

Wow, [nice document in the Wiki|http://wiki.sdn.sap.com/wiki/display/Security/BestPractice-HowtoanalyzeandsecureRFC+connections]. Not sure how I missed this before. This will definitely get me started.

Edited by: Chris Hall on Sep 30, 2010 9:36 PM

[Former Member]

I plan to finish it by year-end. You are all welcome to chip in - that is what wikis are about.

I added a general comment upfront on the importance of the user type.

Cheers,

Julius

Edited by: Julius Bussche on Sep 30, 2010 9:53 PM

[Former Member]

>

> --> sure? I thought non dialog users are not charged....(that is so in my 7.0 system....
> 
> b.rgds, Bernhard

They are free of charge ... and <phew> if they were not, our PI/XI-system would definitely ruin us! That system creates userIDs for every process!

Assign them license-type 91 (Test) (that should work for every kind of price-list you have signed your contract for).

[Former Member]

Dipanjan was refering only to Communication type users. They are now intended to be used by human individuals each having their own communication type user ID - so they are license relevant, or should be...

SYSTEM and SERVICE type users are by design not intended to be license relevant.

Cheers,

Julius

[WolfgangJanzen]

See [SAP Note 622464|https://service.sap.com/sap/support/notes/622464]:

A COMMUNICATION user is actually a DIALOG user w/o the ability to use SAPGUI.

That's at least how the runtime handles the user type. Regarding software license measurement, I'd assume that COMMUNICATION and DIALOG users are treated identical - but that just my personal opinion (I simply do not know).

[Former Member]

Communication Users

If there are technical users in use and they fall into one of the categories below, they can be classified as test users (ID 91).  

Communication
Cross-system activities, not capable of interaction
    *
      Batch Input
    *
      External RFC
    *
      CPIC 

System

System  	System-dependent and system-internal activities, not capable of interaction  	
Internal RFC
Background processing

Service

Service  	System access (anonymous) used jointly by different users, not capable of interaction  	
Anonymous system access (Internet user)

For all SAP Pricelist types - published at service.sap.com/licenseauditing

From a licesing PoV (as of now) they are '91' (free of charge) - the main criterium being: interaction. If every dialogue-user would have her/his own communication user (for whatever purpose ... ) the license-data would still be compressed and the license type with the highest monetary value will be billed (in named user measurement).

Edited by: Mylène Dorias on Oct 4, 2010 12:54 PM

Edited by: Mylène Dorias on Oct 4, 2010 12:55 PM

[Former Member]

I think we need to get away from the assumption that a "technical user" is anything other than a Dialog type user.

Unfortunately legacy documentation and urban legends do not make this shift very intuitive...

Cheers,

Julius

[WolfgangJanzen]

Well, I've always considered a "technical user" as one which is assigned a user-type "SYSTEM" or "SERVICE".

That implies: "COMMUNICATION"-typed users are "human users which are not supposed to use SAPGUI".

Well, I admit that the name "COMMUNICATION" is not the best choice - it's a historic / inherited / legacy term.

Edited by: Wolfgang Janzen on Oct 4, 2010 1:59 PM

[Former Member]

Please think of the 3.1I / 4.5B installations that are still out there ... and will be in extended maintenance forever! At that time there was no such thing as 'Service' - User ...

[WolfgangJanzen]

I'm only referring to those releases where the user type SERVICE exists - and that's not 3.x, 4.0x or 4.5x.

The user-type COMMUNICATION, however, also exists in those old releases.

Kindly notice the release-validity information of note 622464.

Cheers,

Wolfgang

PS: "nothing is forever" ...

PS: I can even remember R/3 2.1G ...

Edited by: Wolfgang Janzen on Oct 4, 2010 2:21 PM

[Former Member]

>

> I'm only referring to those releases where the user type SERVICE exists - and that's not 3.x, 4.0x or 4.5x.
> The user-type COMMUNICATION, however, also exists in those old releases.
> Kindly notice the release-validity information of note 622464.
> 
> Cheers,
> Wolfgang

I know that note by heart

And -obviously- I failed to make myself clear - of course there was user-type 'Communication' or 'CPIC' which -at that time- was free of charge - which probably is the reason it still is free of charge (downward compatibility).

>

> PS: "nothing is forever" ...

I now I failed at an attempt at sarcasm ... I think, I should go home now

>

> PS: I can even remember R/3 2.1G ...
> 

So do I. The memory alone is another reason to go home

[chris_hall2]

We are still on 4.6C

[Former Member]

>

> We are still on 4.6C   

Oh!!

Now we please need your kernel release and patch level in order to decide what to advise ...

[Former Member]

You should still change the usrr type to SYSTEM and check there are to type 'D' users in USR02 either!

Cheers,

Julius

[Former Member]

>

> You should still change the usrr type to SYSTEM and check there are to type 'D' users in USR02 either!
> 
> Cheers,
> Julius

Only after having checked the kernel/patch, otherwise you might run into problems [like this one|https://service.sap.com/sap/support/notes/760414].

[Former Member]

Okay, we don't know whether the kernel hasn't been patched in the past 6 years, nor whether CPIC communication is being used at all - or possibly even param login/disable_cpic = 1 would have made an even shorter audit out of this user type aspect of the original question.

In short to summarize: You can still use Communication type users for when the application user in the client side "owns" the ID and is permitted to change the password, but you simply want to achieve that they cannot logon via the SAPGui logon screen. By implication, you should not save the password of any Communication type users into logon data storages (SM59, SICF, etc) in the same way that you should not do so for Dialog type users.

If you want to use "hardwired" users for system communication or making services available on the system, use SYSTEM type users or respectively SERVICE type users. Note that with SERVICE type users the remote callers can not only debug their own applications, but also the backend ABAP applications in the context of the connection user, and with the authorizations of the user entered in the connection (if authorized for debugging - even display debugging is critical here!).

Cheers,

Julius

[chris_hall2]

This message was moderated.