出于安全考虑,我将从数据库中的每次登录中删除所有服务器角色,只留下“sa”:
//Get all server info for this instance
Server oServer = new Server(@"YAHYA-PC\SQLEXPRESS");
//Get all logins
var users = oServer.Logins;
//Get all server roles in the current instance
ServerRoleCollection oServerCollection = oServer.Roles;
//foreach login name drop all roles
foreach (Login oLogin in users)
{
if (oLogin.Name != "sa")
{
foreach (ServerRole oRole in oServerCollection)
{
if (oRole.Name != "public")
{
oRole.DropMember(oLogin.Name);
}
}
}
}
一开始是成功的,但是在第二次运行代码之后,事实证明Server对象通过Sql Windows身份验证连接,所以它不断给我一个例外,因为我省略了Sql Windows帐户中的所有服务器角色。是否有任何可能的方法使Server对象通过Sql Server帐户登录连接?
使用答案进行编辑:
ServerConnection oConnection = new ServerConnection(@“ServerInstance”,“UserName”,“Password”);
服务器oServer =新服务器(oConnection);
答案 0 :(得分:1)
尝试将连接字符串更改为:Provider = SQLNCLI10; Server = myServerAddress; Uid = myUsername; Pwd = myPassword
更新虽然这可能已经为您提供了您最初寻求的答案,但我同意Dave Markle's post中的所有内容,并且应该早些提及。
答案 1 :(得分:1)
出于安全考虑,我将从每个角色中删除所有服务器角色 登录数据库并只留下“sa”
我认为“安全目的”是将明智设计的安全功能从SQL Server中取出并用你设计的一组不明智的安全漏洞替换它们?
这是一个糟糕的坏主意,虽然可能有一种方法可以解决这个问题,但是你应该避免这样做。有一个原因,SQL Server不允许您只使用SQL Server身份验证,而只允许Windows身份验证。实际上,有多种原因:
1)Windows中的所有内容都在Windows安全上下文中运行。这包括SQL Server本身,它必须在Windows中存在的服务进程标识下运行,以便访问其所有数据文件。您无法完全从图片中删除Windows身份验证,因为它实际上管理着每台Windows计算机上的所有内容。
2)使用仅Windows身份验证(通常比使用混合模式身份验证更好的选项)允许使用Kerberos的委派方案。其他方案涉及不明智且有时不可能的凭证分配。诀窍是您必须正确配置Kerberos才能执行此操作。
3)您可以使用带有Windows身份验证的Active Directory集中管理您的密码策略。这是SQL Server身份验证无法实现的,因为可以在不知道您的网络管理员的情况下关闭密码策略检查。
此外,您打开SA帐户是登录服务器的唯一方法。这是非常不明智的,除非你只是在沙盒里玩,即便如此,我也不会这样做。通过仅使用SA帐户,使用服务器的每个人都可以通过全权访问来为您的服务器执行任何操作。如果您已授予对SQL Server服务流程的高级访问权限,那么几乎任何用户都可以相对轻松地控制整个计算机。
这是一个坏主意。我的建议是放弃这个想法,并在SO上发布关于你的更高层次目标以及如何实现这些目标的问题。
答案 2 :(得分:1)
您可以选择在SQL Server安装时使用Windows身份验证和/或SQL Server身份验证。这将是真正排除身份验证类型的最佳方式。至于你上面提到的动机,我会提醒你不要这样做。我把它比作说“我通过让每个人都成为管理员来提高安全性。”它没有意义。
你有很多旋钮可以提高安全性......角色是任何战略的关键部分......