Linux ssh active directory

Настройка SSH на CentOS с аутентификацией через Active Directory

Мы рассмотрим простые примеры команд, которые позволят настроить аутентификацию пользователей Active Directory на Linux для входа по SSH. Данная инструкция подойдет для CentOS версий 7 и 8.

Подготовка сервера

Обновляем список пакетов:

Задаем имя компьютеру:

hostnamectl set-hostname mypc.domain.local

Устанавливаем часовой пояс (у меня московское время):

timedatectl set-timezone Europe/Moscow

Устанавливаем сервис для синхронизации времени и запускаем его:

yum install chrony

systemctl enable chronyd —now

Настройка аутентификации SSH через AD

yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

• realmd — сервис для автоматического поиска и конфигурирования AD.
• sssd — пакет программ, с помощью которого можно настраивать аутентификацию и авторизацию в системах на базе UNIX.
• oddjob — служба, которая принимает запросы по D-BUS (системная шина сообщений) на выполнение действий.
• oddjob-mkhomedir — в соответствии с названием, пакет позволяет отправить запрос на создание домашнего каталога пользователя.
• adcli — утилита для ввода компьютера в домен.
• samba-common и samba-common-tools — набор пакетов для выполнения запросов к файлам и принтерам клиентов Microsoft Windows.

Сканируем наш домен:

realm discover DOMAIN.LOCAL

Вводим компьютер в домен:

realm join -U username DOMAIN.LOCAL

* DOMAIN.LOCAL — ваш домен.
** username — имя учетной записи с правом вводить компьютер в домен.

Настраиваем sssd для возможности вводить логин без префикса домена:

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

authconfig —enablemkhomedir —enablesssdauth —updateall

Запускаем сервис sssd:

systemctl enable sssd.service

systemctl restart sssd

Готово. Пробуем зайти по SSH под доменной учетной записью.

Аутентификация по группам AD

Мы настроили возможность авторизовываться в системе для любого пользователя в Active Directory. Попробуем ограничить доступ с помощью групп безопасности.

Мы можем задать настройки в конфигурационном файле:

simple_allow_groups = Domain Admins@domain.local

* где в данном примере предоставлен доступ все пользователям группы Domain Admins.

После внесения изменений нужно перезагрузить сервис sssd:

systemctl restart sssd

Также мы можем управлять настройками командами.

Сначала очистим доступ:

Теперь дадим разрешение для 3-х групп:

realm permit -g «Domain Admins»@domain.local

realm permit -g «Тестовая группа»@domain.local

realm permit -g ssh@domain.local

* данные команды разрешают вход пользователям групп Domain Admins, Тестовая группа, ssh.

Источник

Вики 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 и последующей корректной работы аутентификации/авторизации на базе доменных учётных записей.

Дополнительные источники информации:

Проверено на следующих конфигурациях:

Версия ОС
Debian GNU/Linux 10.1 (Buster)

Автор первичной редакции:
Алексей Максимов
Время публикации: 13.09.2019 16:43

Источник

На сцене вновь лауреаты международных конкурсов SSH и sudo. Под рукодством заслуженного дирижера Active Directory

/.ssh/authorized_keys. Однако с ростом инфраструктуры возникает желание управлять этими правами централизованно. На сегодняшний день вариантов решения может быть несколько:

• Система управления конфигурацией — Chef, Puppet, Ansible, Salt
• Active Directory + sssd
• Разнообразные извращения в виде скриптов и ручного редактирования файлов

На мой субъективный взгляд, оптимальным вариантом централизованного управления является все-таки связка Active Directory + sssd. Преимущества данного подхода вот в чем:

• Действительно Единый централизованный каталог пользователей.
• Раздача прав sudo сводится к добавлению пользователя в определенную группу безопасности.
• В случае различных Linux-систем возникает необходимость вводить дополнительные проверки на определение ОС при использовании систем конфигурации.

Сегодняшняя сюита будет посвящена именно связке Active Directory + sssd для управления правами sudo и хранением ssh ключей в едином репозитории.
Итак, зал застыл в напряженном молчании, дирижер поднял палочку, оркестр приготовился.
Поехали.

Дано:

• Домен Active Directory testopf.local на Windows Server 2012 R2.
• Linux хост под управлением Centos 7
• Настроенная авторизация с использованием sssd

Оба решения вносят изменения в схему Active Directory, поэтому проверяем все на тестовом окружении и только потом вносим изменения в рабочую инфраструктуру. Хочу заметить — все изменения точечные и, по сути, добавляют лишь необходимые атрибуты и классы.

Действие 1: управление sudo ролями через Active Directory.

Для расширения схемы Active Directory необходимо скачать последний релиз sudo — 1.8.27 на сегодняшний день. Распаковываем, копируем файл schema.ActiveDirectory из каталога ./doc на контроллер домена. Из командной строки с правами администратора из директории, куда скопировали файл, запускаем:

ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Не забываем подставлять свои значения)

