Skip to Content
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.

image
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.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

      1. Satheesh Ramakrishnan
        Hi Shilpa,

        It is a nice article.

        Do you know what will be your Base DN if you have to query multiple windows domains for MDM user authentication? Is it possible to query multiple windows domain?

        Appreciate your response.

        Regards
        Satheesh

        (0) 
        1. Shilpa Bhanot Post author
          Hi Satheesh,

          I do not know whether this is applicable for multiple window domains as I have implemented it for single domain.
          But i think , for different domains also , the Base DN should remain the same.

          Base DN=DC=ad,DC=company-name,DC=com

          However the Admin DN would change according to the domain in which the user is created .
          For example:

          Admin DN=CN=Shilpa Bhanot,OU=Users,OU=domain1,DC=ad,DC=company-name,DC=com

          or
          Base DN=CN=Shilpa Bhanot,OU=Users,OU=domain2,DC=ad,DC=company-name,DC=com

          In these examples domain 1/2  will represent the actual hiearchy under which the user in created in domain. It may be organisational or gegraphical hiearchy.

          Hope this information helps you.

          Regards
          Shilpa Bhanot

          (0) 
          1. Satheesh Ramakrishnan
            Hi Shilpa,

            Thank you! It is possible to have common Base DN for both domains, but do you know if MDM can handle two Admin DN, one for each domain?
            2) Can MDM query two domains for user authentication, if user is not found in domain1 and goto domain2 with right Admin DN for binding?

            Appreciate your help.

            Regards,
            Satheesh

            (0) 
            1. Shilpa Bhanot Post author
              Hi Satheesh,

              Yes , it is possible to have a common base DN for both th domains as both domains will come under the same (basic hiearchy) domain name .

              I am not very sure if MDM can handle 2 Admin DNs at the same time ….but I would suggest that you can go ahead with a single Admin DN- that means atleast one user should exist with read role to all the users in LDAP. This user will be able to read all users in all the domains.
              So the Admin Domain will actually be the DN (domain) under which the Admin user is created.

              Regards
              Shilpa Bhanot

              (0) 
            2. Shilpa Bhanot Post author
              Hi Satheesh,

              Yes , it is possible to have a common base DN for both the domains as both domains will come under the same (basic hiearchy) domain name .

              I am not very sure if MDM can handle 2 Admin DNs at the same time ….but I would suggest that you can go ahead with a single Admin DN- that means atleast one user should exist with read role to all the users in LDAP. This user will be able to read all users in all the domains.
              So the Admin Domain will actually be the DN (domain) under which the Admin user is created.

              Regards
              Shilpa Bhanot

              (0) 
            3. Shilpa Bhanot Post author
              Hi Satheesh,

              Yes , it is possible to have a common base DN for both the domains as both domains will come under the same (basic hiearchy) domain name .

              I am not very sure if MDM can handle 2 Admin DNs at the same time ….but I would suggest that you can go ahead with a single Admin DN- that means atleast one user should exist with read role to all the users in LDAP. This user will be able to read all users in all the domains.
              So the Admin Domain will actually be the DN (domain) under which the Admin user is created.

              Regards
              Shilpa Bhanot

              (0) 

Leave a Reply