none
Как сделать вход в ECP и OWA через HTTP, а не через HTTPS ? RRS feed

  • Вопрос

  • Subj, а то достало постоянное напоминание о том, что сертификат недействителен, хотя он стоит самозаверенный, но я так понял,, для входа через Инет надо покупать сертификат в VeriSign или др. фирме.

    Bill Gates

    27 ноября 2013 г. 9:46

Ответы

  • Привет,

    Можно стаделать редирект с HTTP на HTTPS, таким образом у Вас будет HTTP и более надежная структура:

    Simplify the Outlook Web App URL


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

    • Помечено в качестве ответа -STAS- 2 декабря 2013 г. 14:38
    28 ноября 2013 г. 8:02
    Модератор

Все ответы

  • Привет,

    Можно стаделать редирект с HTTP на HTTPS, таким образом у Вас будет HTTP и более надежная структура:

    Simplify the Outlook Web App URL


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

    • Помечено в качестве ответа -STAS- 2 декабря 2013 г. 14:38
    28 ноября 2013 г. 8:02
    Модератор
  • 1. Что бы настроить вход через HTTP необходимо в консоли IIS отключить "требовать SSL"

    Детальнее тут:

    http://www.mustbegeek.com/configure-url-redirection-in-exchange-2013/

    2. Для входа через интернет нет необходимости покупать сертификат от сторонних центров сертификации. Необходимо что бы клиент доверял вашему сертификату, который выставлен на OWA и т.д.. И сертификат был действительный. Для этого нужно что бы у клиента был в хранилище сертификатов корневой сертификат центра сертификации, сертификат был по времени действительный, были опубликованы CRL(списки отзыва) и AIA(цепочка сертификации) указанные в сертификате и клиент должен иметь возможность проверить єти данные через ссылки указанные в сертификате(+анонимная авторизация). Если он не может проверить CRL и AIA по какой либо причине, сертификат будет не действительным.

    3. Редирект HTTPS > HTTP не безопасен.


    28 ноября 2013 г. 8:29
  • 1. "Для этого нужно что бы у клиента был в хранилище сертификатов корневой сертификат центра сертификации, сертификат был по времени действительный,

    2. ...были опубликованы CRL(списки отзыва) и AIA(цепочка сертификации) указанные в сертификате и клиент должен иметь возможность проверить єти данные через ссылки указанные в сертификате(+анонимная авторизация). Если он не может проверить CRL и AIA по какой либо причине, сертификат будет не действительным"

    1. Так в том и проблема, что у пользователей теперь куча разных устройств в разных местах, и объяснять каждому, как установить сертификат в хранилище ... довольно проблемно. Потому видимо придётся сторонним воспользоваться. VeriSign или ещё какой.

    2. Поподробнее можно пожалуйста про CRL и AIA ?


    Bill Gates

    28 ноября 2013 г. 11:30
  • Лучше взять триальный сертификат, проверить на нем, а потом купить публичный сертификат.

    Сазонов Илья http://isazonov.wordpress.com/

    30 ноября 2013 г. 10:11
    Модератор
  • Сегодня получить сертификат публичного СА весьма просто. Домен регулярно продлеваете? Посмотрите внимательно на список услуг, предоставляемых вашим регистратором. Например - http://www.nic.ru/dns/service/ssl/ . Не забудьте, что для работы с Exchange необходим набор имён в сертификате.

    > 2. Поподробнее можно пожалуйста про CRL и AIA ?

    Если у Вас нет своего доменного СА, оно вам не надо. Если есть, или планируется к развёртыванию, пути к спискам отзыва и сертификатам указываются при настройке СА, именно доступ "туда" и нужно обеспечить снаружи.


    S.A.

    30 ноября 2013 г. 19:33
  • Домен продлеваем регулярно уже 8 лет. Только у нас не ник, а валюхост. У него такой услуги не видел. Да, и СА у нас есть свой, доменный.

    Bill Gates

    1 декабря 2013 г. 12:10
  • Что ж, тогда воспользоваться услугами хоть того же rucenter, стандартный сертификат на набор доменных имён вполне подойдёт.

    "СА у нас есть свой, доменный" - а почему сертификат на Exchange самоподписанный, а не от доменного СА? :) Ну, неважно -

    Для сертификатов от доменного СА, открыть для просмотра любой из них, и на вкладке "Состав" посмотреть значения параметров "Точки распространения списков отзыва (CRL)" и "Доступ к информации о центрах сертификации". Как минимум один (для каждого параметра) из методов и путей должен быть доступен "снаружи".

    Если внутреннее и внешнее имена доменов совпадают, это очень просто (достаточно публикации 1:1 и прописывании на внешнем dns). Если нет ... зависит от. Как минимум, понадобится прописывание внешних путей в настройках СА и перевыпуск сертификатов. Естественно, требуется тщательное планирование, чтобы проверки работали (с минимальными задержками) как изнутри, так и снаружи.

    То есть, с учётом необходимости (она никуда не девается) обеспечения доверия своему рутовому сертификату на любых пользовательских устройствах (прописывания его туда тем, или иным способом), затраты порядка 5 тыр в год могут оказаться существенно оптимальнее.


    S.A.

    1 декабря 2013 г. 12:57
  • С сертификатом уже разобрались - теперь стоит доменный, действительный. Кстати, можно его как-нибудь автоматом продлевать ? По поводу получения сертификата от внешнего СА есть где-нибудь литература или хау-ту ?


    Bill Gates

    Дв ... по поводу входа через HTTP вместо HTTPS:

    Всё сделали по инструкции. Работает .. НО:

    При переводе авторизации вместо DOMAIN\User на User с предустановленным доменом domain.local сначала приходится вводить имя-пароль на HTTP-страничке, потом перенаправляет и вводим пароль ещё раз уже на HTTPS-странице ...

    Получается либо юзерам надо объяснять, что такое домен и в какую сторону наклонять "палочку" (\), либо объяснять, что надо к http (который они обычно не вводят, т.к. браузеры его подставляют сами) не забывать добавлять буковку "s" ... Хрен редьки не слаще выходит ... Они итак-то вместо mail.domain.ru норовят mail.ru ввести (да ещё в строке поиска Яндекса :)

    • Изменено -STAS- 2 декабря 2013 г. 14:29
    2 декабря 2013 г. 14:14
  • Продлевать сертификат "автоматом"? О наличии готовых средств для этого слышать не доводилось. Наверное, при горячем желании, можно сочинить скрипты с соответствующей функциональностью. Однако, это будет сильно не кошерно с точки зрения безопасности: как минимум, понадобится эккаунт с админскими правами и действительным на годы паролем, для запуска запланированного задания. Нехорошо.

    Хотя для "просто веб-сервера", чьё доменное имя совпадает с именем компьютера, можно просто использовать автоматически продлеваемый системой сертификат по шаблону "компьютер", для Exchange это не подходит. Но раз в пару лет вызвать оснастку "сертификаты", и нажать "Обновить этот сертификат с тем же ключом" (или с новым ключом, если что) - не сильно большая проблема? А соответствующие события с оповещениями у меня (с коллегой :)) в аутлуке отмечены.

    По поводу хау-ту по получению сертификата от внешнего СА - на том же nic.ru есть подробные инструкции, что и как нужно при покупке через них. Проблем не вызывает. У любого "продавца" должно быть аналогично.


    S.A.

    P.S. По "входу" - у меня с конца прошлого века :) просто настроена безусловная (сразу) переадресация с http://mail.domain на https://mail.domain, когда-то кодом, сейчас IIS-киными средствами, ничего никому дважды вводить не надо. А пользователям проще объяснять, что "логин это почтовый адрес - user@domain" ;)
    2 декабря 2013 г. 15:14

  • S.A.

    P.S. По "входу" - у меня с конца прошлого века :) просто настроена безусловная (сразу) переадресация с http://mail.domain на https://mail.domain, когда-то кодом, сейчас IIS-киными средствами, ничего никому дважды вводить не надо. А пользователям проще объяснять, что "логин это почтовый адрес - user@domain" ;)
    В IIS как это сделать ?

    Bill Gates

    3 декабря 2013 г. 7:14
  • Собственно, оно описано по уже отмеченной в качестве ответа ссылке выше. Тонкий момент - разрешить анонимный доступ (разрешения на чтение для IIS_IUSRS) на корень сайта (только!), тщательно проверив, конечно же, чтобы на owa, ecp, ews ... это не распространялось.

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

    И да, если сервер(а) доступен не напрямую, а через публикацию на ISA/TMG (как у нас), делегирование проверки подлинности должно быть "Без делегирования, но клиент может ..." (и "без проверки подлинности" в listener). Ещё, у меня два раздельных правила, по HTTP доступ только к корню сайта (для переадресации), и только по HTTPS на всё остальное... но это просто "на всякий случай" :).


    S.A.

    4 декабря 2013 г. 8:43