Это один из моментов, которые стоит понять до установки.
Например:
DNS domain: infra.example.com
и Kerberos realm:
INFRA.EXAMPLE.COM
Realm — это пространство имён Kerberos. Именно его мы затем увидим в principal:
admin@INFRA.EXAMPLE.COM
FreeIPA обычно предлагает realm на основе DNS domain, записанный в верхнем регистре. Это логичная и рекомендуемая схема. Но технически DNS domain и realm — не одно и то же понятие. Поэтому:
DNS domain
≠
Kerberos realm
Перед установкой важно решить оба значения сознательно. Особенно потому, что realm — это не тот параметр, который хочется «переименовать потом».
7. Если планируется интеграция с Active Directory — думать о namespace нужно сразу
Представим, что уже существует:
AD: ad.example.com
А FreeIPA мы хотим развернуть как отдельный identity-контур. Тогда выбор DNS domain FreeIPA должен учитывать будущий trust и отсутствие конфликтов между пространствами имён. Нежелательно выбирать домен просто потому, что:
«так короче».
Правильнее спросить:
- — существует ли уже такая DNS-зона;
- — кто ею управляет;
- — не пересекается ли она с AD;
- — будет ли строиться trust;
- — как клиенты будут находить нужные сервисы.
Архитектура имён, которая выглядит безобидно на одном сервере, становится значительно важнее после появления второго identity-домена.
8. Нужно заранее решить: integrated DNS или внешний DNS
FreeIPA может работать в двух основных вариантах.
Вариант 1 — integrated DNS
FreeIPA управляет собственной DNS-зоной. Installer может настроить DNS вместе с остальными компонентами:
FreeIPA ├── LDAP ├── Kerberos ├── CA ├── HTTP/API └── DNS
Преимущество — тесная интеграция. FreeIPA может автоматически поддерживать необходимые служебные записи.
Вариант 2 — внешний DNS
DNS остаётся, например, на существующих корпоративных DNS-серверах. Тогда:
FreeIPA
↓
генерирует необходимые DNS records
↓
администратор размещает их
во внешнем DNS
Оба подхода рабочие. Но решение нужно принимать до установки, потому что оно определяет дальнейшую эксплуатацию. Integrated DNS удобен для самого FreeIPA. Но это не означает, что IPA DNS должен автоматически становиться универсальным DNS-сервисом всей организации.
9. Зачем FreeIPA нужны SRV-записи
Обычная запись:
ipa.infra.example.com → 192.0.2.10
говорит: где находится конкретный сервер. Но клиенту FreeIPA нужно узнавать другое: где находится LDAP? где находится Kerberos? Для этого используются DNS SRV records. Например:
_ldap._tcp.infra.example.com
и:
_kerberos._udp.infra.example.com
Проверить их можно через:
dig SRV _ldap._tcp.infra.example.com
dig SRV _kerberos._udp.infra.example.com
Смысл этой архитектуры:
клиент знает domain
↓
DNS сообщает сервис
↓
клиент находит IPA server
Поэтому DNS в FreeIPA выполняет не только обычное разрешение:
имя → IP
Он участвует в service discovery — автоматическом поиске нужных сервисов.
10. Время — тоже часть аутентификации
Kerberos чувствителен к расхождению системного времени. Поэтому до установки проверяем:
timedatectl
и, например:
chronyc tracking
Нас интересует не просто наличие chronyd.
Нас интересует результат:
время на сервере действительно синхронизировано?
То есть:
chronyd active
≠
время корректно синхронизировано
Это тот же принцип, который мы уже применяли к active (running).
Если часы клиента и KDC заметно расходятся, Kerberos-аутентификация начинает давать ошибки, которые на первый взгляд могут вообще не выглядеть как проблема времени.