Проблема подтверждена.

Причина в поведении мастера настройки учетных записей (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  выступать.