Результаты запроса SQL Server 2005 различаются для разных учетных записей AD, использующих один и тот же вход SQL.

Есть две учетные записи AD, admin1 и admin2. Оба вошли в систему на одинаковых машинах, оба открывают SQL Server Management Studio и входят в систему как один и тот же пользователь SQL на один и тот же сервер SQL (с использованием проверки подлинности SQL Server, а НЕ с использованием встроенной безопасности), и оба запускают идентичный запрос: «SELECT * FROM Вид1". Однако admin1 получает много результатов (правильный набор результатов), тогда как admin2 получает пустой набор результатов. Это происходит на каждом компьютере в домене, независимо от версии Windows, проводного/беспроводного подключения и т. д.

Почему это происходит? Разве SSMS не должна быть независимой от учетной записи Windows при использовании проверки подлинности SQL Server? Любая помощь будет оценена по достоинству.


dynamics-crm active-directory crm sql-authentication sql-server-2005
person Corehop    schedule 19.09.2011    source источник
comment
Есть ли шанс, что вы используете схемы, и admin1 сопоставляется с другой схемой, чем admin2? Кроме того, попробуйте исключить SSMS из набора, запустите его из командной строки (примерно) sqlcmd -s servername -D myDB -u myUser -p Pwd -Q SELECT * FROM View1   -  person billinkc    schedule 19.09.2011

Ответы (2)


arrow_upward
1
arrow_downward

Проблема, с которой я столкнулся, была связана с Microsoft Dynamics CRM, а не с самим SQL Server. Я использовал фильтрованные представления, которые возвращают нулевые результаты любому пользователю, не использующему проверку подлинности Windows. Я не уверен, как я получил результаты, о которых я упоминал выше, но повторив попытку в другой день, я так и не смог получить результаты с аутентификацией SQL, независимо от того, какую учетную запись Windows я использовал. Точно так же я всегда мог получить результаты при входе в систему с проверкой подлинности Windows.

person Corehop    schedule 27.10.2011

arrow_upward
1
arrow_downward

Вы можете либо использовать необработанные таблицы, либо взломать базовую структуру представления, вручную вставив записи, которые показывают имя домена в качестве идентификатора входа в систему проверки подлинности SQL Server, и предоставив не CRMReaderRole, а стандартную роль DQL. Взгляните на замечательную функцию fn_FindUserGuid, которая ищет SystemGuid, к которому присоединяются все внутренние представления. Просто сфабрикуйте эту пластинку и несколько других, и все будет хорошо. Если вы перепроектируете их систему, вы увидите, что есть способ обмануть систему.

По сути, это просто SystemUserBase, SystemUserPrincipals, UserSettingsBase.

Очевидно, что это не рекомендуется Microsoft. ¯(°_°)/¯ Но когда вам нужно подключение ODBC к общему серверу, который предоставляет общие отчеты многим пользователям за пределами прекрасного мира CRM, вам нужно сделать это. Вы НЕ найдете другого способа, кроме репликации данных в другую базу данных, но, конечно, имейте в виду, что динамика удивительно динамична и часто меняется. Удачи в синхронизации сред.

На мой взгляд, эта система явно была разработана таким образом, чтобы склонить пользователей к продуктам Microsoft. Не говоря уже о том, что я бы не поступил так же, если бы владел Microsoft. Когда вас заставляют взломать, вас заставляют взломать.

person Johnny Shockers    schedule 30.04.2012