dilemme ! Optmiser la sécurité ou fonctionnalités

[Muahdib]

Bonjour à tous,

 

Sous les conseils d'un ami, beebop ( qui ne tari pas d'éloge sur les modérateurs et l'esprit de ce forum ), je viens à vous pour essayer d'apporter ma pierre à l'édifice concernant la sécurité sous windows ( vaste sujet ! ).

J'ai étudier ( autant que je l'ai pu ! ) les différents articles sur l'optimisation de la sécurité trouver sur zebulon, j'ai remarqué que la sécurisation d'un windows se faisait souvent au dépend des services et fonctionnalités proposé par le système, en gros on doit choisir de faire des sacrifices ! mais lorsqu'un service est indispensable et qu'il offre une vulnérabilité, on à pas trop le choix, sauf si on se casse la tête pour trouver un moyen de sécuriser le service ( par exemple restraindre sa portée ) CF: la restriction de l'écoute en local du service RPC.

Voila en gros le sujet dont j'aimerais que vous vous empariez afin de faire de la sécurité mais de façons peut être plus subtile que d'arrêter tel ou tel service ( j'espère que je ne m'embrouille pas trop dans mes explications et que vous voyez ou je souhaite en venir).

 

A ce propos j'ai une question qui concerne le service Workstation (lanmanworkstation), en fait lorsqu'il est arrêter, j'ai remarqué ( peut être vous aussi !) que la modification des comptes utilisateurs ( renommer un compte, voir ces propriétés ) n'était plus possible, j'ai consulter les services dépendant du service workstation et je n'ai rien remarqué concernant les comptes système, donc si quelqun à déja réfléchis au sujet et/ou à une explication à m'apporter je lui en serais reconnaissant.

J'ai d'autre question concernant le sujet dont je vous ai parler, mais je vais d'abord faire quelque test dans le cadre d'un réseaux local et d'une administration centralisé, c-a-d executer des commandes d'administration à distance ( ce qui m'interrêsserais c'est de limiter l'écoute du serveur RPC non pas à 127.0.0.1 mais à un réseaux local pour qu'il ne répondes qu'aux requêtes RPC d'ordinateur situé sur un réseau donné )

 

Voila !

Encore bravo pour votre esprit d'entraide et de partage des connaissances, j'espère pouvoir vous apportez autand que vous le ferez, bon courage et à bientôt.

 

PS : je suis désolé pour les fautes d'orthographe mais je me suis relus plusieurs fois mais je ne suis pas trés trés bon !

[le_facteur]

vaste sujet effectivement,

 

faut sans doute poser la question aux auteurs des articles du site

[ipl_001]

Bonjour Muahdib, le_facteur, bonjour à tous,

 

Je te souhaite la bienvenue sur Zeb'Sécurité ! Merci de venir sur notre forum !

 

Salut à BeeBop !

[Muahdib]

Bonjour Muahdib, le_facteur, bonjour à tous,

 

Je te souhaite la bienvenue sur Zeb'Sécurité ! Merci de venir sur notre forum !

 

Salut à BeeBop !

565464[/snapback]

Je n'y manquerais pas !

Merçi à vous, il y a longtemps que je cherchais le moyen de vraiment contrôler les ports ouverts de ma machine ( à la " main ") vous m'avez donnés des piste de recherche que je n'aurais jamais trouvé tout seul.

 

Je ferais de mon mieux pour être utile !

Bon surf

[Invité tesgaz]

salut,

 

quelques questions interessantes )

 

bon, je vais essayé de décortiquer tout ça, pas trés facile de tout expliquer en quelques mots :

 

J'ai étudier ( autant que je l'ai pu ! )  les différents articles sur l'optimisation de la sécurité trouver sur zebulon, j'ai remarqué que la sécurisation d'un windows se faisait souvent au dépend des services et fonctionnalités proposé par le système,  en gros on doit choisir de faire des sacrifices ! mais lorsqu'un service est indispensable et qu'il offre une vulnérabilité, on à pas trop le choix, sauf si on se casse la tête pour trouver un  moyen de sécuriser le service ( par exemple restraindre sa portée ) CF: la restriction de l'écoute en local du service RPC.

 

a) en gros, non, on ne fait pas trop de sacrifice, tout simplement parce que Windows livre par défaut un systeme avec beaucoup de services qui sont avant tout prévu pour travailler dans un domaine ou dans un reseau local, est-ce le cas de monsieur 'tout_le_monde' qui a juste un pc chez lui et sans réseau ?

non, bien sur, sur cet état de fait, on peut faire un constat :

-1 ) on peut desactiver ces services qui n'auront aucun intérêt et qui sont la cible privilégiées des malwares

(les services liés à RPC, Netbios, SMB, disributed transction coordination, Accès à distance au Registre, etc..)

- 2) 50% des autres services sont des fonctionnalités de confort, auquel on peut largement se passer (exemple, gravure de CD, horloge, centre de sécurité, clientDNS, telnet, webclient, etc..)

 

voila, on est sur les bases d'une sécurisation correcte, je n'ai pas mis tout les services, parce qu'au nombre de 90 environ, ca donne du boulot pour répondre

mais, qu'est ce qu'on peut retenir, c'est que la désactivation de nombreux services n'empèche pas de faire fonctionner correctement le systeme, qu'il est possible de réactiver un service des lors ou on en aurait le besoin, et surtout qu'on bouche des trous de sécurité archi connus, surtout de la part des fabricants de malwares et qui ne se gènent pas pour les exploiter (on le voit tout les jours ici)

 

b) alors, on a 2 solutions :

- on garde les services activés et dans ce cas, c'est le firewall (si bien paramétré) qui controlera les entrées/sorties des services en question (donc + de ressource pour gérer tout ca)

- on désactive ces services, et ainsi on allège le travail du firewall, on consomme moins de ressource CPU et on utilise moins de threads (donc, bilan positif en qualité de confort d'utilisation, et de sécurité)

 

 

 

A ce propos j'ai une question qui concerne le service Workstation (lanmanworkstation), en fait lorsqu'il est arrêter, j'ai remarqué ( peut être vous aussi !) que la modification des comptes utilisateurs ( renommer un compte, voir ces propriétés ) n'était plus possible, j'ai consulter les services dépendant du service workstation et je n'ai rien remarqué concernant les comptes système, donc si quelqun à déja réfléchis au sujet et/ou à une explication à m'apporter je lui en serais  reconnaissant.

- alors ce service fait parti des services que l'on doit conserver en automatique, puisque de nombreux services dépendent de lui :

- Affichage des messages

- Avertissement

- Explorateur d'ordinateur

- Localisateur d'appels de procédure distante RPC

- Ouverture de session réseau

mais si tout ces services cités sont déja désactivé, ce service n'a aucune incidence sur la gestion des comptes utilisateurs sur le pc (uniquement) donc, meme désactiver, cela n'empeche pas de creer un compte ou de le supprimer

mais par contre, il sera impossible d'ouvrir une session sur un réseau local si ce service est désactivé, normal, puisque service est comme son nom l'indique workstation

si tu ne peux pas faire fonctionner les options de gestion des comptes sur ton ordinateur en local uniquement

tu peux toujours tester dans une cmd :

net user toto /add (qui créer un compte utilisateur)

net user toto /active:no (desactive le compte)

 

pour un domaine, on lui prefere la commande : net use

pour un partage on utilise la commande : net share nom du partage /user: nombre | unlimited

etc..

 

regarde si ca fonctionne, mais laisse ce service en automatique si tu es en reseau et que tu veux faire du partage

 

 

J'ai d'autre question concernant le sujet dont je vous ai parler, mais je vais d'abord faire quelque test dans le cadre d'un réseaux local et d'une administration centralisé, c-a-d executer des commandes d'administration à distance ( ce qui m'interrêsserais c'est de limiter l'écoute du serveur RPC non pas à 127.0.0.1 mais à un réseaux local pour qu'il ne répondes qu'aux requêtes RPC d'ordinateur situé sur un réseau donné )

 

Alors, pour RPC, le fait qu'il écoute sur la boucle local n'empèche absolument pas le fonctionnement du reseau local, ni du reseau distant, ca n'a rien à voir

RPC pour fonctionner utilise des interfaces, les plus connues sont :

- Portmapper qui permet de connaitre l'emplacement où il est possible d'atteindre un service RPC repéré par un identifiant d'interface ( un numéro de port TCP ou UDP)

IRemoteActivation : service permet d'instancier des objets COM à distance (Component Objet Model)

IOXIDResolver : service de résolution des OXID (références à des objets COM)

seul le 1er est utilisé dans un réseau local, je ne vois pas l'intérêt de faire écouter RPC sur le reseau local ou meme sur un reseau distant, et cela ne l'empeche pas de fonctionner correctement

 

d'ailleurs à ce sujet, Windows a inventé un nouveau service pour protéger RPC qui se nomme DCOMLaunch, c'est lui qui autorise ou non que RPC travaille ou pas sur les requetes, mais le port 135 est toujours ouvert sur le 0.0.0.0 (donc, toujours vulnérable (pas aussi facilement qu'avant, mais quelques tests vont de ce sens de vulnérabilité)

 

donc, pour résumé, fermer le port 135 en le conservant uniquement en ecoute sur la boucle local est ce qui est le plus sécurisé (mieux que n'importe quel firewall)

 

pour le reste, il faut rester dans l'optique que Windows a toujours du mal à gérer le multi-taches au dela de 21 processus (qu'en on regarde les nombreux posts sur les problèmes de lenteur ou de bugs, on oublie souvent cette notion de multi-taches quelque soit la qualité du matériel employé, juste que si le pc est plus puissant, les soucis se verront moins)

 

la sécurité ne s'arrête pas qu'à la fermeture des services, elle est également indispensable dans la gestion de l'utilisation du systeme (autorisation ou restriction des programmes, des utilisateurs, des dossiers, etc..)

 

en espérant avoir répondu à tes questions

[Muahdib]

Bonjour à tous et merci à tegaz d'avoir pris le temps de répondre aussi exaustivement et rapidement.

 

 

salut,

 

quelques questions interessantes )

 

bon, je vais essayé de décortiquer tout ça, pas trés facile de tout expliquer en quelques mots :

a) en gros, non, on ne fait pas trop de sacrifice, tout simplement parce que Windows livre par défaut un systeme avec beaucoup de services qui sont avant tout prévu pour travailler dans un domaine ou dans un reseau local, est-ce le cas de monsieur 'tout_le_monde' qui a juste un pc chez lui et sans réseau ?

 

Si je peux me permettre, c'est de plus en plus le cas, avec les connexions haut débit, et les prix des matériels toujours à la baisse, le recyclage de nos vieille békane introduit les réseaux locaux de plus en plus chez le particulier ( peut être pas Monsieur tout le monde, mais tout ceux qui ont au moind 2 PC ont essayé de les relier entre eux ( au minimum avec un câble croisé ), sans parler des routeur sans fils qui se démocratise de plus en plus.

C'est dans ce contexte que j'abordais la sécurité et les services réseaux disponibles sous windows.

 

non, bien sur, sur cet état de fait, on peut faire un constat :

-1 ) on peut desactiver ces services qui n'auront aucun intérêt et qui sont la cible privilégiées des malwares

