PDF MDM Security Guide en

CUSTOMER
SAP NetWeaver Master Data Management 7.1

Document Version: 5.4 June 2017
MDM Security Guide

Content
Document History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Users, Roles, and Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Roles and Authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Predefined Users, Roles, and Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Single Sign-On. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Authentication and SSO-like Feature in MDM Java Components. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
User Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
iViews and UWL Authentication and the SSO-like Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
MDM Web Services Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Password Change Enforcement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Strong and Secure Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Password Validity Timeframe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
2.9 Unused Authorization Credentials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 User Account Locking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.11 CLIX Commands for Managing Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.12 User Administration Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.13 Emergency User Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.14 LDAP Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
LDAP in MDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Preparing MDM for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
MDM LDAP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
LDAP Server Data Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
LDAP Search Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
LDAP Errors and MDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Network and Communication Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Secure Communication Channels Using SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
3.2 Secure Connection Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 MDM Server Configuration for SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Connecting Securely from MDM Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Server Landscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
3.6 Communication Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Network Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
MDM Security Guide

2 CUSTOMER Content
3.8 Remote Function Call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.9 Secure Connection to Microsoft Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
3.10 Authentication of Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
IP-Based Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
SSL-Based Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
ABAP API Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Java/.NET Trusted Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Authorization Concepts and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Separation of Duties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Change Log for Authorization Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Change Log Archiving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1 Logging of Security-Relevant Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Content Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7 MDM File System Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1 MDM File Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.2 Session IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3 User Session Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
8 Regulatory Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1 Person-Related Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Data Protection and Privacy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9 Client Digital Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.1 Viewing Win32 Client Digital Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
MDM Security Guide

Content CUSTOMER 3
Document History
Table 1:
Document Version Description of Change
5.4 / June 2017 Guide updated for MDM 7.1 SP18.
Section 2.3, Predefined Users, Roles, and Passwords [page 9] states

that a password is predefined initially for the User Admin role.
A digital signature is added to win32 clients. See section Viewing Win32 Cli
ent Digital Signatures [page 57].
Updated the section Person-Related Data to cover Data Protection and Pri
vacy. See section Data Protection and Privacy [page 55]
5.3 / December 2016 Guide updated for MDM 7.1 SP17.
5.2 / June 2016 Guide updated for MDM 7.1 SP16.
Minor corrections to the section on LDAP support.
Added new MDM LDAP parameters in the section, MDM LDAP Parameters
[page 19].
Guide updated to standard format.
Reorganized section LDAP Support [page 17].
4.21 / June 2014 Corrected description of User Filter parameter in the section,MDM LDAP
Parameters [page 19].
4.2 / March 2014 Guide updated for MDM 7.1 SP12.
Added three new mds.ini parameters and updated descriptions of other

parameters in the section, MDM LDAP Parameters [page 19].
4.0 / March 2013 Guide updated for MDM 7.1 SP10.
New password requirement enforcement options added. See Strong and

Secure Passwords [page 12].
Updated the section,LDAP Support [page 17].
3.2 / August 2012 Guide updated for MDM 7.1 SP09.
Added note that you can configure a secure connection from MDS to the
Active Directory only when MDS is installed on a Windows platform.
MDM Security Guide

4 CUSTOMER Document History
Document Version Description of Change
3.1 / April 2012 Consolidated information from the MDM Console Reference guide into the
following sections:
LDAP Support [page 17]

Authentication of Trusted Connections [page 35]
3.0 / September 2011 Guide updated for MDM 7.1 SP08.
Secure Trusted Connection support added. See Authentication of Trusted

Connections [page 35].
New mds.ini option added for securing connections to Microsoft Active Di

rectory LDAP Server (MDS on Windows only). See Secure Connection to
Microsoft Active Directory [page 35].
Default Admin user password changed to sapmdm. See User Administra

tion Tools [page 16].
New CLIX commands added for password management operations. See

CLIX Commands for Managing Passwords [page 15].
New CLIX command added for emergency Admin user password creation.
See Emergency User Creation [page 16].
2.0 / May 2011 Guide updated for MDM 7.1 SP07
SSL support added. See Network and Communication Security [page

28].
MDM Security Guide

Document History CUSTOMER 5
1 Overview
An overview of the intended audience and scope of this security guide for SAP NetWeaver Master Data
Management (MDM) 7.1.
Target Audience
Technology consultants
System administrators
CIOs
Security experts
This document is not included as part of the Installation Guides, Configuration Guides, Technical Operation
Manuals, or Upgrade Guides. Such guides are only relevant for a certain phase of the software lifecycle,
whereby the Security Guides provide information that is relevant for all phases of the lifecycle.
Scope of this Guide
The MDM Security Guide describes the security only for SAP NetWeaver Master Data Management.
For information about other SAP components used in MDM scenarios, see the MDM Master Guide on the SAP
Help Portal at help.sap.com/nwmdm71.
Fundamental Security Guides
See the corresponding Security Guides for the SAP components that are a part of the MDM scenarios.
Table 2:
Application Guide Most Relevant Sections or Specific
Restrictions
SAPECC 6.0 SAP ERP 2005 Security Guide In the SAP ERP 2005 Security Guide,
choose Security Guides for SAPECC
6.0.
SAP NetWeaver Process Integration 7.1 SAP NetWeaver Security Guide In the SAP NetWeaver Security Guide,
choose Security Guides for SAP
NetWeaver Products SAP Security
Guide PI .
MDM Security Guide

6 CUSTOMER Overview
Application Guide Most Relevant Sections or Specific
Restrictions
Operating Systems and Database Plat SAP NetWeaver Security Guide In the SAP NetWeaver Security Guide,
forms choose Operating System and
Database Platform Security Guides.
For a complete list of SAP Security Guides, see service.sap.com/securityguide on SAP Service
Marketplace.
Components of SAP NetWeaver MDM
For a complete list of SAP NetWeaver MDM components, see the MDM Master Guide on the SAP Help Portal at
help.sap.com/nwmdm71.
MDM Security Guide

Overview CUSTOMER 7
2 Users, Roles, and Authentication
MDM provides its own user management. There are no user and role features delivered on top of the MDM
user management.
2.1 Users
You can set passwords for MDM Servers and users of MDM repositories.
Master Data Servers
By default, access to new Master Data Servers is not limited. You have to set a password to control access.
When mounting a Master Data Server for the first time using the MDM Console, make sure that you set a
password for the server. Select the MDM Server in the left window pane of the MDM Console window, and
choose MDM Servers Change Password .
MDM Repositories
You access MDM repositories with a user and password. SAP NetWeaver MDM uses its own mechanisms to
define users. You have to set passwords for the users to control access:
When creating a new repository, make sure that you set a password for the predefined Administrator user.
When updating an existing repository or unarchiving a shipped repository template, you have to use the
users and passwords that were already defined for the repository.
Note
You must log on to the repository at least once during an MDM Console session. This means that you have
to log on to a repository each time you start the MDM Console. The icon next to the repository name
indicates whether you have to log onto the repository.
For more information about updating repositories, see the MDM Upgrade Guide on the SAP Help Portal at
help.sap.com/nwmdm71.
MDM Security Guide

8 CUSTOMER Users, Roles, and Authentication
2.2 Roles and Authorizations
SAP NetWeaver MDM uses its own mechanisms for roles and authorizations.
Roles
Roles are assigned to users. Each repository contains the standard roles: Admin and Default. They cannot be
deleted. The Admin role cannot be changed. The Default role is predefined with full privileges.
Authorizations
Authorizations (called privileges in MDM) are assigned to roles and are edited in the Roles table. You can
granularly enable or disable authorizations for specific functions (such as Add Records or Delete Records) or
limit access to tables and fields (such as read/write access and constraints).
The following privileges are required to manage users, roles, and passwords:
Add user or role object

Modify user or role object
Delete user or role object
For more information, see the section, MDM User and Role Management, in the MDM Console Reference Guide
on the SAP Help Portal at help.sap.com/nwmdm71.
2.3 Predefined Users, Roles, and Passwords
A new repository has one predefined user and two predefined roles.
When creating a repository from scratch, there is one predefined user and there are two predefined roles. The
predefined user is the Admin user and the predefined Admin role is assigned to it. A password is predefined
initially for the User Admin role. It is very important to maintain a strong password for this user shortly after
creating the repository.
The other predefined role is the Default role. Initially it has full privileges. It is important to reduce these
privileges shortly after creating the repository.
2.4 Single Sign-On
MDM Security Guide

Users, Roles, and Authentication CUSTOMER 9
SAP NetWeaver MDM 7.1 does not support single sign-on. When a client application is used, user IDs and
passwords need to be provided to log on to the Master Data Server and the repositories.
The .NET and Java APIs use the user name and password or the trusted connection concept to log on to the
Master Data Server and the repositories. For more information, see Trusted Connections [page 10].
The ABAP API uses the trusted connection concept and extends this concept by always logging on with the sy-
uname of the logged on user on the AS ABAP.
2.5 Authentication and SSO-like Feature in MDM Java

