Trusting Transaction (SMT2)

The trusting transaction SMT2 (or SM59 ® RFC ® Trusting Systems) constructs a list of all trusting systems that have been established for this trusted system. Here, a logon and authorization check for the current user and client is performed, using the destination TRUSTING_SYSTEM@S00 that has been automatically created.       

 

This basically corresponds to transaction SM51, if you use Remote Login to perform a logon on a different application server. 

                                                                    

If problems occur while setting the destination TRUSTING_SYSTEM@S00 (such as host name or service information), you either have to create a new destination for your needs, and then enter the host name or service information using SAP router strings, or adjust the network settings of the server. To correct the problem in transaction SMT2, you have to adjust the network configuration of the server. As this transaction is only to be used for test purposes, in this case you could also choose to ignore the error.                    

                                           

To perform a logon as a different user or client, you have to create a new RFC destination with a trusted option set. 

 

In this scenario, the following error text in SMT2 can be ignored:

No authorization to log on as a trusted system (Trusted RC=0)

 

If the host name contains the character '_' (as in "my_host"), then the generation of the related trusting system destination may lead to incorrect settings. This problem can be corrected by implementing Support Package SAPKB46D09 (see below). For earlier releases, the changes required to correct the problem can be made manually.

 

Using a Trusted/Trusting Relationship

You can now use the configured trusted/trusting relationship to create RFC destinations in the trusted system (client), which are for the trusting system (server), by using transaction SM59 and the 'Trusted System' flag. The result of this is that, when such destinations are used for the RFC logon to the trusting system, no password is sent.

                                                                                

A prerequisite for successfully using a trusted/trusting relationship is that the user being used has the corresponding authorization object S_RFCACL in the trusting server system. If you want to create a suitable authorization for different      

clients and users, note that you have to enter the caller data (caller client and caller user) of the caller system (in our example from system C00) into the S_RFCACL fields RFC_CLIENT and RFC_USER. For example, if user U_1 under client M_1 in caller system C00 wants to work as user U_2 with client M_2 in the called system S00 under a trusted relationship, then the user (U_2, M_2) in the system S00 must have authorization ZRFCACL_XXX, which has the following settings:    

 

  RFC_SYSID : C00  

 

  RFC_CLIENT: M_1                                                            

  RFC_USER  : U_1                                                             

  RFC_EQUSER: N (for NO)                                                     

  RFC_TCODE : *                                                              

  RFC_INFO  : *                                                               

  ACTVT     : 16                                                             

                                                                             

The following steps describe how you can enter the above settings for server system S00:

                                              

SU03 + double-click the entry "AAAB"  "Cross-Application Authorization Objects" and then choose "Authorization check for RFC user (ex. trusted system)" as the object class, then double-click the authorization object S_RFCACL and create Z_RFCACL_XXX.

After this, make sure you activate your settings.                          

                                                                             

If the same user is always used in the client system and server system for a trusted/trusting relationship (meaning that U_1 = U_2), the authorization Z_RFCACL_XXX can also be defined as follows:  

·          RFC_SYSID : C00                                                            

·          RFC_CLIENT: M_1                                                            

·          RFC_USER  : ' '                                                                      

·          RFC_EQUSER: Y (for Yes)                                                              

·          RFC_TCODE : *                                                              

·          RFC_INFO  : *                                                              

·          ACTVT     : 16                                                             

Setting the authorization field RFC_EQUSER to 'Y' is the same as setting the field RFC_USER = SY-UNAME for the logged user in the caller system (here, system C00).                           

Note that when maintaining and assigning S_RFCACL authorizations (in this case, Z_RFCACL_XXX), you must use as few generic values (for example '*') for RFC_SYSID, RFC_CLIENT and RFC_USER as possible. By doing this, those users who fulfill these criteria regarding RFC_CLIENT and RFC_USER, can call RFC modules from within the caller system, using the called user.

                           

You must ensure that high security requirements in the caller system is linked with the usage of user maintenance transactions (such as SU01). If this is not the case, anyone who has this authorization can get a user and log on to the trusting system (S00).      

After you have maintained the authorization Z_RFCACL_XXX, you must create an authorization profile as follows, and link it to the authorization Z_RFCACL_XXX:                                                              

                                                                                      

Call SU02 and in the field "Manually edit authorization profiles", enter Z_<C00> as the authorization profile. Choose "Create work area for profiles" and then create a new profile. Enter S_RFCACL as the object, and Z_RFCACL_XXX as the authorization.

After this, make sure you activate the profile.  

                                                                                     

You now have to assign the authorization profile you have just created to the trusted/trusting user. To do this, enter the profile Z_<C00> on the tab page Profile in transaction SU01.                                                 

You can check the authorizations for the logged on users in the current system in advance, by using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

As of Release 40B, for security reasons, the authorization profile SAP_ALL does not contain an authorization for S_RFCACL.  

Authorization errors that occur while using an RFC destination which has the 'Trusted Systems' flag set to 'Yes' are documented with the following messages:

                                                                                   

No authorization to log on as a trusted system (trusted RC = <0 1 2 3>).                                                                                    

Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:

                                                                        

 0   Invalid logon data (user ID and client) for the trusting system.                                                                        

     Solution: In the server system (trusting system), create the userin the corresponding client.                                               

 1   Calling system is not a trusted system, or security  ID for the system is invalid.                             

     Solution: Create (again) the trusted system                

 2   User has no authorization for the server system  (trusting system, for object S_RFCACL), or a logon was made using one of the protected users DDIC or SAP*.                                                          

Solution:                                                                      

