IP-based trusted connections enable users from “safe” machines to access Master Data Servers and repositories using their sign-on credentials only (without having to additionally provide Master Data Server and repository passwords).
IP-bases trusted connections are currently available to SAP system usernames only.
Users must still provide a DBMS password for operations which require a connection to the DBMS.
3.11.1 How IP-Based Trusted Connections Work
There are three basic elements in a trusted connection:
● Trusted System. The machine sending the connection request.
● Authenticated User. The username signed on to the trusted system.
● Master Data Server. The Master Data Server receiving the connection request.
Trusted systems are identified by IP address in a special file (allow.ip). In this file, you can enter IP addresses for individual machines or for an entire subnet. Requests from IP
addresses not included in this file are automatically denied. An optional file, deny.ip, lets you restrict specific IP addresses within an otherwise “allowed” subnet.
You must create the allow.ip and deny.ip files, they are not created automatically by MDM.
By default, the Master Data Server looks for allow.ip and deny.ip in the folder containing the Master Data Server executable file (mds.exe). You can change this location by modifying the TrustFilesDir parameter in the Master Data Server configuration file (mds.ini).
In order for users to connect to an MDM repository from a trusted connection, their usernames must exist on the MDM repository’s Users table.
Alternatively, if the Master Data Server is configured for LDAP use, the username must exist in the LDAP directory referenced in the Master Data Server configuration file.
If no matching username is found on the Users table or LDAP directory, access to the MDM repository is denied.
Once connected, users are permitted access to MDM repository data and functions based on the MDM role(s) assigned to their MDM or LDAP usernames.
Each Master Data Server must maintain its own trusted connections. The tables and parameters required for trusted connections are described below.
IP-Based Trusted Connections
File Description
allow.ip A flat, text-only file containing the IP addresses of trusted
systems. Connections requests from systems not included in this list are automatically denied.
Only one IP address can be entered per line.
Wildcards can be used to signify an entire subnet. For example, 10.17.79.* or 10.17.* or 10.*
Comments can be inserted by placing a # in the first column.
Placed by default in the same folder as mds.exe.
deny.ip A flat, text -only file containing the IP addresses of excepted machines in an allowed subnet. Connection requests from IP addresses in this file are denied.
Same comments as allow.ip.
File is optional.
mds.ini The parameter TrustFiles Dir identifies the location of the allow.ip and deny.ip files. This is set by default to the folder where the Master Data Server executable file (mds.exe) is located.
The Master Data Server must be restarted after modifying the allow.ip or deny.ip files.
3.11.2 SSL-Based Trusted Connections
For SSL-based authentication of trusted connections, the list of trusted distinguished names must be maintained in an allow.dn file, where each trusted distinguished name must appear on its own line in the file, in the format:
issuerName:<distinguished name>:subjectName:<distinguished name>
The batch scripts described in “Configuring SSL-Based Trusted Connections”
below create an allow.dn file formatted for use with MDM. If an allow.dn file already exists, the scripts will append distinguished names to the file provided.
3.11.3 Configuring SSL-Based Trusted Connections
Batch script files (*.bat) for creating and/or importing certificates for use with SSL-based trusted connections are included with MDM CLIX for Windows (version 7.1 SP8 Patch 1 and higher only). These files can be found in the CLIX installation directory.
The batch script files described below require JDK Java 1.5 to be installed on the Windows machine running the scripts.
IP-Based Trusted Connections
3.11.3.1 To Create PK12 Certificates and Import Them to MDM Key Storage Using the MDM Destination Administration Tool
1. Place the following items in a temporary directory on a Windows machine:
o genTrustedPK12.bat o sapgenpse.exe o sapcrypto.dll o SAPSSLS.pse
o allow.dn (if it exists, othewrise the batch file will generate it) 2. Run genTrustedPK12.bat
3. Copy the generated *.p12 client key and client.crt files to the trusted java API client host.
4. Copy SAPSSLS.pse to \usr\sap\<SID>\MDS<instance number>\sec on the MDS host.
5. Copy allow.dn to \usr\sap\<SID>\MDS<instance number>\sec on the MDS host..
6. Delete files from the temporary directory.
Steps to perform on the trusted Java API client host:
1. Open the MDM Destination Administration Tool.
2. Create a new MDM destination for a trusted SSL connection as follows:
1) In the Logon Parameters tab choose Client Certificate as the Trusted System Type.
2) In the Connection Parameters tab, import the client.crt and .p12 files to MDM Key Storage.
•
IP-Based Trusted Connections
3.11.3.2 To Create and Import Java KeyStore Certificates
1. Place the following items in a temporary directory on a Windows machine:
o genTrustedJKS.bat o sapgenpse.exe o sapcrypto.dll o SAPSSLS.pse
o allow.dn (if it exists, othewrise the batch file will generate it) 2. Run genTrustedJKS.bat
3. Copy the *.jks key file created by the batch script to machine where the java API client is hosted (see the MDM Java API Reference Guide for more information about including these files in your Java applications).
4. Copy SAPSSLS.pse to \usr\sap\<SID>\MDS<instance number>\sec on the MDS host.
5. Copy allow.dn to \usr\sap\<SID>\MDS<instance number>\exe on the MDS host.
6. Delete the files from the temporary directory
3.11.3.3 To Import Certificate Authority-Generated PK12 Certificates
1. Place the following items in a temporary directory on a Windows machine:
o importClientPK12ToServerPSE.bat o sapgenpse.exe
o sapcrypto.dll o SAPSSLS.pse
o PK12 file (*.p12)
o allow.dn (if it exists, othewrise the batch file will generate it) 2. Run importClientPK12ToServerPSE.bat
3. Copy the *.p12 key file to the java API client host.
4. Copy SAPSSLS.pse to \usr\sap\<SID>\MDS<instance number>\sec on the MDS host.
5. Copy allow.dn to \usr\sap\<SID>\MDS<instance number>\exe on the MDS host.
6. Delete the files from the temporary directory.
3.11.3.4 To Import Certificate Authority-Generated x509 Certificates
1. Place the following items in a temporary directory on a Windows machine:
o importClientCertToServerPSE.bat o sapgenpse.exe
o sapcrypto.dll o SAPSSLS.pse
o X509 certificate (*.crt)
o allow.dn (if it exists, othewrise the batch file will generate it) 2. Run importClientCertToServerPSE.bat
3. Copy SAPSSLS.pse to \usr\sap\<SID>\MDS<instance number>\sec on the MDS host.
4. Copy allow.dn to \usr\sap\<SID>\MDS<instance number>\exe on the MDS host.
5. Delete the files from the temporary directory.
IP-Based Trusted Connections
3.11.4 ABAP API Trusted Connection:
The ABAP API always passes the logged on AS ABAP user (sy-uname) to the Master Data Server. The AS ABAP user must also be available in the repository (this is not valid for an LDAP scenario) to be able to log onto that repository using the ABAP API. In particular, the Master Data Server trusts a specific AS ABAP server in the landscape.
3.11.5 Java/.NET Trusted Connection:
A specific system in the landscape can be trusted. If one of the APIs is running on the trusted system, it can access the Master Data Server or repository just by submitting an existing user name.
There is no control mechanism like in ABAP for the transmitted user name. You can pass an arbitrary user name to the Master Data Server.
The application on top of the API has to ensure that unauthorized access to the Master Data Server through user name is prevented.
Separation of Duties Support