Что такое код ldap_start_tls


Содержание

Linux.yaroslavl.ru

Учебник РНР
Назад Вперёд

ldap_start_tls — стартует TLS.

Описание

bool ldap_start_tls (resource link)

Эта функция в настоящее время ещё не задокументирована; имеется только список аргументов.

16. Использование TLS

Клиенты и серверы OpenLDAP способны использовать технологию Transport Layer Security ( TLS ) для обеспечения защиты целостности и конфиденциальности данных, а также для поддержки аутентификации LDAP с использованием механизма EXTERNAL SASL . TLS определён в RFC4346.

Примечание: О том, как генерировать сертификаты, смотрите http://www.openldap.org/faq/data/cache/185.html

Для представления идентификационных сущностей клиента и сервера TLS использует сертификаты X.509 . Всем серверам необходимо иметь корректные действующие сертификаты, тогда как клиентские сертификаты не являются обязательными. Клиентам необходимо иметь действующий сертификат в случае прохождения аутентификации с помощью SASL EXTERNAL. Дополнительную информацию о том, как создавать сертификаты и управлять ими, смотрите в документации по OpenSSL, GnuTLS или MozNSS, в зависимости от того, какую реализацию библиотек TLS Вы используете.

DN сертификата сервера должен использовать атрибут CN для именования сервера, и в этом CN должно содержаться полное доменное имя сервера. Дополнительные псевдонимы и шаблоны имени могут присутствовать в расширении сертификата subjectAltName . Подробности об именах в сертификате сервера можно найти в RFC4513.

DN сертификата клиента можно напрямую использовать в качестве аутентификационного DN. Поскольку X.509 — часть стандарта X.500 , а LDAP также основан на X.500, оба они используют одинаковый формат DN; и в общем случае DN в сертификатах X.509 пользователей должны быть идентичны DN из записей LDAP. Однако, иногда данные DN могут не быть совершенно одинаковыми, в этом случае к ним может применяться функция отображения, описанная в подразделе Отображение аутентификационных идентификационных сущностей.

После получения необходимых сертификатов, и на клиенте и на сервере нужно произвести некоторое количество настроек, чтобы включить TLS и задействовать эти сертификаты. Как минимум, на клиентах должно быть настроено имя файла, содержащего все сертификаты Центров сертификации (или Удостоверяющих центров, Certificate Authority, CA), которым они будут доверять. На сервере должен быть настроен список сертификатов CA , а также его собственный сертификат сервера и закрытый ключ.

Обычно сертификат сервера и все доверенные сертификаты клиентов будут изданы одним CA, таким образом, серверу требуется доверять только этому единственному CA. Однако, клиент может соединятся с несколькими защищёнными серверами, управляемыми разными организациями и имеющими сертификаты серверов, сгенерированные многими разными CA. В таком случае, при конфигурации клиента понадобится список многих разных доверенных CA.

Директивы конфигурации slapd для настройки TLS располагаются в секции глобальных директив slapd.conf (5).

16.2.1.1. TLSCACertificateFile

Данная директива указывает файл в формате PEM , содержащий сертификаты для CA, которым slapd будет доверять. Среди них должен быть сертификат для CA, который подписал сертификат сервера. Если подписавший CA не является CA верхнего (корневого) уровня, тогда должны присутствовать сертификаты для всей цепочки CA, начиная от подписавшего CA до CA верхнего уровня. Несколько сертификатов просто добавляются в этот файл; порядок значения не имеет.

16.2.1.2. TLSCACertificatePath

Данная директива указывает путь к директории, содержащей индивидуальные сертификаты CA в отдельных файлах. Кроме того, данная директория должна специальным образом управляться с помощью утилиты OpenSSL c_rehash . При использовании этой функции библиотека OpenSSL будет пытаться искать файлы сертификатов, основываясь на хэше их имени и серийного номера. Утилита c_rehash используется для создания символических ссылок с хэшированными именами, указывающих на актуальные файлы сертификатов. Таким образом, эта опция может быть использована только с файловыми системами, поддерживающими символические ссылки. В общем случае, вместо этого проще использовать директиву TLSCACertificateFile .

При использовании Mozilla NSS, данная директива указывает путь к директории, содержащей сертификат NSS и файлы базы данных ключей. Для добавления сертификата CA может быть использована команда certutil :


    Эта команда добавит сертификат CA, хранящийся в файле /path/to/cacertfile.pem в формате PEM (ASCII).
    -t CT,, означает, что этот сертификат является доверенным CA для выдачи сертификатов,
    которые будут использоваться клиентами и серверами при работе с TLS.

16.2.1.3. TLSCertificateFile

Данная директива указывает файл, содержащий сертификат сервера slapd. Обычно сертификаты являются открытой информацией и не требуют специальной защиты.

При использовании Mozilla NSS, в случае применения базы данных сертификатов/ключей (задаваемой с помощью TLSCACertificatePath ), данная директива указывает имя сертификата, который нужно использовать:


    При использовании маркера (token), отличного от встроенного, сначала укажите имя маркера и двоеточие:


    Для того, чтобы узнать имена сертификатов, используйте certutil -L :

