Как сделать единый вход (авторизацию) для поддоменов

Содержание материала:

Как создать и настроить страницу авторизации для WordPress

Многим из вас наверняка хорошо известна страница WordPress wp-login.php , использующаяся как страница для авторизации. Выглядит и работает она отлично.

Но когда дело доходит до создания веб-сайта для клиентов, скорее всего, вы захотите иметь более гибко настраиваемую страницу авторизации, чтобы она была едина с идеей дизайна сайта.

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

Если это то, чего вам не хватает на сайте — приступайте к изучению инструкции, изложенной в данной статье.

Пользовательская страница авторизации

Итак, первое, что нам нужно, это создать шаблон пользовательской страницы входа. Для этого мы создаем страницу шаблона и называем ее, к примеру, page-login.php .

Затем, создаем новую страницу в панели администрирования и ставим постоянную ссылку для страницы авторизации.

WordPress автоматически подцепит шаблон page-login.php :

Форма входа

Поместите тег wp_login_form в код шаблона page-login.php для отображения формы авторизации:

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

Здесь же вы можете, к примеру, добавить такие штуки как логотип и описание вашего сайта:

Теперь приступим к настройке внешнего вида страницы с помощью CSS-стилей. В этом примере я покажу, как выглядит моя страница для входа.

У нее темный фон с голубой кнопкой, которые соответствуют теме сайта Hongkiat.com :

Проверка связки имя-пароль

В этой части страница уже функционирует. Мы можем попытаться авторизоваться, и если вход выполнен успешно, нас перебросит на страницу, которую мы указали в параметре redirect на предыдущем шаге. Но есть еще кое-что, на что мы обратим наше внимание.

Во-первых, страница wp-login.php до сих пор остается доступной. Стоит поставить редирект с wp-login.php на созданную нами страницу, чтобы наши клиенты могли на неё попасть.

Для этого нужно добавить следующий код в файл functions.php используемой вами темы WordPress:

Не забудьте присвоить переменной $login_page значение адреса вашей страницы для входа.

Во-вторых, страница авторизации работает так как задумано только в случае, если попытка входа удалась. Но, что происходит, если вход не удался?

К примеру, введена неверная пара логин-пароль или оставлено пустое поле. Нас снова выбросит на wp-login.php .

Чтобы избежать этого добавляем следующую функцию в файл functions.php :

Две эти функции выполняют несколько задач: переадресуют пользователей в случае неудачной попытки входа и дописывают к URL-адресу строки запроса login значение failed или empty :

Последняя проблема, которую мы решим это редирект к wp-login.php при выходе с сайта. Нам стоит определить страницу редиректа для корректного перехода при нажатии кнопки выхода:

Сообщение об ошибке

Мы будем показывать пользователю сообщение, и когда случается ошибка, и когда он выходит с сайта при помощи query string , значение которой мы поместили в URL. Для того чтобы получить значение из строки запроса, мы будем использовать переменную $_GET .

Поместите код, приведенный ниже, в шаблон страницы авторизации:

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

Также мы будем отображать сообщения, основанные на значении переменной $error :

И ниже, собственно, пример того, как может такое сообщение выглядеть:

Заключение

Осталось еще несколько вещей, которые мы можем добавить к странице авторизации. К примеру, ссылка на страницу для восстановления пароля, ссылка на страницу регистрации нового пользователя и персонализированные сообщения об ошибках.

Но с другой стороны, наша страница полностью функциональна, позволяет пользователям входить на сайт и выходить из него, и поэтому я считаю это неплохой точкой для старта. Далее можно добавлять тот функционал, который вы посчитаете нужным.

Надеюсь, это руководство окажется для вас полезным!

Данная публикация представляет собой перевод статьи « How To Build A Fully Customized WordPress Login Page » , подготовленной дружной командой проекта Интернет-технологии.ру

Поддомены Google oauth

Я внедрил Google oAuth на сайте (example.com). Все работает отлично, кроме auth из субдоменов на моем сайте (у меня есть тысячи поддоменов). Когда пользователь пытается выполнить авторизацию через субдомен, например

