Modèle pour les clients WCF Kerberos où le serveur utilise le compte utilisateur

Question

Nous avons une application client et service WCF (Windows Communication Foundation). Nous utilisons l'authentification Windows avec Kerberos. Le problème est que le service peut être exécuté sous l'un des nombreux comptes (peut-être le service réseau, peut-être un compte utilisateur spécifique) dépend du groupe informatique. Ce compte n'est pas susceptible de changer tous les jours, mais peut-être à l'occasion (tous les quelques mois peut-être). De plus, nous livrons ce package client/service à plusieurs groupes, et chaque groupe peut avoir son propre compte pour l'exécution du service (pour vous informer que nous ne pouvons pas faire de solution personnalisée pour une seule équipe).). Maintenant, la raison pour laquelle le paragraphe ci-dessus est un problème est apparemment si le service ne fonctionne pas dans le compte SYSTEM ou NETWORK SERVICE, c'est-à-dire un compte d'utilisateur, le client doit spécifier le nom du compte utilisateur dans l'identité de son point final.

Pour en savoir plus sur cette restriction, voir: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/feb6bc31-9a4b-4f8d-a887-ef6d2c7abe41 et http://www.vistax64.com/indigo/146204-using-localhost-v-s-environment-machinename.html

Maintenant, cela fait apparemment qu'il est difficile de faire face à la situation dans laquelle le service informatique change le compte que le service est exécuté. Quel est le modèle pour gérer cela, s'il y en a un? Comment d'autres personnes ont-elles géré cela? Une solution que j'ai pensée est que l'administrateur envoie un email quand le compte d'utilisateur du service a changé, qui a un weblink à une application qui met à jour le client ou un fichier de configuration, ainsi le client se rapporte au nouveau compte d'utilisateur . Mais cela semble hackish.

Certes, cela ressemble beaucoup à l'URI du point final mobile. Sauf que je pense qu'il y a beaucoup plus d'attente de la part des gens que changer l'URI est quelque chose que le client devrait savoir, mais changer le compte sur lequel le service fonctionne est quelque chose qui devrait être relativement transparent pour le client.

BTW, cela doit être hébergé sur IIS 7.0, si cela est important.

Answer 1

Je pense que vous pouvez définir la propriété NegotiateServiceCredential sur True afin que votre reliure utilise SPNego au lieu de hard-cold Kerberos. Lorsque est défini sur true, le client n'a pas besoin de spécifier le nom principal de service et il peut se connecter à un serveur exécutant un compte non-machine. Notez que puisque le client ne demande plus un SPN spécifique, il ne peut plus détecter s'il est connecté à un imitateur piraté du service, mais ceci est généralement mineur sauf si vous êtes vraiment paranoïaque à propos de la sécurité.

En outre, en tant que diatribe latérale: le fait que WCF demande comme SPN le nom du compte est fondamentalement un pet de cerveau. Ce client doit utiliser l'API DsMakeSpn pour composer le SPN à partir du nom du service, de l'hôte et du port. Le serveur doit enregistrer ce SPN pour itslef au démarrage ou laisser un administrateur le faire en utilisant setspn.exe. C'est ainsi qu'ils le font par tous les services traditionnels (bien comportés) dans l'environnement Kerberos/ActiveDirecotry/Windows.

Mise à jour

Sur seconde si je ne vois rien indiquant que le client doit utiliser le nom du compte comme SPN. Ressemble plus à une surveillance de la documentation, au lieu de documenter la bonne façon dont ils recommandent ce qui est fondamentalement une mauvaise pratique. Ou peut-être que le conseil du forum est mauvais, puisque je n'ai pas creusé pour voir ce que la spécification de liaison MSDN dit réellement sur le SPN à utiliser ...

Je ne dispose pas d'un environnement WCF pratique à tester, mais vous pouvez peut-être configurer les clients pour demander un SPN approprié tel que YourService/server:port et enregistrer également le même SPN côté serveur. Soit manuellement en tant qu'exercice laissé aux administrateurs, soit automatiquement à partir de votre service au démarrage et désinscrit à l'arrêt. Le bon façon de le faire est de laisser les admins le faire, mais en réalité c'est une telle douleur que la plupart des services enregistrent le SPN eux-mêmes et vous pouvez probablement suivre cette pratique aussi. Pour enregistrer un nom principal de service, votre service appelle DsWriteAccountSpn. L'écriture doit se propager à l'AD et être répliquée entre les serveurs AD, et ceci au moins une raison pour laquelle le service auto-register/auto-unregister le SPN est une pratique discutable.

Si vous voulez en savoir plus sur le monde merveilleux des SPN et comment ils peuvent détruire votre journée, vous pouvez consulter le How Service Publication and Service Principal Names Work.

Mise à jour

Je suis sûr que vous pouvez utiliser SPN vous le souhaitez. La plupart des exemples utilisent le nom de compte comme 'UPN' (nom principal d'utilisateur) au lieu de SPN, mais cela est juste pour la commodité des exemples car l'utilisation d'un vrai SPN se heurterait à des problèmes administratifs. , pourquoi les administrateurs devraient le faire ...). De Overriding the Identity of a Service for Authentication, pertinentes ont souligné:

Par défaut, lorsqu'un service est configuré pour utiliser une information d'identification de Windows , un élément qui contient un <userPrincipalName> ou élément <servicePrincipalName> est généré dans le WSDL. Si le service est en cours d'exécution sous le LocalSystem, LocalService ou NetworkService compte, est généré par défaut sous la forme de host/<hostname> parce que ces comptes un nom principal (SPN) ont accès à données SPN de l'ordinateur. Si le service exécute sous un compte différent, Windows Communication Foundation (WCF) génère un UPN sous la forme de <username>@<domainName>. Cela se produit car l'authentification Kerberos requiert qu'un UPN ou SPN soit fourni au client pour authentifier le service .

Vous pouvez également utiliser l'outil Setspn.exe pour enregistrer un SPN supplémentaire compte d'un service dans un domaine. Vous pouvez puis utiliser le SPN comme l'identité de le service. Pour télécharger l'outil, voir Windows 2000 Resource Kit Tool: Setspn.exe. Pour plus d'informations sur l'outil , voir Présentation de Setspn.

Answer 2

Set NegotiateServiceCredential et EstablishSecurityContext propriétés à False.