1

У меня проблемы с пониманием взаимосвязи между LDAP и Kerberos (концептуально).

Я понимаю LDAP как службу каталогов, а Kerberos как службу аутентификации.

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

Что я не понимаю, так это два вопроса:

  1. На какой сервер клиенты отправляют свои запросы, когда пользователь пытается войти? Моя интуиция подсказывает мне, что это должен быть сервер Kerberos. Если да, то где приходит сервер LDAP?
  2. Где системный администратор устанавливает разрешения? В этом случае моя интуиция подсказывает мне LDAP. Я могу себе представить, что может быть запись для каждой системы и / или службы, и пользователям будет предоставлен доступ к ним через членство в группах или напрямую. Если да, означает ли это, что сервер LDAP (через интерфейс, такой как phpLDAPadmin) будет устанавливать группы и пользователей соответственно на сервере Kerberos?

Я особенно запутался, потому что вижу связь между LDAP и Kerberos в обеих документах. LDAP говорит о делегировании аутентификации Kerberos здесь, а Kerberos говорит о наличии LDAP в качестве бэкэнда здесь.

Все документы, которые я читаю, кажутся кусочками головоломки, которую мне не удается собрать. Я ценю, если кто-то может объяснить, как это сделать.

|источник

3 ответа3

2

О, это было давно. Посмотрим, что я могу вспомнить.

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

  1. Ваша интуиция права, что она использует сервер Kerberos. Насколько я понимаю, клиент запрашивает TGT с сервера Kerberos ДЛЯ сервера LDAP (используя имя участника службы "ldap/hostname@DOMAIN.NAME" или подобное). Затем клиент может использовать это для входа на сервер LDAP, так как он может проверить билет. Сам пароль клиента никогда не отправляется на сервер LDAP.
  2. Это если вы используете LDAP в качестве бэкэнда для Kerberos. Вы можете использовать каталог LDAP здесь, чтобы сохранить атрибуты и значения для различных вещей. Вы, конечно, не должны использовать LDAP в качестве серверной части для Kerberos.

Ситуация становится еще более запутанной, когда они начинают говорить о SASL, потому что трудно сказать, говорят ли они о SASL на переднем или заднем конце LDAP. Другими словами, используется ли он клиентами для аутентификации в LDAP? Или он используется LDAP для передачи пароля другому источнику аутентификации? Просто будьте осторожны.

В качестве отступления: можно использовать простую привязку с LDAP, отправить пароль на сервер LDAP, который затем передает пароль в другой источник аутентификации (например, Kerberos). Если вы делаете что-то подобное, это хорошо, потому что сам пароль не хранится в LDAP, но, поскольку простое связывание - это простой текст, вам нужно обязательно использовать TLS между клиентом и сервером LDAP.

Надеюсь, это поможет немного. Похоже, у тебя в основном правильная идея.

|источник
1

Ваша интуиция на ходу в обоих случаях. Давайте ответим на оба ваших вопроса один за другим.

  1. Здесь сервис Kerberos является системой аутентификации . Клиент получит зашифрованный билет от сервера kerberos (после успешной аутентификации, конечно) и затем представит его серверу, чтобы показать, что они аутентифицированы.
  2. Здесь сервис ldap является системой авторизации . Информация о пользователе хранится в каталоге (например, UID / GID и т.д.). По сути это заменяет информацию в / etc / passwd. Сервер ldap не обновляет информацию на сервере kerberos.
|источник
0

Это действительно зависит от вашей настройки. Я боролся с этим некоторое время, но я не эксперт.

Для системного администратора отношения между LDAP и Kerberos могут быть такими же простыми, как машина, использующая их обоих. Ваша настройка может быть такой же простой, как использование LDAP в качестве источника для /etc /passwd и /etc /group через nsswitch.conf (и такого плагина, как nss-pam-ldapd из archlinux repo), оставляя атрибут userPassword в LDAP как восклицательный знак точка или звездочка (что означает отсутствие пароля и отсутствие возможности входа).

Kerberos KDC, обеспечивающий аутентификацию по паролю для любых машин, которые вы хотите, где интеграция входа в систему будет отличаться в зависимости от предлагаемой услуги. Например, если это удаленная машина, требующая только доступа через ssh, LDAP по-прежнему предоставляет ту же информацию, что и везде, но Kerberos требуется всего несколько строк в файлах конфигурации ssh. В другой системе, где требуется полная интеграция входа в систему, это может оказаться ОГРОМНОЙ болью в заднице, потому что это требует внесения многих изменений в конфигурацию PAM. Это легко сделать в клиентах RHEL с authconfig, но ожидать, что это будет огромной головной болью в других местах, если вы не знакомы с PAM Тем не менее, положительный момент в работе с PAM заключается в том, что большинство программ (например, ssh) могут использовать PAM, поэтому вам больше не нужно беспокоиться о конфигурации ssh.

Другими словами, если KDC не работает, система никогда не примет ваш пароль правильно или нет (но она знает, что вы пользователь из-за LDAP), а если сервер LDAP не работает, система будет думать, что ваше имя пользователя не ' не существует.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .