В 157.0.1-alt1 нет возможности выбора NTLM при автоматической настройке, доступна аутентификация только с обычным паролем при этом изменение конфигурации недоступно, но на главной странице после указания электронного адреса при настройке вручную оба варианта доступны. С exchange 2013 CU 23 папки уже подключаются нормально, осталось дождаться синхронизации календаря и адресной книги.
Проблема подтверждена. Причина в поведении мастера настройки учетных записей (Account Hub) в Thunderbird: 1. При автоматическом обнаружении параметров через AutoDiscover (ExchangeAutoDiscover.sys.mjs) метод аутентификации жестко выставляется как «Обычный пароль» (passwordCleartext), а альтернативные методы (NTLM, OAuth2) помещаются в authAlternatives. 2. На экране подтверждения найденной конфигурации (шаг emailConfigFound) выбор метода аутентификации не предоставляется, а кнопка «Изменить конфигурацию» (Edit configuration) для нативного EWS в Account Hub заблокирована/скрыта из-за ограничений в апстриме (Bugzilla Mozilla #1959752, #2005166). В ручном режиме (Configure manually) селектор аутентификации для EWS доступен и содержит NTLM (Bugzilla Mozilla #1998428), поэтому подключение проходит успешно. Временное решение (workaround): При добавлении учетной записи на первом шаге сразу нажимать «Настроить вручную», выбирать тип учетной записи Exchange / EWS и явно указывать метод аутентификации NTLM. Связанные баги в апстриме (bugzilla.mozilla.org): - Bug 1959752: Account Hub Edit Configuration should be there for add-on Exchange config, not EWS - Bug 2005166: Oauth not selected in Account Hub Edit Configuration for EWS/Exchange option - Bug 2018729: AccountHub Exchange available auth methods incorrect - Bug 1998428: Expose NTLM as an authentication method for EWS
Мурат, спасибо большое за обращение! Уже исправлено апстримом: https://bugzilla.mozilla.org/show_bug.cgi?id=2075408, войдёт в 159. По идее firefox 159 выходит сегодня, thunderbird 159 на этой неделе. Потом ещё надо будет подождать, пока пройдёт в p11 - это, примерно, ещё неделя.
Вам спасибо за оперативную реакцию! Айрат, а есть информация по адресной книге и календарю, пока хотя бы по адресной книге?
Календарь и адресная книга Exchange - это уже не исправление ошибки, а новая функциональность: сейчас Thunderbird по EWS их не поддерживает. Технически мы можем её реализовать и предложить в апстрим, но решение о добавлении новой функциональности принимает продуктовая дирекция. Поэтому просьба завести отдельный баг с запросом на эту функциональность, а ещё лучше - обратиться с этим запросом в техподдержку. Пока для адресной книги есть обходной путь: каталог LDAP к контроллеру домена AD (Адресная книга -> Создать -> Добавить каталог LDAP, сервер - ваш DC, Base DN - корень домена). Будет работать поиск по общему списку адресов при наборе адресата.
Мы и так сейчас используем LDAP? просто хотелось уже полностью весь возможный функционал. Кстати надо перепроверить работу LDAP по А записи, а не по CNAME, так хоть балансировка какая-то будет. Как лучше сделать по адресной книге и календарю, завести багом или запрос в техническую поддержку?
Лучше через техническую поддержку: так запрос попадёт в продуктовую дирекцию, которая решает, брать ли новую функциональность в работу. Если при подключении LDAP по A-записи что-то будет работать не так, заведите, пожалуйста, отдельный баг.
LDAP мы не хотим использовать учетные данные, что лишний раз не менять и там пароли (смена паролей каждые 3 месяца, политика компании), а хотим использовать kerberos, а ему скорее все FQND наверное нужно, поэтому не совсем уверен, может он с A записью работать. Кстати перепроверил, не работает с A записью.
Причина в том, как работает Kerberos. Билет Kerberos выдаётся на имя конкретного сервера, указанного в настройках Thunderbird. CNAME раскрывается до настоящего имени контроллера домена, и на него билет выдаётся. Имя по A-записи остаётся как есть, контроллер домена такого имени не знает, билет не выдаёт, и вход не проходит. Воспроизвёл это на тестовом стенде. Поэтому балансировка через A-запись с Kerberos не получится: билет выписан на один конкретный контроллер, другой его не примет. Надёжный вариант - указать в настройках LDAP полное имя (FQDN) конкретного контроллера домена. С CNAME у вас сейчас фактически так и работает. Если хотите проверить у себя: закройте Thunderbird полностью, запустите KRB5_TRACE=/tmp/krb5.log thunderbird выполните поиск в адресной книге и посмотрите /tmp/krb5.log - там видно, на какое имя запрашивается билет и что ответил контроллер домена. По календарю и адресной книге Exchange: в планах Thunderbird они есть (https://roadmaps.thunderbird.net/en-US/desktop/), но пока разработка календаря идёт только для Microsoft 365 (Graph), а для EWS и адресной книги работ ещё не видно.
В этом плане CNAME дает немного большую гибкость, чем указывать в настройках LDAP полное имя (FQDN) в случае выхода из сторя указанного DC, можно оперативно в DNS оперативно сменить на другой DC, это проще чем менять на всех хостах имя (FQDN) в настройках LDAP, до восстановления из бэкапа. Через GPO не смог найти настройки LDAP для thunderbird. А адресная книга ews (OAB) тоже могла бы вроде балансира выступать для кластера серверов exchange выступать.