16.2.1.4. TLSCertificateKeyFile

Данная директива указывает файл, содержащий закрытый ключ, соответствующий сертификату, хранящемуся в файле TLSCertificateFile . Закрытые ключи сами по себе являются информацией ограниченного распространения и обычно шифруются с помощью пароля в целях защиты. Однако, текущая реализация не поддерживает зашифрованных ключей, поэтому ключи должны быть незашифрованы, а сами файлы тщательно защищены.

При использовании Mozilla NSS данная директива указывает имя файла, содержащего пароль для ключа сертификата, заданного в TLSCertificateFile . Команда modutil может быть использована для отключения парольной защиты базы данных сертификатов/ключей. Например, если в TLSCACertificatePath в качестве расположения базы данных сертификатов/ключей задана /etc/openldap/certdb, используйте такую команду modutil, чтобы поменять пароль на пустую строку:


    Вы должны знать предыдущий пароль, если он задавался. Проигнорируйте ПРЕДУПРЕЖДЕНИЕ о запуске браузера.
    Нажмите ‘Enter’ на приглашение ввести новый пароль.

16.2.1.5. TLSCipherSuite

Данная директива настраивает то, какие шифры будут приниматься и порядок их предпочтения. — спецификации шифров для OpenSSL. С помощью команды

можно посмотреть подробный список доступных спецификаций шифров.

Кроме отдельных названий шифров, можно применять спецификаторы HIGH , MEDIUM , LOW , EXPORT и EXPORT40 , наряду с TLSv1 , SSLv3 и SSLv2 .

Чтобы посмотреть список шифров в GnuTLS, выполните:

При использовании Mozilla NSS применяется набор спецификаций шифров OpenSSL, который переводится во внутренний формат Mozilla NSS. Простого пути посмотреть список шифров из командной строки не существует. Официальный список находится в исходном коде Mozilla NSS в файле sslinfo.c в структуре

16.2.1.6. TLSRandFile

Данная директива указывает файл, из которого можно получить случайную последовательность бит, когда /dev/urandom недоступен. Если система предоставляет /dev/urandom , то данная директива не нужна, в противном случае необходимо сконфигурировать источник случайных данных. Некоторые системы (например, Linux) предоставляют /dev/urandom по умолчанию, на других (например, Solaris) для этого требуется инсталляция патча, а третьи могут вообще его не поддерживать. В последнем случае нужно установить EGD или PRNGD и задать данную директиву для указания имени сокета EGD/PRNGD. Переменная окружения RANDFILE также может использоваться для указания имени этого файла. Кроме того, при отсутствии этих вариантов, может быть использован файл .rnd в домашней директории пользователя slapd, если таковой существует. Чтобы использовать файл .rnd , просто создайте его и скопируйте туда несколько сотен байт произвольных данных. Этот файл используется только для предоставления начальной последовательности для генератора псевдо-случайных чисел и ему не нужно очень много данных, чтобы работать.


При использовании GnuTLS и Mozilla NSS эта директива игнорируется.

16.2.1.7. TLSDHParamFile

Данная директива указывает файл, содержащий параметры для обмена ключами по алгоритму Диффи-Хеллмана (Diffie-Hellman ephemeral key exchange). Это требуется при использовании основанных на DHE шифров, с том числе всех шифров, основанных на DSA (то есть TLSCertificateKeyFile указывает на ключ DSA), а также шифров RSA, когда в сертификате не указан вариант использования ключа «шифрование ключа» («key encipherment»). Параметры могут быть сгенерированы с помощью следующей команды:

При использовании Mozilla NSS эта директива игнорируется.

16.2.1.8. TLSVerifyClient

Эта директива определяет, какие проверки будут выполняться над клиентскими сертификатами во входящих сессиях TLS, если вообще будут выполняться какие-либо. По умолчанию эта директива установлена в never , в этом случае сервер никогда не запрашивает сертификат у клиента. При установке в allow сервер будет запрашивать сертификат у клиента; если запрашиваемый сертификат не будет предоставлен, сессия будет нормально обработана. Если сертификат предоставлен, но сервер не может его проверить, сертификат будет проигнорирован, и сессия будет обработана нормально, как и в случае, если сертификат не был предоставлен. При установке в try сертификат будет запрошен, и если он не будет предоставлен, сессия будет нормально обработана. Если сертификат предоставлен и не может быть проверен, сессия немедленно завершается. При установке в demand сертификат будет запрошен и действительный сертификат должен быть предоставлен, в противном случае сессия немедленно завершается.

Примечание: Сервер должен запрашивать сертификат клиента при использовании механизма аутентификации EXTERNAL SASL с сессией TLS. Таким образом, перед тем, как пытаться использовать аутентификацию SASL EXTERNAL, должны быть настроены отличные от значения по умолчанию установки TLSVerifyClient . Кроме того, аутентификация с помощью механизма EXTERNAL SASL будет предоставляться лишь тем клиентам, от которых получены действительные клиентские сертификаты.

