ASP.NET 应用程序通过 Windows 身份验证或表单身份验证向 Active Directory 或 SQL 进行身份验证
我正在编写一个需要多种身份验证形式的应用程序。
应用程序需要支持对 Active Directory 的身份验证，但如果用户不在 Active Directory 中，则能够故障恢复到 SQL 成员资格提供程序。 我们可以根据提供的用户名在代码中处理 SQL 提供程序的故障，因为该用户名的格式与 Active Directory 用户名不同。
这可能吗？ 我的意思是，我可以使用会员资格并同时使用 ActiveDirectoryMembershipProvider 和 SqlMembershipProvider 吗？还是我必须自己推出？
另一个额外增加的复杂性是，我希望基于 Windows 身份验证自动对我的内部用户进行身份验证返回 AD，但对不在我们内部网络上的用户或使用 SQL 提供程序的用户使用表单身份验证。
这些很可能是单独的服务器，一个是内部的，另一个是外部的，所以我有很多计划要做来弄清楚数据复制，以及如果 AD 用户访问外部服务器等，我将如何对他们进行身份验证。
我想知道当我开始走这条路时，有什么想法？ 我想要做的事情是否可以在没有我自己动手的情况下实现，或者有没有办法将它们结合在一起？
谢谢回复。
我最初提出这个问题的原因是，大约 7 年前，我能够使用 IIS 进行身份验证，然后将凭证传回 Lotus Domino Server Web 应用程序，让这个特定的 senerio 正常工作。 如果用户未通过 Windows 身份验证/ISS 进行身份验证，则 Domino 将处理身份验证。 这就是我想要在这里做的，但真的想不出一种方法让它在 IIS 中工作。
至于你回复的其余部分，我认为你已经明白了我需要采取的方式。 我已经仔细考虑过这个问题，并在脑海中反复思考过很多次。 无论如何，两个服务器上的应用程序都会有所不同，因为无论如何对外部服务器上的数据的访问都会受到限制。 事实上，已经有很多不同了，我可能只是将它们视为两个应用程序，从而无需在同一应用程序中使用两种类型的身份验证。
我正在考虑为外部服务器编写自己的身份验证/登录窗口的想法，如果用户尝试使用外部服务器上的 AD 凭据登录，我将能够检测到并将其重定向到内部服务器服务器。 如果他们不在本地网络或 VPN 上，他们将根本无法访问。 这部分仍然需要一些思考过程，所以我不确定。
作为一个额外的想法 - 有没有一种方法可以将足够的 AD 提取到 SQL 数据库中，以便我可以使用 AD 凭据从外部服务器对 SQL 数据库的用户进行身份验证，而不会产生任何安全问题？ 我希望我清楚地输入了我的想法......
再次感谢！
蒂姆
I am in the process of writing an application that will need multiple forms of authentication.
The application will need to support authentication to Active Directory, but be able to fail back to a SQL Membership Provider if the user is not in Active Directory. We can handle the failing to the SQL Provider in code based on the username provided because the username will be a different format than the Active Directory username.
Is this even possible? What I mean is, can I use membership and use both ActiveDirectoryMembershipProvider and SqlMembershipProvider together or will I have to roll my own?
Another additional added complexity is that I would like to automatically authenticate my internal users based of Windows Authentication back to AD, but use Forms Authentication for users not on our internal network, or users that are using the SQL Provider.
These will most likely be separate servers, one internal, and the other external so I have a lot of planning to do to figure out the data replication, and how I will authenticate the AD users if they hit the outside server etc.
I am wondering what thoughts are out there as I start down this road. Is what I am wanting to do even possible without me rolling my own, or is there a way to mesh these together?
Thanks for the reply.
The reason I asked originally was because I was able to get this specific senerio working about 7 years ago using IIS to authenticate and then passing back the credentials to a Lotus Domino Server Web App. If the user was not authenticated via the Windows Authentication/ISS then Domino would handle the authentication. This was what I was looking to do here, but really couldn't think of a way to make it work in IIS.
As for the rest of your reply, I think you are on to the way that I will need to take. I have thought this through and tossed it around in my head a lot. The application will be somewhat different on the two servers anyway since there is going to be limited access to the data on the external server anyway. The fact that so much is going to be different already I may just treat these as two applications, thus negating the need to use two types of authentication in the same application anyway.
I am playing around with the idea already of writing my own authentication/login window for the external server, and if the user trys to log in with their AD credentials on the external server I will be able to detect that and redirect them to the internal server. If they are not on the local network or VPN'd in they will simply not get access. This part still has some thought process to go though so I am not sure.
As an additional thought - is there a way to pull just enough of AD into a SQL database to allow me to authenticate users to the SQL database from the external server using their AD credentials, without creating any security issues? I hope I am clearly typing what I am thinking....
Thanks again!
Tim
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，Web 应用程序配置为使用 Windows 身份验证或表单身份验证，但不能同时使用两者。 因此，我认为不可能在要求其他人输入用户名/密码的同时自动对内部用户进行身份验证。
您可以使用自定义提供程序通过表单身份验证向 Active Directory 或 SQL 用户存储进行身份验证。 但是，AD 用户仍然需要输入用户名和密码。 尽管我从未将这两种方法结合起来，但我曾使用表单身份验证来一次或另一次对这两个来源进行身份验证。
话虽如此，我认为您可能需要考虑降低系统的“灵活性”。 如果您有一个面向外部的服务器和一个面向内部的服务器，您只需更改应用程序的每个副本上的提供程序配置即可针对不同的源。 然后，您可以将内部身份验证配置为使用 Windows（自动）身份验证，将外部身份验证配置为使用 Forms 身份验证。
恕我直言，我认为内部用户不应该使用外部服务器来访问应用程序。 如果是的话，他们应该有一个存储在 SQL 中的用户帐户，与他们的 AD 帐户完全分开。 基本上，当有人从外部访问应用程序时，他们就充当外部用户，无论其物理位置如何。
As far as I know, Web Applications are configured to use either Windows Authentication or Forms Authentication, but not both. Therefore, I do not believe it is possible to automatically authenticate internal users while requiring others to enter a username / password.
You could authenticate to Active Directory or a SQL user store via Forms authentication by using a custom provider. However, the AD users would still need to enter their username and password. Although I've never combined these two methods, I have used Forms authentication to authenticate against both sources at one time or another.
With that said, I think you may want to consider reducing the "flexibility" of your system. If you have an external facing server and an internal facing server, you could simply change the provider configuration on each copy of the application to go against a different source. Then, you could configure the internal one to use Windows (automatic) authentication and the external one to use Forms authentication.
IMHO, I believe that internal users should not be using the external server to access the application. If they are, they should have a user account stored in SQL, completely separated from their AD account. Basically, when someone accesses the application externally, they are acting as an external user, irregardless of their physical location.
好吧，可以使用 ActiveDirectoryMembershipProvider 和 SqlMembershipProvider，但这需要您使用自己的代码而不是登录控件来设计登录页面。
关于混合身份验证（Windows 和 Forms），据我所知，只有 IIS 7 可以使其变得简单和干净。 有关详细信息，请参阅此帖子
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication。 ASPX
Well, it is possible to use ActiveDirectoryMembershipProvider and SqlMembershipProvider, but this requires you design your log on page with your own code instead of the Login controls.
About the mix authentication (Windows and Forms), as far as I know only IIS 7 makes it easy and clean. See this post for details,
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx
这是我基于 此信息：
基本上发生的情况是，当未经身份验证的用户访问该站点时，他们会被重定向到 WinLogin.aspx。 由于匿名已关闭，因此集成安全性会进行检查。 如果通过，您在 WinLogin 中的自定义代码就可以运行。 如果集成安全检查失败，则会出现 401 错误。 您的自定义 401 页面重定向到 Login.aspx，用户可以在其中使用 SQL 提供程序的用户名和密码登录。
This is the way I've handled a similar situation based on this info:
What basically happens is that when an unauthenicated user hits the site, they're redirected to WinLogin.aspx. Since anonymous is turned off, integrated security makes a check. If that passes, your custom code in WinLogin can run. If the integrated security check fails, a 401 error occurs. Your custom 401 page redirects to Login.aspx where the user can log in using their username and password with the SQL provider.