Что такое код ldap_bind


Сохранение dns зон BIND в дирректориях openLDAP.

Этот документ — попытка описать КАК под Linux можно упростить администрирование DNS зон сохраняя их в дирректориях openLDAP. Здесь Вы не найдете описания работы BIND, LDAP и как компилируются эти программы.

Часть 1.
Первое что необходимо — это переделать BIND чтобы он понимал LDAP дирректории, для этого необходимо скачать архив bind-sdb-ldap-0.9. К моменту написания документа последние версии программ которые я использовал это BIND-9.2.1 и bind-sdb-ldap-0.9, и я надеюсь разработчики BIND обратят внимание на такую возможность и включат ее в свой пакет в дальнейшем.
Распаковываем архивы.
Все ниже приведенные действия описаны в файле bin-sdb-ldap/INSTALL.

Копируем файлы ldapdb.c в дирректории bin/named и ldapdb.h в bin/named/include исходников BIND.
Редактируем файл bin/named/Makefile.in добавляем строки:

Все. Дальше конфигурируем и компилируем BIND так как нам это надо. Так же если выше приведенные действия Вам кажутся сложными, то уже готовый патч для версии BIND-9.2.1 лежит здесь.

Часть 2.
Следующий этап — настройка файла named.conf и заполнение дирректорий LDAP.
Для понимания LDAP сервером необходимых значений dns зон — копируем схему dnszone.schema в дирректорию схем LDAP сервера.

Разберем на примере небольшую зону (sgb мой внутренний домен):
Создаем группу DNS в дирректории LDAP (dc=sgb это root_ldap дирректория и это никак не связано с доменом sgb, просто совпадения :)

Описание самой зоны sgb:
Описание записи A для localhost:
Описание записи A для book и boss аналогична:
Записываем в ldif файл и добавляем в директорию командой ldapadd. Так же для управления директориями можно установить программу с графическим интерфейсом.

Разберем обратную зону 2.168.192.in-addr.arpa: Описание зоны 2.168.192.in-addr.arpa:

Описание записи PTR для book и boss:
Все просто. Полный HOWTO по заполнению dns зон в LDAP с примерами здесь.

Осталось заменить запись зон в named.conf.
Если раньше было так: Заменяем: Число 178600 это TTL для всех записей где неопределен dNSTTL.

Заключение.
Большинство из источников этого документа было придумано другими людьми, однако почти все примеры взяты из моей головы и протестированы на моем ноутбуке с дистрибутивом RedHat-7.2 и openldap-2.0.11. Если кому нибудь придет в голову написать более обширный документ по централизованному администрированию сетей на базе дирректорий LDAP и воспользоваться данным источником, то я невозражаю, с условием сохранения ниже перечисленных ссылок на исходную документацию.

Что такое код ldap_bind

(PHP 3, PHP 4, PHP 5)

ldap_bind — связывает с LDAP-директорией.

Описание

bool ldap_bind (resource link_identifier [, string bind_rdn [, string bind_password]])

Связывает с LDAP-директорией со специфицированными RDN и password. Возвращает TRUE при успехе, FALSE при неудаче.

ldap_bind() выполняет операцию bind в директории.
bind_rdn и bind_password являются необязательными. Если не специфицированы, делается попытка anonymous bind/анонимной связки.

Проблема с LDAP, неверный синтаксис ldap_bind dn

Я знаю, что моя ошибка будет чем-то очень простым, но я пытался найти проблему и не вижу ее, может быть, вы мне поможете .

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

Мой php-код выглядит следующим образом:

Когда я пытаюсь запустить код, появляется следующая ошибка: ldap_bind неверный синтаксис DN в строке xxxx и эта строка выглядит следующим образом:

2 ответа

Как указано в ошибке, ваш bind DN имеет неверный формат. DN представляют полный путь к объекту — так что в вашем случае должно быть что-то вроде этого (похоже, вы на AD?)

«cn = имя пользователя, ou = пользователи домена, dc = пример, dc = com»

В зависимости от вашего вида LDAP (Active Directory, OpenLDAP и т. д.), вы можете использовать uid (так что просто «имя пользователя») для привязки, но лучше предположить, что вы всегда нужен полный DN.

Вы можете использовать инструмент LDAP, например Apache Directory Studio , чтобы помочь в построении запросов и выяснить, какой объект DN есть. Или есть ldp.exe (при условии, что это AD), но студия каталогов проще в использовании.

На DC, выполняя: dsquery user -samid jim

покажет DN пользователя, соответствующего sAMAccountName: «CN = Джим Виллек, CN = Пользователи, DC = сумасшедший, DC = Виллек, DC = ком»

