Ошибки 0x80042013 и Can't contact LDAP server в Kerio Connect
После перезагрузки почтового сервера, служба Kerio Connect категорически отказывалась подниматься. Точней не так, она стартовала, но почта отправляться категорически не хотела. В логах красовалась ошибка «Can't contact LDAP server», намекающая на проблемы с установкой соединения с LDAP сервером (в моем случае с AD).
Первым делом решил проверить учетную запись, посредством которой происходит взаимодействия с AD. В разделе «Домены» выбираю свой домен, захожу на вкладку «Служба каталога» и вижу, что все вроде хорошо. На всякий случай нажимаю кнопку тестирования соединения и в очередной раз убеждаюсь, что все работает правильно.
Я попробовал перебрать все настройки, создал даже дополнительную учетную запись с правами на возможность чтения схемы домена, но толку никакого. Соединение с каталогом (при нажатии на кнопку тестирования) устанавливалось, но логи продолжало засыпать ошибкой Can’t contact LDAP server в Kerio Connect.
Обильное «гугление» результата не принесло. На официальном форуме находились топики с подобными проблемами, но все они были без конкретных решений. Пришлось запастись кофе и начать раскопки.
Для начала, я создал отдельную учетную запись в AD для почтовика. Раньше обращение к AD выполнялось под учетной записью одного из администраторов домена. Мне такой вариант никогда не нравился, т.к. стоит сменить пароль админу, как начинается хаос. Сервисов, работающих с AD, в компании может быть много, поэтому всегда есть шанс забыть обновить пароль на одном из них.
Я не считаю себя админом-профи, т.к. 95% моего рабочего времени уходит на разработку ПО, но считаю достаточно логичным для сервисов создавать отдельные учетные записи. Видишь в AD пользователя “kerio-mail” и сразу понимаешь, что если изменить ему пароль, то придется обновить настройки в почтовике.
Итак, создал нового пользователя, внес необходимые настройки. В логах ситуациях не изменилась. Ok, торможу службу kerio и пробую в консоле вбить команду ipconfig /flushdns для выполнения очистки кэша DNS.
Повторно запускаю службу kerio connect и смотрю в логи. Что ж, не повезло, ошибка не исчезла. В голову приходит мысль отключить использование LDAP. Отключаю, создаю пользователю, который был импортирован из AD пароль (средствами Kerio Connect) и все чудесным образом заработало (еще бы).
Теперь самое интересное, торможу службу Kerio. Перезагружаю сервер, опять захожу в настройки и включаю использование службы каталога. Ввожу данные того же самого пользователя, делаю тест соединения (опять никаких проблем) и логи остаются чистыми. Никаких намеков на ошибку Cant’t contact LDAP. Возвращаю пользователю аутентификацию по LDAP, и все магическим образом начинает работать.
Истинная причина возникшей проблемы мне непонятна до сих пор. На сервере AD ничего не менялось, на почтовике тоже. Тупая перезагрузка сервера не могла решить проблему, а помогло только полное удаление настроек соединения с LDAP и повторный их ввод. Подозреваю, что проблема кроется где-то под капотом Kerio Connect, но об этом узнать уже не получится.
Ошибка 0x80042013 в Kerio Outlook Connector
Не успев вдоволь нарадоваться решению проблемы, как пришла новая беда. На рабочих станциях многих пользователей MS Outlook никак не хотел соединяться с почтовым сервером Kerio Connect. Администраторы Kerio Connect знают, что для комфортной работы MS Outlook c почтовым сервером требуется установить специальный коннектор (Kerio Outlook Connector). Как показывает практика, это ПО далеко от идеала. В случае возникновения ошибок, можно сломать голову в поисках решения.
Вот взять мою ситуацию. Захожу в настройки соединения, и пробую нажать кнопку «обнаружить». Сразу возникает окно с ошибкой без какого-либо внятного текста. Указан просто хексовый номер 0x80042013 и фиг знает в какую сторону двигаться в поисках решения. Опять-таки, Google находит подобные проблемы, но как всегда без конкретных решений.
Мне повезло, что данная проблема проявлялась только у некоторых пользователей. Решил сравнить их настройки. Оказалось, у некоторых пользователей на вкладке «Сведения о сервере» не установлен флаг «Применять защищенное соединение (SSL)». Именно у этих пользователей почта и не хотела работать. Ставлю один единственный флажок, и все магическим образом возвращается в строй.
Детали ошибки 0x80042013
Решение проблемы я нашел, но мне заинтересовала природа столь странного поведения. Ведь как-то же все эти пользователи раньше работали с почтой без SSL! Возвращаюсь на сервер с Kerio Connect и внимательно осматриваю панель управления. Ответ на мой вопрос крылся в разделе «Службы». По каким-то странным причинам, служба HTTP не хотела стартовать на 80 порту (порт, кстати, был не занят).
Вот именно из-за этого клиенты с некоторых рабочих станций и не могли установить соединение.
Не все в курсе как работает Kerio Outlook Connector. Для работы ему необходима возможность установки соединения со службой HTTP/HTTPS, которую поднимает служба Kerio Connect. Не зная про этот маленький нюанс (а я не знал, т.к. администрированием этой штуки не занимался), можно долго танцевать с бубном, матеря разработчиков Kerio за магическую ошибку 0x80042013.
Запоминаем, если Kerio Outlook Connector сыпет непонятными ошибками, то действуем по следующему сценарию:
