ActiveDirectory/Join

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

Ввод машины в домен — это процесс, в результате которого компьютер становится частью инфраструктуры Active Directory (AD) или другого домена, управляемого централизованной службой каталогов. Это действие связывает компьютер с доменом и наделяет его рядом характеристик и возможностей, таких как централизованная аутентификация, авторизация и управление настройками.

Для того, чтобы машина стала частью домена, необходимо выполнение следующих действий:

На контроллере домена - изменение LDAP-базы домена;
На клиенте (машина, которую необходимо ввести в домен) - настройка сети и системных конфигураций.

На контроллере домена

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

Происходит создание объекта computer с уникальным именем машины в формате MACHINE$. Учетная запись привязывается к контейнеру или определенной организационной единице (OU) в базе LDAP, что позволяет контролировать доступ машины в домен и устанавливать необходимые групповые политики. По умолчанию учетные записи компьютеров создаются в контейнере Computers.

Примечания

Длинные имена машин в домене

Рекомендации (для имен хостов, больше 15 символов) для клиентов и серверов на базе ALT:

Хосту задаётся два имени: длинное (dnsHostname) и короткое (sAMAccountName, NetBIOS Name).
Длинное имя должно совпадать с именем хоста (hostname).
При введении хоста в домен оба имени нужно указывать явно.
Оба имени должны быть уникальными.
Для корректной работы службы SSSD в параметре настройки ad_hostname необходимо задавать короткое имя хоста.
Обновление DNS записей с помощью SSSD будет выполняться только для короткого имени. По этому обновление DNS записей рекомендуется отключить (dyndns_update = false, dyndns_update_ptr = false).
Для введения хоста в домен в режиме с двумя именами предлагается использовать временное решение в виде распространяемого не из пакета скрипта system-auth

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

#./system-auth write ad domain.alt super-long-hostname sub --netbiosname=short-host

В случае с коротким именем хоста поведение скрипта не меняется.

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

На клиенте

Предварительно на клиенте должна быть настроена сеть. В качестве первичного DNS должен быть указан такой DNS-сервер, который который умеет разрешать DNS-имена из домена AD.

В процессе привязки машины к домену происходит создание машинной учетной записи (или нахождение уже существующей, созданной заранее) и смена ее пароля.

При добавлении Linux-машины в домен создается файл krb5.keytab, который хранит ключи для аутентификации машины в домене через Kerberos (тот самый пароль учетной записи машины). Он необходим для того, чтобы машина могла аутентифицироваться и взаимодействовать с доменом.

Просмотреть содержимое файла krb5.keytab:

# klist -ket

Таким образом можно получить следующую информацию:

KVNO (Key Version Number) — номер версии ключа в системе аутентификации Kerberos. Когда ключ аутентификации учетной записи меняется (например, при ротации пароля), KVNO увеличивается. Это позволяет различать старые и новые версии ключей.
Timestamp - время создания записи для ключа в keytab-файле.
Principal - уникальный идентификатор объекта в Kerberos, для которого был сгенерирован ключ аутентификации. В krb5.keytab обычно хранятся Principal, которые используются для аутентификации машины или служб, работающих на ней. Они включают:
- Машинный Principal (представляет учетную запись компьютера в домене)
  hostname$@REALM
- Host Principal (используется для базовых служб, связанных с машиной)
  host/hostname.example.com@REALM
  
  host/hostname@REALM
- Service Principal (представляет сетевые службы, которые используют Kerberos для аутентификации)
  HTTP/webserver.example.com@REALM
  
  ldap/server.example.com@REALM
- Restricted Host Principal (используется для служб с дополнительными ограничениями)
  restrictedkrbhost/hostname.example.com@REALM
  
  restrictedkrbhost/hostname@REALM

При добавлении Windows-машины в домен пароль учетной записи машины генерируется и хранится локально в базе Security Account Manager (SAM) в зашифрованном виде.

Файл SAM находится по пути: C:\Windows\System32\config\SAM. Он недоступен для прямого чтения, так как защищен системой. Пароль используется для вычисления ключа Kerberos, необходимого для аутентификации.

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

Чтобы ввести машину под управление домена необходим еще ряд действий:

Настройка локальной аутентификации - для локальных и доменных пользователей. Эта настройка позволяет машине работать как с локальными учетными записями, так и с учетными записями из домена.
Настройка разрешения имен - позволяет машине правильно обрабатывать имена пользователей и групп из домена и обеспечивать доступ к ресурсам через корректную работу с именами.
ID-mapping - настройка, которая связывает UID/GID локальных пользователей с идентификаторами в домене (на windows-машинах не требуется).
Настройка ролей и привилегий - настройка управления доступом для пользователей домена на клиентских рабочих станциях.
Групповые политики - настройка рабочей среды.

Когда компьютер становится частью домена, он подчиняется доменным политикам и интегрируется с другими компьютерами в домене. Это позволяет использовать возможности централизованного управления учетными записями, доступом и настройками безопасности. Привязка машины к домену также упрощает аутентификацию доменных пользователей, позволяя им входить в систему с одной учетной записью и получать доступ ко всем ресурсам (Single Sign-On (SSO)).

