From the first glance, the task of configuring LDAP authentication in Caché is not hard at all – the manual describes this process in just 6 paragraphs. On the other hand, if the LDAP server uses Microsoft Active Directory, there a few non-evident things that need to be configured on the LDAP server side. Those who don’t do anything like that on a regular basis may get lost in Caché settings. In this article, we will describe the step-by-step process of setting up LDAP authentication and cover the diagnostic methods that can be used if something doesn’t work as expected. ### Configuration of the LDAP server 1. Create a user in ActiveDirectory that we will use to connect to Caché and search for information in the LDAP database. This user must be located in the domain’s root. ![](https://hsto.org/getpro/habr/post_images/895/8ae/5ad/8958ae5ad1326aacdb0ef566f9b2085c.png) 2. Let’s create a special unit for users who will be connecting to Caché and call it IdapCacheUsers. 3. Register users there. ![image](https://habrastorage.org/getpro/habr/post_images/622/acf/4cf/622acf4cf6acdac4a0c7c98a8d3d11e5.png) 4. Let’s test the availability of the LDAP database using a tool called ldapAdmin. You can download it [here](http://www.ldapadmin.org/download/ldapadmin.html). 5. Configure the connection to the LDAP server: ![image](https://habrastorage.org/getpro/habr/post_images/4cf/bc1/a9d/4cfbc1a9dbef9520fe0c217b2999350d.png) 6. All right, we are connected now. Let’s take a look at how it all works: ![image](https://habrastorage.org/getpro/habr/post_images/2ee/42e/068/2ee42e068dd1fd7da5a5541b46f090f5.png) 7. Since users that will be connecting to Caché are in the ldapCacheUsers unit, let’s limit our search to this unit only. ![image](https://habrastorage.org/getpro/habr/post_images/16b/84c/837/16b84c8375087886164da5a0bb147fa3.png) ![image](https://habrastorage.org/getpro/habr/post_images/622/ef5/6d9/622ef56d9eef7514cb722ad5df690dc7.png) ### Settings on the Caché side 8. The LDAP server is ready, so let’s proceed to configuring the settings on the Caché side. Go to Management Portal -> System Administration -> Security -> System Security -> LDAP Options. Let’s clear the “User attribute to retrieve default namespace”, “User attribute to retrieve default routine” and “User attribute to retrieve roles” fields, since these attributes are not in the LDAP database yet. ![](/sites/default/files/inline/images/fig1_0.png) 9. Enable LDAP authentication in System Administration -> Security -> System security -> Authentication/CSP Session Settings 10. Enable LDAP authentication in services. The %Service\_CSP service is responsible for connecting web applications, %Service\_Console handles connections through the terminal. 11. Configure LDAP authentication in web applications. ![](/sites/default/files/inline/images/fig2.png) 12. For the time being and for testing the connection, let’s configure everything so that new users in Caché have full rights. To do this, assign the %All role to the user _PUBLIC. We will address this aspect in the future …… ![](/sites/default/files/inline/images/fig3.png) 13. Let’s try opening the configured web application, it should open without problems. 14. The terminal also opens 15. After connecting, LDAP users will appear on the Caché users list 16. The truth is, this configuration gives all new users complete access to the system. To close this security hole, we need to modify the LDAP database by adding an attribute that we will use to store the name of the role that will be assigned to users after connecting to Caché. Prior to that, we need to make a backup copy of the domain controller to ensure that we don’t break the entire network if something goes wrong with the configuration process. 17. To modify the ActiveDirectory schema, let’s install the Active Directory snap-in on the server where ActiveDirectory is installed (it is not installed by default). Read the instruction [here](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732110(v=ws.11)). 18. Let’s create an attribute called intersystems-Roles, OID 1.2.840.113556.1.8000.2448.2.3, a case-sensitive string, a multi-value attribute. ![image](https://habrastorage.org/getpro/habr/post_images/ea1/649/08b/ea164908bab895dc922d0dcda0e77b94.png) 19. Then add this attribute to the class “user”. ![image](https://habrastorage.org/getpro/habr/post_images/b79/4d5/7ce/b794d57ce3e2e5856d31ef4ad0f4aa92.png) 20. Let’s now make it so that when we view the list of unit users, we can see a “Role in InterSystems Cache” column. To do that, click Start -> Run and type “adsiedit.msc”. We are connecting to “Configuration” naming context. ![image](https://habrastorage.org/getpro/habr/post_images/79c/5ee/d59/79c5eed5972bbd1c6a05faddc7c185e2.png) 21. Let’s go to the CN=409, CN=DisplaySpecifiers, CN=Configuration container and choose a container type that will show additional user attributes when we view it. Let’s choose unit-level display (OU) provided by the organisationalUnit-Display container. We need to find the extraColumns attribute in its properties and change its value to ”intersystems-Roles, Role in IntersystemsCache,1,200,0”. The rule of composing the attribute is as follows: attribute name, name of the destination column, display by default or not, column width in pixels, reserved value. One more comment: CN=409 denotes a language code (CN=409 for the English version, CN=419 for the Russian version of the console). ![image](https://habrastorage.org/getpro/habr/post_images/ec9/4f7/4bd/ec94f74bd1a3befa3f2bcda394fe6e7b.png) 22. We can now fill out the name of the role that will be assigned to all users connecting to Caché. If your Active Directory is running on Windows Server 2003, you won’t have any built-in tools for editing this field. You can use a tool called ldapAdmin (see item 4) for editing the value of this attribute. If you have a newer version of Windows, this attribute can be edited in the “Additional functions” mode – the user will see an additional tab for editing attributes. ![image](https://habrastorage.org/getpro/habr/post_images/a6d/bc8/98e/a6dbc898e5046b5f60e62f38a378801b.png) 23. After that, let’s specify the name of this attribute in the LDAP options on the Caché management portal. ![](/sites/default/files/inline/images/fig4_0.png)   24. Let’s create an ldapRole with the necessary privileges ![](/sites/default/files/inline/images/fig5.png) 25. Remove the %ALL role from the user _PUBLIC 26. Everything is set up, let’s try connecting to the system 27. If it doesn’t work right away, enable and set up an audit ![](/sites/default/files/inline/images/fig6.png) 28. Audit settings ![](/sites/default/files/inline/images/fig7.png) 29. Look at the error log in Audit Database. ### Conclusion In reality, it often happens that the configuration of different roles for different users is not required for working in an application. If you only need to assign a particular set of permissions to users logging in to a web application, you can skip steps 16 through 23. All you will need to do is to add these roles and remove all types of authentication except for LDAP on the “Application roles” tab in the web application settings. In this case, only users registered on the LDAP sever can log in. When such a user logs in, Caché automatically assigns the roles required for working in this application.