Components
When using the Web Services Generator or iViews, you can use an SSO-like feature.
With the SSO-like feature in MDM, there is no need to re-authenticate between the application running on the
SAP NetWeaver Application Server Java (AS Java) and MDS. The same MDM session is kept for different
requests to the MDS issued by the same source.
The AS Java object for the SSO is the SAP logon ticket.
As SAP logon ticket evaluation is not currently supported in the MDS, the SSO-like feature is implemented in
the MDM applications on the AS Java.
2.5.1 User Management
For the SSO-like feature, the user authenticated for SAP NetWeaver Application Server Java (AS Java) should
be propagated to MDM.
You can do this with the following user configurations:
Same users in UME and MDS:

LDAP
User replication in both systems
Different users in UME and MDS:
User mapping to an MDM system using SAP NetWeaver Portal
User mapping to an MDM service user (constant user)
2.5.2 Trusted Connections
Trusted connection configuration has a direct influence on how authentication is performed and whether or
not the SSO-like feature is supported. See Authentication of Trusted Connections [page 35] for more
information about trusted connection configuration.
MDM Security Guide

2.5.3 iViews and UWL Authentication and the SSO-like
Feature
The following facets have an impact on the authentication mode and SSO-like feature support:
User mapping
User management
Trusted connection between SAP NetWeaver Application Server Java (AS Java) and MDM
User mapping is defined for a specific MDM system:
Same as in iViews and UWL in the MDM 5.5 release
Likely with authenticated session
Trusted connection also works
No user mapping: SSO-like feature
User management as described for same users in UME and MDS in User Management [page 10]
Trusted connection is required between AS Java and MDS
2.5.4 MDM Web Services Security
The Web Services Generator application is a Web application supporting basic HTTP authentication of SAP
NetWeaver Application Server Java (AS Java). MDM user credentials are inserted by the user in the Web
Services Generator wizard.
The Web services generated by the Web Services Generator have security capabilities.
SSL Support
The transport protocol for the generated Web services can be either SOAP over HTTP or SOAP over HTTPS.
You can also specify that the transport protocol for connecting generated Web services to the Master Data
Server has a secure connection.
Authentication
You can define the following authentication modes in the SAP NetWeaver Application Server Java (AS Java)
for the generated Web services:
No Authentication
An MDM constant user is defined in the Visual Administrator/Services/Configuration Adapter and its
MDM password is stored there.
Basic Authentication
User name and password of the Web service user are propagated to MDM. This requires user
management as described for same users in UME and MDS in User Management [page 10].
MDM Security Guide

Basic Authentication with SAP Logon Ticket
SAP logon ticket support as well as basic authentication can be enabled for the Web service. This requires
user management as described for same users in UME and MDS in User Management [page 10] and a
trusted connection between AS Java and MDS.
2.6 Password Change Enforcement
Users with the appropriate authorization (such as the Admin role) can create new users in the MDM Console.
End users can be forced to change their password after the first logon to the Master Data Server using one of
the MDM client applications.
This feature prevents the administrator from knowing the passwords of the end users.
Note
The admin-supplied password is not saved in the password history.
You can configure this initial password behavior by setting the flag User Must Change Password in the MDM
Console User Detail pane to Yes after creating a user. (The default setting for User Must Change Password is
No.)
This feature can also be used by the administrator to enforce a password change by the user at any time.
2.7 Strong and Secure Passwords
Strong and secure passwords are a combination of upper and lowercase letters, numbers and special
characters with a recommended length of approximately 12 14 characters. Passwords using personal
information like names or dates, user names or repetitions, dictionary words and sequences should not be
used.
From MDM 7.1 SP10, you can set a password policy to enforce end users to use strong and secure passwords.
A password policy can include one or more of the following requirements:
Minimum and maximum password length

Inclusion of uppercase and lowercase characters
Inclusion of at least one digit
Inclusion of at least one special character
Prohibition of the user name in the password
No reuse of recent passwords (password history)
Password requirement options are set in the mds.ini file. After setting these options, the new password
requirements are enforced for password changes or creation of new passwords.
The following sections describe the password requirements that you can set in the mds.ini file.
MDM Security Guide

Minimum and Maximum Length of Password
You can set the minimum and maximum length of passwords in the mds.ini file.using the following options:
Minimum Password Length

The default value for the minimum password length is 6. This is also the lowest value that is allowed for the
minimum password length.
Maximum Password Length
The default value for the maximum password length is 13. This is also the lowest value that is allowed for
the maximum password length. The highest allowed value is 255.
If the minimum password length is set to a value that is equal to or greater than the maximum password
length, the allowed password length will be a fixed value that is equal to the maximum password length.
Password Complexity Requirements
You can set password complexity requirements in the mds.ini file using the following options:
Password Must Contain Uppercase And Lowercase Letters

The default value is False. If set to True, an MDM user password must contain at least one uppercase letter
and one lowercase letter from a language that uses uppercase and lowercase.
Password Must Contain At Least One Digit
The default value is False. If set to True, an MDM user password must contain at least one digit.
Password Must Contain At Least One Special Character
The default value is False. If set to True, an MDM user password must contain at least one non-
alphanumeric character.
Password Cannot Contain
The User Name The default value is False. If set to True, an MDM user password must not contain the
corresponding user name.
Password Re-use
To increase password security, you can prevent users from reusing previous passwords by using the Number
Of Previous Passwords That Cannot Be Reused option in the mds.ini file.
The value that you set for this option determines the number of recent passwords that are stored in the user's
password history and cannot be re-used.
A password is saved in the password history when it is first defined. The default value of 1 means that only the
current password is saved, therefore, a new password must always be different from the current password.
You cannot define a value of less than 1. The maximum value allowed is 99. SAP recommends a value of at
least 3.
Note
The admin-supplied password is not saved in the password history.
MDM Security Guide

2.8 Password Validity Timeframe
Users are forced to change the password after the validity timeframe for the password has expired.
The validity timeframe of the password is maintained centrally in the mds.ini file located in the server
directory ..\sap\MAF\MDS {instance number}\config.
Two parameters are used for this setting:
Password Expiration Days=90

This option sets the number of days until a password will expire (here 90 days).
Password Expiration Warning=7
This option sets the number of days that warnings are sent before a user's password expires (here 7
days).
After the defined number of warning days, the user cannot log onto the system without changing his or her
password.
Note
Changes to the mds.ini file take effect only after a restart of the Master Data Server.
Direct changes to the mds.ini file are not logged by the MDM system and it is therefore advisable to limit
access to this file.
It is possible to define that the password for a user will never expire. The flag Password Never Expires in the
console user administration activates the described behavior if it is set to Yes.
2.9 Unused Authorization Credentials
Authentication credentials are not automatically deactivated if they have not been used for a certain period of
time.
The administrator should deactivate user accounts that are not in use by assigning a non-authorized role
and/or by assigning a secret password.
2.10 User Account Locking
The user account is locked after a defined number of failed password logon attempts for a defined length of
time.
The user account lock settings are maintained centrally in the mds.ini file located in the server directory ..
\sap\MAF\MDS {instance number}\config.
MDM Security Guide

Two parameters are used for this setting:
Lock Account After Failed Password Attempts=3

This option sets the number of failed password logon attempts allowed before the user account is locked
(here on the third failed attempt the account will be locked).
Lock Account Duration=1800
This option sets the duration of the password lock after the failed password attempts allowed (here 1800
seconds).
After the defined number of failed password logon attempts, the user cannot log on to the system for the
defined number of seconds.
Note
Changes to the mds.ini file take effect only after a restart of the Master Data Server.
Direct changes to the mds.ini file are not logged by the MDM system and it is therefore advisable to limit
access to this file.
The administrator can reset a locked account at any time. The flag Reset Account Lock in the console user
administration deactivates the lock if it is set to yes.
Note
The User Account Lock feature does NOT work for users with the Admin role. This prevents administrators
from lock out scenarios.
Tip
Keep the number of users with the Admin role as small as possible. Use especially strong passwords for
those users, as they are not protected against brute force attacks.
This feature can significantly slow down password brute force attacks if the number of allowed failed password
attempts is set to a low value and the lock duration is set to a relatively high value.
2.11 CLIX Commands for Managing Passwords
The repUser set of MDM CLIX commands enable administrators to get information about, change, expire,
and unexpire passwords for repository users.
For complete information about these commands, see the CLIX Command Reference on the SAP Help Portal
at help.sap.com/nwmdm71.
MDM Security Guide

2.12 User Administration Tools
SAP NetWeaver MDM uses its own mechanism to define users.
The following table shows the tools used for user management and user administration with the business
scenario.
Table 3:
Tool Detailed Description
DBMS Use the user management of your DBMS.
MDM Console Use the user management as described in the MDM Console Reference Guide. In
the MDM Console you define the MDM user.
Java / .NET / ABAP APIs All available APIs offer functions for user management. You can build your own
user management tools on top of the APIs.
MDM CLIX The repUser set of MDM CLIX commands enable administrators to get infor
mation about, change, expire, and unexpire passwords for repository users.
Standard User
The following table shows the standard user created by the system when you build a repository from scratch.
Table 4:
System User ID Password Description
MDM Repository Admin sapmdm MDM Installation Guide
MDM Console Reference