Директивы конфигурации клиента в основном соответвуют директивам конфигурации сервера. Названия этих директив различаются и они указываются в ldap.conf (5) вместо slapd.conf (5), но их функциональность практически не отличается. Кроме того, хотя большинство этих параметров могут быть настроены на уровне системы в целом, все они могут быть переопределены отдельными пользователями в своих файлах .ldaprc .

Операция LDAP Start TLS используется в LDAP для инициации переговоров TLS. Все инструменты командной строки OpenLDAP поддерживают флаги -Z и -ZZ , указывающие, что требуется выполнить операцию Start TLS. Последний флаг указывает, что инструмент должен завершить работу, если сессия TLS не может быть установлена, в то время как первый флаг позволяет продолжить выполнение команды.

В среде LDAPv2 TLS, как правило, стартовал при использовании схемы LDAP Secure URI ( ldaps:// ) вместо нормальной схемы LDAP URI ( ldap:// ). Инструменты командной строки OpenLDAP позволяют использовать обе схемы с флагом -H и в опции URI файла ldap.conf (5).

16.2.2.1. TLS_CACERT

Это эквивалент серверной директивы TLSCACertificateFile . Как отмечалось в подразделе Настройка TLS, клиенту обычно требуется знать о большем количестве CA, нежели серверу, но в остальном применимы аналогичные соображения.

16.2.2.2. TLS_CACERTDIR

Это эквивалент серверной директивы TLSCACertificatePath . Указанная директория также должна управляться с помощью утилиты OpenSSL c_rehash . При использовании Mozilla NSS директория, указанная в параметре , может содержать базу данных сертификатов/ключей.

16.2.2.3. TLS_CERT

Данная директива указывает файл, содержащий сертификат клиента. Поскольку этот сертификат у каждого пользователя свой, данная директива может быть указана только в пользовательском файле .ldaprc .

При использовании Mozilla NSS, в случае применения базы данных сертификатов/ключей (указанной в TLS_CACERTDIR ), данная директива определяет имя сертификата, который нужно использовать:


    При использовании маркера (token), отличного от встроенного, сначала укажите имя маркера и двоеточие:


    Для того, чтобы узнать имена сертификатов, используйте certutil -L :

16.2.2.4. TLS_KEY

Эта директива указывает файл, содержащий закрытый ключ, соответствующий сертификату, который хранится в файле TLS_CERT . Здесь применимы те же соображения, что и для серверной директивы TLSCertificateKeyFile . Данная директива также определяется отдельно для каждого пользователя.

16.2.2.5. TLS_RANDFILE

Данная директива аналогична серверной директиве TLSRandFile .

16.2.2.6. TLS_REQCERT

Данная директива эквивалентна серверной директиве TLSVerifyClient . Однако, значение по умолчанию для клиентов — demand , и обычно нет оснований, чтобы изменять эту настройку.

OpenLDAP/TLS

Предупреждение!

Для большинства клиентов режим проверки сертификатов можно указать через файл /etc/openldap/ldap.conf (часто это единственное место, если файл отсутствует — его нужно создать). Для своей задачи, я использую такой:

NSS/PAM [ править ]

Редкий случай, когда cat /etc/openldap/ldap.conf не нужен: режим проверки серверного сертификата настраивается непосредственно в ##/etc/_ldap.conf:

Dovecot [ править ]

В /etc/dovecot/dovecot-ldap.conf (см. Open LDAP и Dovecot) можно только включить TLS:

Остальное — через /etc/openldap/ldap.conf.

OpenLDAP (репликация через syncprov/syncrepl) [ править ]

В файле конфигурации БД (у меня /etc/openldap/slapd-hdb-db01.conf):

Contents

Share

Sign up for our newsletter.

Get the latest tutorials on SysAdmin and open source topics.

How To Encrypt OpenLDAP Connections Using STARTTLS

Introduction

OpenLDAP provides an LDAP directory service that is flexible and well-supported. However, out-of-the-box, the server itself communicates over an unencrypted web connection. In this guide, we will demonstrate how to encrypt connections to OpenLDAP using STARTTLS to upgrade conventional connections to TLS. We will be using an Ubuntu 14.04 as our LDAP server.

Prerequisites

Before you get started with this guide, you should have a non-root user with sudo set up on your server. To set up a user of this type, follow our Ubuntu 14.04 initial setup guide.

We will cover how to install OpenLDAP on an Ubuntu 14.04 server in this guide. If you already have OpenLDAP installed on your server, you can skip the relevant installation and configuration steps.

LDAP Over SSL vs LDAP with STARTTLS

There are two ways to encrypt LDAP connections with SSL/TLS.

Traditionally, LDAP connections that needed to be encrypted were handled on a separate port, typically 636 . The entire connection would be wrapped with SSL/TLS. This process, called LDAP over SSL, uses the ldaps:// protocol. This method of encryption is now deprecated.

STARTTLS is an alternative approach that is now the preferred method of encrypting an LDAP connection. STARTTLS “upgrades” a non-encrypted connection by wrapping it with SSL/TLS after/during the connection process. This allows unencrypted and encrypted connections to be handled by the same port. This guide will utilize STARTTLS to encrypt connections.

Setting the Hostname and FQDN

Before you get started, we should set up our server so that it correctly resolves its hostname and fully qualified domain name (FQDN). This will be necessary in order for our certificates to be validated by clients. We will assume that our LDAP server will be hosted on a machine with the FQDN of ldap.example.com .

To set the hostname in all of the relevant places on your server, use the hostnamectl command with the set-hostname option. Set the hostname to the short hostname (do not include the domain name component):

Next, we need to set the FQDN of our server by making sure that our /etc/hosts file has the correct information:

Find the line that maps the 127.0.1.1 IP address. Change the first field after the IP address to the FQDN of the server, and the second field to the short hostname. For our example, it would look something like this:

Save and close the file when you are finished.

You can check that you’ve configured these values correctly by typing:

This should return your short hostname:

Check the FQDN by typing:

This should return the FQDN:

Installing the LDAP Server and GnuTLS Software

After ensuring that your hostname is set properly, we can install the software we need. If you already have OpenLDAP installed and configured, you can skip the first sub-section.

Install the OpenLDAP Server

If you do not already have OpenLDAP installed, now is the time to fix that. Update your server’s local package index and install the software by typing:

You will be asked to provide an LDAP administrative password. Feel free to skip the prompt, as we will be reconfiguring immediately after.

In order to access some additional prompts that we need, we’ll reconfigure the package after installation. To do so, type:

Answer the prompts appropriately, using the information below as a starting point:

  • Omit OpenLDAP server configuration? No (we want an initial database and configuration)
  • DNS domain name: example.com (use the server’s domain name, minus the hostname. This will be used to create the base entry for the information tree)
  • Organization name: Example Inc (This will simply be added to the base entry as the name of your organization)
  • Administrator password: [whatever you’d like]
  • Confirm password: [must match the above]
  • Database backend to use: HDB (out of the two choices, this has the most functionality)
  • Do you want the database to be removed when slapd is purged? (your choice. Choose “Yes” to allow a completely clean removal, choose “No” to save your data even when the software is removed)
  • Move old database? Yes
  • Allow LDAPv2 protocol? No

Install the SSL Components


Once your OpenLDAP server is configured, we can go ahead and install the packages we’ll use to encrypt our connection. The Ubuntu OpenLDAP package is compiled against the GnuTLS SSL libraries, so we will use GnuTLS to generate our SSL credentials:

With all of our tools installed, we can begin creating the certificates and keys needed to encrypt our connections.

Create the Certificate Templates

To encrypt our connections, we’ll need to configure a certificate authority and use it to sign the keys for the LDAP server(s) in our infrastructure. So for our single server setup, we will need two sets of key/certificate pairs: one for the certificate authority itself and one that is associated with the LDAP service.

To create the certificates needed to represent these entities, we’ll create some template files. These will contain the information that the certtool utility needs in order to create certificates with the appropriate properties.

Start by making a directory to store the template files:

Create the CA Template

Create the template for the certificate authority first. We’ll call the file ca_server.conf . Create and open the file in your text editor:

We only need to provide a few pieces of information in order to successfully create a certificate authority. We need to specify that the certificate will be for a CA (certificate authority) by adding the ca option. We also need the cert_signing_key option to give the generated certificate the ability to sign additional certificates. We can set the cn to whatever descriptive name we’d like for our certificate authority:

Save and close the file.

Create the LDAP Service Template

Next, we can create a template for our LDAP server certificate called ldap_server.conf . Create and open the file in your text editor with sudo privileges:

Here, we’ll provide a few different pieces of information. We’ll provide the name of our organization and set the tls_www_server , encryption_key , and signing_key options so that our cert has the basic functionality it needs.

The cn in this template must match the FQDN of the LDAP server. If this value does not match, the client will reject the server’s certificate. We will also set the expiration date for the certificate. We’ll create a 10 year certificate to avoid having to manage frequent renewals:

Save and close the file when you’re finished.

Create CA Key and Certificate

Now that we have our templates, we can create our two key/certificate pairs. We need to create the certificate authority’s set first.

Use the certtool utility to generate a private key. The /etc/ssl/private directory is protected from non-root users and is the appropriate location to place the private keys we will be generating. We can generate a private key and write it to a file called ca_server.key within this directory by typing:

Now, we can use the private key that we just generated and the template file we created in the last section to create the certificate authority certificate. We will write this to a file in the /etc/ssl/certs directory called ca_server.pem :

We now have the private key and certificate pair for our certificate authority. We can use this to sign the key that will be used to actually encrypt the LDAP session.

Create LDAP Service Key and Certificate

Next, we need to generate a private key for our LDAP server. We will again put the generated key in the /etc/ssl/private directory for security purposes and will call the file ldap_server.key for clarity.

We can generate the appropriate key by typing:

Once we have the private key for the LDAP server, we have everything we need to generate a certificate for the server. We will need to pull in almost all of the components we’ve created thus far (the CA certificate and key, the LDAP server key, and the LDAP server template).

We will put the certificate in the /etc/ssl/certs directory and name it ldap_server.pem . The command we need is:

Give OpenLDAP Access to the LDAP Server Key

We now have all of the certificates and keys we need. However, currently, our OpenLDAP process will be unable to access its own key.

A group called ssl-cert already exists as the group-owner of the /etc/ssl/private directory. We can add the user our OpenLDAP process runs under ( openldap ) to this group:

Now, our OpenLDAP user has access to the directory. We still need to give that group ownership of the ldap_server.key file though so that we can allow read access. Give the ssl-cert group ownership over that file by typing:

Now, give the ssl-cert group read access to the file:

Our OpenSSL process can now access the key file properly.

Configure OpenLDAP to Use the Certificate and Keys

We have our files and have configured access to the components correctly. Now, we need to modify our OpenLDAP configuration to use the files we’ve made. We will do this by creating an LDIF file with our configuration changes and loading it into our LDAP instance.

Move to your home directory and open a file called addcerts.ldif . We will put our configuration changes in this file:

To make configuration changes, we need to target the cn=config entry of the configuration DIT. We need to specify that we are wanting to modify the attributes of the entry. Afterwards we need to add the olcTLSCACertificateFile , olcCertificateFile , and olcCertificateKeyFile attributes and set them to the correct file locations.

The end result will look like this:

Save and close the file when you are finished. Apply the changes to your OpenLDAP system using the ldapmodify command:

We can reload OpenLDAP to apply the changes:

Our clients can now encrypt their connections to the server over the conventional ldap:// port by using STARTTLS.

Setting up the Client Machines

In order to connect to the LDAP server and initiate a STARTTLS upgrade, the clients must have access to the certificate authority certificate and must request the upgrade.

On the OpenLDAP Server

If you are interacting with the OpenLDAP server from the server itself, you can set up the client utilities by copying the CA certificate and adjusting the client configuration file.

First, copy the CA certificate from the /etc/ssl/certs directory to a file within the /etc/ldap directory. We will call this file ca_certs.pem . This file can be used to store all of the CA certificates that clients on this machine may wish to access. For our purposes, this will only contain a single certificate:


Now, we can adjust the system-wide configuration file for the OpenLDAP utilities. Open up the configuration file in your text editor with sudo privileges:

Adjust the value of the TLS_CACERT option to point to the file we just created:

Save and close the file.

You should now be able to upgrade your connections to use STARTTLS by passing the -Z option when using the OpenLDAP utilities. You can force STARTTLS upgrade by passing it twice. Test this by typing:

This forces a STARTTLS upgrade. If this is successful, you should see:

If you mis-configured something, you will likely see an error like this:

Configuring Remote Clients

If you are connecting to your OpenLDAP server from remote servers, you will need to complete a similar process. First, you must copy the CA certificate to the client machine. You can do this easily with the scp utility.

Forwarding SSH Keys to the Client

If you connect to your OpenLDAP server using SSH keys and your client machine is also remote, you will need to add them to an agent and forward them when connecting to your client machine.

To do this, on your local machine, start the SSH agent by typing:

Add your SSH key to the agent by typing:

Now, you can forward your SSH keys when you connect to your LDAP client machine by adding the -A flag:

Copying the CA Certificate

Once you are connected to the OpenLDAP client, you can copy the CA certificate by typing:

Now, append the copied certificate to the list of CA certificates that the client knows about. This will append the certificate to the file if it already exists and will create the file if it doesn’t:

Adjust the Client Configuration

Next, we can adjust the global configuration file for the LDAP utilities to point to our ca_certs.pem file. Open the file with sudo privileges:

Find the TLS_CACERT option and set it to the ca_certs.pem file:

Save and close the file when you are finished.

Test the STARTTLS upgrade by typing this:

If the STARTTLS upgrade is successful, you should see:

Force Connections to Use TLS (Optional)

We’ve successfully configured our OpenLDAP server so that it can seamlessly upgrade normal LDAP connections to TLS through the STARTTLS process. However, this still allows unencrypted sessions, which may not be what you want.

If you wish to force STARTTLS upgrades for every connection, you can adjust your server’s settings. We will only be applying this requirement to the regular DIT, not the configuration DIT accessible beneath the cn=config entry.

First, you need to find the appropriate entry to modify. We will print a list of all of the DITs (directory information trees: the hierarchies of entries that an LDAP server handles) that the OpenLDAP server has information about as well as the entry that configures each DIT.

On your OpenLDAP server, type:

The response should look something like this:

You may have more DIT and database pairs if your server is configured to handle more than one DIT. Here, we have a single DIT with the base entry of dc=example,dc=com , which would be the entry created for a domain of example.com . This DIT’s configuration is handled by the olcDatabase=<1>hdb,cn=config entry. Make note of the DNs of the DITs you want to force encryption on.

We will use an LDIF file to make the changes. Create the LDIF file in your home directory. We will call it forcetls.ldif :

Inside, target the DN you want to force TLS on. In our case, this will be dn: olcDatabase=<1>hdb,cn=config . We will set the changetype to “modify” and add the olcSecurity attribute. Set the value of the attribute to “tls=1” to force TLS for this DIT:

Save and close the file when you are finished.

To apply the change, type:

Reload the OpenLDAP service by typing:

Now, if you search the dc=example,dc=com DIT, you will be refused if you do not use the -Z option to initiate a STARTTLS upgrade:

We can demonstrate that STARTTLS connections still function correctly:

Conclusion

You should now have an OpenLDAP server configured with STARTTLS encryption. Encrypting your connection to the OpenLDAP server with TLS allows you to verify the identity of the server you are connecting with. It also shields your traffic from intermediate parties. When connecting over an open network, encrypting your traffic is essential.

LDAP. Настройка отказоустойчивого LDAP сервера

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:


  • Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
  • Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
  • Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
  • Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
  • Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Ключевые особенности этого LDAP-сервера:

  • Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
  • Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
  • Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
  • SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
  • Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
  • Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.

После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.

Общая структура 389 Directory Server

389 DS состоит из нескольких компонентов.

  • Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
  • Сервер администрирования (Administration Server). Он управляет сервером каталогов. Сервер предоставляет интерфейс управления через протокол HTTP(S), так же предоставляет веб-интерфейс для просмотра логов и статуса репликации. Физически это apache + модули для управления ns-slapd.
  • Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.

Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.

Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).

Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.

