Sie sind auf Seite 1von 29

Installation of SAPROUTER on OS/400

Document Version:

$Revision:

#16 $, $DateTime:

2015/05/18 09:56:33 $

Notation used througout this document


When describing CL-commands as usual the +-sign indicates lines to be continued:
Do no type the +-sign when typing these commands in interactive mode using the command
entry panel.
You must type the +-sign when the command is entered in a CL-source file which will be
compiled afterwards.

Components needed on OS level


Option 33 (PASE, 64-Bit) must be installed.

Software needed from SAP Service Marketplace


1. The SAPEXE.SAR package.
You need some parts from the SAPEXE.SAR-package. You can download it from the Software
Donwload Area at the SAP Service Marketplace:
Additional Components SAP Kernel SAP Kernel 64-Bit SAP Kernel 7.21 64-Bit
OS/400 #database independent. Here you need the package SAPEXE_<nnn>.SAR; get the
one with the highest patch level; it must be at least 500.
2. The SAPCAR program.
(a) In order to extract the downloaded SAP software you need the program SAPCAR. If you
do not have it available on your IBM i-System, you can download it from the Software
Download Area at the SAP Service Marketplace Additional Components SAPCAR
SAPCAR 7.21 OS/400.
After downloading the SAPCAR package from the marketplace (SAPCAR_<nnn>-########.EXE),
simply rename it as SAPCAR and move it to the /tmp/-directory on your IBM i-System. Then
proceed:
(b) Logon with QSECOFR
(c) Perform these steps
CALL QP2TERM
umask 022
mkdir -p
/usr/local/bin
cp /tmp/SAPCAR /usr/local/bin/
1

chmod 0755
/usr/local/bin/SAPCAR
rm /tmp/SAPCAR
<F3>
3. Documentation for SAPROUTER using the sapcrypto library.
The document https://support.sap.com/remote-support/help/installing-saprouter.html
describes the general steps in the setup of SAPROUTER with sapcrypto library for all supported
operating systems. The text you are reading now is largely based on this document; therefore
we strongy recommend to carefully check this document for more up-to-date information.
Please also have a look at the following documents on the Service Marketplace:
https://service.sap.com/saprouter/. General Information about SAPROUTER-Setup;
however the OS/400-specific parts are outdated.
http://service.sap.com/saprouter-sncdoc/. This is an older generic documentation
for the installation of the SAPROUTER using Secure Network Connection (SNC) with sapcrypto
Library, which doesnt include the OS/400 specifics. The links and general information may
still be of interest for you.

SAP notes needed


1. From 04/15/2015 11:00 AM CET until 07/18/2015 you need to get SAP note 2131531. Attached to that note you will find the old SAProuter SMP Root CA certificate; it is the file
smprootca.der. Copy this file to the /tmp/SRT/-directory of your IBM i-System.

Installing the contents of the packages on the IBM i-System


1. Logon as user QSECOFR.
2. Create a user profile and a group profile on your IBM i that will be used to run the SAPROUTER
In this document we call the user profile SAPRTADM; its primary group will be SAPRTGRP. Do not
use more than eight characters for the profile names to avoid some difficulties which otherwise
might arise with the PASE-subsystem:
CRTUSRPRF USRPRF(SAPRTGRP) PASSWORD(*NONE)
USRCLS(*PGMR)
+
TEXT(Group Profile for SAPROUTER)
CRTUSRPRF USRPRF(SAPRTADM) PASSWORD(XXXXXXXX) USRCLS(*PGMR)
+
TEXT(User to run SAPROUTER) SPCAUT(*SAVSYS) PWDEXPITV(*NOMAX) +
GRPPRF(SAPRTGRP) GRPAUT(*USE) GRPAUTTYP(*PGP)
GRTOBJAUT OBJ(RSTOBJ) OBJTYPE(*CMD) USER(SAPRTADM) AUT(*USE)
/* GRTOBJAUT OBJ(RSTLIB) OBJTYPE(*CMD) USER(SAPRTADM) AUT(*USE) */
CRTDIR DIR(/HOME/SAPRTADM) DTAAUT(*EXCLUDE) OBJAUT(*NONE)
2

CHGOWN
CHGPGP
CHGAUT
CHGAUT
CHGAUT

OBJ(/HOME/SAPRTADM)
OBJ(/HOME/SAPRTADM)
OBJ(/HOME/SAPRTADM)
OBJ(/HOME/SAPRTADM)
OBJ(/HOME/SAPRTADM)

NEWOWN(SAPRTADM)
NEWPGP(SAPRTGRP)
USER(SAPRTADM) DTAAUT(*RWX)
USER(SAPRTGRP) DTAAUT(*RX)
USER(*PUBLIC) DTAAUT(*NONE)

3. Create an IFS-directory for SAPROUTER (we call it /usr/sap/saprtrpase here, but you may
choose any name you want) do not forget to backup an existing /usr/sap/saprtrpase:
CALL QP2TERM
umask 022
# Save /usr/sap/saprtrpase to /usr/sap/saprtrpase-<YYMMDDHHMMSS>:
test -d /usr/sap && cd /usr/sap && test -e saprtrpase &&
mv saprtrpase saprtrpase-$(date +%C%m%d%H%M%S)
# Create a new empty /usr/sap/saprtrpase directory:
mkdir -p /usr/sap/saprtrpase
chown SAPRTADM:SAPRTGRP /usr/sap/saprtrpase
chmod 02750
/usr/sap/saprtrpase
<F3>
4. In one of the next steps we will create a library LIBROUTER containing the objects needed by
SAPROUTER; the name used is an example you can chose any name you want. Please backup
any existing library LIBROUTER, so that you are able to restore it, if the procedure described
here would fail:
/* Create a backup library LIBROUTER@:
*/
DLTLIB LIB(LIBROUTER@)
RNMOBJ OBJ(LIBROUTER) OBJTYPE(*LIB) NEWOBJ(LIBROUTER@)

/* May fail */
/* May fail */

The last command must only fail if LIBROUTER does not exist. Otherwise check if LIBROUTER is
still in use.
5. Log out.
6. Logon as user SAPRTADM.
7. Create a new empty library LIBROUTER for SAPROUTER:
CRTLIB LIB(LIBROUTER)
8. Copy the downloaded SAPEXE.SAR package to an IFS-directory; in this document we assume
that the package has been saved to the /tmp/SRT/-directory.

9. Extract the package; it is named like SAPEXE_<nnn>-<xxxxxxxx>.SAR, where <nnn> ist the
Version of the package and <xxxxxxxx> is an internally used number. In the following we will
name such a package like SAPEXE_<nnn>.SAR:
CALL QP2TERM
umask 002
PATH=/usr/local/bin:${PATH}; export PATH
cd /usr/sap/saprtrpase
mkdir SAPEXE
chmod 02770 SAPEXE
cd SAPEXE
SAPCAR -xvf /tmp/SRT/SAPEXE_<nnn>.SAR
cd ..
ln -s SAPEXE/libsapcrypto.o .
ln -s SAPEXE/saprouter
.
ln -s SAPEXE/niping
.
ln -s SAPEXE/sapgenpse
.
ln -s SAPEXE/ILE_TOOLS
.

#
#
#
#
#
#
#

Subst. <nnn> by the correct num.


Mind the ..
Mind the .
Mind the .
Mind the .
Mind the .
Mind the .

<F3>
10. Build up the ILE library:
CLRLIB LIB(QTEMP)
CPYFRMSTMF FROMSTMF(/usr/sap/saprtrpase/ILE_TOOLS)
TOMBR(/QSYS.LIB/QTEMP.LIB/ILE.FILE) MBROPT(*REPLACE)
RSTOBJ OBJ(*ALL) SAVLIB(QTEMP) DEV(*SAVF) OBJTYPE(*PGM *CMD)
SAVF(QTEMP/ILE)
CRTDUPOBJ OBJ(ILEWRAPPER) FROMLIB(QTEMP) OBJTYPE(*PGM)
TOLIB(LIBROUTER) NEWOBJ(SAPROUTER)
CRTDUPOBJ OBJ(ILEWRAPPER) FROMLIB(QTEMP) OBJTYPE(*PGM)
TOLIB(LIBROUTER) NEWOBJ(NIPING)
CRTDUPOBJ OBJ(ILEWRAPPER) FROMLIB(QTEMP) OBJTYPE(*PGM)
TOLIB(LIBROUTER) NEWOBJ(SAPGENPSE)
CRTDUPOBJ OBJ(CMDMAINP)
FROMLIB(QTEMP) OBJTYPE(*PGM)
TOLIB(LIBROUTER)
CRTDUPOBJ OBJ(SAPROUTER) FROMLIB(QTEMP) OBJTYPE(*CMD)
TOLIB(LIBROUTER)
CLRLIB LIB(QTEMP)

+
+
+
+
+
+
+

11. In order to work correctly with SAPROUTER, you need some kind of logon or configuration program,
an example of which is outlined here feel free to modify it according to your needs:

CRTSRCPF FILE(LIBROUTER/QCLSRC) MBR(LOGON)


Using e.g
EDTF FILE(LIBROUTER/QCLSRC) MBR(LOGON)
write the following CL program into the LOGON-Member allowing for lower case, as the /QOpenSysFilesystem is case-sensitive:
PGM
DCL VAR(&USER) TYPE(*CHAR) LEN(10)
CHGCURLIB LIBROUTER
CHGCURDIR DIR(/usr/sap/saprtrpase)
RTVUSRPRF *CURRENT RTNUSRPRF(&USER)
ADDENVVAR PASE_PATH
VALUE(/usr/sap/saprtrpase:/QOpenSys/usr/bin)
REPLACE(*YES)
ADDENVVAR PASE_LIBPATH
VALUE(/usr/sap/saprtrpase/SAPEXE:/QOpenSys/usr/lib)
REPLACE(*YES)
ADDENVVAR SECUDIR
VALUE(/usr/sap/saprtrpase)
REPLACE(*YES)
ADDENVVAR SNC_LIB
VALUE(/usr/sap/saprtrpase/libsapcrypto.o)
REPLACE(*YES)
ADDENVVAR USER
VALUE(&USER)
REPLACE(*YES)
ENDPGM

+
+
+
+
+
+
+
+
+
+

Create the CL-Program:


CRTBNDCL PGM(LIBROUTER/LOGON) SRCFILE(LIBROUTER/QCLSRC) SRCMBR(LOGON) +
DBGVIEW(*ALL)
12. Create the IFS file /usr/sap/saprtrpase/saprouttab acoording to your needs and the requirements of SAPROUTER with SNC (see below).

Creating a secure network connection (SNC) if needed


The tool sapgenpse
The main tool to work with when creating a secure network connection is the program SAPGENPSE. It
has several subcommands:
The command gen_pse is used to generate the saprouters PSE (Personal Security Environment)
file, which includes the public and private key pair and a public-key certificate.
A synonym for this command is get_pse.
If you are using a trusted CA, then you can also use the gen_pse command to generate a certificate
request. Per default, all of the items are generated, however, you can use the options -noreq or
-onlyreq to explicitly include or omit the certificate request:
Generating a public/private key-pair stored in the new PSE-file local.pse:
CALL PGM(SAPGENPSE) PARM(gen_pse +
-noreq -p <Path>/local.pse -x <PIN> <DN>)
Where PIN is an arbitrary passphrase which protects the PSE-file from unauthorized access
and DN ist the Distinguished Name or SNC Name:
<DN> := CN = <Common Name>, OU = <Org. Unit>, O = <Organization>, C = <Country>
Example:
CN=ABC, OU=Test, O=MyCompany, C=DE
So a valid call to SAPGENPSE could be
CALL PGM(SAPGENPSE) PARM(gen_pse -noreq -p /tmp/ex.pse
-x 123456789U_u CN=ABC, OU=Test, O=MyCompany, C=DE)

Generating a certificate request for the public key stored in the PSE specified by the -p
parameter and store it into the IFS-file given by the -r parameter:
CALL PGM(SAPGENPSE) PARM(gen_pse +
-onlyreq -p <Path>/local.pse -x <PIN> -r <reqfile>)
Example:
CALL PGM(SAPGENPSE) PARM(gen_pse -onlyreq -p /tmp/ex.pse +
-x 123456789U_u -r /tmp/reqf)
The command import_own_cert is used to import the CA-response to a PKCS#10 certification
request:
6

CALL PGM(SAPGENPSE) PARM(import_own_cert +


-c <CA-reponse-file> -p <Path>/local.pse -x <PIN>)
The command maintain_pk is used to display, add to, or delete certificates from the PKList of
a PSE. All of the certificates (public keys) in the PKList are fully trusted.
To add single certificate from <cert-file>:
CALL PGM(SAPGENPSE) PARM(maintain_pk +
-a <cert-file> -p <Path>/local.pse -x <PIN>)
Example:
CALL PGM(SAPGENPSE) PARM(maintain_pk -a /tmp/smprootca.der +
-p /tmp/ex.pse + -x 123456789U_u)
Output:
maintain_pk for PSE "/tmp/ex.pse"
Subject : CN=SMP Root CA, OU=Service Marketplace, O=SAP, C=DE
PKList updated (1 entries total, 1 newly added)
The command export_own_cert is used to export the own certificate from the PSE to the file
<output file>:
CALL PGM(SAPGENPSE) PARM(export_own_cert +
-o <output file> -p <Path>/local.pse -x <PIN>)

How to proceed
1. Go to: http://service.sap.com/saprouter-sncadd Trust Center Service in Detail
SAProuter Certificates Apply Now!-Button and get the Distinguished Name for your
SAPROUTER from the list of SAProuters registered for your installation.
The Distinguished Name normally is structured this way:
<Your Distinguished Name>
= CN=<saprouter-server-name>, OU=<cust-number>, OU=SAProuter, O=SAP, C=DE

2. Choose an arbitrary PIN or Passphrase to protect the PSE-Files that will be generated in the
following steps. These files are containers for the private and public keys used to encrypt and
decrypt the communication and should therefore be protected by a PIN.
3. Logon on as SAPRTADM
4. Build up the correct environment:
CALL PGM(LIBROUTER/LOGON)
5. Now create your private/public key-pair:
CALL PGM(SAPGENPSE) PARM(gen_pse -v +
-noreq
-p local.pse -x <your PIN> <Your Distinguished Name>)
It is stored in the IFS-file /usr/sap/saprtrpase/local.pse.
Please keep in mind, that here you have to use single-quotes around the distinguished name and
not double-quotes. You also have to provide the PIN via parameter -x, because the program
SAPGENPSE has no interactive mode on IBM i to request a missing PIN.
6. Now you create the SSO (Single Sign On) credentials for the SAPROUTER by another SAPGENPSE
subfunction namely seclogin:
CALL PGM(SAPGENPSE) PARM(seclogin -x <your PIN> -p local.pse)
The credentials are only valid for the currently logged in user, which must be SAPRTADM. They are
stored in the file /usr/sap/saprtrpase/cred_v2. For increased security change its permissions
so that ist is only accessible by the OS-user SAPRTADM which will be running the SAPROUTER:
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(SAPRTADM) DTAAUT(*RW)
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(SAPRTGRP) DTAAUT(*NONE)
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(*PUBLIC) DTAAUT(*NONE)
Check its permissions:
DSPAUT OBJ(/usr/sap/saprtrpase/cred_v2) SYMLNK(*NO)
This should give you an output like this:
Display Authority
Object . . . . . . . . . . . . :
8

/usr/sap/saprtrpase/cred_v2

Type . . . . . . .
Owner . . . . . .
Primary group . .
Authorization list

User
*PUBLIC
SAPRTADM
SAPRTGRP

.
.
.
.

.
.
.
.

Data
Authority
*EXCLUDE
*RW
*NONE

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

:
:
:
:

STMF
SAPRTADM
SAPRTGRP
*NONE

--Object Authorities-Exist Mgt Alter Ref


X
X

X
X

X
X

X
X

In the same way check the authorities of the file /usr/sap/saprtrpase/local.pse:


DSPAUT OBJ(/usr/sap/saprtrpase/local.pse) SYMLNK(*NO)
This should give you an output like this:
Display Authority
Object . . . . . .
Type . . . . . . .
Owner . . . . . .
Primary group . .
Authorization list

User
*PUBLIC
SAPRTADM
SAPRTGRP

.
.
.
.
.

.
.
.
.
.

Data
Authority
*EXCLUDE
*RW
*NONE

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

:
:
:
:
:

/usr/sap/saprtrpase/local.pse
STMF
SAPRTADM
SAPRTGRP
*NONE

--Object Authorities-Exist Mgt Alter Ref


X
X

X
X

X
X

X
X

The CHGAUT-step should not be necessary for the local.pse-file.


7. Generate the certificate request with the following command:
CALL PGM(SAPGENPSE) PARM(gen_pse -v +
-onlyreq -p local.pse -x <your PIN> -r certreq)
It is stored in the IFS-file /usr/sap/saprtrpase/certreq.
8. Display the output file certreq
DSPF STMF(/usr/sap/saprtrpase/certreq)
9

and with copy & paste insert the certificate request including the lines -BEGIN... and
-END... into the text area of the same form on the SAP Service Marketplace from which you
copied the Distinguished Name. In response you will receive the certificate signed by the CA in
the Service Marketplace, cut & paste the text to a local file named /usr/sap/saprtrpase/srcert.
As this signed certificate is quite long, it might be better to create this file with a PC based
text editor and then upload it via NetServer/400. You can now install the certificate in your
SAPROUTER with the following call:
CALL PGM(SAPGENPSE) PARM(import_own_cert -c srcert
-x <your PIN> -p local.pse)

9. From 04/15/2015 11:00 AM CET until 07/18/2015 you also need to import the old SAProuter
Root CA manually:
The old SAProuter SMP Root CA certificate is attached to SAP note 2131531. It is the file
smprootca.der. Copy this file to the /tmp/SRT/-directory of your IBM i
Import the old SAProuter SMP Root CA certificate as trusted into your PSE:
CALL PGM(SAPGENPSE) PARM(maintain_pk -a /tmp/SRT/smprootca.der +
-x <your PIN> -p local.pse)
This is necessary, since SAP has to keep using saprouter certificates signed by the old SAProuter
SMP Root CA for interoperability reasons. If you omit this step, SNC connections to SAP cannot
be established.
You should see an output like:
maintain_pk for PSE "/usr/sap/saprtrpase/local.pse"
Subject : CN=SMP Root CA, OU=Service Marketplace, O=SAP, C=DE
PKList updated (1 entries total, 1 newly added)
10. Check that the certificate has been imported correctly:
CALL PGM(SAPGENPSE) PARM(get_my_name -v -n Issuer)
The name of the Issuer should be:
CN=SAProuter CA, OU=SAProuter, O=SAP, C=DE
After 04/15/2015 tha name of the Issuer should be:
CN=SAProuter CA, OU=SAProuter, O=SAP Trust Community II, C=DE
10

If this is not the case, delete the files cred_v2, local.pse, srcert and certreq they are
in the IFS-directory /usr/sap/saprtrpase and start over with item 5 Now create your
private/public key-pair (page 8). If the output still does not match, please open an incident
at component XX-SER-NET stating the actions you have taken so far and the output of the
commands following Generate the certificate request.
11. You can check the expiration date of your certificate as follows:
CALL PGM(SAPGENPSE) PARM(get_my_name)
These certificates are only valid for one year, so dont forget to create and install a new one in
good time, otherwise it wont be possible to use the connection to SAP any longer. If you should
experience any problems, please open a customer message in component BC-OP-AS4, describing
what you have done so far and giving the output of each command you used.

Creating the saprouttab


Additional actions necessary before you can start SAPROUTER You have to setup a new saprouttab
as described in the following document: http://service.sap.com/saprouter-sncdoc. Please
edit the saprouttab as follows:
EDTF STMF(/usr/sap/saprtrpase/saprouttab)
The simplest saprouttab without any security is
# SAPROUTTAB without any security --- use only for testing
P * * *
# EOF
you should only use it to test your basic setup.
An example of a saprouttab which gives access only to a specific SAP-System is this one (without
SNC):
# SAPROUTTAB
##
#P/S/D <source-host> <dest-host> <dest-serv> <password>_opt
##
# Allow access from anywhere to SAP system running on host hostX
# with system number 61:
#
P
*
hostX
3261
# EOF
11

Example saprouttab for SNC connections registered to sapserv2 in Germany:


# SNC connection to and from SAP
KT "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" 194.39.131.34 *
# SNC connection to local system for R/3-Support
# R/3 Server: 192.168.1.1
# R/3 Instance: 00
KP "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" 192.168.1.1 3200
# SNC connection to local WINDOWS system for WTS, if applicable
# Windows server: 192.168.1.2
# Default WTS port: 3389
KP "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" 192.168.1.2 3389
# SNC connection to local UNIX system for SAPtelnet, if applicable
# UNIX server: 192.168.1.3
# Default Telnet port: 23
KP "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" 192.168.1.3 23
# SNC connection to local portal system for URL access, if applicable
# Portal server: 192.168.1.4
# Port number: 50003
KP "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" 192.168.1.4 50003
# Access from the local Network to SAP
P 192.168.*.* 194.39.131.34 3299
# deny all other connections
D * * *
Example saprouttab for SNC connections registered to sapserv9 in Singapore:
# SNC connection to and from SAP
KT "p:CN=sapserv9, OU=SAProuter, O=SAP, C=DE" 169.145.197.110 *
# SNC connection to local system for R/3-Support
# R/3 Server: 192.168.1.
# R/3 Instance: 00
KP "p:CN=sapserv9, OU=SAProuter, O=SAP, C=DE" 192.168.1.1 3200
# SNC connection to local WINDOWS system for WTS, if applicable
# Windows server: 192.168.1.2
12

# Default WTS port: 3389


KP "p:CN=sapserv9, OU=SAProuter, O=SAP, C=DE" 192.168.1.2 3389
# SNC connection to local UNIX system for SAPtelnet, if applicable
# UNIX server: 192.168.1.3
# Default Telnet port: 23
KP "p:CN=sapserv9, OU=SAProuter, O=SAP, C=DE" 192.168.1.3 23
# SNC connection to local portal system for URL access, if applicable
# Portal server: 192.168.1.4
# Port number: 50003
KP "p:CN=sapserv9, OU=SAProuter, O=SAP, C=DE" 192.168.1.4 50003
# Access from the local Network to SAP
P 192.168.*.* 169.145.197.110 3299
# deny all other connections
D * * *

Running the saprouter


1. Logon on as SAPRTADM
2. Build up the correct environment:
CALL PGM(LIBROUTER/LOGON)
3. Now you can start the SAPROUTER either using Secure Network Connection (SNC) or without
Secure Network Connection:
With SNC:
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab +
-K p:<Your Distinguished Name>)
Without SNC:
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab)
Per default the SAPROUTER will listen to the TCP-Port 3299. You may change this by using the
additional -S <Port Number> option when starting SAPROUTER.
To test the fundamental functionality of the SAPROUTER which runs on hostA, assume that there is
a SAP-system running on hostX with system number 61 and that we are using one of the non-SNC
13

