LDAP

In the blog article series “How to integrate with LDAP”, we introduce a whole range of different options and possibilities for how the LDAP provided by UCS can be expanded or used in cooperation with other services.

In the first section of this article, “Typical Configuration Options”, I will be using an example to demonstrate the sort of information typically required to perform user authentication against the UCS LDAP. I will be taking you through the necessary configuration steps using the project management system Redmine as an example, as this requests all the typical information.

In the second section, “Types of Search Users”, I will go into more detail on the possibilities available to you if it is not possible to search through the UCS LDAP anonymously.

If you are not all that familiar with the topic of LDAP yet, I would recommend you read our blog article: Brief Introduction: What’s Behind the Terms LDAP and OpenLDAP? first of all.

1. Typical Configuration Options

Typical configuration options for an LDAP connection include the following elements:

  • an LDAP server
  • an LDAP port and
  • an LDAP search filter

If the LDAP server does not permit any anonymous or unauthorized read accesses, you also need to define the following points:

  • User account (using DN format) for the search
  • Password for the user account for the search

LDAP server

The LDAP server is used to specify either the IP address or the host name – or even better the FQDN (fully qualified domain name) – of the server to be queried. The LDAP server itself also needs to be specified. For example: ucs-master.example.com.

Common designations for this field include Name, Server, and LDAP Server.

LDAP port

The UCS LDAP service can be reached via ports 7389 (unsecure) and 7636 (SSL encrypted). If Samba is installed on the server and configured as an AD-compatible domain controller, the ports 389 (unsecure) and 636 (SSL encrypted) are reserved for Samba and can no longer be used for the OpenLDAP communication. Tools which procure data from an MS AD should also be configured against the directory service provided by Samba.

Tools which procure data from an OpenLDAP, in contrast, should prefix the ports with a “7”. Example: 7389

Common designations for this field include Port and LDAP Port.

LDAP search filter

The LDAP search filter can be used to reduce the number of search results prior to the output, for example: only user accounts or Windows clients are queried. Example: (&(objectClass=person)(mailPrimaryAddress=*)). This search returns objects which are a person and have a primary e-mail address.

Common designations for this field include Filter and LDAP Filter.

User for the LDAP search

If the LDAP server does not permit any anonymous search queries, a user name in the form of its distinguished name (DN) must additionally be specified in the configuration for the LDAP search. Example: uid=searchuser,cn=users,dc=example,dc=com.

Common designations for this field include Account, BindDN and Bind-DN.

Password for the search user

The password needs to be specified for it to be possible to perform the LDAP query. The password here is unencrypted and unhashed. Such fields are normally correctly configured as password fields in a web interface, so that the password cannot be viewed.

Common designations for this field include Password and Bind-DN Password.

User creation

If a service such as Redmine, for example, maintains its own user database and only uses LDAP for user authentication, there may be an option for creating the user directly in the service’s database. As the service has its own compulsory fields for user accounts such as the user name, it is generally possible to specify LDAP attributes, which are then completed in the database. An overview of common fields can be found in the “Attributes” section.

Common designations for this option include On-the-fly user creation and Create a user, if not already available.

Screenshot LDAP Authentication

Attributes

Some services such as Redmine, for example, maintain their own user database and only use the LDAP for user authentication. These services offer the option of connecting LDAP attributes to a field in the service. If the attribute is found in the LDAP, the value is transferred automatically and entered in the internal database.

Common attributes which are adopted include:
User name (LDAP attribute: uid)
Given name (LDAP attribute: givenName)
Surname (LDAP attribute: sn)
E-mail (LDAP attribute: mailPrimaryAddress or mail)

2. Types of Search Users

If the LDAP is configured in such a way that no anonymous LDAP searches can be performed, a user account must be specified, which can subsequently used to search the LDAP.

LDAP attributesThis can either be done using a user created in the LDAP or with the host account of a system on which a service is installed (insofar as the system has joined the UCS domain, this generally means all UCS systems).

User for the search

The configuration of the LDAP query with a user can be practical if a service is being used which is only provided on one system, as is this case in our example with Redmine.
The user’s configuration is transparent and facilitates the configuration of services, as it is immediately clear which user is being used to run the queries.
We recommend creating a specific LDAP search user so that it is not necessary to input the login data of domain users or the domain administrator in the configurations. You can find an illustrated guide in our wiki under Cool Solution – LDAP search user.

Searching with the host account

The configuration of the LDAP query with the host account can be practical if a service offers configuration of the LDAP search via a configuration file or a service is offered on multiple servers.

At the same time it is important to note that the search with the host account of the server on which the service is installed is subject to the regular and automatic changing of the server password. That means that if the server’s host account password changes it is no longer possible to perform LDAP searches with a configured service. As such, when creating the configuration file, the mechanism for changing the password for the host account must also be taken into consideration. Detailed instruction can be found in our developer documentation Documentation on Password Rotation.

One considerable advantage of the method described above is that the configuration can be rolled out simultaneously on all the servers capable of providing a similar service.

We hope that this article has been able to give you a good overview of the configuration possibilities in LDAP for connecting users.

Use UCS Core Edition for Free!
Download now

Comments

  1. Sharif

    April 14, 2017 at 18:50

    Still I need exact details on how to integrate Ubuntu with UCS. Your documentation doesn’t provide what I need. Just briefing!!

    Reply
    1. Timo Denissen

      Timo Denissen

      April 18, 2017 at 09:18

      Hello Sharif,

      have you had a look at our documentation [1] on how to integrate Ubuntu with UCS? If you need further assistance in integrating Ubuntu to your UCS domain, don’t hesitate to ask in our forum at help.univention.com/

      Regards,
      Timo Denissen

      [1] http://docs.software-univention.de/domain-4.2.html#ext-dom-ubuntu

      Reply
      1. Sharif

        April 18, 2017 at 11:12

        Dear Timo,
        I really appreciate the effort you’ve made to help us in the forum.
        But I wish your article would be more specific in some steps like for ex.
        1. In step one, which configuration files for Ubuntu to be modified.
        2. where shall I copy & paste the configuration of the UCS master domain controller to the Ubuntu system.
        All I need is the full details
        Thanks again Timo

        Reply
        1. Timo Denissen

          Timo Denissen

          April 18, 2017 at 11:16

          Hello Sharif,

          please have a look at our documentation on how to join/integrate Ubuntu to UCS, your questions are answered there: http://docs.software-univention.de/domain-4.2.html#ext-dom-ubuntu

          I have joined several Ubuntu systems using the documentation.

          Could you please specify the topic in our forum where you asked for help? We can give better assistance using the forum than our blog comment section 😉

          Regards,
          Timo Denissen

          Reply
          1. Sharif

            April 27, 2017 at 11:35

            The steps described in the post is so complicated and is taking too long. It’s a shame how to go through so much burden just to join a single Ubuntu machine (Linux) to UCS (which is also Linux and comes from same family) whilst Windows joins the UCS server much easily. I’ve tried and succeeded in joining Ubuntu to UCS (AD domain Windows Compatible) hoping to find much easier way to integrate Ubuntu machine with the server. I hope enhancements and upgrades would be made for Linux machines to save us the burden as System Administrators.

  2. Jerome

    October 6, 2017 at 07:54

    Hi Sharif,

    Yes, as you said the documentation should be easy, because now I am facing the same situation. Since you succeeded on this could you please send any document if you have prepared or could you please help me in some way. My email id :XXX@XXX.XXX

    Regards,
    Jude Jerome

    Reply
    1. Irina Feller

      October 17, 2017 at 09:43

      Hello Jerome,

      Thank you for the communication of your use cases! We will try to ease the process in future releases, but for now I’d like to explain the background:

      The documentation provided by us and linked above tries to summarize the easiest way to configure an Ubuntu client to use an LDAP / Kerberos environment as provided by UCS with full functionality. The steps documented are designed to work based on “copy & paste”, so you should be able to configure your Ubuntu client in six steps – or use our code as base for your own script.

      Easier implementable integration like those typically described to join an Active Directory Domain will work in the same way with UCS as long as the Samba 4 Domain Controller component is installed. But those integrations are often limited, i.e. they do not sync POSIX attributes (which can result in problems with Linux to Linux file exchange). Best place to discuss this is help.univention.com/.

      For data protection reasons, we have blackened your email address and forwarded your message to Sharif directly (including your email address).

      Best regards
      Irina

      Reply
  3. Gian

    August 2, 2019 at 05:54

    Hi! how can I integrate Univention LDAP to my Atlassian Jira? do you have a documentation for this? because I can’t find the Server Settings and LDAP Schema settings in my Univention console with admin rights.

    Reply
    1. Michael Grandjean

      August 2, 2019 at 09:27

      Hello Gian,

      afaik we don’t have a detailed how-to for Jira, but it should be pretty straight forward, according tho this documentation by Atlassian:
      https://confluence.atlassian.com/adminjiraserver071/connecting-to-an-ldap-directory-802592350.html

      The server settings and the LDAP attributes need to be configured in Jira and not in the Univention console. You just need to connect both this blog article and the Atlassian how-to.

      For any further help, please head to https://help.univention.com/ for our Community Support.

      Best regards,
      Michael

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *