company_banner

Настройка репликации во FreeIPA 4.4 с domain level 1

  • Tutorial
image

У нас в компании для организации и управления доступами для Linux-серверов
используется такой сервис как FreeIPA. FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL. В новой версии появились уровни доменов и был переработан процесс настройки репликации. Так как инструкций вменяемого вида в рунете найти не удалось, я решил написать собственную.

Для начала нам понадобится два сервера с CentOS 7. Сервера будут такие:

ipamaster.org.lan  	ip 192.168.10.23
ipareplica0.org.lan	ip 192.168.10.123

На каждом сервере вносим в /etc/hosts адреса мастера и реплики. В нашем случае это:

192.168.10.23	ipamaster.org.lan
192.168.10.213  ipareplica0.org.lan

Дальше на мастере устанавливаем необходимые пакеты. В нашем случае мы используем сервера FreeIPA как DNS-сервера. Поэтому устанавливем и пакет DNS-сервера:

yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns

После установки пакетов необходимо установить сам сервер FreeIPA. Для автоматизации установки ipa-server-install поддерживает множество ключей, которые позволяют в автоматическом режиме ответить на все вопросы инсталлятора. Мы же в данный момент пройдёмся руками по каждому полю с описанием. Так же ничего не мешает выполнить ipa-server-install -h и составить нужный набор ключей.

Итак установка сервера:

ipa-server-install --setup-dns --mkhomedir

Ключ --setup-dns говорит о том, что мы будем использовать DNS-сервер; ключ --mkhomedir нужен, чтобы на клиентах для каждого пользователя автоматически создавалась home директория.

Далее отвечаем на вопросы.

1. Имя хоста должно быть прописано в хост и резолвится. Оставляем как есть.

Server host name [ipamaster.org.lan]:

2. Доменное имя тоже оставляем как есть.

Please confirm the domain name [org.lan]:

3. Realm name тоже без изменений.

Please provide a realm name [org.lan]:

4. Пароль для менеджмента лдап-директорий нужен сложный. И не потерять.

Directory Manager password: q1w2e3r4t5y6
Password (confirm): q1w2e3r4t5y6

5. Пароль администратора самого сервиса.

IPA admin password: 1234567890

6. Указываем dns forwarders, к примеру, на гугловые сервера. Чтобы закончить указывать форвардеры, достаточно в пустой строке нажать ENTER.

Do you want to configure DNS forwarders? [yes]:
Do you want to configure these servers as DNS forwarders? [yes]:
All DNS servers from /etc/resolv.conf were added. You can enter additional addresses now:
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.8.8
DNS forwarder 8.8.8.8 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip: 8.8.4.4
DNS forwarder 8.8.4.4 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip:
Checking DNS forwarders, please wait…

7. Разрешаем реверс зону.

Do you want to search for missing reverse zones? [yes]:
Do you want to create reverse zone for IP 192.168.10.23 [yes]:
Please specify the reverse zone name [10.168.192.in-addr.arpa.]:
Using reverse zone(s) 10.168.192.in-addr.arpa.

8. Дальше нам выводят данные для проверки. Проверяем, продолжаем.

The IPA Master Server will be configured with:
Hostname:	ipamaster.org.lan
IP address(es):	192.168.10.23
Domain name:	org.lan
Realm name: 	ORG.LAN

BIND DNS server will be configured to serve IPA domain with:
Forwarders:	8.8.8.8, 8.8.4.4
Forward policy:	only
Reverse zone(s):  10.168.192.in-addr.arpa.
Continue to configure the system with these values? [no]: yes

Начинается довольно долгий процесс установки. Одна из самых долгих частей это генерация сертификатов, так что можно сходить попить чаю.

В финале установки нам покажут какие порты используются. Настраиваем фаерволл, чтобы он принимал соединения на этих портах. В нашем случае тестовое окружение и все друг другу доверяют.

1. You must make sure these network ports are open:
TCP Ports:
* 80, 443: HTTP/HTTPS
* 389, 636: LDAP/LDAPS
* 88, 464: kerberos
* 53: bind
UDP Ports:
* 88, 464: kerberos
* 53: bind
* 123: ntp

Можем зайти в веб-интерфейс, проверить работу.

image

Убедились, что всё работает. Теперь переходим к повышению уровня домена. Нам необходимо пройти по вкладкам IPA SERVERS → Topology. Где нас сразу предупреждают, что СА-серверов должно быть больше одного.

image

Отвечаем ОК. И проверяем уровень домена на вкладке Domain Level. Если это свежая установка, он по умолчанию будет 1.

ВНИМАНИЕ! Если вы это делаете на проде, то повышение уровня домена без предварительной подготовки может всё сломать. Делайте это только в том случае, когда понимаете зачем и как.

После этих операций переходим к настройки реплики. И вот тут начинаются отличия от старых механизмов. Если раньше нужно было генерировать ключи, переносить на реплику и делать множество телодвижений, то теперь всё значительно проще.

Итак проверяем что реплика берёт днсы с мастера.

cat  /etc/resolv.conf
search org.lan
nameserver 192.168.10.23

Теперь устанавливаем ipa-client.

yum -y install ipa-client ipa-server-dns

После этого устанавливаем и настраиваем клиента. Тут такая же история как с сервером — есть куча ключей для автоматизации, поэтому выполняем.

/usr/sbin/ipa-client-install -d --mkhomedir --domain=org.lan --server=ipamaster.org.lan --realm=ORG.LAN --principal=admin --password=1234567890  --enable-dns-updates -U

После этого хост должен появиться в веб-интерфейсе.

image
Дальше переходим к настройке репликации. Выполняем.

Ipa-replica-install

У нас попросят пароль админа. Вводим, жмем ENTER.

WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd
 
Password for admin@ORG.LAN:

Далее дожидаемся установки и настройки репликации. После завершения можно зайти на ipareplica0.org.lan там в IPA SERVERS → Topology → Topology Graph мы увидим, что реплика появилась и реплицируется только доменная часть.

image

Но мы также помним про назойливое упоминание, что СА-сервер один и что нам нужен резервный днс. Переходим к настройке днс-сервера на реплике.

Ipa-dns-install

И по аналогии с мастером разрешаем форвардеров. Если вдруг наша реплика находится в другом регионе, можно указать другие форвардеры.

После этого переходим к установке СА сервера.

Ipa-ca-install

Тут у нас спросят наш Directory Manager password. Вы ведь его ещё не потеряли?

Directory Manager (existing master) password: q1w2e3r4t5y6

Это займет довольно много времени, поэтому ждём. После завершения идём на любой веб-интерфейс и проверяем топологию. Пропало назойливое сообщение о том, что СА в единственном экземпляре. И появилась новая связь в графике топологий.

image

Как видим, теперь всё относительно отказоустойчиво. Масштабирование в новой версии стало гораздо более простым и понятным.

Теперь пару слов о том, что стоит не забывать мониторить. Мы мониторим запущенные процессы, открытые порты и самое главное мониторим срок действия корневого СА-сертификата. Потому как в случае, если он прострочится, может возникнуть куча ручной волокиты которая никому не нужна.

Ну и ссылки на официальную документацию:

www.freeipa.org/page/V4_Designs
www.freeipa.org/page/V4_Proposals

Pixonic

143,86

Международная компания по разработке мобильных игр

