Линукс Док

Вход в домен: варианты подключения

SSSD

Автор: Летописец, Дата: 2026-10-18

Подключить ноутбук к домену можно четырьмя способами. Разница между ними — кто заводит машинную учётную запись и кто настраивает SSSD: либо за вас это делает realm, либо вы делаете оба шага руками.

Ниже — от самого простого к самому ручному. Для ноутбука в AD первым способом и стоит ограничиться.

Что вообще происходит при подключении

Полезно понимать, что именно меняется в системе — тогда ошибки перестают быть загадочными:

  1. в домене создаётся учётная запись компьютера (laptop-name$) — это и есть «машина в домене»;
  2. её пароль сохраняется в keytab /etc/krb5.keytab (файл читает только root);
  3. в /etc/sssd/sssd.conf появляется секция домена;
  4. в /etc/krb5.conf — домен Kerberos (если ещё не было);
  5. в /etc/nsswitch.conf к строкам passwd и group добавляется sss;
  6. SSSD запускается и начинает отдавать доменных пользователей системе.

Всё остальное — варианты того, кто делает шаги 1–6.

Способ 1: realm — подключение одной командой

Так работает по умолчанию в Ubuntu и Debian: realmd находит домен, спрашивает у него параметры, сам зовёт нужный механизм (adcli для AD), сам пишет sssd.conf и запускает службу.

$ sudo apt install realmd sssd-ad sssd-tools adcli

Шаг 1 — разведка. Ничего не меняет, только смотрит, видно ли домен в сети:

$ realm discover example.com
example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  ...
  login-formats: %U@example.com
  login-policy: allow-realm-logins

Если тут пусто — дальше идти нет смысла: проблема в сети или DNS, а не в SSSD. Домен ищется через DNS по записям _kerberos._tcp (SRV), поэтому нужен DNS домена, а не только его IP.

Шаг 2 — подключение. Учётка должна иметь право заводить компьютеры в домене:

$ sudo realm join --user=admin example.com
Password for admin@EXAMPLE.COM:

Шаг 3 — проверить, что вышло:

$ realm list
$ getent passwd user@example.com
$ id user@example.com
$ sudo systemctl status sssd | head -5

Шаг 4 — домашний каталог при первом входе. По умолчанию доменный пользователь входит в систему без своего каталога. Чтобы он создавался:

$ sudo pam-auth-update --enable mkhomedir

Выход из домена (машина навсегда уходит из домена — например, списываемый ноутбук):

$ sudo realm leave example.com
$ sudo adcli delete-computer --domain=example.com --login-user=admin

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

Способ 2: adcli + SSSD вручную

То же самое, но без realmd: вы сами пишете sssd.conf, а adcli заводит машинную учётку. Так делают, когда нужен нестандартный конфиг или когда realmd не понимает хитрый домен.

$ sudo apt install sssd-ad sssd-tools adcli

# 1. Завести машинную учётку и получить keytab
$ sudo adcli join example.com --login-user=admin --domain-controller=dc1.example.com

# 2. Написать конфиг (подробно — в «SSSD и Active Directory»)
$ sudo tee /etc/sssd/sssd.conf >/dev/null <<'EOF'
[sssd]
config_file_version = 2
services = nss, pam
domains = example.com

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM
EOF

# 3. Права и запуск
$ sudo chmod 600 /etc/sssd/sssd.conf
$ sudo systemctl enable --now sssd

Машинная учётка уже есть в keytab, поэтому отдельно kinit для машины не нужен.

Способ 3: каталог LDAP без машинной учётки

Если домена Active Directory нет, а есть просто LDAP-каталог (или AD, но без прав заводить компьютеры), подключаются иначе: машинной учётки нет, а SSSD ходит в каталог служебной учётной записью и ищет пользователей в дереве.

$ sudo apt install sssd-ldap sssd-tools

Ключевые настройки (полностью — в «SSSD и LDAP»):

[domain/ldap.example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=sssd-reader,ou=services,dc=example,dc=com
ldap_default_authtok = <пароль служебной учётки>
ldap_id_use_start_tls = true

Разница принципиальная: здесь никто не «входит в домен» — машина просто читает каталог. Значит, нет ни машины в домене, ни единого входа через Kerberos: пароль каждый раз проверяется в LDAP.

Способ 4: FreeIPA

Если в инфраструктуре FreeIPA (это AD-подобный каталог на 389 Directory Server), то подключают его клиентом:

$ sudo apt install freeipa-client
$ sudo ipa-client-install --domain=example.com --server=ipa.example.com

Клиент сам настраивает SSSD, Kerberos и NSS — это аналог realm join для IPA. В настройки SSSD лучше не лезть руками: ipa-client-install перезапишет. Значения попадут в /etc/sssd/sssd.conf с id_provider = ipa.

Как выбрать

Ситуация Способ
Домен Active Directory, обычный ноутбук realm (1)
AD, нужен нестандартный конфиг SSSD adcli + вручную (2)
Каталог LDAP, машинных учёток нет sssd-ldap (3)
Инфраструктура FreeIPA ipa-client-install (4)
Домен без DNS-записей SRV, только по IP вручную (2) + ad_server в конфиге

Что чаще всего ломается

Почти все сбои подключения — не про SSSD, а про три вещи вокруг него:

DNS. Домен ищется по SRV-записям. Если resolvectl status не показывает доменный DNS, realm discover молчит, а kinit пишет «Cannot find KDC». Проверять сначала это.

Время. Kerberos не терпит расхождения часов больше пары минут. Ноутбук после сна — обычный источник «не пускает в домен»:

$ timedatectl
$ sudo systemctl restart systemd-timesyncd

Права на sssd.conf. Файл должен быть 600, иначе служба не стартует, а в журнале — малопонятная строка про permissions.

Проверка подключения — по шагам

# 1. Домен виден
$ realm discover example.com

# 2. Машина в домене (для способов 1 и 2)
$ sudo klist -k /etc/krb5.keytab | head

# 3. Пользователи приходят в систему
$ getent passwd user@example.com && id user@example.com

# 4. Пароль проверяется доменом
$ kinit user@example.com && klist

# 5. Вход целиком, как у человека за экраном
$ su - user@example.com

# 6. Что видит сам SSSD
$ sudo sssctl domain-status example.com
$ sudo sssctl user-checks user@example.com

Если что-то не сходится — журнал, а не догадки:

$ sudo journalctl -u sssd -n 50 --no-pager
$ sudo tail -n 50 /var/log/sssd/sssd_example.com.log

Источники

  • man 8 realm — пакет realmd 0.17.1-3build3; man 1 adcli — adcli 0.9.2-1ubuntu3 (проверено 18.10.2026).
  • man 5 sssd.conf, man 5 sssd-ad, man 5 sssd-ldap — пакет sssd-common 2.12.0-1ubuntu5.5.
  • man 5 nsswitch.conf, man 8 pam-auth-update, man 8 pam_mkhomedir — подключение к NSS и PAM.
  • Репозиторий проекта: https://github.com/SSSD/sssd

Что ещё не проверено

  • Порядок и команды сверены с man-страницами, но на живом домене не выполнялись: своего AD или LDAP у нас нет. На рабочем домене первым делом проверить realm discover и klist -k, а дальше по шагам выше.
  • Права учётной записи на подключение компьютера (ms-DS-MachineAccountQuota в AD) зависят от политики домена — это к администратору домена, не к SSSD.
Оценка статьи 0

Смотрите также

Комментарии

Пока комментариев нет.