2012-07-20 1 views
2

Je suis confronté à un problème DCOM plutôt étrange et très spécifique et j'espère que quelqu'un l'aura rencontré et résolu.Interopérabilité DCOM entre Windows XP et Windows 7

J'essaie d'instancier un objet COM dans un serveur EXE sur une machine Windows 7 (appelons-le W7). Le client réside sur une machine Windows XP (appelez-le WXP). Sur WXP, l'utilisateur connecté est un utilisateur de domaine. Sur W7, l'utilisateur est un utilisateur local. J'ai (afaik) correctement défini tous les droits DCOM, l'authentification et les privilèges de compte. Il n'y a pas de pare-feu impliqué. Tout ce que j'obtiens est que le processus du serveur COM EXE est démarré sur W7, avec le nom d'utilisateur que je m'attends, mais ne semble même pas atteindre sa fonction WinMain et reste suspendu et ne meurt jamais à moins que je le tue. Je peux attacher un débogueur distant (Visual Studio 2010) qui m'avertira que le processus pourrait être bloqué, et quand je le casse, il s'arrête dans une boucle de file de messages (GetMessage/Dispatch).

Le client obtient un pointeur (apparemment valide) mais toute tentative d'utilisation entraîne l'apparition de E_ACCESSDENIED.

Si quelque chose du scénario ci-dessus est modifié, l'instanciation de l'objet COM réussit et l'objet se comporte correctement.

Je sais que la chance est faible pour trouver une réponse, mais tout conseil est le bienvenu.

Merci.

Répondre

2

Le client et le serveur DCOM doivent être à la fois le même administrateur local sur le groupe de travail ou les utilisateurs de domaine sur le même domaine.

Vous pouvez utiliser cette application de test pour vérifier si vos deux machines sont correctement configurées: http://support.microsoft.com/kb/259011 De cette façon, vous assurez-vous que la permission de votre machine et pare-feu sont configurés correctement d'abord sans votre propre code.

+0

Merci pour la réponse. Je vais essayer bientôt et afficher les résultats. La chose confuse est que la situation inverse - dans lequel le client est sur W7 (pas dans le domaine) et le serveur est sur WXP (dans le domaine) - fonctionne! Il fonctionne avec les informations d'identification WXP locales (hors domaine) mais également avec les informations d'identification de domaine. – racanu

+0

J'ai jeté un coup d'œil à l'article et je remarque que le client ne prend pas les informations d'identification (c'est-à-dire le nom d'utilisateur/mot de passe). Cela me fait penser qu'il ne fournit aucun AuthInfo dans CoInitializeSecurity, ce qui signifie qu'il se connecte anonymement au serveur. Je n'ai pas configuré mon serveur pour une telle situation. Je vais le faire, pour l'expérience, mais je ne pense pas que ce soit une solution acceptable pour le code de production. – racanu

+0

J'ai trouvé cet article que j'avais initialement manqué, qui m'a donné quelques idées que je pourrais essayer: http: // stackoverflow.com/questions/6123301/how-does-usurpation-dans-dcom-travail – racanu

1

répondre à ma propre question ...

Il se trouve que dans le client CoInitializeSecurity n'a pas tous les pouvoirs dont il a besoin après tout ... Il a été appelé trop tôt, avant que les pouvoirs ont été connus.

J'ai découvert ceci après avoir utilisé CoSetProxyBlanket (comme décrit ici: How does impersonation in DCOM work?) sur chaque composant que j'instanciais. Chaque composant sur lequel j'ai appelé CoSetProxyBlanket fonctionnait correctement. Cela m'a incité à aller vérifier la CoInitializeSecurity.

Il reste étrange que la connexion inverse (de W7 à WXP) a fonctionné, mais c'est une autre recherche que je dois faire. La question actuelle peut être fermée.

Questions connexes