Меня интересует, насколько хорошо Active Directory будет служить серверной частью аутентификации для веб-сайта, рассчитанного на ~ 1 миллион пользователей. Есть ли у вас опыт работы с AD в веб-средах такого масштаба, и если да, то какой уровень оборудования нам понадобится?
[Обновление] Что касается частоты входа в систему: я согласен, что это ключевой фактор, но у нас пока нет такой информации. Предположим, что обычная коммерческая / банковская настройка сайта: войдите в систему через форму один раз, сохраните свою личность в сеансе (т. Е. Никаких аутентификационных вызовов AD на других страницах, кроме страницы входа).
AD не будет хранить значительный объем пользовательской информации, помимо того, что необходимо для аутентификации.
Насколько загружен, по вашему мнению, будет сайт: Предположим, что это обычный коммерческий / банковский сайт. Никакой дополнительной информации по этому поводу.
Будет ли этот AD разделен: Может быть, хотя предпочтительнее простейшая архитектура.
Будет ли этот AD обслуживать что-нибудь еще: Нет.
Насколько сложной будет ваша структура OU
Будете ли вы расширять схему: Будет использована стандартная схема. Структура OU будет довольно простой.
Вы будете выполнять много поисков по нему?: только для поиска имени пользователя / адреса электронной почты для последующей привязки.
Будете ли вы хранить много информации о пользовательских объектах?: Нет
Не могли бы вы? Да. Вы должны? Нет.
Во-первых, масштабирование нагрузки - 1 миллион пользователей со средним числом входов в систему 1 в секунду - это НАМНОГО отличается от 1 миллиона пользователей со средним числом входов в систему 100–1000 в секунду.
Просто некоторые общие мысли по этому поводу - хотя технически это возможно, я не знаю, что Active Directory была бы идеальным средством для хранения 1 млн пользователей в одном домене. Если бы вы использовали это для своего веб-приложения и у вас возникли проблемы с производительностью, было бы довольно сложно устранить неполадки. Лично для чего-то, поддерживающего 1M пользователей, действительно нужно что-то более посвященное этой конкретной задаче.
Если вам нужно пройти этот тест и вы действительно хотите использовать AD, вам, вероятно, нужно привлечь Microsoft, чтобы убедиться, что ваша архитектура абсолютно правильная, и как минимум провести тестирование нагрузки / производительности.
Количество «других вещей», которые Active Directory делает и вводит (уровни, репликация, расширения, проблемы безопасности учетных записей, находящихся в вашем «производственном» сетевом домене), когда вам просто нужно для базы данных аутентификации, IMHO, не подходит для количество пользователей и требуемая относительная простота. Слишком уж непросто и сложно.
Вы жестяная банка используйте для этого AD. Но я бы порекомендовал вам использовать ADAM (или «AD LDS», как он сейчас называется). Это должно дать вам многие из преимуществ AD, то есть уже существующие технические знания и прочее, например FRS для репликации. Если преимущества AD для этого мало в вашем списке «за», то вам действительно стоит рассмотреть другой пакет LDAP, например Siteminder, хотя для этого потребуется собрать больше технических средств, чтобы построить масштабируемую систему.
Самая большая проблема с производительностью, на которую вам нужно будет обратить внимание, - это одновременные запросы на вход, как указывали многие плакаты. Самый простой способ обойти это - создать свои контроллеры домена на 64-битном оборудовании и убедиться, что на вашем контроллере домена достаточно оперативной памяти для хранения всего файла .dit. Это значительно улучшит вашу производительность, так как полностью исключит разбиение на страницы при обработке запросов LDAP. Вы можете использовать 32-битное оборудование, размер вашего файла .dit меньше 1,5 ГБ, но зачем беспокоиться?
Кроме того, если вы ищете какой-то тип высокой доступности, имейте в виду, что репликация и осведомленность о сайте в AD на самом деле не предназначены для обеспечения этого на уровне, который может потребоваться для коммерческого приложения. Вам нужно будет знать об ограничениях нахождения DC и писать свои приложения для использования Windows API для правильной обработки автономных / недоступных DC. Я часто вижу эту проблему, когда разработчик приложения просто указывает свой пакет аутентификации LDAP на fqdn.ad.domain, но этот адрес является простым циклическим перебором и не будет обновляться, если вы отключите DC.
Обычно для пользователей приложений следует использовать AD - LDS (ADAM). Плата за лицензию отсутствует, и пользователи LDS не могут использоваться в качестве учетных данных безопасности для самих серверов. Это хорошая вещь. Если ваш пользовательский каталог скомпрометирован, ваш рабочий каталог все еще работает.
ВЫ ДОЛЖНЫ использовать AD для управления машинами. Убедитесь, что нет локальных учетных записей, используйте групповую политику, чтобы ограничить параметры безопасности. (Думаю, большинство людей будут удивлены, насколько это может быть сложно.)
Это включает:
Правда в том ... если это новая система. СПД было бы отличным местом для размещения ваших пользователей. У него отличная политика паролей, сложность паролей, бла-бла-бла ... Вам действительно стоит обратить внимание на использование SAML или OpenID ... Если у вас есть сочетание пользователей, которые объединяются, и пользователей, которые не поддерживают, вам все равно следует кодировать против требований модель и абстрагировать код конкретного поставщика аутентификации.
Я не хочу развивать это в направлении, которое вы уже рассматривали или отвергали по другим причинам, но что AD даст вам такого, чего не даст RADIUS? Вероятно, вы могли бы легко настроить масштабируемый сервер RADIUS, и я считать Я видел, что некоторые из них будут использовать базу данных, такую как MySQL, в качестве бэкэнда, что позволит вам легко масштабировать ее и реплицировать без дополнительных функций, которые предоставляет вам AD, которые, по вашему мнению, вы не собирались использовать. RADIUS был создан только для задач аутентификации ... но, пожалуйста, не стесняйтесь исправлять меня в комментариях ...
Мы использовали его для пользователей коммутируемого доступа в некоторых компаниях, в которых я работал много месяцев назад, но не пробовали использовать его с веб-аутентификацией.
Это примечание утверждает, что даже старая Windows Server 2000 выполняла 2376 операций поиска полного дерева на основе LDAP в секунду в каталоге с 5 миллионами объектов. И у них было довольно простое оборудование для своих тестов.
В любом случае, я считаю, что AD - лучшее решение для надежной аутентификации, потому что он очень масштабируемый (у вас может быть столько контроллеров домена, сколько вам нужно и где вам нужно), безопасный. Он был разработан для аутентификации и управления учетными записями, и теперь он довольно зрел в своем развитии.
Я точно не знаю о лицензировании, но думаю, вам не нужны клиентские лицензии для пользователей, если вы используете AD только для аутентификации. Но я думаю, вам нужно запросить MSFS для вашего конкретного сценария.
Количество пользователей не имеет значения по сравнению с количеством пользователей, которых вы будете обслуживать одновременно. Если у вас был миллион пользователей, но вы входили в систему только один раз в день, вам не понадобится много оборудования. Это также зависит от того, как вы выполняете аутентификацию. Если вы используете HTTP-аутентификацию, вам, вероятно, придется выполнять поиск при каждом запросе. Однако, если вы используете HTML-форму, вы можете выполнять поиск по запросу на вход и возвращать cookie для следующих запросов, что означает, что вы выполняете гораздо меньше проверок аутентификации.
Вы бы хотели посмотреть, насколько хорошо масштабируется AD; сколько серверов у вас может быть, обслуживающих запросы, прежде чем репликация станет проблемой, либо с обслуживанием, либо с уменьшающейся отдачей при добавлении новых.
Кроме того, можете ли вы добавить кеширование, чтобы ускорить поиск. Это было бы гораздо важнее для настройки HTTP-аутентификации.
Не забудьте про лицензирование. Вы должны получить Внешний соединитель Windows Server, поскольку 1 млн клиентских лицензий будет очень дорогостоящим.
Леди по лицензированию Microsoft помогает объяснить что такое внешний пользователь.
В вашем вопросе отсутствует много деталей:
Нам реально необходимо много информации, прежде чем мы сможем судить о требованиях к оборудованию.
Я не знаю, была ли статья о Масштабирование Active Directory с помощью Commerce Server содержит общие подсказки и подсказки по масштабированию AD. Может стоит бегло просмотреть?
Если это чисто для аутентификации внешних пользователей - зачем вообще возиться с AD?
Судя по вашим изменениям в вопросе, AD должна работать нормально. Возможно, вы захотите использовать небольшие подсети, чтобы вы могли разделить группы веб-серверов и контроллеров домена на сайты, чтобы случайно не поменять местами один сервер со всеми вашими аутентификациями.
С другой стороны, вы оставляете много функций на столе, как говорили другие, и поэтому вам может быть лучше с аутентификацией на основе форм, возвращающейся к БД. Я считаю, что стек MSFT имеет довольно богатые элементы управления для этого.
Излишний, но просто работает, а не в самый раз? Непростой вопрос.