Showing posts with label RFC. Show all posts
Showing posts with label RFC. Show all posts

Friday, December 16, 2011

How to create RFC connection


This procedure should allow the Basis team to create a RFC connection in any SAP server.
1. Logon to SAP server
2. Use Transaction Code SM59
3. On SM59 screen click on “Create” button
4. On the new screen, give RFC destination name – Name by which the connection would be identified
5. Give Connection Type ( 3 for any SAP to SAP communication ) F4 Help will list down all possible types of connections
6. Give Description for the RFC Connection – Generally the purpose of the connection is mentioned here
7. Click SAVE
8. Give IP address/Host name and system number for destination server in Technical Settings tab
9. Click SAVE
10. Use “Test Connection” to check RFC.
11. If Trusted RFC connection is required, give user credentials in “Logon/Security” tab

Saturday, July 30, 2011

How to export and import RFC information

This can be used to take backup of RFC destinations before systm copy and can be restored once system copy is over.

1) Login to SAP Server with sidadm user
2) create a file with rfcexp.dat with below mentioned data

export
client=771
file="F:\rfcexp.ctl"
Select * from rfcattrib
Select * from rfcdes
Select * from rfcdoc
Select * from RFCSYSACL
select * RSECACHK
select * RSECACTB

3) Run command R3trans -w rfcexp.log F:\rfcexp.dat
4) Export should be over with RC=0
5) For import create file rfcimp.dat with following content

import
file="F:\rfcexp.ctl"

6) Run Command R3trans -w rfcimp.log rfcimp.dat

RFCs should be imported 

Wednesday, July 6, 2011

How to configure Central User Administration (CUA)

Hi All,

Here is the procedure for Central user administration configuration in a landscape:

1) Create Logical systems to all clients for the landscape using BD54 or SALE as
comfortable.

2) Attach Logical system to clients using Same.

3) Create RFC connection to relevant systems with the same name as logical system name .

If you Logical system name is SIDCLNT100 for dev then create RFC connection to
DEV with same name SIDCLNT100.

4) Let us suppose you Central system: DEVCLNT100
Child system: QUACLNT200

5) Create user CUA_DEV_100 in devclnt100 system

4. Create user CUA_QUA_200 in quaclnt200 system.

Create RFC’s to child systems from central and central to child.

5) Now logon to central system and execute tcode scua to configure cua.

Enter the name of the distribution model: CUA

Press create

Enter ALL Child system RFC’s

Save your entries now result screen will appear

If you expand the nodes for

the individual systems, you normally see the following messages for

each system: .ALE distribution model was saved,. .Central User

Administration activated,. and .Text comparison was started.. If

problem messages are displayed here, follow the procedure in SAP

Note 333441:


6) Setting the Parameters for Field Distribution
Enter Tcode SCUM in central system following screen will appear
Now maintain your filed distribution and save it.
You can use transaction SUCOMP to administer company address data.
You can use transaction SCUG in the central system to perform the
synchronization activities between the central system and the child
systems by selecting your child system on the initial screen of transaction
SCUG and then choosing Synchronize Company Addresses in the Central System

After you have synchronized the company addresses, you can transfer the
users from the newly connected child systems to central administration.

This is done, as with the synchronization of the company addresses, using

transaction SCUG in the central system. To do this, on the initial screen of

transaction SCUG, select your child system and choose the Copy Users to

the Central System button.


Use

You can use the report RSCCUSND from the central system of Central User Administration (CUA) to synchronize the master data of selected users with a child system of the CUA. The report sends the master data (including role and profile assignments) to a child system of the CUA.



If master data exists in the child system for the user sent, it is overwritten.

Procedure
...

1. Start report RSCCUSND (for example, using transaction SA38).

2. In the Receiving System field, specify the child system to which you want
to send the user data.

3. You can use the fields User and User Group to restrict the number of users.

4. Specify the data that you want to distribute under Distribution Options.

5. Choose Execute.

Monday, July 4, 2011

SAP User (Must known)


SAP Systems create the standard users SAP*, DDIC and EARLYWATCH during the installation process in the clients as shown in the table below.
During the installation process, SAP Systems creates standard users such as SAP*, DDIC and EARLYWATCH. The table below shows these ID’s with their standard passwords.

SAP*

SAP* will be available right after the installation in all client and contains composite profile SAP_ALL assigned and with  all authorizations, including the ones needed for system set up.
SAP® has implemented this standard, hard-coded (backdoor) ID to allow a login, if the basis administrator’s user-ID is disable or for emergency access. However, to enable this standard ID, SAP* created as regular  user-ID needs to be deleted.
To prevent a login with SAP* after a deletion, the parameter login/no_automatic_user_sapstar should be set. Value 0 (zero)  allows users to log in with SAP*. Value 1 will prevent users from logging on after SAP* is deleted.
  • The standard password for this user directly after the installation of clients 000,001 and 066  is 06071992.
  • The standard password for all new clients  is PASS.
