MDM Security 71

SAP NetWeaver
MDM Security Guide

SAP NetWeaver MDM 7.1 SP08 Document Version 3.1 April 3, 2012
October 2011
Copyright 2012 SAP AG. 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 AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group 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.
Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components.
Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or altered in any way.
Documentation on SAP Service Marketplace You can find this documentation at

service.sap.com/instguidesNW04
April 2012
October 2011
Typographic Conventions
Type Style Example Text Represents Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation. Emphasized words or phrases in body text, graphic titles, and table titles. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.
Icons
Icon Meaning Caution Example Note / Tip Recommendation Syntax
Example text
EXAMPLE TEXT
Example text
Example text
<Example text>
EXAMPLE TEXT
April 2012
MDM 7.1 Security Guide
Document History
Document Version 3. 1/ April 2012 Description of Change Consolidated information from the MDM Console Reference guide into the following sections: o LDAP Support (page 10) o Authentication of Trusted Connections (page 23) Guide updated for MDM 7.1 SP08 Secure Trusted Connection support added. See Authentication of Trusted Connections (page 23). New mds.ini option added for securing connections to Microsoft Active Directory LDAP Server. See Secure Connection to Microsoft Active Directory Configuration (page 23). Default Admin user password changed to sapmdm. See Standard User (page 9). New CLIX commands added for password management operations. See CLIX Commands for Managing Passwords (page 9). New CLIX command added for emergency Admin user password creation. See Emergency User Concept (page 10). Guide updated for MDM 7.1 SP07 SSL support added. See Network and Communication Security (page 17).
3.0 / September 2011
2.0 / May 2011
April 2012
Contents
MDM SECURITY GUIDE .......................................................................................................... 1 1 2 COMPONENTS OF SAP NETWEAVER MDM ................................................................. 2 USERS, ROLES AND AUTHENTICATION....................................................................... 3 2.1 Users ......................................................................................................................... 3 2.2 Roles and Authorizations .......................................................................................... 3 2.2.1 Roles .............................................................................................................. 3 2.2.2 Authorizations ................................................................................................. 3 2.3 Predefined Users, Roles and Passwords ................................................................. 4 2.4 Single Sign-On Support ............................................................................................ 4 2.5 Authentication and SSO-like Feature in MDM Java Components ............................ 4 2.5.1 User Management .......................................................................................... 4 2.5.2 Trusted Connection ........................................................................................ 4 2.5.3 iViews and UWL Authentication and the SSO-like Feature ........................... 5 2.5.4 MDM Web Services Generator Security ........................................................ 5 2.5.5 MDM Web Services Security .......................................................................... 5 2.6 Password Change Enforcement ............................................................................... 6 2.7 Minimum Length of Password ................................................................................... 6 2.8 Password Validity Timeframe.................................................................................... 7 2.9 Strong and Secure Passwords.................................................................................. 8 2.10 Deactivating Authorization Credentials ..................................................................... 8 2.11 Password History ...................................................................................................... 8 2.12 Locking User Accounts ............................................................................................. 8 2.13 CLIX Commands for Managing Passwords .............................................................. 9 2.14 User Administration Tools ......................................................................................... 9 2.14.1 Standard User ................................................................................................ 9 2.15 Emergency User Concept ....................................................................................... 10 2.16 LDAP Support ......................................................................................................... 10 2.16.1 What is LDAP? ............................................................................................. 10 2.16.2 How LDAP Works ......................................................................................... 10 2.16.3 Basic MDM LDAP ......................................................................................... 11 2.16.4 MDM LDAP Fields ........................................................................................ 11 2.16.5 LDAP Access................................................................................................ 11 2.16.6 MDM LDAP Algorithm (Basic) ...................................................................... 13 2.16.7 MDM LDAP Algorithm (Alternative) .............................................................. 14 2.16.8 MDM LDAP Algorithm (Fallback) ................................................................. 14 2.16.9 MDM Architecture in LDAP .......................................................................... 15 2.16.10 Restrictions and Limitations .................................................................... 15 2.16.11 LDAP Errors and MDM ........................................................................... 15 NETWORK AND COMMUNICATION SECURITY .......................................................... 17 3.1 Securing Communication Channels Using SSL...................................................... 18 3.2 Secure Connection Prerequisites............................................................................ 18 3.3 Configuring MDM Servers for SSL .......................................................................... 19 3.3.1 MDS Configuration ....................................................................................... 19 3.3.2 Auxiliary and Slave Server Configuration ..................................................... 19 3.4 Connecting Securely from MDM Clients ................................................................. 20 3.4.1 Connecting Securely from MDM Console .................................................... 20
April 2012
MDM 7.1 Security Guide 3.4.2 Connecting Securely from other Rich Clients .............................................. 20 3.4.3 Connecting Securely from MDM CLIX ......................................................... 21 3.4.4 Connecting Securely from MDM APIs .......................................................... 21 3.4.5 Connecting Securely from MDM Web UIs ................................................... 21 3.4.6 Connecting Securely from MDM Web Services ........................................... 21 3.4.7 Connecting Securely from MDM PI Adaptor ................................................ 21 3.4.8 Connecting Securely from MDM Enrichment Contoller................................ 22 3.5 Server Landscape ................................................................................................... 22 3.6 Communication Channels Used.............................................................................. 22 3.6.1 Client/MDS Communication ......................................................................... 22 3.6.2 MDS/Database Server Communication ....................................................... 22 3.7 Network Ports Used ................................................................................................ 23 3.8 Remote Function Call .............................................................................................. 23 3.9 Secure Connection to Microsoft Active Directory Configuration ............................. 23 3.10 Authentication of Trusted Connections ................................................................... 23 3.10.1 Trusted Connection Configuration Parameters ............................................ 23 3.11 IP-Based Trusted Connections ............................................................................... 24 3.11.1 How IP-Based Trusted Connections Work ................................................... 24 3.11.2 SSL-Based Trusted Connections ................................................................. 25 3.11.3 Configuring SSL-Based Trusted Connections ............................................. 25 3.11.4 ABAP API Trusted Connection: .................................................................... 28 3.11.5 Java/.NET Trusted Connection: ................................................................... 28 4 AUTHORIZATION CONCEPTS AND MANAGEMENT .................................................. 29 4.1 Separation of Duties Support .................................................................................. 29 4.2 Change Log for Authorization Management ........................................................... 29 4.3 Change Log Archiving ............................................................................................. 34 AUDITING ........................................................................................................................ 35 5.1 Logging of Security-Relevant Information ............................................................... 35 CONTENT SECURITY ..................................................................................................... 36 6.1 Document and File Upload...................................................................................... 36 MDM FILE LOCATIONS AND FILE SYSTEM SECURITY ............................................. 36 7.1 Session IDs ............................................................................................................. 37 7.2 User Session Lock .................................................................................................. 37 REGULATORY COMPLIANCE ....................................................................................... 38 8.1 Person-Related Data ............................................................................................... 38
5 6 7
April 2012
Components of SAP NetWeaver MDM Users
MDM Security Guide

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

