mdm security 71
TRANSCRIPT
-
7/30/2019 Mdm Security 71
1/44
SAP NetWeaver
MDM Sec ur i t y Guide
SAP Net Weaver MDM 7.1 SP08
Docum ent Ver s ion 3.1 Apr i l 3, 2012
-
7/30/2019 Mdm Security 71
2/44
October 2011
April 2012
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 notbe modified or altered in any way.
Documentation on SAP Service Marketplace
You can find this documentation atservice.sap.com/instguidesNW04
-
7/30/2019 Mdm Security 71
3/44
October 2011
April 2012
Typogr aph i cC onvent i ons
Type Style Represents
Example Text Words or characters quotedfrom the screen. Theseinclude field names, screentitles, pushbuttons labels,menu names, menu paths,and menu options.
Cross-references to otherdocumentation.
Example text Emphasized words orphrases in body text, graphictitles, and table titles.
EXAMPLE TEXT Technical names of systemobjects. These include reportnames, program names,transaction codes, tablenames, and key concepts of aprogramming language whenthey are surrounded by bodytext, for example, SELECTand INCLUDE.
Example text Output on the screen. Thisincludes file and directorynames and their paths,messages, names ofvariables and parameters,source text, and names ofinstallation, upgrade anddatabase tools.
Example text Exact user entry. These arewords or characters that youenter in the system exactly asthey appear in thedocumentation.
Variable user entry. Anglebrackets indicate that youreplace these words andcharacters with appropriateentries to make entries in thesystem.
EXAMPLE TEXT Keys on the keyboard, forexample, F2 or ENTER.
I cons
Icon Meaning
Caution
Example
Note / Tip
Recommendation
Syntax
-
7/30/2019 Mdm Security 71
4/44
MDM 7.1 Security Guide
April 2012
Document History
DocumentVersion
Description of Change
3. 1/ April 2012 Consolidated information from the MDM Console Reference guideinto the following sections:
o LDAP Support (page 10)
o Authentication of Trusted Connections (page 23)
3.0 / September2011
Guide updated for MDM 7.1 SP08
Secure Trusted Connection support added. See Authentication ofTrusted Connections (page 23).
New mds.ini option added for securing connections to MicrosoftActive Directory LDAP Server. See Secure Connection to MicrosoftActive Directory Configuration (page 23).
Default Admin user password changed to sapmdm. See StandardUser (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 passwordcreation. See Emergency User Concept (page 10).
2.0 / May 2011 Guide updated for MDM 7.1 SP07
SSL support added. See Network and Communication Security (page17).
-
7/30/2019 Mdm Security 71
5/44
MDM 7.1 Security Guide
April 2012
Contents
MDM SECURITY GUIDE .......................................................................................................... 11 COMPONENTS OF SAP NETWEAVER MDM ................................................................. 22 USERS, ROLES AND AUTHENTICATION ....................................................................... 3
2.1 Users ......................................................................................................................... 32.2 Roles and Authorizations .......................................................................................... 3
2.2.1 Roles .............................................................................................................. 32.2.2 Authorizations ................................................................................................. 3
2.3 Predefined Users, Roles and Passwords ................................................................. 42.4 Single Sign-On Support ............................................................................................ 42.5 Authentication and SSO-like Feature in MDM Java Components ............................ 4
2.5.1 User Management .......................................................................................... 42.5.2 Trusted Connection ........................................................................................ 42.5.3 iViews and UWL Authentication and the SSO-like Feature ........................... 52.5.4 MDM Web Services Generator Security ........................................................ 52.5.5 MDM Web Services Security .......................................................................... 5
2.6 Password Change Enforcement ............................................................................... 62.7 Minimum Length of Password ................................................................................... 62.8 Password Validity Timeframe .................................................................................... 72.9 Strong and Secure Passwords.................................................................................. 82.10 Deactivating Authorization Credentials ..................................................................... 82.11 Password History ...................................................................................................... 82.12 Locking User Accounts ............................................................................................. 82.13 CLIX Commands for Managing Passwords .............................................................. 92.14 User Administration Tools ......................................................................................... 92.14.1Standard User ................................................................................................ 92.15 Emergency User Concept ....................................................................................... 102.16 LDAP Support ......................................................................................................... 10
2.16.1What is LDAP? ............................................................................................. 102.16.2How LDAP Works ......................................................................................... 102.16.3Basic MDM LDAP ......................................................................................... 112.16.4MDM LDAP Fields ........................................................................................ 112.16.5LDAP Access ................................................................................................ 112.16.6MDM LDAP Algorithm (Basic) ...................................................................... 132.16.7MDM LDAP Algorithm (Alternative) .............................................................. 142.16.8MDM LDAP Algorithm (Fallback) ................................................................. 142.16.9MDM Architecture in LDAP .......................................................................... 152.16.10 Restrictions and Limitations .................................................................... 152.16.11 LDAP Errors and MDM ........................................................................... 15
3 NETWORK AND COMMUNICATION SECURITY .......................................................... 173.1 Securing Communication Channels Using SSL ...................................................... 183.2 Secure Connection Prerequisites............................................................................ 183.3 Configuring MDM Servers for SSL .......................................................................... 19
3.3.1 MDS Configuration ....................................................................................... 193.3.2 Auxiliary and Slave Server Configuration ..................................................... 19
3.4 Connecting Securely from MDM Clients ................................................................. 203.4.1 Connecting Securely from MDM Console .................................................... 20
-
7/30/2019 Mdm Security 71
6/44
-
7/30/2019 Mdm Security 71
7/44
Components of SAP NetWeaver MDM MDM 7.1 Security Guide
Users
April 2012 1
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 certainphase of the software lifecycle, whereby the Security Guides provide information that isrelevant 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 GuidesSee the corresponding Security Guides of the SAP components that are a part of the MDMscenarios.
Application Guide Most Relevant Sections or
Specific RestrictionsSAP ECC 6.0 SAP ERP 2005 Security Guide In the SAP ERP 2005 Security
Guide, choose SecurityGuides for SAP ECC 6.0.
SAP NetWeaver ProcessIntegration 7.1
SAP NetWeaver SecurityGuide
In the SAP NetWeaverSecurity Guide, chooseSecurity Guides for SAP
NetWeaver ProductsSAPSecurity Guide PI.
Operating Systems andDatabase Platforms
SAP NetWeaver SecurityGuide
In the SAP NetWeaverSecurity Guide, choose
Operating System andDatabase Platform SecurityGuides.
For a complete list of the available SAP Security Guides, seeservice.sap.com/securityguide on the SAP Service Marketplace.
-
7/30/2019 Mdm Security 71
8/44
Components of SAP NetWeaver MDM MDM 7.1 Security Guide
Users
April 2012 2
1 Components of SAP NetWeaver MDM
For a complete list of SAP NetWeaver MDM components, see SAP ServiceMarketplace at service.sap.com/installMDM71 Master Guide.
-
7/30/2019 Mdm Security 71
9/44
Users, Roles and Authentication MDM 7.1 Security Guide
Users
April 2012 3
2 Users, Roles and AuthenticationMDM provides its own user management. There are no user and role features delivered ontop of the MDM user management.
2.1 UsersYou 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 tocontrol access.
When mounting a Master Data Server for the first time using the MDM Console, make surethat 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 ServersChange Password.
MDM Repositories
You access MDM repositories with a user and password. SAP NetWeaver MDM uses its ownmechanisms 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 predefinedAdministrator 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 eachtime you start the MDM Console.
The icon next to the repository name indicates that you have to log onto therepository.
For more information about updating repositories, see SAP Service Marketplace at
service.sap.com/installMDM71 MDM Upgrade GuideUpdate Repository.
2.2 Roles and AuthorizationsSAP 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 AdministrationMDM User and Role
Management
2.2.1 RolesRoles are assigned to users. Each repository contains the following standard roles: Adminand Default. They cannot be deleted. The Admin role cannot be changed. The Default role ispredefined with full privileges.
2.2.2 AuthorizationsAuthorizations (called privilegesin MDM) are assigned to roles and are edited in the rolestable. You can granularly enable/disable authorizations for specific functions (such as AddRecords or Delete Records) or limit access to tables and fields (such as read/write accessand constraints).
-
7/30/2019 Mdm Security 71
10/44
Users, Roles and Authentication MDM 7.1 Security Guide
Predefined Users, Roles and Passwords
April 2012 4
2.3 Predefined Users, Roles and PasswordsIn general there are one predefined user and two predefined roles when creating a repositoryfrom scratch. The predefined user is the Admin user. The Admin role is assigned to it. Apassword 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 toreduce these privileges shortly after creating the repository.
2.4 Single Sign-On SupportSAP 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 therepositories.
The .NET and Java APIs use the user name and password or the trusted connection conceptto log onto the Master Data Server and the repositories. For more information about trustedconnections, see Trusted Connection below.
The ABAP API uses the trusted connection concept and extends this concept by alwayslogging on with the sy-uname of the logged on user on the AS ABAP.
2.5 Authentication and SSO-like Feature in MDMJava 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 theapplication running on the SAP NetWeaver Application Server Java (AS Java) and MDS. Thesame 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 isimplemented in the MDM applications on the AS Java.
2.5.1 User ManagementFor 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 ConnectionTrusted Connection configuration has direct influence on how authentication is performed andwhether or not the SSO-like feature is supported. See Authentication of TrustedConnections for more information about trusted connection configuration.
-
7/30/2019 Mdm Security 71
11/44
Users, Roles and Authentication MDM 7.1 Security Guide
Authentication and SSO-like Feature in MDM Java Components
April 2012 5
2.5.3 iViews and UWL Authentication and the SSO-likeFeature
The following facets have an impact on the authentication mode and SSO-like featuresupport:
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 SecurityThe Web Services Generator application is a Web application supporting basic HTTPauthentication of SAP NetWeaver Application Server Java (AS Java). MDM user credentialsare inserted by the user in the Web Services Generator wizard.
2.5.5 MDM Web Services SecurityThe Web services generated by the Web Services Generator have the following securitycapabilities:
2.5.5.1 SSL Support
The transport protocol for the generated Web services can be either SOAP over HTTP orSOAP over HTTPS. You can also specify that the transport protocol for connecting generatedWeb 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 Adapterand 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 requiresuser management as described in User Management on page 4, under the Same users inUME and MDSsection.
-
7/30/2019 Mdm Security 71
12/44
Users, Roles and Authentication MDM 7.1 Security Guide
Password Change Enforcement
April 2012 6
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 inUME and MDSsection) and a trusted connection between AS Java and MDS are required.
2.6 Password Change EnforcementUsers with the appropriate authorization (such as the Admin role) can create new users in theMDM Console. The end user can be forced to change the password after the first logon to theMaster 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 inthe 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 userat any time.
After creating a user, the default setting for the initial password behavior isNo. You must set it to Yes after user creation.
2.7 Minimum Length of PasswordThe minimum length of passwords can be customized. You can maintain it centrally in themds.ini file located in the server directory ...\sap\MAF\MDSXX\config.
One parameter is used for this setting:
Minimal Password Length=5This option sets the minimal password length (here 5 tokens).
It is important to assign a strong and secure default password to each createduser.
After you change the minimal password length in the ini file, this password length is notautomatically applied to all users whose assigned password is shorter than the minimalpassword length.
The default value for the minimal password length is 5. It can be set to zero, but we do notrecommend that you allow users without passwords.
-
7/30/2019 Mdm Security 71
13/44
Users, Roles and Authentication MDM 7.1 Security Guide
Password Validity Timeframe
April 2012 7
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 istherefore advisable to limit access to this file.
2.8 Password Validity TimeframeUsers are forced to change the password after the validity timeframe for the password hasexpired.
The validity timeframe of the password is maintained centrally in the mds.ini filelocated in the server directory ..\sap\MAF\MDS{instance number}\config.
Two parameters are used for this setting:
Password Expiration Days=90This option sets the time until a password will expire (here 90days).
Password Expiration Warning=7This option sets the number of days a user will get warningsbefore his password expires (here 7 days).
After the defined number of warnings, the user cannot log onto the system without changinghis 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 setto yes.
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 istherefore advisable to limit access to this file.
-
7/30/2019 Mdm Security 71
14/44
Users, Roles and Authentication MDM 7.1 Security Guide
Strong and Secure Passwords
April 2012 8
2.9 Strong and Secure PasswordsPasswords that are easily guessed (for example, with a dictionary attack, UserID, companyname) are not recognized and are prevented by the Master Data Server. Users of the MDMclients 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 orrepetitions, dictionary words and sequences should not be used.
2.10 Deactivating Authorization CredentialsAuthentication credentials are not automatically deactivated if they have not been used for acertain period of time.
The administrator should deactivate user accounts that are not in use byassigning a non-authorized role and/or by assigning a secret password.
2.11 Password HistoryNo history is stored for the passwords of a user. The user is not prevented from changing hisor 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 AccountsThe user account is locked after a defined number of failed password logon attempts for adefined length of time.
The user account lock settings is maintained centrally in the mds.ini file locatedin the server directory ...\sap\MAF\MDS00\config.
Two parameters are used for this setting:
Lock Account After Failed Password Attempts=3This option sets the number of failed password logon attemptsallowed before the user account is locked (here 2 attempts; withthe third attempt the account will already be locked).
Lock Account Duration=1800This option sets the duration of the password lock after the failedpassword attempts allowed (here 1800 seconds).
After the defined number of failed password logon attempts, the user cannot log onto thesystem for the defined number of seconds.
The administrator can reset a locked account at any time. The flag Reset Account Lock inthe console user administration deactivates the lock if it is set to yes.
-
7/30/2019 Mdm Security 71
15/44
-
7/30/2019 Mdm Security 71
16/44
Users, Roles and Authentication MDM 7.1 Security Guide
Emergency User Concept
April 2012 10
Standard User
System User ID Password Description
MDM Repository Admin sapmdm MDM 7.1 Installation Guide
MDM 7.1 Console ReferenceGuide
2.15 Emergency User ConceptThe emergency user concept defines how to access a system in case of loss of alladministrative user credentials.
To create a new password for the Admin user of an MDM repository, use the CLIX commandrepEmergencyAdminUserSetPassword .For complete information about this command,
see SAP Service Marketplace at service.sap.com/installMDM71 MDM Console
Reference Guide Part 14: CLIX Command Line InterfaceCLIX Commands.
2.16 LDAP SupportSome 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 anddistribute user privileges, rights, and access from a single location.
Without LDAP, the system manager is forced to maintain familiarity with the proprietaryaccess control mechanism offered by each software product, and to use each one toseparately 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 accesscontrol, and it becomes clear how much of a burden it can be to manage access controlwithout LDAP.
By contrast, by using MDM in conjunction with LDAP, MDM customers can manage accesscontrol information in a single location with a common, familiar interface of their choosing.
2.16.2 How LDAP WorksLDAP 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. InBigFoot, this returns 100+ records in the United States. Or you can restrict the search byadding 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 includesName and State lookup categories. Owners of LDAP directories can retrieve additionalfields, categories, or attributes, such as Telephone Numbers, Primary Automobile, HairColor, or MDM User Type. This additional information can be used as well for additionalselection criteria.
For MDM to support LDAP, SAP has designated the information that MDM will be queryingfrom and that must be entered and maintained within the customers LDAPdatabase/directory.
-
7/30/2019 Mdm Security 71
17/44
Users, Roles and Authentication MDM 7.1 Security Guide
LDAP Support
April 2012 11
2.16.3 Basic MDM LDAPUsing 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 MDMcan properly search for user information. Unless an existing field is used, the customermust create one attribute field (named as desired) for MDM use.
The MDM software adds no records to the LDAP directory, nor does it otherwisemanage or make any design changes to its structure. It only performs lookups fromthe LDAP directory to read its contents.
Single sign-on is notsupported. Instead, MDM client software prompts the user forname and password. It was done this way for simplicity, interoperability with UNIXsystems, and flexibility with various client programs or network configurations such asVPNs.
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 FieldsThe MDM LDAP fields are defined or created and then populated by the customer in thecustomers 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 multipleentries as though they were in a single record separated by semi-colons (;).
2.16.5 LDAP AccessAll LDAP access is performed by the Master Data Server. Clients of the Master Data Serverprovide MDMUserName/MDMUserPassvalues, 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 Description
Listening Mode Specifies if the Master Data Server accepts unencrypted, encrypted,or both types of connections. Options are Unencrypted, SSL, or
Both.
Secure
Connection to
Active Directory
Specifies if the Master Data Server connects securely to theMicrosoft Active Directory LDAP server. Options are True or False.
-
7/30/2019 Mdm Security 71
18/44
Users, Roles and Authentication MDM 7.1 Security Guide
LDAP Support
April 2012 12
Parameter Description
LDAP in Use Whether or not MDM should use LDAP. Options are True or False.
Server
Server Port
LDAP system address (usually a DNS name). The LDAP Serverspecification can be either a hostname or an IP address to whichMDM attempts to bind; optional Server Port defaults to 389.
Admin DN
Admin Password
The full DN and password of an Admin that can search for the usersfull DN.
For downward compatibility with previous releases MDM willconstruct a missing Admin DN from the following settings: AdminIdentifier, Admin Name and Base DN.
MDM does not need to be an administrative user to browse thedirectory. Just leave both Admin DN and Admin Password blank ifdirectory setting allows anonymous binding.
Base DNAny other lookup information, such as a base DN suffix, which canbe used to distinguish this branch from others that the search shouldexclude (e.g. o=sap,c=US). It can also include information thatdifferentiates one MDM instance from other MDM instances.
User Identifier
The name of the LDAP id field which will match the value the userprovides as the Username at logon. This would typically besomething like cn or uid.
MDM Roles
Attribute
The name of the LDAP attribute that will hold the group assignments,typically something like memberOf.
MDM Email
Attribute
The name of the LDAP attribute that holds email addresses that areassigned to users and is required for workflow. Usually this attribute
is mail.
Fallback in Use
Whether or not MDM should use fallback methods to providetemporary, read-only access when connection to the LDAP server isinterrupted. Options are True or False.
Group Identifier
The name of the LDAP field which identifies groups. This is typicallysomething like cn or samAccountName. This field is mandatoryfor Group Mapping algorithms. See MDM role algorithm below.
Member Attribute
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 LDAPserver IBM Tivoli, See MDM role algorithm below.
Page Size
The number of records sent by the LDAP server per page. Default is
1000. This need not be changed unless the LDAP server settingdiffers.
User Filter Optional. Limits the users search result to LDAP user entries only.
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.
-
7/30/2019 Mdm Security 71
19/44
Users, Roles and Authentication MDM 7.1 Security Guide
LDAP Support
April 2012 13
All LDAP parameters except LDAP in Use can be changed in mds.ini withouthaving to stop and restart MDS.
You must run aVerify > Repair operation on all repositories mounted on aMaster 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-specificuser authorization.
By contrast, if the Master Data Server is configured to use LDAP and is unable to find theLDAP server, it will completely prevent any access to the MDM system, unless fallbackparameters are specified.
Consider the following mds.ini example for MS Active Directory:
[MDM LDAP]
LDAP in Use=TrueServer=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 UserNameand 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 UserIdentifier 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, suchas 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 theLDAP user group assignments. The LDAP group name maps almost directly to the MDMrole name. MDM reads the attribute value, extracts the group name, drops the rest of thegroups 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 whichare valid. Roles not found are assumed to be associated with another MDM repositoryand are ignored (if this is a result of a typo, the user will likely notice that he is unable to
perform certain expected activities).
-
7/30/2019 Mdm Security 71
20/44
Users, Roles and Authentication MDM 7.1 Security Guide
LDAP Support
April 2012 14
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 rolenames 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 providedpassword. If this fails, the user is prevented from logging into MDM.
This MDM LDAP algorithm applies not only in connection with Microsoft Active Directory, butalso for other situations where users groups match MDM roles. For example, for IBM TivoliDirectory 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. Insome 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 dedicatedattribute (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 userlogs 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 todistinguish 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 failfor several reasons, such as the LDAP Server cannot be reached or the username does notexist on that server. When Fallback in Use=True, the system tries to authenticate theuser 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 thetraditional, internal MDM methodology. With this method, the username (and accompanyingroles) must already be defined in the particular MDM repository. This may be valuable forselect 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 beused for testing or emergency only, like LDAP server downtime
Although MDIS and MDSS could log-on on behalf of a repository Admin user ifthe fallback option was set, it's recommended to create technical users in theLDAP user directory for this purpose.
-
7/30/2019 Mdm Security 71
21/44
Users, Roles and Authentication MDM 7.1 Security Guide
LDAP Support
April 2012 15
2.16.9 MDM Architecture in LDAPMaking MDM LDAP-aware includes the following:
Inspect or configure the mds.ini file to determine whether MDM uses proprietary uservalidation or LDAP validation.
Run aVerify > Repair operation on all repositories mounted on a Master Data Serverafter configuring the mds.ini file for LDAP validation.
If using an LDAP viewer, perform security validation and retrieve role information fromLDAP as outlined in the previous sections. Use the role names retrieved from LDAPrather than the MDM repository to initialize the user and login. Any roles that are notfound in the current MDM repository are ignored, and if none of the roles in the LDAPlist are found, the user is prevented from logging in.
Role names within MDM cannot contain semi-colons (;) nor start with anexclamation point (!), as enforced by MDM Console.
The MDM administrator must design a role-naming scheme to suit the particulars of the MDMinstallation/implementation. If there is more than one MDM repository (such as test anddevelopment repositories, subset repositories, and so on), these will all share the role namesthat are stored in LDAP.
While roles are designed and named via the MDM software, they are assignedto users via LDAP, centralizing this information outside of specific MDMrepositories. For multi-repository environments, you may need to name roles inan MDM repository keeping in mind other repositories that could use the samerole names. By having unique roles across all repositories, you can effectively
control specific repository access to your users.
2.16.10 Restrictions and LimitationsMDM Console users do not run under LDAP in the initial release of this functionality. We willreview the value of putting MDM Console access under LDAP control at some future time.
2.16.11 LDAP Errors and MDMErrors that occur due to LDAP failures are returned to the client application. Therefore, youare 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 youuse.
Some of the more common error messages are listed below.
Error Explanation / Possible Reasons
Ambiguous User More than one user exists with this login name.
User AuthorizationFailed
User exists, wrong password given.
-
7/30/2019 Mdm Security 71
22/44
-
7/30/2019 Mdm Security 71
23/44
Network and Communication Security MDM 7.1 Security Guide
LDAP Support
April 2012 17
3 Network and Communication SecurityYour network infrastructure is extremely important for protecting your system. Your networkneeds to support the communication necessary for your business without allowingunauthorized access. A well-defined network topology can eliminate many security threatscaused by software errors (at both operating system and application level) or network attackssuch as eavesdropping. If users cannot log onto your application or database servers atoperating system or database layer, then there is no way for intruders to compromise themachines and gain access to the database or files of the backend system. Additionally, ifusers 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 theSAP NetWeaver platform. Therefore, the security guidelines and recommendations describedin the SAP NetWeaver Security Guide also apply to the business scenario. Details thatspecifically apply to the business scenario are described in the following topics:
Communication Channel SecurityAs communication channels transfer all kinds of business data, they should beprotected against unauthorized access.
Network SecurityA minimum security requirement for your network infrastructure is the use of a firewallfor 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 againstunauthorized access. External security attacks can also come from "inside", forexample through social engineering.
Communication DestinationsCommunication destinations within a SAP NetWeaver MDM installation have to bemonitored. The kind of monitoring depends greatly on the implemented systemlandscape.
Carelessly handled users and authorizations for connection destinations cancause 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.
-
7/30/2019 Mdm Security 71
24/44
Network and Communication Security MDM 7.1 Security Guide
Securing Communication Channels Using SSL
April 2012 18
3.1 Securing Communication Channels Using SSLTransport layer security for communication among MDM servers and clients is available usingthe Internet standard protocol Secure Sockets Layer (SSL). This optional encrypted channelruns alongside the existing MDM client-server TCP communication layer.
MDM servers can be configured to allow clients to establish either unencrypted or secure SSLconnections, 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 SP072. Configuring MDM servers for SSL.3. Copying SSL library and client key files to client locations.4. Creating secure connections from rich client UIs5. Creating secure connections via APIs
MDM supports SSL for communication between MDM components only.
Communications established between third party applications and MDMcomponents, including, but not limited to the DBMS, are not affected by MDMsecurity settings; however, the third party applications may provide their ownform of communication security.
For more information about which MDM components support SSL-basedcommunication, see SAP Service Marketplace at
service.sap.com/installmdm71 Master GuideSecuring
Communication Channels Using Secure Sockets Layer (SSL).
3.2 Secure Connection PrerequisitesAll MDM servers and clients must be version 7.1 SP07 or higher. In addition, the followingserver-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
Key files and ticket files are created automatically during the installation/upgradeprocess, but the SSL Library file must be downloaded separately. Forinformation about downloading the SSL Library file, see SAP Note397175.
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.
https://service.sap.com/sap/support/notes/397175https://service.sap.com/sap/support/notes/397175https://service.sap.com/sap/support/notes/397175https://service.sap.com/sap/support/notes/397175 -
7/30/2019 Mdm Security 71
25/44
-
7/30/2019 Mdm Security 71
26/44
Network and Communication Security MDM 7.1 Security Guide
Connecting Securely from MDM Clients
April 2012 20
The header and parameters described in this section must also be added to themds.ini file of any remote MDS on which a slave repository is mounted. Formore information, see SAP Service Marketplace at
service.sap.com/installmdm71 MDM Console Reference Guide
Part 7: MDS AdministrationSSL-Specific Parameters for a Client MDS.
3.4 Connecting Securely from MDM Clients
3.4.1 Connecting Securely from MDM ConsoleIcons 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 MDMConsole. For more information, see SAP Service Marketplace at
service.sap.com/installMDM71 MDM Console Reference Guide Part 7: MDS
AdministrationAccessing Master Data Servers.
3.4.2 Connecting Securely from other Rich ClientsWhen connecting MDM Data Manager, MDM Import Manager, MDM Syndicator, or MDMPublisher to a repository on an SSL-enabled Master Data Server, a lock icon appears on theclients Connect To MDM Repository dialog.
Secure connections to repositories on SSL-enabled MDM servers must be configured fromwithin each client. For information, see Setting Up Secure Repository Connections in theclients reference guide.
-
7/30/2019 Mdm Security 71
27/44
Network and Communication Security MDM 7.1 Security Guide
Connecting Securely from MDM Clients
April 2012 21
3.4.3 Connecting Securely from MDM CLIXBefore you can connect CLIX to an SSL-enabled Master Data Server, you must add the pathsto the client-side SSL library and key files to the clix.ini file. Adding the Y[+] option flag to aCLIX command then encrypts communication with the MDS.
For more information, see SAP Service Marketplace at service.sap.com/installmdm71
MDM Console Reference GuidePart 14: CLIX Command Line Interface.
3.4.4 Connecting Securely from MDM APIsFor 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 ManagingConnections 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 UIsFor information about establishing SSL secure connections from Web UIs, see SAP Service
Marketplace at service.sap.com/installmdm71 :
MDM Portal Content Development GuideConnecting with the MDM RepositoryConfiguring a System Object
MDM Web Dynpro Components GuideInstalling the MDM Web DynproEnvironmentCreating a Destination for the MDMRepository
3.4.6 Connecting Securely from MDM Web ServicesFor information about establishing SSL secure connections from Web UIs, see SAP ServiceMarketplace 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 RuntimeEnvironmentMDM Web Services Security
Generated Web Services (Runtime)Data Types Common Data TypesGeneric Data TypesRepositoryInformation Data Type
Generated Web Services (Runtime)Web Services and OperationsGenericFunctionality for Web Service OperationsConnecting the MDM Repository atRuntime
3.4.7 Connecting Securely from MDM PI AdaptorFor 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 MessagingMDM Adapter Specific Configuration.
http://aiokeh.wdf.sap.corp:50000/SAPIKS2/content_get.sap?TMP_IWB_TASK=PREVIEW2&_CLASS=IWB_EXTHLP&_LOIO=B5EA3F2CB738493D947FC0D7F9BA3048&LANGUAGE=EN&RELEASE=7385http://help.sap.com/saphelp_nwmdm71/helpdata/en/48/d1f90613ba2b63e10000000a42189d/frameset.htmhttp://help.sap.com/saphelp_nwmdm71/helpdata/en/48/d1f90613ba2b63e10000000a42189d/frameset.htmhttp://help.sap.com/saphelp_nwmdm71/helpdata/en/48/d1f90613ba2b63e10000000a42189d/frameset.htmhttp://aiokeh.wdf.sap.corp:50000/SAPIKS2/content_get.sap?TMP_IWB_TASK=PREVIEW2&_CLASS=IWB_EXTHLP&_LOIO=B5EA3F2CB738493D947FC0D7F9BA3048&LANGUAGE=EN&RELEASE=7385 -
7/30/2019 Mdm Security 71
28/44
Network and Communication Security MDM 7.1 Security Guide
Server Landscape
April 2012 22
3.4.8 Connecting Securely from MDM EnrichmentContoller
For information about establishing SSL secure connections from the MDM PI Adaptor, see
SAP Service Marketplace at service.sap.com/installmdm71
MDM EnrichmentArchitecture GuideEditing the Configuration File of the Enrichment Controller.
3.5 Server LandscapeIt is possible to install MDM servers and the DBMS on the same or on different physicalserver machines. The MDM server landscape should be placed within a secured area, evenin a closed corporate network.
You should ensure that the DBMS cannot be accessed by end users (except for thedatabase administrator) using any kind of management tools, as certain scenarios requirethat the database user and password for end users are available.
3.6 Communication Channels Used3.6.1 Client/MDS CommunicationIn general, the Master Data Server (MDS) communicates with the following applications orAPIs 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 theservers and clients.
The Master Data Server also contains an RFC server. It is used to communicate with theMDM ABAP (for more information, see Remote Function Call below ).
3.6.2 MDS/Database Server CommunicationMDS uses the ODBC API to connect to the databases.
http://dwdf212/IPNW_KM/KM_Teams/MDM/KW/IWB_EXTHLP~44BEDB54317456A3E10000000A1553F6/http://dwdf212/IPNW_KM/KM_Teams/MDM/KW/IWB_EXTHLP~44BEDB54317456A3E10000000A1553F6/http://dwdf212/IPNW_KM/KM_Teams/MDM/KW/IWB_EXTHLP~44BEDB54317456A3E10000000A1553F6/http://dwdf212/IPNW_KM/KM_Teams/MDM/KW/IWB_EXTHLP~44BEDB54317456A3E10000000A1553F6/ -
7/30/2019 Mdm Security 71
29/44
Network and Communication Security MDM 7.1 Security Guide
Network Ports Used
April 2012 23
3.7 Network Ports UsedAs of MDM 7.1 SP08, MDM uses the following default listening ports:
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 youinstall/upgrade MDM. For more information, see SAP Service Marketplace at
service.sap.com/installmdm71 Installation Guideor Upgrade Guide.
3.8 Remote Function CallThe Master Data Server (MDS) contains a Remote Function Call (RFC) server. This RFCserver is used to connect through MDM ABAP API, which is an add-on for the SAPNetWeaver 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 DirectoryConfiguration
The following Master Data Server (MDS) setting is stored under the [LDAP] section of themds.ini file.
Parameter Description
Secure Connection
to Active DirectorySpecifies if the Master Data Server connects securely to theMicrosoft Active Directory LDAP server. Options are True or
False.
3.10 Authentication of Trusted ConnectionsSAP NetWeaver MDM 7.1 offers a Trusted Connection mechanism for authentication of clientconnections to MDS. When enabled, there are two modes of client authentication: IP andSSL.
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 spoofingattacks. SSL-based authentication for trusted connections removes this vulnerability.
When SSL-based authentication is enabled, all requests for trusted connections coming fromtrusted distinguished names (DNs) will be accepted.
3.10.1 Trusted Connection Configuration ParametersThe following Master Data Server (MDS) settings are stored under the [MDM Server]
section of the mds.ini file.
Parameter Description
Trusted Connection
Authentication ModeSpecifies the type of authentication required for trustedconnections to the Master Data Server (MDS). Options are
None, IP, SSL, or Both.
-
7/30/2019 Mdm Security 71
30/44
Network and Communication Security MDM 7.1 Security Guide
IP-Based Trusted Connections
April 2012 24
If the Trusted Connection Authentication Mode parameter is set to
None, no trusted connections will be accepted. If set to IP or Both, a warningwill 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 ConnectionsIP-based trusted connections enable users from safe machines to access Master DataServers and repositories using their sign-on credentials only (without having to additionallyprovide Master Data Server and repository passwords).
IP-bases trusted connections are currently available to SAP system usernamesonly.
Users must still provide a DBMS password for operations which require aconnection to the DBMS.
3.11.1 How IP-Based Trusted Connections WorkThere 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 canenter 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 yourestrict specific IP addresses within an otherwise allowed subnet.
You must create the allow.ip and deny.ip files, they are not createdautomatically by MDM.
By default, the Master Data Server looks for allow.ip and deny.ip in the folder containing theMaster 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 existin 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 MDMrepository is denied.
Once connected, users are permitted access to MDM repository data and functions based onthe MDM role(s) assigned to their MDM or LDAP usernames.
Each Master Data Server must maintain its own trusted connections. The tables andparameters required for trusted connections are described below.
-
7/30/2019 Mdm Security 71
31/44
Network and Communication Security MDM 7.1 Security Guide
IP-Based Trusted Connections
April 2012 25
File Description
allow.ip A flat, text-only file containing the IP addresses of trustedsystems. Connections requests from systems not included in thislist 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 exceptedmachines in an allowed subnet. Connection requests from IPaddresses in this file are denied.
Same comments as allow.ip.
File is optional.
mds.ini The parameter TrustFilesDir identifies the location of theallow.ip and deny.ip files. This is set by default to the folderwhere the Master Data Server executable file (mds.exe) islocated.
The Master Data Server must be restarted after modifying the allow.ip or deny.ipfiles.
3.11.2 SSL-Based Trusted ConnectionsFor SSL-based authentication of trusted connections, the list of trusted distinguished namesmust 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::subjectName:
The batch scripts described in Configuring SSL-Based Trusted Connectionsbelow 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 ConnectionsBatch script files (*.bat) for creating and/or importing certificates for use with SSL-basedtrusted connections are included with MDM CLIX for Windows (version 7.1 SP8 Patch 1 andhigher 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 onthe Windows machine running the scripts.
-
7/30/2019 Mdm Security 71
32/44
Network and Communication Security MDM 7.1 Security Guide
IP-Based Trusted Connections
April 2012 26
3.11.3.1 To Create PK12 Certificates and Import Them to MDM KeyStorage Using the MDM Destination Administration Tool
1. Place the following items in a temporary directory on a Windows machine:
o genTrustedPK12.bat
o sapgenpse.exeo sapcrypto.dllo 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 APIclient host.
4. Copy SAPSSLS.pse to \usr\sap\\MDS\sec on theMDS host.
5. Copy allow.dn to \usr\sap\\MDS\sec on the MDShost..
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 Parameterstab choose Client Certificateas the Trusted
System Type.
2) In the Connection Parameterstab, import the client.crt and .p12 files
to MDM Key Storage.
-
7/30/2019 Mdm Security 71
33/44
-
7/30/2019 Mdm Security 71
34/44
Network and Communication Security MDM 7.1 Security Guide
IP-Based Trusted Connections
April 2012 28
3.11.4 ABAP API Trusted Connection:The ABAP API always passes the logged on AS ABAP user (sy-uname) to the Master DataServer. The AS ABAP user must also be available in the repository (this is not valid for anLDAP 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 username.
There is no control mechanism like in ABAP for the transmitted user name. Youcan pass an arbitrary user name to the Master Data Server.
The application on top of the API has to ensure that unauthorized access to theMaster Data Server through user name is prevented.
-
7/30/2019 Mdm Security 71
35/44
-
7/30/2019 Mdm Security 71
36/44
Authorization Concepts and Management MDM 7.1 Security Guide
Change Log for Authorization Management
April 2012 30
Function ID map:
Records
Function ID in log: Corresponding 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
Images
Function ID in log: Corresponding hex value: Function name:
33554433 2000001 ModifyImagePrintSize
33554434 2000002 CropAndRotateImages
Hierarchy
Function ID in log: Corresponding hex value: Function name:50331649 3000001 MoveHierarchy
50331650 3000002 HideChildren
50331651 3000003 CreateAliases
Taxonomy
Function ID in log: Corresponding hex value: Function name:
67108865 4000001 AddAttributes
67108866 4000002 DeleteAttributes
67108867 4000003 ModifyAttributes
-
7/30/2019 Mdm Security 71
37/44
Authorization Concepts and Management MDM 7.1 Security Guide
Change Log for Authorization Management
April 2012 31
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
Families
Function ID in log: Corresponding hex value: Function name:
100663297 6000001 SynchronizeFamilyTree
100663298 6000002 ModifyFamilyData
100663299 6000003 ModifyFamilyPartitioning
Layouts
Function ID in log: Corresponding hex value: Function name:
117440513 7000001 ModifyLayout
117440514 7000002 RenameLayoutColumns
Publications
Function ID in log: Corresponding hex value: Function name:
134217729 8000001 AddPublications
134217730 8000002 DeletePublications
134217731 8000003 RenamePublications
134217732 8000004 AddPublicationNodes
134217748 8000014 AddSectionNodes
134217749 8000015 AddInternalNodes134217750 8000016 AddPresentationNodes
134217733 8000005 DeletePublicationNodes
134217751 8000017 DeleteSectionNodes
134217752 8000018 DeleteInternalNodes
134217753 8000019 DeletePresentationNodes
134217734 8000006 MovePublicationNodes
134217735 8000007 RenamePublicationNodes
134217754 0800001a SplitSectionNodes
-
7/30/2019 Mdm Security 71
38/44
Authorization Concepts and Management MDM 7.1 Security Guide
Change Log for Authorization Management
April 2012 32
134217755 0800001b CombineSectionNodes
134217742 0800000e ModifyCachedLayoutItems
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
Publisher Checkout
Function ID in log: Corresponding hex value: Function name:251658241 0F000001 CheckoutPubObj
251658242 0F000002 AssignPubObjCheckout
251658243 0F000003 OverridePubObjCheckout
Publisher Indexes
Function ID in log: Corresponding hex value: Function name:
167772161 0A000001 AddPubIndices
167772162 0A000002 DeletePubIndices
167772163 0A000003 RenamePubIndices
-
7/30/2019 Mdm Security 71
39/44
Authorization Concepts and Management MDM 7.1 Security Guide
Change Log for Authorization Management
April 2012 33
167772164 0A000004 ModifyPubIndexDataSource
167772165 0A000005 ModifyPubIndexKeyDefs
167772166 0A000006 ModifyPubIndexEntryRedefines
167772167 0A000007 ModifyPubIndexProperties
167772168 0A000008 ModifyPubIndexStyles
167772169 0A000009 ModifyPubIndexDocumentProperties
167772170 0A00000A AddPubIndexSource
167772171 0A00000B DeletePubIndexSource
Branded Client
Function ID in log: Corresponding hex value: Function name:
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
150994976 9000020 SetNamedSearch
Distributions Role
Function ID in log: Corresponding hex value: Function name:184549377 0B000001 AddImportMaps
184549378 0B000002 ModifyImportMaps
184549379 0B000003 DeleteImportMaps
184549380 0B000004 AddExportMaps
184549381 0B000005 ModifyExportMaps
184549382 0B000006 DeleteExportMaps
184549383 0B000007 EnableKeyMapping
-
7/30/2019 Mdm Security 71
40/44
Authorization Concepts and Management MDM 7.1 Security Guide
Change Log Archiving
April 2012 34
Administration
Function ID in log: Corresponding hex value: Function name:
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
Schema
Function ID in log: Corresponding hex value: Function name:
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 ModifySchemaObject218103819 0D00000b DeleteSchemaObject
4.3 Change Log ArchivingChanges to authorizations are logged in the MDS_Audit log file. If a log file exceeds a size of2 MB, a new file is created. Since logs are not overwritten, you can create a long-termarchive.
There is no MDM tool for archiving old log files. Older log files should be
archived manually or using an archive tool.
-
7/30/2019 Mdm Security 71
41/44
Auditing MDM 7.1 Security Guide
Logging of Security-Relevant Information
April 2012 35
5 Auditing
5.1 Logging of Security-Relevant InformationThe Master Data Server contains a logging functionality for security-relevant information. Thelogs are stored as CSV files in the usr\sap\\\log directory. Youcan 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, youcan create a long-term archive. Due to the risk of running out of hard disk space, you shouldarchive old log files or (if there is no need for a long-term archive) delete them from time totime.
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)
-
7/30/2019 Mdm Security 71
42/44
Content Security MDM 7.1 Security Guide
Document and File Upload
April 2012 36
6 Content Security
6.1 Document and File UploadThe Master Data Server can store documents (PDF) and files (images, sounds, videos, andbinary objects) in the database. It does not contain an integrated virus scanner. Documentsand files should be checked with a separate virus scanner before they are released foruploading.
7 MDM File Locations and File SystemSecurity
Under Windows, the base directory is usr\sap\\.
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: Contains the configuration ini file Access recommendation: Do not share
Data: Contains cached information Access recommendation: Do not share
Exe: Contains the application Access recommendation: Do not share
Log: Contains MDM log files. Access recommendation: Can be made available to MDM administrators
MDM Accelerator
Contains accelerator files for repositories 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 scenariothat accesses the file system directly is implemented
-
7/30/2019 Mdm Security 71
43/44
MDM File Locations and File System Security MDM 7.1 Security Guide
Session IDs
April 2012 37
Reports Contains repository operation (archive, duplicate, load, unarchive,
update, verify check, verify repair) reports
Access recommendation: Can be made available to MDM administrators 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 andlong-term archiving files should never be stored in this directory. This directorycan be made available to MDM administrators, and can be accessed using theSAPControl WebService or the SAPmmc Console.
If the access recommendation of a folder is restricted, it has to be protected byoperating system settings.
7.1 Session IDsThe Master Data Server uses session IDs to authenticate client users. There are differentsessions 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 asession ID is detected before it is authenticated, it might be misused at a laterpoint of time after authentication of the user.
The randomly-defined part of the session ID is 64 bits long. It is not impossibleto 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 LockA 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 theunattended 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 systemshould be configured so that it locks automatically after a certain period ofinactivity. This prevents unauthorized users from accessing the application and
the corresponding user session.
-
7/30/2019 Mdm Security 71
44/44
Regulatory Compliance MDM 7.1 Security Guide
Person-Related Data
8 Regulatory Compliance
8.1 Person-Related DataPerson-related data is an important topic within a master data environment. One of the tasksof 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 DataManagement Server in the environment, the application must comply with thefollowing rules:
Master data applications must provide the capability to avoidunnecessary storage of person-related data.
Master data applications must provide the capability to notify a person ifdata 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 reasonfor storing the data.
Person-related data stored for different reasons must be storedseparately.
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 SAPMaster Data Server (for example, using one of the available APIs).