КЕЙС #03 — FreeIPA: клиент подключён, но вход запрещён

Исходная ситуация:

ipa-client-install
→ успешно

Клиент отображается в FreeIPA. SSSD запущен:

systemctl status sssd

active (running)

Но при попытке подключения:

ssh user@client.example.ru

получаем отказ во входе. На первый взгляд возникает противоречие: клиент успешно включён в FreeIPA, почему доменная учётная запись не работает? Но:

ipa-client-install successful
        ≠
user login successful

Успешное подключение хоста к FreeIPA подтверждает только часть всей цепочки.

1. Сначала разделим вход пользователя на этапы

SSH-вход доменного пользователя — это не одна операция. Упрощённо:

SSH
 ↓
NSS
 ↓
SSSD
 ↓
FreeIPA
 ↓
Kerberos
 ↓
PAM
 ↓
HBAC
 ↓
user session

На разных этапах решаются разные вопросы. Например:

существует ли такой пользователь?

правильный ли у него пароль?

разрешено ли ему входить именно на этот host?

разрешён ли SSH как service?

может ли система создать пользовательскую сессию?

Поэтому сообщение:

Permission denied

само по себе ещё не является диагнозом.

2. Authentication и authorization — не одно и то же

Это особенно важно в FreeIPA. Authentication отвечает на вопрос: пользователь действительно тот, за кого себя выдаёт? Например:

user
 ↓ password
Kerberos
 ↓
ticket

Authorization отвечает уже на другой вопрос: имеет ли этот пользователь право выполнить конкретное действие? Например:

user authenticated
        ↓
можно ли ему войти
на client01 через sshd?
        ↓
HBAC

То есть совершенно возможна ситуация:

пароль правильный
        +
Kerberos работает
        +
вход по SSH запрещён политикой

Поэтому:

authentication successful
        ≠
login authorized

3. Начинаем не с SSH, а с DNS

FreeIPA очень сильно зависит от корректного DNS. На клиенте проверяем IPA-сервер:

getent hosts ipa.example.ru

и:

dig ipa.example.ru

Затем SRV-записи:

dig SRV _ldap._tcp.example.ru

dig SRV _kerberos._udp.example.ru

Нас интересует не просто: DNS вообще что-то отвечает. А:

получает ли клиент именно те адреса и сервисы, которые соответствуют нашей FreeIPA-инфраструктуре? Если клиент обращается не к тому DNS или получает старую запись, все дальнейшие симптомы могут выглядеть как проблема Kerberos или SSSD.

4. Проверяем время

Kerberos чувствителен к рассинхронизации часов. На клиенте:

timedatectl

и, например:

chronyc tracking

Нужно подтвердить:

System clock synchronized
→ yes

или эквивалентное состояние используемой службы времени. Важно:

chronyd active
        ≠
часы синхронизированы

Сервис может быть запущен, но иметь проблему с источниками времени.

5. Проверяем Kerberos отдельно от SSH

Попробуем получить билет:

kinit user@EXAMPLE.RU

Если успешно:

klist

покажет Ticket Granting Ticket. Например:

Default principal:
user@EXAMPLE.RU

krbtgt/EXAMPLE.RU@EXAMPLE.RU

Это очень сильная развилка диагностики. Если kinit не работает, пока рано искать проблему в sshd. Проблема находится ниже:

DNS
Kerberos
credentials
KDC
time

Если kinit работает:

Kerberos authentication
→ подтверждена

Идём дальше.

6. Но успешный kinit ещё не означает, что Linux знает пользователя

Следующий уровень — получение identity information. Проверяем:

getent passwd user

или:

id user

Ожидаем примерно:

uid=123456(user)
gid=123456(user)
groups=...

Если kinit работает, а:

id user

возвращает:

no such user

то пароль и Kerberos здесь уже не главные подозреваемые. У нас другая цепочка:

Linux
 ↓
NSS
 ↓
SSSD
 ↓
FreeIPA directory

И именно она не даёт системе получить информацию о пользователе.

7. Зачем здесь NSS

NSS — Name Service Switch. Он определяет, откуда Linux получает информацию о:

• пользователях;
• группах;
• именами хостов и других сущностях.

Для пользователя приложение может запросить:

кто такой user?

и система через NSS передаст запрос SSSD. Упрощённо:

id user
   ↓
NSS
   ↓
SSSD
   ↓
FreeIPA

Поэтому:

Kerberos ticket есть
        ≠
NSS обязательно видит пользователя

Это разные механизмы.