我一直在努力研究 SQL Server 中与安全相关的问题。
我们正在开发一个面向 SQL Server 2008 的 .NET 应用程序，并且我们希望使用 FileStream。
现在我发现，如果您使用集成安全性，SQL Server 只允许通过 Win32 API 进行 FileStream。问题是我们已经完成了大约 80% 的应用程序，但它完全基于 SQL 身份验证。因此，我们直接从应用程序中执行 INSERT，而不是对每个 CRUD 操作使用存储过程。
这是相对安全的，因为我可以以加密的形式存储 SQL 用户名和密码。我知道密码以明文形式传输，但我愿意接受这一点。
我们希望最终用户能够通过 Crystal Reports 等工具连接到数据库，为此我们有一个额外的 SQL 登录名，该登录名仅授予 SELECT 权限。
现在，如果我们更改为集成安全性，我们将必须授予个人用户（通过 AD 组等）执行应用程序可以执行的操作的权限。否则应用程序将无法完成其工作。但是，当最终用户直接连接到数据库时，他也将拥有这些权利。
我看到有人说您应该对每个 CRUD 操作使用存储过程，并仅向 AD 组授予 EXEC 权限，但我该怎么做呢？我不明白用户在直接连接或通过应用程序连接时如何拥有不同的授权......任何人都可以启发我这一点。
一个额外的加分问题：据我所知，集成安全性不适用于工作组。那么人们如何让 FileStream 在工作组中工作呢？或者这被认为是不可能的？
集成安全性将在工作组中工作，使用旧机制，您在两台计算机上拥有匹配的用户名和密码。此外，如果服务器具有匹配的用户帐户，则域用户可以使用旧机制登录到非域服务器。
集成安全性甚至可以处理不匹配的用户名和密码。这可能会对您的情况有所帮助。
尝试这个：
NET USE \\DBSERVER /USER:DOMAIN\USERNAME
系统将提示您输入密码。这将与数据库服务器建立 NetBIOS 会话。完成此操作后，您应该能够在数据库服务器上看到共享文件夹和共享打印机。
一旦在客户端计算机和数据库服务器之间建立了 netbios 会话，您就可以使用集成安全性，而无需提示输入密码。
You may如果它不能与 TCP 一起工作（但我认为可以），则必须指定“命名管道”作为要使用的网络协议。命名管道继承您现有的 NetBIOS 会话，因此只要您可以列出您可能就可以使用的共享。
您还可以使用Windows API函数建立登录会话NetUseAdd with USE_INFO_2（级别 2）包含密码的信息。
我想简短的答案是，您可以为您的应用程序提供特殊的 Windows 登录，并让用户使用它登录。但请注意，他们也无法使用自己的用户名和密码连接到同一服务器。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
