Чтобы не засорять излишним цитированием, я буду вырезать содержимое внутри абзацев с цитатами.

> Автоматизации для сервис провайдеров. Корпоративные порталы на 10000+ человек штата. Крупные
> MDM-решения (1С весьма средненький), собственные, например, поверх AXAPTA.

И тут мы вспоминаем, что крупнейшие корпорации не используют AD: Apple, Google, IBM, и т..д

>> Вы это расскажите OVA Exchenge
> MS Exchange это всего-навсего почтовый сервер,... Есть
> продукты в MS, которые ходят в LDAP напрямую, но они обычно
> именно что должны работать с LDAP, тот же RADIUS (NPAS). Есть
> AzureAD Connect называется эта штука.
> И то, она это не требует а предлагает как опцию.

Kerberos в бэкенде тоже LDAP использует, а не из астрала берет данные.
Та же авторизация Kerberos на инсталляции в 10 пользователей, 1000 пользователей и 50000 пользователей требует разное количество времени на одном и то же железе сервера и одной и той же сети. Время пропорционально увеличивается с увеличением количества пользователей. Однако, если у нас в одном OU будут пользователи и компьютеры, то время поиска нужной записи еще возрастет. Да, кэш запросов в kerberos есть, но он при большом количестве активных пользователей быстро затирается новыми данными.

> А теперь давайте подумаем, как Exchange продавать как сервис...
> В итоге должна получиться группа кластеров, каждый из которых находится в демилитаризованной
> зоне, работает со своими контроллерами и не лезет дальше разрешенного.

Это вообще никак не связано с OU. Тоже самое можно и нужно делать, даже нужно делать и в случае использования Lotus, Kerio, Postfix/Exim+Dovecot, Zimbra...

> ...Далее мы заводим новые и новые организации в AD (они
> ложатся в CN=Configuration), а пользовательские учетки мы грузим в OU выделенные
> под каждую организацию в основном каталоге.

Что мешает к Configuration привязывать группы?

> Вот тут-то они и нужны эти OU. Когда есть несколько независимых и
> неуправляемых вами инфраструктур AD, пользователей которых нужно постоянно синхронизировать
> внутрь большого каталога и внутренние права и группы и много чего
> еще.

Синхронизация групп даже здесь будет проходить быстрее.

> AD это не каталог, ADDS - это LDAP+DNS+Kerberos+SMB/DFRS+RPC+SOAP,

LDAP+DNS+Kerberos+SMB работает на всех известных мне живых проектов служб каталогов. В том числе и тех, которые строятся исключительно на базе OpenLDAP+MIT-Kerberos+ISC BIND+ISC DHCP+SAMBA3 (да, все еще Samba3)
DFRS - вещь хорошая, но помимо проблем при потере сетевой связанности между КД и редактированием одних и тех же объектов. (Помнится это было главной причиной для IBM, почему они отказались от AD.) Всегда прикалывало, как для одного и того же пользователя на одной той же машине приезжают различающиеся политики в зависимости от того, как какому КД машина подключилась сейчас. (Одну и ту же политику за пять минут два раза отредактировали, подключаясь к разным серверам, когда синхронизация не сработала из-за загруженности сети.) Нифига в логах не было.

> И еще есть AD CS, но увидеть его в
> крупном развертывании можно только в организации, которая реально требует контроля за
> политиками выдачи сертификатов, смарткартами и сетевыми устройствами ipsec и WPA Enterprise.

CA Service-а нет только у ленивого уже. И у Samba. Хотя та же Samba прекрасно предоставляет возможность для 2ФА, но с внешним CA.
ipsec и WPA Enterprise - и опять это можно сделать во многих службах каталогов.
Все это примеры звучат так: "а у этого производителя авто есть руль".