Альт линукс ввести в домен windows

Инструкция по вводу рабочей станции под управлением ALT Linux в домен Active Directory (работающий под Windows или под Samba в режиме AD DC).
Устаревшая инструкция: Ввод в домен на базе Windows 2003

Внимание! Если Ваш домен имеет суффикс .local — необходимо отключить avahi-daemon (подробнее ниже, пункт 2 примечаний).

Параметры домена

Подготовка

Установка пакетов

С версии alterator-auth-0.31-alt1

apt-get install task-auth-ad-sssd

apt-get install alterator-auth sssd-ad samba-common-tools

Требуемые версии:

• pam-config >= 1.7.0-alt1
• alterator-auth >= 0.26-alt1

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

Синхронизация времени

С версии alterator-auth 0.28 синхронизация времени производится автоматически с контроллером домена.

Для более ранних версий:

Способ 1: Через net time

net time set -S <имя домена>

Способ 2: По протоколу RFC 867

На сервере включается через xinetd daytime-tcp ^[1]:

# chkconfig --list | grep daytime-tcp
        daytime-tcp:    вкл

А на клиенте — служба settime-rfc867:

chkconfig settime-rfc867 on
service settime-rfc867 start

Способ 3: Через Центр управления системой → Дата и время

Включите флажок «Получать точное время с NTP-сервера» и укажите в поле справа pool.ntp.org. После этого нажмите кнопку «Применить».

Способ 4: Через ntpdate

ntpdate pool.ntp.org

Ввод в домен

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

Для ввода компьютера в Active Directory потребуется установить пакет task-auth-ad-sssd и все его зависимости.

В Центре управления системой перейдите в раздел Аутентификация (Пользователи → Аутентификация). Выберите пункт «Домен Active Directory» и заполните поля. Нажмите кнопку «Применить».

Картинка с сайта: www.altlinux.org

Ввод в домен в командной строке

# system-auth write ad school.alt host-15 school 'administrator' 'Pa$$word' [--windows2003] [--createcomputer="COMPUTEROU/SubCOMPUTEROU/SubSubCOMPUTEROU"] [--winbind] [--gpo] [-d]
Joined 'HOST-15' to dns domain 'school.alt'

Примечания

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

Рекомендации (для имен хостов, больше 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

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

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

Настройка SSSD

См. статью SSSD/AD, Настройки SSSD в Alterator

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

# getent passwd ivan
ivan:*:10005:10002:ivan:/home/SCHOOL/ivan:/bin/bash

# net ads info
LDAP server: 192.168.1.1
LDAP server name: c228.school.alt
Realm: SCHOOL.ALT
Bind Path: dc=SCHOOL,dc=ALT
LDAP port: 389
Server time: Ср, 22 апр 2015 16:22:47 MSK
KDC server: 192.168.1.1
Server time offset: -1

# net ads testjoin
Join is OK

Примечание: Вы не увидите пользователей из AD с помощью команды # getent passwd на клиентской машине. Этот функционал отключен по-умолчанию для того чтобы сократить нагрузку на серверы. Поэтому для проверки необходимо указать точное имя пользователя # getent passwd имя_пользователя . Список пользователей можно посмотреть на сервере командой # samba-tool user list

Примечания

1. Ограничение: имя домена должно указывать на DC. Если это не так, поправляйте /etc/krb5.conf и вводите вручную, либо в файл /etc/hosts добавьте строку с контроллером домена (кдц) ДОМЕН.local и перезапустите сеть. После этого проверьте из командной строки ping ДОМЕН.local и вводите в домен.
2. При указании домена, имеющего суффикс .local, потребуется на сервере и подключаемых компьютерах под управлением Linux отключить службу avahi-daemon (доменная зона «local.» используется в технологии zeroconf):

   # chkconfig avahi-daemon off; reboot
   

3. Следите за синхронизацией времени на клиенте и сервере.
4. Для предотвращения кэширования имён пользователя отключите службу nscd.
5. В новых версиях Samba до запуска службы winbind должна запускаться служба smb.
6. Если возникает проблема просмотра билетов Kerberos под доменным пользователем, скопируйте правильный krb5.conf из samba:

   # rm -f /etc/krb5.conf
   # cp /var/lib/samba/smb_krb5/krb5.conf* /etc/krb5.conf
   

7. Если у вас домен Windows 2003 (не R2), то в директивы default_tgs_enctypes, default_tkt_enctypes и preferred_enctypes файла /etc/krb5.conf добавьте ещё DES3-CBC-SHA1.
8. Для возможности входа в ОС под доменным пользователем при его недоступности можно включить опцию кэширования учётных данных в конфиге SSSD (подробнее тут, опция cache_credentials).
9. Убедитесь, что у вас в /etc/samba/smb.conf и /etc/sssd/sssd.conf прописаны параметры, отвечающие за автоматическое обновление пароля машины:
   • файл /etc/samba/smb.conf:

     [global]
     machine password timeout = 0
     

   • файл /etc/sssd/sssd.conf:

     [sssd]
     user = root
     
     [domain/SCHOOL.ALT]
     ad_update_samba_machine_account_password = true
     

   Подробнее здесь

Настройка окна входа

Настройка LightDM

В /etc/lightdm/lightdm.conf раскомментируйте строку в группе [SeatDefaults]:

greeter-hide-users=true

Это позволит вводить имя пользователя вручную, а не прокручивать огромный список доступных доменныx пользователей.

Также полезно выключить выбор языка. В файле /etc/lightdm/lightdm-gtk-greeter.conf в группе [greeter] укажите:

show-language-selector=false

В новых версиях lightdm-gtk-greeter можно указать кнопки явно:

show-indicators=~a11y;~power

Полный перечень доступных кнопок:

show-indicators=~a11y;~power;~session;~language

Решение проблем

Изменение пароля при истечении его срока

При использовании winbind нет диалога смены пароля, меняемого при первом запуске или при истечении его срока. В p10 необходимо обновить samba до 4.17:

apt-repo upgrade 332201

И дописать в файл /etc/security/pam_winbind.conf:

После этого выполните:

systemctl restart winbind

Отображение глобальных групп на локальные

Примечание: Первые два пункта данного раздела выполняются автоматически, если АРМ вводится в домен с помощью task-auth-ad-sssd.

Установка модуля ролей

apt-get install libnss-role

Настройка ролей и привилегий

Добавляем роль локальных администраторов:

# groupadd -r localadmins

Примечание: Лучше использовать группу localadmins (вместо admins) по избежание конфликта с группой admins во FreeIPA.

Создаём привилегию на право удалённого доступа (по протоколу ssh):

# groupadd -r remote

Включаем удалённый доступ только для группы remote:

# control sshd-allow-groups enabled
# sed -i 's/AllowGroups.*/AllowGroups = remote/' /etc/openssh/sshd_config

Настраиваем список привилегий для пользователей (для роли users):

# roleadd users cdwriter cdrom audio proc radio camera floppy xgrp scanner uucp fuse

Настраиваем список привилегий для администраторов (для роли admins):

# roleadd localadmins wheel remote vboxusers

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

# roleadd 'Domain Users' users

или

# roleadd 'Пользователи домена' users

Далее

# roleadd 'Domain Admins' localadmins

или

# roleadd 'Администраторы домена' localadmins

Просматриваем список назначенных ролей и привилегий:

# rolelst
# id ivan

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

Дополнительные роли

Соответственно, если надо выдать права администраторов АРМ пользователям, которые не являются Domain Admins,
то нужно завести новую группу в AD (например, PC Admins), добавить туда необходимых пользователей.
Затем на АРМ добавить роль для данной группы:

# roleadd 'PC Admins' localadmins
# rolelst
users: cdwriter cdrom audio video proc radio camera floppy xgrp scanner uucp vboxusers fuse tsusers
localadmins: wheel
domain users: users
domain admins: localadmins
pc admins: localadmins

После этого (и после разрешения sudo для группы wheel) под пользователем входящим в группу PC Admins
можно запускать команду повышения прав sudo.

user@alt8 ~ $ su - petrov
Password: 
petrov@alt8 ~ $ id
uid=445010929(petrov) gid=445000513(domain users) группы=445000513(domain users),10(wheel),14(uucp),19(proc),
22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),100(users),458(tsusers), 459(localadmins),466(fuse),468(video),
480(camera),492(vboxusers),498(xgrp),499(scanner),445010930(pc admins)
petrov@alt8 ~ $ sudo apt-get update
Пароль:
Получено: 1 http://ftp.altlinux.org p8/branch/x86_64 release [880B]
Получено: 2 http://ftp.altlinux.org p8/branch/x86_64-i586 release [537B]
Получено: 3 http://ftp.altlinux.org p8/branch/noarch release [673B]
Получено 2090B за 0s (36,9kB/s).
Найдено http://ftp.altlinux.org p8/branch/x86_64/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/x86_64/classic release
Найдено http://ftp.altlinux.org p8/branch/x86_64-i586/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/x86_64-i586/classic release
Найдено http://ftp.altlinux.org p8/branch/noarch/classic pkglist
Найдено http://ftp.altlinux.org p8/branch/noarch/classic release
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено

Подключение файловых ресурсов

Рассматриваемые способы позволяют подключать файловые ресурсы (file shares) для доменного пользователя без повторного ввода пароля (SSO, Single Sign-On).

Через gio

Примечание: Способ актуален для дистрибутивов, использующих gio (ранее — gvfs) (например, Simply Linux, ALT Workstation, СП).

Недостаток такого способа — необходимо открыть ресурс в файловом менеджере (Caja, Pcmanfm). Однако можно открывать любые ресурсы на любых серверах, входящие в домен Active Directory.

1. Устанавливаем необходимые пакеты (с правами root):

# apt-get install fuse-gvfs gvfs-backend-smb libgio

2. Включаем пользователя в группу fuse (с правами root):

# gpasswd -a <пользователь> fuse

# control fusermount public

3. Входим доменным пользователем.

4. Открываем ресурс в файловом менеджере (например, по адресу smb://server/sysvol). Ресурс смонтирован по пути /var/run/<uid_пользователя>/gvfs или /run/user/<uid_пользователя>/gvfs/smb-share:server=<сервер>,share=<ресурс>

Другой вариант (полезно для скриптов в автозапуске):

gio mount smb://server/sysvol/

Примечание: Если необходимо открывать что-то с ресурса в WINE, в winecfg добавьте диск с путём /var/run/<uid_пользователя>/gvfs.

С использованием pam_mount

Заданный файловый ресурс подключается с заданного сервера автоматически при каждом входе доменным пользователем.

1. Устанавливаем pam_mount:

# apt-get install pam_mount

Если осуществляется подключение файловых ресурсов по протоколу CIFS (SMB), то установите cifs-utils:

# apt-get install cifs-utils

# apt-get install systemd-settings-enable-kill-user-processes

2. Прописываем pam_mount в схему аутентификации по умолчанию. В конец файла (/etc/pam.d/system-auth) добавьте строки

session         [success=1 default=ignore] pam_succeed_if.so  service = systemd-user quiet
session         optional        pam_mount.so disable_interactive

Параметр disable_interactive нужен для того, чтобы pam_mount не спрашивал пароль. Первая строка предназначена для того, чтобы не монтировать дважды при запуске systemd —user. Подробнее: https://wiki.archlinux.org/title/pam_mount#Login_manager_configuration

Пример файла /etc/pam.d/system-auth при аутентификации доменного пользователя под SSSD:

#%PAM-1.0

auth            [success=4 perm_denied=ignore default=die]      pam_localuser.so
auth            [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
auth            [default=1]     pam_permit.so
auth            substack        system-auth-sss-only
auth            [default=1]     pam_permit.so
auth            substack        system-auth-local-only
auth            substack        system-auth-common

account         [success=4 perm_denied=ignore default=die]      pam_localuser.so
account         [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
account         [default=1]     pam_permit.so
account         substack        system-auth-sss-only
account         [default=1]     pam_permit.so
account         substack        system-auth-local-only
account         substack        system-auth-common

password        [success=4 perm_denied=ignore default=die]      pam_localuser.so
password        [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
password        [default=1]     pam_permit.so
password        substack        system-auth-sss-only
password        [default=1]     pam_permit.so
password        substack        system-auth-local-only
password        substack        system-auth-common

session         [success=4 perm_denied=ignore default=die]      pam_localuser.so
session         [success=1 default=bad] pam_succeed_if.so uid >= 500 quiet
session         [default=1]     pam_permit.so
session         substack        system-auth-sss-only
session         [default=1]     pam_permit.so
session         substack        system-auth-local-only
session         substack        system-auth-common
session         [success=1 default=ignore] pam_succeed_if.so  service = systemd-user
session         optional        pam_mount.so disable_interactive

3. Устанавливаем правило монтирования ресурса в файле /etc/security/pam_mount.conf.xml:

<volume uid="10000-2000200000"
        fstype="cifs"
        server="c253.test.alt"
        path="sysvol"
        mountpoint="~/share"
        options="sec=krb5i,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>

где

• uid=»10000-2000200000″ — диапазон присваиваемых для доменных пользователей UID (подходит и для Winbind и для SSSD);
• server=»c253.test.alt» — имя сервера с ресурсом;
• path=»sysvol» — имя файлового ресурса;
• mountpoint=»~/share» — путь монтирования в домашней папке пользователя.

Опционально можно добавить:

• sgrp=»group_name» — имя группы, при членстве пользователя в которой, папка будет примонтирована.

Внимание! Обязательно указывайте настоящее имя сервера в параметре server, а не имя домена

Параметр sec=krb5i более безопасный, но требует больше вычислительных ресурсов. Вместо него можно указать sec=krb5.

Пример файла /etc/security/pam_mount.conf.xml:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

<!--
  См. pam_mount.conf(5) для описания.
-->

<pam_mount>

<!-- 
  Отладка должна быть раньше всего остального,
  т.к. этот файл все равно считываются за
  один проход сверху вниз
-->
<debug enable="0" />

<!-- Определение монтируемых томов -->
<volume uid="10000-2000200000"
        fstype="cifs"
        server="c253.test.alt"
        path="sysvol"
        mountpoint="~/share"
        options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />


<!--
  pam_mount parameters: General tunables
-->

<!--
<luserconf name=".pam_mount.conf.xml" />
-->

<!--
Обратите внимание, что если закомментировать mntoptions, то будут заданы значения по умолчанию.
Необходимо явно инициализировать его пустой строкой чтобы сбросить значения на по-умолчанию.
-->

<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,sec" />

<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->

<mntoptions require="nosuid,nodev" />

<!--
  Требуется наличие ofl из hxtools
-->

<logout wait="0" hup="no" term="no" kill="no" />

<!-- Параметры pam_mount: связанные тома -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">

<pam_mount>

<debug enable="0" />

<volume uid="10000-2000200000"
        fstype="cifs"
        server="c253.test.alt"
        path="sysvol"
        mountpoint="~/share"
        options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />


<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other,sec" />

<mntoptions require="nosuid,nodev" />

<logout wait="0" hup="no" term="no" kill="no" />

<mkmountpoint enable="1" remove="true" />

</pam_mount>

Для отладки подключения замените в файле /etc/security/pam_mount.conf.xml

на

При этом отладочные сообщения будут показываться в журнале Journald.

Вы можете сменить механизм монтирования отдав его на откуп systemd. Для этого в pam_mount.xml.conf можно задать\переопределить опции cifsmount, umount

  <cifsmount>systemd-mount -A -G -q -t cifs %(COMBOPATH) %(MNTPT) -o uid=%(USERUID),gid=%(USERGID),username=%(USER),%(OPTIONS)</cifsmount>
  <umount>systemd-mount -u %(MNTPT)</umount>

Советы

• Для того, чтобы подключенная папка не показывалась на рабочем столе Mate, следует в параметры добавить x-gvfs-hide.
• Если при выходе пользователя всё равно файловый ресурс остаётся подключенным, отмонтируйте его и удалите файл /run/pam_mount/<имя_пользователя>

Ссылки

• Групповые политики/Подключение сетевых дисков

Через autofs

В этом случае заданный ресурс подключается автоматически при каждом обращении пользователя и отключается после определенного времени бездействия (определяется конфигурацией Autofs).

Основная статья AutoFS

https://www.altlinux.org/Autofs

Для дистрибутивов c KDE

1. Установить kde5-autofs-shares:

   # apt-get install kde5-autofs-shares
   

2. Добавить в /etc/auto.master строку:

   /mnt/samba /etc/auto.smb -t 34567
   

   Здесь /mnt/samba — каталог в котором будут подключаться сетевые файловые системы, /etc/auto.smb — скрипт, входящий в состав пакета autofs, 34567 — таймаут подключения при отсутствии обращения.

3. Включить и запустить сервис autofs:

   # systemctl enable --now autofs
   

4. В файловом менеджере Dolphin по адресу smb:/ («Сеть»/«Общие папки Samba») найти нужный ресурс Windows (Samba)
5. В контекстном меню подключаемого ресурса (правая кнопка мыши) выбрать пункт «Подключение»:

   

   Картинка с сайта: www.altlinux.org

   Данный ресурс будет подключаться автоматически при входе в систему

Примечание: Список ресурсов для подключения хранится в файле ~/.autofs.shares

Внимание! Способ работает только для ресурсов с гостевым доступом или ресурсов с авторизацией Kerberos.

Групповые политики

Групповые политики (GPO) на Linux применяются только контроль входа через SSSD и средства Centrify.

SSSD

SSSD имеет внутреннюю поддержку следующих групповых политик:

Примечание: Планируется поддержка других групповых политик средствами подключаемых модулей

Примечание: Получение прав root см. root

Ссылки по групповым политикам

• https://fedoraproject.org/wiki/Changes/SssdGpoBasedAccessControl
• http://wiki.eri.ucsb.edu/stadm/AD_Samba4
• http://centrifying.blogspot.ru/2014/01/basics-using-group-policy-on-unixlinux.html
• https://www.youtube.com/watch?v=2cJWnUZ8qLI

Ссылки

• https://wiki.archlinux.org/index.php/Active_Directory_Integration
• Ввод в домен на базе Windows 2003
• https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
• https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member
• https://linux.samba.narkive.com/ceDM0TFO/samba-wbinfo-i-failed-to-call-wbcgetpwnam-wbc-err-domain-not-found

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

Механизм ввода машины в домен

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

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

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

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

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

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

На клиенте

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

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

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

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

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

  1. KVNO (Key Version Number) — номер версии ключа в системе аутентификации Kerberos. Когда ключ аутентификации учетной записи меняется (например, при ротации пароля), KVNO увеличивается. Это позволяет различать старые и новые версии ключей.
  2. Timestamp — время создания записи для ключа в keytab-файле.
  3. 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, необходимого для аутентификации. Ознакомиться с тем, как создать keytab файл на контроллере домена, можно в статье Capturing traffic.

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

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

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

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

Примечания

Конфликт имени машины и имени домена: необходимо избегать конфликта NetBIOS имени машины и NetBIOS имени домена. Убедитесь, что NetBIOS имя локальной машины (хоста) отличается от NetBIOS имени домена. Например, полное доменное имя машины (FQDN): host1.domain.alt. NetBIOS имя машины HOST1 отличается от NetBIOS имени домена DOMAIN.

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

Рекомендации (для имен хостов, больше 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

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

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

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

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

Пользователь

• На Linux-машинах пользователем, не наделенным правами администратора, ввод машины в домен невозможен.
• На Windows-машинах пользователь без дополнительных прав по умолчанию имеет возможность ввести в домен не более 10 рабочих станций Windows (изменить это число можно отредактировав атрибут ms-DS-MachineAccountQuota в оснастке Active Directory Service Interfaces Editors (ADSI Edit))

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

Администраторы в Active Directory могут вводить машины в домен, но возможность повторного ввода машины зависит от прав доступа к учётной записи компьютера в AD.

• На Linux-машинах администраторам домена предоставляется централизованный контроль, позволяя им создавать и перезаписывать учётные записи машин независимо от их владельца.

  Ввод Linux-машины:

  1. Центр управления системой:c тем, как ввести машину через ЦУС, можно ознакомиться в статье Alterator-auth .
  2. Командная строка: Ввод в AD домен клиента на ALT Linux.

• На Windows-машинах администратор имеет право вводить машины в домен, но не могут перезаписывать учётные записи, владельцами которых не являются.

  Как ввести Windows-машину в домен: официальная документация Microsoft.

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

• На Linux-машинах пользователи, принадлежащие группе Domain Admins и любой другой группе с правами администратора, имеют права на добавление машин в домен. Как добавить пользователя в группу и наделить ее правами можно ознакомиться в статье ADMC. В таком случае так же можно добавить машину в домен как через графический интерфейс (ЦУС), так и с помощью командной строки. Как это делать см. Ввод Linux-машины.

• На Windows-машинах пользователи, принадлежащие группе Domain Admins и любой другой группе с правами администратора, так же имеют права на добавление машин домен. С делегированием административных полномочий в Active Directory можно ознакомиться в статье.

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

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

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

• На Linux-машинах в таком случае необходимо предварительно на контроллере домена создать учетную запись машины и использовать ее при присоединении машины к домену. У созданной машинной учетной записи во вкладке Безопасность добавить необходимого пользователя в качестве доверенного лица и выставить разрешения на полный доступ. На клиенте во время вводы машины в домен используем созданную машинную учетную запись и учетную запись пользователя с правами подключения к домену. Узнать, как выполнить каждое действие, можно в статье ADMC
• На Windows-машинах с предоставлением права на добавление компьютеров в домен AD можно ознакомиться в статье Делегирование административных полномочий в Active Directory.

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

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

• На Linux-машинах первая машина с таким же именем теряет связь с доменом.

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

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

• На Windows-машинах первая машина с таким именем теряет связь с доменом.

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

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

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

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

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

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

Примечание: В ALT Linux для ввода машины в домен можно использовать как Winbind, так и SSSD. Предпочтительно использовать SSSD, а Winbind применять в случаях, когда требуется его уникальный функционал, недоступный в SSSD. Подробнее в статье: SSSD&Winbind

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

Чтобы воспользоваться этим способом, потребуется, в зависимости от того, какой метод будет использоваться для интеграции с доменом, установить соответствующий пакет (если он еще не установлен): task-auth-ad-sssd для SSSD или task-auth-ad-winbind для Winbind вместе со всеми зависимостями:

# apt-get install task-auth-ad-sssd
# apt-get install task-auth-ad-winbind

Также следует убедиться в наличии пакетов gpupdate и gpresult, и, если они отсутствуют, установить их:

# apt-get install gpupdate
# apt-get install gpresult

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

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

  

  Картинка с сайта: www.altlinux.org

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

  # 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, происходит подготовка машины (данные настройки выполняются автоматически):

1. Настройка Avahi-daemon — настройка порядка поиска имен хостов в файле nsswitch.conf, если используется домен с суффиксом .local. В таком случае поиск через DNS должен быть раньше поиска через mDNS (Multicast DNS).
2. Проверка DNS (проверка доступности Kerberos-сервера для указанного домена)

   $ host -t SRV _kerberos._tcp.domain.alt | grep 'SRV record'
   

3. Редактирование системных конфигураций

   • Настройки kerberos в файле /etc/krb5.conf

     • realm Kerberos по умолчанию:

       default_realm = DOM.LOC

     • отключение поиска realm Kerberos домена через DNS:

       dns_lookup_realm = false

     • включение поиска kdc (центра распределения ключей) через 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 /etc/sssd/sssd.conf

     • домены, которые обслуживает SSSD (секция [sssd]):

       domains = DOMAIN.ALT

     • добавляется раздел для конкретного домена [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):

       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
     

   • Настройка ролей и привилегий

     Использование модуля libnss-role:

     # control libnss-role enabled
     

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

     Domain Users связывается с локальной группой users:

     # roleadd 'Domain Users' users
     

     Domain Admins связывается с локальной группой localadmins:

     # roleadd 'Domain Admins' localadmins
     

   • Включение групповых политик

     Включение работы групповых политик и выбор шаблона локальной политики (local policy) выполняется командой gpupdate-setup:

   • Настройка менеджера дисплея LightDM

     Происходят в файле /etc/lightdm/lightdm.conf

     • Отключение отображения списка пользователей в приветствии в /etc/lightdm/lightdm.conf в разделе [SeatDefaults]:
     • Выключение отображения выбора языка на экране приветствия в файле /etc/lightdm/lightdm-gtk-greeter.conf в разделе [greeter]

       show-language-selector=false
       

       Если индикатор выбора языка не отключился, следует самостоятельно проверить параметр indicators, определяющий, какие индикаторы отображаются в графическом интерфейсе приветствия LightDM, и удалить элемент ~layout, который отвечает за выбор раскладки клавиатуры из списка доступных.

   • Синхронизация времени с контроллером домена перед присоединением

     net time set -S <имя домена>
     

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

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

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

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

Вывод машины из домена включает в себя следующие этапы:

1. Удаление учетной записи машины;
2. Переключение клиентской машины на локальную базу пользователей.

• На Linux-машинах удалить машинную учетную запись можно несколькими способами:

  • на контроллере домена с помощью # 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.

• На Windows-машинах: Remove-Computer.

Диагностика

• На Linux-машинах проверить локальные настройки системы и параметры службы каталогов для успешной работы клиента в составе домена можно с помощью diag-domain-client.

  Установка инструмента:

  # apt-get install diag-domain-client
  

  Синтаксис команды diag-domain-client:

  diag-domain-client [ОПЦИИ] [<test-function-name>]
  

  где test-function-name — название функции из списка тестов. Если не указывать название функции, будут запущены все тесты.

  Возможные опции:

  • -h, —help — показать справку и выйти;
  • -V, —version — вывести версию и выйти;
  • -v, —verbose — подробный вывод;
  • -w[FILE], —logfile[=FILE] — записать подробный протокол в файл по указанному пути. Если файл не указан, вывод будет записан в файл ./diag-domain-client.log. В случае если файл уже существует, то запись производится в файл с постфиксом (например, diag-domain-client.log.1, diag-domain-client.log.2 и т.д.);
  • -f, —force — принудительная запись в существующий файл;
  • -l, —list — вывести список тестов.

  Пример запуска всех тестов:

  # diag-domain-client:
  Check hostname persistance: [DONE]
  Test hostname is FQDN (not short): [DONE]
  System authentication method: [DONE]
  Domain system authentication enabled: [DONE]
  System policy method: [DONE]
  System group policy enabled: [DONE]
  Check Kerberos configuration exists: [DONE]
  Kerberos credential cache status: [DONE]
  Using keyring as kerberos credential cache: [DONE]
  Check DNS lookup kerberos KDC status: [DONE]
  Check machine crendetial cache is exists: [DONE]
  Check machine credentials list in keytab: [DONE]
  Check nameserver resolver configuration: [DONE]
  Compare krb5 realm and first search domain: [DONE]
  Check Samba configuration: [DONE]
  Compare samba and krb5 realms: [DONE]
  Check Samba domain realm: [DONE]
  Check hostname FQDN domainname: [DONE]
  Check time synchronization: [DONE]
  Time synchronization enabled: [WARN]
  Check nameservers availability: [DONE]
  Check domain controllers list: [DONE]
  Check Kerberos and LDAP SRV-records: [DONE]
  Compare NetBIOS name and hostname: [DONE]
  Check common packages: [DONE]
  Check group policy packages: [DONE]
  Check SSSD AD packages: [DONE]
  Check SSSD Winbind packages: [WARN]
  

  Подробнее с самим инструментом и каждой проверкой можно ознакомиться в статье Диагностические инструменты.

В организации на рабочих компьютерах сотрудников происходит постепенная замена операционных систем с MS Windows на Linux. При этом контроллер домена остаётся под управлением MS Windows Server. Нужно обеспечить вход пользователей на рабочие компьютеры с ОС Linux под своими доменными учётными записями.

Есть компьютер, где уже установлена ОС Alt Linux («Альт Рабочая станция» 10) с последними обновлениями.

При установке операционной системы был дополнительно указан для установки пункт «Активный каталог (AD)». Если его не указать, то перед включением компьютера в домен нужно будет обязательно установить пакет task-auth-ad-sssd со всеми зависимостями.

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

Заходим в «Пуск — Администрирование — Центр управления системой»:

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

В разделе «Пользователи» нажимаем на «Аутентификация»:

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

Здесь нужно выбрать «Домен Active Directory», проверить поля «Домен» и «Имя компьютера» (у меня они были заполнены автоматически), и нажать «Применить». Появится окно, где нужно ввести имя администратора домена (без указания домена) и его пароль:

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

После нажатия кнопки «ОК» должно появиться окно «Добро пожаловать в домен»:

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

После этого можно выходить из «Центра управления системой»:

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

Не перезагружая компьютер нужно внести изменения в файл /etc/krb5.conf

Для этих целей я подготовил файл krb5.conf следующего содержания:

includedir /etc/krb5.conf.d/


 
[logging]
# default = FILE:/var/log/krb5libs.log # при необходимости можно раскомментировать
# kdc = FILE:/var/log/krb5kdc.log
# admin_server = FILE:/var/log/kadmind.log


 
[libdefaults]
default_realm = <полное имя домена большими буквами>
# default_realm = EXAMPLE.COM # это пример написания
dns_lookup_kdc = true
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_ccache_name = KEYRING:persistent:%{uid}


 
[realms]
<полное имя домена большими буквами> = {
default_domain = <IP-адрес основного контроллера домена>
}


 
[domain_realm]
.<полное имя домена маленькими буквами> = <полное имя домена большими буквами>
<полное имя домена маленькими буквами> = <полное имя домена большими буквами>

И заменяю этим файлом тот, который был в системе изначально:

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

Теперь нужно перезагрузить компьютер. Всё компьютер в домене и можно заходить под доменной учётной записью.

Однако при попытке получить права суперпользователя (например, команда su-) из-под доменной учётки, появится сообщение «Отказано в доступе»:

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

Чтобы это исправить, нужно на контроллере домена создать группу (у меня в примере это linux-admins), в которую включить доменных пользователей, у которых будет такое право.

После этого на Linux-машине нужно снова авторизоваться под локальной (не доменной) учётной записью и выполнить команды:

roleadd localadmins wheel
roleadd linux-admins localadmins

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

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

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

1. Предварительно устанавливаем пакеты, необходимые для включения и более удобной настройки станции:
   samba-swat
   krb5-kinit
   libkrb5
   Для этого настраиваем службу управления пакетами apt для работы через прокси-сервер (если прокси-сервер используется в организации).
   В файле конфигурации /etc/apt/apt.conf прописываем строку:
   Acquire::ftp::Proxy»//root:password@127.0.0.1:8080″;
   и затем запускаем менеджер пакетов Synaptic через основное меню -> система -> менеджер пакетов. В меню «настройки» заходим в репозитории. Там ставим галочки напротив пунктов ftp://ftp.altlinux.org/pub/… И нажимаем OK. Затем жмем «получить сведения». Synaptic должен обновить список доступных пакетов из интернета. После чего через «поиск» ищем по ключевым словам нужные пакеты. В правой части окна появится список, где и надо выбрать нужные пакеты и нажать «применить». Пакеты установятся вместе с зависимостями.

2. Настраиваем сетевое окружение, после чего наш компьютер видит домен windows. В файле /etc/resolv.conf прописываем строку:
   nameserver ipaddr (где ipaddr — это ip адрес контроллера домена)

3. Делаем, чтобы сервис swat запускался автоматически: в файле /etc/xinet.d/swat
   меняем значение disable с yes на no и перезапускаем службу:
   
   service xinetd restart

4. Запускаем swat в браузере: http://localhost:901

5. Во вкладке GLOBALS ставим следующие значения:
   Security = ads (это режим domain member)
   Workgroup = WORKGROUP (or DOMAIN) ex. TEAM
   Realm = full domain name. ex. TEAM.LOCAL
   Netbios name = netbios имя нашего компьютера
   Подтверждаем изменения нажав кнопку commit changes наверху страницы.
   И последнее значение настраиваем, переключившись в режим advanced view:
   Password server = ip адрес контроллера домена
   Затем опять подтверждаем изменения.
   Далее во вкладке STATUS запускаем или перезапускаем службы smbd и nmbd.

6. Настраиваем службу аутентификации Kerberos.
   В файле /etc/krb5.conf ставим значек # перед всеми строками в разделе [libdefaults]. Этим мы заставляем Kerberos производить аутентификацию на контролере домена, а не на локальной машине. (# дает компилятору директиву не обрабатывать строку)

7. Подключаем станцию к домену. Выполняем команды:
   kinit administrator@realm (где администратор — это администратор домена и realm полное имя домена)
   net ads join -U administrator
   
   появляется приглашение о вводе пароля администратора, вводим его. После чего должны увидеть сообщение, что наш компьютер ввели в домен.

После установки ОС АЛЬТ в действующую ИТ-инфраструктуру или в тестовую среду, соответствующую продуктивной, ИТ-специалисты часто сталкиваются с вопросом: как ввести компьютер в домен службы каталогов. В основном, в Active Directory  от Microsoft.

Чтобы избежать проблем с вводом в домен, системному администратору необходимо убедиться, что служба синхронизации времени работает. И время на рабочей станции соответствует времени на домен-контроллере. Также на рабочей станции должны быть указаны правильные DNS-серверы, в которых присутствуют корректные SRV-записи, указывающие на работающий домен-контроллер.

В ОС АЛЬТ компьютер можно ввести в домен с помощью графического интерфейса. Для этого необходимо установить пакет task-auth-ad-sssd. Операция по вводу в домен рабочей стации через графический интерфейс достаточна проста, нужно лишь правильно указать следующие пункты:

1. тип домена (ALT Linux, Active Directory, FreeIPA);
2. правильное название домена;
3. правильное имя рабочей группы;
4. имя компьютера.

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

1. Компьютер подготовлен к вводу в домен, у него есть все необходимые данные.

   Системному администратору нужно изменить имя компьютера или оставить указанное при установке, проверить правильность домена и ввести компьютер в домен.

1. Появляется запрос на подтверждение полномочий пользователя на ввод в домен компьютера.

   В конфигурации по умолчанию права для ввода компьютера в домен есть у всех аутентифицированных пользователей домена (с ограничением в 10 компьютеров). У групп «Администраторы» домена и «Администраторы учета» этого ограничения нет.

1. Появляется сообщение об успешном вводе в домен.

   Администратор перезагружает компьютер, попадает в рабочий домен и может авторизоваться с помощью доменной учетной записи пользователя. Это функция, которая работает в Linux «из коробки». И с которой не должно быть сложностей.

1. Проверка успешного ввода в домен.

   Достаточно выполнить несколько команд, чтобы убедиться в том, что компьютер был успешно включен в домен Active Directory:

• net ads info – выводит информацию о домене, в котором состоит компьютер 
• net ads testjoin – выводит информацию о проверки связи с доменом

Однако, трудности, все же бывают. Например:

1. Использование зарезервированного домена .local. Для успешного подключения в домен с суффиксом суффикс .local необходимо отключить на рабочей станции службу и сокет avahi—daemon.

1. «Невозможно найти KDC указанного домена». Компьютер, на котором установлена ОС АЛЬТ (клиент), не может достучаться до домен-контроллера на Windows. Нужно проверить работу DNS-сервиса, убедиться, что с клиента корректно разрешаются имя домен-контроллера, сам домен, а также необходимые SRV-записи. После этого компьютер без проблем попадает в домен.

Как еще можно быстро и просто включить компьютер в домен?

Разработать модуль включения компьютеров в домен и настройки авторизации пользователей в системе централизованного управления конфигурациями и инфраструктурой на базе Puppet, как это сделали мы. Модуль позволяет включать в домен компьютеры, которые объединены общим логическим признаком (например, «новые рабочие станции»).

Для использования модуля достаточно указать название домена  и его тип (например, Active Directory). После включения компьютера в среду «новые рабочие станции», на нем автоматически применятся настройки, позволяющие ввести его в домен одной командой. Ввод команды обусловлен требованиями по информационной безопасности (передается пароль учетной записи, обладающей правами на ввод в домен).

Однако, для того, чтобы отечественное ПО в данном случае работало действительно хорошо, нужно снять два самых частых ограничения при работе компьютера с ОС АЛЬТ в домене Active Directory.

Ограничение №1. Сопоставление доменных групп безопасности с локальными

Ситуация. Администратору нужно выполнить настройки для сопоставления доменных групп безопасности с локальными группами. Чтобы у группы безопасности администраторов рабочих станций, применяемых к Windows-клиентам, были одновременно и права администратора и в ОС АЛЬТ. К примеру, если администратор входит в группу «Администраторы домена», он не будет добавлен в группу wheel. При этом выполнять настройки по сопоставлению нужно на каждом компьютере, вручную. Потому что групповые политики по добавлению группы безопасности из Active Directory в локальную группу на компьютере с ОС АЛЬТ не применяются.

Как снять ограничение. Использовать систему централизованного управления конфигурациями и инфраструктурой – например, на базе Puppet. С ее помощью можно распространить нужное состояние и параметры на любое количество компьютеров – в автоматизированном режиме.

Если добавляется доменная группа администратора рабочих станций, то система управления конфигурациями позволяет «раскатать» ее сразу на десятки, сотни или даже тысячи компьютеров. И администраторы рабочих станций на доменных рабочих станциях с ОС Windows, без проблем становятся еще и администраторами на компьютерах с ОС АЛЬТ. Не надо подключаться к каждому компьютеру, вводить последовательность команд вручную. Отпадает и необходимость в создании «костыльных» скриптов, которые полуавтоматизируют процесс, обладая при этом существенными недостатками (например, нет журналирования событий). Нужно просто описать, какое состояние рабочей станции необходимо получить. И дождаться результата. Группа компьютеров будет получать указанную администратором конфигурацию с  серверов системы управления конфигурациями.  

Ограничение №2. Подключение сетевых ресурсов

Ситуация. При организации файлового сервиса в Windows-инфраструктуре зачастую используются пространства DFS (Distributed File System). И публикация файловых ресурсов. При этом у многих системных администраторов возникает вопрос: «Как и под каким пользователем правильно подключить предоставляемый пользователю сетевой ресурс»?

Казалось бы, для подключения сетевого ресурса можно использовать пользователя, который в данный момент работает за компьютером, или выделить отдельного, Но это не совсем корректно. Потому что за одним и тем же компьютером могут работать разные доменные пользователи, тогда прав на запись информации у них не будет. Или пароль отдельного пользователя будет храниться в файловой системе в открытом виде. В этом случае могут быть предоставлены некорректные права, дающие доступ к файлам для всех. Что небезопасно.

Как снять ограничение. Можно подключать сетевые ресурсы с помощью модуля PAM (Pluggable Authentication Modules) – pam_mount. Использование этого метода позволяет подключать сетевой ресурс от имени активного доменного пользователя с назначенными ему правами, вводя при этом пароль только раз – при входе в систему. К примеру, так мы подключаем сетевой ресурс «Консультант Плюс» на сервере Windows.

Мы подключаем его под доменным пользователем, который авторизовался на рабочей станции, и запуск «Консультанта» проходит без проблем. Для организации доступа к DFS-пространствам: при успешном входе пользователя сетевой ресурс автоматически подключается. Пользователь обладает всеми теми же правами, что и в случае подключения ресурса с Windows-клиента.

И снова – при десятках, сотнях и тысячах компьютеров подключить вручную сетевые ресурсы нереально. Начинают требоваться «костыли» или же трудозатраты становятся непомерными. Поэтому мы и тут используем разработанную нами централизованную систему управления конфигурациями и инфраструктурой на базе Puppet. Мы написали для нее модуль, помогающий автоматизировано, с минимальными затратами сил и времени, подключать сетевые ресурсы. При добавлении нового сетевого ресурса, достаточно будет объявить его в распространяемой конфигурации. Эта информация приходит на указанную администратором группу компьютеров. А пользователи видят сетевой ресурс на рабочих столах своих компьютеров — при следующем входе в систему.

Автор: Дмитрий Кияев, инженер DevOps в ALP Group