This Security Guide describes the security for the SAP NetWeaver MDM component only.
For information about the other SAP components used for the MDM scenarios, see SAP Service Marketplace at service.sap.com/installMDM71 Master Guide.
Fundamental Security Guides

See the corresponding Security Guides of the SAP components that are a part of the MDM scenarios. Application SAP ECC 6.0 Guide SAP ERP 2005 Security Guide Most Relevant Sections or Specific Restrictions In the SAP ERP 2005 Security Guide, choose Security Guides for SAP ECC 6.0. In the SAP NetWeaver Security Guide, choose Security Guides for SAP NetWeaver Products SAP Security Guide PI. In the SAP NetWeaver Security Guide, choose Operating System and Database Platform Security Guides.
SAP NetWeaver Process Integration 7.1
SAP NetWeaver Security Guide
Operating Systems and Database Platforms
SAP NetWeaver Security Guide
For a complete list of the available SAP Security Guides, see service.sap.com/securityguide on the SAP Service Marketplace.
April 2012
Components of SAP NetWeaver MDM Users
Components of SAP NetWeaver MDM

For a complete list of SAP NetWeaver MDM components, see SAP Service Marketplace at service.sap.com/installMDM71 Master Guide.
April 2012
Users, Roles and Authentication Users
2
2.1
Users, Roles and Authentication

