У нас есть несколько клиентских серверов в DMZ, которые также имеют учетные записи пользователей, все учетные записи находятся в файле теневых паролей. Я пытаюсь объединить входы пользователей в систему и думаю о том, чтобы разрешить пользователям LAN аутентифицироваться в Active Directory. Для аутентификации требуются службы Apache, Proftpd и ssh. После консультации с группой безопасности я настроил DMZ для аутентификации, в котором есть прокси-сервер LDAPS, который, в свою очередь, связывается с другим прокси-сервером LDAPS (прокси-2) в локальной сети, и этот передает информацию аутентификации через LDAP (как привязка LDAP) к контроллеру AD. Второй прокси-сервер LDAP необходим только потому, что сервер AD отказывается говорить по TLS с нашей безопасной реализацией LDAP. Это работает для Apache с использованием соответствующего модуля. На более позднем этапе я могу попытаться перенести учетные записи клиентов с серверов на прокси-сервер LDAP, чтобы они не разбросаны по серверам.
Для SSH я присоединил proxy2 к домену Windows, чтобы пользователи могли входить в систему, используя свои учетные данные Windows. Затем я создал ключи ssh и скопировал их на серверы DMZ с помощью ssh-copy, чтобы включить вход без пароля после аутентификации пользователей.
Это хороший способ реализовать такую систему единого входа? Я пропустил здесь какие-либо проблемы с безопасностью или, может быть, есть лучший способ достижения моей цели?
Если вы используете PAM для своего стека аутентификации, вы можете использовать pam_krb5 предоставлять Kerberos аутентификация за ваши услуги. Kerberos изначально был разработан для работы с враждебными средами, обрабатывает аутентификацию через прокси и уже является частью спецификации AD. Зачем бороться с LDAP, если вы можете заставить Kerberos делать за вас тяжелую работу и продолжать жить? Да, вам придется немного почитать, и да, это займет немного времени, но я использовал аутентификацию Curb-to-AD в течение многих лет и обнаружил, что это самый простой и быстрый способ получить SSO работает из коробки, когда у вас есть Active Directory в качестве серверной части аутентификации.
Главное, с чем вы столкнетесь, - это то, что Microsoft решила очень конкретизировать типы шифрования по умолчанию (они в основном сделали свои собственные), поэтому вам нужно настроить свои клиенты Kerberos, чтобы иметь правильные соответствие типы шифрования, иначе серверы AD продолжат отклонять его. К счастью, это простая процедура, и она не потребует большего количества правок в krb5.conf.
А теперь несколько ссылок для рассмотрения ...
Взгляд Microsoft на Kerberos
Объединение Kerberos и Active Directory
ssh и Kerberos аутентификация через PAM
Apache и Kerberos
ProFTP и Kerberos
RFC действий Microsoft с Kerberos (о которых вы действительно не хотите читать):