Rapport SSRS Viewer + ASP.NET les informations d'Identification 401 Exception
J'ai un rapport enregistré sur un SQL2005 serveur de rapports, et je souhaite retourner un rendu PDF de ce rapport. J'ai compris cela lorsque l'on travaille avec un local *.rdlc fichier (et j'ai blogué à ce sujet), mais pas lorsque l' *.rdl réside sur un serveur de rapports. Je suis un 401 Non Autorisé erreur à la ligne...
reportViewer.ServerReport.SetParameters(reportDefinition.ReportParameters);
Voici la méthode utilisée pour effectuer le rendu du rapport.
public byte[] Render(IReportDefinition reportDefinition)
{
var reportViewer = new ReportViewer();
byte[] renderedReport;
try
{
var credentials = new WindowsImpersonationCredentials();
reportViewer.ServerReport.ReportServerUrl = new Uri("http://myssrsbox", UrlKind.Absolute);
reportViewer.ServerReport.ReportServerCredentials = credentials;
reportViewer.ServerReport.ReportPath = reportDefinition.Path;
//Exception is thrown on the following line...
reportViewer.ServerReport.SetParameters(reportDefinition.ReportParameters);
string mimeType;
string encoding;
string filenameExtension;
string[] streams;
Warning[] warnings;
renderedReport = reportViewer.ServerReport.Render(reportDefinition.OutputType, reportDefinition.DeviceInfo, out mimeType, out encoding, out filenameExtension, out streams, out warnings);
}
catch (Exception ex)
{
//log the error...
throw;
}
finally
{
reportViewer.Dispose();
}
return renderedReport;
}
L'autre chose qui vous manque plus que le WindowsImpersonationCredentials classe.
public class WindowsImpersonationCredentials : IReportServerCredentials
{
public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
{
authCookie = null;
userName = password = authority = null;
return false;
}
public WindowsIdentity ImpersonationUser
{
get { return WindowsIdentity.GetCurrent(); }
}
public ICredentials NetworkCredentials
{
get { return null; }
}
public override string ToString()
{
return String.Format("WindowsIdentity: {0} ({1})", this.ImpersonationUser.Name, this.ImpersonationUser.User.Value);
}
}
D'autres choses que vous devez savoir...
- C'est en cours d'exécution sur un intranet, et l'usurpation d'identité est activé.
- Journalisation indique que l'usurpation de l'identité de l'utilisateur est définie correctement.
- Ce fonctionne lors de l'exécution dans Visual Studio (
http://localhost:devport
), et il fonctionne lors de l'exécution sur ma zone de développement (http://localhost/myApplication
). Il ne fonctionne pas lors de l'exécution de nos tests ou les serveurs de production. - J'ai essayé des solutions à la fois avec et sans le système.net.defaultProxy paramètres dans le web.config. Ni travaillé.
Ce que je fais mal? Est-ce un paramètre de serveur? Est-il le code? Est-il web.config?
L'usurpation de l'identité de l'utilisateur d'avoir accès au serveur de rapports -- ce rapport en particulier?
Avez-vous essayé de lancer IIS sous l'usurpation de l'identité de l'utilisateur sur votre dev machine (localhost) pour imiter de plus près ce qui se passe sur votre serveur de test? Il sonne comme un plat problème d'autorisations avec emprunt d'identité de l'utilisateur contre le serveur de rapports ou de déclaration de base de données du serveur. Je suppose que l'usurpation de l'identité de l'utilisateur est un compte de domaine.
Oui, l'usurpation de l'identité de l'utilisateur a accès au répertoire approprié sur le serveur de rapports.
Avez-vous essayé de lancer IIS sous l'usurpation de l'identité de l'utilisateur sur votre dev machine (localhost) pour imiter de plus près ce qui se passe sur votre serveur de test? Il sonne comme un plat problème d'autorisations avec emprunt d'identité de l'utilisateur contre le serveur de rapports ou de déclaration de base de données du serveur. Je suppose que l'usurpation de l'identité de l'utilisateur est un compte de domaine.
Oui, l'usurpation de l'identité de l'utilisateur a accès au répertoire approprié sur le serveur de rapports.
OriginalL'auteur Jarrett Meyer | 2009-09-17
Vous devez vous connecter pour publier un commentaire.
Nous n'avons finalement trouver le problème. Nos administrateurs réseau ont désactivé le double-saut, alors que l'usurpation d'identité a été correctement connecté
domain\jmeyer
, la demande était encore de tenter de se connecter à la SRS boîte avecdomain\web01$
. Pourquoi est-il mis en place comme cela? Parce que le double-saut est un énorme trou de sécurité. (Ou alors on m'a dit. Cela sonne comme quelque chose que vous lisez sur Le Daily WTF?)Notre solution a été de créer un générique
domain\ssrs_report_services
de l'utilisateur, et se connecter avec cet utilisateur à la suite d'informations d'identification réseauCi-dessus est l'exemple classique de la solution que vous pouvez trouver partout dans les internets.
Comme il a été expliqué à moi, il fonctionne sur dev, car il ne compte pas comme un saut pour passer de localhost (comme client) -> localhost (IIS) -> SRS
Pour info, les administrateurs peuvent configurer la délégation par le serveur de base. Découvrez: serverfault.com/questions/16364/...
En créant un nouvel utilisateur de domaine, n'est-ce pas ce que cela signifie que vous ne serez pas en mesure de limiter les rapports jusqu'au niveau de l'utilisateur même si, comme tout le monde à l'aide de votre application va être authentifié en utilisant les mêmes informations d'identification? Merci
OriginalL'auteur Jarrett Meyer
"Double saut" est autorisé - swith sur l'authentification Kerberos ... (à condition qu'il fonctionne correctement!)
OriginalL'auteur