Вход в домен AD клиентом на ALT Linux

В семействе дистрибутивов ALT рекомендуемым способом ввода машины в домен является использование модуля аутентификации alterator-auth, который использует команду net ads join.

Модуль можно использовать в ЦУС (Центр управления системой) и в командной строке:

Центр управления системой:

Командная строка:
```
# system-auth write ad domain.name host workgroup [Administrator password] [--windows 2003] [--create computer=COMPUTER OU/Linux] [--winbind] [--gpo]
```
- --windows 2003 - указывает, что подключение производится к домену на основе Windows Server 2003. Это может потребоваться для включения совместимости с устаревшими версиями AD.
- --create computer=COMPUTER OU/Linux - указывает организационную единицу (OU), в которую будет помещена учетная запись компьютера.
  COMPUTER — Имя создаваемой записи компьютера в домене.
  
  OU/Linux — Путь к организационной единице в AD, где будет создана эта запись. Например: OU=LinuxComputers,DC=example,DC=com.
  
  Если ключ не указан, учетная запись компьютера будет помещена в стандартный контейнер Computers.
- --winbind - указывает использовать службу Winbind для взаимодействия с Active Directory.
- --gpo- активирует поддержку групповых политик (GPO) на клиентской машине.

Перед вводом машины в домен с помощью команды net ads join, происходит подготовка машины (данные настройки выполняются автоматически):

Настройка Avahi-daemon - настройка порядка поиска имен хостов в файле nsswitch.conf, если используется домен с суффиксом .local. В таком случае поиск через DNS должен быть раньше поиска через mDNS (Multicast DNS).
Проверка DNS (проверка доступности Kerberos-сервера для указанного домена)
```
$ host -t SRV _kerberos._tcp.domain.alt | grep 'SRV record'
```
Редактирование системных конфигураций
- Настройки kerberos в файле /etc/krb5.conf
  область Kerberos по умолчанию:
  default_realm = DOM.LOC
  
  отключение поиска области Kerberos домена через DNS:
  dns_lookup_realm = false
  
  включение поиска kerberos-настроек домена через DNS:
  dns_lookup_kdc = true
- Настройка конфигурационного файла /etc/samba/smb.conf
  В этом конфигурационном файле содержатся настройки самого сервиса Samba и службы winbind. К настройкам Samba относятся:
  kerberos-имя домена:
  realm = DOMAIN.ALT
  
  рабочая группа:
  workgroup = DOMAIN
  
  имя рабочей станции в сетевом окружении:
  netbios name = CLIENT2
  
  уровень безопасности Active Directory:
  security = ADS
  
  метод хранения kerberos-ключей рабочей станции:
  kerberos method = system keytab
  
  К настройкам службы Winbind, который запущен в любом случае (при использовании и SSSD и Winbind)
  перечисление Winbind всех пользователей домена при вызове соответствующих команд:
  winbind enum users = no
  
  перечисление Winbind всех групп домена:
  winbind enum groups = no
  
  шаблон пути для домашнего каталога пользователя:
  template homedir = /home/%D/%U
  
  оболочка по умолчанию, которая будет назначена доменным пользователям при их авторизации на машине:
  template shell = /bin/bash
  
  формат имен пользователей при их использовании в системе
  winbind use default domain = yes
  
  Пример секции [global] конфигурационного файла:
  [global] security = ads realm = DOMAIN.ALT workgroup = DOMAIN netbios name = WS8 template shell = /bin/bash kerberos method = system keytab wins support = no winbind use default domain = yes winbind enum users = no winbind enum groups = no template homedir = /home/%D/%U winbind refresh tickets = yes winbind offline logon = yes idmap config * : range = 10000-20000000 idmap config * : backend = tdb machine password timeout = 0 ; encrypt passwords = true ; dns proxy = no ; socket options = TCP_NODELAY ; domain master = no ; local master = no ; preferred master = no ; os level = 0 ; domain logons = no ; load printers = no ; show add printer wizard = no ; printcap name = /dev/null ; disable spoolss = yes
- настройка SSSD
  домены, которые обслуживает SSSD (секция [sssd]):
  domains = DOMAIN.ALT
  
  в секцию [pam] добавляется раздел для конкретного домена [domain/DOMAIN.ALT].
  
  использование для идентификации, аутентификации, изменения паролей и управления доступом в системе Active Directory (AD) как центральный источник информации:
  id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad
  
  оболочка по умолчанию, которая будет назначена доменным пользователям при их авторизации на локальной машине:
  default_shell = /bin/bash
  
  шаблон пути для домашнего каталога пользователя:
  fallback_homedir = /home/%d/%u
  
  настройки обработки групповых политик (GPO) и синхронизации учетной записи машины с Active Directory (AD):
  ad_gpo_ignore_unreadable = true ad_gpo_access_control = permissive ad_update_samba_machine_account_password = true
  
  Минимальный конфигурационный файл (/etc/sssd/sssd.conf) для sssd-ad выглядит следующим образом:
  [sssd] config_file_version = 2 services = nss, pam # Managed by system facility command: ## control sssd-drop-privileges unprivileged|privileged|default user = _sssd # SSSD will not start if you do not configure any domains. domains = DOMAIN.ALT [nss] [pam] [domain/DOMAIN.ALT] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad default_shell = /bin/bash fallback_homedir = /home/%d/%u debug_level = 0 ; cache_credentials = false ad_gpo_ignore_unreadable = true ad_gpo_access_control = permissive ad_update_samba_machine_account_password = true