The preferable method to protect this user is the deactivation of SAP* :
  • Remove all authorizations from this user.
  • Create a new superuser and deactivate SAP*.
  • Change all of the default passwords for these users.
  • Lock the user account.
  • Set the parameter login/no_automatic_user_sapstar to 1.
  • Activate the audit log for this user.
  • Assign them to the group SUPER so that they only be modified by administrators who are authorized to change users in the group SUPER.
Report RSDELSAP deletes the user SAP*in the client 066. The corresponding source code is not active but available.

DDIC

The user DDIC is established in the client 000 and 001 with the installation and copies of these clients. This standard user -id is uitilized to cover installation and release updates including changes to the data dictionary. The use of the transport management system is restricted to display only.
This is the protection against any direct development. As the technical steps related to this process are initiated in the client 000, the DDIC only needs to be a dialog user in 000. In all other clients he can be set to the user type “system”. The standard password for this user directly after the installation is 19920706.
The report RDDPWCHK allows to check the password that is assigned to the user DDIC. In case the password matches, the dialog window will be closed. For mismatches the message False is displayed. The counter for false login does not count these password detection attempts.
Do not delete DDIC or its profiles. DDIC is needed for certain tasks in installation and upgrade, software logistics, and for the ABAP Dictionary. Deleting it results in loss of functions in these areas.
To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock it when necessary.
To find out which clients you have in your system, display the table T000 using transaction SM30.
Use the report RSUSR003 to make sure that the user SAP* has been created in all clients and that the standard passwords have been changed for SAP*, DDIC (and also the older user SAPCPIC). For more information, see SAP Note 40689.

Remote Support Users

When using the SAP support services, you often need to allow remote access to your system using a user defined at your site. Because you are allowing system access to someone outside of your system, you should take extra precautions to protect this user. We recommend the following:
  • Define a special user for remote access. Do not use any of the standard users.
  • Define a procedure for activating and deactivating the user. Activate it only when necessary and deactivate it once the remote session is completed.
  • Do not disclose this user’s password over the remote session. Send it over a separate channel such as an e-mail or a return telephone call. Change the password once the session is completed.

EARLYWATCH

EARLYWATCH is created in the client 066 during installtion and is used for remote control by SAP® and is only set up with some standard authorizations S_TOOLS_EX_A for performance monitoring. The user is to be locked in general, and can be unlocked upon request. Initial password for EARLYWATCH is support.

Summary

To summarize, we recommend that you regularly review the following criteria for protecting the standard users:
  • Maintain an overview of the clients that you have and make sure that no unknown clients exist.
  • Make sure that SAP* exists and has been deactivated in all clients.
  • Make sure that the default passwords for SAP*, DDIC, and EARLYWATCH have been changed.
  • Make sure that these users belong to the group SUPER in all clients.
  • Lock the users SAP*, DDIC, EARLYWATCH and your remote support user. Unlock them only when necessary. (Note that it should never be necessary to use SAP*!)
  • Lock DDIC and EARLYWATCH and unlock them only when necessary.

But wait, don’t walk away,there is more….

TMSADM

This ID is automatically created at the set up the change and transport management system in the client 000. The user type is “Communication”, and is utilized for transports by the CTS. TMSADM is assigned to profile S_A.TMSADM assigned that authorizes the use of RFC with display of the development environment as well as access to write to the file system. The standard password for this user directly after the installation is PASSWORD.

SAPCPIC

SAPCPIC is created as a “communication” user at the installation and is mostly used for EDI. The standard profile S_A.CPIC restricts the access to the use of RFC. This user is hard-coded into the function module  INIT_START_OF_EXTERNAL_PROGRAM together with a standard password. This needs to be considered in case of password changes for this user.
The standard password for this user directly after the installation is ADMIN.

SAP* in J2EE

The user is established with full authorizations for the administration. With regard to security, the user has no standard password assigned. To utilize this user as emergency user the properties in the UME need to be maintained. Setting the ume.superadmin.activated property to true will activate the use of this user for emergency cases. Setting a password in ume.superadmin.password will then activate the user finally after the restart of the engine.  While the user SAP* is in use, all other users will be inactivated during this time.
When the system is fixed, the deactivation can be achieved by setting the ume.superadmin.activated property to false.

J2EE_ADMIN_

This user is the Java standard user with full administration authorization in this environment. The password is to be assigned during the set up.
High complexity is recommended for this password.

J2EE_GUEST

This user is a Java standard user who can be utilized for anonymous access. The user is locked per default. The password is assigned during the installation.

SAPJSF_

This user is a standard communication user for LDAP Lightweight Directory Access Protocol data sources.

ADSuser

This standard user is utilized for the communication between Java and ADS Adobe Document Service.

caf_mp_scvuser

This standard user is utilized in the context of the Composite Application Framework (CAF) core transport system and communication with other Java services.