Сложные отношения Kerberos и LDAP
У меня проблемы с пониманием отношений между LDAP и Kerberos (концептуально).
Я понимаю LDAP как службу каталогов, а Kerberos как службу аутентификации.
Мы также знаем, что LDAP также способен хранить пароли, но дизайн LDAP должен быть общедоступным каталогом и не подходит для хранения конфиденциальной информации. Вот почему предпочтительно делегировать аутентификацию другому сервису, например Kerberos.
Что я не понимаю, так это два вопроса:
- На какой сервер клиенты отправляют свои запросы, когда пользователь пытается войти? Моя интуиция подсказывает мне, что это сервер Kerberos. Если да, то где приходит сервер LDAP?
- Где системный администратор устанавливает разрешения? В этом случае моя интуиция подсказывает мне LDAP. Я могу себе представить, что может быть запись для каждой системы и / или службы, и пользователям будет предоставлен доступ к ним через членство в группах или напрямую. Если да, означает ли это, что сервер LDAP (через интерфейс, подобный phpLDAPadmin) будет соответственно устанавливать группы и пользователей на сервере Kerberos?
Я особенно запутался, потому что вижу связь между LDAP и Kerberos в обеих документах. LDAP говорит о делегировании аутентификации Kerberos здесь, а Kerberos говорит о наличии LDAP в качестве бэкэнда здесь.
Все документы, которые я читаю, кажутся кусочками головоломки, которую мне не удается собрать. Я ценю, если кто-то может объяснить, как это сделать.
3 ответа
О, это было давно. Посмотрим, что я могу вспомнить.
Да, это может определенно сбивать с толку, потому что вы можете использовать Kerberos для аутентификации для LDAP, и вы также можете сделать так, чтобы Kerberos использовал LDAP в качестве бэкэнда. Хотя это не одно и то же, часто трудно различить, о чем идет речь, когда вы пытаетесь найти его. Я могу говорить только о LDAP, использующем Kerberos для его аутентификации, поскольку у меня нет опыта работы с ним.
- Ваша интуиция права, что она использует сервер Kerberos. Насколько я понимаю, клиент запрашивает TGT с сервера Kerberos ДЛЯ сервера LDAP (используя имя субъекта службы "ldap/hostname@DOMAIN.NAME" или подобное). Затем клиент может использовать это для входа на сервер LDAP, так как он может проверить билет. Сам пароль клиента никогда не отправляется на сервер LDAP.
- Это если вы используете LDAP в качестве бэкэнда для Kerberos. Вы можете использовать каталог LDAP здесь, чтобы сохранить атрибуты и значения для различных вещей. Вы, конечно, не должны использовать LDAP в качестве серверной части для Kerberos.
Вещи становятся еще более запутанными, когда они начинают говорить о SASL, потому что трудно сказать, говорят ли они о SASL на переднем или заднем конце LDAP. Другими словами, используется ли он клиентами для аутентификации в LDAP? Или он используется LDAP для передачи пароля другому источнику аутентификации? Просто будьте осторожны.
В качестве отступления: можно использовать простую привязку с LDAP, отправить пароль на сервер LDAP, который затем передает пароль другому источнику аутентификации (например, Kerberos). Если вы делаете что-то подобное, это хорошо, потому что сам пароль не хранится в LDAP, но, поскольку простое связывание - это простой текст, вам нужно обязательно использовать TLS между клиентом и сервером LDAP.
Надеюсь, это поможет немного. Похоже, у тебя в основном правильная идея.
Ваша интуиция на ходу в обоих случаях. Давайте ответим на оба ваших вопроса.
- Здесь сервис Kerberos является системой аутентификации. Клиент получит зашифрованный билет от сервера kerberos (после успешной аутентификации, конечно) и затем представит его серверу, чтобы показать, что они аутентифицированы.
- Здесь сервис ldap является системой авторизации. Информация о пользователе хранится в каталоге (например, UID / GID и т. Д.). По сути это заменяет информацию в /etc/passwd. Сервер ldap не обновляет информацию на сервере kerberos.
Это действительно зависит от вашей настройки. Я боролся с этим некоторое время, но я не эксперт.
Для системного администратора отношения между 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 не работает, система будет думать, что ваше имя пользователя не ' не существует.