- Настраиваем доменную аутентификацию на сетевом оборудовании
- Установка и настройка сервера с ролью Network Policy Server
- Настройка сетевого оборудования для работы с сервером RADUIS
- Доменная (LDAP) аутентификация в Codeigniter
- Добавим библиотеку и конфигурационный файл
- Напишем небольшой код авторизации
- Как настроить доменную аутентификацию
- Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)
Настраиваем доменную аутентификацию на сетевом оборудовании
При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).
Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.
Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.
Установка и настройка сервера с ролью Network Policy Server
Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.
Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).
- RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
- Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
- Network Polices – правила аутентификации
Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.
Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.
В окне Configure Settings изменим значение атрибута Service-Type на Administrative.
И, напоследок, переместим новую политику на первое место в списке политик.
Настройка сетевого оборудования для работы с сервером RADUIS
Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).
Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:
Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!
Для Cisco ASA конфигурация будет выглядеть так:
Совет. Если что то-не работает, проверьте:
- Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
- Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
- Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
- Внимательно изучите логи NPS сервера
Источник
Доменная (LDAP) аутентификация в Codeigniter
Статья ориентирована на начинающих Codeigniter-щиков, таких как я.
В процессе создания внутреннего сайта одной из российских компаний, возникла необходимость ограничить доступ пользователей к некоторым страницам, функциям. Так как все пользователи в домене, то и на сайте есть смысл использовать доменную аутентификацию.
Найти самостоятельно информацию в принципе не трудно. Поисковые системы еще ни кто не отменял. Я просто решил собрать найденные кусочки и объединить их в один, на русском языке.
Допустим, что CI уже установлен и настроен. Кстати, на одном из западных сайтов, доступно много хороших и исчерпывающих видео уроков по настройке и использованию Codeigniter-а.
Добавим библиотеку и конфигурационный файл
Конечно, существуют некоторые функции в самом PHP, но использовать их не всегда рационально. За основу возьмем библиотеку adLDAP. В ней есть все необходимое и даже больше.
Первым делом создадим конфигурационный файл, например adldap.php и положим его в \system\application\config\
Далее необходимо добавить библиотеку. Но как сделать так, что бы ей можно было пользоваться в CI, как остальными? За нас это уже сделал один программист, и предоставил для общественного пользования (онутверждает, что лицензия не нарушена). Ее мы и добавим в \system\libraries\ и назовем, например Adldap.php.
После выше описанных манипуляций библиотекой можно пользоваться в Codeigniter-е, как и другими, например:
$this->load->library(‘Adldap’);
$this->adldap->authenticate($username, $password);
Напишем небольшой код авторизации
Сделать это проще простого.
Во-первых, создадим форму для ввода логина и пароля:
Во-вторых, контролер и саму функцию для авторизации в домене. Но домен большой и пользователей много и если просто проверять пароль и логин, то к ограниченным частям сайта будут иметь все члены домена.
Для более тонкой настройки нужен еще один параметр для проверки — группа (Active Directory). Назовем ее, например Web_Group, и добавим нужных нам пользователей:
//Проверяем логин и пароль
$authUser = $this->adldap->authenticate($this->input->post(‘username’), $this->input->post(‘password’));
//проверяем наличие пользователя в группе
$groupinfo = $this->adldap->user_ingroup($this->input->post(‘username’), ‘Web_Group’, ‘NULL’);
//В случае если $authUser и $groupinfo истина
if ($authUser === true and $groupinfo === true) <
//Осталось только добавить информацию в массив сессии о том, что проверка успешна и доступ к определенным ресурсам открыт
$data = array(‘username’ => $this->input->post(‘username’), ‘usergroup_access’ => ‘Web_Group’, ‘is_logged_in’ => true);
$this->session->set_userdata($data);
redirect();
> else <
echo «Ошибка авторизаци»;
>
>
>
Вот и все. Теперь в любой другой функции можно делать проверку и в зависимости от результата предоставлять или не предоставлять доступ.
Примерно это должно выглядеть так:
//Вытаскиваем и проверяем прошел или нет пользователь авторизацию
if ($this->session->userdata(‘is_logged_in’) == true) <
echo «Доступ к данным открыт»;
Теперь осталось только дописать функцию уничтожения сессии (Logout):
function logout() <
$this->session->sess_destroy();
redirect();
>
Спасибо за внимание.
UPD: нашел еще одну интересную LDAP библиотеку.
Источник
Как настроить доменную аутентификацию
Kaspersky Security Center 13 позволяет использовать доменную аутентификацию в OpenAPI по протоколам NTLM и Kerberos. Использование доменной аутентификации позволяет пользователю Windows включить безопасную аутентификацию в Kaspersky Security Center 13 Web Console без повторного ввода пароля в корпоративной сети (единый вход).
Аутентификация домена в OpenAPI по протоколу Kerberos имеет следующие ограничения:
- Пользователь Kaspersky Security Center 13 Web Console должен пройти аутентификацию в Active Directory по протоколу Kerberos. У пользователя должен быть действующий билет на получение билетов Kerberos (далее также TGT). TGT выдается автоматически при аутентификации в домене.
- Вы должны настроить аутентификацию Kerberos в браузере. Подробнее см. в документации используемого вами браузера.
Если вы хотите использовать доменную аутентификацию с использованием протоколов Kerberos, ваша сеть должна соответствовать следующим условиям:
- Сервер администрирования должен запускаться под доменной учетной записью.
- Для учетной записи Сервера администрирования необходимо указать следующую информацию:
- «KLKscSrv/ «
- «KLKscSrv/ «
Здесь, – сетевое имя устройства Сервера администрирования, – полное доменное имя устройства Сервера администрирования.
- При подключении через Консоль администрирования или Kaspersky Security Center Web Console необходимо указывать адрес Сервера администрирования точно так же, как адрес, для которого зарегистрировано имя субъекта-службы (SPN). Вы можете указать либо или .
- Для входа без пароля служба браузера, в котором открыта Kaspersky Security Center Web Console, должна работать под доменной учетной записью.
Протоколы Kerberos и NTLM поддерживаются только в OpenAPI для Kaspersky Security Center 13. Эти протоколы не поддерживаются в OpenAPI для Kaspersky Security Center Linux.
Источник
Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)
Приветствую всех, если вас заинтересовала статься значит вы тем или иным образом стыкались или интересовались данным вопросом, либо просто почитать.
Данный кейс с реальной практики, проект начался в начале 2019 и все «n» баз были переведены в течении полугода на доменную авторизацию (надеюсь все понимают, что это значит), но мне больше нравится SSO.
Значит что имеем:
Windows Server 2016 + AD (не рассматриваем как настраивать)
CentOS 7 + Haproxy + Comodo SSL Wildcard
Windows Server 2016 + IIS + 1C
Опишу вкратце что и как взаимодействует, вся инфраструктура доменная (кроме unix подобных), сервер с 1С-на нем поднята только 1С, сама БД на SQL-ных серверах они нам не нужны сейчас. Все публикации работают по https. конечно есть и подключение сервер база (их мы тоже не будем рассматривать так как доменная авторизация в таком режиме работает сразу и без проблем. Значит клиент с доменным устройством Windows 10 вошел в систему с доменной учеткой запускает 1С в которой прописана ссылка на базу например https://1cbase.yourdomain.com, обращается в к haproxy, тот в свою очередь согласно правилам адресует его на нужный сервер с этой базой, далее IIS принимает соединение, подхватывает доменные учетные данные и передает их в 1С. Ниже схемка:
Вроде все понятно, конечно если об этом вы слышите в первый раз, то нужно будет почитать дополнительные материалы как настраивается каждый сервис.
Двигаемся дальше и приступаем к настройке наших сервисов
Haproxy, просто ставим с репозитория и корректируем конфиг, в моем случае сервис обслуживает не только 1С а и другие WEBы, по этому у меня настройка с 80 редиректор в 443, но для 1С в клиенте нужно писать сразу https так как клиент 1С не воспринимает редирект и прописав http вы просто никуда не попадете. Плюс который для меня важен в такой схеме что на моем маршрутизаторе открыт только 80 и 443 порты и на этом все, я не делаю для каждой БД другой порт и т.д., просто устанавливаешь в своей команде стандарт названия баз и передаешь в ТП что б они знали и могли прописать базу. хотя и это автоматизировано и у каждого сотрудника согласно должности свой список баз. Так вот ссылка всегда будет иметь нормальный для меня вид. например https://rt.yourdomain.com или https://ut.yourdomain.com или https://erp.yourdomain.com. Подняли haproxy (у меня HA-Proxy version 2.0.13) и добавляем конфиг
Можно так же использовать сертификаты Let’s Encrypt но у меня есть подписанный ЦС, а еще может быть что клиент 1С на разных ОС будет ругаться на Let’s Encrypt. Если у вас кластер 1С тогда нужно добавить еще один сервер rt_db_srv02 в backend rt_db_server
Настройка IIS, тут уже будет больше картинок.
После инстала IIS, включаем только 80й порт остальные нам не нужны так как ssl будет занимается haproxy. На картинке ниже роли, которые нужно поднять:
Я это все делаю с помощью Ansible, поэтому готовых команд PS под рукой нет. Идем дальше и не к настройке IIS, а к установке 1С:
По стандарту заходим в консоль администрирования 1С подключаем базу и тд. В клиенте 1С на сервере на котором бы будем делать публикацию прописываем имя сервера (у нас же AD и DNS внутренний) можно без порта, но естественно если порт у вас отличный от стандартного (например, подняли еще одну службу на 1640), то его писать тоже нужно типа server1С1:1641, но если у вас кластер тогда пишем так server1С1;server1С2 (server1С1:1641;server1С2:1641) и нормальные имена нужно прописывать обязательно, так как это пойдет в конфиг IIS. Чуть не забыл, после инсталляции 1С службу, которую она создаст, необходимо запустить от имени доменного пользователя, на сервер 1С его нужно будет сделать админом, а в домене может быть обычным пользователем. главное что б мог читать пользователей с AD. Например
Публикуем базу как обычно, все по дефолту, с необходимыми галочками в hs/ws
И тут возвращаемся к IIS, тут уже будет публикация в 1С в сайте по умолчанию, но мы ее не трогаем пока что. это как эталон конфига. Делаем паку в C:\inetpub\wwwroot\, например rt.yourdomain.com, ну что б было все красиво и понятно тому, кто придет на этот сервер после нас или с нами. Добавляем новый веб-сайт (это, я думаю, понятно как) и заполняем:
Веб сайт есть, а далее вместе с ним создается и пул приложений. который нам больше всего и нужно, так как в нем мы задаем кто будет авторизовать креды пользователей в 1С и расшифровывать karberos. Для этого нам нужен еще один доменный пользователь желательно отдельный, например iis_service (создаём помним пароль)))
Так он выглядит стандартно:
Приводим его в нужный вид, редактируя удостоверение:
Тюним, Режим управления выставляем Классический и нужно что б это удостоверение использовалось для этого делаем в редакторе конфигурации сервер (путь system.webServer/security/authentication/windowsAuthentication).
IIS настроен, переходим к нашей новой публикации rt.yourdomain.com, для начала выставляем проверку подлинности:
Копируем конфиг публикации, то есть с наше стандартной публикации берем два файла default.vrd и web.config копируем в папку C:\inetpub\wwwroot\rt.yourdomain.com, отлично. Чуть поправим конфиг, буквально удалим в одно строчке символы, что б наши ссылки были короче и красивей. В файле default.vrd удаляем как на картинке и именно так. даже если что-то было после / мы это удаляем:
Ну и по классике что б не было кракозябликов в 1С то правим настройку страницы ошибок для нашей публикации rt.yourdomain.com:
С этим все готово. Для корректной работы, необходимо в AD прописать spn запись, это просто заходим на домен контроллер и запускаем команды, в которых пишем нашу публикацию и нашего пользователя, который расшифровывает kerberos:
В 1С пользователю вставляем авторизацию как на картинке:
Со списка доменов нужно выбрать тот, что большими буквами и в виде короткой записи.
на этом пока все. возможно еще подкорректирую статью, пост был важен для меня, так как при работе с проектом нужно было много разбираться и собирать по кусочкам. а что-то и самому изобретать. Надеюсь, статья будет полезна тем, кому необходимо решить аналогичный кейс.
В следующей статье напишу про то, как мы сделали веб страничку с сеансами пользователей и возможностью их удаления.
Источник