将 Active Directory 与我的应用程序同步
我继承了一个具有自己的用户数据库和登录身份验证方案的应用程序，该方案无法替换。
现在需要与 Active Directory 集成。
我已经实现了混合模式（表单和 AD）身份验证，其中我遇到的问题是保持用户同步，
我已在用户数据库中添加了一列以获取活动目录帐户名称。管理员需要在 AD 中创建一个用户，在我们的应用程序中创建它，然后在我们的应用程序中，选择匹配的 AD 用户......
这感觉又脏又天真，有什么更好的方法可以做到这一点。
I've inherited an application with its own user database and login authentication scheme which cannot be replaced.
There is now a need to integrate with Active Directory.
I've implemented mixed mode (forms and AD) authentication, where I'm having issues is keeping the users in sync
I've added a column to our user database for the active directory account name. The admin will need to create a user in AD, Create it in our application, and then in our application, select the AD user that matches...
This feels dirty and naive, what better ways are there to do this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以将 Active Directory 作为 SQL Server 中的链接服务器进行查询。您可以编写存储过程来尝试查询 SQL Server 表或 Active Directory 并返回正确的登录信息。不会有数据的复制或同步。
以下是如何将 AD 添加为链接服务器并对其进行查询（不过，您必须使用 LDAP 字符串，希望您了解 AD 的基础知识）： http://www.kodyaz.com/articles/active-directory-services-queries-using-openquery.aspx
You can query Active Directory as a linked server in SQL Server. You could write stored procs that would attempt to query either SQL Server tables or Active Directory and return the correct login information. There would be no copying or synchronizing of data.
Here's how to add AD as a linked server and query it (you have to use LDAP strings, though, hopefully you know the basics of AD): http://www.kodyaz.com/articles/active-directory-services-queries-using-openquery.aspx
正如其他人提到的，一件事是不要使用名称作为数据库中的键。使用 AD 中的用户 SID 作为数据库中的密钥，因为它在 AD 中是持久的并且不会更改。 GUID 也可以使用，但我相信在某些情况下这可能会改变。
我会研究两种方法：
One thing, as others have mentioned, is to not use the name as the key in your DB. Use the user's SID from AD as the key in your database, as this is persistent in AD and will not change. The GUID could be used too, but in some scenario's this may change i believe.
There are two approaches I would look into:
我建议的一件事是不要将帐户名存储在数据库中，而是将 AD 用户帐户的 GUID 存储在数据库中。然后，如果某些管理员更改了某些内容，即使用户名已更改，连接也会保留。
您可以在 sql server 中使用 CLR 库 和一个sql 作业，用于定期在 AD 和用户之间同步帐户数据库。
您可以使用一个组，clr 库可以查找该组，拉入所有成员，然后自动同步 - 即根据 AD 组的所有权更新/创建/停用帐户。然后，您的管理员只需在 AD 中创建用户，授予他们访问组的权限，然后等待作业开始。 （或者手动启动）
One thing I recommend is not storing the account name in the database, but the guid for the AD user account. Then if some admin changes something the connection remains even though the username has changed.
You can use a CLR library within sql server and a sql job to periodically sync accounts between AD and the user database.
You could use a group, which the clr library can look for, pull in all the members, and then automatically sync - that is update/create/deactive accounts according to their ownership of the AD group. Then your admin will only need to create the user in AD, give them access to the group, and wait for the job to kick off. (or go kick it off manually)
我目前正在参与一个项目，该项目在某些方面与您所描述的类似。我发现创建通过 SQL CLR 函数调用的托管程序集是与 Active Directory 集成的最佳方式。最后，我确实觉得 SQL CLR 解决方案足够优雅且易于管理，足以支持我未来的需求。
由于我的项目和解决方案与您的情况并不完全相同，因此我没有完美的答案，但是如果您选择使用 SQL CLR 与 Active Directory 集成，我确实有一些一般性建议。当然，您可能仍然想考虑将 Active Directory 作为链接服务器进行查询（正如 DarrellNorton 在他的 答案）...这可能很适合您的需求。
如果您确实决定采用 SQL CLR，您可能会发现这些注释很有帮助...
使用 SQL CLR 与 Active Directory 集成：
使用 SQL CLR 与 Active Directory 集成的好处是您将使用托管代码，并且您可以使用 .NET Framework 的大部分内容来实现您想要实现的功能。对我来说，缺点是您最终必须编写一个像样的库程序集，该程序集对异常具有相当的弹性，以防止对数据库引擎的可靠性造成任何理论上（或实际！）的损害。
注册您的程序集和使用
系统目录服务
我在将程序集安装到 SQL Server 时遇到的第一个“问题”是您必须在数据库中注册 System.DirectoryServices 程序集...默认情况下它未启用。以下问题和接受的答案详细介绍了该问题。希望这可以为您节省一些提前了解陷阱的时间。
在 .NET 中使用 Active Directory
我要指出的另一件事是我用来构建自定义库的资源。我在 Code Project 上找到了一篇很棒的（虽然有点旧）How-To 文章，它几乎是我整个实现的主要参考来源：
Code Project 上的（几乎）通过 C# 实现 Active Directory 中的所有内容< /p>
您会发现这篇文章涵盖了从创建和创建的所有内容。管理用户使用域和信任。
我对此资源的唯一问题是它不涵盖 System.DirectoryServices（例如帐户管理、协议、ActiveDirectory）。据我了解，在 .NET 中有多种与 LDAP 交互的方法。我的预感是，如果对所有这些名称空间有正确的了解，可能会创建更好/更快的实现。这并不是说我当前的实现速度不够快，无法满足我的需求...我只是想知道如果我通过原始 LDAP 协议（System.DirectoryServices.Protocols）或其他方式编写“更接近金属”是否会更好.
I am currently involved in a project that is similar in some ways to what you described. I have found that creating a managed assembly called via SQL CLR functions was the best way to integrate with Active Directory. In the end, I do feel like the SQL CLR solution is elegant and manageable enough to support my needs into the future.
Since my project and the solution are not the exact same as your situation I don't have the perfect answer, however I do have some general advice if you go the route of using SQL CLR to integrate with Active Directory. Of course, you might still want to look into querying Active Directory as a linked server (as suggested by DarrellNorton in his answer)... this may suit your needs just fine.
If you do decide to go the route of SQL CLR you might find these notes helpful...
Using SQL CLR to integrate with Active Directory:
The nice thing about using SQL CLR to integrate with Active Directory is that you will be using managed code and you have most of the .NET Framework at your disposal in terms of what functionality you want to implement. The downside for me has been that you end up having to write a decent library assembly that is fairly resilient against exceptions to prevent any theoretical (or real!) impairment to your database engine's reliability.
Registering your assembly & using
System.DirectoryServices
The first "gotcha" I ran into installing my assembly to SQL Server was that you have to register the System.DirectoryServices assembly in the database... by default it is not enabled. The following question and accepted answer cover the issue in detail. Hopefully this saves you some time knowing about the gotcha in advance.
Working with Active Directory in .NET
The other major thing I would point out is the resource I used to build my custom library. I found a great (although slightly old) How-To article on Code Project which was pretty much the primary source of reference for my entire implementation:
(Almost) Everything In Active Directory via C# on Code Project
You will find that this article covers everything from creating & managing users to working with domains and trusts.
The only issue I have with this resource is that it does not cover the child namespaces under System.DirectoryServices (e.g. AccountManagement, Protocols, ActiveDirectory). From what I have read, there are multiple ways to interact with LDAP in .NET. My hunch is that there may be a better / faster implementation that could be created with the right knowledge about all of these namespaces. This isn't to say my current implementation isn't fast enough for my needs... I just wonder if it could be better if I wrote "closer to the metal" via raw LDAP protocols (System.DirectoryServices.Protocols) or something.
我想解决这个问题的最好方法是使用 Forefront Identity Manager -> http://www.microsoft.com/forefront/identitymanager/en/us /default.aspx
就像身份管理世界中的 BizTalk，您可以将信息同步到不同的异构基础设施，包括目录、数据库和业务线应用程序
I guess the best way to deal with this is using Forefront Identity Manager -> http://www.microsoft.com/forefront/identitymanager/en/us/default.aspx
its like BizTalk in Identity Management World, you can sync information to different heterogeneous infrastructure, including directories, databases, and line of business applications