Guide
2.13 Emergency User Creation
You can create an emergency user to access a system in case of loss of all administrative user credentials.
To create a new password for the Admin user of an MDM repository, use the CLIX command
repEmergencyAdminUserSetPassword. For complete information about this command, see the CLIX
Command Reference on the SAP Help Portal at help.sap.com/nwmdm71.
MDM Security Guide

2.14 LDAP Support
Some MDM customers require support for LDAP (Lightweight Directory Access Protocol) within the MDM
system. This section discusses the various issues of LDAP use within MDM.
Note
From MDM 7.1 SP06 and higher, to use LDAP authentication for MDM users on HP-UX 11.31, you must have
Mozilla LDAP C SDK 5.17 installed. For support, contact your Hewlett-Packard (HP) vendor.
What is LDAP?
LDAP allows a company to control, configure and distribute user privileges, rights, and access from a single
location.
Without LDAP, the system manager is forced to maintain familiarity with the proprietary access control
mechanism offered by each software product, and to use each one to separately maintain access control
information every time an employee is hired, moves, changes job within the organization, and so on.
Imagine a company with thousands of employees and dozens of programs requiring access control, and it
becomes clear how much of a burden it can be to manage access control without LDAP.
By contrast, by using MDM in conjunction with LDAP, MDM customers can manage access control information
in a single location with a common, familiar interface of their choosing.
How LDAP Works
LDAP acts as a lookup into a directory, very similar to using a telephone book. For example, you can perform a
general search, such as one that returns all instances of Mary Lamb. In BigFoot, this returns 100+ records in
the United States. Or you can restrict the search by adding in California to the search, which then returns 6
records.
It turns out that the BigFoot search engine is based on an LDAP directory that includes Name and State
lookup categories. Owners of LDAP directories can retrieve additional fields, categories, or attributes, such as
Telephone Numbers, Primary Automobile, Hair Color, or MDM User Type. This additional information
can be used as well for additional selection criteria.
For MDM to support LDAP, SAP has designated the information that MDM will be querying from and that must
be entered and maintained within the customers LDAP database/directory.
2.14.1 LDAP in MDM
Using LDAP within MDM conforms to the following guidelines:
MDM Security Guide

The customer is responsible for the maintenance and design of their LDAP directory. They must inform
MDM of several LDAP directory fields and attributes so that MDM can properly search for user
information. Unless an existing field is used, the customer must create one attribute field (named as
desired) for MDM use.
The MDM software adds no records to the LDAP directory, nor does it otherwise manage or make any
design changes to its structure. It only performs lookups from the LDAP directory to read its contents.
Single sign-on is not supported. Instead, MDM client software prompts the user for name and password. It
was done this way for simplicity, interoperability with UNIX systems, and flexibility with various client
programs or network configurations such as VPNs.
MDM supports either LDAP users or MDM users, but not both simultaneously.
MDM does not support connections to multiple LDAP directories.
MDM LDAP Fields
The MDM LDAP fields are defined or created and then populated by the customer in the customers LDAP
directory. Presently, MDM makes use of LDAP user group assignments, stored in LDAP fields. In rare cases
when LDAP user group assignments cannot be used, MDM requires the addition of only one attribute field
(unless an existing field is used):
MDMRoles a list of role names separated by semi-colons (;)
Note
While SAP suggests the name MDMRoles, you can choose any name that suits your situation.
Since LDAP allows multiple instances of an attribute, MDM concatenates multiple entries as though they were
in a single record separated by semi-colons (;).
2.14.2 Preparing MDM for LDAP
Making MDM LDAP-aware includes the following:
Inspect or configure the mds.ini file to determine whether MDM uses proprietary user validation or LDAP
validation (see MDM LDAP Parameters [page 19]).
After configuring the mds.ini file for LDAP validation, run a Verify > Repair operation on all repositories
mounted on a Master Data Server
If using an LDAP viewer, perform security validation and retrieve role information from LDAP (see LDAP
Search Algorithms [page 24]). Use the role names retrieved from LDAP rather than the MDM repository
to initialize the user and login. Any roles that are not found in the current MDM repository are ignored, and
if none of the roles in the LDAP list are found, the user is prevented from logging in.
Note
Role names within MDM cannot contain semi-colons (;) nor start with an exclamation point (!), as
enforced by MDM Console.
MDM Security Guide

The MDM administrator must design a role-naming scheme to suit the particulars of the MDM installation/
implementation. If there is more than one MDM repository (such as test and development repositories, subset
repositories, and so on), these will all share the role names that are stored in LDAP.
Note
While roles are designed and named via the MDM software, they are assigned to users via LDAP,
centralizing this information outside of specific MDM repositories. For multi-repository environments, you
may need to name roles in an MDM repository keeping in mind other repositories that could use the same
role names. By having unique roles across all repositories, you can effectively control specific repository
access to your users.
Using MDM LDAP Fallback
When MDS uses LDAP (LDAP in Use=True), user validation can fail for several reasons; for example, the
LDAP server cannot be reached or the username does not exist on that LDAP server.
When Fallback in Use=True, MDM first tries to find the user in the LDAP server, and if it is not there,
MDM then looks for the user in the repository.
When Fallback in Use=True and Use Cache=True, MDM first tries to find the user in the LDAP data
cache, and then in the LDAP server. If it is not there, MDM then looks for the user in the repository.
This parameter is relevant only for the login phase. After the user has logged in, the parameter has no further
meaning. MDM continues to work in LDAP mode and does not recognize any of the users that are saved in the
MDM repository.
2.14.3 MDM LDAP Parameters
All LDAP access is performed by the MDS (Master Data Server). Clients of the MDS provide MDMUserName/
MDMUserPass values, which MDM then validates with LDAP.
LDAP contact information and other parameters relevant to MDM are maintained in the secure mds.ini file in
a separate section named [MDM LDAP].
If this section is absent, LDAP use is disabled.
Table 5:
Parameter Description
LDAP in Use Whether MDM should use LDAP. Options are True or False.
Server LDAP system address (usually a DNS name). The LDAP Server specifica
tion can be either a hostname or an IP address to which MDM attempts to
Server Port
bind; optional Server Port defaults to 389.
MDM Security Guide

Admin DN The full distinguished name (DN) and password of an Admin that can search
for the users full DN.
Admin Password
For backward compatibility with previous releases, MDM will construct a
missing Admin DN from the following settings: Admin Identifier,
Admin Name, and Base DN.
MDM does not need to be an administrative user to browse the directory.

Leave both Admin DN andAdmin Password blank if directory setting al
lows anonymous binding.
Base DN The node from which MDM starts to search in the LDAP server, for example,
o=sap,c=US. This node includes users, groups, and more.
Users Base DN To optimize the search, define the subnode under the Base DN from which
to start the search for user information.
Note
If you define both Users Base DN and Groups Base DN, MDM ig
nores the Base DN setting. If only one of them is defined, MDM uses
Base DN for the other.
Groups Base DN To optimize the search, define the subnode under the Base DN from which
to start the search for group information.
Note
If you define both Users Base DN and Groups Base DN, MDM ig
nores the Base DN setting. If only one of them is defined, MDM uses
Base DN for the other.
User Identifier The name of the LDAP ID field that will match the value that the user pro
vides as the Username at logon, such as cn or uid.
MDM Roles Attribute The name of the LDAP attribute that contains the group assignments, such
as memberOf.
MDM Email Attribute The name of the LDAP attribute that contains the email addresses that are
assigned to users, and is required for workflow. Usually this name is mail.
Fallback in Use When set to True, if the LDAP server is not available or the user does not
exist in the LDAP server, MDM will attempt to find user information in the re
pository.
This parameter is relevant only for the login phase and should be used care
fully. When using this parameter our recommendation is to set only one user
in the repository, which should be read-only since company security should
be based on LDAP alone (if Use LDAP=True).
The default is False.
Group Identifier The name of the LDAP attribute that identifies groups, such as cn or
samAccountName. This field is mandatory for group mapping algorithms.
For more information, see LDAP Search Algorithms [page 24].
MDM Security Guide

Member Attribute (Optional) The name of the LDAP attribute that lists all members of an LDAP
group, such as member. Use this field, for example, with LDAP server IBM
Tivoli. For more information, see LDAP Search Algorithms [page 24].
Page Size The number of records sent by the LDAP server per page. Default is 1000.
This value does not need to changed unless LDAP performance is problem
atic and you need to retrieve much more than 1000 records per search from
the LDAP server.
User Filter (Optional) Use this parameter to improve performance by limiting the user
search results to LDAP user records only.
For example, if you set User Filter=&(objectClass=person)

(Uid=*), the additional condition objectClass=person limits the re
sult set on the LDAP server side to user records only.
This applies to all different search algorithms for users and groups.
Group Filter (Optional) Use this parameter to improve performance by limiting the group
search results to LDAP group entries only.
For example, if you set Group Filter=groupOfNames=*, the follow