Provide the user with the corresponding authorization or avoid using the protected users DDIC and SAP*. Authorization errors that occur while using an RFC destination which has the 'Trusted Systems' flag set to 'Yes' are documented with the following messages:

 

No authorization to log on as trusted system (Trusted RC = <0 1 2 3>).                                  

                                                                                   

Here, the trusted return codes ( = 0, 1, 2 or 3 ) have the following meanings:

 0   Invalid logon data (user ID and client) for the trusting system.                                                                       

     Solution: In the server system (trusting system), create the user in the corresponding client.                                               

 1   Calling system is not a trusted system, or security ID for the system is invalid.                              

     Solution: Create (again) the trusted system (see above).                

 2   User has no authorization for the server system (trusting system, for object S_RFCACL), or a logon was made using one of the protected users DDIC or SAP*.                                                          

     Solution: Provide the user with the corresponding authorization or avoid using the protected users DDIC and SAP*.                                              

  3 Time stamp of the logon data is invalid.                            

      Solution:  Check the system time on the client host and server  host, as well as the validity date of the logon data.                 

      (Note that the default date 00:00:00 means unrestricted validity.)                                                    

 

Building a Trusted/Trusting Relationship

A trusted/trusting relationship must always be built starting from the trusting system (server). The following describes the individual steps for defining a trusted/trusting relationship of the trusted system C00 (client) to trusting system S00 (server):                  

 

Log on to the trusting system S00 (server). Here, create a destination for the trusted system C00 (client) using transaction SM59 (for example, C00_SYSTEM). It is important that the option 'Trusted System' is not set to active for this destination (Security Option Trusted System = No). 

 

We recommend that you do not specify any logon data in this destination, as someone could use a remote login to misuse this destination in SM59 by working as the user that is defined here. This destination must only be used for creating and deleting the trusted/trusting relationship and not for any other purpose. It must therefore be named correspondingly.

Call transaction SMT1 (or SM59  and then transaction menu RFC ® Trusted Systems).                                                          

Choose Create. Enter the destination of the client system (in the example, C00_SYSTEM) in the dialog box. After confirming this, an RFC logon to the client system occurs, and the necessary information is exchanged between the systems (S00 <-> C00). 

 

 If no logon data has been entered in the destination (in the example, C00_SYSTEM), an RFC logon screen is displayed for the client system (C00). In this particular case, a manual logon must be performed. In each case, a successful logon to the client system must be performed in this step, so that the trustedrelationship can be built.

 

 

When a trusted relationship has been successfully built, the trusted entry for the client system (C00) is displayed. If you want to restrict the validity of the logon data for the client system, enter a timeframe in the corresponding field. The default value (00:00:00) means that the validity is unrestricted.     

                                                       

In the scenario where the same user and client are used, you can use the menu option Entry to perform authorization checks: These checks first attempt to reach the client using the logon data specified in the definition destination (in the example, C00_SYSTEM), and then try to log back on to the server system with the same logon data, using a trusted RFC. Choosing the menu option Current Server forces the return path to occur on the current application server, and choosing menu option Trusting System induces load balancing, meaning that the logon takes place on any application server in the server system.

 

If different users or clients are used for the trusted scenario, you must create an RFC destination on the client side, and perform an authorization check for the specified logon data, setting the flag for "Trusted System" to "Yes".       

Testing & Troubleshooting in Trusted/Trusting Systems

To test a trusted system, you can perform the authorization checks for the current server and the trusting system. To do this, choose the menu entry. If no valid logon data are supplied, the logon screen of the trusted systems appears. You should log on to the system. If your test is not successful, read the section Troubleshooting in Trusted/Trusting Systems below.

Troubleshooting in Trusted/Trusting Systems

After creating a trusted system, you have to test the destination. To do this, log on to the trusted system using remote login.

Alternatively, you can also perform an authorization check for the trusted server. To do this, select the respective function from the test menu.

If your login attempt fails, you will receive the following message: No authorization to log in as trusted system (error code = <0|1|2|3>). Note that the special users DDIC and SAP* must not be used.

 

The error code explanation is as follows:

·        Invalid login data (user ID and client) for the trusting system

Solution: Create the user ID for the client in the trusting system.

·        No trusted system entry exists for the calling system, or the security key for the system is invalid.

Solution: Create the trusted system entry again.

·        The user does not have a trusted system authorization (object S_RFCACL). 

Solution: Provide the user with the necessary authorization.

·        The time stamp of the login data is invalid.

Solution: Check the clock settings on both the client and server host and the expiration date of the login data. (Note that the default expiration period 00:00:00 means no limit.)

 

You can check whether correct login information has been provided for the trusted system in the trusting system by means of the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

 

If all your tests are successful and you still don't get access to the trusting system, refresh the relevant database by choosing Environment ® Mass changes ® Reset all buffers from the user maintenance screen.

To find out the cause of an error, activate the trace flag on the destination details screen, reproduce the error and read the information provided with the error ID CALL_FUNCTION_SINGLE_LOGIN_REJ in the short dump created in the called system (the trusting system).

 

Logon Authorization Checks in the Trusting System

The logon data used for logging on to a trusting system undergo an authorization check.

 

The data provided by the trusted system is checked for system name, client, user name, and other optional data. These data must match the field values of authorization object S_RFCACL.

 

The system administrator can check a user's logon data using the function module AUTHORITY_CHECK_TRUSTED_SYSTEM.

 

 

Displaying Trusting Systems

In a trusted system, you can obtain a list of all trusting systems. Choose RFC ® Trusting systems to display the list of trusting systems.

 

Click on the name of a trusting system to display the application servers of that system. The application server names contain the suffix _TRUSTED.

 

