即使在设置了默认架构和默认数据库之后，也没有应用默认架构

Posted 2023-02-16

【中文标题】即使在设置了默认架构和默认数据库之后，也没有应用默认架构

【英文标题】：Default Schema not being applied even after setting default schema and default DB

【发布时间】：2020-02-14 23:34:13

【问题描述】：

我有一个有趣的问题！让我为你准备舞台：

1) Windows 身份验证

2) 已为登录 XCORP\USERA 的用户设置了默认架构标识

3) 已为登录 XCORP\USERA 的用户设置了默认数据库标识

4) XCORP\USERA 没有系统管理员

5) XCORP\USERA 是数据库的所有者

6) 已尝试运行新的数据库设置脚本（删除并重建数据库）

好的，正如我所提到的 - 这很有趣，原因如下 - 我有一个数据库帐户（我们将其称为 IdentityIQUSER），它使用 SQL 登录身份验证和完全相同的设置，可以正常工作！ （完全相同的设置意味着我可以在漂亮的小方框中选中和取消选中）我可以在 SQL 帐户上毫无问题地拨打电话。只有当我使用 windows 帐户时，我才发现问题。在做了一些灵魂搜索之后，我运行了以下命令，引导我找到了出错的路径（可能与登录有关）选择 SCHEMA_NAME();有趣的是，返回的不是identityiq，而是dbo，所以我做了更多的挖掘，发现了大量的有效访问。如果有帮助，我可以提供一份清单。所以这是我的三个问题。

问题 1：是否可以授予任何有效访问权限，从而导致 DBO 成为默认架构（类似于 sysadmin 发生的情况）

问题 2：AD 组可以控制您在服务器上获得的有效访问权限吗？如果这里的答案是肯定的，有谁知道我如何追踪 AD 中的哪个组授予了这些有效的访问权限？

问题 3：我从未在 DB 中如此深入 - 所以我可能没有看到正确的东西，所以如果这不是前进的正确方向，我应该去哪里看？

另外，作为旁注，我正在寻找是否可以使用显式访问覆盖有效访问（因为我相信拒绝优先），并且当我重新登录时，我的所有访问都已恢复......我我可能是第一个抱怨访问过多的人。大声笑感谢您花时间查看。

【参考方案1】：

好的，经过大量的故障排除和挖掘，我们找到了答案！我们知道来自 AD 的组可以设置 sysadmin，这将覆盖本机设置的任何内容。然而，我们不知道的是，如果通过连接到该组的 MSSQL 接口创建和添加一个帐户，它也会携带该服务器角色，即使它本身是关闭的。所以让我更简洁地解释一下。

第 1 步： 组 A 设置为 sysadmin 角色，是一个 AD 组，已添加到 MSSQL。 A 组 - 包含 XCORP\USER1

第二步： XCORP\USER1 将 XCORP\USER2 添加到 MSSQL。

遵循这个顺序 XCORP\USER2 现在永久成为系统管理员角色的一部分...我不知道为什么要遵循这个逻辑，但这是最终结果。

所以要修复它：

第 1 步：使用不属于包含 sysadmin 角色的组的帐户 步骤 2：添加另一个域用户 第 3 步：庆祝您拥有一个普通帐户。