none
Exchange 2013 Outlook Anywhere ошибка аутентификации EventID 4624 Неизвестное имя RRS feed

  • Вопрос

  • Добрый день.

    Инфраструктура:

    2 сервера Exchange 2013 CU10 (CAS+MBX).

    Балансировщик CitrixNescaller балансирующие подключения клиентов между серверами.

    Настройки Outlook Anywhere: внешние и внутренние имена различаются, аутентификация внутренняя NTLM, внешняя Negotiate.

    Как правило клиенты при запуске Outlook авторизуются штатно с сообщением в журнале безопасности:

    An account was successfully logged on.
    
    Subject:
    	Security ID:		NULL SID
    	Account Name:		-
    	Account Domain:		-
    	Logon ID:		0x0
    
    Logon Type:			3
    
    Impersonation Level:		Impersonation
    
    New Logon:
    	Security ID:		DOMAIN\TestUser13
    	Account Name:		TestUser13
    	Account Domain:		DOMAIN
    	Logon ID:		0x60ADD03
    	Logon GUID:		{00000000-0000-0000-0000-000000000000}
    
    Process Information:
    	Process ID:		0x0
    	Process Name:		-
    
    Network Information:
    	Workstation Name:	USERWORKSTATION
    	Source Network Address:	CITRIXNETSCALLER_IP
    	Source Port:		27771
    
    Detailed Authentication Information:
    	Logon Process:		NtLmSsp 
    	Authentication Package:	NTLM
    	Transited Services:	-
    	Package Name (NTLM only):	NTLM V2
    	Key Length:		0

    Но иногда авторизация фелится с сообщением:

    An account failed to log on.
    
    Subject:
    	Security ID:		SYSTEM
    	Account Name:		EXCHANGESERVER$
    	Account Domain:		DOMAIN
    	Logon ID:		0x3E7
    
    Logon Type:			8
    
    Account For Which Logon Failed:
    	Security ID:		NULL SID
    	Account Name:		TestUser13@smtpdomain
    	Account Domain:		EXCHANGESERVER
    
    Failure Information:
    	Failure Reason:		Unknown user name or bad password.
    	Status:			0xC000006D
    	Sub Status:		0xC0000064
    
    Process Information:
    	Caller Process ID:	0x12a4
    	Caller Process Name:	C:\Windows\System32\inetsrv\w3wp.exe
    
    Network Information:
    	Workstation Name:	EXCHANGESERVER
    	Source Network Address:	CITRIXNETSCALLER_IP
    	Source Port:		24032
    
    Detailed Authentication Information:
    	Logon Process:		Advapi  
    	Authentication Package:	Negotiate
    	Transited Services:	-
    	Package Name (NTLM only):	-
    	Key Length:		0
    

    При этом вылезает запрос учетных данных для пользователя. 

    Наблюдается на разных клиентах (Outlook 2010,2013,2016) разных ОС(winXP/7/8)

    Subcode 0xC0000064 означает, что неверное имя пользователя. Действительно вместо имени пользователя указывается его адрес эл. почты.

    Пробовал решение из ttps://support.microsoft.com/ru-ru/kb/896861, но не сработало.

    Есть какие-то мысли о том, почему ряд запросов авторизации приходит с именем сервера в качестве рабочей станции и email вместо адреса эл почты.

Ответы

  • Поставить на клиента фидлер и посмотреть какие запросы\ответы у HTTPS сессии.
  • Поставить на клиента фидлер и посмотреть какие запросы\ответы у HTTPS сессии.

    С помощью фидлера выяснил.

    На площадке присутствует третий сервер Server3 (MBX+CAS).
    Он не содержит и никогда не содержал почтовых ящиков, не включен в балансировку балансировщиком, для него SiteAffinity для автодискавера установлен в $null, чтобы клиенты на него случайно не зашли, получая url автодискавера через SCP в АД.

    Ожидаемое поведение автодискавера:

    1) Служба автообнаружения на сервере получает запрос от клиентского приложения (Outlook) с email-адресом клиента и его учетными данными
    2) Служба уточняет с помощью AD в какой базе данных на каком сервере находится почтовый ящик клиента и находит его на серверах Server1,Server2
    3) Служба получает настройки клиентского доступа (URL'ы служб, параметры аутентификации и т.п.) с сервера, полученного в шаге 2.

    4) Служба создает ответ на запрос на основе данных, полученных в шаге 3 и отправляет его клиенту.

    По факту выяснилось, что служба автодискавера на каждый 3-4 запрос возвращала настройки не с того сервера, где в данный момент активен ящик пользователя, а с сервера Server3, где для OutlookAnywhere была выставлена аутентификация Basic. Что вызывало запрос учетных данных для пользователей клиентским приложением.

    Установили на сервере Server3 настройки Outlook Anywhere такие же, как на Server1,Server2 проблема воспроизводиться перестала.

    Exchange в данном случае с CU10, возможно в более поздних обновлениях проблема исправлена.

Все ответы

  • Поставить на клиента фидлер и посмотреть какие запросы\ответы у HTTPS сессии.
  • Посмотри, что на Exchange создан loopback network adapter.

    Он нужен чтобы Netscaler не использовался, как шлюз.

    http://citrix.stefanriek.de/citrix/howto-load-balance-while-preserving-a-clients-source-ip-but-not-using-the-netscaler-as-your-gateway/

    https://benddiscount.com/2015/01/15/exchange-2010-load-balancing-with-netscaler-10-1/


    scientia potentia est
    My blog

  • Хорошая идея, потребуется сертификат с ключем, установленный на экчендж сервере, чтобы влезть внутрь https сессии. Не уверен, что мне его дадут, но попробую.
  • Не потребуется, вы влезе в ту сессию, котороая открыта у вашего клиента, который уже устанавливает защищенное соединение с сервером. 
  • Поставить на клиента фидлер и посмотреть какие запросы\ответы у HTTPS сессии.

    С помощью фидлера выяснил.

    На площадке присутствует третий сервер Server3 (MBX+CAS).
    Он не содержит и никогда не содержал почтовых ящиков, не включен в балансировку балансировщиком, для него SiteAffinity для автодискавера установлен в $null, чтобы клиенты на него случайно не зашли, получая url автодискавера через SCP в АД.

    Ожидаемое поведение автодискавера:

    1) Служба автообнаружения на сервере получает запрос от клиентского приложения (Outlook) с email-адресом клиента и его учетными данными
    2) Служба уточняет с помощью AD в какой базе данных на каком сервере находится почтовый ящик клиента и находит его на серверах Server1,Server2
    3) Служба получает настройки клиентского доступа (URL'ы служб, параметры аутентификации и т.п.) с сервера, полученного в шаге 2.

    4) Служба создает ответ на запрос на основе данных, полученных в шаге 3 и отправляет его клиенту.

    По факту выяснилось, что служба автодискавера на каждый 3-4 запрос возвращала настройки не с того сервера, где в данный момент активен ящик пользователя, а с сервера Server3, где для OutlookAnywhere была выставлена аутентификация Basic. Что вызывало запрос учетных данных для пользователей клиентским приложением.

    Установили на сервере Server3 настройки Outlook Anywhere такие же, как на Server1,Server2 проблема воспроизводиться перестала.

    Exchange в данном случае с CU10, возможно в более поздних обновлениях проблема исправлена.

  • к слову Outlook так и не воспринял фидлеровский сертификат и при активной дешифрации https так и не удалось Outlook'у подключиться к каталогу /rpc.

    У нас в настройках Outlook провайдеров выставлено имя сертификата, чтобы клиенты на XP работали. Так у фидлеровского сертификата имя в сертификате отличается, из-за этого оутлук так и не устанавливал соединение при фидлере.

    Но это детали.