Windows xp exchange 2013 запрос пароля
Вопрос
Добрый день. Перевожу потихоньку организацию на 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 :
SSLOffloading : True
ExternalClientsRequireSsl : False
InternalClientsRequireSsl : False
Во внутренней сети DNS-записи cas-array.domain.local и mail.contoso.com — обе ссылаются на ip-адрес NLB-кластера.
Извне — mail.contoso.com — это адрес обратного прокси.
Ответы
Итак — проблему удалось решить двумя способами.
Первый. Действия с локальной политикой безопасности действительно помогли:
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-подключение) мне больше нравится второй вариант. Т.к. не надо городить групповые политики и всё отлично работает.
Windows xp exchange 2013 запрос пароля
Вопрос
Добрый день. Перевожу потихоньку организацию на 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 :
SSLOffloading : True
ExternalClientsRequireSsl : False
InternalClientsRequireSsl : False
Во внутренней сети DNS-записи cas-array.domain.local и mail.contoso.com — обе ссылаются на ip-адрес NLB-кластера.
Извне — mail.contoso.com — это адрес обратного прокси.
Ответы
Итак — проблему удалось решить двумя способами.
Первый. Действия с локальной политикой безопасности действительно помогли:
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-подключение) мне больше нравится второй вариант. Т.к. не надо городить групповые политики и всё отлично работает.
Windows xp exchange 2013 запрос пароля
Вопрос
Добрый день. Перевожу потихоньку организацию на 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 :
SSLOffloading : True
ExternalClientsRequireSsl : False
InternalClientsRequireSsl : False
Во внутренней сети DNS-записи cas-array.domain.local и mail.contoso.com — обе ссылаются на ip-адрес NLB-кластера.
Извне — mail.contoso.com — это адрес обратного прокси.
Ответы
Итак — проблему удалось решить двумя способами.
Первый. Действия с локальной политикой безопасности действительно помогли:
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-подключение) мне больше нравится второй вариант. Т.к. не надо городить групповые политики и всё отлично работает.