我对活动目录作为一个网站的authentication后端有多好感，对于大约一百万用户的规模。 你有在这个规模的networking环境中使用AD的经验吗？如果有的话，我们需要什么水平的硬件？
[更新]关于login频率：我同意这是一个关键因素，但我们还没有这些信息。 假设一个常规的商业/银行网站设置：通过表单login一次，在一个会话中携带你的身份（即没有login页面以外的页面上的ADauthentication调用）。
AD将不会存储超过authentication所需的大量用户信息。
你期望网站有多忙 ：假设一个正常的商业/银行网站。 没有进一步的信息。
本AD是否会被分割 ：虽然最简单的架构是可取的。
本指令是否会服务于其他任何人 ：否。
你的OU结构有多复杂
你会扩展模式：将使用标准模式。 OU结构将相当简单。
你会在其上执行许多search ：只查找用户名/电子邮件的后续绑定。
你会存储大量的信息对用户对象 ：没有
你可以吗？ 是。 你应该？ 没有。
首先，缩放负载 – 平均每秒1次login的1M用户是一个不同于1M用户的平均每秒100-1000次login的LOT。
只是一些一般的想法虽然 – 虽然技术上可以，但我不知道活动目录将是理想的工具，1M的用户全部存储在一个域。 如果您将其用于Web应用程序并开始出现性能问题，那么排除故障将非常困难。 就个人而言，对于支持1M用户的东西，它确实需要更专注于该特定任务。
如果这是您需要达到的基准，并且您确实想要使用AD，那么您可能需要让Microsoft参与，以确保您的架构是绝对正确的，并且至less能够对您的负载/性能进行testing。
当你只需要一个authentication数据库时，Active Directory所做和引入的“其他事物”的数量（层，复制，扩展，帐户在你的“生产”networking域上的安全问题）是恕我直言，不适合用户的数量和相对简单的要求。 太过于矫枉过正。
你可以使用AD来做到这一点。 但我会build议你去与ADAM（或现在称为“AD LDS”）。 它应该给你许多AD的好处，即预先存在的技术知识和像复制FRS的东西。 如果AD在这个“专业”列表中的优势很低，那么你应该考虑一个不同的LDAP软件包，比如Siteminder，尽pipe这需要将更多的技术集成在一起来构build一个可扩展的系统。
许多海报指出，你需要看的最大的性能问题是并发login请求。 最简单的方法是在64位硬件上构buildDC，并确保DC有足够的RAM来存储整个.dit文件。 这将显着改善您的性能，因为它将完全消除处理LDAP查询时的分页。 你可以用你的.dit文件的32位硬件小于1.5GB，但为什么要麻烦？
另外，如果您正在寻找某种types的高可用性，请注意，AD中的复制和站点感知function并非真正为在商业应用程序上可能需要的级别提供此function。 您需要了解定位DC的限制，并编写应用程序以使用Windows API正确处理脱机/不可用的DC。 我看到这个问题很多，一个应用程序开发者只需要在fqdn.ad.domain上指向他们的LDAPauthentication包，但是这个地址我只是一个简单的循环，如果你离线一个DC，这个地址不会被更新。
一般来说，您应该为应用程序用户使用AD-LDS（ADAM）。 没有许可证费用，LDS中的用户不能用作服务器本身的安全凭证。 这是一件好事。 如果您的用户目录被盗用，那么您的操作目录仍然有效。
你应该使用AD来pipe理机器。 确保没有本地帐户，使用组策略来限制安全设置。 （我想大多数人会感到惊讶，这可能是多么紧张。）
这些包括：
真相是…如果这是一个新的系统。 LDS将是放置用户的好地方。 它有很好的密码政策，密码的复杂性，等等等等等等…你应该真的在使用SAML或OpenID …如果你有一个联合用户组合和用户，你不应该仍然编码索赔模型并抽象出authentication提供者的具体代码。
我不想把这个方向带到你已经考虑或者由于其他原因而被拒绝的方向，但是AD会给你什么，像RADIUS这样的东西不会呢？ 你可能很容易设置一个可扩展的RADIUS服务器，我想我已经看到一些将使用像MySQL的数据库作为后端，使您可以轻松地扩展和复制它没有添加的function，广告会给你，你听起来就像你不打算使用的一样。 RADIUS只是用于身份validation任务而已…但请随时纠正我的意见…
我们曾经在一些在许多月前工作过的企业用拨号用户使用它，但没有用Webauthentication来尝试它。
本文声称，即使是旧的Windows Server 2000，也是在500万个对象目录上每秒执行2,376次基于LDAP的全树search。 他们的testing硬件非常简单。
无论如何，我认为AD是可靠身份validation的最佳解决scheme，因为它具有很高的可扩展性（您可以根据自己的需要和需要的地方安装域控制器）。 它是为authentication和账户pipe理而devise的，现在已经相当成熟。
我不知道有关授权的问题，但是我认为如果您仅使用AD进行身份validation，则不需要为用户提供CAL。 但我认为你需要查询你的具体情况的MSFS。
与同时使用的用户数量相比，用户数量相当无关紧要。 如果你有一百万用户，但你每天只有一次login，你不会需要很多硬件。 这也取决于你如何做authentication。 如果您使用HTTP身份validation，则可能需要查找每个请求。 但是，如果您使用HTML表单，则可以对login请求执行查找，并返回以下请求的cookie，这意味着您可以执行更less的身份validation查找。
你会想看看AD如何扩展; 在复制成为问题之前，有多less服务器可以提供服务请求，要么维护，要么产生增加的更多回报。
另外，你可以添加caching来加快你的查找。 这对HTTPauthentication设置来说更重要。
不要忘记授权。 您应该获得一个Windows Server外部连接器 ，因为1M CAL将会非常昂贵。
微软的Licensing Lady可以帮助解释外部用户是什么 。
你的问题有很多细节缺失：
在我们可以根据硬件要求做出判断之前，我们需要大量的信息。
我不知道是否与商业服务器缩放活动目录中的文章包含任何通用的AD缩放提示和技巧。 这可能是值得快速浏览？
如果这纯粹是为了validation外部用户 – 为什么即使打扰广告？
基于你对这个问题的编辑，AD应该工作得很好。 您可能需要使用小型子网，以便将networking服务器和数据中心组分配到站点中，这样您就不会意外地将单个服务器与所有身份validation交换。
另一方面，正如其他人所说，你在桌面上留下了很多function，所以你可能会更好地使用基于表单的身份validation返回到数据库。 我相信MSFT堆栈具有相当丰富的控制function。
矫枉过正，只是工作，而不是恰到好处？ 从来没有一个简单的问