Поделиться публикацией
Комментарии 18
    0
    И это работает? Просто у меня на клиентах аутентификация отваливается, если основной сервер погасить. Более того, я в конфигах клиента не нашел вообще никакого упоминания реплики. Если вручную его туда поместить — все начинает работать.
      +2
      Ну так при установки клиента указывается 2 опции сервер.
      Или /etc/sssd/sssd.conf Там опция ipa_server = _srv_, server1, serevr2
      Что говорит о том что вначале смотрим DNS потом идём по списку серверов.
      Тестировалось неоднократно.
        +1
        А, то есть нужно вручную указывать все сервера? Я делал ipa-client-install без параметров, он только первый сервер подхватывал из днс, хотя там оба прописаны.
          +1
          У нас клиент ставится ансиблом примерно вот такой командой
          /usr/sbin/ipa-client-install
               --mkhomedir
               --domain={{ domain }}
               --server={{ ipa_server }}
               --server={{ ipa_slave }}
               --realm={{ realm }}
               --principal={{ ipa_adm }} 
               --password={{ ipa_adm_pass }}
               --hostname={{ansible_fqdn}}
               --enable-dns-updates  -U
               --force-join
          

          И ни разу проблем с авторизацией не было.
          Если очень нужно могу посмотреть позже.
            0
            Нет, спасибо. Я вручную правил конфиг — тоже все работает. Посмотрю при установке клиента ваш способ с параметрами.
              0
              А у вас точно днсы смотрят на сервера ипы?
              И в днсах SRV записи в корневой зоне содержат по 2 сервера?
                0
                Да, возможно здесь затык. ДНС у меня отдельный, записи прописывал вручную. Может не верно прописал? Можете показать записи в зоне ipa, kerberos и ldsp?
                  +2
                  Вот так
                    0
                    Благодарю. Буду править свою конфигурацию.
      +1
      Спасибо за то что делитесь опытом.
      Бывают мелочи, на которых спотыкаешься.

      Как насчет?
      «FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL.»

      У себя пробую FreeIPA + Ubuntu 16.04. Пока особых проблем не огреб :-)
        0
        >«FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL.»
        Это опен-соурс проект, спонсируемый Red Hat.
        В RHEL есть похожий коммерческий продукт.
        По-видимому, автор имел в виду Red Hat, не RHEL.
        0
        Всегда рады помочь.
        В нашем случае FreeIPA заменяет АД практически полностью. Некоторый функционал пришлось допиливать самими конечно, но в целом оно так.

        Убунты мы не используем не могу сказать про подводные камни.
          +1
          Спасибо за статью! Не хотите написать продолжение? Очень интересно почитать на основании реального опыта использования, насколько «замена AD» — реальность.

          В частности, интересуют такие стандартные примеры использования AD:
          • аутентификация пользователя без ввода пароля в связке браузер+веб сервер
          • аутентификация от имени пользователя без ввода пароля в базе данных по цепочке браузер->веб сервер->СУБД
          • аутентификация от имени пользователя без ввода пароля по цепочке браузер->веб сервер->файл-сервер
          • использование сертификатов/смарт-карт/TPM наравне с паролем
          • аутентификация пользователя без ввода пароля в системах телефонии (PBX)
          • аутентификация пользователя без ввода пароля на серверах IM (например, OpenFire)

          Если нет времени/желания писать статью, не могли бы вы ответить хотя бы да/нет/не пробовали по каждому пункту?

          Документацию по ссылке просмотрел, но она какая-то маркетинговая, что ли: обещают «Single Sign On из всех приложений», но по ссылке вместо подробностей — просто констатация того, что у них реализован Kerberos.
            +2
            Продолжение в планах.
            У нас нет клиентских пк с линуксом поэтому для пользовательского кербероса мы не особо используем это.
            Наши основные направления это:
            — Централизация всей инфраструктуры. У нас всё береётся из FreeIPA в том числе инвентори для Ансибла. Группы для заббикса и всякие авторизации средствами лдапа
            — Актуализация и динамическое обновление днсов. WIN машины туда добавляются скриптом.

            Керберосом особо не пользуемся в продакшне. На тестовом стенде нормально работал керберос + ОТП.
            0
            Хоть и год прошел, но может кто-то ответит.
            Тестим связку FreeIPA + Win AD. Хотим всех пользователей/группы хранить в АД, а в IPA настраивать только HBAC. На данный момент эта пара серверов (виндовый контроллер и сама freeipa) работают, но возникла пара вопросов:
            Как подобную репликацию провернуть в случае с настроенным трастом между доменом IPA и виндовым? Нужно ли каждую реплику трастить с виндовым доменом? Или отказоустойчивость при виндовом трасте организуется другим образом?
            И вторая проблема — кэш sssd. Получается, что их два — один на сервере freeipa и один на клиентах. В случае обновления данных в виндовом АД, на клиентах они обновляются очень долго, либо могут вообще не обновиться (замечено на убунтах). Команды инвалидации кэша не помогают, приходится удалять кэш и на сервере freeipa, и на самих клиентах. Как это можно решить?
              +1
              Я трастил каждую реплику. В ипе есть экстернал группы которые могут приходить из виндового домена которому доверяют.
              С кешом такая пролема наблюдается только в случае работы с дебиан подобными системами. Как лечить сказать не могу у нас везде центось. Но где-то в рассылках было обсуждение, тут только гугл поможет.
                0
                Спасибо за ответ. Попробуем трастить каждую реплику. Настройка реплик, как я понимаю, в остальном не отличается?
                Про sssd — пытался гуглить, но утонул в почтовых рассылках. Очень неудобная коммуникация у проекта). Игра с опциями кэширования пока тоже не дала удовлетворительного результата.
                Есть еще один момент про Убунты — в релизах вплоть до 16.04 идет очень старая версия пакета. Нам нужна была фича с short names (чтобы вводить логин без доменного суффикса), но пришлось руками собирать пакеты и обновлять sssd
                  0
                  Трастить каждую реплику нужно для отказоустойчивости.
                  Про кеши, будет время посмотрю на убуне

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое