j'ai le problème suivant : j'ai deux PC en réseau sous Windows NT 4 avec
deux applications qui doivent communiquer via un pipe nommé à travers le
réseau. Je possède les sources de l'appli qui ouvre le pipe en tant que
serveur, je peux les modifier.
J'ai d'abord fait un essai en utilisant le même domaine/utilisateur sur
les deux PC : ça marche.
Deuxième essai avec deux utilisateurs différents : là ça ne marche plus,
je suppose que c'est un problème de droits.
Je voudrais savoir où se situe le problème : est-ce au moment de la
création du pipe nommé qu'il faut définir les paramètres de sécurité, ou
bien dans les paramètres de configuration de Windows ? Auriez-vous un
lien expliquant comment il faut faire ?
Question subsidiaire : si je veux en plus faire la même manip en
utilisant cette fois des comptes locaux au lieu de comptes itinérants,
est-ce que je vais avoir des problèmes supplémentaires ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud Debaene
Frederic Phan wrote:
Bonjour,
j'ai le problème suivant : j'ai deux PC en réseau sous Windows NT 4 avec deux applications qui doivent communiquer via un pipe nommé à travers le réseau. Je possède les sources de l'appli qui ouvre le pipe en tant que serveur, je peux les modifier.
J'ai d'abord fait un essai en utilisant le même domaine/utilisateur sur les deux PC : ça marche.
Deuxième essai avec deux utilisateurs différents : là ça ne marche plus, je suppose que c'est un problème de droits.
Je voudrais savoir où se situe le problème : est-ce au moment de la création du pipe nommé qu'il faut définir les paramètres de sécurité, ou bien dans les paramètres de configuration de Windows ? Auriez-vous un lien expliquant comment il faut faire ?
Le paramètre lpPipeAttributes de CreatePipe spécifie les droits d'accès au pipe. Si tu lui passes NULL, l'utilisateur courant (celui qui créé le pipe), le groupe local Adminstrateurs et le compe Système à tous les droits sur le pipe. Le compte "Everyone" a les droits en lecture uniquement.
Tous les détails sont là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
Question subsidiaire : si je veux en plus faire la même manip en utilisant cette fois des comptes locaux au lieu de comptes itinérants, est-ce que je vais avoir des problèmes supplémentaires ?
Un compte local n'étant valide et connu que sur une machine donnée, oui tu vas avoir des problèmes en fonction de ta configuration exacte (est-ce que le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une solution est de donner les droits complets à tout le monde sur le pipe. Si on veut être quand même un poil sécurisé, le groupe "Authenticated Users" peut être utile.
Arnaud MVP - VC
Frederic Phan wrote:
Bonjour,
j'ai le problème suivant : j'ai deux PC en réseau sous Windows NT 4
avec deux applications qui doivent communiquer via un pipe nommé à
travers le réseau. Je possède les sources de l'appli qui ouvre le
pipe en tant que serveur, je peux les modifier.
J'ai d'abord fait un essai en utilisant le même domaine/utilisateur
sur les deux PC : ça marche.
Deuxième essai avec deux utilisateurs différents : là ça ne marche
plus, je suppose que c'est un problème de droits.
Je voudrais savoir où se situe le problème : est-ce au moment de la
création du pipe nommé qu'il faut définir les paramètres de sécurité,
ou bien dans les paramètres de configuration de Windows ? Auriez-vous
un lien expliquant comment il faut faire ?
Le paramètre lpPipeAttributes de CreatePipe spécifie les droits d'accès au
pipe. Si tu lui passes NULL, l'utilisateur courant (celui qui créé le pipe),
le groupe local Adminstrateurs et le compe Système à tous les droits sur le
pipe. Le compte "Everyone" a les droits en lecture uniquement.
Tous les détails sont là :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
Question subsidiaire : si je veux en plus faire la même manip en
utilisant cette fois des comptes locaux au lieu de comptes itinérants,
est-ce que je vais avoir des problèmes supplémentaires ?
Un compte local n'étant valide et connu que sur une machine donnée, oui tu
vas avoir des problèmes en fonction de ta configuration exacte (est-ce que
le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une
solution est de donner les droits complets à tout le monde sur le pipe. Si
on veut être quand même un poil sécurisé, le groupe "Authenticated Users"
peut être utile.
j'ai le problème suivant : j'ai deux PC en réseau sous Windows NT 4 avec deux applications qui doivent communiquer via un pipe nommé à travers le réseau. Je possède les sources de l'appli qui ouvre le pipe en tant que serveur, je peux les modifier.
J'ai d'abord fait un essai en utilisant le même domaine/utilisateur sur les deux PC : ça marche.
Deuxième essai avec deux utilisateurs différents : là ça ne marche plus, je suppose que c'est un problème de droits.
Je voudrais savoir où se situe le problème : est-ce au moment de la création du pipe nommé qu'il faut définir les paramètres de sécurité, ou bien dans les paramètres de configuration de Windows ? Auriez-vous un lien expliquant comment il faut faire ?
Le paramètre lpPipeAttributes de CreatePipe spécifie les droits d'accès au pipe. Si tu lui passes NULL, l'utilisateur courant (celui qui créé le pipe), le groupe local Adminstrateurs et le compe Système à tous les droits sur le pipe. Le compte "Everyone" a les droits en lecture uniquement.
Tous les détails sont là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
Question subsidiaire : si je veux en plus faire la même manip en utilisant cette fois des comptes locaux au lieu de comptes itinérants, est-ce que je vais avoir des problèmes supplémentaires ?
Un compte local n'étant valide et connu que sur une machine donnée, oui tu vas avoir des problèmes en fonction de ta configuration exacte (est-ce que le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une solution est de donner les droits complets à tout le monde sur le pipe. Si on veut être quand même un poil sécurisé, le groupe "Authenticated Users" peut être utile.
Arnaud MVP - VC
Frederic Phan
Arnaud Debaene a écrit :
Tous les détails sont là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
OK, merci beaucoup. J'ai passé pas mal de temps avant d'arriver à faire ce que je voulais, mais j'y suis arrivé.
Un compte local n'étant valide et connu que sur une machine donnée, oui tu vas avoir des problèmes en fonction de ta configuration exacte (est-ce que le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une solution est de donner les droits complets à tout le monde sur le pipe. Si on veut être quand même un poil sécurisé, le groupe "Authenticated Users" peut être utile.
Vu l'utilisation que je vais en faire, j'ai opté pour le plus simple : accès à tout le monde.
Encore Merci.
Frédéric
Arnaud Debaene a écrit :
Tous les détails sont là :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
OK, merci beaucoup. J'ai passé pas mal de temps avant d'arriver à faire
ce que je voulais, mais j'y suis arrivé.
Un compte local n'étant valide et connu que sur une machine donnée, oui tu
vas avoir des problèmes en fonction de ta configuration exacte (est-ce que
le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une
solution est de donner les droits complets à tout le monde sur le pipe. Si
on veut être quand même un poil sécurisé, le groupe "Authenticated Users"
peut être utile.
Vu l'utilisation que je vais en faire, j'ai opté pour le plus simple :
accès à tout le monde.
Tous les détails sont là : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/named_pipe_security_and_access_rights.asp
OK, merci beaucoup. J'ai passé pas mal de temps avant d'arriver à faire ce que je voulais, mais j'y suis arrivé.
Un compte local n'étant valide et connu que sur une machine donnée, oui tu vas avoir des problèmes en fonction de ta configuration exacte (est-ce que le client ouvre le pipe en lecture seule ou en lecture-écriture?) Une solution est de donner les droits complets à tout le monde sur le pipe. Si on veut être quand même un poil sécurisé, le groupe "Authenticated Users" peut être utile.
Vu l'utilisation que je vais en faire, j'ai opté pour le plus simple : accès à tout le monde.