saprouttabs mentioned above. Then the connection from the local SAPGUI running on your PC via
hostA to hostX (PC hostA hostX(61)) can be testet by using this SAPROUTER-String in your
SAPGUI:
/H/hostA/H/hostX/S/3261
or
/H/hostA/S/<SAProuter Port Number>/H/hostX/S/3261
For automation purposes, you might want to submit a program via SBMJOB into batch otherwise
an interactive terminal session will be blocked by the SAPROUTER. To this end write the following
CL-Program into the Member RUNSAPRTR of LIBROUTER/QCLSRC
With SNC:
PGM
CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab +
-K p:<Your Distinguished Name>)
ENDPGM
Without SNC:
PGM
CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab)
ENDPGM
and create the program RUNSAPRTR in library LIBROUTER:
CRTBNDCL PGM(LIBROUTER/RUNSAPRTR) SRCFILE(LIBROUTER/QCLSRC) +
SRCMBR(RUNSAPRTR) DBGVIEW(*ALL)
So you may submit this program as a batch job:
SBMJOB CMD(CALL PGM(LIBROUTER/RUNSAPRTR)) USER(SAPRXADM)

14

Cleaning up the directory /tmp/SRT/


In a final step you may want to clean up the directory by removing the SAR archives you downloaded
from the SAP Service Marketplace.