Я получаю сообщение об ошибке от Google —

Как это можно решить?

Это потому, что Google OAuth не поддерживает сопоставление поддоменов подстановочных знаков. Вы можете обратиться к дополнительной документации здесь

Другие ответы уже выяснили, что причиной неприятностей является то, что Google OpenAuth не поддерживает поддомены подкачки. Однако, что вы спрашиваете, как это можно решить? Ну, у вас есть два варианта, в соответствии с этой электронной почтой:

Обеспечьте единую конечную точку обработки OAuth2 для всех поддоменов. То есть у вас будет основной домен и конечная точка, через которые вы также выполняете аутентификацию для поддоменов. Когда выполняется аутентификация, вы перенаправляетесь обратно в поддомен. Там предположительно параметр состояния OpenAuth, в котором вы можете кодировать имя поддомена. Это то, что я сделал, вот код: https://github.com/debiki/debiki-server/blob/master/app/controllers/LoginWithOpenAuthController.scala

Вы можете независимо регистрировать каждый поддомен с помощью Google.

Какой вариант вы выберете, зависит от того, какой бренд просят пользователи Google одобрить. Основной домен или поддомен?

Одновременная авторизация Yii2 на поддоменах. Cookies на поддоменах

Создал отдельный сайт на поддомене. Возникла ситуация, когда на главном домене авторизуюсь в личный кабинет, а потом открываю сайт на поддомене, то нужно здесь снова авторизоваться для этого сайта на поддомене. Нужно настроить единую авторизацию на всех поддоменах основного сайта.

Для примера возьмем два сайта site.ru и en.site.ru.

Для сквозной авторизации на поддоменах достаточно поправить конфигурацию вашего приложения Yii2:

Мы прописали домен для COOKIE, что позволяет авторизационным данным сохраняться как на основном домене, так и на поддомене.

После этого было замечено, что в случае выхода с сайта (Yii::$app->user->logout()) — пользователь остается авторизованным на другом домене. Проблема решается аналогично как и для Yii1 — добавлением пары строчек в конфигурацию:

Распространение авторизации на поддомены

Иногда требуется распространить авторизацию на все поддомены, включая основной домен. Другими словами, необходимо сделать один файл сессии для домена и его поддоменов.

Для этого необходимо прописать в файле htaccess следующее:

Вместо «7» поставьте свою версию php. Вместо «.domain.com» свой домен. Обратите внимание на точку в начале » . domain.com».

После установки можно проверить правильность, подглянув в phpinfo(). Там будет строка:

Топ-пост этого месяца:  Как задается в css3 радиальный и линейный градиент

Теперь удостоверимся в правильности распространения сессии на все поддомены. Для этого сначала откроем папку, где хранятся файлы сессии php. Путь к ней можно найти в том же phpinfo(), под названием «session.save_path». Удалим из этой папки все файлы сессий (это нестрашно, если проект находится в разработке, но на активном проекте это причинит неудобства пользователям). Теперь открываем анонимное окно браузера. В нём вкладки на несколько разных поддоменов. Если при открытии двух и более поддоменов будет создан только один сессионный файл, то всё прошло хорошо:

Если от открытия двух поддоменов в браузере создалось два файла сессии, то где-то была допущена ошибка. Если файл один, то всё прошло успешно, данные сессии берутся из одного файла.

Не забудьте, что в CMS сессия может запоминаться в куки. Поэтому для активации распределённой на поддомены сессии, необходимо полностью очистить куки сайта в браузере.

Проверка авторизации на поддомене

Ответа пока нет

Похожие вопросы

Не выводится ошибка авторизации

Вопрос на счет домена

Смена шаблона в поддомене без смены в домене.

Показывать email комментатора только админу

Автоматический переход на отдельную страницу авторизации?

Ну а найти ‘‘ в файле addnews.php можете ? Затем с низу в верх выписывая весь зависимый код пока выписывать будет нечего.

Найдя по тегу строку Вы увидите
$tpl->set( ‘‘, $cats );
затем выше включая данный тег выписываете включая $cats, после увидите еще одну переменную $categories_list, и попробуете найти её (найдёте что-то вроде $categories_list = CategoryNewsSelection( $cat_list, 0 );)