How to bind to a active directory server (ldaps://) using ldap_simple_bind_s

I have written a sample program to authenticate a user on ldaps server, program is as follows:

This program always fails during first bind operation with message «Can’t contact LDAP server» and a return code of -1, I also tried with ldap_simple_bind_s, but result is same, however the same program works well if I change the URL to ldap://10.10.10.10:389

In ldap.conf file

entry is already there. Can someone please help on this?

Аутентификация LDAP — метод ldap_bind () очень медленный

Мое приложение имеет аутентификацию ldap для пользователей.

Когда я проверяю подлинность, требуется около 10-15 секунд. Если я немедленно выйду из системы и войду снова. Это просто занимает 100 мс или что-то очень медленное время. Через некоторое время, когда я пытаюсь войти снова, это снова занимает 10-15 секунд.

Это происходит очень быстро, когда мы подключаемся с моего персонального компьютера с Windows, но на нашем веб-сервере требуется время.

Что может быть причиной этой проблемы?

Ниже приведен мой код, но он успешен, но требует времени для завершения. Если я обновлю эту страницу снова, она будет мгновенной.

Решение

Вы можете захватить захват сетевых пакетов (например, Wireshark) — поскольку вы используете открытый текст LDAP, он будет читабельным. Вы увидите метки времени с высоким разрешением для пакетов и сможете определить, где происходит задержка. Вы также можете выделить время для различных компонентов процесса аутентификации в коде, чтобы получить лучшее представление о какие занимает много времени (пример ниже).

Существуют ли основные проблемы с сетью, например, много повторно переданных пакетов?

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

Получаете ли вы разные результаты, используя VIP с балансировкой нагрузки (если таковой существует) и каждый сервер каталогов? Может быть определенный сервер, который работает плохо. Я также столкнулся с конфигурациями балансировщика нагрузки, которые привели к большой задержке (VIP был медленным, каждый сервер каталогов работал нормально) и смог привлечь сетевую команду, предоставив хорошую статистику.

Ошибка в привязке к LDAP (ldap_bind) при использовании SSL-соединения?

Всем доброго дня!

Столкнулся с проблемой при бинде к LDAP (Active Directory на Windows 2008 сервере) при использовании SSL-соединения (ldaps://. ).
При выполнении следующего кода:

на строке с функцией ldap_bind выдает ошибку:

Если вместо ldaps:// использовать ldap://, то есть, незащищенное соединение, то этот же код выполняется без ошибок.

Мне критично использовать именно SSL-соединение, так как оно, судя по всему, необходимо для смены пароля пользователя LDAP посредством задания параметра unicodePwd функцией ldap_mod_replace.

Или, возможно, есть иной способ смены пароля в AD, помимо вышеописанного?

Вопрос по php, ldap &#8211 Проблема LDAP, неверный синтаксис ldap_bind dn

Я знаю, что моя ошибка будет чем-то очень простым, но я пытался найти проблему, и я не вижу ее, может быть, вы можете помочь мне .

Я пытаюсь создать функцию с помощью PHP, чтобы я мог подключиться к LDAP и найти нужную информацию.

Мой PHP-код выглядит следующим образом:

Когда я пытаюсь запустить код, он выдает мне следующую ошибку: ldap_bind неверный синтаксис DN в строке xxxx, и эта строка выглядит следующим образом:

покажет DN пользователя, соответствующего sAMAccountName: «CN = Джим Виллек, CN = Пользователи, DC = сумасшедший, DC = willeke, DC = com»

ваш bind DN имеет неправильный формат. DN представляют полный путь к объекту — так что в вашем случае должно быть что-то вроде этого (похоже, вы на AD?)

«cn = имя пользователя, ou = пользователи домена, dc = пример, dc = com»

В зависимости от вашего вида LDAP (Active Directory, OpenLDAP и т. Д.), Вымог бы быть в состоянии использовать uid (так что просто ‘username’) для привязки, но лучше предположить, что вам всегда нужен полный DN.

LDAP.com

Lightweight Directory Access Protocol

LDAPv3 Wire Protocol Reference: The LDAP Bind Operation

The LDAP bind operation is used to authenticate a client to the directory server. LDAPv3 supports two basic types of authentication:

  • Simple authentication, in which the client identifies itself with a DN and proves its identity with a password.
  • SASL (Simple Authentication and Security Layer) authentication, which is an extensible framework that allows for a broad range of authentication types.

A client can send a bind request at any time on a connection. If the connection has already been authenticated with an earlier bind request, sending another bind request can be used to re-authenticate the connection as a different user (or the same user if you send the same credentials). If the bind attempt does not succeed, the connection will revert to an unauthenticated state. And any request sent on a connection before the client performs a bind will also be treated as unauthenticated.

LDAP doesn’t do anything to protect bind credentials from anyone who can observe the communication between the client and the server. Certain SASL mechanisms do provide the ability to obscure sensitive information like passwords, but other SASL mechanisms do not, and there is also no protection for simple authentication. Unless you know that you’re using a SASL mechanism that does adequately protect the authentication credentials, and you also know that there won’t be any other sensitive information transferred over the connection, you are strongly encouraged to encrypt the communication between the client and the server (for example, using TLS).

The Bind Request

The bind request protocol operation is defined as follows in RFC 4511 section 4.2:

The LDAPDN and LDAPString dependencies are defined as follows elsewhere in RFC 4511:

The elements of the bind request protocol op are as follows:

  • version — The LDAP protocol version. You should only ever use version 3. LDAPv2 was declared historic by RFC 3494 in March of 2003 and should no longer be used. And because LDAPv3 is so extensible, it’s unlikely that there will ever be a need for an LDAPv4.
  • name — The DN of the user that is trying to authenticate. This is typically only provided when performing a simple bind. When using SASL authentication, the user is generally identified by some other means (e.g., something inside the SASL credentials or some other information the server has about the client), and the name field is left blank. Note that the official LDAP specification states that this must be a DN, but some directory servers (like Active Directory) disregard this and allow certain kinds of non-DN values.
  • authentication — The credentials for the bind request. For a simple bind, this is the password for the account authenticated by the name element. For a SASL bind, this is a sequence that contains at least the SASL mechanism name and optionally an octet string with SASL credentials.

We’ll provide specific examples of simple and SASL bind requests later in this section.

The Bind Response

The bind response protocol operation is defined as follows in RFC 4511 section 4.2.2:

This means that the bind response has all of the elements of the LDAPResult protocol op (result code, matched DN, diagnostic message, and optional referral URLs), which we’ve already discussed in depth in an earlier section, plus an optional set of server SASL credentials. The server SASL credentials will only be included in the response to a SASL bind request, and only in response to certain kinds of SASL bind requests.

The bind response protocol operation has a BER type of 0x61 (application class, constructed, tag number one). We will provide examples of bind responses later in this section.

The Simple Bind Operation

As described above, the simple bind operation is used to authenticate with a DN and password. There are actually two kinds of simple binds: anonymous and authenticated. The anonymous simple bind has empty strings for both the DN and the password, while an authenticated simple bind has non-empty values for both of those fields.

The original LDAPv3 specification (RFC 4511 section 4.2.2) stated that an anonymous simple bind only required that the password be empty, but allowed the DN to be non-empty. This led to security vulnerabilities in a number of applications that used an LDAP server to authenticate users but didn’t bother checking to see whether the user actually provided a password. The revised LDAPv3 specification (RFC 4513 section 5.1.2) now recommends that servers reject simple binds that include a non-empty DN but an empty password with an unwillingToPerform (53) result.

When a non-empty password is provided, it must be the clear-text representation of that password, without any encryption, hashing, or other kind of obfuscation. So a communication security layer like TLS is strongly recommended when using an authenticated simple bind to ensure that the credentials are protected.

The following example demonstrates the encoding for an anonymous simple bind request with a message ID of one and no request controls:

And the following example shows the encoding for an authenticated simple bind request for user u >

The bind response protocol operation for a simple bind request is merely an LDAPResult with type 0x61. Assuming that the server returned a successful response to either of the above requests, with no matched DN, diagnostic message, referral URLs, or controls, it would be encoded as follows:

The SASL Bind Operation

SASL is the Simple Authentication and Security Layer, and it’s based on the specification described in RFC 4422. SASL is an extensible framework that allows for a wide variety of authentication types, including the creation of custom types. Each flavor of SASL authentication is called a mechanism, and the SASL mechanism that the client wants to use is identified by name. There SASL bind request may also include additional information, called SASL credentials, to use in the authentication process.

Some common SASL mechanisms include:

  • PLAIN — Authenticates with an identifier and a password. This is very similar to LDAP simple authentication, although the identifier doesn’t have to be a DN. It could be a username, email address, telephone number, account number, or something else that uniquely identifies the target user and that the user is likely to know. It’s also possible to provide an alternate authorization identity to indicate that subsequent requests on the connection should be processed under the authority of some other user.
  • EXTERNAL — Authenticates the client with information that the server already knows about the client from some means other than what it provides in the bind request. This is most commonly used to authenticate with a certificate that the client presented during TLS negotiation, but it’s conceivable that the client could be identified in some other way.
  • GSSAPI — Authenticates the client with a Kerberos KDC.
  • CRAM-MD5, DIGEST-MD5, SCRAM-SHA-1, and SCRAM-SHA-256 — These are challenge-response authentication mechanisms that authenticate the user with an identifier and a password (much like the PLAIN mechanism), but that protect the password by constructing a digest through the use of a random challenge string provided by the server (and often combining it with additional information).
  • OAUTHBEARER — Authenticates the client with an OAuth 2.0 bearer token.

The Ping Identity Directory Server (formerly UnboundID Directory Server) also defines a number of additional SASL mechanisms for stronger authentication types, including:

  • UNBOUNDID-CERTIFICATE-PLUS-PASSWORD — Identifies the client with a certificate provided during TLS negotiation, but also uses a password as a second authentication factor.
  • UNBOUNDID-TOTP — Authenticates the client with an identifier, a static password, and a time-based one-time password (like those generated by the Google Authenticator or Authy apps) as described in RFC 6238.
  • UNBOUNDID-DELIVERED-OTP — Authenticates the client with an identifier, a static password, and a one-time password generated by the server and delivered to the client through some out-of-band mechanism (for example, SMS, email message, voice call, or mobile app notification).
  • UNBOUNDID-YUBIKEY-OTP — Authenticates the client with an identifier, a static password, and a one-time password generated by a YubiKey device.

Describing all of the ins and outs of all these SASL mechanisms is beyond the scope of this document. But to illustrate the encoding for SASL requests and responses, let’s look at an example using the CRAM-MD5 mechanism. Although this mechanism is no longer considered secure, it is good for illustration purposes because it is fairly simple, because it involves a multi-stage bind process, and because it involves a response that includes server SASL credentials.

The CRAM-MD5 authentication process operates as follows:

    The client sends a bind request with a version of 3, an empty name, a SASL mechanism name of CRAM-MD5, and no SASL credentials. If we assume a message ID of one and no request controls, that bind request would be encoded as:

The server returns a bind response with a result code of saslBindInProgress (14) and server SASL credentials that are a randomly-generated challenge string encapsulated in angle brackets. If we assume that the server generated a challenge string of , the bind response would be encoded as:

The client sends a second bind request with a version of 3, an empty name, a SASL mechanism name of CRAM-MD5, and SASL credentials that are comprised of the authentication ID followed by a space and a hexadecimal representation (with all letters in lowercase) of the HMAC-MD5 digest of the challenge string (returned in step 2) using the user’s password as the key. Let’s assume that the user wants to authenticate with a username of jdoe (which will be indicated by an authentication ID of u:jdoe) and a password of secret123. The hexadecimal representation of the HMAC-MD5 digest of the string using a key of secret123 is d52116c87c31d9cc747600f9486d2a1d, so the second bind request (this time, with message ID two) is:

Assuming that the credentials were correct and the account is usable, the server returns a bind response with a result code of success (0) and no server SASL credentials. This is encoded as:

ldap_bind function

The ldap_bind function asynchronously authenticates a client with the LDAP server. The bind operation identifies a client to the directory server by providing a distinguished name and some type of authentication credential, such as a password. The authentication method used determines the type of required credential.

Syntax

Parameters

The session handle.

A pointer to a null-terminated string that contains the distinguished name of the entry used to bind.

A pointer to a null-terminated string that contains the credentials to use for authentication. Arbitrary credentials can be passed using this parameter. The format and content of the credentials depend on the setting of the method parameter. For more information, see the Remarks section.

The authentication method to use.

Return Value

If the function succeeds, the return value is the message ID of the initiated operation.

If the function fails, it returns –1 and sets the session error parameters in the LDAP structure.

Remarks

This implementation of ldap_bind supports the following authentication method.

Authentication method Description Credential
LDAP_AUTH_SIMPLE Authentication with a plaintext password. A string that contains the user password.

LDAP_AUTH_SIMPLE is the only authentication method compatible with the asynchronous version of binding; ldap_bind. Using any other authentication method with ldap_bind will fail and return LDAP_PARAM_ERROR. Calling ldap_bind with the LDAP_AUTH_SIMPLE method is equivalent to calling ldap_simple_bind. All other authentication methods require synchronous binding as provided by ldap_bind_s.

Be aware that LDAP 2 servers require an application to bind before attempting any other operations that require authentication.

Multithreading: Bind calls are not safe because they apply to the connection as a whole. Use caution if threads share connections and, when possible, thread the bind operations with other operations.

ldap_bind

ldap_bind - связывает с LDAP-директорией.

Описание

bool ldap_bind (resource link_identifier [, string bind_rdn [, string bind_password]])

Связывает с LDAP-директорией со специфицированными RDN и password. Возвращает TRUE при успехе, FALSE при неудаче.

ldap_bind() выполняет операцию bind в директории.
bind_rdn
и bind_password являются необязательными. Если не специфицированы, делается попытка anonymous bind/анонимной связки.

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