(les services liés à RPC, Netbios, SMB, disributed transction coordination, Accès à distance au Registre, etc..)

- 2) 50% des autres services sont des fonctionnalités de confort, auquel on peut largement se passer (exemple, gravure de CD, horloge, centre de sécurité, clientDNS, telnet, webclient, etc..)

 

Evidement je suis d'accord pour dire qu'il y a beaucoup de service qui ne sont pas indispensable ( gravure CD, asssitance à distance, insertion automatique etc...), qui sont la pour le confort et dont on peut se passer par contre je ne vois pas comment se passer du Client DNS lorsque l'on veut faire de l'internet, ou de SMB pour faire du partage de fichier ( et même entre linux/windows, SMB c'est bien )

 

voila, on est sur les bases d'une sécurisation correcte, je n'ai pas mis tout les services, parce qu'au nombre de 90 environ, ca donne du boulot pour répondre

mais, qu'est ce qu'on peut retenir, c'est que la désactivation de nombreux services n'empèche pas de faire fonctionner correctement le systeme, qu'il est possible de réactiver un service des lors ou on en aurait le besoin, et surtout qu'on bouche des trous de sécurité archi connus, surtout de la part des fabricants de malwares et qui ne se gènent pas pour les exploiter (on le voit tout les jours ici)

Encore une fois je suis d'accord mais, lorsqu'on en a besoin ( exemple : partage de fichier entre 2 PC ) on se trouve face à un dilemme, il est assez simple d'arrêter ou de désactiver un service qui constitue une vulnérabilité pour moi le défis est de faire fonctionner le service, pour ces besoins tout en le sécurisant ( c'est la que je voulais en venir dans le sujet )

b) alors, on a 2 solutions :

- on garde les services activés et dans ce cas, c'est le firewall (si bien paramétré) qui controlera les entrées/sorties des services en question (donc + de ressource pour gérer tout ca)

- on désactive ces services, et ainsi on allège le travail du firewall, on consomme moins de ressource CPU et on utilise moins de threads (donc, bilan positif en qualité de confort d'utilisation, et de sécurité)

- alors ce service fait parti des services que l'on doit conserver en automatique, puisque de nombreux services dépendent de lui :

- Affichage des messages

- Avertissement

- Explorateur d'ordinateur

- Localisateur d'appels de procédure distante RPC

- Ouverture de session réseau

mais si tout ces services cités sont déja désactivé, ce service n'a aucune incidence sur la gestion des comptes utilisateurs sur le pc

 

Tu as raison, moins il y a de processus lancé en mémoire et plus tu as de ressource disponible pour les appli. utilisateur, mais honnêtement avec les Ram disponible actuellement ( même les config de base propose 512 Mo en standart maintenant ! )

Je me suis mal exprimer à propos du service station de travail, petit rappel, ce service est installé, lorsque dans les propriétés réseaux ont installe le service Client pour les réseaux microsoft ( si on désintalle ce service dans les propriértés réseaux, le service station de travail n'apparaît même pas dans la console des services ) et c'est dans le cas de cette configuration que, lorsque l'on souhaite modifier un compte utilisateur du sytème, il nous répond que le service station de travail doit être lancé, je suppose que si l'on le désactive cela doit faire pareil, aprés on peut toujours le lancé à la main, faire ces modif. et ensuite l'arrêter, je suis d'accord et de toute façon c'est comme ça que je procède aussi mais pour ma part je ne trouve pas cette solution entièrement satisfaisante.

(uniquement) donc, meme désactiver, cela n'empeche pas de creer un compte ou de le supprimer

As tu essayé de modifier un compte sans le service Station de travail

mais par contre,  il sera impossible d'ouvrir une session sur un réseau local si ce service est désactivé, normal, puisque service est comme son nom l'indique workstation

si tu ne peux pas faire fonctionner les options de gestion des comptes sur ton ordinateur en local uniquement

Pas de problème quand le service station de travail peut se lancer !

tu peux toujours tester dans une cmd :

net user toto /add (qui créer un compte utilisateur)

net user toto /active:no (desactive le compte)

 

pour un domaine, on lui prefere la commande : net use

pour un partage on utilise la commande : net share nom du partage /user: nombre | unlimited

etc..

je n'est pas essayé dans le Dos avec la commande net user ( à voir éventuellement ), pour intervenir sur un compte du domaine, c'est net user aussi avec l'option /domain, ( net use c'est pour utiliser un partage ) j'ai déja utiliser cette procédure pour gérer les comptes d'un domaine en automatisant même les procèdure de modification grâce à un fichier .bat mais je préfère la commande adduser ( du kit de ressource technique ).

 

regarde si ca fonctionne, mais laisse ce service en automatique si tu es en reseau et que tu veux faire du partage

Alors, pour RPC, le fait qu'il écoute sur la boucle local n'empèche absolument pas le fonctionnement du reseau local, ni du reseau distant, ca n'a rien à voir

RPC pour fonctionner utilise des interfaces, les plus connues sont :

- Portmapper qui permet de connaitre l'emplacement où il est possible d'atteindre un service RPC repéré par un identifiant d'interface ( un numéro de port TCP ou UDP)

IRemoteActivation : service permet d'instancier des objets COM à distance (Component Objet Model)

IOXIDResolver : service de résolution des OXID (références à des objets COM)

seul le 1er est utilisé dans un réseau local, je ne vois pas l'intérêt de faire écouter RPC sur le reseau local ou meme sur un reseau distant, et cela ne l'empeche pas de fonctionner correctement

D'accord, mais j'avais cru comprendre que par défaut RPC acceptais toutes les connexion 0.0.0.0:0 quel que soit l'adresse IP sourcedu client qui se connecte et qu'en appliquant les modification sur la base de registre on pouvais lui dire de n'accepter que les requêtes RPC émanant du localhost lui même.

Toujours dans le contexte d'un réseaux local, lorsque l'on souhaite executer une commande à distance ( genre toute les commandes Remote, comme Rkill ou shutdown pour tuer un processus sur une machine distante ou carrément l'arrêter, c'est le service RPC du poste sur lequel on se connecte qui va executer la commande , donc si le service n'accepte que les connexion 127.0.0.1, normalement il ne devrais pas accepter l'exécution d'une commande lancé depuis un autre poste du réseau, d'ou l'intérêt d'autoriser par exemple tout un sous réseau.

Sécuriser ( pas d'écoute sur 0.0.0.0:0 pas assez restrictif ! ) mais afin de permettre une administration à distance de tes postes ( autoriser l'écoute juste sur la classe utilisé dans ton réseau local )

d'ailleurs à ce sujet, Windows a inventé un nouveau service pour protéger RPC qui se nomme DCOMLaunch, c'est lui qui autorise ou non que RPC travaille ou pas sur les requetes, mais le port 135 est toujours ouvert sur le 0.0.0.0 (donc, toujours vulnérable (pas aussi facilement qu'avant, mais quelques tests vont de ce sens de vulnérabilité)

 

donc, pour résumé, fermer le port 135 en le conservant uniquement en ecoute sur la boucle local est ce qui est le plus sécurisé (mieux que n'importe quel firewall)

 

pour le reste, il faut rester dans l'optique que Windows a toujours du mal à gérer le multi-taches au dela de 21 processus (qu'en on regarde les nombreux posts sur les problèmes de lenteur ou de bugs, on oublie souvent cette notion de multi-taches quelque soit la qualité du matériel employé, juste que si le pc est plus puissant, les soucis se verront moins)

 

la sécurité ne s'arrête pas qu'à la fermeture des services, elle est également indispensable dans la gestion de l'utilisation du systeme (autorisation ou restriction des programmes, des utilisateurs, des dossiers, etc..)

 

en espérant avoir répondu à tes questions

565542[/snapback]

 

Tout à fait d'accord avec toi,

merci pour tes réponses,

c'est confrontant son point de vue qu'on le fait avancer,

Tout ce que je souhaite c'est participer au débat sans arrière penser par contre je m'efforcerais de préciser dans quel contexte je me place, administration réseau, ou configuration en monoposte connecter à un internet.

Bon courage à tous...

[Beebop]

Bonjour Muahdib, Tesgaz, Ipl, bonjour à tous,

 

Extrèmement intéressant tout ça !

 

A suivre.......

 

Salut Moumou , merci de ta visite !

[Invité tesgaz]

re à tous,

 

Toujours dans le contexte d'un réseaux local, lorsque l'on souhaite executer une commande à distance ( genre toute les commandes Remote, comme Rkill ou shutdown pour tuer un processus sur une machine distante ou carrément l'arrêter, c'est le service RPC du poste sur lequel on se connecte qui va executer la commande , donc si le service n'accepte que les connexion 127.0.0.1, normalement il ne devrais pas accepter l'exécution d'une commande lancé depuis un autre poste du réseau, d'ou l'intérêt d'autoriser par exemple tout un sous réseau.

 

en fait ca ne fonctionne pas comme tu l'imagines , je vais essayer d'être le plus clair et simple possible

 

Remote procedure call (RPC) c'est le dispacheur, il fonctionne un peu comme un centre de tri postal, c'est lui qui décide quand un paquet arrive sur ton pc, vers quel service ou programme il doit l'envoyer et sur quel protocole et port de connexion il va établir la connexion.

 

que RPC fonctionne sur la boucle local sert uniquement à le sécurisé comme dit plus haut, rien n'empèche d'utiliser des commandes reseau qui elle-mêmes utiliseront un service ou un programme ouvert et autorisé par ton firewall

 

RPC n'a besoin d'aucune aide exterieure à la boucle locale pour savoir quel port il va ouvrir, puisque les port sont attribués en fonction des services jusqu'a 1024 (c'est identique sur tout les pcs puisque qu'attribuer par les RFC ) et les autres ports sont ouverts aléatoirement au(dela de 1024 jusqu'a 65535)

 

As tu essayé de modifier un compte sans le service Station de travail

oui, et ca fonctionne parfaitement, j'ai fais ce tuto avec le service désactivé :

http://speedweb1.free.fr/frames2.php?page=bureau5

 

 

Evidement je suis d'accord pour dire qu'il y a beaucoup de service qui ne sont pas indispensable ( gravure CD, asssitance à distance, insertion automatique etc...), qui sont la pour le confort et dont on peut se passer par contre je ne vois pas comment se passer du Client DNS lorsque l'on veut faire de l'internet, ou de SMB pour faire du partage de fichier ( et même entre linux/windows, SMB c'est bien )

 

oui, mais sans connâitre ton réseau, je suis incapable de te donner des indications précises sur la fermeture de ces services, le client DNS ne sert à rien en reseau local, bon, maintenant certain FAI utilise ce service en dégroupé, c'est pour cela qu'il faut être prudent dans une config personnel parce ce qui sera valable pour toi, ne le sera pas forcement pour ton voisin

 

bon, si tu veux en savoir plus, avec ton reseau, donnes plus de détails sur tes configs, les serveur, etc..

je verrai si je peux t'aider dans ce que tu recherches

[Muahdib]

re à tous,

en fait ca ne fonctionne pas comme tu l'imagines , je vais essayer d'être le plus clair et simple possible

 

Remote procedure call (RPC) c'est le dispacheur, il fonctionne un peu comme un centre de tri postal, c'est lui qui décide quand un paquet arrive sur ton pc, vers quel service ou programme il doit l'envoyer et sur quel protocole et port de connexion il va établir la connexion.

 

que RPC fonctionne sur la boucle local sert uniquement à le sécurisé comme dit plus haut, rien n'empèche d'utiliser des commandes reseau qui elle-mêmes utiliseront un service ou un programme ouvert et autorisé par ton firewall

 

RPC n'a besoin d'aucune aide exterieure à la boucle locale pour savoir quel port il va ouvrir, puisque les port sont attribués en fonction des services jusqu'a 1024 (c'est identique sur tout les pcs puisque qu'attribuer par les RFC ) et les autres ports sont ouverts aléatoirement au (dela de 1024 jusqu'a 65535)

oui, et ca fonctionne parfaitement, j'ai fais ce tuto avec le service désactivé :

http://speedweb1.free.fr/frames2.php?page=bureau5

oui, mais sans connâitre ton réseau, je suis incapable de te donner des indications précises sur la fermeture de ces services, le client DNS ne sert à rien en reseau local, bon, maintenant certain FAI utilise ce service en dégroupé, c'est pour cela qu'il faut être prudent dans une config personnel parce ce qui sera valable pour toi, ne le sera pas forcement pour ton voisin

 

bon, si tu veux en savoir plus, avec ton reseau, donnes plus de détails sur tes configs, les serveur, etc..

je verrai si je peux t'aider dans ce que tu recherches

565955[/snapback]

 

Ben je pensais que sécuriser RPC comme indiquer dans le tuto, s'étais justement qu'il ne soit plus en écoute sur tcp 0.0.0.0:0 donc qu'il accepte n'importe quel connexion distante mais plutôt qu'il écoute sur 127.0.0.1 et à ce moment la pour moi le service ne répondras pas aux requête provenant d'autre PC autre que lui même (127.0.0.1=localhost)

Je suis désolé si j'ai du mal mais j'ai vraiment envie de comprendre,

dans le cadre de mon boulot, on est dans un réseau local ethernet 100 MB/s, les postes sont connecter à un switch lui même est cascadé sur un routeur cisco ( gigabit ) plusieur site relié entre eux par de la fibre optique.

Par exemple sur un segment du réseau, tout ce qui raccordé au switch, je voudrais à partir d'un poste faire de l'administration réseaux ( c'est ce que je fait ) surveiller les processus qui tourne sur mes postes clients, parfois copier des fichier dessus, uitliser les commandes Remote: rkill et shtudown ne sont que 2 exemples et j'ai observé par rapport à RPC que sur certain poste client, les commandes d'administration à distance ( rien d 'exotique tout viens du kit de ressource technique 2000) ne fonctionnais pas, avec comme justification, le service RPC distant n'a pas répondus ( tu interprète ça comment ?) les poste clients sont sous 2000 pro SP4 avec toute les mises à jour, le poste d'administration est en 2000 pro tout ça dans le même domaine et bien entendus pour l'administration distante j'utilise un compte ayant des droit administrateur.

déja sous XP si pas de DNScache, pas de connexion possible avec le contrôleur de domain ça c'est vérifié et sûr et certain ( j'ai pas mal gallérer à comprendre pourquoi je ne pouvais pas voir dans active directory les objets du domain à partir de poste client mal configurer, c'est à dire serveur DNS interne non renseigné.

Je sais que cela fait beaucoup d'info mais ne te casse pas trop la tête de toute les façon je faire des tests :

désactivé certain services et tester si j'arrive à faire ce que je veux....dans tout les cas merci d'essayer de m'aider,

[Invité tesgaz]

le service RPC distant n'a pas répondus ( tu interprète ça comment ?)

 

je l'interprete que RPC gère à lui seul une cinquantaine de services, donc, ce n'est obligatoirement "Appel de procédure distante" qui peut être en cause