а затем видим еще $cat_list, и тут же строка выше $cat_list = explode( ‘,’, $row[‘category’] );

всё на этом формирование категорий закончено (вместо $tpl->set используем просто ‘<$cats>‘ в месте где нужно разместить выборку категорий), это всё нужно разместить ниже запроса $row в editnews.php

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

Поддомены для SEO — особенности многорегионального продвижения

Поддомены для продвижения – да или нет?

Зачем нужны отдельные домены для регионов?
Что мешает использовать единый сайт для покупателей и партнеров независимо от географии?

Все просто — поисковые системы показывают различную информацию людям из разных городов. Вот официальная документация Яндекса про поиск с учетом региона .

Если вы продаете пиццу или офисные стулья, то Яндекс и Google постараются показывать ваш сайт только тем людям, для которых ваша компания будет «местной». Пиццу и стулья лучше покупать на месте. А вот например, «биография Пушкина» от региона не зависит. Ни в жизни, ни в Яндексе.

Разумеется, все продавцы захотели быть «местными» везде. Например, имея склад в Москве и Питере, тем не менее показываться в поиске в Подольске и Волгограде. Мол, доставка же работает.

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

Один из элементов такой проверки — в Яндексе назначить регион сайту можно тремя разными способами — Каталог, Справочник, Вебмастер. Сложнее всего попасть в Каталог по «чужому» региону. Но если удалось, вы окажетесь в выдаче.

Проще организовать несколько сайтов на поддоменах и привязать каждый к отдельному региону.

Делать или не делать поддомены для SEO?

Может показаться, что поддомены — панацея и решают все проблемы. На самом деле нет. Есть много примеров, когда крупные и уважаемые сайты поддомены НЕ делают. Оцените, например, адреса страниц волгоградских представительств федеральных брендов:

Но задавать себе этот вопрос нужно.

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

Плохо, если вопрос про региональное продвижение и поддомены ставит специалиста в ступор.

Как правильно делать региональное продвижение?

Правильно — взвесить все факторы и принять решение. Наличие или отсутствие поддоменов затрагивает не только изменения информации на сайте. Приходится адаптировать логику работы.

  • SEO и привязки городов;
  • изменения цен и наличия товаров, условий доставки (это влияет на технику работы сайта);
  • вопрос «переключения города» и связанных с этим эффектов (перейду на главную? или просто город сменится? а корзина сохранится? а можно «повторить заказ, сделанный в другом городе»? а я в аэропорту заказывал перед вылетом, что мне теперь делать?)
  • выгрузка на Яндекс.Маркет и другие торговые площадки, изменения цен и адресов карточек товара;
  • сбор аналитики (если сайт один, все в куче, а если сайтов много, три часа на сведение);
  • интеграции с 1С и дублирование контента.

Мы разобрались в этом вопросе сами и решили помочь клиентам.

Итак, сводная таблица.

Положительные выводы подсвечены зеленым, негативные красным.

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

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

Придется делать уникальный контент (хотя бы стараться) для каждого региона (ассортимент, цены, отзывы региональных клиентов, цены и т. д.)

  • добавить город в название товара,
  • информация о цене, оплате, доставке, наличии, контактах указана для данного региона,
  • есть отличие ассортимента,
  • размещается информация о региональных акциях, скидках, спецпредложениях,
  • отзывы клиентов именно этого города.

Отчетность и съем позиций по каждому поддомену в каждом регионе — дорого.

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

Если у компании до 7 регионов, можно присвоить регионы всему сайту без поддоменов.

Через сервис Яндекс.Вебмастер сайту может быть присвоен только один регион.

Несколько регионов (до 7 штук) могут быть присвоены только через Яндекс.Каталог в том случае, если сайт относится к этим регионам.

Индексация новых разделов происходит быстрее, чем индексация новых поддоменов.

Нужно оптимизировать только отдельные новые разделы.

Яндекс.Маркет (настройки на Маркете)

Если у магазина есть представительства (региональные магазины) в других городах, причем в этих городах есть именно торговые точки с типом «торговый зал», тогда можно создать на Маркете отдельные региональные магазины.

У каждого их этих магазинов будет свой личный кабинет, свои настройки и свой прайс-лист, соответствующий региону, а также свой домен, отличающийся от основного, например, приставкой, обозначающей регион. В реальности регистрировать именно такой домен с приставкой не потребуется.

Вывод: Маркету все равно, он поддерживает обе модели.

Должно соблюдаться правило — при переходе с Маркета пользователь должен видеть на странице сайта именно тот товар, и ту цену, которые он видел на Маркете.

Нужен отдельный прайс-лист для каждого региона.

Поддомены удобны, но не обязательны (есть способ обойтись без них, если кодировать регион в ссылке на товар через параметр)

Вывод: Маркету все равно, он поддерживает обе модели.

Для удобства лучше иметь один рекламный кабинет для одного поддомена.

Один рекламный кабинет в каждой из рекламных систем, легко найти нужную рекламную кампанию.

Аналитика контекстной рекламы

Поддомены меняют трудоемкость аналитики (считать обороты, конверсии, итд), но ее и так много на многорегиональных порталах, независимо от того как это сделано.

Вывод: этот пункт не влияет ни на что.

Аналитика трафика и сбор статистики

Некоторые маркетологи рекомендуют для чистоты статистики на каждый поддомен заводить отдельный счетчик Метрики (ресурс в Analytics).

Топ-пост этого месяца:  Уменьшение размера изображения методы квантования цвета и сглаживание

Мы рекомендуем использовать один аккаунт и один ресурс.

Поддомены всегда можно определить по странице входа.

Один аккаунт в системе аналитики и один счетчик сбора данных.

Одна настройка эл. коммерции, один коллтрекинг, итд.

Если проигнорировать рекомендацию делать “вакансии по городам”, “акции по городам”, и сделать копию контента везде, то примерно одинаково .

Разделение и отображение контента

Не исключаем ситуацию, что в СПБ-выдачу будет примешан МСК-поддомен просто потому, что его модератор набрал больше отзывов для товаров и лучше подготовил картинки.

Если речь только о разной информации о наличии, контактах, информации об оплате и доставке, можно реализовать магазин без поддоменов .

Очень зависит от различий в контенте и системы прав конкретного сайта.

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

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

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

С поддоменами больше механической возни, на едином сайте больше сложной логики и коллизий.

Внутренняя реализация структуры каталога

Сложность разработки законченной системы возрастает на 30%.

Сложность меньше на 30%

Авторизация на сайте

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

Скорость работы сайта

Почти не отличаются, так как общая посещаемость не меняется.

Некоторые файлы придется продублировать, места для «поддоменов» требуется незначительно больше .

Особенности оформления заказа и функций корзины

Оформление заказа одинаковое. Проще реализуются функции корзины.

Оформление заказа одинаковое. Сложнее реализуются функции корзины.

Много сложностей с настройкой прав доступа

Также — кто должен видеть заказы?

Дороже за счет многодоменного сертификата

Есть еще некоторые вопросы, которые могут повлиять на выбор схемы и стоимость ее реализации. Эти вопросы касаются не столько сайтостроения и поискового продвижения , сколько особенностей работы компании.

Разные юрлица в городах

Часто разные города обслуживаются разными филиалами или даже юридическими лицами.

Сделать так, чтобы сайт на Битриксе принимал оплату разными способами и делал документы от разных юрлиц, можно без особых проблем. Это требует работы программиста, но задача относительно проста.

Каталог зависит от города

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

Этот вопрос можно решать по-разному, но в итоге может потребоваться просто сделать несколько копий каталогов в 1С и выгружать их раздельно.

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

Примером сайта, где хорошо решены все эти вопросы, может служить сайт дистрибьютора моторных масел shell-volgograd.ru , имеющий 3 дополнительных домена для Пензы, Саратова и Астрахани.

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

Тем не менее вопросов много, и их нужно решать вдумчиво.

Иногда решение будет другим.

Если нужна помощь — вы знаете кого спросить.

Межсайтовая авторизация 2

По итогам поста, сделанного в июле 2009 и продолжительным испытаниям, мы пришли к простой и оптимальной для нас схеме межсайтовой авторизации.

Задача — организовать межсайтовую авторизацию между проектами, размещенными на разных доменах (site1.com, site2.com). Пользователь автризовавшись на одном проекте, получает авторизацию на всех (Single Sign On). Тоже самое с кнопкой выход (Single Sign Out). Доступ к хранилищу сессий и к базе есть у каждого проекта. На обоих проектах авторизация не обязательна.
Хочу подчеркнуть что вопросы регистрации, хранения и передачи пользовательских данных сейчас не обсуждаются, интересует только авторизация.

Задачу можно разделить на три основных части:

  1. Авторизация — пользователь ввел логин и пароль в форме.
  2. Автоматическая авторизация — пользователь нажал «запомнить меня», или уже авторизован на одном из проектов.
  3. Выход — пользователь нажал кнопку «выход».

Договоримся, что:

  • site.com — один из проектов.
  • sso.com — сервер общей авторизации.

Авторизация

Автоматическая авторизация

Выход

Пользователь на site.com жмет на кнопку «выход». Опускаем сессию, удаляем сессионную cookie и делаем редирект на sso.com с зашифрованным обратным адресом. sso.com удаляет сессионную cookie и связь ID сессии с ID пользователя в базе. Пользователь вышел!

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

Буду рад, если наш опыт будет вам полезен. Конструктивная критика приветствуется.

Update: Спасибо DileSoft и divedeep за ценные замечания, которые учел в этой схеме.

Поддомены Google oauth

Я внедрил Google oAuth на сайте (example.com). Все работает отлично, кроме auth из субдоменов на моем сайте (у меня есть тысячи поддоменов). Когда пользователь пытается выполнить авторизацию через субдомен, например

Я получаю сообщение об ошибке от Google —

Как это можно решить?

Это потому, что Google OAuth не поддерживает сопоставление поддоменов подстановочных знаков. Вы можете обратиться к дополнительной документации здесь

Другие ответы уже выяснили, что причиной неприятностей является то, что Google OpenAuth не поддерживает поддомены подкачки. Однако, что вы спрашиваете, как это можно решить? Ну, у вас есть два варианта, в соответствии с этой электронной почтой:

Обеспечьте единую конечную точку обработки OAuth2 для всех поддоменов. То есть у вас будет основной домен и конечная точка, через которые вы также выполняете аутентификацию для поддоменов. Когда выполняется аутентификация, вы перенаправляетесь обратно в поддомен. Там предположительно параметр состояния OpenAuth, в котором вы можете кодировать имя поддомена. Это то, что я сделал, вот код: https://github.com/debiki/debiki-server/blob/master/app/controllers/LoginWithOpenAuthController.scala

Вы можете независимо регистрировать каждый поддомен с помощью Google.

Какой вариант вы выберете, зависит от того, какой бренд просят пользователи Google одобрить. Основной домен или поддомен?

Как сделать единый вход (авторизацию) для поддоменов?

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В пошлый раз мы рассмотрели, как находить основной шлюз в операционных системах. Сегодня я хочу вернуться к рассмотрению еще одной настройки для программного продукта ManageEngine ServiceDesk. В данной статье мы рассмотрим механизм сквозной авторизации (SSO) или как его еще называют единый вход. Данный механизм поможет пользователям открывать сервис деск без ввода логина и пароля, используя учетные данные под которыми они вошли в систему.

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

Есть такая вещь, как SSO (Single-Sign-On) или как ее еще именуют сквозная авторизация — это по сути единый вход на сервис, без ввода логина и пароля с использованием текущих учетных данных, которые были использован при авторизации на компьютере. Большинство современных программных комплексов стараются внедрять у себя SSO, например как у vCenter, где он добавляет Windows авторизацию. ManageEngine ServiceDesk в этом плане не исключение. Тут два варианта реализации, первый это служба федерации Active Directory для всех браузеров, и требует дополнительного сервера или встроенная SSO, но там есть ограничения на поддерживаемые браузеры, будут работать Internet Explorer, Google Chrome.