ing search is executed:
ldapsearch ... baseDN (&(groupOfNames=*)

(groupIdentifier=MDM RoleName))
Group Identifier is the name of the LDAP ID field that matches the
MDM role name, such as cn or samAccountName.
The additional condition limits the result set on the LDAP server side to spe
cific role records only.
This applies to all different search algorithms for users and groups.
Secure Connection to Active Specifies whether the MDS connects securely to the Microsoft Active Direc
Directory tory LDAP server. Possible values are True or False.
Note
You can configure a secure connection from MDS to the Active Directory
only when MDS is installed on a Windows platform.
User ObjectType DN (Optional) Use this parameter to specify that the user identifier attribute re
lates to a user. This optimizes the search operation in the LDAP server and
limits the search to users only.
For example:
Active Directory: User ObjectType DN=objectClass=user

Open LDAP: User ObjectType
DN=objectClass=inetOrgPerson
MDM Security Guide

Group ObjectType DN (Optional) Use this parameter to specify that the group identifier attribute
relates to an LDAP group. This optimizes the search operation in the LDAP
server and limits the search to LDAP groups only.
For example:
Active Directory: Group ObjectType DN=objectClass=group
Enable Case Sensitive Login (Optional) From MDM 7.1 SP11, you can use this option to cancel the case-
sensitive limitation for login to MDM using LDAP.
This limitation was added in MDM 7.1 SP08 and cannot be cancelled in re
leases SP08 through SP10.
All LDAP parameters except LDAP in Use can be changed in mds.ini without having to stop and restart
MDS. You must run a Verify > Repair operation on all repositories mounted on a Master Data Server after
changing the servers LDAP in Use parameter.
2.14.4 LDAP Server Data Cache

You can set up a cache for LDAP server data.
Whenever MDM needs information about user permissions or user names, MDM queries the LDAP server. In
order to improve performance you can set up a cache for user names, user email addresses, and user groups.
Note
The cache is not used for login operations.
To set up and use the cache for LDAP server data, add the following parameters to the [MDM LDAP] section in
the mds.ini configuration file:
Table 6:
Use Cache Set the value to True to use the internal MDS cache for LDAP server data. The
default is False.
Cache Update Interval MDM checks at the specified interval whether the LDAP data cache needs to be
updated.
The default is 24 hours.
Sample Code
Use Cache=True
Cache Update Interval=24
Changes to these parameters in mds.ini take effect after MDS is restarted.
MDM Security Guide

After enabling the cache for LDAP server data, MDM adds the following parameters to mds.ini. These
parameters are required for checking whether any changes were made in the LDAP server data since the last
check.
If you make changes to the following parameters, you do not need to restart MDS.
Table 7:
Create Time Stamp The name of the property in the LDAP server that stores the time stamp when a
Identifier user or role was created in the LDAP server.
MDM tries to detect the LDAP attribute name according to known values,
whenCreated or createtimestamp. If one of these values is detected, it is
added automatically to mds.ini.
If your LDAP server does not use one of these known values, the LDAP cache will
not start. In order to enable LDAP cache functionality, modify this parameter
with the attribute name that is used by your LDAP server.
Modify Time Stamp The name of the property in the LDAP server that stores the time stamp of the
Identifier last update of the user or role in the LDAP server.
MDM tries to detect the LDAP attribute name according to known values,
whenChanged or modifytimestamp. If one of these values is detected, it is
added automatically to mds.ini.
If your LDAP server uses a different property name, you must modify this param
eter accordingly.
DateTime End Trail The trailing characters of the Date/Time string in the Modify Time Stamp attrib
ute in the LDAP server, which is used when checking whether the LDAP server
was modified since the last check. For example, 201611131200.Z is the Date/
Time string for 2016-11-13:12:00, and the trailing characters are .Z.
If your LDAP server is in a Windows environment, the default value is .0Z

If your LDAP server is in a UNIX environment, the default value is .Z.
If you manually set values for Create Time Stamp Identifier and Modify Time
Stamp Identifier properties, you should also manually set the DateTime End Trail
property as MDM will not attempt automatically to find the value for the prop
erty.
In order to enable LDAP data cache operations, the following entries in mds.ini are required and should be
configured with relevant data:
Users Base DN
Groups Base DN
For more information, see MDM LDAP Parameters [page 19].
Once the LDAP data cache is enabled in MDS, MDM retrieves requested information from the cache and does
not request information from the LDAP server except for login information and required updates to the cache.
MDM Security Guide

The information in the cache is automatically updated from the LDAP server on the following actions:
Loading MDS
Any changes in MDM roles (add, remove, or modify)
After mounting a repository
In the following cases, MDM checks whether any changes were made to the LDAP data before updating the
LDAP cache:
After checking the LDAP server for changes at the interval specified in mds.ini
On loading the repository
After a repository update
After a login by a user that exists in the LDAP server but not in the LDAP cache
When a cache update is required:
The LDAP cache manager rejects new requests for LDAP cache data and it redirects them to the LDAP
server.
After MDS finishes the last request, the LDAP cache update operation starts.
Once the update operation starts, all requests for internal cache data are rerouted to the LDAP server
directly.
When the cache update operation finishes, MDM continues to serve user and role requests from the
cache.
Note
You can manually refresh the LDAP cache with updated LDAP server data using the CLIX command
repRefreshLDAPCacheData. For more information, see the section, Repository Control Commands, in the
CLIX Command Reference.
2.14.5 LDAP Search Algorithms
MDM uses different methods to search in LDAP depending on the LDAP parameter settings in the LDAP
section of the mds.ini file:
Group member search: Used when both Group Identifier and Member Attribute parameters are
set.
Group filter search: Used when Group Identifier is set but Member Attribute is empty.
Attribute search: Used when Group Identifier is empty.
Group Member Search
The group member search algorithm retrieves information for all users assigned to the specified group, as
follows:
1. The group DN of every MDM role is retrieved.
MDM Security Guide

2. All members of the group are identified by the group DN.
3. The user information for all members is retrieved.
In the actual implementation, the user information is not retrieved for every user individually, since
performance would be affected by the large number of individual LDAP calls. Instead, the user information is
requested in chunks to lower the number of LDAP calls.
The group member search algorithm works for LDAP servers with the following mds.ini file settings:
User Identifier=samAccountName
Group Identifier=samAccountName
MDM Roles Attribute=memberOf
Member Attribute=member
The algorithm also works for IBM Tivoli with the following mds.ini file settings:
User Identifier=Uid
Group Identifier=cn
MDM Roles Attribute=ibm-allGroups
Member Attribute=ibm-allMembers
You can also use this search algorithm with other LDAP directory brands, such as, OpenLDAP, Sun One,
iPlanet, and so on.
Note
A role name can occur multiple times in your LDAP tree. However, for a case sensitive DBMS, such as
Oracle, be sure to enter role names with the same case as stored in the MDM repository. Roles can be
viewed from within MDM Console.
Group Filter Search
Starting from MDM 7.1 SP02, you can use the group filter search algorithm (also known as GroupMapping2)
for LDAP servers. The group filter search uses an improved search filter to minimize the size of the result set
by retrieving only users with a roles attribute value that matches the group Distinguished Name.
The Group Filter search algorithm makes use of the LDAP Group Identifier attribute to identify a group.
For many LDAP server installations this attribute is samAccountName, and you can use this algorithm with the
following mds.ini file settings:
User Identifier=samAccountName
Group Identifier=samAccountName
MDM Roles Attribute=memberOf
The search results might be improved by using an additional filter attribute as described in the following
section.
MDM Security Guide

Attribute Search
The attribute search algorithm can be used when no groups are defined in the LDAP directory or the defined
groups cannot be used for some reason.
The attribute search algorithm works in a similar way to the group filter search, but the search filter uses only
the MDM role name, as the group DN cannot be used because of the lack of groups.
The MDM roles attribute can be any LDAP attribute that is used for MDM user role assignments. You can
create the LDAP attribute, or you can use an existing LDAP attribute that is dedicated to MDM user role
assignment.
The MDM roles attribute must be multi-valued to allow more than one MDM role to be assigned to a user.
For each MDM user, the MDM role assignments must be maintained in the LDAP directory.
The member attribute setting is not used.
The group identifier must explicitly be empty, as this distinguishes the attribute search from group
mapping. (If you remove the parameter from mds.ini the system will use the default for a missing group
identifier parameter, which is the value set for the user identifier parameter.)
There is no mapping from MDM role name to LDAP group name.
The attribute search algorithm can be used with the following mds.ini file settings:
User Identifier=cn
MDM Roles Attribute=employeeType
Group Identifier=
Member Attribute=
Without traversing the tree, the attribute search is much faster and can be used to provide user information to
the workflow.
With very large directories, when the search might still be slow, you can try to narrow the search results by an
improved search filter. For example, if the user entries in LDAP have a special object type, such as person, you
can use the option to specify an additional user search filter condition in the mds.ini file:
User Filter=objectClass=person
2.14.6 LDAP Errors and MDM
Errors that occur due to LDAP failures are returned to the client application. Therefore, you are likely to receive
reports from clients when there are problems with your LDAP service.
Note
You should always test changes to LDAP with the MDM client software that you use.
Some of the more common error messages are listed in the following table.
MDM Security Guide

