Active Directory для веб-аутентификации: масштабируется до 1 млн пользователей?

Как правило, вы должны использовать AD - LDS (ADAM) для пользователей приложения. Лицензионный сбор не взимается, и пользователи в LDS не могут использоваться в качестве учетных данных безопасности для самих серверов. Это хорошая вещь. Если ваш пользовательский каталог скомпрометирован, то ваш рабочий каталог все еще функционирует.

ВЫ ДОЛЖНЫ использовать AD для управления машинами. Убедитесь, что нет локальных учетных записей, используйте групповую политику, чтобы ограничить параметры безопасности. (Я думаю, что большинство людей будут удивлены, насколько это может быть сжато.)

Они включают:

• Использование IPSEC, чтобы убедиться, что NTLM всегда проходит с дополнительным шифрованием.
• Отключение кэшированных учетных данных.
• Обеспечить более надежное шифрование алгоритмов на Kerberos.
• Белый список приложений, которые запускаются на серверах с политиками Applocker/Software Restriction, если необходимо использовать полную установку. Попробуйте использовать ядро ​​сервера. (По крайней мере, попробуй... это все, что я говорю.)

Правда в том... если это новая система. LDS будет отличным местом для размещения ваших пользователей. У него отличная политика паролей, сложность паролей, бла-бла-бла... Вы действительно должны обратить внимание на использование SAML или OpenID... Если у вас есть смесь пользователей, которые объединяются в федерацию, и пользователей, которые этого не делают, вы все равно должны кодировать против требований модель и абстрагирование конкретного кода поставщика аутентификации.

Вы можете использовать AD для этого. Но я бы порекомендовал вам пойти с ADAM (или "AD LDS", он называется сейчас). Он должен дать вам много преимуществ AD, то есть уже существующие технические знания и такие вещи, как FRS для репликации. Если преимущества AD для этого незначительны в вашем списке "плюсов", то вам действительно следует рассмотреть другой пакет LDAP, например Siteminder, хотя для создания масштабируемой системы для этого потребуется собрать больше технологий.

Как указывалось многими авторами, самая большая проблема с производительностью, на которую вам нужно обратить внимание - это параллельные запросы входа в систему. Самый простой способ обойти это - построить свои контроллеры домена на 64-битном оборудовании и убедиться, что на вашем контроллере достаточно оперативной памяти для хранения всего файла.dit. Это значительно повысит вашу производительность, поскольку полностью исключит подкачку при обработке запросов LDAP. Вы можете использовать 32-битное оборудование с размером файла.dit менее 1,5 ГБ, но зачем?

Кроме того, если вы ищете какой-либо тип высокой доступности, имейте в виду, что репликация и осведомленность о сайтах в AD на самом деле не предназначены для обеспечения этого на уровне, который вам может понадобиться для коммерческого приложения. Вам нужно будет знать об ограничениях определения местоположения контроллера домена и писать свои приложения для использования Windows API для правильной обработки автономных / недоступных контроллеров домена. Я часто вижу эту проблему, когда разработчик приложения просто указывает свой пакет аутентификации LDAP на fqdn.ad.domain, но этот адрес - просто циклический перебор, и он не будет обновляться, если вы переведите DC в автономный режим.

Я не хочу принимать это в направлении, которое вы уже рассматривали или отклонили по другим причинам, но что даст вам AD, а что-то вроде RADIUS - нет? Вероятно, вы могли бы легко настроить масштабируемый RADIUS-сервер, и я думаю, что я видел некоторые, которые будут использовать базу данных, такую ​​как MySQL, для бэкэнда, что позволит вам легко масштабировать ее и реплицировать без дополнительных функций, которые AD даст вам, как вы озвучили как ты не собирался использовать. RADIUS был отчасти создан только для задач аутентификации... но, пожалуйста, не стесняйтесь исправлять меня в комментариях...

Мы использовали его для пользователей коммутируемого доступа в некоторых компаниях, которые я работал много месяцев назад, не пробовал это с веб-аутентификацией.

В этой заметке утверждается, что даже старая Windows Server 2000 выполняла 2 376 операций поиска по полному дереву на основе LDAP в секунду в каталоге с 5 миллионами объектов. И у них было довольно простое оборудование для их тестов.

В любом случае, я думаю, что AD - это лучшее решение для надежной аутентификации, потому что она очень масштабируема (вы можете иметь контроллеры домена столько, сколько вам нужно и где вам нужно), безопасна. Он был разработан для аутентификации и управления учетными записями, и теперь он достаточно зрел в своем развитии.

Я точно не знаю о лицензировании, но думаю, что вам не нужны клиентские лицензии для пользователей, если вы используете AD только для аутентификации. Но я думаю, что вам нужно запросить MSFS для вашего конкретного сценария.

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

С другой стороны, вы оставляете много функциональности на столе, как говорили другие, и поэтому вам может быть лучше, если аутентификация на основе форм вернется к БД. Я полагаю, что стек MSFT обладает довольно широкими возможностями для управления именно этим.

Overkill, но Just Works, против Just Right? Никогда простой вопрос.

В вашем вопросе не хватает деталей:

1. Насколько вы ожидаете, что веб-сайт будет
2. Будет ли эта реклама разделена
3. Будет ли это объявление служить что-нибудь еще
4. Насколько сложной будет ваша структура OU
5. Будете ли вы выполнять много поисков на нем
6. Будете ли вы расширять схему
7. Будете ли вы хранить много информации о пользовательских объектах
8. Будет ли обменяться с этим AD

Много информации, в которой мы реально нуждаемся, прежде чем мы сможем принять решение о требованиях к оборудованию.

Я не знаю, содержит ли статья о масштабировании Active Directory с Commerce Server какие-либо общие советы и рекомендации по масштабированию AD. Это может стоить быстрого просмотра?

Если это чисто для аутентификации внешних пользователей - зачем вообще беспокоиться об AD?

Не забывайте лицензирование. Вы должны получить внешний соединитель Windows Server, так как 1М клиентские лицензии будут очень дорогостоящими.

Licensing Lady от Microsoft помогает объяснить, что такое внешний пользователь.

Количество пользователей не имеет значения по сравнению с количеством пользователей, которых вы будете обслуживать одновременно. Если у вас было миллион пользователей, но у вас был только один логин в день, вам не нужно много оборудования. Это также зависит от того, как вы делаете аутентификацию. Если вы используете HTTP-аутентификацию, вам, вероятно, придется искать каждый запрос. Однако, если вы используете HTML-форму, вы можете выполнить поиск по запросу на вход в систему и вернуть cookie для следующих запросов, что означает, что вы делаете гораздо меньше проверок подлинности.

Вы хотели бы посмотреть, насколько хорошо AD масштабируется; сколько серверов может обслуживать запросы до того, как репликация станет проблемой, или поддержка, или получение убывающих возвратов, добавляя больше.

Кроме того, вы можете добавить кеширование для ускорения поиска. Это было бы гораздо важнее для настройки аутентификации HTTP.