После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.

На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.

Для нашего сервиса службы каталогов мы используем два сервера ldap00 и ldap01. На каждом из них будут установлены два инстанса LDAP сервера, один для нужд admin server-ов, второй для наших данных.
План установки будет такой:

  1. Установка первого сервера на ldap00;
  2. Настройка репликации на ldap00;
  3. Установка и настройка ldap инстанса на ldap01;
  4. Установка admin server-а на ldap01;
  5. Установка и настройка ldap инстансов для хранения пользовательских данных.

Установка первого сервера на ldap00

Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.

Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.

Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.

Вот некоторые из них:

  • setup-ds.pl — устанавливает инстанс LDAP-сервера, сервер создается не подключенным к admin server-у;
  • setup-ds-admin.pl — устанавливает admin server, при необходимости устанавливает инстанс LDAP-сервера для хранения своей конфигурации;
  • register-ds-admin.pl — подключает инстанс к admin server-у, при необходимости устанавливает admin server;
  • remove-ds.pl — удаляет инстанс;
  • remove-ds-admin.pl — удаляет admin server и все инстансы;
  • dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.

Для начала запустим dsktune:

# dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).

NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.

Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.

tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.

echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

Добавим в /etc/sysctl.conf:

для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:

запускаем еще раз dsktune и убедимся, что у нас все готово для установки.

Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.

