none
Exchange 2013 и Windows XP - постоянный запрос пароля RRS feed

  • Вопрос

  • Добрый день. Перевожу потихоньку организацию на Exchange 2013. Вроде всё ок - с клиентами у которых Windows 7 и выше - проблем нет. Обнаружились проблемы с Windows XP - Outlook постоянно требует пароль. Если с нуля добавлять в Outlook учетную запись - видно, что при попытке входа на сервер запрашивается пароль (запрос идет к CAS-массиву. Конфигурация ниже).

    Что имеем - Exchange 2013 cu8. Два CAS-сервера: cas01.domain.local, cas02.domain.local. Используется NLB-кластер.

    Outlook Anywhere на всех серверах клиентского доступа настроен с такими параметрами:

    ExternalHostname : mail.contoso.com
    InternalHostname : cas-array.domain.local
    ExternalClientAuthenticationMethod : Ntlm
    InternalClientAuthenticationMethod : Ntlm
    IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
    SSLOffloading                      : True
    ExternalClientsRequireSsl          : False
    InternalClientsRequireSsl          : False

    Во внутренней сети DNS-записи cas-array.domain.local и mail.contoso.com - обе ссылаются на ip-адрес NLB-кластера.

    Извне - mail.contoso.com - это адрес обратного прокси.


    16 апреля 2015 г. 10:06

Ответы

  • Итак - проблему удалось решить двумя способами.

    Первый. Действия с локальной политикой безопасности действительно помогли:

    Computer Configuration\Windows\Settings\Security Settings\Local Policies\Security Options. В параметре Network security: LAN Manager authentication level выбираем Send NTLMv2 response only

    При этом у меня в OA были следующие настройки:

    ExternalClientsRequireSsl          : False
    InternalClientsRequireSsl          : False

    -----------------------------------------------------------

    Второй метод. Как оказалось - достаточно было в OA всего-лишь включить требование SSL для внутренних клиентов. В итоге я включил и для внутренних и для внешних (включаем конечно же на всех CAS-серверах).

    ExternalClientsRequireSsl          : True
    InternalClientsRequireSsl          : True

    Есть замечание - у меня в сертификате на CAS-серверах первым прописано общее имя балансировщика (cas-array.domain.local), а затем уже имена серверов и т.д. И т.к. Windows XP не умеет читать в SAN-записи сертификата дальше первой строчки (об этой проблеме можно прочитать в этой статье) - то в моем случае всё проходит нормально:

    Windows XP пытается подключиться к cas-array.domain.local. Служба autodiscover нам говорит, что для этого подключения CertPrincilalName должен быть равен "msstd:cas-array.domain.local", находит такую запись в первой строке поля SAN сертификата и удачно подключается.

    Если же к примеру в данном случае в поле SAN сертификата первая запись будет не cas-array.domain.local, а cas01.domain.local - то Windows XP уже не сможет подключиться:

    Windows XP пытается подключиться к cas-array.domain.local. Служба autodiscover нам говорит, что для этого подключения CertPrincilalName должен быть равен "msstd:cas-array.domain.local", но находит только запись cas01.domain.local в сертификате.  Соответственно подключение не устанавливается - и нам будут вылазить постоянные запросы пароля.

    В этом случае на CAS-серверах мы можем указать какое имя в сертификате будет использовано для подключения. В этом примере:

    Set-OutlookProvider EXPR -CertPrincilalName "msstd:cas01.domain.local"

    Set-OutlookProvider EXCH -CertPrincilalName "msstd:cas01.domain.local"

    После применения этих команд мы можем увидеть, что Autodiscover отправляет клиенту информацию, что CertPrincilalName должен быть равен "msstd:cas01.domain.local". Windows XP начинает нормально авторизовываться.

    --------------------------------------------------

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


    • Помечено в качестве ответа Anikin Alexander 16 апреля 2015 г. 16:14
    • Изменено Anikin Alexander 16 апреля 2015 г. 16:14
    16 апреля 2015 г. 16:14
  • Добрый день

    Попробуйте добавить политику:

    Group Policy Object (GPO) that's applied to all the computers on your network, navigate to Computer Configuration\Windows\Settings\Security Settings\Local Policies\Security Options, and set the Network security: LAN Manager authentication level выберите Send NTLMv2 response only


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

    • Помечено в качестве ответа Anikin Alexander 16 апреля 2015 г. 16:14
    16 апреля 2015 г. 10:52
    Модератор

