Одна из концепций облака Office 365 — это «single sign-on» для пользователей, что весьма всех радует, и в интернетах часто можно прочитать заявления, что если вы внедрите у себя AD FS, то получите «единый вход» — SSO. Согласиться с этим утверждением можно лишь отчасти, поскольку AD FS действительно предоставляет SSO для большинства популярных приложений Office 365, но не для Outlook, который является, наверное самым популярным.

Давайте разберемся, почему так происходит.

Почему Outlook не поддерживает Single Sign-On

credПредставим среду гибридного развертывания. Есть Office 365 и AD FS, ящик пользователя передвинут в облако. На изображении мы видим запрос пароля при запуске Outlook, происходящий потому, что Outlook использует “basic authentication” over HTTPS для Exchange Online, и если посмотреть на трафик между клиентом и сервером, то можно увидеть, как EXO аутентифицируется на сервере AD FS от имени пользователя. После того, как пользователь введет учетные данные, он может воспользоваться опцией «сохранить» пароль, используя Диспетчер учетных данных Windows. (Именно это «решение» мне предложили использовать представители поддержки MSFT на форуме community.office365.com). В таком случае у пользователя действительно будет «подобие SSO»- при следующем запуске пароль не будет запрашиваться, поскольку учетные данные сохранились. Однако при следующей смене (сбросе) пароля проблемы вновь возникнут.

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

Еще одной сложностью является то, что текущий процесс аутентификации не позволяет воспользоваться многофакторной аутентификацией (MFA), и вместо легкого использования Azure Multi-Factor Authentication единственный выбор- это использование функционала “App Passwords”, который пока далек от совершенства.

Современная Аутентификация

В начале прошлого года мы услышали о “Modern Authentication”, и как она решит озвученные выше проблемы. Прошло больше года, и появились многочисленные обновления, исправлявшие всевозможные проблемы. Изначальный список был довольно длинный но все удалось допилить. В марте 2015, был анонсирован public preview программы и всем желающим предлагалось использовать обращение в поддержку.

Включение Современной Аутентификации

Итак, Modern Authentication поддерживается в Office 365:

Включена по умолчанию в SharePoint Online, требует включения администратором тенанта в Exchnage Online (см ниже), а для Skype for Business  требуется открыть заявку в Microsoft. На клиентской стороне Office 2016 поддерживает ее из коробки как приоритетную, а 2013 потребует внесение дополнительных настроек в реестр. Если Вы используете AD FS, ознакомьтесь со статьей KB3052203, действия из которой потребуется выполнить, поскольку конечная точка /adfs/services/trust/13/windowstransport по умолчанию отключена. Если используются заявки AD FS, ознакомьтесь с документом Understand how Modern Authentication will impact those rules.

Проверить и включить Modern Authentication в Exchnage Online можно так:

oath

Заводить заявку в поддержку сегодня уже не обязательно, но если Вы делали ее ранее- просто проверьте, включена ли поддержка для Вашего тенанта.

Диагностика Современной Аутентификации

Включите TCOTrace, файл с логом находится по пути %temp%\outlook.exe.txt

Ищем события в журнале вида

ADAL: message=’Could not discover endpoint for Integrate Windows Authentication. Check your ADFS settings. It should support Integrate Widows Authentication for WS-Trust 1.3.’, additionalInformation=’Authority: https://login.windows.net/common

и смотрим, что же может пойти не так.

Обновления, необходимые для МА:

Не нужно думать, что старенький Outlook 2013 без обновлений будет работать с современной аутентификацией. Не будет, если версии dll ниже, чем

 15.0.4625.1000:

  • C:\Program Files\Common Files\Microsoft Shared\OFFICE15\MSO.DLL
  • C:\Program Files\Common Files\Microsoft Shared\OFFICE15\Csi.dll
  • C:\Program Files\Microsoft Office\Office15\GROOVE.EXE
  • C:\Program Files\Microsoft Office\Office15\OUTLOOK.EXE

и сле��ующая dll должны быть выше чем 1.0.1933.710:

  • C:\Program Files\Common Files\Microsoft Shared\OFFICE15\ADAL.DLL

