Ввод компьютера debian в домен windows

Для упрощения добавления Ubuntu или Debian в домен Active Directory вместо связки samba+winbind можно использовать пакет realmd (Realm Discovery), который позволяет автоматически настроить службу SSSD (System Security Services Daemon) в Linux. Эта статья применима для Ubuntu 20.04/22.04 и Debian 10/11.

Прежде всего обновите пакеты на вашем хосте Linux:

$ sudo apt -y update

Выведите текущее имя хоста:

$ hostnamectl

Если нужно, измените имя хоста:

$ sudo hostnamectl set-hostname ubnt22.vmblog.ru

Проверьте, что в Linux корректно настроен клиент DNS и он указывает на ваши контроллеры домена AD:

# cat /etc/resolv.conf

nameserver 192.168.42.10
nameserver 192.168.142.10
search vmblog.ru

Т.к. пакет SSSD используется Kerberos для аутентификации, убедиться, что у вас корректно настроен NTP клиент и настроена синхронизация времени с контроллерами домена AD. Можно настроить так:

$ sudo systemctl status systemd-timesyncd
$ sudo nano /etc/systemd/timesyncd.conf

NTP=192.168.42.10

$ sudo systemctl restart systemd-timesyncd

Установите необходимые пакеты:

$ apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Проверьте, что ваш хост может обнаружить домен AD:

$ realm discover vmblog.ru --verbose

vmblog.ru
type: kerberos
realm-name: VMBLOG.RU
domain-name: vmblog.ru
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin

Вы можете задать атрибуты вашего хоста Linux, которые нужно сохранить в учетной записи компьютера в Active Directory (атрибуты operatingSystem и operatingSystemVersion):

$ nano /etc/realmd.conf

[active-directory]
os-name = Ubuntu GNU/Linux
os-version = 22.04 (Jammy Jellyfish)

Для добавления Linux хоста в домен Active Directory вам понадобится учетная запись AD с правами администратора домена (или пользователь, которому делегированы права на добавление компьютеров в домен).

В самом простом случае для добавления хоста Ubuntu/Debian в домен достаточно выполнить команду:

$ sudo realm join -U apetrov vmblog.ru

Введите пароль доменного пользователя.

По умолчанию для вашего хоста Linux будет создана учетная запись компьютера AD в корневом OU (Organizational Unit) с именем Computers. Вы можете сразу поместить вам хост в нужную OU. Для этого используйте другую команду добавления в домен:

$ sudo realm join --verbose --user=apetrov --computer-ou="OU=Linux Servers,OU=HQ,DC=vmblog,DC=ru" vmblog.ru

Проверьте, что ваш хост теперь находится в домене AD:

$ sudo realm list

type: kerberos
realm-name: VMBLOG.RU
domain-name: vmblog.ru
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U@vmblog.ru
login-policy: allow-realm-logins

Чтобы автоматически создавать домашний каталог пользователям, выполните:

sudo bash -c "cat > /usr/share/pam-configs/mkhomedir" <<EOF
Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
required pam_mkhomedir.so umask=0022 skel=/etc/skel
EOF

$ sudo pam-auth-update

Выберите пункт activate mkhomedir.

Картинка с сайта: vmblog.ru

Проверьте конфигурацию sssd в файле:

$ cat /etc/sssd/sssd.conf

Чтобы применить изменения из файла sssd.conf, нужно перезапустить службу:

$ systemctl status sssd

Теперь вы может выполнить аутентификацию в Linux с помощью учетной записи Active Directory (указывается в формате UPN: user@vmblog.ru).

Проверьте, что вы можете получить информацию о пользователе AD:

$ id apetrov@vmblog.ru

Можно переключиться на пользователя:

su - apetrov@vmblog.ru

Creating directory '/home/apetrov@vmblog.ru'.
apetrov@vmblog.ru@ubnt22:~$

Чтобы разрешить доменным пользователям вход на хост Linux (консоль+SSH), выполните:

$ realm permit apetrov1@vmblog.ru ivanov2@vmblog.ru

Или разрешить доступ для пользователей доменных групп безопасности:

$ ream permit -g LinuxAdmins@vmblog.ru

Чтобы разрешить, запретить доступ всем пользователям домена:

$ sudo realm permit --all
$ sudo realm deny --all

Вы можете разрешить определенным пользователям и группам повышать привилегии с помощью sudo. Создайте файл:

$ sudo nano /etc/sudoers.d/linux-admins

Добавьте в него пользователей и/или группы, которым разрешено sudo:

%LinuxAdminx@vmblog.ru ALL=(ALL) ALL
aivanov@vmblog.ru ALL=(ALL) ALL

Измените права на файл:

$ chmod 0440 /etc/sudoers.d/linux-admins

Теперь попробуйте аутентифицироваться на вашем Linux хосте с доменной учетной записью.

Процесс добавления rpm-based дистрибутивов (CentOS/Rocky Linux/RHEL/Fedora) в домен Active Directory немного отличается и описан в отдельной статье.

unix-linux:debian:bookworm:join-debian-linux-12-bookworm-to-active-directory-domain-with-sssd-realmd-with-ad-security-group-authorization-in-pam-for-console-login-and-ssh-sso-putty-kerberos-auth

# hostname KOM-SRV01.sub.holding.com

# apt-get install realmd sssd-tools sssd libnss-sss libpam-sss adcli packagekit -y

# realm discover sub.holding.com --verbose

 * Resolving: _ldap._tcp.sub.holding.com
 * Performing LDAP DSE lookup on: 10.5.1.4
 * Performing LDAP DSE lookup on: 10.6.0.4
 * Successfully discovered: sub.holding.com
sub.holding.com
  type: kerberos
  realm-name: SUB.HOLDING.COM
  domain-name: sub.holding.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

# realm join --verbose --user=adm-petya \
 --user-principal="host/kom-srv01.sub.holding.com@SUB.HOLDING.COM" \
 --computer-ou="OU=Linux Servers,OU=KOM,DC=sub,DC=holding,DC=com" \
 kom-dc01.sub.holding.com

...
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

# apt-get install krb5-user -y

# klist -e -k -t /etc/krb5.keytab

# nano /etc/sssd/sssd.conf

# sss_cache -E
# ( systemctl stop sssd ) && \
 ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* ) && \
 ( systemctl start sssd )

# getent group kom-servers-admins@sub.holding.com

# id adm-petya
# getent passwd adm-petya

# nano /etc/security/access-groups-to-login

# chown root:root /etc/security/access-groups-to-login
# chmod 600 /etc/security/access-groups-to-login

# journalctl -f | grep login

# journalctl -f -u ssh.service

# chown root:root /etc/security/access-users-to-login
# chmod 600 /etc/security/access-users-to-login

# nano /etc/sudoers.d/kom-srv-linux-admins

# chmod 0440 /etc/sudoers.d/kom-srv-linux-admins

Интеграция Linux-серверов в домен Windows Active Directory (AD) позволяет централизованно управлять пользователями и упростить аутентификацию. В этой статье мы рассмотрим, как добавить Debian в домен Windows AD, используя realmd и SSSD.

Описание используемых служб:

• Realmd (Realm Discovery) – сервис D-Bus, позволяющий производить настройку сетевой аутентификации и членства в домене (Active Directory) без сложных настроек. Информация о домене обнаруживается автоматически. Для аутентификации и проверки учетных записей realmd использует SSSD (через Kerberos и LDAP) или Winbind.
• SSSD (System Security Services Daemon) — это клиентский компонент централизованных решений для управления идентификацией, таких как Microsoft Active Directory, Kerberos, OpenLDAP  и других серверов каталогов. SSSD обслуживает и кэширует информацию, хранящуюся на удаленном сервере каталогов, и предоставляет услуги идентификации, аутентификации и авторизации хост-машине.

Исходные данные:

• Контроллер домена (DC1) на Windows Server 2019, домен JAKONDA.LOCAL (IP — 192.168.1.100)
• Linux система (debian) на Debian 11 Bullseye (IP — 192.168.1.10)

Подготовка системы

Перед началом убедитесь, что ваша система Debian обновлена:

apt-get update && apt-get upgrade -y

Указываем FQDN (Fully Qualified Domain Name) имя системы, в файле /etc/hostname:

debian.jakonda.local

Файл /etc/hosts приводим к виду таким образом, чтобы в нём была запись с полным доменным именем компьютера и с коротким именем, ссылающаяся на один из внутренних IP хоста:

127.0.0.1	localhost
192.168.1.10	debian.jakonda.local debian

Настраиваем клиент DNS на хосте. Файл /etc/resolv.conf приводим к виду с учетом ваших данных:

domain jakonda.local
search jakonda.local
nameserver 192.168.1.100

Настройка синхронизации времени

Для корректной аутентификации по протоколу Kerberos необходимо синхронизировать время сервера и клиента. Если системные часы расходятся более чем на 5 минут, то аутентификация не будет выполнена.

Установим NTP сервер и выполним синхронизацию времени с контроллером домена:

apt-get install ntp ntpdate -y

ntpdate dc1.jakonda.local

Установка необходимых пакетов

Устанавливаем необходимые пакеты:

apt-get install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit -y

Проверка доступности домена

Проверим, доступен ли домен для обнаружения через DNS:

realm discover jakonda.local -v

 * Resolving: _ldap._tcp.jakonda.local
 * Performing LDAP DSE lookup on: 192.168.1.10
 * Successfully discovered: jakonda.local
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: no

Команда realm discover возвращает полную конфигурацию домена и список пакетов, которые необходимо установить, чтобы система была зарегистрирована в домене.

Предварительная настройка

Перед вводом в домен, можно настроить realmd переопределив настройки по-умолчанию. Это делается путем размещения настроек в файле /etc/realmd.conf¹.

Настройки в этом файле применяются только в момент присоединения к домену или области.

Для примера зададим атрибуты системы для объекта компьютера в Active Directory (атрибуты operatingSystem и operatingSystemVersion) и укажем в какую OU поместить объект:

[active-directory]
os-name = Debian GNU/Linux
os-version = 11.8 (Bullseye)

[jakonda.local] 
computer-ou = OU=Linux Computers,DC=jakonda,DC=local

Ввод в домен

Для ввода системы в домен выполните команду:

realm join jakonda.local -U Administrator
Password for Administrator:

Замените Administrator на учетную запись с правами на добавление компьютеров в домен.

Проверим, что система находится в домене:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@jakonda.local
  login-policy: allow-realm-logins

Инструмент realmd после ввода системы в домен, создает файл конфигурации — /etc/sssd/sssd.conf:

[sssd]
domains = jakonda.local
config_file_version = 2
services = nss, pam

[domain/jakonda.local]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = JAKONDA.LOCAL
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = jakonda.local
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Этих параметров достаточно для авторизации доменных пользователей в системе.

Важно помнить, что файл /etc/sssd/sssd.conf должен иметь разрешения 600 и root:root, иначе демон sssd не будет запускаться.

В случае внесения каких то изменений в файл конфигурации, то после этого всегда необходимо перезапускать SSSD:

Проверка работы

Проверим, что учетные записи из домена доступны. Получим информацию о доменном пользователе — jakonda@jakonda.local.

getent passwd jakonda@jakonda.local
jakonda@jakonda.local:*:1851201887:1851200513:Jakonda:/home/jakonda@jakonda.local:/bin/bash

Проверим в каких группах пользователь jakonda@jakonda.local состоит:

groups jakonda@jakonda.local
jakonda@jakonda.local : domain users@jakonda.local domain admins@jakonda.local

Если вы только что изменили членство пользователя в группе, может пройти некоторое время, прежде чем sssd заметит это из-за кэширования.

Попробуем войти в систему:

sudo login

debian.jakonda.local имя пользователя: Jakonda
Пароль:
Linux debian.jakonda.local 5.10.0-23-amd64 #1 SMP Debian 5.10.179-3 (2023-07-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Создание каталога /home/jakonda@jakonda.local.

Автоматическое создание домашнего каталога

Чтобы доменным пользователям создавался их домашний каталог при входе в систему, выполним команду:

pam-auth-update --enable mkhomedir

Результатом выполнения команды будет, добавление в /etc/pam.d/common-session строки:

session optional                        pam_mkhomedir.so umask=0022 skel=/etc/skel

Управление разрешениями на вход для пользователей домена

Чтобы задать правила доступа, используйте следующие две команды:

• realm deny
• realm permit

Глобальные разрешения

Чтобы предоставить или запретить доступ для всех пользователей, используется команда с параметром --all:

realm permit --all
realm deny --all

Разрешения по пользователям

Чтобы предоставить доступ указанным пользователям, используется команда:

realm permit user@jakonda.local
realm permit 'JAKONDA.LOCAL\user'

Разрешения по группам безопасности

Для пользователей доменных групп безопасности, используется команда:

ream permit -g %Domain\admins@jakonda.local

Запрещающие правила

Чтобы запретить доступ указанным пользователям, используется команда с параметром -x:

realm permit -x user@jakonda.local

SUDO разрешения

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

Создаем файл /etc/sudoers.d/admins со следующим содержанием:

%ServerAdmins ALL=(ALL) ALL

Хочу заместить если группа безопасности содержит пробелы, например — Domain admins, то указывать ее нужно в формате — %Domain\admins

Вывод из домена

Опишу так же процедуру вывода системы из домена, на случай если такая возникнет необходимость.

Сперва выводим список сконфигурированных доменов:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-realm-logins

Для вывода системы из домена, выполняем команду:

realm leave -v -U Administrator@jakonda.local

Замените Administrator на учетную запись с правами на удаление компьютеров в домен и jakonda.local на свой домен.

Если в выводе сконфигурированных доменов присутствует две записи (две записи присутствуют при использовании двух client-software — winbind и sssd), к примеру вот так это выглядит:

realm list

jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: winbind
  required-package: winbind
  required-package: libpam-winbind
  required-package: samba-common-bin
  login-formats: JAKONDA\%U
  login-policy: allow-any-login
jakonda.local
  type: kerberos
  realm-name: JAKONDA.LOCAL
  domain-name: jakonda.local
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U
  login-policy: allow-realm-logins

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

realm leave -v --client-software=sssd -U Administrator@jakonda.local
realm leave -v --client-software=winbind -U Administrator@jakonda.local

Очистка системы

После вывода системы из домена, удаляем кеш SSSD и Kerberos.

Останавливаем SSSD демон:

Удаляем SSSD кеш:

Удаляем Kerberos кеш:

1. Подробное описание realmd-conf — https://www.freedesktop.org/software/realmd/docs/realmd-conf.html ↩︎

Всем привет!

Термин Microsoft Active Directory Domain Services включает в себя множество технологий, поэтому сразу уточню, в этой статье речь пойдет про использование контроллера домена только для аутентификации пользователей. То есть в финале, нужна возможность любому сотруднику предприятия сесть за любую рабочую станцию Linux, используя свой доменный логин и пароль.

Начиная с Windows 2000 Server для аутентификации пользователей домена используется протокол Kerberos, разработанный еще в 80-х годах прошлого столетия, алгоритм работы которого, ИМХО, являет собой пример отличного инженерного хака, в хорошем (изначальном:) смысле этого слова. В конце статьи есть ссылка на описание его работы, а сейчас надо сказать, что имеется несколько реализаций этого протокола и решение из этой статьи не привязано только к Microsoft Active Directory

Итак, на предприятии уже развернут контроллер домена, вероятнее всего — Microsoft Active Directory и перед нами — рабочая станция Linux (примеры будут для Debian, но работать будет и в других дистрибутивах и, даже, в моей любимой FreeBSD:). Как ввести ее в домен?

Да очень просто:

student@debian:~$ sudo apt install krb5-user -y

В Debian даже не понадобится редактировать, но убедитесь, и, при необходимости укажите эти строки в файле конфигурации Kerberos клиента (достаточно только их)

student@debian:~$ sudo nano /etc/krb5.conf

[libdefaults]
        default_realm = CORP.RU

Вместо CORP.RU должно быть имя домена (Kerberos сферы) Вашего предприятия

И все, можно “входить” в домен:

student@debian:~$ kinit ivanovii
Password for ivanovii@CORP.RU:

student@debian:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: ivanovii@CORP.RU
Valid starting       Expires              Service principal
02/22/2023 00:09:13  02/22/2023 10:09:13  krbtgt/CORP.RU@CORP.RU
renew until 02/23/2023 00:09:09

ivanovii — зарегистрированный в домене логин пользователя, замените его на тот, который есть у Вас, можно, даже, использовать Administrator. В результате работы команды kinit была осуществлена аутентификация пользователя и получен Ticket-Granting Ticket (TGT) “билет на выдачу билетов”, позволяющий, в дальнейшем, получить билеты на доступ к зарегистрированным в домене сервисам, реализуя таким образом технологию единого входа — single sign-on (SSO).

Можно заканчивать статью

