Мой блог - Полноценный ввод рабочей станции Ubuntu Linux в Windows-домен

Полноценный ввод рабочей станции Ubuntu Linux в Windows-домен

Рабочая станция или сервер под управлением Linux-дистрибутива в Windows домене, миф или реальность? Давно уже не только реальность, а еще и достаточно типовая задача решаемая при помощи пошаговой инструкции, а если ее переложить в виде скрипта, то ввод в домен будет не сложнее чем при использовании родных утилит Windows. Так как последние версии Samba позволяют вводить рабочую станцию или сервер под управлением OS Linux в домен Windows практически без "танцев с бубном", мы проработали подробный план по вводу в домен для систем на базе Ubuntu Linux. Данная инструкция была многократно опробирована, как в рамках крупных проектов, так и типовых интерграйий Ubuntu Workstations с Windows Active Directory.

Фотография автора

Автор: Антон Черноусов
Опубликовано: 2 месяца, 3 недели (последние правки: 0 минут назад) - 4 комментария
Категории записи: Active Directory, Linux, Samba, Ubuntu, Windows, Популярное, Рабочие станции, Системное администрирование


Рабочая станция или сервер под управлением Linux-дистрибутива в Windows домене - миф или реальность? Давно уже не только реальность, а еще и достаточно типовая задача решаемая при помощи пошаговой инструкции, а если ее переложить в виде скрипта, то ввод в домен будет не сложнее чем при использовании родных утилит Windows.

Так как, последние версии Samba позволяют вводить рабочую станцию или сервер под управлением OS Linux в домен Windows практически без "танцев с бубном", мы проработали подробный план по вводу в домен для систем на базе Ubuntu Linux.

Данная инструкция была многократно апробирована, как в рамках крупных проектов, так и типовых интеграций Ubuntu Workstations с Windows Active Directory.

Цели:

  • Интегрировать рабочую станцию в домен INFERNO
  • Реализовать возможность авторизации с использованием учетных записей домена
  • Организовать доступ к рабочей станции для определенных групп пользователей
  • Предоставить административные функции (sudo) для определенной группы пользователей
  • Организовать общий сетевой ресурс и ограничить доступ для определенных групп пользователей
  • Дополнительно предоставить возможность offline-авторизации в случае временной недоступности домена

Установка и настройка:

Установим пакеты, необходимые для интеграции с Windows-доменом:

# aptitude install krb5-user samba winbind libnss-winbind libpam-winbind

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

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

nameserver 172.16.0.3
search inferno.inferno.com

В случае использования автогенерируемого файла resolv.conf (средствами resolvconf) в файл /etc/interfaces необходимо добавить записи:

dns-nameservers 172.16.0.3
dns-search inferno.inferno.com

Основой работы Windows-домена уровня включая 2003 и выше является служба Kerberos, за пользовательскую часть которой, отвечает пакет krb5-user. На этапе установки пакета у вас будет запрошен REALM-домена и адреса Kerberos серверов обслуживающих домен.

В последних версиях пакета эта информация не требуется и все сведения для нормального функционирования Kerberos-клиента получаются посредством DNS-запросов к сервисным записям, а конфигурационный файл /etc/krb5.conf приобретает вид:

[libdefaults]
 default_realm = INFERNO.INFERNO.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = true
 ticket_lifetime = 24h
 forwardable = yes
[login]
 krb4_convert = true
 krb4_get_tickets = false

Проверить корректность настроек службы Kerberos можно выполнив команду получения «билета»:

# kinit chernousov@INFERNO.INFERNO.COM

Обратите внимание, что имя домена указано прописными буквами - это принципиальный момент ,в противном случае,вы получите ошибку: kinit: KDC reply did not match expectations while getting initial credentials). Проверьте полученные "билеты" командой klist, и если вы получили список выданных "билетов" kerberos, то можно приступать к присоединению рабочей станции к домену. Ввод рабочей станции или сервера под управлением OS Linux несколько сложнее чем Windows.

И первым этапом необходимо провести базовую настройку конфигурационного файла /etc/samba/smb.conf и минимальный файл конфигурации достаточный для подключения к домену windows (с комментариями) приведен ниже:

