Utilisation de DefaultCredentials et de DefaultNetworkCredentials

Question

Nous avons du mal à comprendre comment fonctionnent ces objets d'informations d'identification. En fait, ils peuvent ne pas fonctionner comme nous nous attendions à ce qu'ils travaillent. Voici une explication du problème actuel.

Nous avons 2 serveurs qui ont besoin de parler les uns avec les autres via des services Web. Le premier (appelons-le Server01) a un service Windows en cours d'exécution en tant que compte NetworkService. L'autre Server02 a ReportingServices fonctionnant avec IIS 6.0. Le service Windows sur Server01 essaie d'utiliser le WebService ReportingServices Server02 pour générer des rapports et les envoyer par courrier électronique.

Donc, 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, mais ... nous ne sommes pas autorisés à. Donc, nous essayons d'utiliser les DefaultCredetials ou DefaultNetworkCredentials et le transmettre à la RS Webservice:

rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials 

Ou:

rs.Credentials = System.Net.CredentialCache.DefaultCredentials 

De toute façon ne fonctionnera pas. Nous recevons toujours 401 Non autorisé de IIS. Maintenant, ce que nous savons est que si nous voulons donner accès à une ressource connecté en tant que NetworkService, nous devons accorder à DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):

Octroi de l'accès à un serveur SQL distant

Si vous 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 s'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 votre nom de serveur Web. Par exemple, si votre application ASP.NET s'exécute sur un serveur nommé SVR1 dans le domaine CONTOSO, le serveur SQL voit une demande d'accès à la base de données à partir de CONTOSO \ SVR1 $.

Nous avons supposé que l'octroi d'accès de la même manière avec IIS fonctionnerait. Cependant, ce n'est pas le cas. Ou au moins, quelque chose n'est pas correctement configuré pour qu'il s'authentifie correctement.

Alors, voici quelques questions:

1. Nous avons lu à propos de « Usurpation utilisateurs » quelque part, avons-nous besoin de mettre cela quelque part dans le service Windows ?

2. Est-il possible d'accorder l'accès au compte intégré NetworkService à un serveur IIS distant?

Merci d'avoir lu!

Answer 1

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, quand vous trouvez qu'il est source de confusion pour résoudre les problèmes comme celui-ci, vous devez d'abord examiner les détails techniques derrière ASP.NET usurpation d'identité soigneusement.

Answer 2

Voici quelques éléments que vous pouvez extraire: - définir un nom principal de service (SPN) pour le service de génération de rapports; vous pouvez trouver de bons exemples dans google; - Autoriser la délégation (ClientCredentials.Windows.AllowImpersonationLevel)

Answer 3

Le problème que vous ne parvenez pas à vous authentifier auprès d'IIS ou de 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. En règle générale, SSRS réussit généralement à configurer IIS correctement, de sorte que vous ne devriez pas avoir à modifier ces paramètres. J'ai revérifié mon installation (qui est SSRS 2005, les choses peuvent avoir 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 l'emprunt d'identité est activé. Cela signifie qu'IIS devrait simplement simplement authentifier vos informations d'identification (en validant un nom d'utilisateur/mot de passe correct), ne pas autoriser (déterminer si cet utilisateur est autorisé à exécuter le rapport en question). IIS transmet ensuite les informations d'identification à SSRS, qui possède ses propres paramètres pour déterminer les comptes autorisés à consulter les rapports. En outre, vous pouvez automatiser l'envoi de rapports sur une base planifiée directement dans SSRS. Vous n'avez donc pas besoin du service Windows si votre planification est assez simple (par exemple, quotidienne, hebdomadaire, etc.).