OWA SSO


Single Sign On безусловно, хорошая штука, но с Exchange ее применяют очень редко. Почему? Скорее всего, потому, что про нее администраторы и не знают: общаясь с коллегами, несколько раз безуспешно пытался выяснить отличия различных форм аутентификации для виртуальных каталогов Exchange- часто многие путаются в показаниях и представляют себе довольно туманно, зачем нужны те или иные разновидности аутентификации. Все это, конечно, доходчиво описано в библиотеке им. Ленина.

Большинство облачных сценариев использует как дополнительный огромный плюс SSO для пользователей домена при открытии корпоративной страницы почты. Чем локальная инсталляция хуже? Да, собственно, ничем- давайте посмотрим, как включить SSO для пользователей домена, тем более, что этот функционал можно добавить и к другим «тайным» для многих возможностям Exchange, о которых упоминалось ранее.

  1. Просмотрим дефолтные методы аутентификации для понимания картины:

1

2. Определим для пользователей корпоративной сети метод windows authentication для OWA и ECP, для применения параметров сразу же необходимо выполнить  iisreset.

2

3. Данный шаг рекомендуется выполнить при помощи групповых политик, в объекте GPO необходимые параметры находятся по пути Computer Configuration-Policies- Administrative Templates-Windows Components-Internet Explorer-Internet Control Panel -Security Page- Sites to zone assigned list. Здесь нам необходимо добавить второе условие для успешного «прозрачного» входа пользователя на страницу входа без повторного запроса учетных данных- сайт корпоративной почты должен быть в списке доверенных. Добавляем сайт в список, выставляем параметр 2 напротив. Параметры для номеров зон следующие:
1 — интрасеть
2 — доверенные узлы
3 — зона интернет
4 — зона ограниченных узлов

1

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

Как внутренний, так и публичный сертификат подойдет.

Troubleshooting: Проверяем, что клиент доверяет сертификату, сайт со страницей входа в доверенных, и метод авторизации WA. Результат: «прозрачный» для пользователя вход на страницу почтового сервиса без повторного ввода учётных данных.

Полезные ссылки:

http://support.microsoft.com/kb/2871485

http://blogs.technet.com/b/exchange/archive/2015/02/11/configuring-multiple-owa-ecp-virtual-directories-on-the-exchange-2013-client-access-server-role.aspx

http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/enabling-forms-based-authentication-external-internal-owa-2010-users-exchange-2010-published-using-forefront-tmg-2010-part1.html

Реклама

7 Replies to “OWA SSO”

    1. Никаких проблем не вижу, собственно. Пропишите SPN правильно для нужного сервиса, и Керберос будет у Вас корректно работать.
      Единственное только что — есть момент с публикацией через ISA-TMG, listner должен быть с одним суффиском.
      http://blogs.technet.com/b/exchange_ru/archive/2012/02/20/owa-exchange-2010-sp2.aspx
      https://social.technet.microsoft.com/forums/ru-RU/aa862f72-7884-49f9-aa07-af5f8fbfc48d/-sso-owa-exchange-2007-exchange-2010
      Так что, если у Вас именно такая ситуация, растущая из домена .local, то привет проектировщику.
      К Вам тогда будет маленький вопрос- а зачем Вы сознательно разделили URL, и не используете единое пространство? Плюсы есть очевидные в Вашем сценарии?

  1. Дмитрий, спасибо за ответ.
    Ситуация у меня следующая:
    есть три сайта — сайт в ДЦ (2 сервера Exchange (CAS+MBX)), сайт в офисе 1 (2 сервера Exchange (CAS+MBX)) ,сайт в офисе 2 (серверов Exchange нет, только пользователи). Одна DAG.

    Internal и External URL:
    — для сайта ДЦ: mail.domain.ru
    — для сайта Офис1: mail2.domain.ru

    Сайт ДЦ является основным, т.е. базы активны там. Сайт Офис1 — резервный (копии баз).

    Я пробовал настроить SSO по Вашей статье как раз только на резервном сайте, но в результате внутри FBA, а снаружи идет запрос без FBA.

    а насчет SPN можно подробней?

    1. Я буду краток, с Вашего позволения. FBA работать не должен, если мы говорим об SSO. Мы, выбирая windows auth, опираемся в этом случае на керберос и его работы с service principal names. Т.е. точно так же, как на файловом сервере у вас прописан SPN для CIFS, и есть прозрачный доступ без повторного ввода пароля, как это было бы в случае ntlm. Таким образом, если сервер один- то SPN обычно сервис рисует сам. Если два и более- рисует администратор.
      Почитайте на выходных https://fromreallife.wordpress.com/2014/11/11/%D0%B2%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B0-kerberos-%D0%B2-exchange-2013/

      1. Спасибо.
        Понятно как должно быть, но по факту изнутри почему-то запрашивает FBA.
        а ASA у меня прописаны, и setspn.exe -l их показывает.

        Но вот почему-то не работает….

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s