Авторизация через домен windows

Здесь рассмотрим выполнение сквозной авторизации пользователя в Active Directory C получением параметров пользователя.
Необходимым условием является наличие пользователя в домене, т.е. пользователь не прописанный в домене не пройдет авторизацию.
Прежде всего необходимо установить соединение нашего php-скрипта с доменом.
Подразумевается, что в AD прописан не только пользователь, но и компьютер пользователя.
Часто в описании пользователя отсутсвует привязка к компьютеру, – этот скрипт проверяет сведения о компьтере в домене и вытягивает всю необходимую информацию.
Сделаем это следующим образом:
1. Получаем имя удаленного хоста, при входе пользователя на страницу.

2. Поскольку полученное имя может быть длинее 15 символов (а именно столько позволяет внести NETBIOS-имя), – обрезаем до необходимой длнины, убираем все символы после первой точки (т.к. полученное имя имя будет иметь формат “логин.субдомен.домен”) и в переменную “текущий пользователь” берем результат, добавляя к нему спецсимвол “$”.

3. Устанавливаем соединение с доменом.
Для этого используем пару “логин-пароль” имеющие права считать информацию из AD.

Получение информации из домена разделим на две составляющие: информация о компьютере и информация о пользователе.
4. Извлечение информации о копьютере.
Эту операцию выполнит следующий код:

5. Извлечение информации о пользователе (в качестве продолжения кода приведенного в п.4)

Выше приведенный способ я использовал по причине запрета доменной политикой использования в браузере ActiveX.
Если же ActiveX у вас разрешен – можно использовать другой способ извлечения из AD информации о пользователе посетившем web-страницу, приведенный ниже:

Вход на доменный компьютер под локальной учетной записью

В некоторых случаях требуется на компьютере, который включен в домен Active Directory войти не под доменной, а под локальной учетной записью. Большинству администраторов этот трюк знаком, но пользователи зачастую о нем не знают.

Немного предыстории. После того, как компьютер добавлен в домен Active Directory, вы можете войти в него под учетной записью домена или локального пользователя (если конечно локальная учетная запись не отключена и вход под ней не заблокирован через групповые политики). В Windows XP и Windows Server 2003 на экране входа в систему имелся раскрывающийся список «Вход в систему», в котором можно было выбрать в какой домен вы хотите войти, либо, если нужно зайти под локальной учетной, для этого нужно выбрать пункт «Этот компьютер» — @Computer_Name (this computer) .

Однако в последующих версиях Windows это раскрывающийся список из интерфейса входа в систему убрали. Вместо этого списка на экране входа в систему, появилась небольшая кнопка «Как я могу войти в другой домен» (How to log on to another domain). Если вы нажмете эту кнопку, появится следующий совет.

Type domain name\domain user name to sign in to another domain.
Type РKZ-ТZI01K1\local user name to sign in to this PC only (not a domain )

Чтобы войти в другой домен, введите имя_домена\имя_пользователя_домена
Чтобы войти только на этот компьютер (не в домен), введите РKZ-ТZI01K1\локальное_имя_пользователя

Как вы видите, в тексте сообщения присутствует имя данного компьютера (в нашем примере РKZ-ТZI01K1). И если вы хотите войти под локальной учетной записью, в поле с именем пользователя нужно указать имя локального пользователя в следующем формате РKZ-ТZI01K1\Administrator. Естественно, если имя компьютера довольно длинное и не несет смысловой нагрузки, его набор с клавиатуры может стать настоящим испытанием.

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

Секрет в том, что Windows использует символ точки (.) в качестве псевдонима для локального компьютера. Поэтому, если в поле с именем пользователя поставить .\ , то система будет считать, что вы хотите авторизоваться под локальной учеткой. Соответственно изменится поле Sign in to, вместо имени домена там уже будет указано имя данного компьютера.

Теперь после .\ осталось набрать имя локальной учетной записи и пароль.

Этот небольшой трюк может использоваться для входа на доменный компьютер под локальной учетной записью во всех поддерживаемых версиях Windows, начиная с Windows Vista и заканчивая Windows 10 и Windows Server 2016.

Совет. Аналогичным образом можно авторизоваться на удаленном компьютере в рабочей группе под локальной учетной запись при доступе к общим файлам по протоколу SMB.

Аутентификация и авторизация в домене 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

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