[global]
 # Рабочая группа (Сокращенное наименование домена)
 workgroup = INFERNO
 # Описание сервера отопражается при выводе перечня компьютеров домена или рабочей группы
 # %h (системное имя linux хоста).
 server string = %h server (Samba, Ubuntu)
 # Выключаем встроенный wins-сервер.
 wins support = no
 # Полное имя домена к которому подключена станция
 realm = INFERNO.INFERNO.COM
 # Разрешаем nmbd поиск NetBIOS имен с использованием DNS.
 dns proxy = yes
 # Расположение log-файлов.
 log file = /var/log/samba/log.%m
 # Ограничивам размер каждого log-файла в килобайтах.
 max log size = 1000
 # В syslog пишем только минимум информации, например о
 #крахе службы (основные данные в персональный log samba)
 syslog = 0
 # Можно назначить скрипт который будет отпабатывать в случае
 # краха службы samba (например перезапуск и отправка письма администраторам)
 # panic action = /usr/share/samba/panic-action %d
 # Роль сервера (отдельный сервер или член домена)
 server role = member server
 # Запросы с неправильным паролем будут отклонены, если такое имя пользователя существует.
 # Если не существует, то такие запросы будут считаться как попытки зайти гостем
 map to guest = bad user
 # Интерпретатор командной строки для доменных пользователей
 template shell = /bin/bash

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

# net ads join -U "chernousov@INFERNO.INFERNO.COM"

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

Enter chernousov@INFERNO.INFERNO.COM's password:
Using short domain name -- INFERNO
Joined 'INFER-ANALYSER' to dns domain 'inferno.inferno.com'

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

Перезапускаем службы smbd, nmbd и winbind.

# service smbd restart
# service nmbd restart
# service winbind restart

Настраиваем обработку учетных данных пользователей домена на рабочей станции Linux

При интеграции служб учетных записей Windows и Linux необходимо учитывать, что Windows использует SID-записи, а Linux использует UID и GID. Преобразование из одного типа записей в другой может осуществляться несколькими методами, разница в которых состоит лишь в том, будут ли числовые идентификаторы Linux-пользователей вошедших при помощи домена идентичными на всех рабочих станциях Linux подключенных к домену, или нет.

Для обеспечения уникальности числовых идентификаторов GID и UID предназначена служба Active Directory Microsoft Windows Services для UNIX (служба NIS), описываемая RFC 2307. В случае развертывания службы, становится доступна дополнительная вкладка Unix Attributes в свойствах пользователя, где необходимо задать GID и UID для каждого из пользователей. Такой метод необходим только в ряде случаев взаимодействия Unix-сервисов, например, в случае использования NFS ,как показывает практика,можно обойтись без обеспечения такого функционала. Так же, имеются некоторые проблемы, которые могут возникнуть в результате использования RFC 2307, например, в случае если администратор забудет назначить Unix-идентификаторы, получение сведений о пользователе вызовет ошибку. Мы не будем рассматривать сервисы RFC 2307 (возможно, я рассмотрю их позже если читателям будет интересно, конечно же).

Рассмотрим несколько типовых команд wbinfo, которые нам понадобятся в дальнейшем.

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

# wbinfo -u
INFERNO\guest
INFERNO\administrator
INFERNO\tsinternetuser
INFERNO\iusr_dc
INFERNO\iwam_dc
INFERNO\iusr_dc2
INFERNO\valiev
INFERNO\mac
INFERNO\verkeev
INFERNO\bochevarov
INFERNO\vdgg

Получаем список доменных групп:

# wbinfo -g
INFERNO\domain users
INFERNO\domain computers
INFERNO\domain guests
INFERNO\group policy creator owners
INFERNO\domain admins

Получаем Windows SID пользователя:

# wbinfo --name-to-sid="INFERNO\Chernousov"
S-1-5-21-1177238915-436374069-1343024091-5713 SID_USER (1)

Преобразовываем Windows SID в Linux UID:

# wbinfo --sid-to-uid=S-1-5-21-1177238915-436374069-1343024091-5713-1 

На этом месте остановимся подробнее.

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

-1

Это означает, что служба конвертации идентификаторов работает неправильно.

Модифицируем наш конфигурационный файл, добавив в него следующие параметры:

idmap config *:backend = tdb
idmap config *:range = 10000 - 49999
После модификации перезапустим службы и проверим выполнение команды преобразования идентификаторов:
# wbinfo --sid-to-uid=S-1-5-21-1177238915-436374069-1343024091-571310001

В этом режиме на каждом клиенте используется собственная база данных для преобразования имен в Windows и Linux идентификаторы, и для работы с учетными записями домена и Kerberos этого вполне достаточно, но обратите внимание на переменную range и она описывает диапазон, исходя из которого, будут выдаваться Unix-идентификаторы в процессе запроса данных. Этим, собственно, и объясняются расхождения UID для пользователей домена на разных рабочих станциях.

Настраиваем связку «Локальный пользователь → Доменный пользователь».

Это достаточно просто. Необходимо в конфигурационный файл /etc/nsswitch.conf к параметрам passwd и group добавить метод winbind, в результате должно получиться вот так:

passwd: compat winbind
group: compat winbind

Для задействования этого функционала необходима установленная библиотека libnss-winbind. Следующим этапом необходимо удостовериться, что интеграция доменных учетных записей прошла успешно, для этого выполните следующую команду:

# id "INFERNO\chernousov"

Если все правильно, то вы увидите список доменных групп и их преобразование в локальные идентификаторы. Например, вот так:

uid=10001(INFERNO\chernousov) gid=10000(INFERNO\domain users) группы=10000(INFERNO\domain users),
10001(INFERNO\группа с запрещением репликации паролей rodc),10002(INFERNO\domain admins),
10003(INFERNO\rocket_access),10004(INFERNO\unix users),10005(INFERNO\unix admins)

Так же, рекомендую проверить назначение домашнего каталога и интерфейса командной строки для пользователя по умолчанию. Для этого служит команда getent:

# getent passwd "INFERNO\chernousov"

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

INFERNO\chernousov:*:10001:10000:Anton Chernousov:/home/INFERNO/chernousov:/bin/bash

Следующим этапом рассмотрим авторизацию пользователей и вопросы разграничения доступа.

За авторизацию доменных пользователей отвечает библиотека libpam-winbind.

Описания методов PAM-авторизации пользователей находятся в каталоге /etc/pam.d/ и при установке библиотеки необходимые параметры настраиваются автоматически. Можете проверить доступ, попробовав подключиться к рабочей станции по SSH указав учетные данные доменного пользователя.

# ssh "INFERNO\chernousov"@172.16.3.61

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

# dpkg-reconfigure libpam-runtime

Выберите параметр «Create home directory on login» и повторите вход доменным пользователем, если все прошло успешно, то каталог будет создан автоматически.

По умолчанию, всем пользователям домена разрешен доступ на рабочую станцию, но нам требуется определить доступ определенной группе пользователей домена, а остальным запретить. Для этого служит конфигурационный файл /etc/security/pam_winbind.conf по умолчанию он отсутствует, но вы можете скопировать его из каталога /usr/share/doc/libpam-winbind/examples/pam_winbind.conf.

В данном файле можно настроить несколько параметров, как я уже сказал выше, разрешим доступ только для одной группы пользователей, для чего определим ее SID в домене:

# wbinfo --name-to-sid="INFERNO\unix users"
S-1-5-21-1177238915-436374069-1343024091-5725 SID_DOM_GROUP (2)

И установим параметр require_membership_of в полученный SID:

require_membership_of = S-1-5-21-1177238915-436374069-1343024091-5725

В данном файле мы можем, так же, настроить параметры кеширования учетных данных и offline-авторизации:

cached_login = yes

Для работы offline авторизации в конфигурационный файл /etc/samba/smb.conf необходимо добавить параметр:

winbind offline logon = yes

Так-же, нам необходимо предоставить определенной группе пользователей права администратора на этой рабочей станции. В linux-терминологии предоставим им доступ к выполнению любых операций через sudo. Для этого в файл /etc/sudoers добавим доменную группу INFERNO\unix admins:

%INFERNO\\unix\ admins ALL=(ALL:ALL) ALL

Обратите внимание на экранирование пробелов и символа\.

Следующим этапом разрешим пользователям доступ определенным каталогам на linux-машине по протоколу smb (общие ресурсы Windows). Например, предоставим доменным пользователям доступ к каталогу /opt/share с правами только на чтение.

Создадим каталог /opt/share и установим его группу владельцев в «пользователи домена»:

# mkdir /opt/share
# chgrp -R "INFERNO\domain users" /opt/share

В файл /etc/samba/smb.conf добавим описание ресурса и ограничим доступ к нему для группы пользователей домена.

[share]
 comment = Public domain share
 path = /opt/share/
 browseable = yes
 read only = no
 create mask = 0775
 directory mask = 0775
 valid users = @"INFERNO\domain users"
Пожалуйста, оцените мою статью (всего оценок 4, средняя оценка 5.00):

Комментарии к статье:

Sergey 2 месяца, 1 неделя назад

Не верю я что это работает.

Ссылка | Ответ

Anton Chernousov 2 месяца, 1 неделя назад

Правда работает, проверьте.

Ссылка | Ответ

Станислав 1 месяц, 3 недели назад

Действительно работает. Перелопатил не один десяток статей на эту тему, но только благодаря этой смог окончательно реализовать задачу. Во всех статьях, почему-то был упущен вопрос о преобразовании SID в UID, возможно подразумевалось, что оно должно происходить на стороне сервера службой NIS... Но тем не менее, только благодаря описанной здесь методике разобрался что к чему... Спасибо автору.

Ссылка | Ответ

Anton Chernousov 1 месяц, 3 недели назад

Есть еще службы Unix для Windows, но это не NIS, а надстройка над схемой Active Directory. Там можно вручную задавать соотношения к внутренним Linux GID UID, но как показала практика от этой балалайки больше вреда чем пользы.

Ссылка | Ответ

Оставьте комментарий:

обязательно

обязательно (не публикуется)

необязательно

обязательно

обязательно