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

Введение

Ввод компьютера под управлением Astra Linux в домен Windows Active Directory или в домен Samba может быть выполнен двумя способами:

1. С использованием инструментария sssd:
   1. графический инструмент fly-admin-ad-sssd-client;
   2. инструмент командной строки astra-ad-sssd-client;

2. С использованием инструментария winbind:

   Инструментарий winbind устарел, не поддерживает полной функциональности и не рекомендуется к использованию. Рекомендованным инструментарием является sssd.

   1. графический инструмент fly-admin-ad-client;
   2. инструмент командной строки astra-winbind;

Далее рассматривается установка и использование этих инструментов. Рекомендованным способом ввода в домен является ввод с использованием sssd. Дополнительную информацию про winbind и sssd см. Сравнение winbind и sssd.

Конфигурация стенда

Инструменты SSSD

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

Установить графический инструмент fly-admin-ad-sssd-client можно используя графический менеджер пакетов synaptic или из командной строки командой:

sudo apt install fly-admin-ad-sssd-client

При установке графического инструмента будет автоматически установлен инструмент командной строки astra-ad-sssd-client.

После установки пакет доступен в графическом меню:

• в Astra Linux Special Edition 1.8: «Пуск» → «Параметры» → «Клиент и сервер» → «Настройка клиента SSSD Fly»;
• в более ранних обновлениях:  «Пуск» → «Панель управления» → «Сеть» → «Настройка клиента SSSD Fly».

Для ввода компьютера Astra Linux в домен Active Directory:

1. Запустить инструмент:
   
   

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

2. После запуска инструмента указать:
   1. имя домена, к которому требуется подключиться;
   2. имя и пароль администратора домена;
   3. опционально — IP-адрес, который должен быть назначен клиенту (для Astra Linux Special Edition 1.8, в более ранних обновлениях назначение IP-адреса не поддерживается);
   4. нажать кнопку «Подключиться»:

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

Инструмент командной строки astra-ad-sssd-client автоматически устанавливается при установке графического инструмента fly-admin-ad-sssd-client. При необходимости работать в командной строке без использования графики инструмент может быть установлен отдельно:

sudo apt install astra-ad-sssd-client

Ввод компьютера в домен может быть выполнен командой:

sudo astra-ad-sssd-client -d example.com -u Администратор

где:

• -d example.com — указание имени домена;
• -u Администратор — указание имени администратора домена;

Примерный диалог при выполнении команды:

compname = astra01
domain = example.com
username = admin
введите пароль администратора домена:
ok
продолжать ? (y\N)
y
настройка сервисов...
Завершено.
Компьютер подключен к домену.
Для продолжения работы, необходимо перезагрузить компьютер!

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

sudo reboot

Подсказка по команде astra-ad-sssd-client:

sudo astra-ad-sssd-client -h
Usage: astra-ad-sssd-client <ключи>
ключи:
-h,--help   этот текст
-d   домен. если отсутствует, берется из hostname.resolv.conf
-y   отключает запрос подтверждения
-i   информация по текущему подключению
-u   логин администратора домена
-n   сервер времени.
-px  получает пароль администратора домена от внешнего сценария
     через перенаправление стандартного ввода (stdin)
-p   пароль администратора домена
-U   удаление
--par <параметры>   указать дополнительные параметры вручную (для realm)
-fn,  --fullnames   использовать полные имена пользователей вида 'admin@domain.ru' (доступно при установке актуального оперативного обновления)
-sn,  --shortnames  использовать короткие имена пользователей вида 'admin' (по умолчанию) (доступно при установке актуального оперативного обновления) 

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

1. Получить билет Kerberos от имени администратора домена:

   kinit admin@dc01.example.com

2. Проверить статус подключения:

   sudo astra-ad-sssd-client -i

Примеры

Подключение к домену domain.net с именем администратора admin и (небезопасным!) указанием пароля администратора, без запроса подтверждения:

sudo astra-ad-sssd-client -d domain.net -u admin -p 12345678 -y

Подключение к домену domain.net с именем администратора admin и с использованием пароля администратора из файла /root/pass, без запроса подтверждения:

cat /root/pass | sudo astra-ad-sssd-client -d domain.net -u admin -px -y

Подключение к домену domain.net без запроса подтверждения:

sudo astra-ad-sssd-client -d domain.net -y

Получение информации о текущем домене

sudo astra-ad-sssd-client -i

Удаление данных подключения:

sudo astra-ad-sssd-client -U

Удаление компьютера из домена Windows AD

Для удаления компьютера из домена (удаление механизма авторизации) используйте команду:

sudo astra-ad-sssd-client -U

Автоматическое обновление пароля доменного компьютера в связке sssd+samba

Службы sssd и samba могут самостоятельно периодически обновлять пароль компьютера. На компьютерах, введенных в домен с помощью инструмента astra-ad-sssd-client, используется обновление пароля только службой sssd.  Обновление пароля службой samba по умолчанию отключено в конфигурации этой службы.  Обновление пароля службой samba недопустимо и ведет к невозможности работы компьютера в домене. При внесении изменений в конфигурацию службы samba для предотвращения включения обновления пароля необходимо соблюдать следующие требования:

• параметр kerberos method должно иметь значение secrets and keytab (это значение присваивается по умолчанию при вводе в домен):
  

  kerberos method = secrets and keytab

• если параметру kerberos method присвоено иное значение, то должен быть задан параметр machine password timeout со значением 0:
  

  machine password timeout = 0

Особенности ввода в домены Windows AD 2008

При вводе компьютеров Astra Linux в домены Windows AD тип домена определяется автоматически. В соответствии с типом домена выбирается ПО для подключения. При работе со старыми версиями Windows AD (в частности, при работе с Windows AD 2008) автоматически выбираемое ПО может работать некорректно. В таких случаях для устранения ошибок ввода может потребоваться принудительно задать тип домена adcli (опция —par «-membership-software=adcli»). Пример команды:

sudo astra-ad-sssd-client -d <имя_домена> -u <имя_администратора_домена> —par «—membership-software=adcli»

Инструменты Winbind

sudo astra-winbind -h
Usage: astra-winbind <ключи>
ключи:
-h   этот текст
-dc  имя контроллера домена. если FQDN, ключ -d можно опустить
-d   домен. если отсутствует, берется из файла /etc/resolv.conf
-g   группа. если отсутствует, берется из домена
-n   сервер времени. если нет, используется контроллер домена
-y   отключает запрос подтверждения
-i   информация по текущему подключению
-u   логин администратора домена
-px  получает пароль администратора домена из stdin
-p   пароль администратора домена (небезопасно)
-s   разрешить и запустить службу подключения к домену
-S   запретить и остановить службу подключения к домену
-l   вывести компьютер из домена

примеры:
полное имя контроллера домена и отключение запроса подтверждения
    astra-winbind -dc astra01.atws.as -u admin -p password -y
сторонний сервер времени и запрос пароля в процессе
    astra-winbind -dc astra01 -d atws.as -n 192.168.5.7 -u admin
передача пароля через stdin, домен ищется в resolv.conf
    echo  | ./astra-winbind -dc astra01 -u admin -px -y
информация о текущем домене
    astra-winbind -i

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

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

Ввод машины в домен — это процесс, в результате которого компьютер становится частью инфраструктуры 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]
  

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

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

Всем привет!

Термин 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?

Общая информация

Если вам нужно просто предоставить сетевой доступ к ресурсам Linux компьютера, то смотрите статью Samba.

В этой статье мы опишем как подключить Linux компьютер к домену под управлением Microsoft Active Directory и сделать из него файловый сервер.

После выполнения этой инструкции мы будем иметь в сети файловый сервер под управлением ОС Линукс, входящий в домен Windows 2003 и ничем не отличающийся от файлового сервера под Windows. Пользователи домена смогут обращаться к его ресурсам под своими учётными записями. Доступ регулируется группами домена AD.

По этой инструкции настраивались Debian (4, 5), Ubuntu 9.10, создавалась она на основе официальной документации и многих рекомендаций и инструкций из Интернета. Остальные Linux’ы настраиваются сходным образом.

Для Alt Linux написана хорошая инструкция http://freesource.info/wiki/AltLinux/Dokumentacija/SambaInWin2kDomain?v=omo&

Проверка требований

• Проверяем что Samba собрана с поддержкой Kerberos:

# smbd -b | grep KRB

   HAVE_KRB5_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_DECODE_KRB5_AP_REQ
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_C_ENCTYPE_COMPARE
   HAVE_KRB5_C_VERIFY_CHECKSUM
   HAVE_KRB5_ENCRYPT_BLOCK
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_FREE_AP_REQ
   HAVE_KRB5_FREE_DATA_CONTENTS
   HAVE_KRB5_FREE_KEYTAB_ENTRY_CONTENTS
   HAVE_KRB5_FREE_KTYPES
   HAVE_KRB5_FREE_UNPARSED_NAME
   HAVE_KRB5_GET_PERMITTED_ENCTYPES
   HAVE_KRB5_GET_RENEWED_CREDS
   HAVE_KRB5_KEYBLOCK_IN_CREDS
   HAVE_KRB5_KEYTAB_ENTRY_KEY
   HAVE_KRB5_KEYUSAGE_APP_DATA_CKSUM
   HAVE_KRB5_KT_FREE_ENTRY
   HAVE_KRB5_LOCATE_KDC
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL2SALT
   HAVE_KRB5_PRINC_COMPONENT
   HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
   HAVE_KRB5_SET_REAL_TIME
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_TKT_ENC_PART2
   HAVE_KRB5_USE_ENCTYPE
   HAVE_LIBGSSAPI_KRB5
   HAVE_LIBKRB5
   HAVE_MAGIC_IN_KRB5_ADDRESS
   HAVE_TICKET_POINTER_IN_KRB5_AP_REQ
   KRB5_VERIFY_CHECKSUM_ARGS

• Также проверим что поддерживается LDAP

# smbd -b | grep LDAP

   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_ADD_RESULT_ENTRY
   HAVE_LDAP_DN2AD_CANONICAL
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

• Для корректной работы Samba в домене Windows 2003 нужны версии MIT Kerberos version >=1.3.1. Проверим:

# dpkg -l | grep krb

ii  krb5-config    1.22                       Configuration files for Kerberos Version 5
ii  libkrb53       1.6.dfsg.4~beta1-5lenny1   MIT Kerberos runtime libraries

• Для корректной работы с Windows 2008 серверами сама Samba должна быть достаточно свежая:

# smbd -V

Version 3.2.5

Установка Samba

• Устанавливаем сервер и клиент samba.

# apt-get install samba samba-client krb5-config

При настройке krb5-config лучше указывать IP адреса контроллеров домена, а не их DNS имена.

Настройка Samba

• Для подключения к домену Active Directory удобно использовать утилиту Likewise-Open.

• Для администрирования Samba удобно использовать SWAT или webmin, которые предоставляют веб интерфейс. Попасть на него можно по адресу http://server_address:901 и https://server_address:10000 соответственно, указав для соединения пользователя root. Но будьте осторожны — он полностью переписывает smb.conf и некоторые параметры может просто игнорировать. Лучше предварительно сделать резервную копию файла. Я сначала использовал SWAT, а затем дорабатывал конфигурационный файл /etc/samba/smb.conf руками. Вот, что осталось у меня не закоментированным (принтеры к этому серверу не подключены):

[global]
        unix charset = LOCALE
        realm = WORKGROUP.DOMAIN.LOCAL
        server string = Storage samba server
        interfaces = eth0
        bind interfaces only = Yes
        security = ADS
        obey pam restrictions = Yes
        passdb backend = tdbsam
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .
        log level = 3
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 100
        name resolve order = lmhosts host wins bcast
        printcap name = CUPS
        local master = No
        domain master = No
        dns proxy = No        
        ldap ssl = no
        panic action = /usr/share/samba/panic-action %d
        idmap uid = 10000-20000
        idmap gid = 10000-20000
        template shell = /bin/bash
        invalid users = root

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

[distrib]
        path = /data/distrib
        valid users = @WORKGROUP\DistribGroup
        write list = @WORKGROUP\DistribGroup
        read only = No
        create mask = 0777
        directory mask = 0777

[backup]
        path = /data/backup
        valid users = @WORKGROUP\BackupGroup
        write list = @WORKGROUP\BackupGroup
        read only = No
        create mask = 0777
        directory mask = 0777

Мы описали два общих каталога:

• backup — доступ имеют только пользователи входящие в группу BackupGroup в Active Directory. Они могут создавать и удалять файлы/каталоги
• distrib — доступ имеют все пользователи входящие в группу DistribGroup в Active Directory