Double-clicking the name of an application server displays a dialog box, in which you can enter the transaction that you want to execute in the trusting system. You can also specify whether the transaction is to be executed in the same session, or in a new one.

 

Changing Trusted Destinations

You can change existing destinations for each system from the trusted system maintenance screen (RFC ® Trusted systems, transaction code SMT1) by clicking on the Maintain destination pushbutton.

 

In trusted systems, destinations for trusting systems are automatically created. These destinations are used when you display trusting systems via RFC ® Trusting systems (transaction code SMT2).

 

To prevent others from making changes to your trusted destination, mark the checkbox Destination not changeable in the Attributes section. To make the destination changeable again, double-click the checkbox.

 

Note that destinations must be kept consistent. For this reason, you are not allowed to change the ID of the target system, the system number, or the destination name.

Displaying, Maintaining and Testing Trusted Systems

To display or maintain a trusted system in the trusting system, proceed as follows:

 

1.If you want to define an SAP system as a trusted system, you must first create a logical destination that allows a trusted system relationship.

2.From the RFC destination overview  screen (transaction SM59), choose RFC ® Trusted systems or enter transaction code SMT1.

3.   If trusted systems have already been defined, they are displayed in a hierarchy tree. To display existing trusted systems, expand the nodes in the hierarchy tree.

4.To create a trusted system, click the Create icon.

5.In the dialog window, enter the destination for the remote system. To change a destination, see Changing Trusted Destinations below.

6.All the necessary information such as application server name and security key is supplied automatically.

7.If you want to restrict the validity period of the logon data, enter an end date in the Validity period field.

8.If you want take over the transaction code of the calling program into the called system, mark the appropriate checkbox.

9.Only then will an authorization check be performed in the called system for the transaction code (field RFC_TCODE of the S_RFCACL authorization object, see Logon Authorization Checks in the Trusting System below).

 

 As you delete a trusted system relationship, the logon screen of the relevant system is displayed, if no valid logon data are provided. You must log on to that system to complete the deletion.

Trust Relationships Between SAP Systems

SAP systems may establish trusted relationships between each other.

If a calling SAP system is known to the called system as a trusted system, no password must be supplied.

The calling SAP system must be registered with the called SAP system as a trusted system. The called system is called the trusting system.

Trust relationships between SAP systems have the following advantages:

·        Single Sign-On is possible beyond system boundaries.

·        No passwords are transmitted in the network.

·        Timeout mechanism protects against replay attacks.

·        User-specific logon data are checked in the trusting system.

Using this feature, you can create a virtual SAP system consisting of various SAP systems that are called remotely. Remote logon data are checked in the trusting system.

 

The trust relationship is not mutual, which means, it applies to one direction only. To establish a mutual trust relationship between two partner systems, you must define each of the two as trusted systems in its respective partner system.

 

For additional security, you can make use of SAP's SNC interface (Secure Network Communications) for third-party security systems such as Kerberos and SECUDE.

SAP Netweaver - Overview of Monitoring Architecture

You can display monitoring data for the following components in the central monitoring system (CEN):

• Systems based on SAP Web AS ABAP and Java

• SAP systems with earlier releases (as of SAP R/3 3.0)

• Non-SAP components

The data is transferred to CEN using CCMS agents or ABAP RFC connections. You can display it there directly in the Alert Monitor, or forward the data to external tools or SAP Business Intelligence for additional evaluation.

The elements of the monitoring architecture function largely independently of each other and can, particularly, be further developed and adjusted independently of each other.

The alert monitor also provides the administration methods that you need to monitor the system. These enable you to set threshold values for alerts and add or adapt auto-reaction and analysis methods. Auto-reaction methods react automatically when an alert is triggered; analysis methods enable you to examine the cause of an alert without leaving the alert monitor. The monitoring architecture also contains tools for administering and archiving the alerts.

Program/Application	Description
CCMS agents	CCMS agents are independent processes that connect a monitored component (such as a host, an ABAP instance, or a Java instance) with CEN using RFC.
Operating System Collector SAPOSCOL	SAPOSCOL is a stand-alone program that runs in the operating system background. It runs independently of SAP instances exactly once per monitored host and collects data about operating system resources.
Availability Monitoring with CCMSPING	With this type of monitoring at system or instance level, the CCMSPING agent queries the relevant message server about which instances are reported as active. You can also have the instance availability of ABAP systems monitored using a direct RFC call to the instance itself.
Monitoring with the Generic Request and Message Generator	With this type of monitoring at application level, CEN periodically calls a GRMG application using a URL. The GRMG application performs component-specific checks and returns the result of the checks to CEN.

Trust Relationships Between SAP Systems

SAP systems may establish trusted relationships between each other.

If a calling SAP system is known to the called system as a trusted system, no password must be supplied.

The calling SAP system must be registered with the called SAP system as a trusted system. The called system is called the trusting system.

Trust relationships between SAP systems have the following advantages:

·        Single Sign-On is possible beyond system boundaries.

·        No passwords are transmitted in the network.

·        Timeout mechanism protects against replay attacks.

·        User-specific logon data are checked in the trusting system.

Using this feature, you can create a virtual SAP system consisting of various SAP systems that are called remotely. Remote logon data are checked in the trusting system.

 

The trust relationship is not mutual, which means, it applies to one direction only. To establish a mutual trust relationship between two partner systems, you must define each of the two as trusted systems in its respective partner system.

 

For additional security, you can make use of SAP's SNC interface (Secure Network Communications) for third-party security systems such as Kerberos and SECUDE.

FAQs - SAP ENqueue Lock

[1] Question: How large can and should the lock table be configured?

Às of Release 4.0 the default size for the lock table is 4 MB. For medium-sized systems this value is absolutely sufficient. As of 4.6, it appears that a size of 10-20 MB is required for some background jobs, and a size of 32-200 MB may be required for large systems, although this is the exception. As a lock table that is too small causes transaction terminations, but resources for the lock table are relatively low, a size of 20 MB should be specified initially. no further changes are generally required to the layout of the shared memories with this size (except for AIX 32 bit). You can enter this setting using the profile parameter: enque/table_size = 20000

You can monitor the lock table in transaction SM12 via the menu option "Extras -> Statistics".

The lock table is a shared memory, not a database table.

[2] Question: What does the expired queue time in the syslog mean for locks?

Locks can usually only be set in the R/3 system if they are available. If an object is already locked, requests to lock it are refused and the error message " ... locked by user ..." is issued. This prevents the dead lock situations familiar from databases. However, a job should not terminate in background processing if a lock happens to be unavailable. In such cases, the locks are requested with the addition "and wait". The queue time incurred is then logged in the syslog. The maximum queue time is set using the profile parameter enque/delay_max.

[3] Question: How does communication take place in lock management?

This question is especially important for troubleshooting since it indicates the characters at which errors can occur. In the Central Instance, all work processes can access the lock table directly. Therefore, the ENQ work process is not needed, and so no communication occurs.

An application server sets and deletes locks via the Message Server. There is therefore communication from work process-> dispatcher->server -> dispatcher -> ENQ work process. The lock table is read by RFC, that is, work process-> dialog process -> gateway-> gateway-> dialog process -> dialog process. Here again, the ENQ process is not required, although two dialog processes are needed for RFC communication. Central instances with few dialog processes can be overloaded quickly in this way. The same also applies to pure background or update server processing. The number of dialog work processes must therefore be at least as high as the number of remaining processes.

[4] Question: What are "black" and "blue" locks?

Black locks are normal transaction locks. Blue locks are inherited by the update system and deleted with the corresponding update request. Blue locks are also saved in the file system and restored when the system is restarted.

 

Mass Generation of Profiles (SUPC)

You can use the mass profile generation transaction to determine which roles already have authorization profiles. You can also perform a mass generation of roles or generate the missing role authorization profiles for roles in the background.

 

You will need the following authorizations to use Transaction SUPC:

·        User master maintenance: Authorization Profile (S_USER_PRO)

·        User master maintenance: Authorizations (S_USER_AUT)

·        Authorization system: Check for roles (S_USER_AGR)

 

Procedure

       1.      In role maintenance (transaction SUPC), choose Utilities ® Mass Generation in the role maintenance (transaction SUPC).

       2.      Specify the desired selection criteria.

To generate all profiles to be generated automatically (last checkbox), you can further restrict the role selection in the next screen.

 

 

 

Determining Users with the Users Node

There are a number of evaluation options available to you using the Users node. These are explained below.

·        Cross-System Information

·        Users by Address Data (RSUSR002_ADDRESS)

 

You perform the procedure for evaluating with generic input options (placeholder asterisk and multiple selection). To obtain a result, the corresponding criteria, such as room, must be maintained in the user data.

·        Users by Complex Selection Criteria (RSUSR002)

·        By Critical Combinations of Authorizations at Transaction Start (RSUSR008)

·        With incorrect logon attempts (RSUSR006)

 

This evaluation is started immediately without additional selection criteria when you choose Execute in the User Information System. The result list displays all users with incorrect logon attempts:

¡        Number of incorrect logon attempts (users that are not locked)

¡        Users locked due to incorrect logon attempts

¡        Users locked by administration

¡        Users locked globally in the central system (if you are using CUA)

¡        Users locked locally and globally by the administration (if you are using CUA)

 

This evaluation also displays the date and time of the last logon.

·        By logon date and password change (RSUSR200)

·        With critical authorizations (RSUSR009)

·        With Critical Authorizations (New Version) (RSUSR008_009_NEW)

 

Important SAP Security Tables

Table	Description
USR02	Logon data
USR04	User master authorization (one row per user)
UST04	User profiles (multiple rows per user)
USR10	Authorisation profiles (i.e. &_SAP_ALL)
UST10C	Composit profiles (i.e. profile has sub profile)
USR11	Text for authorisation profiles
USR12	Authorisation values
USR13	Short text for authorisation
USR40	Tabl for illegal passwords
USGRP	User groups
USGRPT	Text table for USGRP
USH02	Change history for logon data
USR01	User Master (runtime data)
USER_ADDR	Address Data for users
AGR_1016	Name of the activity group profile
AGR_1016B	Name of the activity group profile
AGR_1250	Authorization data for the activity group
AGR_1251	Authorization data for the activity group
AGR_1252	Organizational elements for authorizations
AGR_AGRS	Roles in Composite Roles
AGR_DEFINE	Role definition
AGR_HIER2	Menu structure information - Customer vers
AGR_HIERT	Role menu texts
AGR_OBJ	Assignment of Menu Nodes to Role
AGR_PROF	Profile name for role
AGR_TCDTXT	Assignment of roles to Tcodes
AGR_TEXTS	File Structure for Hierarchical Menu - Cus
AGR_TIME	Time Stamp for Role: Including profile
AGR_USERS	Assignment of roles to users
USOBT	Relation transaction to authorization object (SAP)
USOBT_C	Relation Transaction to Auth. Object (Customer)
USOBX	Check table for table USOBT
USOBXFLAGS	Temporary table for storing USOBX/T* chang
USOBX_C	Check Table for Table USOBT_C

 

SAP Security FAQs - Application Level Security

