RFC User Type

Hi
Calling gurus.
When gererating RFC users for the READ and TMW rfc's in Solution Manager users gets generated, and I know the user type is Communication user, however should you be forced to have to create your own users to use within this rfc would it be best to stick to communication user type, or could a system user type be used. 
It is my understanding that logon via read rfc should not be allowed as it could be a security risk.
If I am on the wron track please enlighten me or point me towards a conclusive best practice regarding this.
Thanks in advance.

Hello again Paul,
1.-
At the same 2008 manual "Activating the SAP EarlyWatch Alert on Solution Manager 7.0" yo can see on page 11 this:
...A working dialog connection such as *TRUSTED or LOGIN. Once the *BACK destination is created, these can be deleted again...
This prerequisites are need for the creation ob RFC "_BACK" on remote system, but for remote call of sdccn the prerequisites on Page 15 are not enough !!!
If you want to call remotely sdccn from solution manager you need a dialog trusted connection.
I have just tested on our solution manager 5 minutes ago, you are invited to our solution manager if you want to check it.
2.-
What about this:
My question is, Will take into account SAP this users for the "SAP Security user audit" ?
Regards:
Luis

Similar Messages

  • Password inconsistancy issue with RFC users in ECC 6.0 System after upgrade

    Hi,
    We have upgraded the system from 4.7 to ECC 6.0, but facing the password inconsistancy problem for RFC users. We have set the parameters like "login/min_password_lng" as "8" and "login/password_downwards_compatibility" as "3" & RFC user Type is "system". Could you please suggest how to resolve the password inconsistancy issue.

    Hi Chandan,
    you need to run the txn. SECSTORE and there it will shows you all the RFCs that have inconsistent passwords. Please maintain the correct passwords there.
    In case the existing passwords are no longer acceptable due to new security policies as per the new SAP version, you will have to change the password from SU01.
    Regards,
    Shitij

  • Which user type to user for RFC receiver channel

    Hi Forum,
    I m developing XI scenarios which include RFC receiver chhanel (in IB: Integration Directory), to call a function moule in a R/3,
    which kind of user should i use for this purpose, i mean to say,
    which user type:
                    SYSTEM
                    Dialog
                    Communication
                    System
                    Reference
    and what should be the roles of that user,
    which type of the user doesnt gets locked, on wrong attempts

    Hi,
    Generally S_RFC and S_SERVICE authorizations  are nedded while calling RFC module from R3. Also check for role S_RFC_ADM
    The backend should have the authorization to execute the RFC on the backend.
    You can test the module in R3 and create a role using PFCG assign the tcode - SU53 (authorization check) and also assign the S_RFC and S_SERVICE to role.
    Refer
    RFC Logon user authorizations
    Question on service userid - for RFC call
    End User Authorizations and Roles
    Calling R3 RFC via http
    For RFC different authorization object is requried. You can ask your basis team to add the relevant authorization object in a new role and then add the new role to any existing service user or better create a new system user and add the role.
    Thanks
    swarup

  • SMSY creates RFC user as "Communication" user type

    Transaction SMSY was used to create RFC destinations to all satellite systems. In the SMSY wizard, it was requested that the RFC be created as well. After both RFC user and destination were created, it was perceived that the RFC user is of type "Communication".
    According to SAP Note 622464, "Communication" user will require the user to modify the password after it has expired. Therefore, I ask:                                                                               
    1. Why does SMSY creates RFC user of type "Communication" instead of  "System"?                                                              
    2. Is there any harm if the RFC user is updated from "Communication" to "System"?

    Hello,
    'Communication' users are used to 'communicate' ! So they require dialog login (like here in these RFCs) and which they can do and for what they are defined i.e. to login or to make communcation possible via RFCs
    'System' users are used to handle the background tasks which do not require dialog login across SAP systems or via RFCs. In other words, system user is not a dialog user and hence can't act as a user in RFCs to communicate acrosss SAP systems !
    Hence,
    1. SMSY creates 'communcation users'
    2. if the RFC user is updated as the system user, then no 'dialog login' and hence 'no communication'

  • RFC USER USER TYPE- SYSTEM/SERVICE?

    Hi,
    We are using CTP method of GATP.
    Currently our user type for RFCUSER (Usermentioned in rfc destination) is service? It allows dialog mode this is security concern for us as RFC USER as all authorisations.
    When we changed it to system user it is giving error while triggering GATP. Also there is dump in SCM system with message
    "DYNPRO_SEND_IN_BACKGROUND"
    "/SAPAPO/SAPLATP4" or " "
    "SYSTEM-EXIT".
    pls. suggest solution
    Regards,
    Santosh

    Hi,
    This info i took it from help library.
    If you want the ATP check to be performed in SAP APO but triggered from SAP R/3, make sure when
    defining the RFC connection of the SAP APO system in SAP R/3 that you use a user ID for the SAP APO
    system that was created there as a dialog user.
    Thanks,
    nandha

  • Invalid_jobdata when submitting job with rfc user

    Hi,
    I've created a function module in the erp system to remotly trigger a report program by a bw prossess chain.
    When running in the forground it works fine, but the runtime is so long that I want it as a background job.
    So I call job_open, job_submit, job_close in the function module. When I test the function module in the erp system with my dev user it opens a new job, adds a step and release correctly. It also runs fine if I intercept it in the debugger and change sy-uname to aleremote (the standard rfc user).
    It does not work when it's acctually called rfc from the bw system. The job is opened, but job_submit throws invalid_jobdata.
    Could this have anything to do with rfc or the executing user (which is of type SYSTEM)?

    I've caught the execption so there is no dump, but I'm unable to determine why the function module job_submit gives invalid_jobdata only when the executing user is the aleremote user and only when the call originated (the call to my module) from a remote system (the module job_submit is called locally thru my module). Authorization for the user is sap_all, but I was woundering maybe the user type system could be a problem?

  • Authorization Required for RFC user  in R/3-APO system.

    Could you please help regarding one authorization issue. I want to know the authorization required for one RFC user. Now this RFC user used for RFC connection of SAP R/3 - SAP APO system. user type is given dialog type and SAP_ALL profile has been given to this user  id. Now I have to remove SAP_ALL from this user id in R/3 and APO system and  provide the required the authorization in R/3 and APO system.
    Regard
    Auroshikha

    The RFC authorisation depends completely on what the user is doing (ALEREMOTE?).  We can't tell you what RFC auths your connection requires. 
    There is a guide to doing this here: https://wiki.sdn.sap.com/wiki/display/Security/BestPractice-HowtoanalyzeandsecureRFC+connections

  • Meaning of User types & their use....

    Hi all,
    Please explain me below user types and their significance in brief:
    USR02-USTYP  Description
    A             Dialog
    B             System User (Internal RFC and Background Processing)
    C             Communication User (External RFC)
    L             Reference User
    S             Service User
    Regards,
    Sachin

    User Type
    Dialog 'A'
    A normal dialog user is used by one person only for all types of logon.
    During a dialog logon, the system checks for expired and initial passwords and provides an option to change the password.
    Multiple dialog logons are checked and logged if necessary.
    System 'B'
    Use the system user type for internal system processes (-> background processing) or system-related processes (-> ALE, workflow, TMS, CUA).
    Dialog logon (using SAP GUI) is not possible.
    A user of this type is excluded from the general settings for password validity. Only user administrators can change the password using transaction SU01 (Goto -> Change Password).
    Multiple logons are permissible.
    Communication 'C'
    Use users of type Communication for dialog-free communication between systems (-> RFC or CPIC) .
    Dialog logon (using SAP GUI) is not possible.
    The general settings for the validity period of a password apply to users of this type. Users of this type can change their passwords (like dialog users). The dialogs for changing the password must be provided by the caller (RFC/CPIC client). You can use the RFC function module USR_USER_CHANGE_PASSWORD_RFC or the RFC API function RfcOpenEx() to change the password.
    Service 'S'
    A user of the type Service is a dialog user that is available to an anonymous, larger group of users. Generally, this type of user should only be assigned very restricted authorizations.
    For example, service users are used for anonymous system access using an ITS service or a public Web service. Once an individual has been authenticated, a session that started anonymously using a service user can be continued as a personal session using a dialog user (see SUSR_INTERNET_USERSWITCH)
    During logon, the system does not check for expired and initial passwords. Only the user administrator can change the password.
    Multiple logon is allowed.
    Reference 'L'
    Like the service user, a reference user is a general user, not assigned to a particular person. You cannot log on using a reference user. The reference user is only used to assign additional authorization. Reference users are implemented to equip Internet users with identical authorizations.
    On the Roles tab, you can specify a reference user for additional rights for dialog users. Generally, the application controls the allocation of reference users. You can allocate the name of the reference user using variables. The variables should begin with "$". You assign variables to reference users in transaction SU_REFUSERVARIABLE.
    This assignment applies to all systems in a CUA landscape. If the assigned reference user does not exist in one of the CUA child systems, the assignment is ignored.

  • RFC User for satellite systems

    Hello Gurus,
    I just wanted to ask about one issue. We are a SAP partner and using Solution Manager in VARs scenario. There are many systems of our customers connected to our Solution Manager..
    Now I want to ask about RFC user(s). As I see, in our Solution Manager there are many users(communications type C) with Synthax SOLMAN<system id> or something like that. It means basically, that we have for every particular customerS system one SOLMAN user for RFC(cust_scout) in our Solution Manager. My question is if we can replace all of these users with only one RFC user for all the systems and customers?
    Many thanks in advance for your help
    Miloslav Pudil
    IDS Scheer
    Prague
    Czech Republic

    >
    Miloslav Pudil wrote:
    > I just wanted to ask about one issue. We are a SAP partner and using Solution Manager in VARs scenario. There are many systems of our customers connected to our Solution Manager..
    > Now I want to ask about RFC user(s). As I see, in our Solution Manager there are many users(communications type C) with Synthax SOLMAN<system id> or something like that. It means basically, that we have for every particular customerS system one SOLMAN user for RFC(cust_scout) in our Solution Manager. My question is if we can replace all of these users with only one RFC user for all the systems and customers?
    Hi Miloslav,
    Technically, it will work that you define one common RFC user in your SolMan for communication (RFC BACK destination) from all connected managed systems.
    BUT, I would never recommend it.
    Once a managed system cause issues in your SolMan, you are not able (or at least it's much more difficult) to identify the managed system. Same happens, if a invalid password in the BACK destination leads to a locked user.
    My recommendation: Spend the extra effort in creating a user per managed system. Operation will be much easier later.
    See also this guide:
    [Activating EarlyWatch Alert [EWA] in End Customeru2019s System |http://service.sap.com/~form/sapnet?_SHORTKEY=00200797470000089947&_OBJECT=011000358700000567342009E]
    Best regards,
    Ruediger

  • Password for RFC USer

    Hi experts,
    We need to set the password for RFC User in small letters.But we are not able to do it ,because of our 'login/*' parameter values.
    Is there is any other method to create the password for User ID with small letters(Ex:welcome,hello)?
    Thanks in Advance,
    Karthika

    > > Login rules are not specific to user types. It is same for all type of users.
    > Sorry, this is not correct. The password validity rules are a good example which don't apply to SYSTEM and SERVICE type users. Other examples are the idle time rules and compliance to policy rules and the logon ticket rules and remote login via debugging rules and...
    >
    I tried to talk about is as per the ongoing discussion topic i.e. Case sensitiveness of Passwords and not other attributes. So from this point of view there is no such separate rule applies during admin imposed password or during a change (the cases where system prompts for changing password).
    > > From NAS 7 there is a change in the password rules.
    > There were major changes in 46B, and 6.10 and 6.40 as well, and Karthika still has not told us which release she is on.
    >
    Agreed totally.
    > > [Note 750390 - USR02: various problems with password attributes|https://service.sap.com/sap/support/notes/750390]
    > > [Note 624635 - Error messages with password change using RFC function|https://service.sap.com/sap/support/notes/624635]
    > I cannot see how these notes are related to this silly requirement of setting a lower-case only password.
    >
    I didn't went through in details fully but seen it contains a considerable error details.... may be of any help to OP.
    > I think either Karthika is playing a joke on us, or the person interviewing Karthika is playing a joke on her... These would be the only logical explanations left which I can see for for such a requirement.
    >
    May be.. but of course need more information and purpose of such strictness for setting such password. Also the FM PASSWORD_FORMAL_CHECK can be used with required customizations but you are the best person to tell this properly.
    regards,
    Dipanjan

  • RFC User for Connectivity with ABAP Server Proxy Required?

    Hi people,
    I am just wondering how I set-up my connectivity between XI and my business system B.
    Our basis already set-up the connection to the runtime workbench from B->XI
    For that sake they've added the xirwbuser to B (Xi has it as well, of course).
    Now I am configuring the whole thing in the Directory. There I need an receiver agreement and a channel. For that I take the adapter type "XI". Anyway, I need to give here an RFC destination as well. I've added one of type "H".
    And now the issue: Do I really need a separate user for that rfc connection? I thought with proxies the systems are somewhat like "hard-wired" and do not need special users.
    Anyway, if I need a dedicated RFC user: Is a certain role enough or do I need special roles depending on the stuff I am doing in the business system?
    Thanks in advance!
    Helge

    You can of course use an existing service user.
    But for monitoring purpose it is receommended to use a seperate user. (Think about system log entries).
    The user needs the role SAP_XI_APPL_SERV_USER.
    Regards
    Stefan

  • RFC user logon failed R3077

    Hello
    RFC user logon failed.
    Can anybody help me out for R3077
    Its occuring regularly
    Thanks And Regards
    Akash Gupta

    Hello akash,
    Possible reasons :-
    1> user must be of type "System" in logon data.
    2> must be unicode "in RFC"
    Rest you could follow this link :-
    /thread/250014 [original link is broken]
    Please do write to me at [email protected] in case of more queries.
    Thank you.
    Regards,
    Manomeet
    Award points if helpful **

  • RFC as type of connection in transaction sm04 of Database server

    Hello I wander what means RFC as type of connection in transaction sm04 of Database server.
    Does it mean an user logged on applicaton server is displayed on database server as RFC?

    Hi Jan
    User login to SAP may be possible with either GUI or RFC. GUI implies to direct logon to SAP though the SAP GUI. This is characterised by the user name.
    The other way is RFC which implies to remote access to the system. This is usually characterised by IP address or the domain address .
    I hope this helps
    Regards
    Chen

  • Portal System Object - ABAP User Type?

    Hi
    I've created a System Object, which will be used to connect to a NW '04 system. I'm using UIDPW as the Logon Method, and have defined the relevant user mappings.
    When I test the connection using a normal Dialog user in the ABAP backend, everything works perfectly. However, when I use a Communication user, the connection test fails.
    Does anyone have any suggestions on getting the connection to work with a Communication user? What is the recommended ABAP user type for backend connections? I assume Communication user is recommended, as this doesn't allow dialog login, etc.
    Thanks
    Stuart

    Having done further investigation, it seems the problem is not with the user type. I'm able to connect when assigning the SAP_ALL profile to my Communications user (which I obviously don't want).
    What permissions must I assign to this user to allow it to log in? All I've done so far is assign permissions on the S_RFC authorisation object to allow RFC calls to my function group.
    Do I need to assign additional login permissions?

  • Impact of Changing User Types

    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.

    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

Maybe you are looking for