Utilisation de DefaultCredentials et DefaultNetworkCredentials
Nous avons du mal à comprendre comment ces objets d'identification fonctionnent. En fait, ils peuvent ne pas fonctionner comme nous nous attendions à ce qu'ils fonctionnent. Voici une explication du problème actuel.
Nous avons 2 serveurs qui doivent communiquer entre eux via des services Web. Le premier (appelons-le Server01) a un service Windows exécuté en tant que compte NetworkService. L'autre Server02 a ReportingServices en cours d'exécution avec IIS 6.0. Le service Windows sur Server01 essaie d'utiliser le Server02 ReportingServices WebService pour générer des rapports et les envoyer par email.
Alors, voici ce que nous avons essayé jusqu'à présent.
Définition des informations d'identification lors de l'exécution ( Cela fonctionne parfaitement bien ):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Maintenant, si nous pouvions utiliser un utilisateur générique, tout irait bien, cependant ... nous ne sommes pas autorisés à le faire. Nous essayons donc d'utiliser les DefaultCredetials ou DefaultNetworkCredentials et de les transmettre au RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Ou:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Dans les deux cas, cela ne fonctionnera pas. Nous obtenons toujours 401 non autorisé par IIS. Maintenant, ce que nous savons, c'est que si nous voulons donner accès à une ressource journalisée en tant que NetworkService, nous devons l'accorder à DOMAIN\MachineName$ ( http://msdn.Microsoft.com/en-us/library/ms998320.aspx ):
Accorder l'accès à un serveur SQL distant
Si vous accédez à une base de données sur un autre serveur du même domaine (ou dans un domaine approuvé), les informations d'identification réseau du compte de service réseau sont utilisées pour vous authentifier auprès de la base de données. Les informations d'identification du compte de service réseau sont de la forme DomainName\AspNetServer $, où DomainName est le domaine du serveur ASP.NET et AspNetServer est le nom de votre serveur Web.
Par exemple, si votre application ASP.NET s'exécute sur un serveur nommé SVR1 dans le domaine CONTOSO, SQL Server voit une demande d'accès à la base de données de CONTOSO\SVR1 $.
Nous avons supposé que l'octroi de l'accès de la même manière avec IIS fonctionnerait. Cependant, ce n'est pas le cas. Ou du moins, quelque chose n'est pas défini correctement pour qu'il s'authentifie correctement.
Alors, voici quelques questions:
Nous avons lu quelque part sur "Usurpation d'identité des utilisateurs", devons-nous définir cela quelque part dans le Service Windows ?
Est-il possible d'accorder l'accès au compte intégré NetworkService à un serveur IIS) distant?
Merci d'avoir lu!
Tous les détails dont vous avez besoin sont inclus dans cet article très ancien,
http://msdn.Microsoft.com/en-us/library/ms998351.aspx
En bref, lorsque vous trouvez déroutant de résoudre des problèmes comme celui-ci, vous devez d'abord examiner attentivement les détails techniques derrière l'emprunt d'identité ASP.NET.
Le problème est-il que vous ne parvenez pas à vous authentifier auprès d'IIS ou à ne pas vous authentifier auprès de SSRS? Le compte DOMAIN\MachineName $ peut avoir besoin d'une autorisation dans SSRS pour exécuter le rapport que vous essayez d'automatiser.
SSRS fait généralement un très bon travail pour obtenir IIS configuré correctement, vous ne devriez donc pas avoir à vous soucier de ces paramètres. J'ai revérifié mon installation (qui est SSRS 2005, les choses ont peut-être fonctionné) différemment dans SSRS 2000 et vous n'avez pas dit quelle version vous utilisez), et il est configuré pour utiliser l'authentification Windows et a l'emprunt d'identité activé. Cela signifie IIS devrait essentiellement authentifier vos informations d'identification ( valider un nom d'utilisateur/mot de passe correct), non autoriser (déterminer si cet utilisateur a l'autorisation d'exécuter le rapport en question). IIS transmet ensuite les informations d'identification à SSRS, qui a ses propres paramètres pour déterminer quels comptes sont autorisés à afficher des rapports.
En outre, vous pouvez automatiser l'envoi de rapports sur une base planifiée directement dans SSRS, de sorte que vous n'aurez peut-être pas du tout besoin du service Windows si votre planification est assez basique (c'est-à-dire quotidienne, hebdomadaire, etc.).
Voici quelques éléments que vous pouvez vérifier: - définir un SPN (Service Principal Name) pour le service de reporting; vous pouvez trouver de bons exemples dans google; - Autoriser la délégation (ClientCredentials.Windows.AllowImpersonationLevel)