Открываем adsiedit.msc и подключаемся к контексту по умолчанию:

В корне домена создаем подразделение sudoers. (Буржуины упорно утверждают, что именно в этом подразделении демон sssd производит поиск на предмет sudoRole объектов. Однако, после включения детального дебага и изучения логов, было выявлено, что поиск производится по всему дереву каталога.)

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

Среди возможных доступных атрибутов из расширения схемы основными являются следующие:

• sudoCommand — определяет, какие команды разрешены к выполнению на хосте.
• sudoHost — определяет для каких хостов применяется данная роль. Может быть задано как ALL, так и для отдельного хоста по имени. Также возможно использование маски.
• sudoUser — указываем, каким пользователям разрешено выполнение sudo.
  В случае указания группы безопасности, в начале имени добавляем знак “%”. Если в имени группы присутствуют пробелы, беспокоиться не о чем. Судя по логам, задачу экранирования пробелов берет на себя механизм sssd.

рис 1. Объекты sudoRole в подразделении sudoers в корне каталога

рис 2. Членство в группах безопасности, указанных в sudoRole-объектах.

Следующая настройка производится на стороне Linux.

В файле /etc/nsswitch.conf добавляем в конец файла строку:

В файле /etc/sssd/sssd.conf в секции [sssd] в сервисы добавляем sudo

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

Частенько случается так, что очистка кэша не помогает. Тогда останавливаем сервис, чистим базу, стартуем сервис.

Подключаемся под первым пользователем и проверяем, что ему доступно из-под sudo:

То же самое проделываем со вторым нашим пользователем:

Подобный подход позволяет централизованно определять роли sudo для различных групп пользователей.

Хранение и использование ssh ключей в Active Directory

При небольшом расширении схемы есть возможность хранить ключи ssh в атрибутах пользователя Active Directory и использовать их при авторизации на Linux хостах.

Должна быть настроена авторизация через sssd.

Добавляем нужный атрибут при помощи PowerShell скрипта.

Function New-AttributeID <
$Prefix=«1.2.840.113556.1.8000.2554»
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),«AllowHexSpecifier»)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),«AllowHexSpecifier»)
$oid=[String]::Format(«<0>.<1>.<2>.<3>.<4>.<5>.<6>.<7>«,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
>
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$attributes = @ <
lDAPDisplayName = ‘sshPublicKey’;
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = «2.5.5.5»;
isSingleValued = $true;
adminDescription = ‘User Public key for SSH login’;
>

New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter ‘name -eq «user»’
$userSchema | Set-ADObject -Add @

После добавления атрибута нужно перезапустить службу Active Directory Domain Services.
Переходим к пользователям Active Directory. Любым удобным для Вас способом генерируем пару ключей для ssh подключения.

Запускаем PuttyGen, нажимаем кнопочку «Generate» и судорожно елозим мышью в пределах пустой области.

По завершению процесса мы можем сохранить публичный и приватные ключи, залить публичный ключ в атрибут пользователя Active Directory и наслаждаться процессом. Однако публичный ключ необходимо использовать из окна «Public key for pasting into OpenSSH authorized_keys file:«.

Добавляем ключ в атрибут пользователя.

Вариант 2 — PowerShell:

Итак, мы имеем на текущий момент: пользователь с заполненным атрибутом sshPublicKey, настроенный клиент Putty для авторизации по ключам. Остается один небольшой момент, как же заставить демон sshd вытягивать нужный нам публичный ключ из атрибутов пользователя. С этим успешно справляется небольшой скрипт, найденный на просторах буржуйского интернета.

Выставляем на него права 0500 для root.

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

Меня лично очень смущал момент пароля в чистом виде в скрипте, несмотря на выставленные права.

Сохраняю пароль в отдельный файл:

Выставляю права на файл 0500 для root

Меняю параметры запуска ldapsearch: параметр -w superSecretPassword меняю на -y /usr/local/etc/secretpass

Финальным аккордом в сегодняшней сюите редактируем sshd_config

Как следствие, получаем следующую последовательность при настроенной авторизации по ключам в ssh клиенте:

1. Пользователь подключается к серверу, указывая свой логин.
2. Демон sshd через скрипт вытягивает значение публичного ключа из атрибута пользователя в Active Directory и проводит авторизацию по ключам.
3. Демон sssd производит дальнейшую аутентификацию пользователя на основании принадлежности к группе. Внимание! Если таковая не сконфигурирована, то любой пользователь домена будет иметь доступ к хосту.
4. При попытке sudo происходит поиск демоном sssd в каталоге Active Directory на предмет ролей. При наличии ролей проверяются атрибуты и членство пользователя в группе (если sudoRoles настроены на использовании групп пользователей)

Таким образом ключи хранятся в атрибутах пользователя Active Directory, разрешения sudo — аналогично, доступ к хостам Linux по доменным учетным записям осуществляется путем проверки принадлежности к группе Active Directory.

Финальный взмах дирижерской палочки — и зал замирает в благоговейной тишине.

Источник