Все ответы

  • В интернете находил много ссылок и как решение прописывал

    Set-OutlookProvider EXPR -CertPrincilalName "msstd:cas-array.domain.local"

    Это не помогает. Да и у меня для внешний и внутренних пользователей отключено использование SSL:

    ExternalClientsRequireSsl          : False
    InternalClientsRequireSsl          : False

    (до этого было включено для внешних пользователей - я отключил сегодня)

    Какие могут быть идеи?


    16 апреля 2015 г. 10:13
  • Добрый день

    Попробуйте добавить политику:

    Group Policy Object (GPO) that's applied to all the computers on your network, navigate to Computer Configuration\Windows\Settings\Security Settings\Local Policies\Security Options, and set the Network security: LAN Manager authentication level выберите Send NTLMv2 response only


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

    • Помечено в качестве ответа Anikin Alexander 16 апреля 2015 г. 16:14
    16 апреля 2015 г. 10:52
    Модератор
  • Проблема заключается в том, что система Windows XP, получив задание проверить, что в сертификате сервера есть имя для подключения, не умеет пройти по списку полей SAN дальше чем первая запись, и отыскать нужное имя. 

    1) Необходимо скачать шаблон групповых политик для нужно версии Outlook (в нашем случае это Outlook 2007) https://www.microsoft.com/en-us/download/details.aspx?id=22666 для Outlook 2007

    http://download.microsoft.com/download/D/B/0/DB080999-71D6-4498-AD42-34873F8DD04B/2426686_template.adm для outlook 2010.

    По возможности, я бы советовал использовать версию Outlook 2010 и выше при работе с Exchange 2013.

    2) Далее необходимо создать GPO и повесить его на OU с проблемным компьютером.

    3) Добавить шаблон в GPO.

    В шаблоне выполнить следующие настройки по статье из technet. http://support.microsoft.com/en-us/kb/2426686 (В статье описывается outlook 2010, в 2007 все тоже самое). Не забудьте установить все флаги в параметре RPC/HTTP Connection Flags. 

    Проблема уйдет. 

    16 апреля 2015 г. 11:58
  • Итак - проблему удалось решить двумя способами.

    Первый. Действия с локальной политикой безопасности действительно помогли:

    Computer Configuration\Windows\Settings\Security Settings\Local Policies\Security Options. В параметре Network security: LAN Manager authentication level выбираем Send NTLMv2 response only

    При этом у меня в OA были следующие настройки:

    ExternalClientsRequireSsl          : False
    InternalClientsRequireSsl          : False

    -----------------------------------------------------------

    Второй метод. Как оказалось - достаточно было в OA всего-лишь включить требование SSL для внутренних клиентов. В итоге я включил и для внутренних и для внешних (включаем конечно же на всех CAS-серверах).

    ExternalClientsRequireSsl          : True
    InternalClientsRequireSsl          : True

    Есть замечание - у меня в сертификате на CAS-серверах первым прописано общее имя балансировщика (cas-array.domain.local), а затем уже имена серверов и т.д. И т.к. Windows XP не умеет читать в SAN-записи сертификата дальше первой строчки (об этой проблеме можно прочитать в этой статье) - то в моем случае всё проходит нормально:

    Windows XP пытается подключиться к cas-array.domain.local. Служба autodiscover нам говорит, что для этого подключения CertPrincilalName должен быть равен "msstd:cas-array.domain.local", находит такую запись в первой строке поля SAN сертификата и удачно подключается.

    Если же к примеру в данном случае в поле SAN сертификата первая запись будет не cas-array.domain.local, а cas01.domain.local - то Windows XP уже не сможет подключиться:

    Windows XP пытается подключиться к cas-array.domain.local. Служба autodiscover нам говорит, что для этого подключения CertPrincilalName должен быть равен "msstd:cas-array.domain.local", но находит только запись cas01.domain.local в сертификате.  Соответственно подключение не устанавливается - и нам будут вылазить постоянные запросы пароля.

    В этом случае на CAS-серверах мы можем указать какое имя в сертификате будет использовано для подключения. В этом примере:

    Set-OutlookProvider EXPR -CertPrincilalName "msstd:cas01.domain.local"

    Set-OutlookProvider EXCH -CertPrincilalName "msstd:cas01.domain.local"

    После применения этих команд мы можем увидеть, что Autodiscover отправляет клиенту информацию, что CertPrincilalName должен быть равен "msstd:cas01.domain.local". Windows XP начинает нормально авторизовываться.

    --------------------------------------------------

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


    • Помечено в качестве ответа Anikin Alexander 16 апреля 2015 г. 16:14
    • Изменено Anikin Alexander 16 апреля 2015 г. 16:14
    16 апреля 2015 г. 16:14