Users
MDM provides its own user management. There are no user and role features delivered on top of the MDM user management.
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. To set a Master Data Server password for the first time or to change it, select the MDM Server in the left window pane 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.
Starting with MDM 7.1, you must log onto the repository at least once during an MDM Console session. This means that you have to log onto a repository each time you start the MDM Console. The icon next to the repository name indicates that you have to log onto the repository. For more information about updating repositories, see SAP Service Marketplace at service.sap.com/installMDM71 MDM Upgrade Guide Update Repository.
2.2
Roles and Authorizations
SAP NetWeaver MDM uses its own mechanisms for roles and authorizations. For more information, see SAP Service Marketplace at service.sap.com/installMDM71 MDM Console Reference Guide Part 10: MDM System Administration MDM User and Role Management
2.2.1
Roles
Roles are assigned to users. Each repository contains the following standard roles: Admin and Default. They cannot be deleted. The Admin role cannot be changed. The Default role is predefined with full privileges.
2.2.2
Authorizations
Authorizations (called privileges in MDM) are assigned to roles and are edited in the roles table. You can granularly enable/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).
April 2012
Users, Roles and Authentication Predefined Users, Roles and Passwords
2.3
Predefined Users, Roles and Passwords
In general there are one predefined user and two predefined roles when creating a repository from scratch. The predefined user is the Admin user. The Admin role is assigned to it. A password is not maintained initially for this user. 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 Support
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 onto 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 onto the Master Data Server and the repositories. For more information about trusted connections, see Trusted Connection below. 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 Connection
Trusted Connection configuration has direct influence on how authentication is performed and whether or not the SSO-like feature is supported. See Authentication of Trusted Connections for more information about trusted connection configuration.
April 2012
Users, Roles and Authentication Authentication and SSO-like Feature in MDM Java Components
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 in User Management on page 4 (under Same users in UME and MDS). Trusted connection is required between AS Java and MDS.
2.5.4
MDM Web Services Generator 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.
2.5.5
MDM Web Services Security
The Web services generated by the Web Services Generator have the following security capabilities:
2.5.5.1
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.
2.5.5.2
Authentication
You can define the following authentication modes in the SAP NetWeaver Application Server Java (AS Java) for the generated Web services:
2.5.5.3
No Authentication
An MDM constant user is defined in the Visual Administrator/Services/Configuration Adapter and its MDM password is stored there.
2.5.5.4
Basic Authentication
User name and password of the Web service user are propagated to MDM. This requires user management as described in User Management on page 4, under the Same users in UME and MDS section.
April 2012
Users, Roles and Authentication Password Change Enforcement
2.5.5.5
Basic Authentication with SAP Logon Ticket
SAP logon ticket support as well as basic authentication can be enabled for the Web service. User Management (as described in User Management on page 4, under the Same users in UME and MDS section) and a trusted connection between AS Java and MDS are required.
2.6
Password Change Enforcement
Users with the appropriate authorization (such as the Admin role) can create new users in the MDM Console. The end user can be forced to change the 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. You can configure this initial password behavior. The flag User Must Change Password in the MDM Console User Detail pane activates the described function if it is set to Yes. This feature can also be used by the administrator to enforce a password change by the user at any time.
After creating a user, the default setting for the initial password behavior is No. You must set it to Yes after user creation.
2.7
Minimum Length of Password
The minimum length of passwords can be customized. You can maintain it centrally in the mds.ini file located in the server directory ...\sap\MAF\MDSXX\config. One parameter is used for this setting: Minimal Password Length=5 This option sets the minimal password length (here 5 tokens).
It is important to assign a strong and secure default password to each created user. After you change the minimal password length in the ini file, this password length is not automatically applied to all users whose assigned password is shorter than the minimal password length. The default value for the minimal password length is 5. It can be set to zero, but we do not recommend that you allow users without passwords.
April 2012
Users, Roles and Authentication Password Validity Timeframe
Changes to mds.ini only take effect 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.
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 time until a password will expire (here 90 days). Password Expiration Warning=7 This option sets the number of days a user will get warnings before his password expires (here 7 days). After the defined number of warnings, the user cannot log onto the system without changing his or her password. 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.
April 2012
Users, Roles and Authentication Strong and Secure Passwords
2.9
Strong and Secure Passwords
Passwords that are easily guessed (for example, with a dictionary attack, UserID, company name) are not recognized and are prevented by the Master Data Server. Users of the MDM clients should choose strong and secure passwords.
Strong and secure passwords are a combination of upper and lowercase letters, numbers and special characters with a length of approximately 12 14 tokens. Passwords using personal information like names or dates, user names or repetitions, dictionary words and sequences should not be used.
2.10 Deactivating 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.11 Password History

No history is stored for the passwords of a user. The user is not prevented from changing his or her password to a previous password.
When changing their password, users of the MDM clients should choose a password that was not yet used.
2.12 Locking User Accounts

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 is maintained centrally in the mds.ini file located in the server directory ...\sap\MAF\MDS00\config. 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 2 attempts; with the third attempt the account will already 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 onto the system for the defined number of seconds. 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.
April 2012
Users, Roles and Authentication CLIX Commands for Managing Passwords
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.
The User Account Lock feature does NOT work for users with the Admin role. This prevents administrators from lock out scenarios.
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.
2.13 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 SAP Service Marketplace at service.sap.com/installMDM71 MDM Console Reference Guide Part 14: CLIX Command Line Interface CLIX Commands.
2.14 User Administration Tools

SAP NetWeaver MDM uses its own mechanism to define users. The table below shows the tools used for user management and user administration with the business scenario. Tool DBMS MDM Console Java/.NET/ABAP APIs MDM CLIX Detailed Description Use the user management of your DBMS. Use the user management as described in the MDM Console Reference Guide. In the MDM Console you define the MDM user. All available APIs offer functions for user management. You can build your own user management tools on top of the APIs. The repUser set of MDM CLIX commands enable administrators to get information about, change, expire, and unexpire passwords for repository users.
2.14.1
Standard User
The table below shows the standard user created by the system when you build a repository from scratch.
April 2012
Users, Roles and Authentication Emergency User Concept
Standard User System MDM Repository User ID Admin Password sapmdm Description MDM 7.1 Installation Guide MDM 7.1 Console Reference Guide
2.15 Emergency User Concept

The emergency user concept defines how 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 SAP Service Marketplace at service.sap.com/installMDM71 MDM Console Reference Guide Part 14: CLIX Command Line Interface CLIX Commands.
2.16 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.
2.16.1
What is LDAP?
Simply put, LDAP is a sort of database that 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.
2.16.2
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.
April 2012
10
Users, Roles and Authentication LDAP Support
2.16.3
Basic MDM LDAP
Using LDAP within MDM conforms to the following guidelines: 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.
2.16.4
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 us 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 (;)
While SAP suggests the name MDMRoles, you are free to choose any name that suits your situation. Since LDAP can allow multiple instances of an attribute, MDM will concatenate multiple entries as though they were in a single record separated by semi-colons (;).
2.16.5
LDAP Access
All LDAP access is performed by the Master Data Server. Clients of the Master Data Server 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, then LDAP use is disabled. Parameter Listening Mode Description Specifies if the Master Data Server accepts unencrypted, encrypted, or both types of connections. Options are Unencrypted, SSL, or Both. Specifies if the Master Data Server connects securely to the Microsoft Active Directory LDAP server. Options are True or False.
Secure Connection to Active Directory
April 2012
11
Parameter LDAP in Use Server Server Port
Description Whether or not MDM should use LDAP. Options are True or False. LDAP system address (usually a DNS name). The LDAP Server specification can be either a hostname or an IP address to which MDM attempts to bind; optional Server Port defaults to 389. The full DN and password of an Admin that can search for the users full DN. For downward 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. Just leave both Admin DN and Admin Password blank if directory setting allows anonymous binding. Any other lookup information, such as a base DN suffix, which can be used to distinguish this branch from others that the search should exclude (e.g. o=sap,c=US). It can also include information that differentiates one MDM instance from other MDM instances. The name of the LDAP id field which will match the value the user provides as the Username at logon. This would typically be something like cn or uid. The name of the LDAP attribute that will hold the group assignments, typically something like memberOf. The name of the LDAP attribute that holds email addresses that are assigned to users and is required for workflow. Usually this attribute is mail. Whether or not MDM should use fallback methods to provide temporary, read-only access when connection to the LDAP server is interrupted. Options are True or False. The name of the LDAP field which identifies groups. This is typically something like cn or samAccountName. This field is mandatory for Group Mapping algorithms. See MDM role algorithm below. The name of the LDAP field that lists all members of an LDAP group, like member. This field is optional. It is used for instance with LDAP server IBM Tivoli, See MDM role algorithm below. The number of records sent by the LDAP server per page. Default is 1000. This need not be changed unless the LDAP server setting differs. Optional. Limits the users search result to LDAP user entries only.
Admin DN Admin Password
Base DN
User Identifier MDM Roles Attribute MDM Email Attribute
Fallback in Use
Group Identifier
Member Attribute
Page Size
User Filter
Group Filter
Optional. Limits the groups search result to LDAP group entries only.
* For True/False values that have a default, the default is highlighted in bold.
April 2012
12
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.16.6
MDM LDAP Algorithm (Basic)
If the Master Data Server is not using LDAP, it will proceed with its traditional MDM-specific user authorization. By contrast, if the Master Data Server is configured to use LDAP and is unable to find the LDAP server, it will completely prevent any access to the MDM system, unless fallback parameters are specified. Consider the following mds.ini example for MS Active Directory: [MDM LDAP] LDAP in Use=True Server=192.168.100.198 Server Port=389 Base DN=o=sap,c=US Admin DN=Manager,o=sap,c=US Admin Password=secret User Identifier=samAccountName MDM Roles Attribute=memberOf Group Identifier=samAccountName MDM Email Attribute=mail Fallback in Use=True With these parameters, LDAP authorization by the Master Data Server proceeds according to the following steps: 1. MDM receives a connection request from a client process which includes a UserName and UserPassword. 2. MDM binds to the LDAP Server using five parameters: LDAP_Host LDAP_Port LDAP_AdminDN LDAP_AdminPass LDAP_BaseDN
This can fail if any of the parameter values are inaccurate. 3. As Admin, MDM searches for the full User DN (Distinguished Name) combining User Identifier and Base DN. Failure occurs if anything other than a single entry is retrieved. 4. MDM finds uid=UserName where baseDN=o=sap,c=US. This returns a full DN, such as cn=Joe Cat, ou=Development, ou=Engineering, ou=People, o=sap, c=US. 5. Using the full DN returned above, MDM derives the user MDM role assignments from the LDAP user group assignments. The LDAP group name maps almost directly to the MDM role name. MDM reads the attribute value, extracts the group name, drops the rest of the groups distinguished name and treats the group name as role name. 6. The list of role names is then compared to those in the MDM system to determine which are valid. Roles not found are assumed to be associated with another MDM repository and are ignored (if this is a result of a typo, the user will likely notice that he is unable to perform certain expected activities).
April 2012
13
Do not worry about a role name occurring 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. 7. MDM then attempts to bind to the LDAP server using the full user DN and the provided password. If this fails, the user is prevented from logging into MDM. This MDM LDAP algorithm applies not only in connection with Microsoft Active Directory, but also for other situations where users groups match MDM roles. For example, for IBM Tivoli Directory Server, the proper setting will be: MDM Roles Attribute=ibm-allgroups Member Attribute=ibm-allMembers
2.16.7
MDM LDAP Algorithm (Alternative)
The MDM LDAP algorithm described above makes use of LDAP user group assignments. In some rare cases, no groups are defined in LDAP or the defined groups cannot be used. An alternative approach is to store MDM role assignments in a configurable but dedicated attribute (which may require a schema change if no other existing LDAP field can be used). The idea is to retrieve users MDM role assignments directly from that LDAP field when a user logs on to an MDM application. The mds.ini setting for MDM role assignments retrieved from dedicated LDAP field is: MDM Roles Attribute=MDMRoles Group Identifier=
The Group Identifier parameter must explicitly be set to empty to distinguish the alternative search algorithm from the basic algorithm.
2.16.8
MDM LDAP Algorithm (Fallback)
When the Master Data Server is using LDAP (LDAP in Use=True) user validation can fail for several reasons, such as the LDAP Server cannot be reached or the username does not exist on that server. When Fallback in Use=True, the system tries to authenticate the user after such a failure, as follows: If the username is not validated in LDAP because either the user does not exist in LDAP, or the LDAP server is unreachable, then MDM will attempt to validate that user against the traditional, internal MDM methodology. With this method, the username (and accompanying roles) must already be defined in the particular MDM repository. This may be valuable for select usernames that you wish to maintain in MDM in addition to LDAP.
This kind of authentication should be restricted to admin users only. It should be used for testing or emergency only, like LDAP server downtime Although MDIS and MDSS could log-on on behalf of a repository Admin user if the fallback option was set, it's recommended to create technical users in the LDAP user directory for this purpose.
April 2012
14
2.16.9

MDM Architecture in 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. Run a Verify > Repair operation on all repositories mounted on a Master Data Server after configuring the mds.ini file for LDAP validation. If using an LDAP viewer, perform security validation and retrieve role information from LDAP as outlined in the previous sections. 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.
Role names within MDM cannot contain semi-colons (;) nor start with an exclamation point (!), as enforced by MDM Console. 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.
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.
2.16.10 Restrictions and Limitations

MDM Console users do not run under LDAP in the initial release of this functionality. We will review the value of putting MDM Console access under LDAP control at some future time.
2.16.11 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.
You should always test changes to LDAP with the MDM client software that you use. Some of the more common error messages are listed below. Error Ambiguous User User Authorization Failed Explanation / Possible Reasons More than one user exists with this login name.
User exists, wrong password given.
April 2012
15
Error Admin Authorization Failed Invalid User Unable to Initialize LDAP Host Mds.ini Problem
Explanation / Possible Reasons Invalid Admin DN or password setting in mds.ini. Invalid Admin Identifier setting in mds.ini. Invalid Base DN setting in mds.ini. User does not exist in LDAP. Invalid User Identifier setting in mds.ini. Server or port specified in mds.ini could not be reached.
A required parameter is missing from the [MDM LDAP] section of mds.ini. Check the Master Data Server log for the missing parameter name. None of the roles retrieved from LDAP are valid for this repository. Invalid MDM Roles Attribute setting in mds.ini.
User Has No Roles
April 2012
16
Network and Communication Security LDAP Support
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 wellknown 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.
Carelessly handled users and authorizations for connection destinations can cause severe security issues. 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.
April 2012
17
Network and Communication Security Securing Communication Channels Using SSL
3.1
Securing 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 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 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
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 SAP Service Marketplace at service.sap.com/installmdm71 Master Guide Securing Communication Channels Using Secure Sockets Layer (SSL).
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 SSL Library file: sapcrypto.dll Key file: CLIENT.PSE Ticket file: ticket
MDM client-side components:
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.
April 2012
18
Network and Communication Security Configuring MDM Servers for SSL
3.3
Configuring MDM Servers for SSL
Server-side SSL settings are stored in a servers .ini file. For information about configuring MDM server parameters, see SAP Service Marketplace at service.sap.com/installmdm71 MDM Console Reference Guide Part 7: MDS Administration.
If you are upgrading from a version of MDM prior to MDM 7.1 SP07, the parameters described in this section must be manually added to your server configuration files. They are added automatically only for new installations of MDM 7.1 SP07.
3.3.1
MDS Configuration
The following Master Data Server (MDS) settings are stored under the [MDM Server] section of the mds.ini file. Parameter Listening Mode SSL Lib Path SSL Key Path Description Specifies if the Master Data Server accepts unencrypted, encrypted, or both types of connections. Options are Unencrypted, SSL, or Both. The path to the servers SSL Library file. The path to the servers SAPSSLS.PSE file
If the Listening Mode parameter is set to Unencrypted, attempts by clients to establish secure connections to the Master Data Server will fail.
3.3.2
Auxiliary and Slave Server Configuration
The following auxiliary server (MDIS, MDSS, MDLS) settings are stored in mdis.ini, mdss.ini, and mdls.ini 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). Parameter Service Control Security Enabled SSL Enabled Description Options are True or False. Must always be False on UNIX landscape. 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. The path to the auxiliary servers SSL Library file. The path to the auxiliary servers SAPSSLS.PSE file
SSL Lib Path SSL Key Path
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.
April 2012
19
Network and Communication Security Connecting Securely from MDM Clients
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. For more information, see SAP Service Marketplace at service.sap.com/installmdm71 MDM Console Reference Guide Part 7: MDS Administration SSL-Specific Parameters for a Client MDS.
3.4
3.4.1
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 SSLenabled 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 SAP Service Marketplace at service.sap.com/installMDM71 MDM Console Reference Guide Part 7: MDS Administration Accessing Master Data Servers.
3.4.2
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 on the clients Connect To MDM Repository dialog.
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 clients reference guide.
April 2012
20
Network and Communication Security Connecting Securely from MDM Clients
3.4.3
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 SAP Service Marketplace at service.sap.com/installmdm71 MDM Console Reference Guide Part 14: CLIX Command Line Interface.
3.4.4
Connecting Securely from MDM APIs
For information about establishing SSL secure connections from applications that use MDM Java or .NET APIs, see SAP Service Marketplace at service.sap.com/installmdm71 MDM Java and .NET API : Getting Started with Java API Tasks Managing Connections and Sessions For information about establishing SSL secure connections from ABAP API applications, see SAP Service Marketplace at service.sap.com/installmdm71 MDM ABAP API Configuring MDM ABAP API for SNC.
3.4.5

Connecting Securely from MDM Web UIs
For information about establishing SSL secure connections from Web UIs, see SAP Service Marketplace at service.sap.com/installmdm71 : MDM Portal Content Development Guide Connecting with the MDM Repository Configuring a System Object MDM Web Dynpro Components Guide Installing the MDM Web Dynpro Environment Creating a Destination for the MDM Repository
3.4.6

Connecting Securely from MDM Web Services
For information about establishing SSL secure connections from Web UIs, see SAP Service Marketplace at service.sap.com/installmdm71 MDM Web Services Guide : 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
3.4.7
Connecting Securely from MDM PI Adaptor
For information about establishing SSL secure connections from the MDM PI Adaptor, see SAP Service Marketplace at service.sap.com/installmdm71 MDM PI Adapter Guide Setting Up Messaging MDM Adapter Specific Configuration.
April 2012
21
Network and Communication Security Server Landscape
3.4.8
Connecting Securely from MDM Enrichment Contoller
For information about establishing SSL secure connections from the MDM PI Adaptor, see SAP Service Marketplace at service.sap.com/installmdm71 MDM Enrichment Architecture Guide Editing the Configuration File of the Enrichment Controller.
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
3.6.1
Communication Channels Used

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 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 below ).
3.6.2
MDS/Database Server Communication
MDS uses the ODBC API to connect to the databases.
April 2012
22
Network and Communication Security Network Ports Used
3.7
Network Ports Used

Unencrypted Port 59950 59650 59750 59850 SSL Port 59951 59651 59751 59851
As of MDM 7.1 SP08, MDM uses the following default listening ports: Application MDS MDLS MDIS MDSS
You can configure different listening ports from the installer when you install/upgrade MDM. For more information, see SAP Service Marketplace at service.sap.com/installmdm71 Installation Guide or Upgrade Guide.
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.
3.9
Secure Connection to Microsoft Active Directory Configuration

Description Specifies if the Master Data Server connects securely to the Microsoft Active Directory LDAP server. Options are True or False.
The following Master Data Server (MDS) setting is stored under the [LDAP] section of the mds.ini file. Parameter Secure Connection to Active Directory
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.
3.10.1
Trusted Connection Configuration Parameters
The following Master Data Server (MDS) settings are stored under the [MDM Server] section of the mds.ini file. Parameter Trusted Connection Authentication Mode Description Specifies the type of authentication required for trusted connections to the Master Data Server (MDS). Options are None, IP, SSL, or Both.
April 2012
23
Network and Communication Security IP-Based Trusted Connections
If the Trusted Connection Authentication Mode parameter is 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.
SSL-based authentication of trusted connections also requires the Master Data Servers Listening Mode parameter to be set to SSL or Both .
3.11 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).
IP-bases trusted connections are currently available to SAP system usernames only. Users must still provide a DBMS password for operations which require a connection to the DBMS.
3.11.1

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

Separation of Duties Support
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.
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 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). Legend of access values: Function log: 1 = Execute 0 = None Table and field log: 2 = Read-only 3 = Read/write
April 2012
29
Authorization Concepts and Management Change Log for Authorization Management
Function ID map: Records Function ID in log: 16777217 16777218 16777233 16777219 16777220 16777234 16777221 16777222 16777223 16777235 16777224 16777225 16777226 16777227 16777228 16777229 16777230 16777231 16777232 Corresponding hex value: 1000001 1000002 1000011 1000003 1000004 1000012 1000005 1000006 1000007 1000013 1000008 1000009 0100000A 0100000B 0100000C 0100000D 0100000E 0100000F 1000010 Images Function ID in log: 33554433 33554434 Corresponding hex value: 2000001 2000002 Hierarchy Function ID in log: 50331649 50331650 50331651 Corresponding hex value: 3000001 3000002 3000003 Taxonomy Function ID in log: 67108865 67108866 67108867 Corresponding hex value: 4000001 4000002 4000003 Function name: AddAttributes DeleteAttributes ModifyAttributes Function name: MoveHierarchy HideChildren CreateAliases Function name: ModifyImagePrintSize CropAndRotateImages Function name: AddRecords ModifyRecords ModifyCheckedOutRecords DeleteRecords MergeRecords MergeCheckedOutRecords ProtectRecords UnprotectRecords CheckOutRecords CheckOutNewRecords CheckInRecords RollBackRecords CheckInNonOwned RollBackNonOwned ModifyJoinNonOwned has been used before has been used before has been used before Has not been used before
April 2012
30
67108868 67108869 67108870 67108871 67108872 67108873 67108874 67108875 67108876 67108877 67108878
4000004 4000005 4000006 4000007 4000008 4000009 0400000a 0400000b 0400000c 0400000d 0400000e Families
ConvertAttributeType SplitAttribute MergeAttributes SetAttributePriority ModifyLinkedAttributes ReassignAttributeRatings AddMatchingSets DeleteMatchingSets ModifyMatchingSets Partition ConsolidateChildren
Function ID in log: 100663297 100663298 100663299
Corresponding hex value: 6000001 6000002 6000003 Layouts
Function name: SynchronizeFamilyTree ModifyFamilyData ModifyFamilyPartitioning
Function ID in log: 117440513 117440514
Corresponding hex value: 7000001 7000002 Publications
Function name: ModifyLayout RenameLayoutColumns
Function ID in log: 134217729 134217730 134217731 134217732 134217748 134217749 134217750 134217733 134217751 134217752 134217753 134217734 134217735 134217754
Corresponding hex value: 8000001 8000002 8000003 8000004 8000014 8000015 8000016 8000005 8000017 8000018 8000019 8000006 8000007 0800001a
Function name: AddPublications DeletePublications RenamePublications AddPublicationNodes AddSectionNodes AddInternalNodes AddPresentationNodes DeletePublicationNodes DeleteSectionNodes DeleteInternalNodes DeletePresentationNodes MovePublicationNodes RenamePublicationNodes SplitSectionNodes
April 2012
31
134217755 134217742 134217743 134217744 134217745 134217746 134217747 134217756 134217757 134217758 134217759 134217760 134217761 134217762 134217763 134217768 134217764 134217765 134217766 134217767 134217769 134217736 134217738 134217739 134217740 134217741
0800001b 0800000e 0800000f 8000010 8000011 8000012 8000013 0800001c 0800001d 0800001e 0800001f 8000020 8000021 8000022 8000023 8000028 8000024 8000025 8000026 8000027 8000029 8000008 0800000a 0800000b 0800000c 0800000d
CombineSectionNodes ModifyCachedLayoutItems ModifySectionNodeData ModifyPresentationNodeData AddSpreads DeleteSpreads ModifySpreads ShuffleSection AddPages DeletePages MovePages AddPresentations DeletePresentations MovePresentations RecoverPresentationItems AddItemsToSnapshot DeletePresentationItems RelocatePresentationItems FlowSection ApplyTemplates PurgeDisconnectedFromSnap ModifyPublicationLayout ModifyPublicationFamilyData ModifyPublicationRecords ModifyPublicationFormat ModifyDocWorkspace
Publisher Checkout Function ID in log: 251658241 251658242 251658243 Corresponding hex value: 0F000001 0F000002 0F000003 Publisher Indexes Function ID in log: 167772161 167772162 167772163 Corresponding hex value: 0A000001 0A000002 0A000003 Function name: AddPubIndices DeletePubIndices RenamePubIndices Function name: CheckoutPubObj AssignPubObjCheckout OverridePubObjCheckout
April 2012
32
167772164 167772165 167772166 167772167 167772168 167772169 167772170 167772171
0A000004 0A000005 0A000006 0A000007 0A000008 0A000009 0A00000A 0A00000B Branded Client
ModifyPubIndexDataSource ModifyPubIndexKeyDefs ModifyPubIndexEntryRedefines ModifyPubIndexProperties ModifyPubIndexStyles ModifyPubIndexDocumentProperties AddPubIndexSource DeletePubIndexSource
Function ID in log: 150994958 150994959 150994945 150994946 150994947 150994948 150994949 150994950 150994951 150994952 150994953 150994954 150994955 150994956 150994957 150994976
Corresponding hex value: 0900000e 0900000f 9000001 9000002 9000003 9000004 9000005 9000006 9000007 9000008 9000009 0900000a 0900000b 0900000c 0900000d 9000020 Distributions Role
Function name: ModifyMultipleRecords DeleteMultipleRecords AddToMask RemoveFromMask ReplaceInMask ModifyMask ImportFromExcel ExportToText ExportToExcel ExportToAccess SaveOriginalToDisk EnableFamilyModifications EnableLayoutModifications EnablePublicationModifications EnablePubIndexModifications SetNamedSearch
Function ID in log: 184549377 184549378 184549379 184549380 184549381 184549382 184549383
Corresponding hex value: 0B000001 0B000002 0B000003 0B000004 0B000005 0B000006 0B000007
Function name: AddImportMaps ModifyImportMaps DeleteImportMaps AddExportMaps ModifyExportMaps DeleteExportMaps EnableKeyMapping
April 2012
33
Authorization Concepts and Management Change Log Archiving
Administration Function ID in log: 201326593 201326594 201326595 201326596 201326597 201326598 201326599 201326600 201326601 201326602 201326603 201326604 201326605 201326606 Corresponding hex value: 0C000001 0C000002 0C000003 0C000004 0C000005 0C000006 0C000007 0C000008 0C000009 0C00000a 0C00000b 0C00000c 0C00000d 0C00000e Schema Function ID in log: 218103809 218103810 218103811 218103812 218103813 218103814 218103815 218103816 218103817 218103818 218103819 Corresponding hex value: 0D000001 0D000002 0D000003 0D000004 0D000005 0D000006 0D000007 0D000008 0D000009 0D00000a 0D00000b Function name: ImportSchema ExportSchema AddTable ModifyTable DeleteTable AddField ModifyField DeleteField AddSchemaObject ModifySchemaObject DeleteSchemaObject Function name: DescribeRepository MaintainRegions MaintainConnection MaintainRepositorySettings SynchronizeSlave NormalizeRepository ShareRepository UnlockRepository CompactRepository RepairRepository TruncateChangeLog RefreshCalcFields StartRepository StopRepository
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.
There is no MDM tool for archiving old log files. Older log files should be archived manually or using an archive tool.
April 2012
34
Auditing Logging of Security-Relevant Information
5
5.1
Auditing
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.) 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)
April 2012
35
Content Security Document and File Upload
6
6.1
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 File Locations and File System Security
Under Windows, the base directory is usr\sap\<SAPSID>\<instance_name>. Under Linux/Solaris, you can set the base directory to a different directory. In both cases, additional directories are created under BASEDIR\mdm as follows: Config: Data: Exe: Log: MDM Accelerator Contains accelerator files for repositories Access recommendation: Do not share Contains MDM log files. Access recommendation: Can be made available to MDM administrators Contains the application Access recommendation: Do not share Contains cached information Access recommendation: Do not share Contains the configuration ini file Access recommendation: Do not share
Archives Contains created repository archives Access recommendation: Can be made available to MDM administrators
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
April 2012
36
MDM File Locations and File System Security Session IDs
Reports Contains repository operation (archive, duplicate, load, unarchive, update, verify check, verify repair) reports Access recommendation: Can be made available to MDM administrators
Sec 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. Not used.
If the access recommendation of a folder is restricted, it has to be protected by operating system settings.
7.1

Session IDs
Server session (certain console functions) Admin session (certain console functions). User session (data manager functions).
The Master Data Server uses session IDs to authenticate client users. There are different sessions for different purposes:
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.2
User Session Lock
A long inactivity (for example, 30 minutes) implies that the user has left his or her work place. If the 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 reauthentication 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.
April 2012
37
Regulatory Compliance Person-Related Data
8
8.1
Regulatory Compliance
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).
April 2012
38

MDM Security 71

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MDM Security 71

Încărcat de

Drepturi de autor:

Formate disponibile

SAP NetWeaver

MDM Security Guide

Documentation on SAP Service Marketplace You can find this documentation at

MDM 7.1 Security Guide

3.0 / September 2011

2.0 / May 2011

MDM 7.1 Security Guide

Components of SAP NetWeaver MDM Users

MDM 7.1 Security Guide

MDM Security Guide

Scope of this Guide

Fundamental Security Guides

SAP NetWeaver Process Integration 7.1

SAP NetWeaver Security Guide

Operating Systems and Database Platforms

SAP NetWeaver Security Guide

Components of SAP NetWeaver MDM Users

MDM 7.1 Security Guide

Components of SAP NetWeaver MDM

Users, Roles and Authentication Users

MDM 7.1 Security Guide

Users, Roles and Authentication

Master Data Servers

Roles and Authorizations

Users, Roles and Authentication Predefined Users, Roles and Passwords

MDM 7.1 Security Guide

Predefined Users, Roles and Passwords

Single Sign-On Support

Authentication and SSO-like Feature in MDM Java Components

MDM 7.1 Security Guide

iViews and UWL Authentication and the SSO-like Feature

MDM Web Services Generator Security

MDM Web Services Security

Users, Roles and Authentication Password Change Enforcement

MDM 7.1 Security Guide

Basic Authentication with SAP Logon Ticket

Password Change Enforcement

Minimum Length of Password

Users, Roles and Authentication Password Validity Timeframe

MDM 7.1 Security Guide

Password Validity Timeframe

Users, Roles and Authentication Strong and Secure Passwords

MDM 7.1 Security Guide

Strong and Secure Passwords

2.10 Deactivating Authorization Credentials

2.11 Password History

2.12 Locking User Accounts

Users, Roles and Authentication CLIX Commands for Managing Passwords

MDM 7.1 Security Guide

2.13 CLIX Commands for Managing Passwords

2.14 User Administration Tools

Users, Roles and Authentication Emergency User Concept

MDM 7.1 Security Guide

2.15 Emergency User Concept

2.16 LDAP Support

How LDAP Works

Users, Roles and Authentication LDAP Support

MDM 7.1 Security Guide

Basic MDM LDAP

MDM LDAP Fields

Secure Connection to Active Directory

Users, Roles and Authentication LDAP Support