1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.

2. Typical
Allows you to specify common defaults and options.

3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]:


Выбираем третий пункт (мы же experienced server administrators =) )

Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.

If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.

Do you want to register this software with an existing
configuration directory server? [no]:

Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.

Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).

Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.

Затем нас ждет вопрос о Directory Manager DN.

Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.

Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.

Настройка репликации на ldap00

Для подключения к серверу нужно поставить и запустить консоль управления 389-console.

В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.

Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.

Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local

У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.

Теперь немного теории о принципах репликации.

В репликации участвуют два типа серверов, supplier и consumer.

supplier — сервер, который копирует реплику на другой сервер.

обязанности supplier сервера:

  • отвечать на запросы клиентов на чтение и запись;
  • поддержание информации о состоянии изменений реплики;
  • инициализация репликации на consumer сервера.

supplier сервер должен быть всегда доступен, поскольку запись производится только на этом сервере, а потом реплицируется на другие севера.

Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.

consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.

consumer должен:

  • отвечать на read запросы клиентов;
  • пересылать запросы на обновления данных на сервер;
  • при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.

Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.

Supplier сервер повторяет эти изменения на каждом consumer сервере.

Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.

Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.

Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.

Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.

Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.

ldapmodify -h 127.0.0.1 -p 6389 -x -D «cn=root» -W
Enter LDAP Password:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