Troubleshooting
Problems with SNC
1. Logon on as SAPRTADM
2. Build up the correct environment:
CALL PGM(LIBROUTER/LOGON)
3. Provide the output of the following commands:
CALL PGM(SAPGENPSE) PARM(seclogin -l)
Typical output:
running seclogin with USER="SAPRTADM"
0: CN=<hostX>, OU=##########, OU=SAProuter, O=SAP, C=DE
/usr/sap/saprtrpase/local.pse
Options: LIFETIME= Wed, 12 Feb 2014 10:16:10 (GMT)
DIRACCESS=FALSE
CRLCHECK=FALSE
1 readable SSO-Credentials available
Typical error messages:
seclogin:

No SSO credentials available

or
running seclogin with USER="SAPRTADM"
0 (LPS:OFF): CN=<hostX>, OU=##########, OU=SAProuter, O=SAP, C=DE
(LPS:OFF): /usr/sap/saprtrpase/local.pse
NOT readable for SAPRTADM

NO readable SSO-Credentials available (total 1)

15

CALL PGM(SAPGENPSE) PARM(get_my_name -n validity)


Typical output:
SSO for USER "SAPRTADM"
with PSE file "/usr/sap/saprtrpase/local.pse"
Validity - NotBefore:
Tue Feb 12 11:16:10 2013 (130212101610Z)
NotAfter:
Wed Feb 12 11:16:10 2014 (140212101610Z)
Typical error messages:
get_my_name:

no PSE name supplied, no SSO credentials found

or
get_my_name: no PSE name supplied, SSO credentials not readable for you!
running seclogin with USER="SAPRTADM"
0 (LPS:OFF): CN=<hostX>, OU=##########, OU=SAProuter, O=SAP, C=DE
(LPS:OFF): /usr/sap/saprtrpase/local.pse
NOT readable for SAPRTADM

NO readable SSO-Credentials available (total 1)


ILEWRAPPER calling sapgenpse: Nonzero returncode of PASE program. (rc=21)
The (error) messages indicate possible problems with your SNC-Setup:
SNC-Setup was not completed.
The SNC-Setup was not done as user SAPRTADM.
You are outside of the validity period of the certificates.

Appendices
Appendix I: How to establish a SNC-connection between two SAProuters
To create a SNC-Connection between two SAProuters running on hostA and hostB respectively follow
these steps:
1. On each of the hosts substituting X by A and B do:

16

(a) Logon on to hostX as SAPRTADM


(b) Build up the correct environment:
CALL PGM(LIBROUTER/LOGON)
(c) Now create your private/public key-pair:
CALL PGM(SAPGENPSE) PARM(gen_pse -v +
-noreq
-p local.pse -x <your PIN> CN=SRThostX)
It is stored in the IFS-file /usr/sap/saprtrpase/local.pse.
Please keep in mind, that here you have to use single-quotes around the distinguished name
and not double-quotes. You also have to provide the PIN via parameter -x, because the
program SAPGENPSE has no interactive mode on IBM i to request a missing PIN.
(d) Now you create the SSO (Single Sign On) credentials for the SAProuter by another SAPGENPSE
subfunction namely seclogin:
CALL PGM(SAPGENPSE) PARM(seclogin -x <your PIN> -p
local.pse)

