Ожидаемое поведение:

Когда пользователь впервые входит в свой профиль пользователя Windows и загружает Outlook 2016, запускается мастер настройки профиля Outlook, и от пользователя требуется лишь несколько раз нажать «Далее», чтобы настроить его автоматически и правильно.

* Обратите внимание, что это работало, как и ожидалось, до обновления офиса, вероятно, 6 или более месяцев назад.

Ошибка:

Проблема, которая возникает, заключается в том, что наш поставщик услуг электронной почты (1 и 1) или Outlook изначально не делает этого, кроме учетных данных для входа в систему, прошедших процесс автообнаружения Outlook 2016 в настройке / мастере профиля Outlook. Это требует, чтобы пользователь вводил свои учетные данные минимум 3 или более раз. Это для пользователей, которые загружают свою учетную запись / профиль в первый раз.

Окружающая среда и информация:

У меня есть подключенные к домену клиентские компьютеры Windows 10 с учетными записями пользователей, которые хранятся на сервере активных каталогов, и установка MS Outlook 2016 MSI развернута. Домен / учетная запись электронной почты не совпадает с полным доменным именем AD и не является учетной записью Office365. Это стандартный почтовый сервис 1and1. У меня есть информация о пользователе и адрес электронной почты на AD. Когда пользователь открывает Outlook в первый раз, запускается мастер настройки профиля. Когда пользователь проходит установку, мастер предварительно заполняет адрес электронной почты из AD, и процесс автообнаружения начинается, как и ожидалось. На третьем шаге "Вход на сервер" появляется приглашение для входа в учетную запись 1and1. Пользователь предоставляет свой пароль (адрес электронной почты уже заполнен) и отправляет его. Тем не менее, приглашение продолжает возвращаться. Я проверил это, и если вы выберете "Сохранить пароль", он будет запрашивать в общей сложности 3 раза, пока не примет его и не сохранит.

Насколько я понимаю, процесс автообнаружения извлечет параметры подключения из файла autdiscover.xml и затем передаст учетные данные учетной записи пользователя windows, как это было раньше. При просмотре журнала он находит файл autodiscover.xml с сервера 1 и 1 и загружает настройки, но не проходит проверку подлинности. У кого-нибудь есть идея, что происходит? Есть ли обходной путь или способ заставить конкретный протокол аутентификации для пользователя / прохода?

Я пробовал несколько параметров в групповой политике для процесса проверки подлинности, но, похоже, настройки только для Exchange/Office365.

Любая помощь или направление, чтобы найти решение приветствуется.

-------- Обновление 8-17-2017 ---------

Я попытался выполнить ответ, предложенный Магнусом ниже, но это диалоговое окно недоступно, когда профиль Outlook не существует, когда пользователь загружает Outlook. Однако я настроил тестовый объект групповой политики для определенного пользователя / машины в нашей сети и со следующими настройками:

  • Конфигурация пользователя> Шаблоны администрирования> MS Outlook 2016> Настройки учетной записи> Exchange> Аутентификация с Exchange Server, установленным в NTLM

  • Конфигурация пользователя> Шаблоны администрирования> MS Outlook 2016> Параметры учетной записи> Exchange> Параметр проверки подлинности прокси-сервера RPC установлен на NTLM

С этими наборами все равно не ходи. Еще раз он предлагает пользователю 3 раза с учетными данными для входа. Я где-то читал статью (не могу найти ее в Google), что в текущей версии Outlook 2016 с обновлениями она сильно зависит от того, что установлено в автообнаружении. Я предполагаю, что он ищет протокол в автообнаружении (если он существует) независимо от того, что я установил в своем тестовом объекте групповой политики.

С учетом вышесказанного я включаю данные журнала и результатов из «Test Autoconfig Tool» в Outlook. Пожалуйста, обратитесь ниже и дайте мне знать, если у кого-нибудь есть какие-либо предложения. Я думаю, что мне, возможно, придется как-то создать свой собственный ответ XML.

Скриншот автообнаружения журнала

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover
  xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response
    xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>FirstName LastName (user@domain.com)</DisplayName>
      <AutoDiscoverSMTPAddress>user@domain.com</AutoDiscoverSMTPAddress>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>

      <Protocol>
        <Type>IMAP</Type>
        <LoginName>user@domain.com</LoginName>
        <Encryption>SSL</Encryption>
        <Port>993</Port>
        <Server>imap.1and1.com</Server>
        <SPA>off</SPA>
        <TTL>0</TTL>
      </Protocol>

      <Protocol>
        <Type>POP</Type>
        <LoginName>user@domain.com</LoginName>
        <AuthRequired>on</AuthRequired>
        <Encryption>SSL</Encryption>
        <Port>995</Port>
        <Server>pop.1and1.com</Server>
        <SPA>off</SPA>
        <TTL>0</TTL>
      </Protocol>

      <Protocol>
        <Type>SMTP</Type>
        <LoginName>user@domain.com</LoginName>
        <Encryption>Auto</Encryption>
        <Port>587</Port>
        <Server>smtp.1and1.com</Server>
        <SPA>off</SPA>
        <UsePOPAuth>on</UsePOPAuth>
        <TTL>0</TTL>
      </Protocol>

    </Account>
  </Response>
</Autodiscover>

1 ответ1

0

Возможно, что Outlook пытается аутентифицироваться с помощью метода Negotiate , который использует Kerberos. Вы можете увидеть список вещей, которые можно попробовать здесь.

Мобильный Outlook не настроен для использования проверки подлинности NTLM

Функция мобильного Outlook позволяет вам получить удаленный доступ к своей учетной записи Exchange из Интернета, когда вы работаете за пределами брандмауэра вашей организации.

При использовании Outlook Anywhere для подключения к вашему серверу Exchange нам нужно выбрать метод аутентификации среди обычной аутентификации, NTLM-аутентификации и согласованной аутентификации. Разница между ними заключается в том, как пароли отправляются при подключении к серверу. При базовой аутентификации пароль отправляется в виде открытого текста. Использование проверки подлинности NTLM может значительно сократить количество запросов пароля.

Чтобы проверить настройки аутентификации, перейдите в «Файл»> «Настройки учетной записи»> «Настройки учетной записи», выберите учетную запись Exchange и нажмите « Изменить». В мастере изменения учетной записи нажмите « Дополнительные параметры», а затем перейдите на вкладку « Подключение ». Нажмите кнопку «Настройки прокси-сервера Exchange», и теперь вы можете увидеть настройки в разделе «Настройки аутентификации прокси». Попробуйте изменить аутентификацию на NTLM Authentication, а затем снова проверьте проблему.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .