如何在“托管解决方案”中使用 Active Directory？
昨天，我接到 Microsoft 代表的电话，询问我们是否提供“托管解决方案”，大概是大力推动 Windows Azure 的一部分。 我一挂断电话，我们的营销总监就来到我的办公室，并表示我们的大多数客户都要求在下一版本中集成 Active Directory。 然后我想到：如果应用程序不在客户的网络上，如何在“托管解决方案”中使用 Active Directory？
作为有关 Active Directory 集成的一个更普遍的问题，这通常对应用程序意味着什么样的功能更改？ 这是否意味着用户只需通过 Active Directory 身份验证即可登录应用程序，或者是否意味着应用程序从 Active Directory 获取其用户列表，或者在应用程序中创建新用户或组是否会在 Active Directory 中创建新用户或组？
我刚刚陷入了流行语战争的交火之中吗？
Yesterday I got a call from a Microsoft representative asking if we supply "hosted solutions", presumably as part of the big Windows Azure push. As soon as I got off that call, our marketing director came into my office and said the majority of our customers are demanding Active Directory integration in the next version. Then it occurred to me: how does one use Active Directory in a "hosted solution" if the application does not live on the customer's network?
As a more general question about Active Directory integration, what kind of functional changes does that usually imply for an app? Does it mean a user is signed into the app just by authenticating to Active Directory or does it mean the app gets its list of users from Active Directory or does the creation of new users or groups in the app create new users or groups in Active Directory?
Am I just caught in the crossfire of a war of buzzwords?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
你不。 Active Directory 可以在公共 Internet 上运行，尽管这使网络的安全性和设置变得相当复杂。
一般来说，根据 Active Directory 对应用程序进行身份验证意味着您的会员提供商（例如）将调用 Active Directory 进行身份验证，然后用户只需登录即可； 您不会在自己的数据库中保留活动凭据等。 不过，我认为明智的做法是缓存该信息，并准备除了目录之外还针对该缓存进行身份验证，以防域控制器无法进行身份验证（如果您跨域运行目录，则风险特别大）互联网）。
You're not. Active Directory can be run across the public Internet, though this complicates the security and setup of the network rather considerably.
Generally, authenticating an app against Active Directory means that your membership provider (for example) would call into Active Directory to do the authentication and, after that, the user is simply logged in; you don't keep active credentials, etc, in your own database. However I would consider it smart to cache that information as well, and be prepared to authenticate against that cache in addition to the directory, in case the domain controller is unavailable for authentication (an especially large risk if you're running the directory across the Internet).
您可以使用 Active Directory 联合服务在两个组织之间通过 Internet 启用 AD 身份验证。 请参阅：http://technet.microsoft.com/en-us/library/ cc786469.aspx
我从未使用过它，只是读过它。 希望能帮助到你。
You can use Active Directory Federated Services to enable authentication using AD over the internet between two organizations. See: http://technet.microsoft.com/en-us/library/cc786469.aspx
I've never used it only read about it. Hope it helps.
接受的答案解释了 Active Directory 的作用，我同意缓存基本用户信息在许多情况下可能很有用。
Active Directory 可以扩展到企业网络之外、互联网和连接的 Web 服务。 正如另一位用户提到的，这是通过 ADFS（Active Directory 联合服务）实现的，它允许在单独的身份验证服务之间建立“可信”连接。 “Office 365 Jump Start”网络研讨会解释了许多场景：
http://technet.microsoft.com/en-us/edge/office-365-jump-start-04-microsoft-office-365-identity-and-access-solutions
查看这些后，我立即认为“托管”AD 和 ADFS 服务在客户不想在内部维护 AD 服务器的情况下会很有用（如果您这样做，Microsoft 不建议运行少于 5 个单独的服务器！）最近，Microsoft还推出了Azure云平台。 他们提供的其中一项服务被标记为“身份”，您可以在此处看到：
http://www.windowsazure.com/en-us/services/identity/
这是 Microsoft 自己的托管 AD 服务解决方案。 事实上，他们甚至提到使用他们的“Identity”托管服务作为 Office 356 甚至 Google Web 应用程序的 SSO（单点登录）解决方案。
我仍在学习 AD 和 Microsoft 的云产品，但我希望这能为您指明正确的方向。
The accepted answer explains the role of Active Directory and I agree that caching basic user information may be useful in many instances.
Active Directory can be expanded outside of a corporate network, to the internet and connected web services. As another user mentioned, this is achieved through ADFS (Active Directory Federation Services) which allows "trusted" connections to be set up between separate authentication services. There were a number of scenarios explained as part of the "Office 365 Jump Start" webinars:
http://technet.microsoft.com/en-us/edge/office-365-jump-start-04-microsoft-office-365-identity-and-access-solutions
After viewing these, I immediately thought that a "hosted" AD and ADFS service would be useful, where a customer doesn't want to maintain the AD servers internally (Microsoft don't recommend running less than 5 seperate servers if you're doing this!) Recently, Microsoft have also launched their Azure cloud platform. One of the services they provide is labelled "Identity" which you can see here:
http://www.windowsazure.com/en-us/services/identity/
This is Microsoft's own solution to hosted AD services. In fact, they even mention using their "Identity" hosted service as a solution for SSO (Single Sign-On) for Office 356 and even Google web apps.
I am still learning about AD and Microsoft's cloud offerings, but I hope this points you in the right direction.
这里有一篇文章： http://www.developerfusion.com /article/121561/integrating-active-directory-into-azure/ 深入描述了如何将 Active Directory 与 Azure 集成 - 希望有所帮助。
There's an article here: http://www.developerfusion.com/article/121561/integrating-active-directory-into-azure/ which describes in-depth how to integrate Active Directory with Azure - hope that helps.
Active Directory 可以在公共互联网上运行，但您会遇到延迟时间，这可能会导致您的应用程序超时或崩溃，具体取决于您的带宽。 过去，我在另一家名为 ultradns.com 的公司设立了帐户，该公司专门从事此类场景。 希望有帮助。
Active Directory can be run across the public internet but you will experience lag times which may cause your app to time out or crash depending on your bandwidth. In the past, I have setup accounts with another company called ultradns.com who specializes in these types of scenarios. hope that helps.
如果您需要微软的任何支持，您最好选择真正的托管框架。
我确定您需要一些链接：
HMC （托管消息传递和协作）
我所知道的关于该框架的唯一真实博客来自 Kip Ng
ASP.NET 论坛也是解答有关框架问题的良好资源。
此处是为 Exchange 多租户配置 AD 的工作示例，尽管它基于旧版本的框架，但许多相同的原则都适用。
另外，尝试搜索关键字多租户来查找一些文章。
You'd be best off going with a true hosting framework if you would like any support from MS.
I'm sure you'd like some links so:
HMC (Hosted Messaging and Collaboration)
The ONLY true blog I know about on the framework is from Kip Ng
The ASP.NET forums are a good resource for questions on the Framework as well.
An example of the work that goes into configuring AD for Exchange multitenancy is here, though it is based on an older version of the framework a lot of the same principles apply.
Also, try searching on the keyword multitenancy for some articles.