The credentials are only valid for the currently logged in user, which must be SAPRTADM.
They are stored in the file /usr/sap/saprtrpase/cred_v2. For increased security change
its permissions so that ist is only accessible by the OS-user SAPRTADM which will be running
the SAProuter:
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(SAPRTADM) DTAAUT(*RW)
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(SAPRTGRP) DTAAUT(*NONE)
CHGAUT OBJ(/usr/sap/saprtrpase/cred_v2) USER(*PUBLIC) DTAAUT(*NONE)
Check its permissions:
DSPAUT OBJ(/usr/sap/saprtrpase/cred_v2) SYMLNK(*NO)
This should give you an output like this:
Display Authority
Object . . . . . .
Type . . . . . . .
Owner . . . . . .
Primary group . .
Authorization list
Data

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

:
:
:
:
:

/usr/sap/saprtrpase/cred_v2
STMF
SAPRTADM
SAPRTGRP
*NONE

--Object Authorities-17

User
*PUBLIC
SAPRTADM
SAPRTGRP

Authority
*EXCLUDE
*RW
*NONE

Exist

Mgt

Alter

Ref

X
X

X
X

X
X

X
X

In the same way check the authorities of the file /usr/sap/saprtrpase/local.pse:


DSPAUT OBJ(/usr/sap/saprtrpase/local.pse) SYMLNK(*NO)
This should give you an output like this:
Display Authority
Object . . . . . .
Type . . . . . . .
Owner . . . . . .
Primary group . .
Authorization list

User
*PUBLIC
SAPRTADM
SAPRTGRP

.
.
.
.
.

Data
Authority
*EXCLUDE
*RW
*NONE

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

:
:
:
:
:

/usr/sap/saprtrpase/local.pse
STMF
SAPRTADM
SAPRTGRP
*NONE

--Object Authorities-Exist Mgt Alter Ref


X
X

X
X

X
X

X
X

The CHGAUT-step should not be necessary for the local.pse-file.


(e) Export your own public key to the file router_X.cer:
CALL PGM(SAPGENPSE) PARM(export_own_cert +
-o router_X.cer -p local.pse -x <PIN>)
2. Copy host_A:/usr/sap/saprtrpase/router_A.cer to host_B:/usr/sap/saprtrpase/ and copy
host_B:/usr/sap/saprtrpase/router_B.cer to host_A:/usr/sap/saprtrpase/.
Then on each of the hosts you will have the files router_A.cer and router_B.cer in the IFSdirectory /usr/sap/saprtrpase/.
3. Now you have to add each others key to the list of trusted public keys:
On host_A
CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPGENPSE) PARM(maintain_pk +
-a router_B.cer -p local.pse -x <PIN>)
On host_B
18

CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPGENPSE) PARM(maintain_pk +
-a router_A.cer -p local.pse -x <PIN>)
4. You need to maintain the saprouttab on each of the hosts:
On host_A
# Outbound connections to host_B will use SNC
KT "p:CN=SRThostB" host_B 3299
# Allow all inbound connections
P *
*
*
# EOF
On host_B
# Accept incoming SNC-connections from host_A to any host and any port
KP "p:CN=SRThostA" *
*
# EOF
5. Start both SAProuters:
On host_A
CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab +
-K p:CN=SRThostA)
On host_B
CALL PGM(LIBROUTER/LOGON)
CALL PGM(SAPROUTER) PARM(-r -R /usr/sap/saprtrpase/saprouttab +
-K p:CN=SRThostB)
Of course you should create CL-programs containing these commands.
6. Test the SAProuter connection: The program niping may be used to test the setup.
(a) Open a new 5250-Terminal-session to host_B and start niping in server mode:
CALL PGM(LIBROUTER/LOGON)
CALL PGM(NIPING) PARM(-s)
The server listens on TCP-port 3298, which could be changed by using the -S <Port Number>parameter.
19

(b) Open a new 5250-Terminal-session to host_A start niping in client mode:


CALL PGM(LIBROUTER/LOGON)
CALL PGM(NIPING) PARM(-c -H +
/H/localhost/S/3299/H/host_B/S/3299/H/localhost/S/3298)
If on host_A (the client side) it returns output like below the setup is complete:
Fri May 15 15:37:24 2015
send and receive 10 messages (len 1000)
Fri May 15 15:37:25 2015
------avg
max
min

times
0.298
0.655
0.251

----ms
ms
ms

Fri May 15 15:37:26 2015


tr
6545.325 kB/s
excluding max and min:
av2
0.260 ms
tr2 7519.249 kB/s

Appendix II: Help output of sapgenpse


The command CALL PGM(SAPGENPSE) PARM(-h) produces the output:
SAPGENPSE tool for creation and management of PSE-files and SSO-credentials
Usage: sapgenpse [-fips on/off] [-h] [-l <sapcryptoPath>] <command> \
[-h] [sub-options] ...
-l <sapcryptoPath>
-h
-fips on/off
<command>
<command> -h

Path of CommonCryptoLib (libsapcrypto.so) to be used


Show help text
Activate fips mode
Command to execute
Show help text of named command

All commands that create PSEs or Credentials support the option -lps.
(These commands are gen_pse, import_p12, import_p8, keytab, seclogin)
The -lps option enables the usage of the Local Protection Storage (LPS) to
20

protect the sensitive information stored in PSEs and Credentials.


An LPS protected PSE or credential could only be used on the same system
where it has been created.
The LPS uses one of the following mechanisms to protect the data:
- (DP ) The Microsoft Data Protection API, on Windows only
- (TPM) Trusted Platform Module (TPM), on Linux systems with an installed TPM
- (INT) Internal protection mechanisms, on all other systems
It is strongly recommended to use LPS to protect all PSEs and Credentials.
The command lps_enable can be used to enable LPS on existing PSEs.
The command seclogin can be used to enable LPS on existing credentials.

<command> must be one of:


gen_pse
create new PSE and/or PKCS#10 certification request
(same as "get_pse")
gen_verify_pse
generate a verify PSE
import_own_cert
import CA response to PKCS#10 certification request
seclogin
create/add/delete SSO-credentials for a PSE ("cred_v2")
or change PIN/Passphrase of a PSE
get_my_name
show attributes of the user certificate/keytab in a PSE
maintain_pk
show/add/delete trusted keys/certs in PKList of PSE
export_own_cert
export the user certificate of a PSE
import_p12
import a PKCS#12 digital ID transport file
export_p12
export a PKCS#12 digital ID transport file
pseconv
convert between PSE format v2 and v4
import_p8
create new PSE from PKCS#8 private key plus certs
keytab
manage keyTab in PSE
cryptinfo
show properties of Secure Login Crypto Kernel
lps_import
import a PSE (add LPS protection)
lps_export
export a PSE (remove LPS protection)
lps_enable
enables LPS protection of a PSE (in-place)
lps_disable
disables LPS protection of a PSE (in-place)
lps_show
show LPS protection state of a PSE
show
show file content and other information
passing "-h" after a <command> will show further help information
The command CALL PGM(SAPGENPSE) PARM(gen_pse -h) produces the output:
Create a new PSE and a PKCS#10 certification request or
or create a (renewal) PKCS#10 certification request for an existing PSE

21

Usage: gen_pse -p <pse-file> [other-options] [Distinguished name]


Options:
-p <pse-file>
-r <req-file>
-lps
-a <alg>

filename for (new) PSE


filename for PKCS#10 request (default: stdout)

-s <size>
-x <pin>
-noreq
-onlyreq
-2
-4

use LPS to protect the new PSE


algorithm DSA or RSA (default is RSA)
with GOST plugin: GostR3410-2001
key size in Bits (default=alg-specific, rsa=2048, dsa=1024)
PIN/Passphrase for PSE (default: query interactively)
do not create/print a PKCS#10 certification request
create PKCS#10 certification request for an existing PSE
create PSE format v2
create PSE format v4

-h
-v

print this help


verbose

Examples:
- create an lps protected file SAPSNCS.pse with server DName
(prompts for PSE password)
sapgenpse gen_pse -lps -p SAPSNCS.pse "CN=SAPServerABC, C=DE"
- create PKCS#10 certification request for an existing PSE
sapgenpse gen_pse -p SAPSNCS.pse -onlyreq -r cert.p10
- create an lps protected file SAPSNCS1.pse with server DName and PKCS#10 Request
(prompts for PSE password)
sapgenpse gen_pse -lps -p SAPSNCS1.pse "CN=SAPServerABC1, C=DE" -r cert1.p10
The command CALL PGM(SAPGENPSE) PARM(import_own_cert -h) produces the output:
Import the CA-response to a PKCS#10 certification request
Normally the CA-response should be a PKCS#7 response containing the
full certification path up to and including the RootCA certificate
However, a lot of CAs respond with only your signed certificate
-- in this case you will have to supply one or more additional
22

files with all intermediateCA and RootCA certificates that are


needed for a complete certification path using option -r.
Usage: import_own_cert -c <CA-reponse-file> [other-options]
Options are:
-p <pse>
-x <pin>
-c <file>
-r <file2>
-r <file3>

-h
-v

name of PSE file for which to import the CA-response


(default: try PSE from default SSO-credentials)
PIN/Passphrase for PSE (default: try SSO, query interactively)
file containing the CA response to the PKCS#10 request
(PEM, Base64 or DER binary)
additional file containing RootCA certificate(s)
"-r" may be used up to 10 times
for adding certificates
(PEM, Base64 or DER binary)
print this help
verbose (use multiple times for more details)

The command CALL PGM(SAPGENPSE) PARM(seclogin -h) produces the output:


Create, display or delete Single Sign-On (SSO) credentials
or alternatively change the PIN/passphrase on a PSE
! Changing a PIN of a PSE will not auto-update the SSO-credential!
! Adding a new credential will not auto-update an existing credential!
Usage: seclogin <mode-option> [<more-options>]
One of these <mode-option> selects the mode of operation:
-l
list SSO-credentials
-r
replace SSO-credentials
use this option if the PSE PIN/Passphase has been changed
or if your want to change the LPS protection of credentials
-chpin
change the PIN/passphrase of a PSE
-d
delete SSO-credentials
<none>
add an SSO-credential (at the end)
more Options for -chpin (Change PIN/Passphrase of PSE)
-p <pse-file>
filename for PSE
-x <pin>
PIN/Passphrase for PSE (default: no PIN, query interactively)
-xn <new-pin>
new PIN/Passphrase for PSE (default: query interactively)
more Options for -d

(delete SSO-credentials)
23

-p <pse-file>
<num>

delete SSO-credentials for this PSE


delete SSO-credential number <num> (default: first in list)

Options for -l
-O <username>

(list SSO-credentials)
list credentials for user <username>

Options for <none>


(create/add SSO-credential)
-lps
use LPS to protect the new SSO-credential
-p <pse-file>
create SSO-credential for this PSE (required parameter)
-x <pin>
PIN/Passphrase for PSE (default: no PIN, query interactively)
-1
insert new credential at the beginning of the list
-O <username>
create SSO-credential for OTHER user <username>
Options for -r
-lps
-p <pse-file>

-O <username>

(replace SSO-credential)
use LPS to protect the new SSO-credential
PSE for which SSO-credential should be changed (optional parameter)
Without this option, all readable credentials are changed.
Use -r without -p to change LPS mode for all credentials.
PIN/Passphrase for PSE (default: no PIN, PIN from old credential,
query interactively)
protect SSO-credential for OTHER user <username> (non LPS mode only)

-h
-v

print this help


verbose

-x <pin>

Examples:
- create lps protected SSO-credential for SAPSNCS.pse
(prompts for PSE password)
sapgenpse seclogin -lps -p SAPSNCS.pse -O abcadm
- replace one lps unprotected SSO-credential with lps protected SSO-credential
sapgenpse seclogin -r -lps -p SAPSNCS.pse
- replace all lps unprotected SSO-credentials with lps protected
SSO-credentials (password prompted if PSE has a new password)
sapgenpse seclogin -r -lps -p SAPSNCS.pse
- show SSO-credentials created for a dedicated user
sapgenpse seclogin -l -O abcadm
24

- delete SSO-credential for SAPSNCS.pse


sapgenpse seclogin -d -p SAPSNCS.pse
- delete SSO-credential Nr 1
sapgenpse seclogin -d 1
- change PIN / password of SAPSNCS.pse
sapgenpse seclogin -chpin -x <old_pin> -xn <new_PIN> -p SAPSNCS.pse
- replace old SSO-credential with new SSO-credential(password prompted
if SAPSNCS.pse has a new password)
sapgenpse seclogin -r -p SAPSNCS.pse -O abcadm
The command CALL PGM(SAPGENPSE) PARM(get_my_name -h) produces the output:
Display the attributes/properties of the user/owner certificate in a PSE
Usage: get_my_name [options]
Options are:
-p <pse-file>
-n <attribute>

-h
-v

which PSE to query (default: try SSO)


show only particular attribute(s)
<attribute> must be one of:
subject, issuer, serialno, keyinfo, validity, all
print this help
verbose (use multiple times for more details)

Examples:
- display the subject of SAPSNCS.pse
sapgenpse get_my_name -p SAPSNCS.pse -n subject -v
- display all attributes of SAPSNCSKERB.pse
sapgenpse get_my_name -p SAPSNCSKERB.pse

25

The command CALL PGM(SAPGENPSE) PARM(maintain_pk -h) produces the output:


Display, add to, or delete certificates from the PKList of a PSE
All of the certificates (public keys) in the PKList are fully trusted.
When someone elses certificate is verified (authenticated), it must
be directly signed by (or chained to) either our own key, our PKRoot
or one of the certificates (public keys) in PKList.
Usage: maintain_pk <mode-option> [more-options]
One
-l
-l
-l
-l
-a
-m

-d
-d
-f

of these <mode-options> selects the mode of operation:


display certificates/keys of PKList
PEMlist
display certificates/keys of PKList in PEM-framed base64
<num>
display certificate/key number <num> of PKList
<string>
display certificates/keys in PKList containing <string>
<cert-file> add SINGLE certificate from <file>
(PEM, Base64 or DER binary)
<cert-file> add MULTIPLE certificates from <file>
[<string>] (PEM, Base64 or DER binary)
if <string> is supplied, only certs where the subject name
contains <string> are considered/processed by add MULTIPLE
<num>
delete certificate/key number <num> from PKList
<string>
delete certificates/keys from PKList containing <string>
flush PKList entirely (delete all certificate/keys)

more Options:
-p <pse-file>
-x <pin>
-y

-h
-v

filename for PSE (default: use SSO-credentials)


PIN/Passphrase for PSE (default: try SSO, query interactively)
automatic YES-mode (for -m/-M add MULTIPLE certificates
and for -f and -d <string>)
print this help
verbose (use multiple times for more details)

The command CALL PGM(SAPGENPSE) PARM(export_own_cert -h) produces the output:


Exports ones own certificate from the PSE
If you want to configure trust between two PSEs, you need to add
one intermediateCA or RootCA cert from the certification path
of each PSE to the PKList (=Trustanchors) of each other PSE.
26

In a PKI-less scenario with self-signed certs (which can be


used, but is not recommended) you might import the Owner/End-Entity
certificate of each PSE into the PKList of each other PSE instead.
Usage: export_own_cert [options] [-o <output file>] [-p <pse file] [-x pin]
Options:
-p <pse-file>
-x <pin>
-r

filename for PSE (default: use SSO-credentials)


PIN/Passphrase for PSE (default: try SSO, query interactively)
export PKRoot (depending on output format used in -f)
x509:
export PKRoot instead of owner cert
pkcs7:
include PKRoot in cert chain
x509pkipathv1: this flag is currently ignored
-o <out-file>
write output to file <out-file> (default: STDOUT)
-f (x509,pkcs7,x509pkipathv1,PEMlist) select output format for own cert (chain):
x509
A single X.509 certificate (default)
pkcs7
pkcs7 container with cert chain
x509pkipathv1 X509PKIPathv1 container with cert chain
PEMlist
chain as PEM-framed base64
-b
output binary ASN.1 DER (instead of PEM-framed base64
(binary flag will be ignored when writing to stdout)
-h
-v

print this help


verbose

Examples:
- Export SAPSNCS.pse own certificate only and save it as file
(password prompted if no credentials available)
sapgenpse export_own_cert -o psecert.cer -p SAPSNCS.pse
- Export SAPSNCS.pse own certificate including certificate chain
without root certificate and save it as file
(password prompted if no credentials available)
sapgenpse export_own_cert -f pkcs7 -o psecert.p7b -p SAPSNCS.pse
- Export SAPSNCS.pse own certificate including certificate chain
including root certificate and save it as file
(password prompted if no credentials available)
sapgenpse export_own_cert -r -f pkcs7 -o psecert.p7b -p SAPSNCS.pse

27

- Export SAPSNCS.pse PKRoot only and save it as file


(password prompted if no credentials available)
sapgenpse export_own_cert -r -f x509 -o Rootcert.cer -p SAPSNCS.pse

Appendix III: Help output of niping


The command CALL PGM(NIPING) PARM(-h) produces the output:
Test Program for NI-Layer (network interface), Version 40, January 14 2008
running modes
start server
start client
self test
verify nodeaddr
interface list
MAC address list

niping
niping
niping
niping
niping
niping

-s
-c
-t
-v
-i
-m

additional options
-H hostname
name of server-host
(default
-S service
service-name or port-number
(default
-K sncname
SNC-name server
(default
-B bufsize
size of data-buffer
(default
-L loops
number of loops
(default
-V tracelev
trace level (0 - 3)
(default
-T tracefile
name of trace file
(default
-I idle time
maximum idle time
(default
t > 0 shutdown after t secs idle
t = 0 no automatic shutdown
t < 0 shutdown after -t secs idle or
first client disconnect (server only)
-R
raw mode
-P
detail print

localhost)
3298)
no SNC)
1000)
10)
1)
stdout)
300 sec)

expert options
-N timeout
for completion of fragmented packages (default 200 msecs)
-O
one way mode
-Q maxbytes
fragment test mode
-D delay
delay between sends
(default 0 msec)
--acl_file=acl-file # load acl-file (server mode)
--acl_check
# load and check acl and exit
28

--sock_buf_size=bufsize : socket send/receive buffer size in bytes


(only set if larger than OS defaults)
default: 32768
valid range: 0 - 10000000 (0 = OS defaults)

Check network connection between host A and B on NI-level


--------------------------------------------------------Start niping as a server (option -s) on host A. Then start
niping as a client (option -c) on host B.
The client sends <loops> packets of size <bufsize> which are
echoed by the server. The client then displays the average,
maximum and minimum round trip time.

Check the basic functionality of the NI-layer


--------------------------------------------To perform a self test on the local host start niping with
option -t. The last line of the output should contain
"*** SELFTEST O.K. ***" if no problems occured.

29

Das könnte Ihnen auch gefallen