What does the certification ITSEC E2 medium (SAP's security certification) mean?

SAP has received the ITSEC security certificate from the German Federal Office for Security in Information Technology (Bundesamt für Sicherheit in der Informationstechnik (BSI)).
SAP R/3 4.0B has been evaluated according to the Information Technology Security Evaluation Criteria (ITSEC) Version 2.1, June 1991 and the IT Security Evaluation Manual (ITSEM) Version 1.0, September 1993. The evaluation result was E2/Medium.
The certificate is recognized in the following countries: Germany, Finland, France, Great Britain, Italy, Holland, Norway, Portugal, Sweden, Switzerland, and Spain.
The ITSEC classification F-C2, E2 corresponds to the US TCSEC (Orange Book) classification C2. You can find further information on the ITSEC certification under the alias Security on the SAP Service Marketplace and in SAP Note 0077462.

Where do I get information about partners?

First, see the partner directory on the SAP Service Marketplace using the alias /partnerdir. Second, you can e-mail a question to security@sap.com with your details and we will try to answer your questions about partners.

Can specific transactions be allowed or disallowed on the backend?

This should be administered through a qualified authorization concept. All transactions you wish to give to a user should be integrated into a role using the Profile Generator (transaction PFCG). More information is provided by the training course CA940 (SAP R/3 Authorization Concept).

What security-related training courses are there?

BC940 (Security and Auditing), CA940 (SAP R/3 Authorization Concept), HR307 (Technical aspects in HR, one chapter concerning authorizations in HR), BC305 (Advanced System Administration, chapters about CUA, CCMS and auditing). In addition to the training offered by SAP, there are a variety of partners providing training in fields like Public Key Infrastructures and directory integration.

Where can I find more information about mySAP Technology for Security?

Use the aliases /Security and /Securityguide on the SAP Service Marketplace. You can also use the general e-mail Service@sap.com.
See also: composite SAP Note 30724.

Which Quick Links on the SAP Service Marketplace (http://service.sap.com) are relevant for Security?

/Security (Information and literature about all security topics)
/TCS (Information about the SAP Trust Center Service)
/AIS (Information about SAP's Audit Information System)
/Securityguide (Download the SAP Security Guide)
/Systemmanagement (Computer Center Management System (CCMS); a tool for System Monitoring and Alert Management)
/Securityconsulting (Consulting services from SAP concerning security)

You might also want to have a look on the website of SAPLabs, Palo Alto: wwwtech.saplabs.com/guidebooks. There are downloads of predefined roles available as well as info and downloads of the "Made Easy Guide Books" one of which is the "Authorizations Made Easy 4.6A/B Guide Book" explaining the Profile Generator and how to set up authorizations in detail.

Is there information available on a security review by SAP (costs, benefit, and so on)?

Refer to SAP Deutschland AG&Co.KG´s (SAP LGD) Security Consulting service (alias Securityconsulting on the SAP Service Marketplace).

 

SAP Security FAQs - Trust Relationship Management

How can I use a Single Sign On logon other than the SAP system logon with username and password (for example with Active Directory integration)?

For more information, see the documentation on "Pluggable Authentication Services" available at http://service.sap.com/security -> Security in Detail -> Trust Relationship Management -> Pluggable Authentication Services.

The document describes, for example, how you can use the Microsoft Windows NT/Windows 2000 standard logon as a Single Sign-On for SAP systems (including Employee Self-Service (ESS) systems). The Windows 2000 standard logon uses Active Directory. If you are using special user attributes through a direct access to Active Directory, you can still provide your own authentication service by attaching your library to the Pluggable Authentication Service interface on the ITS Agate component of your SAP ESS installation.

How do I use SSO for SAP and non-SAP web applications?

You can use SSO with non-SAP web applications by using mySAP Logon Tickets. After the first authentication (by the mySAP Workplace), the ticket is sent with each URL call. This means that your (non-SAP) applications also receive a ticket. This ticket can be verified. You can find sample programs for reading and checking tickets in the download area of the MiniApp community page (using Quick Link: miniapp). Please be aware that if you have two IIS instances running on two servers IIS_number1 and IIS_number2, they must be in the same webserver domain, such as

·          server1.workplace.yourcompany.com

·          server2.workplace.yourcompany.com.

SAP Passports - where can I learn more about it?

On SAP Service Marketplace you can find a detailed description of the process in the presentation "SAP Passports - How to Get Started". To test SAP passport functionality in your SAP Workplace, please generate a Certificate Request (CR) and send a message on component BC-SEC to SAP via SAPNet R/3 Frontend (OSS) or SAP Service Marketplace. We will send you the necessary certificate for your Registration Authority (RA).

How do Pluggable Authentication Service and X.509 certificates work together?

The Pluggable Authentication Service (PAS) is a way for the mySAP Workplace 2.11 to use external authentication, for example, by reusing the Windows NT logon (the user does not need to enter an additional username/password for the mySAP Workplace 2.11) for internal usage or, for example, for using Radius (SecurID Cards) for external usage of the mySAP Workplace as a portal. If you want to use certificate-based authentication, SAP components (as of SAP R/3 4.5) do not require PAS, since they natively support certificate authentication.

Do I need a license for Pluggable Authentication Service (PAS)?

Customers no longer need to license the mySAP Workplace to be able to use PAS. All they need is an ITS, which is free of charge.

What do I need to do to install and configure the Pluggable Authentication Service (PAS)?

In short, you need:
   - To install/modify an ITS service (SAP-proprietary)
   - To install/modify the HTML logon template (standard HTML)
   - In certain cases: write a DLL for connecting an external authentication server (such as Netegrity Siteminder, and so on)
For more information, see www.service.sap.com/security -> Security in Detail -> Trust Relationship Management ->Pluggable Authentication Service.

Does SAP offer a Trust Center?

Yes. For more information, see the SAP Service Marketplace using the alias /TCS. SAP offers client certificates, server certificates, for example, for Secure Socket Layer, and router certificates for service connections through SAPRouter.

What are trusted systems?

Trusted systems are systems with a relationship of trust between them. For example, if you have set up a trusted relationship between system A and system B, so that system A trusts system B, a user that has logged onto system A can start a transaction in system B without entering a password but using the user ID from system A. (This is important since a user ID and password in an RFC destination means that all connections result in the same user ID connecting.)

Where is the SAP Passport physically stored?

Passports are stored wherever the browser stores its certificates. In the case of Microsoft Internet Explorer, this is the registry. You can usually also replace the browser storage using a third party product, for example a smart card or a central Personal Security Environment (PSE) server.

What is Kerberos?

Kerberos is a network authentication protocol developed by the Massachusetts Institute of Technology (MIT). It is designed to provide strong authentication for client/server applications by using secret-key cryptography. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and the server to a client) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business. (Source: http://web.mit.edu/kerberos/www/ )

How do I integrate an external product like Kerberos into Secure Network Communication from SAP?

Secure Network Communication (SNC) is an SAP protocol that interfaces with security products such as Kerberos through the Generic Security Services Application Programming Interface (GSS API), in the context of SAP. Each SNC node needs to have a Personal Security Environment (PSE), where a key pair is stored, as well as public key certificates from other SNC nodes, and CA trust hierarchies, certification revocation lists, and so on. You also need to download a Kerberos GSS API package.

 

SAP Security FAQs - System Management

What are Secure Network Communication and Secure Socket Layer?

Secure Network Communication (SNC) is an interface that enables you to secure communication paths between SAP system components. Strong authentication, integrity protection, and privacy protection is provided. The actual protection is provided by an external security product that is available to the SAP system using the SNC interface. The interface complies with the Internet standard Generic Security Services Application Programming Interface (GSS API) version 2. The default product provided by SAP is the SAP Cryptographic Library, which you can use for SNC between SAP system server components.

Secure Sockets Layer (SSL) is an Internet standard protocol developed by Netscape that is used to secure communications across the Internet. The SSL protocol layer exists between the network layer protocol (for example, TCP/IP) and the application layer protocol (for example, HTTP). The protocol uses public key technology to secure the communication between a client and a server. The SSL protocol provides encrypted connections, SSL server authentication, SSL client authentication, and SSL mutual authentication (both server and client authentication).

To access Internet addresses that use SSL connections, you use URLs starting with HTTPS: instead of HTTP:. For more information, see:
http://www.netscape.com/security/techbriefs/ssl.html or
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

When and for what are SNC licenses required?

The SAP Crypto Software is free of charge for SNC implementations between SAP servers. The customer must purchase additional licenses from our partners for SNC implementations between the frontend and SAP server.

You use SNC principally to encrypt the communication channel. If the customer wants encrypted communication between the frontend and the SAP server and uses the WinGUI, the customer must purchase additional SNC licenses. This is also the case for Single Sign-On with WinGUI and the SAP server, which can only be implemented using SNC. If the customer uses Web-based access to SAP systems (using the WebGUI), the customer does not require additional licenses for Single Sign-On (this is implemented without SNC) and encryption between the frontend and the SAP server (this uses SSL).

Since when is it possible to secure RFC connections using Secure Network Communication?

Since SAP R/3 4.0.

What can I do to audit my system?

There are various mechanisms to audit your system described in the SAP WebASecurity Guide and the Audit Information System.(Transactions SM19, RZ20, RZ21 or SECR).

Does SAP require that all servers are run behind a firewall?

The realization of an independent SAP security concept is possible because SAP provides an application infrastructure with its own server and frontend components. Wherever possible, this concept is based on ensuring general end-to-end security. That is why no specific security components such as firewalls, reverse-proxies, or virtual private networks are presupposed. However, SAP does not have its own operating system and does support databases from other vendors, who are responsible for their own security concepts and mechanisms.

The SAP Security Guide explains in detail what precautions are necessary at operating system and database level to minimize the weaknesses of these components. This includes, for example, the separation of the administrators for the operating system, for the SAP system and for the database, the protection of the program and configuration files of the SAP system and the operating sytem, as well as the secure configuration of the network functions of the operating system. The SAP Security Guide can be found on the SAP Service Marketplace alias securityguide.

When using Single Sign-On products, is it possible to ensure that certain systems can only be accessed from specifc PCs?

You can do this using SAProuter (even without SNC). With SAProuter, you can control which IP addresses (client PCs) can access an SAP system, using an access control list.

What does the SAP Router do in the SAP secure environment?

The SAP Router is a program (executable file) that is included on the installation CD. Basically, the SAP Router regulates who (which address) is allowed to go to where (another address). This is configured in a number of files. More information is provided by the training course BC305 (Advanced R/3 System Administration).

Which algorithms are provided by the sapcryptolib?

The sapcryptolib implements the following interfaces: SSL, SNC, and SSF (without encryption). The algorithms that are used depends on the interface and protocol.

For SSL the SAPCRYPTOLIP needs an RSA-PSE. The following ordered list of ciphersuites from server and client is offered to the peer during the SSL handshake:

1. SSL_RSA_WITH_RC4_128_SHA
2. SSL_RSA_WITH_RC4_128_MD5
3. SSL_RSA_WITH_3DES_EDE_CBC_SHA
4. SSL_RSA_WITH_DES_CBC_SHA
5. SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
6. SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
7. SSL_RSA_EXPORT_WITH_RC4_40_MD5
8. SSL_RSA_WITH_NULL_SHA
9. SSL_RSA_WITH_NULL_MD5

For SNC/GSS-API you also need an RSA-PSE. The RSA procedure is used for authentication and key exchange. The connection is encrypted with 3DES-EDE "Triple-DES".

When creating a PSE for RSA keys 1024-bits are used per default, for DSA keys 512- bits are used per default. The DSA keys in the SAPCrypto are only used for the electronic signature of the SAPSECU (signed URLs for content server, SSO2 ticket)

A complete list of the implemented algorithms follows:

SYM_ENC Algorithms
rc2CBC	OID 1.2.840.113549.3.2, ?? Unidentified parameter:
rc4	OID 1.2.840.113549.3.4, NULL parameter
DES-ECB	OID 1.3.14.3.2.6, NULL parameter
DES-CBC	OID 1.3.14.3.2.7, Parameter DES-IV (default zeros)
DES3-CBC	OID 1.3.36.3.1.3.2.1, Parameter DES-IV (default zeros)
DES3-CBC-buggy	OID 1.3.36.3.1.3.2, Parameter DES-IV (default zeros)
DES-EDE	OID 1.3.14.3.2.17, NULL parameter
DES-EDE3-CBC	OID 1.2.840.113549.3.7, Parameter DES-IV (default zeros)
desECB	Same algorithm as DES-ECB
desCBC	Same algorithm as DES-CBC
desEDE	Same algorithm as DES-EDE
desCBC_pad	OID 1.3.36.3.1.5, Parameter DES-IV (default zeros)
desCBC_no_pad	OID 1.3.36.3.1.26, Parameter DES-IV (default zeros)
desECB3	Same algorithm as DES-EDE
desCBC3	Same algorithm as DES3-CBC
desCBC3_pad	OID 1.3.36.3.1.13, Parameter DES-IV (default zeros)
NullEncryption	OID 1.3.36.3.1.38, NULL parameter
DES-CBC-ISO0	OID 1.3.36.3.1.1.4.1.2, Parameter DES-IV (default zeros)
DES-CBC-ISO1	OID 1.3.36.3.1.1.4.1.1, Parameter DES-IV (default zeros)
DES3-CBC-ISO0	OID 1.3.36.3.1.3.4.1.2, Parameter DES-IV (default zeros)
DES3-CBC-ISO1	OID 1.3.36.3.1.3.4.1.1, Parameter DES-IV (default zeros)
desCBC3_nopad	OID 1.3.36.3.1.13.1, Parameter DES-IV (default zeros)
DES-EDE3-CBC-nopad	OID 1.2.840.113549.3.7.1, Parameter DES-IV (default zeros)
rc2CBC_nopad	OID 1.2.840.113549.3.2.1, ?? Unidentified parameter:
AES128-ECB	OID 2.16.840.1.101.3.4.1.1, NULL parameter
AES128-CBC	OID 2.16.840.1.101.3.4.1.2, Parameter DES-IV (default zeros)
AES192-ECB	OID 2.16.840.1.101.3.4.1.21, NULL parameter
AES192-CBC	OID 2.16.840.1.101.3.4.1.22, Parameter DES-IV (default zeros)
AES256-ECB	OID 2.16.840.1.101.3.4.1.41, NULL parameter
AES256-CBC	OID 2.16.840.1.101.3.4.1.42, Parameter DES-IV (default zeros)

 

ASYM_ENC Algorithms
RSA	OID 1.2.840.113549.1.1.1, NULL parameter
rsa	OID 2.5.8.1.1, Parameter Keysize (default 512)
encISO9796-2Withrsa	OID 1.3.36.7.2.1, NULL parameter
id-RSAES-OAEP	OID 1.2.840.113549.1.1.7, ?? Unidentified parameter

 

HASH Algorithms
RSA-MD2	OID 1.2.840.113549.2.2, NULL parameter
RSA-MD4	OID 1.2.840.113549.2.4, NULL parameter
RSA-MD5	OID 1.2.840.113549.2.5, NULL parameter
NIST-SHA	OID 1.3.14.3.2.18, NULL parameter
SHA-1	OID 1.3.14.3.2.26, NULL parameter
md2	Same algorithm as RSA-MD2
md4	Same algorithm as RSA-MD4
md5	Same algorithm as RSA-MD5
RIPEMD-160	OID 1.3.36.3.2.1, NULL parameter
ripemd160	Same algorithm as RIPEMD-160
sha	Same algorithm as NIST-SHA
sha1	Same algorithm as SHA-1

 

SIG Algorithms
NIST-DSA	OID 1.3.14.3.2.12, Parameter p, q, g
md5-DES-CBC	OID 1.3.6.1.5.3.1, Parameter DES-IV (default zeros)
md5-DES-CBC3	OID 1.3.36.3.1.33, Parameter DES-IV (default zeros)
md5-IDEA	OID 1.3.36.3.1.31, NULL parameter
md2WithRsa	OID 1.3.14.7.2.3.1, NULL parameter
md4WithRsa	OID 1.3.14.3.2.2, NULL parameter
md5WithRsa	OID 1.3.14.3.2.3, NULL parameter
sigS_ISO9796-2Withsha1	OID 1.3.36.3.4.2.2.1, NULL parameter
sigS_ISO9796-2Withripemd160	OID 1.3.36.3.4.2.2.2, NULL parameter
sigS_ISO9796-2rndWithsha1	OID 1.3.36.3.4.3.2.1, NULL parameter
sigS_ISO9796-2rndWithripemd160	OID 1.3.36.3.4.3.2.2, NULL parameter
shaWithRSASignature	OID 1.3.14.3.2.15, NULL parameter
sha1WithRSASignature	OID 1.3.14.3.2.29, NULL parameter
ecdsa-with-SHA1	OID 1.2.840.10045.4.1, ?? Unidentified parameter:
rsaSignatureWithsha1	OID 1.3.36.3.3.1.1, NULL parameter
dsa	Same algorithm as NIST-DSA
id-ecPublicKey	OID 1.2.840.10045.2.1, ?? Unidentified parameter
dsaWithSHA	OID 1.3.14.3.2.13, Parameter p, q, g
dsaWithSHA1	OID 1.3.14.3.2.27, Parameter p, q, g
dsaCommon	OID 1.3.14.3.2.20, NULL parameter
dsaCommonWithSHA	OID 1.3.14.3.2.21, NULL parameter
dsaCommonWithSHA1	OID 1.3.14.3.2.28, NULL parameter
md2WithRsaEncryption	OID 1.2.840.113549.1.1.2, NULL parameter
md4WithRsaEncryption	OID 1.3.14.3.2.4, NULL parameter
md5WithRsaEncryption	OID 1.2.840.113549.1.1.4, NULL parameter
sha1WithRsaEncryption	OID 1.2.840.113549.1.1.5, NULL parameter
md2WithRsaTimeDate	OID 1.3.36.3.1.22, NULL parameter
md4WithRsaTimeDate	OID 1.3.36.3.1.24, NULL parameter
md5WithRsaTimeDate	OID 1.3.36.3.1.25, NULL parameter
md5WithRsa_TelesecSig	OID 0.2.262.1.10.1.1.4, NULL parameter
id-dsa-with-sha1	OID 1.2.840.10040.4.3, No parameter
id-dsa	OID 1.2.840.10040.4.1, Parameter p, q, g

 

KEY AGREEMENT Algorithms
dhKeyAgreement	OID 1.2.840.113549.1.3.1, Parameter p, a
dhWithCommonModulus	OID 1.3.14.3.2.16, NULL parameter

When I attempt to download a copy of the SAP Cryptographic Libray, the download site contains a message about Export Control Regulations, but no link to download the library. How do I download the SAP Cryptographic library?

This download process on the SAP Service Marketplace has been developed specially, and has a very special mechanism. This ensures that SAP knows who has downloaded the software, - a flag is set internally in an SAP customer database after the download is complete. SAP AG needs to report to the German government offices who has received the software, because it contains cryptographic elements. This is one of the German export regulations.
This is also the reason why SAP employees see only the screen with the export regulation restrictions that says that they are not allowed to download the software. The SAP Service Marketplace knows (because of your login) that you are an SAP employee and are not allowed to download the software. Customers are also not allowed to download the software if either of the two conditions below is not met:

1.    The customer's COUNTRY must be released for download in our customer database, otherwise no customer in that country can download the software.

2.    The non-military flag is set in the customer record in the SAP customer database.

In the SAP customer database, where the customer records are maintained, there is a flag for "Non-military company". Every local SAP country organization has to verify for each customer whether that company is a "Non-military" company. For more information, contact Thomas Koleyko from the Corporate Export department at SAP AG in Walldorf.

To allow the customer to download the SAP Cryptographic Library, set the "Non-military" flag in the customer record in the SAP customer database system. Only if this is set, can the company download the SAPCryptoLib. Of course, you should first check if you are allowed to set this flag for the company. Please wait one day after this flag is changed in the SAP customer database (ISP) system, as it must be distributed to the SAP Service Marketplace. For more information, see SAP Note 397175.

Is it possible to enforce different authentication mechanisms, such as allowing ordinary users to use user ID/password while system administrators and so on use strong authentication-like certificates?

Yes, this is possible. For more information, see the relevant passage in our SNC cookbook (especially snc/accept_insecure_gui = U), which you will find on the SAP Service Marketplace under http://service.sap.com/security -> Security in Detail -> Secure Management System -> Secure Network Communications, and SAP Notes 379081 and 142595.

What are the license conditions for the SAP-Cryptographic Library?

See SAP Note 597059:

The "SAP Cryptographic Library" (SAPCRYPTOLIB) is available in the SAP Service Marketplace (http://service.sap.com) for software downloading (export control, see Note 397175):

Select the Quick Link in the SAP Service Marketplace: http://service.sap.com/download, then follow the link to "SAP Cryptographic Software".

The following "License Disclaimer" is contained (LICENCE.TXT) in the CAR archives provided for download there:

<Beginnning of Disclaimer>

License Disclaimer for the SAPCRYPTOLIB (SAP's Cryptographic Library)

The SAP Cryptographic Library may only be used as an integral part of SAP products and not as part of other non-SAP products.

The legal use of the SAP Cryptographic Library for Secure Network Communications (SNC) is limited to securing backend server components provided by SAP or entitled SAP partners. The use of the SAP Cryptographic Library for SNC protected communications on a personal computer that runs client components (for example, SAP GUI for Windows or SAP GUI for JAVA) is not permitted.

The use of the SAP Cryptographic Library to secure the SAProuter communication when using the SAPNet - R/3 Frontend for remote support is permitted without restriction.

<End of Disclaimer>

The following explanations on the license conditions for using the "SAP Cryptographic Library" (SAPCRYPTOLIB) are intended to prevent any misunderstandings:

The SAPCRYPTOLIB can be used both as an SNC product and as an SSL Toolkit. The restrictions listed in the "License Disclaimer" apply to the use of the SNC.

No further restrictions apply to the use of the SAPCRYPTOLIB as an SSL implementation in all SAP products. In other words, the SAPCRYPTOLIB may be used both in server and in frontend components, including for the SSL backup of the communication of SAP products for SAP or non-SAP products.