Постойте, но, например, в оснастке “Active Directory Users and Computers” никакой рабочей станции Linux не появилось, как же так? Да, действительно, контроллер домена по прежнему ничего не знает о нашей рабочей станции, фактически, наоборот, это наша рабочая станция, благодаря параметру default_realm = CORP.RU и соответствующим SRV записям в DNS

student@debian:~$ nslookup -q=SRV _kerberos._udp.corp.ru
...
kdc.corp.ru    internet address = A.B.C.D

знает местоположение контроллера домена, и этого достаточно для работы с его Kerberos подсистемой. Для чего может понадобиться регистрация Linux системы в Active Directory и как это сделать — тема отдельной статьи, а сейчас вернемся к нашей задаче — вход доменной учетной записью в Linux систему

За процесс аутентификации пользователей при входе в Linux отвечает библиотека PAM (Pluggable Authentication Modules) использование которой я упоминал в этой статье. В нашем случае добавим в систему модуль, использующий Kerberos аутентификацию:

student@debian:~$ sudo apt install libpam-krb5 -y

В Debian новый модуль добавится в конфигурацию PAM автоматически, сперва логин/пароль будут проверяться в Kerberos, и, в случае неудачи, в локальной базе пользователей:

student@debian:~$ less /etc/pam.d/common-auth

...
auth    [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
auth    [success=1 default=ignore]      pam_unix.so nullok try_first_pas
...

однако, попытка войти в систему доменным пользователем закончится неудачно:

student@debian:~$ sudo login
debian login: ivanovii
Password:
Authentication failure

а в журнале видна причина:

student@debian:~$ sudo tail /var/log/auth.log
...
Feb 22 01:18:43 debian login[1587]: pam_krb5(login:auth): user ivanovii authenticated as ivanovii@CORP.RU
Feb 22 01:18:43 debian login[1587]: pam_unix(login:account): could not identify user (from getpwnam(ivanovii))
...

аутентификация прошла успешно, но дальше, система ничего не знает о нашем пользователе (ни UID, ни GID ни прочих атрибутов)

$ id ivanovii
id: ‘ivanovii’: no such user

Вот теперь мы подошли к этапу, ради которого писалась статья:)

Если начать искать традиционное решение этой задачи, то, скорее всего, Вы узнаете о библиотеке Name Service Switch (NSS) и модулях LDAP, WinBIND или SSSD для нее. Но что если … просто создать учетную запись после успешной аутентификации?

Оказывается, библиотеку PAM можно расширять своими собственными скриптами, используя модуль pam_script. Давайте добавим его в систему:

student@debian:~$ sudo apt install libpam-script -y

Здесь авторы пакета для Debian не угадали наш замысел, расположив модули в таком порядке:

student@debian:~$ less /etc/pam.d/common-auth
...
auth    [success=3 default=ignore]      pam_krb5.so minimum_uid=1000
auth    sufficient                      pam_script.so
auth    [success=1 default=ignore]      pam_unix.so nullok try_first_pass
...

Если честно, то такая конфигурация не только не подходит для нашей задачи, но и очень не хороша с точки зрения безопасности, легко довести ее до ситуации, когда будет достаточно знать логин локального пользователя, например root, для подключения к системе, пароль подойдет любой (вот за это любил FreeBSD, она за нас никогда ничего не делает:) Поэтому, поправьте конфигурацию расположив модули так:

student@debian:~$ sudo nano /etc/pam.d/common-auth

auth    [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
auth    [success=2 default=ignore]      pam_unix.so nullok_secure try_first_pass
auth    requisite                       pam_deny.so
auth    sufficient                      pam_script.so
auth    required                        pam_permit.so

В этом случае, после успешной аутентификации учтённой записи в Kerberos, выполнение “перепрыгнет” два следующих шага и запустит модуль pam_script. Остается только написать скрипт, который проверит наличие учетной записи, и, в случае ее отсутствия в системе — создаст:

student@debian:~$ sudo nano /usr/share/libpam-script/pam_script_auth

#!/bin/bash

id "$PAM_USER" &>/dev/null || useradd -m -s /bin/bash "$PAM_USER"

student@debian:~$ sudo chmod +x /usr/share/libpam-script/pam_script_auth

Проверяем:

student@debian:~$ sudo login
debian login: ivanovii
Password:
...
ivanovii@debian:~$ id
uid=1001(ivanovii) gid=1001(ivanovii) groups=1001(ivanovii)

ivanovii@debian:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1001_0zzvqR
Default principal: ivanovii@CORP.RU
Valid starting       Expires              Service principal
02/22/2023 04:14:30  02/22/2023 14:14:30  krbtgt/CORP.RU@CORP.RU
renew until 02/23/2023 04:14:30

Ну вот и все, мы в системе, и TGT у нас в кармане:)

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

Спасибо, что дочитали до конца, надеюсь, было интересно, посмотрите ссылки, буду рад комментариям, до новых встреч!

Ссылки:

• Kerberos за 5 минут: знакомство с сетевой аутентификацией

• Зачем вводить системы Linux в домен Microsoft?

Joining a Debian Client to Active Directory

Note: This walkthrough was taken almost entirely from https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto. A few configuration changes in the PAM section and verbiage used are the only differences. More work is required to make this Debian-specific.

Required Software/Packages

Time settings

Kerberos requires that the device time be within a few minutes of the server time. See NTP to find out how to keep clocks up-to-date.

FQDN

A valid FQDN is necessary for Kerberos and AD. Edit the local host file so that it is resolvable.

Location: /etc/hosts

127.0.0.1 linux.test.server.com localhost linux

Configure Kerberos

Use apt-get install to install the following packages:

        krb5-user
        libpam-krb5 

krb5 template Location: /etc/krb5.conf

[logging]
        Default = FILE:/var/log/krb5.log

[libdefaults]
        ticket_lifetime = 24000
        clock-skew = 300
        default_realm = test.server.com
#       dns_lookup_realm = false
#       dns_lookup_kdc = true

[realms]
        test.example.com = {
                kdc = example.test.server.com:88
                admin_server = example.test.server.com:464
                default_domain = test.server.com        

}

[domain_realm]
        .server.com = test.server.com
        server.com = test.server.com

Test your configuration by requesting a ticket

root@linux:~# kinit Administrator@test.server.com
Password for Administrator@test.server.com : ****

Use klist to verify request worked

root@linux:~# klist
Ticket cache: File: /tmp/krb5cc_0
Default principal: Administrator@test.server.com

Valid starting          Expires Service principal
05/16/07 10:30:42       05/16/07 20:30:01
Krbtgt/test.server.com@test.server.com
        renew until 05/16/07 10:30:42

Join the Domain

Use apt-get install to install the following packages:

        winbind
        samba

Join Location: /etc/samba/smb.conf

[global]
        security = ads
        realm = test.server.com
        password server = 10.0.0.1
        workgroup = test
#       winbind separator = +
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        winbind enum users = yes
        winbind enum groups = yes
        template homedir = /home/%D/%U
        template shell = /bin/bash
        client use spnego = yes
        client ntlmv2 auth = yes
        encrypt passwords = yes
        winbind use default domain = yes
        restrict anonymous = 2
        domain master = no
        local master = no
        preferred master = no
        os level = 0

Restart services

root@linux:~# /etc/init.d/winbind stop
root@linux:~# /etc/init.d/samba restart
root@linux:~# /etc/init.d/winbind start

Request Kerberos TGT for an account

root@linux:~# net ads join

Using short domain name – test

Joined ‘Linux’ to realm ‘test.server.com’

Test

# wbinfo -u

Setup Authentication

nsswitch Location: /etc/nsswitch.conf

passwd: compat winbind
group:  compat winbind
shadow: compat

Test

root@linux:~# getent passwd

root:x:0:0:root:/root:/bin/bash
. . .
test+administrator:x:10000:10000:Administrator:/home/test/administrator:/bin/b…
test+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash
. . .

root@linux:~#: getent group

root:x:0:
daemon:x:1:
bin:x:2:
. . .
test+organizations-admins:x:10005:administrator
test+domain-admins:x:10006: user, administrator
. . . 

PAM

Location: /etc/pam.d/common-account

account sufficient      pam_winbind.so
account required        pam_unix.so

Location: /etc/pam.d/common-auth

auth sufficient pam_winbind.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required   pam_deny.so

Location: /etc/pam.d/common-session

session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel

Location: /etc/pam.d/sudo

Auth sufficient pam_winbind.so
Auth sufficient pam_unix.so use_first_pass
Auth required    pam_deny.so

@include common-account

Final Config

Each domain needs a directory in home

root@linux:~# mkdir /home/test

Login
login: test+user
password: ****
. . .
test+user@linux:~$