RFC User s

[Former Member]

How is create RFC users ? thru Sm59 ? Su01?

Thanks

[Former Member]

Create them in SU01 and maintain them for the RFC connection in SM59

[Former Member]

So it goes the same format aswe create a normal user( dialog) just that here its a service user ..am I right ?

[Former Member]

That's right, though usually RFC users are System user type rather than Service

[Former Member]

Got you !

I got a request outof the blue telling that RFC users are needed.

I dont have the following :

1. The number of Users they need

2. Whats are the ids they need

So I was taken a back.

Also the logon gp thats requested is not present in the SU01 ..tab where we mention the " authority check gp' am I missing something?

Thanks

[Former Member]

You also need to know what the RFC users are doing. I wouldn't recommend giving them SAP_ALL, rather create roles that give access to the functionality that they need (which can be quite wide at times).

If you have CUA you can look at the 1 or 2 roles usually assigned to the CUA RFC users to see that they really only have access to do what they need to do.

Logon group might refer to the Basis logon group which has something to do with app server grouping and load balancing rather than the group fields in SU01

[Former Member]

Perfect!

To cap it,

1. Create the user thru SU01.

2. User type ;SYSTEM

3.roles as defined or created --to be determined !

4.save it.

there you have an RFC user? Is that all ? whats now open is howdoes he become an RFC user? if we end here ..allsystem users areRFCusers ?

[Former Member]

Hi George, you've got it.

An RFC user is only one that is used for RFC communications. When you set up an RFC connection in SM59 you enter the user you want to use for that connection and that user becomes the RFC user.

The same stands if you are connecting from an external system via RFC

[Former Member]

Yeah Alex,

I got it.But technically speaking he need to become an "Communications' atleat the job describes that..and not a system user right?

Now to maintiain thisuser..say he forgot the PWD ...then SM59 ...click onthe RFC detination and then edit the pwd !!

[Former Member]

The password of that RFC user is typically saved (together with other logon information) in SM59 in a "source" (which may, or may not, be your own SU01 system, the "target").

If that user has authorizations to execute certain applications or function modules, then anybody who has authority to run the application or function in that "source", can run it in your SU01 "target" system under the ID and with the authority of that RFC user.

You should be pick-and-choosy about who you give the password to and more important which access the RFC user has, because access to it is controlled by authorization and not authentication once the password is saved in SM59.

Resetting the password in a co-ordinated manner (both in SU01 "target logon data" and SM59 "source logon data") would also be required, if required.

Cheers,

Julius

[Former Member]

Juluis &Alex..on a more serious note! How did you gather so much of knowledge !

[Former Member]

Alex, I'll let you go first to explain how you came to know about that.

I have to go home now

Cheers,

Julius

[Former Member]

Hi George, I spent a couple of weeks reading some of Julius' old posts, that did it for me

Edited by: Alex Ayers on Dec 18, 2007 5:56 PM

[Former Member]

No no no! Alex's posts are much better and older.

He survived the great depression of '02 while I was still auditing R/2 systems for a company which survived the other depression...

There are many sources of information from which you can gain SAP and SAP security information.

The better ones (in my opinion) for gaining SAP Security knowledge are those which help you to help yourself without making you dependent on them (though SAP can be addictive because of it's crispy internal business security logic - which makes it fascinating even for accountants...:-)

Some of the best ones (in my opinion) to search:

- The system itself.

- SAP Service Marketplace (OSS)

- http://help.sap.com

- SDN (here you have an advantage when asking or answering questions, in that SAP themselves are participants)

- using google or other "SAP" sites with knowledgable contributers, such as SAPfans (there are many such sites; the ones which will give you a sustainable solution are better than those which give you a shortcut).

Last, but by no means least, you can gain invaluable information from questions, and folks who follow-up on answers (and question them as well) - like you do George

A technical discussion forum takes 2 to tango: questions and answers.

From your recent posts, I have learnt that I should have more courage to ask questions.

Thank you George,

Julius

[Former Member]

yes, SAP is so fascinating,So Interesting !! In security area you are given raise the bar of the corporation interms of ethics -again depends how you look at - corporate responsiblity, transparecy..etc.

I am a novice, Juluis --But I am learning from you folks ! With no qualms to ask what I dont know !!

[WolfgangJanzen]

> ... Resetting the password in a co-ordinated manner (both in SU01 "target logon data" and SM59 "source logon data") would also be required, if required.

Well, there is an alternative to storing UID/PWD (and keeping them in synch):

using the RFC Trusted System concept (for ABAP-to-ABAP RFC connections), see

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

When using passwords in SM59 destinations, please notice [SAP Note 1023437|https://service.sap.com/sap/support/notes/1023437].

Cheers, Wolfgang

[Former Member]

Hello Wolfgang,

Yes, I have read SAP note 1023437 prior to you having pointed it out. Some folks learn the hard way...

Yes, Trusted RFC has the freindly effect of eliminating the password, which makes it more administratable for the "target" to determine (and change) from where the logon is "sourced", which user(s) to expose to that "source" and possibly which point of entry the trusted "source" can use.

For n (many) : 1 connections, it is also easier to remove one, without disrupting the others.

Though it is an area to be carefull. I have found that "systems" generally prefer to-be-trusted, or to trust "sources" which have a higher or equal security level than themselves... and would like to be able to audit them (the other party) to get some assurance of this... tricky stuff!

Cheers,

Julius

[WolfgangJanzen]

> Though it is an area to be carefull. I have found that "systems" generally prefer to-be-trusted, or to trust "sources" which have a higher or equal security level than themselves... and would like to be able to audit them (the other party) to get some assurance of this... tricky stuff!

Well, that's a good and valid point.

Of course, the "trusted" system needs to be of "higher or equal security level" then the "trusting" system.

That might then still provide reason for using the UID/PWD approach (with the risk of password locks due to failed logon attempts - mainly because of false configuration, but potentially also because of denial-of-service attacks).

Cheers, Wolfgang

[Former Member]

True, and the opposite could be true as well:

If you don't trust a "source" (for example, they are known to share the passwords you give them), then it might be a safer approach to give them a trusted user in the "target" and restrict the access of that user such that they can only do a very specific set of tasks (successfully) using specific organizational boundaries - and in this case only from their own system.

In that case, it might make more sense to audit the "target" more closely... the "source" has nothing to gain, or loose, or care about the PWD because they don't have it...

Cheers,

Julius