Топ-пост этого месяца:  Групповые действия (bulk_actions) в таблицах постов, страниц, юзеров, комментов…

Алгоритм SSO в ManageEngine ServiceDesk

Когда служба хочет инициировать единый вход, сначала необходимо создать безопасный канал с контроллером домена, и этот же сервис должен использоваться службой для дальнейшего процесса аутентификации в Active Directory. В многодоменной среде служба будет иметь защищенное соединение только с одним контроллером домена, и тот же будет аутентифицировать пользователей других доменов, используя доверительные отношения с этим доменом.

ServiceDesk Plus внедрил безопасный канал в Active Directory, используя службу NETLOGON через учетную запись компьютера. Для включения службы NetLogon эта учетная запись компьютера требует пароль. Сервис NetLogon является внутренним каналом связи Microsoft. Один компьютер создаст уникальный идентификатор в домене и создаст некоторый случайный пароль для дальнейшей связи в домене. Например, когда пользователь пытается войти в систему, компьютер выдаст свою идентификационную информацию AD, а затем попытается аутентифицировать пользователя.

Учетные записи пользователей используются для доступа, и он не может напрямую взаимодействовать с AD, поэтому мы используем учетную запись компьютера для netlogon. Поскольку пароль генерируется случайным образом во время регистрации компьютера в домене, то вы его явным образом не будите знать.

ServiceDesk Plus использует VBScript для создания учетной записи компьютера и установки пароля для них. Начиная с версии 7600, ServiceDesk Plus для сквозной аутентификации использует метод NTMLV2, который обеспечивает лучшую безопасность и проверяет учетные данные с помощью сервиса NETLOGON, и NTLMV1 больше не будет поддерживаться.

Показывать настройку сквозной авторизации я буду на ManageEngine ServiceDesk 10016, которую я недавно обновил. Открываем веб интерфейс ManageEngine ServiceDesk, находим раздел «Параметры — Active Directory».

Находим раздел «Проверка подлинности Active Directory» и активируем функцию «Включить сквозную авторизацию (единый вход)».

Пожалуйста, выберите доменное имя, с которого вы хотите настроить сквозную аутентификацию. Вы можете включить сквозную аутентификацию для пользователей из определенного домена/леса AD. Чтобы аутентификация выполнялась для других пользователей домена, другой домен должен иметь доверительные отношения с выбранным доменом или родительские и дочерние отношения. В случае домена Parent-Child, здесь должен быть выбран только родительский домен. После настройки доверительных отношений в AD необходимо настроить сквозную проверку подлинности.

Чтобы использовать поставщик безопасности NTLM в качестве службы проверки подлинности, необходимо создать учетную запись компьютера в Active Directory с определенным паролем, который соответствует политике паролей в Active Directory. Укажите уникальное имя для учетной записи компьютера и пароль для этой учетной записи. Примечание. Убедитесь, что ваш пароль соответствует политике паролей домена. Тогда имя учетной записи компьютера не должно быть более 12 символов и не должно содержать никаких специальных символов.

  • Имя домена — пишем корневой домен в лесу
  • Учетная запись компьютера — имя компьютера, который будет создан для SSO в вашем домене. Если учетная запись компьютера была создана заранее, то поместите ее на время сброса пароля в контейнер «Computers».
  • Пароль — пароль компьютера, который создан для SSO. ПАРОЛЬ не должен содержать спец символов, иначе работать не будет.
  • IP адрес или DNS сервер — тут обычно прописывают контроллере домена
  • Строка привязки (Bind String) — суда пишется DNS суффикс домена, обычно совпадает с именем рутового домена в лесу.
  • Сайт DNS — имя сайта Active Directory, где находится контроллер домена, к которому идет подключение.

