У меня есть хорошо работающая настройка с использованием OpenLDAP для информации о пользователях и Kerberos для аутентификации, но нам также нужна интеграция с Windows, и для этого мы решили, что переход в Active Directory может быть хорошей идеей. Перенос информации об учетных записях из OpenLDAP довольно тривиален и легко осуществим, но у меня возникла проблема: как перенести пароли/информацию об аутентификации из MIT Kerberos в AD?
Я понимаю, что между ними возможно какое-то делегирование, но это не решит мою проблему? Или я могу выполнить аутентификацию AD против MIT Kerberos KDC? Пароли хранятся в хэшах в Kerberos, поэтому я не могу переместить их в открытом виде. Интересно, будут ли хэши совместимы между MIT и AD, поскольку я могу ввести пароль в AD также в зашифрованном виде.
Есть ли у кого-нибудь опыт в этом? Что бы вы предложили, помимо того, чтобы просто потребовать от всех моих пользователей сменить пароли и иметь одну большую проблему, когда вся аутентификация переключается с одного места на другое без какого-либо сосуществования.
решение1
Но у меня возникла проблема: как перенести пароли/данные аутентификации из MIT Kerberos в AD?
Вы этого не делаете. Хотя хэши Kerberos должны быть одинаковыми между системами, поскольку они используются в качестве ключей шифрования и дешифрования, ни один из публичных API не позволяет устанавливать их напрямую. Учитывая, что AD требует, чтобы пароли были заданы открытым текстом, а ваша установка LDAP/KRB5 добросовестно отбрасывает это, вам нужно либо дождаться смены пароля, либо нарушить основное правило и хотя бы временно хранить пароли в обратимой форме, предполагая, что у вас есть промежуточное ПО для отправки изменений паролей в OpenLDAP/Kerberos, которое вы можете инструментировать.
Я понимаю, что между ними возможно какое-то делегирование, но это не решит мою проблему? Или я могу сделать аутентификацию AD против MIT Kerberos KDC?
Это подход, который мы рассматриваем в данный момент. Аутентификация в Windows с использованием Kerberos Это известно как доверие между областями. Несколько важных вещей, которые следует отметить. Поиск типа шифрования, общего для всех областей, имеет решающее значение и обычно зависит от AD. Версия AD, которую вы используете, обычно диктует криптографию дня. Лучшее руководство по настройке, которое я нашел, на самом деле исходит от Microsoft:Пошаговое руководство по взаимодействию Kerberos для Windows Server 2003. Основная проблема, с которой я столкнулся, заключалась в том, как указать, какой тип шифрования использовать для межобластного доверия, о чем другие руководства, написанные давно, забыли упомянуть.
решение2
Было бы неплохо рассмотреть возможность использования решения, подобного тому, что приведено по ссылке ниже:
http://www.centrify.com/solutions/unix-linux-identity-management.asp
Что касается миграции, вы можете использовать систему типа PCNS для синхронизации паролей во время перемещения. Вы бы некоторое время запустили обе системы параллельно и провели бы несколько дней "все сбрасывают свои пароли", чтобы убедиться, что они синхронизированы перед перемещением. PCNS — НАМНОГО лучшее решение, чем Kerberos interop для того, что вы делаете.
PCNS (Password Change Notification Service) работает на контроллере домена и пересылает пароли на «цель», которая затем устанавливает пароль. Следующая ссылка объясняет, как это сделать.
http://technet.microsoft.com/en-us/library/bb463208.aspx
Если вы создаете новый лес AD, изучите настройки GPO безопасности ДО того, как вы его создадите. Таким образом, вы сможете начать максимально безопасно... Я говорю о версиях NTLM, подписи ldap и т. д.
решение3
Samba4 и freeipa могут позволить рабочим станциям Windows проходить аутентификацию. Вы рассматривали один из них.