Introduction
In the process of configuring LDAP support for MDM, for the purpose of user centralization and authentication, I noticed that there was no step by step article for the same. So it took time but finally we managed to complete it. So here I am presenting my understanding of the process, the limitations, problems faced and some suggestions by SAP for the integration. For all newbie developers, please refer to MDM Console Guide for LDAP integration.Process
All the users should be placed in LDAP. All roles will be placed in MDM. Modify the mds.ini file of the MDM server. If the [LDAP in Use] block doesn’t exist or is set is false, set it to true to enable LDAP support. Restart the MDM service. Modify the rest of the LDAP parameters.
Login to the MDM console. Repair all the repositories. Load the specific repository you want to login.
Now Login to MDM Data Manager with the LDAP user id and password. It will be authenticated and will have the roles according to the groups he is memberOf (Role Attribute).
A screenshot of the MDM LDAP block is given.
Some Guidelines for MDM LDAP Block
1. We were using MDM 5.5 SP5 [5.5.40.83] for the integration. As SP5 has some bugs related to LDAP support, so it is advisable to upgrade it to atleastSP6 or use higher version of MDM. We upgraded to use MDM 5.5 SP06 [5.5.63.80].
2. We were using Microsoft ADS (Active Directory Server) LDAP. We decided to use Department field of LDAP as MDM Role Attribute as it was more convenient rather than going for creating new field MDMRoles or memberOf for which we had to create separate groups corresponding to roles defined in MDM. But as Microsoft LDAP ADS works only with memberOf due to simple binding from MDM, so we had to create new groups and assign them to users using memberOf field of LDAP. So if you are using Microsoft ADS, go for memberOf role attribute to avoid problems later.
3. Place the MDM LDAP block after the server block.
4. Use LDAP IP address instead of the host name in the server parameter.
5. Use role algorithm GroupMapping instead of TraverseSearch as it is faster and efficient.
6. At least one LDAP user must have read access to LDAP as it reads the user and their groups (memberOf) for authentication. It need not be the Administrator of LDAP .It is a user which is needed to bind to LDAP as the user known to the directory. This will act as the Admin User.
7. The Admin password needs to be written as Admin Password = abc123 After saving and closing the mds.ini file, and login into the MDM console, the password will disappear. Instead an encrypted password will take its place in the form: Admin Password+=ABDKE2232323DF
8. Fallback should be set to false while AD is running; otherwise it would always login with the default id and password. For example, take the following scenario : We have a user in MDM but not in LDAP. We are using the all correct parameters for LDAP authentication, but if we have set Fallback = True. We are using the MDM user as fallback user. Now even if we login through LDAP user, the authentication will happen through MDM user and password. So we may not be able to detect the error. So fallback should only be used in special circumstances.
9. The trace level can be changed from 0 to one to keep track of the logs.
10. MDM uses only simple authentication for binding to LDAP. In this case if LDAP uses some other kind of binding (e.g.: GSSAPI), then it would be advisable to use memberOf and GroupMappping.
11. MDM Console users do not run under LDAP in the initial release of this functionality.
12. Role names within MDM cannot contain semi-colons (;) nor start with an exclamation point (!), as enforced by the 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.
13. 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.
9 Comments
