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. Приветствую!
    подскажите ,а как быть, если Internal и External URL OWA совпадают?

    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, и не используете единое пространство? Плюсы есть очевидные в Вашем сценарии?

  2. Дмитрий, спасибо за ответ.
    Ситуация у меня следующая:
    есть три сайта – сайт в ДЦ (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 их показывает.

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

      2. Берите в руки Fiddler и смотрите, что происходит в действительности. Вся правда будет видна.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.