Используются ли в ваших отчетах сквозная встроенная аутентификация, определенная встроенная аутентификация пользователя или аутентификация пользователя sql? Я подозреваю, что первое, и в этом случае вы имеете дело с различием между олицетворением и делегированием.
При подключении к веб-серверу с использованием встроенной аутентификации за кулисами вы фактически используете NTLM или Kerberos. Оба позволяют процессу, выполняющему ваш веб-сервер, действовать как вы. Олицетворение NTLM с помощью маркера безопасности не позволяет серверу подключиться к другому серверу, как вы (то есть к серверу БД), и там снова действовать как вы - это проблема «двойного прыжка». Вместо этого Kerberos использует делегирование, передавая билет, который каждый сервер может проверить на допустимость и разрешить.
Для работы Kerberos есть несколько требований.
- Если вы подключаетесь к веб-серверу, используя имя, отличное от его основного DNS-имени (используя в качестве псевдонима), вы должны зарегистрировать псевдоним как действительный для машины с SetSPN. У вас могут быть проблемы с SPN (имя участника службы) даже без этого. Внимательно проверьте SPN на своих серверах, чтобы убедиться, что он соответствует ожидаемому.
- Сервер, к которому вы изначально подключаетесь, должен быть «доверенным для делегирования» в политике вашего домена.
- Пользователь, под которым работает ваш веб-сервер, также должен быть «доверенным для делегирования».
Вы можете обойти все это, просто сделав в своих отчетах сохраненные учетные данные, а не используя сквозную аутентификацию.
Разницей между dev и test может быть пользователь IIS или источник данных.
Теперь я предполагаю, что вы не используете SharePoint и просто выполняете обычную веб-установку SSRS. Поэтому, если это не так, скажите, пожалуйста.