Поделиться через


Single Sign On для Exchange OWA (ECP)

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

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

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

https://fromreallife.files.wordpress.com/2015/09/12.jpg?w=700

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

https://fromreallife.files.wordpress.com/2015/09/24.jpg?w=700&h=294

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 — зона ограниченных узлов

https://fromreallife.files.wordpress.com/2015/09/15.jpg?w=700

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

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

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