Я хочу развернуть FreeIPA или Red Hat IdM в моей существующей среде
В настоящее время мой домен управляется MS AD, который контролируется отдельной группой. Предположим, что изменить что-либо в MS AD будет сложно или невозможно по политическим причинам.
Для Linux я недавно настроил системы для использования парольной аутентификации Kerberos, предоставляемой непосредственно MS AD, с использованием SSSD в Enterprise Linux. Идентификационная информация по-прежнему предоставляется в локальной системе.
Моя самая большая проблема сейчас - выяснить, как предложить новое пространство доменных имен.
Могу ли я использовать субдомен нашего домена MS AD и передать управление им FreeIPA?
Я думаю, что может быть желательно, чтобы конфигурации Kerberos указывали непосредственно на MS AD, это уже чрезвычайно устойчиво, почему бы не воспользоваться существующей инфраструктурой? Но принесет ли это мне больше хлопот, чем оно того стоит? Я не уверен, как все будет интегрировано.
Учтите это:
Наш стандарт именования хостов выглядит примерно так: app-id-dev / prd.domain.com. Так, например: «server01dev.domain.com»
Согласно политике мы не дублируем идентификатор сервера между средами dev / prd, поэтому я подумал, что отличный способ использовать поддомены - это преобразовать предыдущий пример в «server01.dev.domain.com». Приятной особенностью этого может быть то, что при указании короткого имени хоста нам больше не нужно указывать dev / prd, если наш порядок поиска домена правильно настроен на клиенте.
Воспринимаемое преимущество: это позволило бы мне стать центром сертификации для этих поддоменов. Это должно упростить все, что связано с сертификатами в будущем.
Воспринимаемый недостаток: что это означает для аутентификации? Я по-прежнему хочу, чтобы пользователи аутентифицировались с использованием имени пользователя, которое уже существует в исходном домене. Пример: user0321@DOMAIN.COM, а не user0321@DEV.DOMAIN.COM
Еще одно сомнение, которое у меня есть, заключается в том, есть ли какой-либо смысл в использовании MS AD Kerberos напрямую, потому что, если информация об идентификаторе недоступна из FreeIPA LDAP, это все равно будет препятствовать правильному входу пользователя в систему, если у него нет локального идентификатора в клиентской системе.
Если это реальная проблема, это заставляет меня задаться вопросом, можно ли синхронизировать информацию FreeIPA LDAP с AD, но тогда я думаю, что пользователи должны быть созданы в субдомене.
Или мне следует отказаться от идеи использования MS AD напрямую для обеспечения отказоустойчивости и согласиться с тем, что мне нужно создать отказоустойчивую среду FreeIPA / RH IdM?
Во-первых, я буду использовать FreeIPA и Red Hat Enterprise IdM как взаимозаменяемые. Если это вызывает дискомфорт, позвольте предложить выпить.
FreeIPA должен быть отдельной областью Kerberos от Active Directory и должен использовать отдельную зону DNS, соответствующую области Krb5. Если ваш домен AD использует зону DNS «domain.com» с дочерними зонами «dev» и «prd», вам нужно создать новую зону DNS с названием что-то вроде «idm.domain.com», а также любые суб-области под Это. Вы хотите создать область Krb5 под названием «IDM.DOMAIN.COM» со всеми UPN как USER@IDM.DOMAIN.COM и все SPN как HOST / SERVER123.IDM.DOMAIN.COM или тому подобное (возможно WWW / SERVER123.PRD.IDM.DOMAIN.COM).
Вы можете использовать ту же зону DNS, что и AD, но это ДЕЙСТВИТЕЛЬНО плохая идея. Вы не только потеряете обнаружение службы с помощью DNS, вам придется выполнять сопоставления вручную и, вероятно, будут возникать проблемы с устранением неполадок клиентов, пытающихся передать токен Krb, который не подходит серверам в области IdM.
Вам нужно будет хотя бы кратко поработать с командой AD, чтобы они установили межсферное доверие. Они могут захотеть, чтобы это было одностороннее доверие, где AD - это доверенный домен, а FreeIPA - это доверенный домен. В большинстве случаев это не должно быть проблемой.
В настоящее время версия FreeIPA, поставляемая с RHEL 7, не поддерживает установление доверия с доменом AD на вершине леса и переход вниз к дочерним доменам для аутентификации. В RHEL 7u1 мне сказали, что это будет исправлено, поскольку в FreeIPA будет добавлена поддержка транзитивного доверия, но я не задерживаю дыхание, пока не увижу список функций через день после замораживания кода. В качестве временного решения вы должны иметь возможность настроить доверие к дочернему домену, в котором создаются участники-пользователи.
Я работаю над аналогичным усилием. Удачи, дайте нам знать, как это работает. Мне посчастливилось иметь команду AD в качестве элемента моей команды (а они сидят прямо напротив меня). Мы объединяемся с одним и тем же лидером на уровне команды (подразделение размером с отряд), и у нас есть большая поддержка со стороны руководителя нашего подразделения, который хочет, чтобы эта интеграция была успешной.