Немного про сертификаты… или как починить постоянный redirect owa в Exchnage


ssl

Не все знают, что мощные и современные продукты, такие, как S4B/Lync, Exchnage 2013/16, ADFS 2012R2, и даже другие продукты (например, VMware View) не поддерживают сертификаты CNG.

Screenshot_4

В Lync ошибка может быть при назначении сертификатов Error: An error occurred: “System.Security.Cryptography.CryptographicException” “The buffer supplied to a function was to small””

В TMG при назначении сертификата на листнер, можете получить ошибку “Incorrect key type”

В Exchange мы получим бесконечный редирект в OWA и ECP при использовании FBA.

Но, как показала практика, администраторы серверов и слыхом не слыхивали, что вместо FBA можно использовать SSO.

VMware Horizon View тоже откажется пускать пользователей после смены сертификата на новый, v3.

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

Проверяем вывод команды Certutil.exe -v -store my <thumbprint>, и берем отпечаток нашего сертификата.

Смотрим вывод строки Provider. Если вывод «Provider = Microsoft Software Key Storage Provider», то это плохо. И работать такой сертификат не будет.

Должно быть “Microsoft Enhanced Cryptographic Provider v1.0” либо “Microsoft RSA SChannel Cryptographic Provider”.

Рассмотрим варианты, как бороть проблему. Вариант первый- читать гайды по запросу сертификатов для продукта, где указывается, КАК и почему надо делать. Например, в гайдах Exchnage или Lync администратору зачем-то дают готовый шаблон, который остается скопировать в записную книжку, и администратор этой проблемы если он не боится powershell даже не увидит. Сделайте выводы, если у вас есть проблема с сертификатами, подумайте о ее первопричинах. Возможно, не во всем виноват проклятый Майкрософт, который не поддерживает в данных продуктах CNG, а использует legacy CryptoAPI, работающий на старых добрых Cryptographic Service Providers (CSP). Поэтому- просто ПРАВИЛЬНО перезапросите сертификат, используя предложенную документацию.

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

Ну, например, это не бесплатно, и это не наш метод!

Наш метод такой: Качаем openssl и экспортируем наш проблемный сертификат в pfx , либо берем готовый.

Открываем командную строку с повышенными привилегиями, переходим в каталог \openssl\bin.

Конвертируем наш .pfx в .pem
openssl.exe pkcs12 -in certificate.pfx -out certificate.pem -nodes

Затем конвертируем обратно из .pem в  .pfx
openssl.exe pkcs12 -export -in certificate.pem -out new_certificate.pfx

Cамые внимательные читатели знают, что можно использовать еще и certutil:

certutil -csp «Microsoft RSA SChannel Cryptographic Provider» -importpfx <CertificateFilename>

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

Ссылки по теме:

https://blogs.perficient.com/microsoft/2013/12/lync-support-for-cryptoaping-certificates/

https://anotherexchangeblog.wordpress.com/tag/importpfx-command-failed-0x80090029/

http://blogs.technet.com/b/jasonsla/archive/2015/01/15/the-owa-and-ecp-fba-redirect-loop.aspx

http://blog.vaglid.net/?p=4

Реклама

Bad request (HTTP 400 error) в Exchange 2013 OWA и ECP


Проблема:

После установки CU на один из серверов внезапно перестала работать OWA и ECP. Вдумчиво набитая трубка распечаткой журнала C:\ExchangeSetupLogs\exchangeSetup.log результатов не дала, в то же время ActiveSync, Outlook Anywhere, и все прочее работали без проблем.

Но не OWA:

ecp

На смартфонах все же было видно форму Outlook Web App, однако после ввода (правильных) учетных данных, пользователю выдавалась ошибка:

“Outlook web app didn’t initialize. If the problem continues please contact your helpdesk.

Couldn’t find a base theme (folder name=base)”

В журналах самого сервера фигурировала ошибка:

Screenshot_4

Решение:

Перво наперво было принято решение пересоздать виртуальные каталоги OWA и ECP, как это уже обсуждалось ранее в блоге. Увы, это не помогло.

А помогло вот что: [ТЗ mode on]

Идем на наш CAS сервер, открываем директорию C:\Program Files\Microsoft\Exchange Server\V15\Bin

(обратите внимание, не $exscripts), и запускаем из нее последовательно скрипты UpdateCas.ps1, который пересоздаст интерфейс OWA , и UpdateConfigFiles.ps1.

Примечание: скрипты нигде не упоминаются в официальной документации Microsoft.

Тем не менее, исправляют ситуацию и возвращают OWA  радостным пользователям.

Не создается виртуальная директория owa Exchange 2013


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

Screenshot_4

Что же делать? Каталог вроде бы есть, и в то же время его нет.

Чтобы успешно пересоздать каталог, необходимо в такой ситуации удалить его и из AD:

идем по пути

Configuration—>CN=Services—>CN=Microsoft Exchange—>CN=Organization—>CN=Administrative            Groups—>CN=Exchange Administrative Groups—>CN=Servers—>CN=Exchange—>CN=Protocols—>CN=HTTP

и удаляем каталог owa.

Screenshot_9

После этого скачиваем IIS 6.0 Resource Kit Tools, открываем “Metabase Explorer”

Открываем: Exchange -> LM -> W3SVC -> 1 -> ROOT. Удаляем owa и здесь.

Screenshot_5

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

New-OwaVirtualDirectory  -InternalUrl “https://ServerName/owa” -ExternalUrl “https://mail. domain.com/owa”

New-OwaVirtualDirectory  -InternalUrl “https://ServerName/owa” -ExternalUrl “https://mail. domain.com/owa” -WebSiteName “Exchange Back End”

Обратите внимание на сайт бэкенда, присутствующий на Mailbox’e.

https://technet.microsoft.com/en-us/library/ff629372.aspx

То же самое справедливо и для каталога ECP

Screenshot_6

OWA SSO


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

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

Дело о удаленных элементах, невидимых в OWA или Outlook…


Иногда  обычный пользователь может столкнуться  лицом к лицу со странной проблемой — размером его…. почтового ящика. 🙂

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

В один прекрасный солнечный июньский день один прекрасный солнечный пользователь обратился с прекрасной солнечной проблемой «переполненного, но совсем пустого» почтового ящика в прекрасному и солечному администратору. 🙂

Будучи еще с времен альма матер любителем точных чисел, администратор взглянул на размер почтового ящика в статистике сервера (а надо вам сказать, о внимательные читатели мои, это был Exchange 2007) , и что же он увидел?

Размер почтового ящика, пустого  чуть более чем наполовину, был равен 1,7 GB…. Читать далее