- Настройка аутентификации
  Для изменения настроек аутентификации (параметров PAM) в ALT Linux используется утилита control:
  # control system-auth sss
- Настройка авторизации
  Авторизационные NSS-базы GLibc настраиваются в файле /etc/nsswitch.conf. При использовании sssd, вносятся исправления в следующие строки:
  passwd: files sss shadow: tcb files sss group: files sss services: files sss netgroup: files sss
- Настройка ролей и привилегий
  Использование модуля libnss-role:
  # control libnss-role enabled
- Включение групповых политик
  Включение работы групповых политик и выбор шаблона локальной политики (local policy) выполняется командой gpupdate-setup:
  # gpupdate-setup enable
- Настройка менеджера дисплея LightDM
  Происходят в файле /etc/lightdm/lightdm.conf
- Синхронизация времени с контроллером домена
  net time set -S <имя домена>

Далее net ads join выполняет следующие действия:

Аутентификация с использованием Kerberos: Машина использует Kerberos для аутентификации на контроллере домена, используя учетные данные пользователя,имеющего на это права.
Создание или нахождение уже имеющейся учетной записи машины в AD: Контроллер домена создает объект компьютера в Active Directory или находит заранее созданный. Этот объект связан с учетной записью машины и паролем доверия. Пароль учетной записи машины генерируется и сохраняется в локальном файле krb5.keytab.
Регистрация в DNS: Машина регистрирует свои записи в DNS, чтобы быть доступной для других устройств.

Способы ввода машины в домен

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

Администратор домена

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

Центр управления системой
На клиенте необходимо открыть Центр управления системой - Пользователи - Аутентификация. Выбрать необходимый вариант, заполнить поля и нажать Применить.

Далее потребуется ввести данные администратора домена.

Командная строка

# system-auth write ad domain.alt ws domain 'administrator' 'Pa$$word' --winbind --gpo

Пользователь, принадлежащий группе с правами Администратора

Пользователи, принадлежащие группе Domain Admins и любой другой группе с правами администратора, имеют права на добавление и удаление машин из домена.

В таком случае так же можно добавить машину в домен как через графический интерфейс (ЦУС), так и с помощью командной строки.

Передача пользователю прав на конкретную машину

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

Примечание: В таком случае машина считается повторно введенной в домен,так как она привязывается к учетной записи, которая была предварительно создана на контроллере домена.

В таком случае необходимо предварительно на контроллере домена создать учетную запись машины и использовать ее при присоединении машины к домену:

У созданной машинной учетной записи во вкладке Безопасность добавляем необходимого пользователя в качестве доверенного лица:

Выставляем разрешения на полный доступ:

На клиенте во время вводы машины в домен используем созданную машинную учетную запись и учетную запись пользователя с правами подключения к домену:

Повторный ввод машины в домен с именем уже существующей учётной записи машины

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

Повторно использовать имя уже существующей учётной записи рабочей станции в домене могут:

Администратор домена независимо от того, кто является владельцем учётной записи машины.
Пользователь с делегированными правами на имеющуюся в домене учётную запись машины (с правами на запись и сброс пароля).

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

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

Вывод машины из домена — это процесс удаления компьютера из управления доменом Active Directory, который включает несколько этапов как на стороне клиента, так и на стороне контроллера домена. Этот процесс позволяет вернуть машину в состояние локального управления.

Удалить машинную учетную запись можно несколькими способами:

на контроллере домена с помощью # samba-tool computer delete MACHINE$ - DNS-запись машины удаляется
на контроллере домена с помощью ADMC - DNS-запись машины не удаляется
на клиенте с помощью # net ads leave -U administrator - DNS-запись машины не удаляется

В случаях, когда DNS-запись не удаляется, необходимо удалить ее самостоятельно:

samba-tool dns delete <DNS-сервер> <зона> <имя-записи> <тип-записи> <данные>

<DNS-сервер> — адрес или имя DNS-сервера (например, 10.64.224.104 или dc.domain.alt)
<зона> — имя зоны (например, domain.alt)
<имя-записи> — имя удаляемой записи
<тип-записи> — тип удаляемой записи (например, A, CNAME, TXT и т. д.)
<данные> — значение записи (например, IP-адрес для A-записи)

На клиенте необходимо поменять способ аутентификации на локальную базу пользователей и поставить галочку для восстановления файлов конфигурации по умолчанию (smb.conf, krb5.conf, sssd.conf). Также нужно удалить файл krb5.keytab, поменять hostname и очистить кэш sssd и winbind.