Table 8:
Error Explanation / Possible Reasons
Ambiguous User More than one user exists with this login name.
User Authorization Failed User exists, wrong password given.
Admin Authorization Failed One or more of the following settings in the mds.ini file are invalid:
Admin DN or Admin Password

Admin Identifier
Base DN
Invalid User User does not exist in LDAP or invalid User Identifier setting in the
mds.ini file.
Unable to Initialize LDAP Host Server or port specified in the mds.ini file could not be reached.
Mds.ini Problem A required parameter is missing from the [MDM LDAP] section of the mds.ini
file. Check the Master Data Server log for the missing parameter name.
User Has No Roles None of the roles retrieved from LDAP are valid for this repository or invalid MDM
Roles Attribute setting in the mds.ini file.
MDM Security Guide

3 Network and Communication Security
Your network infrastructure is extremely important for protecting your system. Your network needs to support
the communication necessary for your business without allowing unauthorized access. A well-defined network
topology can eliminate many security threats caused by software errors (at both operating system and
application level) or network attacks such as eavesdropping. If users cannot log onto your application or
database servers at operating system or database layer, then there is no way for intruders to compromise the
machines and gain access to the database or files of the backend system. Additionally, if users are not able to
connect to the server LAN (local area network), they cannot exploit well-known bugs and security holes in
network services on the server machines.
The network topology for SAP NetWeaver MDM 7.1 is based on the topology used by the SAP NetWeaver
platform. Therefore, the security guidelines and recommendations described in the SAP NetWeaver Security
Guide also apply to the business scenario. Details that specifically apply to the business scenario are described
in the following topics:
Communication Channel Security

As communication channels transfer all kinds of business data, they should be protected against
unauthorized access.
Network Security
A minimum security requirement for your network infrastructure is the use of a firewall for all the services
you provide in the Internet.
A more secure method is to protect your systems (or groups of systems) by placing the "groups" in
different network segments, each protected with a firewall against unauthorized access. External security
attacks can also come from "inside", for example through social engineering.
Communication Destinations
Communication destinations within a SAP NetWeaver MDM installation have to be monitored. The kind of
monitoring depends greatly on the implemented system landscape.
Golden rules for connection users and authorizations:
Assign users only the minimum authorizations required.

Choose a strong default password for new users.
Users should choose secure and secret passwords, and change the default password after the first logon.
Caution
Carelessly handled users and authorizations for connection destinations can cause severe security issues.
3.1 Secure Communication Channels Using SSL
Transport layer security for communication among MDM servers and clients is available using the Internet
standard protocol Secure Sockets Layer (SSL). This optional encrypted channel runs alongside the existing
MDM client-server TCP communication layer.
MDM Security Guide

28 CUSTOMER Network and Communication Security
MDM servers can be configured to allow clients to establish either unencrypted or secure SSL connections,
and can handle both types of connections in parallel.
Setting up secure communications within an MDM landscape involves the following steps:
1. Installing or upgrading MDM servers and clients to MDM 7.1 SP07 or later.
2. Configuring MDM servers for SSL.
3. Copying SSL library and client key files to client locations.
4. Creating secure connections from rich client UIs.
5. Creating secure connections via APIs.
Note
MDM supports SSL for communication between MDM components only. Communications established
between third party applications and MDM components, including, but not limited to the DBMS, are not
affected by MDM security settings; however, the third party applications may provide their own form of
communication security.
For more information about which MDM components support SSL-based communication, see the MDM
Master Guide on the SAP Help Portal at help.sap.com/nwmdm71.
3.2 Secure Connection Prerequisites
All MDM servers and clients must be version 7.1 SP07 or higher. In addition, the following server-side and
client-side components are required in order to establish secure connections on MDM systems.
MDM server-side components:
SSL Library file: sapcrypto.dll

Key file: SAPSSLS.PSE
Ticket file: ticket
MDM client-side components:
SSL Library file: sapcrypto.dll

Key file: CLIENT.PSE
Ticket file: ticket
Note
Key files and ticket files are created automatically during the installation/upgrade process, but the SSL
Library file must be downloaded separately. For information about downloading the SSL Library file, see
SAP Note 397175 .
The ticket file must be located in the same directory as the SSL Library file.
Rich UI clients such as MDM Console, MDM Data Manager, MDM Syndicator, and MDM Import Manager
require the 32-bit version of the SSL Library file.
MDM Security Guide

Network and Communication Security CUSTOMER 29
3.3 MDM Server Configuration for SSL
Server-side SSL settings are stored in a servers .ini file.
Note
If you are upgrading from a version of MDM prior to MDM 7.1 SP07, the parameters described in this section
must be added manually to your server configuration files. They are added automatically only for new
installations of MDM 7.1 SP07 and later.
For information about configuring MDM server parameters, see the MDM Console Reference Guide on the SAP
Help Portal at help.sap.com/nwmdm71.
MDS Configuration
The following Master Data Server (MDS) settings are stored under the [MDM Server] section of the mds.ini
file.
Table 9:
Listening Mode Specifies if the Master Data Server accepts unencrypted, encrypted, or both types of con
nections. Options are Unencrypted , SSL , or Both.
Note
If the Listening Mode parameter is set to Unencrypted , attempts by clients to estab
lish secure connections to the Master Data Server will fail.
SSL Lib Path The path to the servers SSL Library file.
SSL Key Path The path to the servers SAPSSLS.PSE file.
Auxiliary and Slave Server Configuration
file.
The following auxiliary server (MDIS, MDSS, MDLS) settings are stored in the mdis.ini, mdss.ini, and
mdls.ini files under the header:
[MDM Server\Remote Server\<MDSHOST>:<portNumber>]
where <MDSHOST> is the name of the machine on which the MDS is installed and <portNumber> is the
listening port for the specified MDS (for example, myhost:50051 ).
MDM Security Guide

Note
The <MDSHOST>:<portNumber> value in the Remote Server heading must exactly match the Server value
located under the [GLOBAL] heading in the auxiliary servers .ini file.
Table 10:
Service Control Security Enabled Options are True or False. Must always be False on UNIX landscape.
SSL Enabled Specifies if the server connects to MDS on an unencrypted or SSL port. Options
are True or False. For the server to establish a secure connection to MDS, this
parameter must be set to True.
SSL Lib Path The path to the auxiliary servers SSL Library file.
SSL Key Path The path to the auxiliary servers SAPSSLS.PSE file.
Note
The header and parameters described in this section must also be added to the mds.ini file of any remote
MDS on which a slave repository is mounted.
3.4 Connecting Securely from MDM Clients
Connecting Securely from MDM Console
Icons in the Console Hierarchy tree display locks to indicate a secure connection to a SSL-enabled server was
established when the server was mounted on the Console.
Secure connections to SSL-enabled MDM servers must be configured from within an MDM Console. For more
information, see the MDM Console Reference Guide on the SAP Help Portal at help.sap.com/nwmdm71.
Connecting Securely from other Rich Clients
When connecting MDM Data Manager, MDM Import Manager, MDM Syndicator, or MDM Publisher to a
repository on an SSL-enabled Master Data Server, a lock icon appears in the clients Connect To MDM
Repository dialog box.
Secure connections to repositories on SSL-enabled MDM servers must be configured from within each client.
For information, see Setting Up Secure Repository Connections in the client reference guide.
MDM Security Guide

Connecting Securely from MDM CLIX
Before you can connect CLIX to an SSL-enabled Master Data Server, you must add the paths to the client-side
SSL library and key files to the clix.ini file. Adding the Y[+] option flag to a CLIX command then encrypts
communication with the MDS.
For more information, see the MDM CLIX Command Reference on the SAP Help Portal at help.sap.com/
nwmdm71.
Connecting Securely from MDM APIs
For information about establishing SSL secure connections from applications that use MDM Java or .NET
APIs, see the following sections in the MDM Java and .NET API Guide on the SAP Help Portal at help.sap.com/
nwmdm71:
Getting Started with Java API

Tasks Managing: Connections and Sessions
For information about establishing SSL secure connections from ABAP API applications, see the MDM ABAP
API Guide on the SAP Help Portal at help.sap.com/nwmdm71.
Connecting Securely from MDM Web UIs
For information about establishing SSL secure connections from Web UIs, see the following guides on the SAP
Help Portal at help.sap.com/nwmdm71:
MDM Portal Content Development Guide: Connecting with the MDM Repository
MDM Web Dynpro Components Guide: Installing the MDM Web Dynpro Environment
Connecting Securely from MDM Web Services
For information about establishing SSL secure connections from Web UIs, see the following sections in the
MDM Web Services Guide on the SAP Help Portal at help.sap.com/nwmdm71:
MDM Web Services Generator (Design Time): Generating a New Web Service
Generated Web Services (Runtime): Creating MDM Destinations for Web Service Operation Calls
Generated Web Services (Runtime): Installing MDM Web Services Runtime Environment: MDM Web
Services Security
Generated Web Services (Runtime): Data Types: Common Data Types: Generic Data Types:
RepositoryInformation Data Type
Generated Web Services (Runtime): Web Services and Operations: Generic Functionality for Web Service
Operations: Connecting the MDM Repository at Runtime
MDM Security Guide

Connecting Securely from MDM PI Adaptor
For information about establishing SSL secure connections from the MDM PI Adaptor, see the section, Setting
Up Messaging: MDM Adapter Specific Configuration,.in the MDM PI Adapter Guide SAP on the SAP Help Portal
at help.sap.com/nwmdm71.
Connecting Securely from MDM Enrichment Controller
For information about establishing SSL secure connections from the MDM Enrichment Controller, see the
section, Editing the Configuration File of the Enrichment Controller,.in the MDM Enrichment Architecture Guide
SAP on the SAP Help Portal at help.sap.com/nwmdm71.
3.5 Server Landscape
It is possible to install MDM servers and the DBMS on the same or on different physical server machines. The
MDM server landscape should be placed within a secured area, even in a closed corporate network.
You should ensure that the DBMS cannot be accessed by end users (except for the database administrator)
using any kind of management tools, as certain scenarios require that the database user and password for end
users are available.
3.6 Communication Channels
Client/MDS Communication
In general, the Master Data Server (MDS) communicates with the following applications or APIs using TCP/IP:
MDM Console
MDM Data Manager
MDM Image Manager
MDM Syndicator
MDM Publisher
MDM Import Manager
Master Data Import Server
Master Data Layout Server
Master Data Syndication Server
MDM Security Guide

MDM Java API
MDM .NET API
MDM CLIX (Command Line Tool)
A native protocol is used for communication between the different servers and between the servers and
clients.
The Master Data Server also contains an RFC server. It is used to communicate with the MDM ABAP (for more
information, see Remote Function Call [page 34]).
MDS/Database Server Communication
MDS uses the ODBC API to connect to the databases.
3.7 Network Ports
As of MDM 7.1 SP08, MDM uses the following default listening ports:
Table 11:
Application Unencrypted Port SSL Port
MDS 59950 59951
MDLS 59650 59651
MDIS 59750 59751
MDSS 59850 59851
You can configure different listening ports from the installer when you install/upgrade MDM. For more
information, see the MDM Installation Guide or MDM Upgrade Guide on the SAP Help Portal at help.sap.com/
nwmdm71.
3.8 Remote Function Call
The Master Data Server (MDS) contains a Remote Function Call (RFC) server. This RFC server is used to
connect through MDM ABAP API, which is an add-on for the SAP NetWeaver Java Application Server (Java
AS).
The RFC functions delivered within MDS can only be called from a trusted Java AS.
MDM Security Guide

3.9 Secure Connection to Microsoft Active Directory
When MDS is installed on a Windows platform, you can configure a secure connection from MDS to the
Microsoft Active Directory LDAP server by setting the Secure Connection to Active Directory
parameter to true. This setting is stored under the [LDAP] section of the mds.ini file. For more information,
see MDM LDAP Parameters [page 19].
3.10 Authentication of Trusted Connections
SAP NetWeaver MDM 7.1 offers a Trusted Connection mechanism for authentication of client connections to
MDS. When enabled, there are two modes of client authentication: IP and SSL.
When IP-based authentication is enabled, all requests for trusted connections coming from trusted IP
addresses will be accepted. This form of authentication is vulnerable to IP spoofing attacks. SSL-based
authentication for trusted connections removes this vulnerability.
When SSL-based authentication is enabled, all requests for trusted connections coming from trusted
distinguished names (DNs) will be accepted.
Trusted Connection Configuration Parameters
file.
Table 12:
Trusted Connection Authentication Mode Specifies the type of authentication required for trusted connections to the
Master Data Server (MDS). Options are None, IP, SSL, or Both.
If set to None, no trusted connections will be accepted.

If set to IP or Both , a warning will be logged of the risks of activating IP-
based authentication.
Note
SSL-based authentication of trusted connections also requires the Master Data Servers Listening Mode
parameter to be set to SSL or Both.
MDM Security Guide

3.10.1 IP-Based Trusted Connections
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).
Note
IP-based 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.
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.
Note
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 the allow.ip and deny.ip files 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).
For users to connect to an MDM repository from a trusted connection, their usernames must exist on the
MDM repositorys 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 files and parameters required for
trusted connections are described in the following table.
MDM Security Guide

Table 13:
File Description
allow.ip A flat, text-only file containing the IP addresses of trusted systems. Connection 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.
Resides 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. Con
nection requests from IP addresses in this file are 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.
File is optional.
mds.ini The parameter TrustFilesDir 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 file.
3.10.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 the following sections 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.
The following files, which are created in the exe folder of the global host after the installation or update of
MDM is complete, are required for configuring SSL-based trusted connections:
Table 14:
File Description Comments
client.pse Client key of the SSL communication. The MDM cli

ents will need this file to connect to the MDM serv
ers.
MDM Security Guide

File Description Comments
SAPSSLS.pse Server key of the SSL communication. The MDM Copied also to the sec folder of the
servers will need this file. MDM servers.
cert.crt Certificate files that are used to connect the MDM

server to the WAS (Web Application Server) in se
cure mode.
cred_v2 For internal use.
ticket For internal use. Copied also to the sec folder of the
MDM servers.
For information about creating the client and server keys manually, see SAP Note 1562668 .
3.10.2.1 Creating PK12 Certificates
Context
You can create PK12 certificates and import them to MDM Key Storage using the MDM Destination
Administration tool.
Procedure
1. Place the following files in a temporary directory on a Windows machine:

genTrustedPK12.bat
sapgenpse.exe
sapcrypto.dll
SAPSSLS.pse
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 the files from the temporary directory.
7. Create a new MDM destination for a trusted SSL connection.
a. On the trusted Java API client host, open the MDM Destination Administration Tool.
b. In the Logon Parameters tab, in the Trusted System Type dropdown list, choose Client Certificate.
c. In the Connection Parameters tab, import the client.crt and .p12 files to MDM Key Storage, by
selecting the files and choosing Import Entry.
MDM Security Guide

3.10.2.2 Creating and Importing Java KeyStore Certificates
Context
You can create and import Java KeyStore certificates.
Procedure

genTrustedJKS.bat
sapgenpse.exe
sapcrypto.dll
SAPSSLS.pse
2. Run genTrustedJKS.bat.
3. Copy the *.jks key file created by the batch script to the machine where the Java API client is hosted.
(For more information about including these files in your Java applications, see the MDM Java API
Reference Guide on the SAP Help Portal at help.sap.com/nwmdm71.)
5. Copy allow.dn to \usr\sap\<SID>\MDS<instance number>\exe on the MDS host.
3.10.2.3 Importing CA-Generated PK12 Certificates
Context
You can import PK12 certificates that were generated by a certificate authority (CA).
Procedure

importClientPK12ToServerPSE.bat
MDM Security Guide

sapgenpse.exe
sapcrypto.dll
SAPSSLS.pse
PK12 file (*.p12)
2. Run importClientPK12ToServerPSE.bat.
3. Copy the *.p12 key file to the java API client host.
3.10.2.4 Importing CA-Generated x509 Certificates
Context
You can import x509 certificates that were generated by a certificate authority (CA).
Procedure

importClientCertToServerPSE.bat
sapgenpse.exe
sapcrypto.dll
SAPSSLS.pse
X509 certificate (*.cert)
2. Run importClientCertToServerPSE.bat.
3.10.3 ABAP API Trusted Connections
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
MDM Security Guide

that repository using the ABAP API. In particular, the Master Data Server trusts a specific AS ABAP server in
the landscape.
3.10.4 Java/.NET Trusted Connections
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.
Note
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.
MDM Security Guide

4 Authorization Concepts and Management
4.1 Separation of Duties
The "4-eyes-principle"/"dual control" is often used to protect critical transactions. This means that access (or
completing an action) is only allowed if at least one additional person has given his or her approval through a
suitable approval process. This is also applicable for administrative tasks.
The Master Data Server does not support the separation of duties.
Proposed solution:
Separation can be implemented for applications on top of the available APIs (.NET, Java, ABAP).
4.2 Change Log for Authorization Management
Auditors need a trace that shows who had which authorization when. The audit log records the creation,
change and deletion of users and roles as well as the assignment of roles to users.
Note
When a role is created, the corresponding authorizations are not added to the log. Roles are always created
with full privileges. When a role is updated, the changes are recorded in the log.
Example
Example of a function log entry:
<repositoryAdmin><role action="modify" id="2"><functionRight>
<function>16777216</function><access>1</access>
</functionRight></role></repositoryAdmin>
In this case the role with ID 2 has been modified. The authorization with ID 16777216 (see function ID map
below) has been set to 1 (Execute).
Example of a tables and fields log entry:
<repositoryAdmin><role action="modify" id="5"><objectRight> <object>1</

object><type>0</type><access>2</access>
</objectRight></role></repositoryAdmin>
In this case the role with ID 5 has been modified. The table access with ID 1 has been set to 2 (Read-only).
MDM Security Guide

42 CUSTOMER Authorization Concepts and Management
Legend of Access Values
Function log:
1 = Execute
0 = None
Table and field log:
2 = Read-only
3 = Read/write
Function ID Map for Records
Table 15:
Function ID in log Corresponging hex value Function name
16777217 1000001 AddRecords
16777218 1000002 ModifyRecords
16777233 1000011 ModifyCheckedOutRecords
16777219 1000003 DeleteRecords
16777220 1000004 MergeRecords
16777234 1000012 MergeCheckedOutRecords
16777221 1000005 ProtectRecords
16777222 1000006 UnprotectRecords
16777223 1000007 CheckOutRecords
16777235 1000013 CheckOutNewRecords
16777224 1000008 CheckInRecords
16777225 1000009 RollBackRecords
16777226 0100000A CheckInNonOwned
16777227 0100000B RollBackNonOwned
16777228 0100000C ModifyJoinNonOwned
16777229 0100000D has been used before
16777230 0100000E has been used before
16777231 0100000F has been used before
16777232 1000010 has not been used before
MDM Security Guide

Authorization Concepts and Management CUSTOMER 43
Function ID Map for Images
Table 16:
33554433 2000001 ModifyImagePrintSize
33554434 2000002 CropAndRotateImages
Function ID Map for Hierarchy
Table 17:
50331649 3000001 MoveHierarchy
50331650 3000002 HideChildren
50331651 3000003 CreateAliases
Function ID Map for Taxonomy
Table 18:
67108865 4000001 AddAttributes
67108866 4000002 DeleteAttributes
67108867 4000003 ModifyAttributes
67108868 4000004 ConvertAttributeType
67108869 4000005 SplitAttribute
67108870 4000006 MergeAttributes
67108871 4000007 SetAttributePriority
67108872 4000008 ModifyLinkedAttributes
67108873 4000009 ReassignAttributeRatings
67108874 0400000a AddMatchingSets
67108875 0400000b DeleteMatchingSets
67108876 0400000c ModifyMatchingSets
67108877 0400000d Partition
67108878 0400000e ConsolidateChildren
MDM Security Guide

Function ID Map for Families
Table 19:
100663297 6000001 SynchronizeFamilyTree
100663298 6000002 ModifyFamilyData
100663299 6000003 ModifyFamilyPartitioning
Function ID Map for Layouts
Table 20:
117440513 7000001 ModifyLayout
117440514 7000002 RenameLayoutColumns
Function ID Map for Publications
Table 21:
134217729 8000001 AddPublications
134217730 8000002 DeletePublications
134217731 8000003 RenamePublications
134217732 8000004 AddPublicationNodes
134217748 8000014 AddSectionNodes
134217749 8000015 AddInternalNodes
134217750 8000016 AddPresentationNodes
134217733 8000005 DeletePublicationNodes
134217751 8000017 DeleteSectionNodes
134217752 8000018 DeleteInternalNodes
134217753 8000019 DeletePresentationNodes
134217734 8000006 MovePublicationNodes
134217735 8000007 RenamePublicationNodes
134217754 0800001a SplitSectionNodes
134217755 0800001b CombineSectionNodes
134217742 0800000e ModifyCachedLayoutItems
MDM Security Guide

134217743 0800000f ModifySectionNodeData
134217744 8000010 ModifyPresentationNodeData
134217745 8000011 AddSpreads
134217746 8000012 DeleteSpreads
134217747 8000013 ModifySpreads
134217756 0800001c ShuffleSection
134217757 0800001d AddPages
134217758 0800001e DeletePages
134217759 0800001f MovePages
134217760 8000020 AddPresentations
134217761 8000021 DeletePresentations
134217762 8000022 MovePresentations
134217763 8000023 RecoverPresentationItems
134217768 8000028 AddItemsToSnapshot
134217764 8000024 DeletePresentationItems
134217765 8000025 RelocatePresentationItems
134217766 8000026 FlowSection
134217767 8000027 ApplyTemplates
134217769 8000029 PurgeDisconnectedFromSnap
134217736 8000008 ModifyPublicationLayout
134217738 0800000a ModifyPublicationFamilyData
134217739 0800000b ModifyPublicationRecords
134217740 0800000c ModifyPublicationFormat
134217741 0800000d ModifyDocWorkspace
Function ID Map for Publisher Checkout
Table 22:
251658241 0F000001 CheckoutPubObj
251658242 0F000002 AssignPubObjCheckout
251658243 0F000003 OverridePubObjCheckout
MDM Security Guide

Function ID Map for Publisher Indexes
Table 23:
167772161 0A000001 AddPubIndices
167772162 0A000002 DeletePubIndices
167772163 0A000003 RenamePubIndices
167772164 0A000004 ModifyPubIndexDataSource
167772165 0A000005 ModifyPubIndexKeyDefs
167772166 0A000006 ModifyPubIndexEntryRedefines
167772167 0A000007 ModifyPubIndexProperties
167772168 0A000008 ModifyPubIndexStyles
167772169 0A000009 ModifyPubIndexDocumentProperties
167772170 0A00000A AddPubIndexSource
167772171 0A00000B DeletePubIndexSource
Function ID Map for Branded Client
Table 24:
150994958 0900000e ModifyMultipleRecords
150994959 0900000f DeleteMultipleRecords
150994945 9000001 AddToMask
150994946 9000002 RemoveFromMask
150994947 9000003 ReplaceInMask
150994948 9000004 ModifyMask
150994949 9000005 ImportFromExcel
150994950 9000006 ExportToText
150994951 9000007 ExportToExcel
150994952 9000008 ExportToAccess
150994953 9000009 SaveOriginalToDisk
150994954 0900000a EnableFamilyModifications
150994955 0900000b EnableLayoutModifications
150994956 0900000c EnablePublicationModifications
150994957 0900000d EnablePubIndexModifications
MDM Security Guide

150994976 9000020 SetNamedSearch
Function ID Map for Distributions Role
Table 25:
184549377 0B000001 AddImportMaps
184549378 0B000002 ModifyImportMaps
184549379 0B000003 DeleteImportMaps
184549380 0B000004 AddExportMaps
184549381 0B000005 ModifyExportMaps
184549382 0B000006 DeleteExportMaps
184549383 0B000007 EnableKeyMapping
Function ID Map for Administration
Table 26:
201326593 0C000001 DescribeRepository
201326594 0C000002 MaintainRegions
201326595 0C000003 MaintainConnection
201326596 0C000004 MaintainRepositorySettings
201326597 0C000005 SynchronizeSlave
201326598 0C000006 NormalizeRepository
201326599 0C000007 ShareRepository
201326600 0C000008 UnlockRepository
201326601 0C000009 CompactRepository
201326602 0C00000a RepairRepository
201326603 0C00000b TruncateChangeLog
201326604 0C00000c RefreshCalcFields
201326605 0C00000d StartRepository
201326606 0C00000e StopRepository
MDM Security Guide

Function ID Map for Schema
Table 27:
218103809 0D000001 ImportSchema
218103810 0D000002 ExportSchema
218103811 0D000003 AddTable
218103812 0D000004 ModifyTable
218103813 0D000005 DeleteTable
218103814 0D000006 AddField
218103815 0D000007 ModifyField
218103816 0D000008 DeleteField
218103817 0D000009 AddSchemaObject
218103818 0D00000a ModifySchemaObject
218103819 0D00000b DeleteSchemaObject
4.3 Change Log Archiving
Changes to authorizations are logged in the MDS_Audit log file. If a log file exceeds a size of 2 MB, a new file is
created. Since logs are not overwritten, you can create a long-term archive.
Note
There is no MDM tool for archiving old log files. Older log files should be archived manually or by using an
archive tool.
MDM Security Guide

5 Auditing
5.1 Logging of Security-Relevant Information
The Master Data Server contains a logging functionality for security-relevant information. The logs are stored
as CSV files in the usr\sap\<SAPSID>\<instance_name>\log directory. You can view them from the MDM
Console. There are two types of logs:
MDS_Audit: Security-relevant Information

MDS_Log: Technical server logs (not described further in this guide)
If a log file exceeds a size of 2 MB, a new file is created. Since logs are not overwritten, you can create a long-
term archive. Due to the risk of running out of hard disk space, you should archive old log files or (if there is no
need for a long-term archive) delete them from time to time.
The following security-relevant information is logged:
Server:
Start/stop server instance

Change server password
Log onto server
Repository:
Log onto or off from repository

Create/delete
Start/stop/repair
Rename repository (log shows only new name)
Archive (log shows only name of repository to archive)
Unarchive repository (log shows only name of archive target)
Archive/unarchive publication model (log shows the same data as archive/unarchive repository)
Create slave (log shows only slave name)
Export schema (log does not show the schemas origin or target name)
Create repository from schema (log shows only name of target repository)
Change DBMS settings (log shows only change event, but no further details)
Add/update/delete role (log shows only update event, but no further details)
Add/update/delete user
Update change tracking (log shows only update event, but no further details)
Create/update/delete port (log shows only events, but no further details)
Repository Metadata:
Create/update/delete table (log shows only event, but no further details)

Create/update/delete table field (log shows only event, but no further details. No information about
corresponding table available.)
MDM Security Guide

