> Куча крупного софта (Radius, WebAuth в Apache/NGINX и PHP), не работает с OUВо-первых, это не крупный софт. Во вторых мелкий софт с ними не должен работать, они нужны для внедрения ограничений авторизации сверху.
> DDoS на КД можно организовать через Web-приложение, отправив за раз пару тысяч запросов на авторизацию с гарантированно некорректными именами пользователей. В общем трафике Web-сервера такое количество запросов даже заметно не будет.
Вы меня простите за высокомерие, но вы реально не видели ничего крупного. =(
Никто никогда не додумается на крупном развертывании обращаться к LDAP-у напрямую из веб-приложения. То что обычно крутят на Apache/Nginx/PHP для мелкого сайтика - это не то приложение которому требуется каталог, ему и табличка сойдёт.
На больших приложениях правильно делать так:
Каталоги (их обычно несколько и не только AD) и базы используются как хранилища атрибутов. Веб-приложение аутентификации (1) рисует фронтенды по работе с формами, даёт Kerberos и прочий Basic, и даже простой JWT для аутентификации на вебсервисах. Само приложение занимается работой по конвертации между Kerberos Ticket, SAML Assertion, OAuth2 Token и конечно же Cookie для всего этого (дальнейшее объяснение в терминологии OAuth2).
У этого приложения своя база конфигурации, своя база для сессионных данных, ведется учет времени жизни токенов, и работа с токенами обновления. Обычно к такому приложению подключают еще и прокси сервер, тогда оно генерирует разные URN и скоупы для разных локаций подключения, предоставляет возможности предаутентификации и тогда оно ведет учет входов и идентифицируют устройств с которых производился вход, количество попыток последние IP. Такое приложение обычно на предприятии обычно одно. Задача этого приложения прежде всего дать нужные атрибуты из каталога конвертировать их в утверждения (claims) и затем передать их через токен авторизации, заверенный сертификатом пользователю. Далее этот токен может быть предъявлен другому приложению, которому он подходит. Иногда требуется обратная операция: конвертирование JWT или SAML Assertion в сервисный тикет Kerberos, который может быть в последствии предъявлен следующему приложению или даже делегирован на еще один хоп.
Реальное приложение (2) с функционалом подключается именно к приложению аутентификации/авторизации по протоколам типа SAML2 или OAuth2. Оно само ничего не аутентифицирует. Работа с объектами производится на основании того что пришло в токенах и есть доверие между приложением 1 и приложением 2.
Кстати, это все стандартные функции Active Directory, во FreeIPA для этого нужно прикостылять OpenStack Keystone или записаться в некроманты и попытаться оживить мёртвый OpenAM.
Вы сами себе выдумали проблему, подключая приложение к каталогу так, что приложение лезет к парольным атрибутам, вместо того чтобы хотя бы воспользоваться Kerberos-ом не то что чем-то более современным и подходящим для веб-задач. Вообще именно из-за убогости поддержки этого всего и тотальной неграмотности линуксоидов их приложения, если им нужно лезть за пользователями в LDAP напрямую, приходится сажать в гетто (прятать за RODC с ограничением кэшей паролей, делать отдельный LDAP специально для юродивых и пр.) или вовсе переписывать/менять на что-то нормальное, потому что качество этих приложений для конечного энтерпрайза, мягко скажем, посредственное.
Это же хрестоматийная проблема. Вот у нас есть суперсоплекуха, она на линуксе, восславьте нас, вам не надо покупать лицуху на венду. Но нам нужно прицепиться к AD напрямую, прямо к RootDSE, чтобы мы там могли всё делать. А если вам не безопасно и медленно просто перестаньте пользоваться AD есть чудесные LDAP решения для Linux. Причем, бараны искренне удивляются, когда у них спрашивают про SSO, про то как устроена их аутентификация и авторизация. И начинают рассказывать сказки про нужно/не нужно, быстро/медленно.
Дальше кратко пройдёмся по низкому образованию:
Корректное планирование большого AD вы найдете здесь: https://learn.microsoft.com/en-us/windows-server/administrat...
Сравнивать системные требования (память/процы/сторадж) с FreeIPA не имеет смысла, потому что там разный набор сервисов и разная архитектура. Когда я писал, что нужно N для отказоустойчивости FreeIPA, я знаю что пишу. Для маленького AD нужно больше и по другому, потому что там учитывается больше сервисов. Для большого AD там будет выше плотность размещения ввиду того что мультитеннантность достигается средствами OU, а не средствами создания нового экземпляра каталога на каждого клиента. Есть разница между 6-8 физических серверов (12-16 если задействуется Kerberos 5, AES и Compound Kerberos Authentication) под контроллеры и 3000+ виртуалками с FreeIPA (про физическое решение тут можно и не думать). И еще там невообразимый объем педального админства, когда столько инстансов.
> Минимальное количество серверов для AD, гарантирующее сохранность каталога, если между всеми КД нарушится сетевая связанность более чем на 5 минут - 4 штуки.
Правильный ответ 2, если будете восстанавливать вручную и (2 + 1 физический) = 3, если хотите, чтобы оно восстановилось автомагически. Для нагрузки на каталог из приведенного мною примера использовать виртуализацию крайне не выгодно.
> Теперь посчитайте минимальное количество серверов, чтобы поддерживать лес, на распределенную организацию хотя бы на четыре подразделения, в которых есть повторяющиеся группы пользователей (бухгалтерия, кадры и т.д.). 16 штук для гарантированного сохранения базы. Хотя там хватит и четырех.
Вы видимо вообще не понимаете что такое OU. Вы их перепутали с AD Site, потому что именно сайтам нужны другие контроллеры. Это разные вещи. OU - это простой объект каталога, папочка такая со специфичными для нее атрибутами. AD Site - это сущность из области геораспределения, которая тоже имеет свои атрибуты в каталоге, но на самом деле является сущностью Kerberos. Kerberos - это протокол сетевой аутентификации и авторизации он защищает подсеть. Подсеть является частью реалма (в Windows реалм - это "корень леса"). Сайты создаются для того чтобы сделать структуру децентрализированной и построить граф поверх реальной сетевой топологии предприятия. Это с одной стороны оптимизирует процессы репликации, а с другой стороны решает вопрос изоляции периметрических (демилитаризованных зон) и недоверенных сетей бранч-офисов от основной доверенной сети в вопросах аутентификации. OU тут вообще не причем. Вы всё себе перепутали!
> "Чтобы пользоваться OU, нужно сделать кэширующий кластер без OU." facepalm.png.
Добро пожаловать в профессию =)
Каждое высоконагруженное приложение, содержащее функционал полнотекстового поиска должно и обязано кэшировать запросы и ответы. Solr/Lucene хотя бы посмотрите, ну ё моё... Нельзя просто так взять и искать в SQL-базах селектами, нельзя просто так брать и искать в Generic-каталогах фильтрами. Большая часть движков баз вообще не пригодна к полнотекстовому поиску. Серебряной пули не бывает. Вы не сделаете идеальный каталог/базу, которая ищет и работает быстро всегда и для всех задач.
Ну вот есть у вас, например, приложение, которое реализует профили пользователей. Пользователь имеет возможность написать в поле "О себе" текст размеров в несколько мегабайт и у него есть аватар профиля, который тоже весит порядочно. Вы не можете укладывать такие вещи в каталоги и вам нельзя просто так положить такие блобы в базы, если вы собрались что-то искать. Далее расширенные информационные поля профиля пользователя не пойдут в каталог, если используются только в одном приложении, это бессмысленная нагрузка. И вот теперь представьте себе строку поиска по этому по всему. Она работает поверх собственного распределенного кэша, который содержит и данные из каталога, и данные из базы приложения. Такое приложение обычно интегрируется в другие части корпоративных порталов чтобы дать пользователю возможность управлять своим аккаунтам и заполнять некоторые поля в каталоге.
Мне кажется вы с ума сойдете сейчас, но я всё равно скажу: обычный LDAP-клиент на стороне приложения в Linux, реализованный стандартной библиотекой создаёт локальные кэш-базы. Если ваше приложение отказоустойчивой и/или кластеризованное логично было бы этот кэш сделать распределенным в рамках кластера.
И главное, я не понимаю в чем здесь противоречие с OU и как они при этом мешает быстрому поиску. Иерархия OU вам потребуется если у вас есть 1500 организаций из которых 200 имеют кор.порталы в которых есть выделенное приложение по работе с профилями пользователей, которое в свою очередь интегрируется куда-там у них еще. Также OU нужны для синхронизации локального AD-клиента с внешним AD сервисного провайдера.
Вы придумали себе мелкую проблему со скоростью OU, которая находится в пределах погрешности в тех юзкейсах, когда OU реально нужны. В общем я ставлю вам двойку в дневник и в журнал, и вызываю родителей в школу.