Если вы указываете имя существующей учетной записи компьютера, указанный здесь пароль также будет установлен в Active Directory для этой учетной записи компьютера. Вы также можете сбросить пароль учетной записи компьютера, нажав на ссылку «Сбросить пароль». Даже если при создании учетной записи компьютера или сброса пароля (уже созданной учетной записи компьютера) из приложения возникнет ошибка, сведения, указанные в окне, будут сохранены в базе данных приложения. Загрузите сценарии и сохраните сценарии NewComputerAccount.vbs и SetComputerpass.vbs. Оба сценария нам пригодятся.

Запуск сценариев на сервере Active Directory

Скопируйте в корень диска C:\ оба сценария, NewComputerAccount.vbs и SetComputerpass.vbs.

  • NewComputerAccount.vbs — создаст в Active Directory в контейнере Computers новую учетную запись компьютера с нужным вам паролем
  • SetComputerpass.vbs — позволит поменять пароль у уже существующей учетной записи компьютера

На контроллере домена, куда вы скопировали ваши скрипты, откройте командную строку от имени администратора. Перейдите в командной строке в корень диска C:\, через команду cd C:\. Если нужно создать новый компьютер, то введите:

CSCRIPT NewComputerAccount.vbs servicedesksso /p пароль /d pyatilistnik

Если нужно сменить пароль, то конструкция будет такой

CSCRIPT SetComputerPass.vbs servicedesksso /p пароль /d pyatilistnik

Так же я вас советую включить логирование на вашем сервере ManageEngine ServiceDesk, поставив соответствующую галку в SSO. Логи будут лежать в C:\ManageEngine\ServiceDesk\logssso.txt

Настройка браузера для SSO

Откройте ваш Internet Explorer и перейдите в его свойства.

Перейдите на вкладку «Безопасность» далее «Местная интрасеть — Сайты» нажимаем кнопку «Дополнительно» и добавляем адрес нашего ManageEngine ServiceDesk в узлы.

Установите на интрасети, низкий уровень безопасности и нажмите кнопку «Другой»

Активируйте пункт «Автоматический вход в сеть с текущим именем пользователя и паролем»

Далее сохраните настройки и перейдите на вкладку «Дополнительно» и активируйте галку «Разрешить встроенную проверку подлинности Windows»

После этого закройте Internet Explorer и заново откройте. Проверьте сквозную авторизацию в ManageEngine ServiceDesk.

Включаем Kerberos аутентификацию в Google Chrome

Google Chrome берет все настройки SSO из Internet Explorer, так что настройте его и еще выполните вот такую команду. Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

Единый вход для нескольких поддоменов

Мне нужно разместить несколько различных услуг на различных подобластей, разделяющих один и тот же домен верхнего уровня, и я хочу, чтобы централизовать процедуру входа.

Идея состояла в том, чтобы:

И перенаправить пользователей на login.tld.com . Затем, после входа, они могут иметь доступ к услугам.

Какой самый лучший способ в PHP, чтобы он реализован и закреплен?

Можно ли не хранить локальный куки и держать сессию открытой?

добавляя больше деталей

Мне нужно, чтобы пользователь также имеет возможность запоминать соединение после того, как он закрывает браузер. У меня есть полный доступ к серверу, таким образом, я могу настроить php.ini, как я хочу

Если вы не хотите, чтобы установить любые местные печенья, вы должны придерживаться сессий. Имея сеанс через поддомены работает чуть-чуть иначе, чем только на одном домене. Так что давайте начнем.

Во- первых , мы должны дать нашей куки сессии новый session_name () . Мы должны сделать это , потому что имя сеанса должно быть определено перед установкой параметров печенья. Это будет хранить старое название сеанса под $old_name и обновить название вашей сессии на «некоторое_имя»:

Далее мы должны установить параметры сеанса печенья с session_set_cookie_params () . Вот где мы говорим на наш сервер , где функция куки будет сессия:

Предшествующей 3-й paramenter (домен «tld.com») с точкой, мы удостоверяясь куки сессии будут видны на все поддомены. В качестве альтернативы, вы можете также использовать:

Наконец конечно , мы должны начать или возобновить нашу сессию в нашем сценарии с session_start () :

Таким образом, чтобы подвести итог, вы должны иметь это в начале каждого сценария, который будет использовать свои сессии:

Добавить комментарий