Я столкнулся с очень странным поведением в SQL Server 2008R2.
У меня есть стороннее приложение, которое действует как клиент SQL Server. У меня есть часть моих пользователей, которые должны иметь доступ к этому приложению. Я создал группу Active Directory, назвав ее «DOM \ appusers», с парой тестовых пользователей. Я создал учетную запись SQL Server с тем же именем, создал базу данных, назвал ее «appdb», создал пользователя в базе данных appdb, «DOM \ appusers», связанный с этим именем входа, и назначил этому пользователю роль «db_owner». .
Большинство операций работают. Но «некоторые» из них получают ошибки. В частности, не удается выполнить один запрос:
SELECT x,y,z
INTO tmpTable
FROM (table1 INNER JOIN table 2 on table1.col1 = table2.col1)
INNER JOIN table3 ON table1.col2 = table3.col2
GROUP BY x,y,a,b,c
HAVING (((table2.col4)=0) AND
((table3.col5)=0)) AND
((table3.col6)=0)
Он был извлечен из SQL Profiler, где он пометил запрос как ошибку, но подробностей об ошибке не было, а приложение бесполезно, поэтому я не могу точно сказать, какая именно ошибка возникла.
Я не эксперт по SQL, поэтому я не знаю, что особенного в этом запросе или почему он должен требовать разрешений помимо db_owner, но на самом деле это не вопрос SQL-запросов.
Что действительно странно для меня, так это то, что если я обхожу группу, я получаю другие результаты. Если я удалю имя входа и пользователя SQL-сервера, описанные выше, затем создаю новое имя для входа и пользователя, напрямую ссылающегося на пользователя Active Directory, и назначу ему ту же роль db_owner, тогда вышеуказанный запрос будет работать. Действительно, все запросы работают должным образом.
Это было достаточно странно, и я подумал, что это моя ошибка. Я проделал один и тот же эксперимент трижды с одинаковым результатом. Я убедился, что тестовые пользователи не имеют доступа к базе данных без одной из указанных выше настроек. Я попытался назначить серверную роль «системного администратора» группе AD, и запрос начал работать. Очевидно, я не могу оставить это таким, но это была точка данных. Я также создал логин с использованием аутентификации SQL Server вместо аутентификации Windows, и это тоже сработало.
Итак, очевидный вопрос заключается в следующем: чем отличаются разрешения, когда пользователь получает их через группу, и «напрямую» (постольку, поскольку все является «прямым» с дополнительными уровнями входа в систему и пользователя базы данных MSSQL)? Не означает ли db_owner то же самое для группы, что и для пользователя? Это просто ошибка? Есть исправление? Я бы предпочел не добавлять каждого пользователя приложения в список пользователей / логинов SQL Server по отдельности, но это единственный обходной путь, о котором я думал до сих пор. Есть другое решение?
Заранее благодарю за любую помощь. :-)
Оказывается, это был не совсем вопрос о разрешениях, несмотря на сообщение об ошибке, которое я получал.
Короче говоря, пользователь SQL-сервера, связанный с группой Windows, не имеет схемы по умолчанию, и ее невозможно настроить. Это ограничение SQL Server 2008R2 (и, вероятно, более ранних версий), которое было исправлено в SQL Server 2012.
Таким образом, запрос приложения пытался создать свою tmpTable в схеме, в которой у него не было разрешения. Причина, по которой это сработало, когда я создал пользователя SQL Server, подключенного к одному пользователю Windows, заключается в том, что в этом случае он назначил схему по умолчанию «dbo», которая была правильной схемой. У пользователя было разрешение писать туда, и все работало.
В конечном итоге единственным решением для меня было создание отдельных пользователей SQL Server и учетных записей, связанных с отдельными учетными записями Windows. Это постоянная проблема обслуживания, но, похоже, она неизбежна в этой версии SQL Server.
Я почти уверен, что проблема в том, что учетная запись службы (вы сказали, что она работает как «СЕТЕВАЯ СЛУЖБА») не имеет необходимых учетных данных для поиска членов группы домена. Если пользователь домена проверяется ОС как действительно DOMAIN \ user, SQL Server доверяет этому, но если SQL Server необходимо проверить, действительно ли DOMAIN \ groupmember является членом DOMAIN \ group, это не удастся, потому что учетная запись службы не ' У меня есть необходимые разрешения для просмотра этой информации. Таким образом, член группы может войти в систему, потому что ОС говорит, что это нормально, но когда она позже проверяет разрешения на объекты, поиск не выполняется.
Попробуйте запустить службу SQL в качестве учетной записи пользователя / службы домена и посмотрите, поможет ли это.