Ответ должен быть
adding new entry «cn=replication manager,cn=config»

Итого, у нас получилось:

Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:

Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.

Установка и настройка ldap инстанса на ldap01

Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).

Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.

Ответы на вопросы скрипта аналогичны предыдущим.

После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.

Подключение производится примерно так:

ldapmodify -h 127.0.0.1 -p 6389 -D «cn=root» -W

dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb


changelogdir должен указывать на директорию с названием вашего инстанса.

2) добавляем пользователя replication manager:

dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

20380119031407Z означает, что срок действия пароля не ограничен.

3) Создаем суффикс netscaperoot:

dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»

4) Создаем базу для суффикса netscaperoot:

dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot

Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.

5) Создаем корневой o=NetScapeRoot:

dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot

6) Разрешаем репликацию для o=netscaperoot:

dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3

Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).

На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.

Последним этапом будет:

7) Настройка репликации от ldap01 на ldap00:

dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:

nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE

nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль

8) Первичная инициилизация репликации с ldap00 на ldap01:

На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start

Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.

Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.

Установка admin server-а на ldap01

Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl

Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot

Дальнейшая настройка тривиальна, следуем указаниям скрипта.

Установка и настройка ldap инстансов для хранения пользовательских данных

Теперь подключаться через консоль управления можно к любому admin server-у.

