Ввод debian 9.4 в домен Active Directory.
Здравствуйте! Имеется: 1) контроллер домена на базе Microsoft Server 2012 R2 с именем test.local; 2) тестовая машина на основе debian 9.4.
И у нас возникает ошибка при вводе команды
Вывод текста с ошибками
Помогите, пожалуйста, разобраться!
у тебя правда домен test.local или это ты замазал реальное название?
Все строки с именем домена были заменены на test.
ну вроде как но спотыкается на уровне получения тикета по керберос, и для начала я бы не использовал тут кириллицу. сделай другую учетку админа домена на английском. очень надеюсь, что проблема в этом. Чуваки, использующие русский языке на серверах должны страдать.
Мы пробовали и на английском. Не помогает
А настройки Kerberos проверяли? Команда
Отрабатывает,только вместо администратор,логин с латинскими символами.
только вместо администратор,логин с латинскими символами.
Ну так попытайтесь тогда к домену присоединиться с тем же логином.
Написали же, что пробовали и так, и так. Два одинаковых админа, просто один на латинице, другой с кириллицей. В centos 7 все без проблем, в debian такая вот проблема.
Не по теме, но в 2018-м году ( хорошо, у вас сервак 2012 R2 ) админы устанавливающие tld .local должны страдать. Повторю, это не по теме, но страданий ожидайте.
так и покажите лог, где латинская учетка, которая умеет делать kinit.
Просто так исторически сложилось (лет 6 прошло:), но уже в этом году запланировали миграцию на другое доменное имя. Что касается пользователя, повторюсь, пробовали по всякому, дело не в пользователе. Завтра с работы выложу логи, с таким же выводом.
Та же самая ошибка.
Попробовать создать учетку компа заранее на АДе. Если присоединит, то разбираться.
Вообще сначала бы надо разбирться.
1) masyagutovmz — это domain admin?
2) В одном месте masyagutovmz, в другом masyagutov_mz. Попробуй делать realm join с опцией —user=masyagutov_mz@TEST.LOCAL, что-ли.
3) Убедись, что SPN для твоего хоста не существует. С виндовой машины: setspn -Q HOST/comp195-debian.test.local. Если вдруг данная команда покажет, что данный SPN есть, то удали его.
4) Using computer account name: comp195-debian.test.local Хм. Длинноватое имя для аккаунта компьютера. Для pre-Win2000 имен максимальная длина 20 символов, а у тебя 25. Попробуй без FQDN, что-ли.
5) Компьютерные аккаунты у вас точно в CN=Computers держат? Просто некоторые его редиректят.
4) На realmd свет клином не сошелся. Это всего лишь обертка для ламеров. Присоединиться к домену можно с помощью «net ads join».
Это всего лишь обертка для ламеров.
Ну дык..😉
Ну и справедливости ради обёртка всё-таки над другим. Хотя может (мог?) и в нет адс.
Обертка, облегчающая создание конфигов krb5.conf/sssd.conf/smb.conf и присоединение к домену.
Ну да.
По идее если принципал уже есть то он должен обновить. Да и хостнейм оно само должно найти без опции. Впрочем, если автор путается в юзернейме, то.
вот это точно неправильно, как минимум надо —computer-name=comp195-debian
По ссылке в твоей статье:
Такое длинное имя аккаунта компьютера просто обрежется до 20 символов, отсюда скорее всего и получаем «Server not found in Kerberos database».
По идее если принципал уже есть то он должен обновить
Даже если SPN определен в другом computer/user аккаунте? Мне казалось, что она всегда пытается создать новый аккаунт.
Впрочем, я сам realmd не пользуюсь, у нас лес с несколькими доменами, realmd в такой конфигурации не катит.
1) masyagutov_mz — администратор домена. 2) это опечатка 3) Ввод команды setspn -Q HOST/comp195-debian.test.local показал такое SPN не найдено. 4) Пробовали короткое имя Comp195 с FQDN и без, та же самая ошибка. 5) Там у нас вновь введенные ПК хранятся. 6) Мы не хотим использовать samba пакет.
Тогда tcpdump на 88 порт (Kerberos) и смотреть, какой SPN он пытался найти в AD.
Кстати — почему ты пытаешься джойниться в домен server_dc.test.local?
Исходя из man realm, должно быть просто test.local:
realm join . test.local
Вопрос решен.
Разобрались сами. Изменили настройки в конфигурации /etc/nsswitch.conf.
Спасибо всем кто пытался нам помочь.
С такими подходами вангую ещё много проблем.
А как выглядела эта строка в /etc/nsswitch.conf до этого?
Просто «hosts: files» что-ли?
Ведь он же резолвил SRV-записи,и выглядело так, как будто с резолвингов все в порядке:
hosts: files mdns4_minimal [NOTFOUND=return] dns
Вики IT-KB
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Содержание
Подключение Debian GNU/Linux 10 (Buster) к домену Active Directory с помощью SSSD/realmd и настройка PAM для аутентификации и авторизации sshd/Apache
Подробное описание процедуры присоединения компьютера с Debian GNU/Linux к домену Active Directory с помощью SSSD и realmd можно найти здесь. Рекомендуется предварительно ознакомится с этим материалом, а также с замечаниями по настройке SSSD в Debian GNU/Linux.
Здесь приведён сокращённый план действий по присоединению Debian GNU/Linux 10 (Buster) к домену Active Directory с помощью SSSD и realmd.
Подготовка
Выполним команду присвоения полного доменного имени в качестве имени хоста, так как по умолчанию в Debian 10 в качестве hostname используется имя узла без доменной части. Это позволит избежать некоторых проблем при вводе компьютера в домен с помощью realmd:
Дополнительно необходимо отредактировать файл /etc/hosts и указать там в качестве IP адреса хоста адрес одного из сетевых интерфейсов. То есть, строку вида:
заменяем на строку вида:
Если требуется, предварительно создаём в домене учётную запись компьютера
Установка realmd/SSSD и ввод в домен
Устанавливаем пакеты необходимые для ввода в домен:
Выполняем обнаружение информации о домене, которое должно отработать без ошибок:
Настраиваем информацию о компьютере, которая будет передана в каталог Active Directory при присоединении к домену.
Выполняем присоединение компьютера к домену Active Directory:
Поддержка Kerberos
Устанавливаем клиентское ПО поддержки Kerberos:
Проверяем наличие и содержимое keytab-файла. В нём, как минимум, должны быть записи типа host/*
Настраиваем конфигурацию клиента Kerberos:
Пример настроенного файла:
Конфигурация SSSD
Настраиваем конфигурацию SSSD:
Пример настроенной конфигурации:
Перезапускаем службу с очисткой кеша sssd:
Выполняем проверку возможности извлечения информации из каталога Active Directory.
Получаем информацию о любой доменной группе безопасности:
Получаем информацию о любом доменной пользователе:
PAM и домашний каталог
Предварительно рекомендуется ознакомится со статьёй Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM, где более подробно описан смысл всех производимых далее настроек системы.
Настраиваем базовую конфигурацию PAM
Правим файл common-session :
В конец файла добавим строку, позволяющую создать домашний каталог в случае его отсутствия:
PAM и доступ на консоль
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к консоли компьютера:
Ограничим доступ к файлу:
Отредактируем модуль PAM, определяющий права доступа к консоли компьютера:
Вставляем перед блоком со строкой @include common-account ссылку на вызов авторизации через созданный нами файл ( access-groups-to-login )
Выполняем проверку входа в систему, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
PAM и доступ к SSH
Отредактируем PAM-модуль, отвечающий за настроку авторизации при подключении через службу сервера SSH
Вставляем перед блоком со строкой @include common-account ссылку на вызов авторизации через созданный нами файл ( access-groups-to-login )
Выполняем проверку входа в систему через SSH, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
PAM и доступ к Apache
Пример создания собственного PAM-модуля для других служб, например, для организации доменной аутентфикации/авторизации в веб-сервере Apache:
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к веб-серверу:
Создадим конфигурационный файл — PAM-модуль
Ограничим доступ к файлам:
SSHD и PuTTy
Подробно про пример настройки сквозной проверки подлинности при использовании PuTTY читаем в статье SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory
Включаем сквозную проверку подлинности для прозрачного подключения с PuTTY
Перезапустим службу сервера
Разрешаем sudo для доменных учётных записей.
Создадим отдельный файл для выдачи прав выполнять sudo доменным учётным записям:
Пример содержимого файла с одной доменной группой доступа, которой разрешено выполнять sudo без ограничений:
Ограничим доступ к файлу
Расширение keytab
В случае необходимости настроки Kerberos аутентификациии в домене Active Directory, возможно потребуется дополнительная настройка keytab-файла на Linux системе.
Пример команд добавления SPN-записи типа HTTP/* (для поддержки доменной аутентификации Kerberos на веб-сервере) Подключаемся к keytab-файлу и получаем информацию о SPN-запиях в нём и текущем номере kvno (нужен для ключа -k )
Добавляем записи поддержки Kerberos для веб-сервера (при запросе хешей указываем те же, что указаны для уже существующих SPN-записей)
Перечиваем результат и записываем изменения в keytab-файл:
Проверяем есть ли нужная SPN-запись в домене (на Windows-машине, присоединённой к домену)
Если записи нет, можем добавить (требуются права уровня доменный администратор)
Apache и PAM с Kerberos
Настраиваем конфигурацию Apache для поддержки аутентификации Kerberos
Установка пакетов поддержки PAM/Kerberos в Apache:
Включение модулей Apache:
Пример файла конфигурации Apache:
В данном примере в Apache для доступа к веб-серверу Apache вызывается настроенный нами ранее PAM-модуль apache2 (через файл /etc/pam.d/apache2 ) PAM-модуль в свою очередь вызывает для процедуры аутентификации SSSD и выполняет авторизацию через файл /etc/security/access-groups-to-web
Не забываем на строне Linux-сервера настроить доступ к keytab-файлу
Перезепускаем службу веб-сервера и проверяем результат:
Финиш
По завершении всех процедур настройки можно вернуть имя хоста в исходное состояние, «привычное» для Debain.
После завершения настройки перезагружаем Linux-сервере, чтобы убедиться в успешном автоматическом запуске SSSD и последующей корректной работы аутентификации/авторизации на базе доменных учётных записей.
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 13.09.2019 16:43
Вики IT-KB
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Содержание
Подключение Debian GNU/Linux 9 (Stretch) к домену Active Directory с помощью SSSD/realmd и настройка PAM для аутентификации и авторизации sshd/Apache
Подробное описание процедуры присоединения компьютера с Debian GNU/Linux к домену Active Directory с помощью SSSD и realmd можно найти здесь. Рекомендуется предварительно ознакомится с этим материалом, а также с замечаниями по настройке SSSD в Debian GNU/Linux.
Здесь приведён сокращённый план действий по присоединению Debian GNU/Linux 9 (Stretch) к домену Active Directory с помощью SSSD и realmd.
Подготовка
Выполняем команду присвоения полного доменного имени в качестве имени хоста, так как по умолчанию в Debian 9 в качестве hostname используется имя узла без доменной части. Это позволит избежать некоторых проблем при вводе компьютера в домен с помощью realmd:
Дополнительно необходимо отредактировать файл /etc/hosts и указать там в качестве IP адреса хоста адрес одного из сетевых интерфейсов. То есть, строку вида:
заменяем на строку вида:
Если требуется, предварительно создаём в домене учётную запись компьютера
Установка realmd/SSSD и ввод в домен
Устанавливаем пакеты необходимые для ввода в домен:
Выполняем обнаружение информации о домене, которое должно отработать без ошибок:
Настраиваем информацию о компьютере, которая будет передана в каталог Active Directory при присоединении к домену.
Устанавливаем пакеты, необходимые для работы SSSD
Выполняем присоединение компьютера к домену Active Directory:
Поддержка Kerberos
Устанавливаем клиентское ПО поддержки Kerberos:
Проверяем наличие и содержимое keytab-файла. В нём, как минимум, должны быть записи типа host/*
Настраиваем конфигурацию клиента Kerberos:
Пример настроенного файла:
Конфигурация SSSD
Настраиваем конфигурацию SSSD:
Пример настроенной конфигурации:
Перезапускаем службу с очисткой кеша sssd:
Выполняем проверку возможности извлечения информации из каталога Active Directory.
Получаем информацию о любой доменной группе безопасности:
Получаем информацию о любом доменной пользователе:
PAM и домашний каталог
Предварительно рекомендуется ознакомится со статьёй Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM, где более подробно описан смысл всех производимых далее настроек системы.
Настраиваем базовую конфигурацию PAM
Правим файл common-session :
В конец файла добавим строку, позволяющую создать домашний каталог в случае его отсутствия:
PAM и доступ на консоль
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к консоли компьютера:
Ограничим доступ к файлу:
Отредактируем модуль PAM, определяющий права доступа к консоли компьютера:
Вставляем перед директивой common-account … ссылку на вызов авторизации через созданный нами файл ( access-groups-to-login )
Выполняем проверку входа в систему, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
PAM и доступ к SSH
Отредактируем PAM-модуль, отвечающий за настроку авторизации при подключении через службу сервера SSH
Вставляем перед директивой common-account … ссылку на вызов авторизации через созданный нами файл ( access-groups-to-login )
Выполняем проверку входа в систему через SSH, используя разрешённую и неразрешённую доменную учётную запись. При этом отслеживаем происходящее в механизмах аутентификации/авторизации через системный лог auth.log
PAM и доступ к Apache
Пример создания собственного PAM-модуля для других служб, например, для организации доменной аутентфикации/авторизации в веб-сервере Apache:
Создадим свой файл для перечисления учётных записей (доменных и локальных), которым будет разрешёно подключение к веб-серверу:
Создадим конфигурационный файл — PAM-модуль
Ограничим доступ к файлам:
SSHD и PuTTy
Подробно про пример настройки сквозной проверки подлинности при использовании PuTTY читаем в статье SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory
Включаем сквозную проверку подлинности для прозрачного подключения с PuTTY
Перезапустим службу сервера
Разрешаем sudo для доменных учётных записей.
Создадим отдельный файл для выдачи прав выполнять sudo доменным учётным записям:
Пример содержимого файла с одной доменной группой доступа, которой разрешено выполнять sudo без ограничений:
Ограничим доступ к файлу
Расширение keytab
В случае необходимости настроки Kerberos аутентификациии в домене Active Directory, возможно потребуется дополнительная настройка keytab-файла на Linux системе.
Пример команд добавления SPN-записи типа HTTP/* (для поддержки доменной аутентификации Kerberos на веб-сервере) Подключаемся к keytab-файлу и получаем информацию о SPN-запиях в нём и текущем номере kvno (нужен для ключа -k )
Добавляем записи поддержки Kerberos для веб-сервера (при запросе хешей указываем те же, что указаны для уже существующих SPN-записей)
Перечиваем результат и записываем изменения в keytab-файл:
Проверяем есть ли нужная SPN-запись в домене (на Windows-машине, присоединённой к домену)
Если записи нет, можем добавить (требуются права уровня доменный администратор)
Apache и PAM с Kerberos
Настраиваем конфигурацию Apache для поддержки аутентификации Kerberos
Установка пакетов поддержки PAM/Kerberos в Apache:
Включение модулей Apache:
Пример файла конфигурации Apache:
В данном примере в Apache для доступа к веб-серверу Apache вызывается настроенный нами ранее PAM-модуль apache2 (через файл /etc/pam.d/apache2 ) PAM-модуль в свою очередь вызывает для процедуры аутентификации SSSD и выполняет авторизацию через файл /etc/security/access-groups-to-web
Не забываем на строне Linux-сервера настроить доступ к keytab-файлу
Перезепускаем службу веб-сервера и проверяем результат:
Финиш
По завершении всех процедур настройки можно вернуть имя хоста в исходное состояние, «привычное» для Debain.
После завершения настройки перезагружаем Linux-сервере, чтобы убедиться в успешном автоматическом запуске SSSD и последующей корректной работы аутентификации/авторизации на базе доменных учётных записей.
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 25.06.2019 09:11