Active Directory authentication for SQL Server on Linux
Applies to: SQL Server (all supported versions) — Linux
This article provides an overview of Active Directory (AD) authentication for SQL Server on Linux. AD authentication is also known as Integrated authentication in SQL Server.
AD authentication overview
AD authentication enables domain-joined clients on either Windows or Linux to authenticate to SQL Server using their domain credentials and the Kerberos protocol.
AD Authentication has the following advantages over SQL Server Authentication:
- Users authenticate via single sign-on, without being prompted for a password.
- By creating logins for AD groups, you can manage access and permissions in SQL Server using AD group memberships.
- Each user has a single identity across your organization, so you don’t have to keep track of which SQL Server logins correspond to which people.
- AD enables you to enforce a centralized password policy across your organization.
Configuration steps
In order to use Active Directory authentication, you must have an AD Domain Controller (Windows) on your network.
The details for how to configure AD authentication are provided in the tutorial, Tutorial: Use Active Directory authentication with SQL Server on Linux. The following list provides a summary with a link to each section in the tutorial:
Known issues
- At this time, the only authentication method supported for database mirroring endpoint is CERTIFICATE . WINDOWS authentication method will be enabled in a future release.
- SQL Server on Linux does not support NTLM protocol for remote connections. Local connection may work using NTLM.
Next Steps
For more information on how to implement Active Directory authentication for SQL Server on Linux, see Tutorial: Use Active Directory authentication with SQL Server on Linux.
Источник
Linux в домене Active Directory
Перед администраторами иногда встают задачи интеграции Linux серверов и рабочих станций в среду домена Active Directory. Обычно требуется:
1. Предоставить доступ к сервисам на Linux сервере пользователям домена.
2. Пустить на Linux сервер администраторов под своими доменными учётными данными.
3. Настроить вход на Linux рабочую станцию для пользователей домена, причём желательно, чтобы они могли при этом вкусить все прелести SSO (Я, например, не очень люблю часто вводить свой длинный-предлинный пароль).
Обычно для предоставления Linux системе пользователей и групп из домена Active Directory используют winbind либо настраивают библиотеки nss для работы с контроллером домена Active Directory по LDAP протоколу. Но сегодня мы пойдём иным путём: будем использовать PowerBroker Identity Services (Продукт известен также под именем Likewise).
Установка.
Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.
Получить Open версию можно на сайте производителя, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.
Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Исходники (Open edition) доступны в git репозирории: git://source.pbis.beyondtrust.com/pbis.git
Я устанавливал PBIS на Debian Wheezy amd64:
Содержимое пакета устанавливается в /opt/pbis. Также в системе появляется новый runscript lwsmd, который собственно запускает агента PBIS.
В систему добавляется модуль PAM pap_lsass.so.
Утилиты (большей частью консольные), необходимые для функционирования PBIS, а также облегчающие жизнь администратору размещаются в /opt/pbis/bin
Ввод в домен.
Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)
Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.
Для ввода в домен потребуется указать: имя домена, логин и пароль доменного пользователя с правами для ввода ПК в домен, контейнер для размещения объекта компьютера в домене — всё то же самое, что и при вводе в домен windows ПК. 
После ввода в домен потребуется перезагрузка.
Обратите внимание — PBIS умеет работать с сайтами Active Directory. Клиент PBIS будет работать с контроллерами того сайта, в котором он находится!
После перезагрузки.
После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ «^»).
В доменной DNS зоне появится запись с именем вашего ПК.
Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.
Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.
Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.
Я также сразу задал «RequireMembershipOf» — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.
Описание каждого параметра можно получить, например так:
Значение параметра устанавливается например так:
Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.
loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.
uid формируется как хэш SID пользователя.
gid — как хэш SID primaryGroup пользователя.
Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.
Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin. Также Firefox (при настройке network.negotiate-auth.trusted-uris) позволяет использовать SSO при доступе к Web-порталам с доменной авторизацией (естественно если SSO настроена на сервере)
А как же SSO при доступе к ресурсам на Linux ПК?
Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.
Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)
И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)
UsePAM yes
(PBIS предоставляет модуль для PAM в том числе)
Также логично будет добавить директиву «AllowGroups» и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.
На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:
Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.
На клиентском Windows ПК (члене домена) при использовании Putty следует в свойствах SSH соединения установить флаг «Attempt GSSAPI authentification (SSH-2 only)» (В разных версиях этот пункт называется по-разному).
Также в секции Connection —> Data можно поставить переключатель в позицию «Use system username»
Если вы намереваетесь организовать таким образом ssh доступ администраторов к linux серверам — хорошей идеей будет запретить на них вход root по ssh и добавить linux-администраторов (а ещё лучше их доменную группу) в файл sudoers.
Это не единственные сценарии применения PBIS. если статья покажется Вам интересной — в следующей напишу как организовать samba файловый сервер в домене для доменных пользователей без winbind.
Дополнительную информацию по теме можно получить на форуме сообщества PowerBroker Identity Services: forum.beyondtrust.com
UPD. К преимуществам PowerBroker Identity Services я могу отнести:
- Хорошую повторяемость (сравните последовательность действий этой статье с инструкцией по настройке winbind)
- Кэширование данных из каталога (доменный пользователь может войти на ПК, когда домен не доступен, если его учётные данные в кэше)
- Для PBIS не требуется формирование в каталоге AD дополнительных атрибутов пользователя
- PBIS понимает сайты AD и работает с контроллерами своего сайта.
- Большую безопасность (samba создаёт учётку компьютера с не истекающим паролем)
- В платной версии (если возникнет такая необходимость) PBIS агент управляем через GPO (хотя это можно и вычеркнуть. если вы не намерены её покупать)
UPD 2 Пришла обратная связь от пользователя sdemon72. Возможно кому-то будет полезно.
Здравствуйте! Попробовал ваш рецепт на свежей linuxmint-18-mate-64bit, все получилось с некоторыми оговорками:
1. С получением программы через сайт у меня возникли сложности (не захотел писать реальный номер телефона, а бутафорский не прокатил — пришло письмо с сомнениями по его поводу), зато нашел репозиторий с наисвежайшими версиями: repo.pbis.beyondtrust.com/apt.html
2. При запуске программы выдает ошибки, чтобы их избежать, нужно перед запуском сделать следующее:
2.1. Установить ssh:
sudo apt-get install ssh
2.2. Поправить /etc/nsswitch.conf:
hosts: files dns mdns4_minimal [NOTFOUND=return]
(т.е. переносим dns с конца строки на вторую позицию)
2.3. Поправить /etc/NetworkManager/NetworkManager.conf:
#dns=dnsmasq
(т.е. комментируем эту строчку)
2.4. Перезапустить network-manager:
sudo service network-manager restart
После этого все сработало на ура! Буду очень благодарен, если внесете эти дополнения в статью, т.к. в поиске по сабжу она выпадает в первых строках. Оставлять комментарии я не могу (запрещает сайт), поэтому пишу вам лично.
Если интересно — история моих изысканий тут: linuxforum.ru/topic/40209
С уважением, Дмитрий
UPD 3: Почему бесплатную версию PBIS не получится применить в большой компании
В бесплатной версии работает только один алгоритм генерации UNIX iD (uid и gid) по SID доменного пользователя. Так вот он не обеспечивает уникальности
этих идентификаторов. Когда у вас очень старый домен или просто много пользователей очень высок риск, что два и более пользователя получат одинаковые идентификаторы в системе с OpenPBIS. В платной версии есть возможность выбора между алгоритмами генерации id, но она стоит значительно дороже аналогичного продукта от Quest Software ;(.
Источник
Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS
В одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD.
Как и в предыдущих заметках посвященных теме интеграции Linux в AD, в качестве хранилища доменных учетных записей пользователей и групп в нашем примере будут использоваться контроллеры домена под управлением ОС Microsoft Windows Server 2012 R2.
Прежде чем приступим, хочу сделать одно важное замечание. В этой заметке мы будем выполнять корректировку некоторых системных конфигурационных файлов, отвечающих за работу аутентификации и авторизации для локального и удалённого входа в Linux-систему. Поэтому, перед тем как начать подобные корректировки, настоятельно рекомендую сделать резервную копию системы, например снапшот виртуальной машины, ибо в случае некорректных настроек PAM мы сможем получить проблемы со входом в систему (например после перезагрузки сервера).
Устанавливаем плагин для Samba4 (nss_winbind) и поддержку Winbind для PAM:
Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя.
Проверяем наличие билета Kerberos
Очищаем кэш билетов:
Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону ( template homedir ) /home/<Домен>/ <Логин>с отсутствием оболочки ( template shell ). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку
Новое содержимое smb.conf :
Обратите внимание на то, что по сравнению с конфигурационным файлом приведённым для примера ранее , добавился также ряд других параметров, нацеленных не конкретно под нашу задачу, а для оптимизации работы процессов Samba.
После изменения диапазона idmap в smb.conf не плохо бы сбросить кэш Winbind:
Для вступления новой конфигурации smb.conf перезапускаем службы Samba:
Добавляем возможность использования Winbind в системный конфигурационный файл nsswitch.conf
Дописываем winbind в строки passwd и group . Результирующий файл будет выглядеть так:
Убеждаемся в том, что ниже указанные команды возвращают список как локальных пользователей и групп так и доменных:
Обратите внимание на то, что при большом количестве пользователей и групп в домене вывод getent может работать некорректно в том случае, если в конфигурации smb.conf диапазон idmap недостаточно велик. Хотя на самом деле у нас нет необходимости получать полный список всех групп и пользователей домена, а достаточно выполнить проверку для какой-то одной конкретной группы, например для доменной группы безопасности, которую мы специально создали для объединения администраторов серверов Linux…
…и для доменной учетной записи любого пользователя, которую мы планируем использовать для входа на наш Ubuntu Server…
Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):
Проверим, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.
Правим файл /etc/pam.d/common-session . В конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия:
Результирующий файл (без вывода комментариев) получится следующий:
Правим файл /etc/pam.d/common-auth . В строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of , в котором указываем имя доменной группы безопасности. В эту группу будут входить пользователи, которым мы хотим разрешить вход на наш Linux-сервер. Имя группы желательно указывать с учётом регистра, то есть так, как она создана в домене AD. Указанная группа должна быть группой глобального типа (область действия в домене AD).
Результирующий файл (без вывода комментариев) получится следующий:
Обратите внимание также на то, что в указанные файлы не стоит вносить никаких других изменений кроме указанных, даже таких простых, как например, изменение отступов в существующих параметрах. В противном случае мы потеряем возможность управлять включением/выключением PAM-модулей через конфигуратор pam-auth-update. Проверить то, как после ручной правки pam-auth-update воспринимает common-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:
Если же всё таки где-то напортачили, то можно заставить pam-auth-update исправить параметры common-файлов в их исходные значения выбрав в указанном сообщении Yes, либо отдельной командой:
Остальные common-файлы привожу информативно. В них мы редактировать вручную ничего не будем, так как конфигуратор pam-auth-update уже внёс все необходимые правки со ссылкой на winbind.
Результирующий файл /etc/pam.d/common-account (без вывода комментариев):
Результирующий файл /etc/pam.d/common-password (без вывода комментариев):
Результирующий файл /etc/pam.d/common-session-noninteractive (без вывода комментариев):
После указанных настроек проверяем вход в систему используя учетные данные пользователя домена AD. В качестве логина указываем доменный логин пользователя (без доменной части). При этом проверяем, то что в систему удаётся войти только тем пользователям, которые включены в доменную группу безопасности KOM-SRV-Linux-Administrators . В случае возникновения проблем при входе следим за системным логом аутентификации:
Замечено, что в случае, если в домене AD в свойствах групп безопасности, членом которых является аутентифицируемый пользователь, присутствует непустой атрибут sIDHistory (группа ранее была мигрирована в текущий домен из другого домена), то в процессе входа в Linux может появляться ряд сообщений типа:
Это связано с тем, что после аутентификации и авторизации для пользователя запускается shell-оболочка, которая была назначена пользователю согласно параметра template shell конфигурационного файла smb.conf . То есть в нашем случае выполняется оболочка /bin/bash . В текущей своей версии оболочка bash при запуске выполняет скрипт /etc/bash.bashrc . Если мы откроем этот скрипт, то увидим, что в нём присутствует такой фрагмент кода:
Этот участок скрипта используется для банального вывода подсказки о том, что для выполнения административных действий требуется использовать sudo. При этом здесь выполняется проверка членства залогинившегося пользователя в группах вызовом утилиты groups, которая в свою очередь при вызове в контексте доменного пользователя будет пытаться вернуть список доменных групп в которые он входит. При этой операции используется Winbind, у которого есть проблемы с чтением из домена AD групп имеющих непустой атрибут sIDHistory.
Чтобы избавиться от вывода подобного рода сообщений при входе в систему есть два простых решения. Либо закомментировать представленный выше участок кода в файле /etc/bash.bashrc , либо для доменных пользователей использовать альтернативную shell-оболочку, например zsh (при этом надо поменять параметр template shell конфигурационного файла smb.conf на /bin/zsh и перезапустить службы Samba). Я предпочёл первый способ.
Итак, мы уже имеем возможность локального и удалённого (по SSH) входа на наш Linux-сервер используя учётную запись пользователя домена AD с ограничением по членству в доменной группе безопасности. Однако для выполнения таким пользователем административных действий в Linux-системе, нам потребуется включить для этого пользователя возможность выполнения sudo. Проще всего будет выдать данное разрешение не для конкретного пользователя, а сразу для указанной доменной группы. Для этого нам потребуется внести изменения в системный конфигурационный файл /etc/sudoers . Прямая правка этого файла не рекомендуется, поэтому воспользуемся специальным инструментом visudo, который при сохранении файла sudoers выполняет его проверку:
Приведу фрагмент файла, в котором описываются группы доступа имеющие возможность выполнять sudo (здесь была добавлена последняя строчка фрагмента):
После сохранения файла снова входим в систему доменным пользователем и пробуем выполнить любую команду с sudo.
На этом всё. В следующей заметке мы рассмотрим процедуру настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows
Дополнительные источники информации:
Источник