На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.

Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).

Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.

ldapsearch через ssl/tls не работает — ldap

Я пытаюсь использовать ldapsearch для подключения ssl/tls, но он не работает:

Сообщение об ошибке не дает достаточного намека на то, что не так. Напротив, простая привязка и поиск идут без проблем на порт 389.

P.S. Вот мой ldap.conf:

Я даже пытался изменить TLS_REQCERT на never , но он все равно не работает.: — (

    1 1
  • 6 окт 2020 2020-10-06 16:12:23
  • Qiang Xu


1 ответ

Сначала замените -h my.server.com -p 3269 на -H ldaps://my.server.com:3269 , как было предложено @dearlbry.

Затем в /etc/openldap/ldap.conf (или /etc/ldap/ldap.conf на моем Ubuntu 13.04) отключите проверку сертификата, добавив следующее:

Вы также можете создать файл ldaprc в текущем каталоге с тем же контентом, если вы не хотите влиять на всю систему.

Это позволит ldapsearch через SSL, но без проверки. Следуйте этим шагам для добавления проверки сертификата в микс.

Как решить ldap_start_tls() «Не удалось запустить TLS: Ошибка подключения» в PHP?

Предупреждение: ldap_start_tls() [function.ldap-start-tls]: невозможно выполнить start TLS: Ошибка подключения в /var/www/X.php в строке Y

ca.crt — это CA, который подписал сертификат сервера LDAP. Сертификат на сервере LDAP истек, и я не могу его изменить.

Вы можете игнорировать действительность в окнах, выпуская

в вашем php-коде. В * nix вам нужно отредактировать /etc/ldap.conf , чтобы содержать

Еще одна вещь, о которой нужно знать, — это то, что для нее требуется версия 3 (версия 2 — по умолчанию php):

Чтобы лучше понять, что происходит, вы можете включить ведение журнала отладки с помощью:

Это можно сделать до того, как произойдет ldap_connect .

Мое решение/обходное решение — использовать

Если у вас есть идея, напишите еще один ответ.

Исправлен путь для ldap.conf в Windows:

Для внесения изменений может потребоваться перезапуск веб-сервера.

В системах на основе debian:

Установите пакет: ldap-utils и в файл /etc/ldap/ldap.conf , отредактируйте строку:

Создайте каталог /etc/ldap/cacerts и скопируйте cacert в /etc/ldap/cacerts/cacert.asc

В системах, основанных на redhat:

Установите пакет: openldap-clients и в файл /etc/openldap/ldap.conf отредактируйте строку:

Создайте каталог /etc/openldap/cacerts и скопируйте cacert в /etc/openldap/cacerts/cacert.asc

Я смог нормально работать с openldap на Amazon Linux (Elastic Beanstalk PHP 7.0) с LDAP MacOS Server 5 с запросом TLS.

(обратите внимание, что если вы не используете openldap, путь будет /etc/ldap/certs/yourcacert.pem). Эта настройка не работала, пока я не разместил сертификат внутри папки certs; он не работал ни с каким другим путем.

Сертификат, который должен быть помещен в этот путь, НЕ является сертификатом TLS сервера. Это сертификат CA (Certificate Authority) органа, выдавшего сертификат TLS сервера/домена. Только сертификат CA, размещенный в этом пути, позволит TLS работать до попытки связывания LDAP в php. Получите сертификат ЦС с вашего сервера или загрузите его с сайта органайзера, они свободно доступны.

Чтобы проверить, работает ли связь LDAP даже без TLS, временно не устанавливайте TLS_REQCERT (возможно, нужно прокомментировать # из TLS_CACERT). Если вы получаете «Не удается подключиться к LDAP», это не ошибка TLS; он просто не может подключиться к серверу, и вам, скорее всего, нужно будет открыть порт 389 (не 636 для TLS).

Не забудьте перезапустить сервер Apache при каждом изменении файла конфигурации или сертификата.

Предупреждение: ldap_start_tls() [function.ldap-start-tls]: невозможно запустить TLS: сервер недоступен

Предупреждение: ldap_start_tls() [function.ldap-start-tls]: невозможно запустить TLS: сервер недоступны в /var/www/html/testldap/index.php по линии 13 Ldap_start_tls удалось

Моя конфигурация выглядит следующим образом

Centos 5.7 версии PHP 5.3.3

php53-Ldap сконфигурированных , Независимо от того, что я пытаюсь сделать, проблема с starttls дает мне головную боль. Любая помощь будет высоко оценен.

Создан 12 дек. 11 2011-12-12 11:11:10 Amol C

Пожалуйста, покажите свой код, и посоветуйте, что провайдер LDAP вы пытаетесь подключиться. – DaveRandom 12 дек. 11 2011-12-12 11:16:47

2 ответа

Вы сделали installed PHP —with-ldap [= DIR]?

  1. Не используйте ldap_start_tls(), если вы уже подключены к серверу LDAP через SSL, например, «LDAPS: // hostame».
  2. вызов ldap_connect() с LDAP: //, а не LDAPS: // для ldap_start_tls(), чтобы добиться успеха

Создан 12 дек. 11 2011-12-12 11:20:15 Elzo Valugi

Я настроил php с php-ldap У меня есть настройки у моих системных администраторов из активного каталога и, следовательно, вам нужно будет их использовать. – Amol C 12 дек. 11 2011-12-12 11:52:41

Хорошо, какое увлекательное путешествие я провел с этим.

Проблема, с которой вы сталкиваетесь, заключается в том, что ваша машина не принимает сертификат сервера как действительный. Простая работа с этим заключается в отключении проверки, которая выполняется в файле ldap.conf или с переменной окружения.


Вы можете редактировать файл в /etc/openldap/ldap.conf ( c:\openldap\sysconf\ldap.conf на Windows) или создать, если он уже не существует, и поставить эту строку в ней:

. или вы можете создать переменную среды названный LDAPTLS_REQCERT со значением never .

После того, как я сделал одну из этих вещей, следующий сценарий работал для меня:

Досадно, ни putenv(‘LDAPTLS_REQCERT=never’); , ни $_ENV[‘LDAPTLS_REQCERT’] = ‘never’; будет работать — вы должны либо создать конфигурационный файл или статически задать переменную.

Если вы хотите проверить сертификаты, вам нужно будет еще немного прочитать о том, как правильно настроить OpenLDAP.

Источники для этого:

Создан 12 дек. 11 2011-12-12 14:14:23 DaveRandom

Denis IT Pro. Russia

Share knowledge

LDAPS, TLS, SSL

Инструкция №0176-IT — LDAPS, TLS, SSL

Port Desctiption
389 plain text OR TLS
636 SSL port
3268 LDAP GC
3269 LDAP GC SSL

Для не родного Microsoft софта, в большинстве случаев будет настраиваться защита через SSL или TLS

Настройка для SSL для attassiant и других подобных java приложений …

Мы же рассмотрим настройку поддержки TLS, на примере ПО Racktables

Для начала убедимся, что у нас есть поддержка TLS и SSL

LLL — формат вывода

H — указываем адрес ldap

P — версия протокола

ZZ — Расширенный режим StartTLS (Transport Layer Security). Если задать -ZZ, тогда операция обязательно должна быть успешной.

Выполнив запрос например такой как выше

мы увидем ошибку

Попробуем явно обратиться по SSL

Ошибка измениться на

Поправим настройки openldap

TLS_REQCERT ALLOW — разрешает нам использовать сертификаты без проверки, то есть selfsigned или там где на серверы не установлены Enterprise CA. Так как наша задача шифровать канал, а не валидировать DC — нам это подходит

После внесение правок, у нас сразу же начнет проходить запрос, на LDAPS порт 636 так и на 389 port TLS (опции -ZZ)

После чего идем уже в конфиг ractables и включаем обязательное требования TLS, use_tls’ => 2 — если где-то настроено не корректно и TLS не работает, вы не сможете войти по LDAP в Racktables

Понять в открытом ли виде ходят ваши данные до контроллера домена поможет, если TLS не работает, вы увидете свой логин и пароль, где host ip DC

Так же для проверки TLS можно проверять так

Сначала ставим tsharck

Полезные команды

Проверяем, что точно есть поддержка ldaps (SSL)

Information Security Squad

В наших предыдущих статьях мы обсуждали установку сервера LDAP в Ubuntu 18.04 / 16.04 и настройку клиента LDAP в Ubuntu 18.04 / 16.04.

В этом кратком руководстве рассматривается защита LDAP-сервера с помощью сертификата и ключа SSL / TLS.

У вас есть два варианта получения сертификата SSL, используемого для защиты Сервера LDAP.

  • Использование самоподписанного SSL-сертификата
  • Приобретение SSL-сертификатов от доверенного центра сертификации.

Это руководство объяснит использование самоподписанных сертификатов. Итак, начнем.

Шаг 1: Генерация самоподписанных сертификатов SSL

Войдите на сервер LDAP и создайте сертификаты SSL для использования.

Удалите парольную фразу из сгенерированного закрытого ключа:

Затем подпишите свой сертификат:

Шаг 2. Настройте SSL на сервере LDAP

Скопируйте сертификаты и ключ в каталог /etc/ldap/sasl2/.

Установите право собственности на сертификаты для пользователя openldap.

Настройте сервер LDAP для использования сертификатов SSL.

Создайте файл конфигурации LDAP для SSL,

Примените конфигурацию, используя следующую команду.

Шаг 3. Настройте клиента LDAP

Настройте клиент LDAP, чтобы обеспечить шифрование соединения между клиентом и сервером.

Добавьте разрешающую строку LS_REQCERT в /etc/ldap/ldap.conf.

Теперь настройте механизм OpenLDAP SSL, раскомментировав строки ниже в файле /etc/ldap.conf.

Теперь вы можете пользоваться SSL-соединением между LDAP-клиентом и сервером.

Илон Маск рекомендует:  Производительность и организация
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL