Схема по умолчанию не применяется даже после установки схемы по умолчанию и базы данных по умолчанию

Question

У меня интересная проблема! Позвольте мне установить для вас сцену:

1) Windows Аутентификация

2) Для пользователя с логином XCORP \ USERA

3 установлено значение по умолчанию База данных identityiq по умолчанию установлена ​​для пользователя с логином XCORP \ USERA

4) XCORP \ USERA НЕ имеет sysadmin

5) XCORP \ USERA является владельцем БД

6) Попытался запустить новые сценарии установки базы данных (снял и перестроил базу данных)

Хорошо, как я уже говорил, это интересно по следующим причинам - у меня есть учетная запись в БД (которую мы будем называть IdentityIQUSER ), который использует SQL аутентификацию при входе в систему с точно такой же настройкой, которая прекрасно работает (Точно такая же настройка означает то, что я могу отмечать и снимать в милых маленьких коробочках). Я могу без проблем звонить с учетной записью SQL. Проблемы возникают только при использовании учетной записи windows. После некоторого поиска души я выполнил следующую команду, которая привела меня к пути, что что-то не так (возможно, при входе в систему). Выберите SCHEMA_NAME (); и что довольно интересно, возвращается не identityiq, а dbo, поэтому я немного покопался и наткнулся на гору эффективного доступа. Я могу предоставить список, если это будет полезно. Итак, вот мой вопрос, который состоит из трех частей.

Вопрос 1. Может ли быть предоставлен какой-либо эффективный доступ, при котором DBO будет схемой по умолчанию (аналогично тому, что происходит с sysadmin)

Вопрос 2. Могут ли группы AD контролировать, какой эффективный доступ вы получаете на сервере? Если ответ здесь «да», кто-нибудь знает, как я могу отследить, какая группа в AD предоставляет эти эффективные права доступа?

Вопрос 3: Я никогда не был так глубоко в БД - так что, возможно, я не буду глядя на правильную вещь, так что, если это не правильное направление для марширования, куда еще мне посмотреть?

Также в качестве примечания я хотел посмотреть, смогу ли я переопределить эффективный доступ явным доступ (поскольку я считаю, что Deny имеет преимущество) и, к сожалению, когда я снова вошел в систему, все мои права доступа были восстановлены ... Я, вероятно, первый человек, который когда-либо жаловался на слишком большой доступ. Спасибо, что нашли время посмотреть.

Answer 1

Хорошо, после долгих поисков и устранения неисправностей, мы нашли наш ответ! Мы знали, что для групп, которые приходят из AD, может быть установлен sysadmin, и он будет переопределять все, что изначально установлено. Однако мы не знали, что если учетная запись будет создана и добавлена ​​через интерфейс MS SQL, подключенный к этой группе, она также будет выполнять эту роль сервера, даже если изначально она отключена. Итак, позвольте мне объяснить более кратко.

Шаг 1: Группа A настроена на выполнение роли sysadmin и является группой AD и добавлена ​​в MS SQL. Группа A - содержит XCORP \ USER1

Шаг 2: XCORP \ USER1 добавляет XCORP \ USER2 к MS SQL.

в соответствии с этой последовательностью XCORP \ USER2 теперь постоянно является частью роли системного администратора. .Я понятия не имею, почему используется этот лог c, но это конечный результат.

Итак, чтобы исправить это:

Шаг 1: Используйте учетную запись, которая НЕ является часть группы, которая содержит роль sysadmin. Шаг 2. Добавьте другого пользователя домена. Шаг 3. Отпразднуйте, что у вас обычная учетная запись.