Это прожиточный минимум, который поможет понять, почему не работает аутентификация на клиенте, внезапно вылезшем из кустов. Чем новее Outlook, тем больше закрыто проблем, на которые Вы можете наступить. Для примера можно взять скрипт на Рowershell, который поможет это быстро проверить:

Write-host"Scanning for Office 2013 Modern Authentication prerequisites..."
If(Test-Path"HKLM:\SOFTWARE\Microsoft\Office\15.0\Common\InstallRoot") {
    #Create registry keys
    $Path= "HKCU:\Software\Microsoft\Office\15.0\Common\Identity"
    If(!(Get-Item$Path-ErrorActionSilentlyContinue)) {New-Item$Path-Force| Out-Null}
    New-ItemProperty$Path-NameVersion-PropertyTypeDWORD-Value1-Force| Out-Null
    New-ItemProperty$Path-NameEnableADAL-PropertyTypeDWORD-Value1-Force| Out-Null
    #Check for updates
    $UpdatesRequired= $False
    If(![bool]((Get-Item"C:\Program Files\Common Files\Microsoft Shared\Office15\MSO.DLL").VersionInfo.FileVersion  -ge"15.0.4625.1000")) {
    Write-host"MSO.DLL requires update - https://support.microsoft.com/en-us/kb/3085480"-ForegroundcolorRed
    $UpdatesRequired= $True
    }
    If(![bool]((Get-Item"C:\Program Files\Common Files\Microsoft Shared\Office15\Csi.dll").VersionInfo.FileVersion  -ge"15.0.4625.1000")) {
    Write-host"Csi.dll requires update - https://support.microsoft.com/en-us/kb/3085504"-ForegroundcolorRed
    $UpdatesRequired= $True
    }
    If(![bool]((Get-Item"C:\Program Files\Microsoft Office\Office15\Groove.exe").VersionInfo.FileVersion  -ge"15.0.4625.1000")) {
    Write-host"Groove.exe requires update - https://support.microsoft.com/en-us/kb/3085509"-ForegroundcolorRed
    $UpdatesRequired= $True
    }
    If(![bool]((Get-Item"C:\Program Files\Microsoft Office\Office15\Outlook.exe").VersionInfo.FileVersion  -ge"15.0.4625.1000")) {
    Write-host"Outlook.exe requires update - https://support.microsoft.com/en-us/kb/3085495"-ForegroundcolorRed
    $UpdatesRequired= $True
    }
    If(![bool]((Get-Item"C:\Program Files\Common Files\Microsoft Shared\OFFICE15\ADAL.dll").VersionInfo.FileVersion  -ge"1.0.1933.710")) {
    Write-host"ADAL.dll requires update - https://support.microsoft.com/en-us/kb/3055000"-ForegroundcolorRed
    $UpdatesRequired= $True
    }
    If($UpdatesRequired) {Write-host"Scan complete: install the updates and re-run the script"-ForegroundcolorRed}
    Else{Write-host"Scan complete: Office 2013 Modern Authentication prerequisites have been met"-ForegroundcolorGreen}
    }
Else{Write-Host"Scan complete: Office 2013 is not installed"-ForegroundcolorRed}
Read-Host
Самый печальный для многих момент в статье. Как верно поняли самые догадливые, современная аутентификация была прикручена на бегу к Outlook 2013, и нет никаких шансов, что она будет работать с более старшими версиями, такими, как например Outlook 2010, увидевший свет  более пяти лет назад, когда мало кто задумывался о добавлении функционала единого входа в приложение…
Что нужно помнить

Важно помнить, как работает обновление маркера в современной аутентификации. Хотя статья “Session Timeouts for Office 365” дает обзорные сведения об этом, некоторые детали в ней отсутствуют. Статья “Frequently Asked Questions about Modern Authentication in Office 2013” приводит более полные сведения, в частности:

  • Обновленный маркер действителен в течение 90 дней
  • Пользователь, который получил обновленный маркер и отключился от производственной сети продолжит  работать с валидным обновлением
  • Изменение федеративного пароля не влияет на обновление маркера
  • Запрос MFA не произойдет на устройстве до тех пор, пока маркер не будет обновлен

В заключение

В текущей реализации видно, что запрос MFA  и обновление маркера не могут быть контролированы так, как подсознательно этого ожидают администраторы, и, как любой функционал Office 365, будет улучшен в будущем…