В приведённой конфигурации подразумевается, что eth0 — это сетевой интерфейс в локальную сеть, где домен имеет полное имя WORKGROUP.DOMAIN.LOCAL

• редактируем /etc/nsswitch:

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind

hosts:          files dns wins
networks:       files dns

protocols:      files
services:       files
ethers:         files
rpc:            files

netgroup:       files

• Проверим, что в /etc/hosts есть корректная запись для нашего сервера, также можно добавить записи для контроллеров доменов:

10.0.0.15      storage.domain.local storage
10.0.0.85      dcwg1.domain.local dcwg1
10.0.0.245     dcwg2.domain.local dcwg2

• Удаляем если есть (или переносим в резервные копии) файл /etc/samba/secrets.tdb и все файлы из /var/lib/samba/*.tdb

• Проверяем конфигурацию (не обязательно):

1. testparm -s

В Ubunto testparm находится в пакете samba-common-bin

• Проверим как Samba-3 winbind общается с контроллером домена Active Directory посредством протокола Kerberos:

# net ads info

LDAP server: 10.0.0.85
LDAP server name: dcwg1.workgroup.domain.local
Realm: WORKGROUP.DOMAIN.LOCAL
Bind Path: dc=WORKGROUP,dc=DOMAIN,dc=LOCAL
LDAP port: 389
Server time: Срд, 03 Мар 2010 13:12:14 NOVT
KDC server: 10.0.0.85
Server time offset: -5

На рассхождение времени в секундах указывает строка «Server time offset: -5». Обратите внимание, что протокол Kerberos зависим от времени, и расхождение с часами контроллера домена допускается лишь незначительное, поэтому желательно настроить NTP клиент (см. статьи по настройке NTP). В Ubuntu это указывается в файле /etc/default/ntpdate:

NTPSERVERS="10.0.0.85 10.0.0.245"

• В Debian (и его сыновьях, таких как Ubuntu и внуках вроде Linux Mint) при установке пакета krb5-cofig сразу предлагается его настройка. Лучше всего попробовать работать с этими настройками, но если ничего предложено не было или мы хотим что-то изменить, то редактируем /etc/krb5.conf (я для более стабильной работы использовал ip адреса вместо имён серверов):

[libdefaults]
        default_realm = WORKGROUP.DOMAIN.LOCAL

# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
#
#...
#
# The following libdefaults parameters are only for Heimdal Kerberos.
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true

[realms]
        WORKGROUP.DOMAIN.LOCAL = {
                kdc = 10.0.0.85
                kdc = 10.0.0.245
                admin_server = 10.0.0.85
        }
#
#...
#
[login]
        krb4_convert = true
        krb4_get_tickets = false

• Проверим работает ли Kerberos, постараемся получить билет и просмотреть его:

# kinit administrator@WORKGROUP.DOMAIN.LOCAL
Password for administrator@WORKGROUP.DOMAIN.LOCAL:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@WORKGROUP.DOMAIN.LOCAL

Valid starting     Expires            Service principal
03/06/10 14:51:41  03/07/10 00:51:47  krbtgt/WORKGROUP.DOMAIN.LOCAL@WORKGROUP.DOMAIN.LOCAL
        renew until 03/07/10 14:51:41

• Удалим полученный билет:

# kdestroy

• Присоединяемся к домену:

# net ads join -UAdministrator

Administrator's password:
Using short domain name -- WORKGROUP
Joined 'STORAGE' to realm 'WORKGROUP.DOMAIN.LOCAL'

Всё, компьютер включен в домен, что можно проверить на контроллере. Даже если после приведённых строк получили следующие:

[2010/03/06 15:04:00,  0] libads/kerberos.c:332(ads_kinit_password)
  kerberos_kinit_password STORAGE$@WORKGROUP.DOMAIN.LOCAL failed: Client not found in Kerberos database DNS update failed!

Проверка работы и отладка

• Для удобства отладки сделаем ссылку на каталог журналов:

# ln -s /var/log/samba /etc/samba/log

• Запускаем samba и winbind:

# /etc/init.d/samba start
# /etc/init.d/winbind start

• Для проверки правильно ли подключение к домену можно посмотреть список пользователей и групп домена (не обязательно):

# wbinfo -u
# wbinfo -g

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

# wbinfo --set-auth-user=root%root_password
# wbinfo --all-domains
# wbinfo -D WORKGROUP
# wbinfo -t

• Проверяем, как работает NSS. Команда getent показывает инфо о пользователе, который может быть как в домене, так и юниксовый:

# getent passwd | grep pm
pm:x:15000:15000::/home/WORKGROUP/pm:/bin/false

# getent passwd | grep pavel
pavel:x:500:500:Pavel Malahov:/home/pavel:/bin/bash

• Теперь можно использовать ресурсы на линукс-сервере, на которые мы дали доступ, как обычные доменные ресурсы.

Дополнительная настройка

• Можно также сопоставить (но это не обязательно) локальные учётные данные и из домена Windows. Для сопоставления пользователей редактируем файл /etc/samba/smbusers.conf:

root = admin administrator

• для сопоставления (мапирования от англ. Map) групп домена и групп UNIX выполняем:

# net groupmap modify ntgroup="Domain Admins" unixgroup=root
# net groupmap modify ntgroup="Domain Users" unixgroup=users
# net groupmap modify ntgroup="Domain Guests" unixgroup=nobody

• После того как всё отлажено, можно понизить уровень записи в журнал до «1». В /etc/samba/smb.conf:

log level = 1

Доступ к Samba из Windows 7 и 2008 r2

Начиная с этих версий параметры авторизации у MS поменялись. Скорее всего Samba вскоре это учтёт, а пока подружить системы можно изменив на Win7 свойства сетевой безопасности:

Пуск — Панель управления — Администрирование — Локальная политика безопасности — Локальные политики — Параметры безопасности

• Сетевая безопасность: минимальная сеансовая безопасность для клиентов на базе NTLM SSP — убрать галочку с «Требовать 128-битное шифрование». Таких параметра два — выполнить для обоих
• Сетевая безопасность: уровень проверки подлинности LAN Manager — выбрать в списке пункт «Отправлять LM- и NTML-ответы»

Работа над ошибками

Winbind не запускается

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

# /etc/init.d/winbind status
 * winbind is not running

В журнале log.winbindd обнаруживаем запись:

[2010/03/06 13:54:34,  2] winbindd/winbindd_util.c:235(add_trusted_domain)
  Added domain BUILTIN  S-1-5-32
[2010/03/06 13:54:34,  2] winbindd/winbindd_util.c:235(add_trusted_domain)
  Added domain STORAGE  S-1-5-21-3963871611-1338977097-196861091
[2010/03/06 13:54:34,  0] winbindd/winbindd_util.c:782(init_domain_list)
  Could not fetch our SID - did we join?
[2010/03/06 13:54:34,  0] winbindd/winbindd.c:1385(main)
  unable to initialize domain list

Видим, что добавлен «встроенный домен» (BUILTIN) и домен «название компьютера» (STORAGE), подключиться к домену AD не удалось.

Решение: Переподключить компьютер в домен. Удалять придётся с самого контроллера, т.к. комадна net ads leave скорее всего не поможет.

Ошибка получения билета Kerberos

При попытке получить билет Kerberos получили:

kinit: KDC reply did not match expectations while getting initial credentials

Решение: указать имя домена в другом регистре. Скорее всего нужны все заглавные

Полезная ссылка: http://subscribe.ru/archive/comp.soft.win.linuxsa/200510/19115643.html

Полезные комманды

См. также

• Статья Samba даёт краткий общий обзор пакета Samba утилит для него, а также описывает простой (без авторизации в домене) способ предоставления каталогов в общий доступ.

Cсылки

• http://linux.yaroslavl.ru//docs/serv/samba/samba-win2000.html — Samba и доменная аутентификация Windows2000
• http://us6.samba.org/samba/docs/man/Samba-Guide/unixclients.html#adssdm- Active Directory Domain with Samba Domain Member Server — подробная инструкция как подключить Linux сервер с помощью Samba 3 к домену под управлением AD Windows 2003.
• http://us6.samba.org/samba/docs/man/Samba-Guide/kerberos.html#id397375 — пример настройки доступа для пользователей Active Directory
• Samba-HOWTO-Collection.pdf, стр.54-57 (поставляется с исходниками) или
• http://jcifs.samba.org/ntstatus.txt — описание статусов