50 CUSTOMER Auditing
Create/update/delete tuple (log shows only event, but no further details)
Create/update/delete tuple field (log shows only event, but no further details)
MDM Security Guide

Auditing CUSTOMER 51
6 Content Security
Document and File Upload
The Master Data Server can store documents (PDF) and files (images, sounds, videos, and binary objects) in
the database. It does not contain an integrated virus scanner. Documents and files should be checked with a
separate virus scanner before they are released for uploading.
MDM Security Guide

52 CUSTOMER Content Security
7 MDM File System Security
7.1 MDM File Locations
Under Windows, the base directory is usr\sap\<SAPSID>\<instance_name> .
Under Linux/Solaris, you can set the base directory to a different directory.
Config:
Contains the configuration ini file
Access recommendation: Do not share
Data:
Contains cached information
Exe:
Contains the application
Log:
Contains MDM log files.
Access recommendation: Can be made available to MDM administrators
MDM
Accelerator
Contains accelerator files for repositories
Archives
Contains created repository archives
Distributions
Contains port configuration files and is used as file shelf for file import/export using ports
Access recommendation: Should only be shared if an import scenario that accesses the file
system directly is implemented
Reports
Contains repository operation (archive, duplicate, load, unarchive, update, verify check, verify
repair) reports
Sec
Not used.
Work
This is the work directory of all processes (SAPStartSrv, MDS , MDIS, MDSS, MDLS) started by the
instance. The folder is used to store a trace. Log files and long-term archiving files should never be
stored in this directory. This directory can be made available to MDM administrators, and can be
accessed using the SAPControl WebService or the SAPmmc Console.
MDM Security Guide

MDM File System Security CUSTOMER 53
Note
If the access recommendation of a folder is restricted, it has to be protected by operating system
settings.
7.2 Session IDs
The Master Data Server uses session IDs to authenticate client users. There are different sessions for different
purposes:
Server session (certain console functions)

Admin session (certain console functions).
User session (data manager functions).
The session ID does not change when the authentication status changes. If a session ID is detected before it is
authenticated, it might be misused at a later point of time after authentication of the user.
The randomly-defined part of the session ID is 64 bits long. It is not impossible to guess a valid session ID (128
bit length would be necessary for that).
Proposed solution:
Secure the communication channel using IPSec or a comparable measure.
7.3 User Session Locks
A long inactivity (for example, 30 minutes) implies that the user has left his or her work place. If an application
is not locked, unauthorized persons can access the application from the unattended computer.
The MDM user session is not locked after an inactive period of time and re-authentication of the user is not
necessary.
All client applications run under Microsoft Windows. The operating system should be configured so that it
locks automatically after a certain period of inactivity. This prevents unauthorized users from accessing the
application and the corresponding user session.
MDM Security Guide

54 CUSTOMER MDM File System Security
8 Regulatory Compliance
8.1 Person-Related Data
Person-related data is an important topic within a master data environment. One of the tasks of the application
is to handle the regulations regarding person-related data. In this context, the Master Data Management
Server is only used as data storage in certain cases.
Depending on the use case and the application on top of the Master Data Management Server in the
environment, the application must comply with the following rules:
Master data applications must provide the capability to avoid unnecessary storage of person-related data.
Master data applications must provide the capability to notify a person if data related to this person is
stored for the first time.
Master data applications must support deletion of personal data.
It must be possible to store the agreement of the affected person to the storage of his/her personal data.
Processing of person-related data must be limited to the primary reason for storing the data.
Person-related data stored for different reasons must be stored separately.
The transfer of person-related data to other systems must be logged.
The points above should be kept in mind when you create applications on top of the SAP Master Data Server
(for example, using one of the available APIs).
8.1.1 Data Protection and Privacy
SAP enables you to comply with national legal data protection and privacy requirements. SAP software
supports data protection and privacy by providing security features and functions for blocking and deleting
personal data. This includes the destruction of stored personal data after the retention period, and the
blocking of stored personal data after the residence (end of purpose) period by restricting access to the data.
Personal data is defined as: The specifics about personal or material circumstances of an identified or
identifiable natural person (data subject).
Data privacy is defined as: A set of legal requirements which forces companies to treat personal data with
special care. The core requirements are to use personal data only for particular business purposes, and to
erase personal data as soon as it is no longer required for the particular purpose.
Blocking is defined as: A method of restricting access to data for which the primary business purpose has
ended.
Deleting data is defined as: The deletion of personal data so that the data is no longer usable.
SAP NetWeaver MDM 7.1 complies with the security requirement SEC-256:
SAP software shall support deletion of personal data (including personally identifiable information).
MDM Security Guide

Regulatory Compliance CUSTOMER 55
For more information about the data protection and privacy features and functions provided by SAP
NetWeaver MDM 7.1, see the following documentation on the SAP Help Portal at help.sap.com/nwmdm71:
Syndicator Guide
Import Manager Reference Guide
Console Reference Guide
CLIX Commands Guide
Data Manager Reference Guide
DB Views Guide
ABAP API Guide
Java and .NET API Guide
MDM Security Guide

56 CUSTOMER Regulatory Compliance
9 Client Digital Signature
9.1 Viewing Win32 Client Digital Signatures
Context
You can view Win32 client digital signatures during MDM 7.1 installation.
Note
The signature is located in the Installation file (wise package) and the .exe file.
Procedure
1. On the User Account Control window, choose Yes when prompted to allow this app to make changes to
your PC?
2. Choose ok when the Console.exe Properties window displays the following Signature List in the Digital
Signatures tab:
a. Name of signer: SAP SE.
b. Digest algorithm: sha1.
c. Timestamp: current date.
MDM Security Guide

Client Digital Signature CUSTOMER 57
Important Disclaimers and Legal Information
Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.
Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be
a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however,
does not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations
of SAP.
Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as
"sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun
does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does
not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any
damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for
transparency (see: http://help.sap.com/disclaimer).
MDM Security Guide

58 CUSTOMER Important Disclaimers and Legal Information
MDM Security Guide
Important Disclaimers and Legal Information CUSTOMER 59
go.sap.com/registration/
contact.html
2017 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP SE
or an SAP affiliate company. The information contained herein may
be changed without prior notice.
Some software products marketed by SAP SE and its distributors
contain proprietary software components of other software
vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company
for informational purposes only, without representation or warranty
of any kind, and SAP or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only
warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks
of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the
trademarks of their respective companies.
Please see http://www.sap.com/corporate-en/legal/copyright/
index.epx for additional trademark information and notices.

PDF MDM Security Guide en

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

PDF MDM Security Guide en

Diunggah oleh

Hak Cipta:

Format Tersedia

CUSTOMER

SAP NetWeaver Master Data Management 7.1

MDM Security Guide

2 Users, Roles, and Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Network and Communication Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

MDM Security Guide

4 Authorization Concepts and Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 MDM File System Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

9 Client Digital Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

MDM Security Guide

5.4 / June 2017 Guide updated for MDM 7.1 SP18.

Section 2.3, Predefined Users, Roles, and Passwords [page 9] states

5.3 / December 2016 Guide updated for MDM 7.1 SP17.

5.2 / June 2016 Guide updated for MDM 7.1 SP16.

Minor corrections to the section on LDAP support.

5.1 / December 2015 Guide updated for MDM 7.1 SP15.

5.0 / December 2014 Guide updated for MDM 7.1 SP13.

Guide updated to standard format.

Reorganized section LDAP Support [page 17].

4.2 / March 2014 Guide updated for MDM 7.1 SP12.

4.1 / December 2013 Guide updated for MDM 7.1 SP11.

Added three new mds.ini parameters and updated descriptions of other

4.0 / March 2013 Guide updated for MDM 7.1 SP10.

New password requirement enforcement options added. See Strong and

Updated the section,LDAP Support [page 17].

3.2 / August 2012 Guide updated for MDM 7.1 SP09.

MDM Security Guide

LDAP Support [page 17]

3.0 / September 2011 Guide updated for MDM 7.1 SP08.

Secure Trusted Connection support added. See Authentication of Trusted

New mds.ini option added for securing connections to Microsoft Active Di

Default Admin user password changed to sapmdm. See User Administra

New CLIX commands added for password management operations. See

2.0 / May 2011 Guide updated for MDM 7.1 SP07

SSL support added. See Network and Communication Security [page

MDM Security Guide

Scope of this Guide

Fundamental Security Guides

MDM Security Guide

Components of SAP NetWeaver MDM

MDM Security Guide

Master Data Servers

MDM Security Guide

Add user or role object

2.3 Predefined Users, Roles, and Passwords

2.4 Single Sign-On

MDM Security Guide

2.5 Authentication and SSO-like Feature in MDM Java

2.5.1 User Management

You can do this with the following user configurations:

Same users in UME and MDS:

2.5.2 Trusted Connections

MDM Security Guide

2.5.4 MDM Web Services Security

MDM Security Guide

2.6 Password Change Enforcement

2.7 Strong and Secure Passwords

Minimum and maximum password length

MDM Security Guide

Minimum Password Length

Password Complexity Requirements

Password Must Contain Uppercase And Lowercase Letters

MDM Security Guide