Bonjour,

Je suis en pleine migration de notre ancien serveur nt4 vers le nouveau 2003 server.

Je passe sur chaque poste migrer le compte local sur un compte de domaine, et jusqu'ici tout se passe à peu près bien.

Sauf cette aprem où je constate par hasard que le pare feu du serveur n'était pas activé. Je rectifie le tir et instantanément ou presque je constate que des utilisateurs ne parviennent plus à accéder à leur lecteurs réseaux. Je vais voir, je teste je ferme leur session je les reloggue : l'ouverture de session ne se fait plus. Je désactive le pare feu du serveur, et là tout rentre dans l'ordre.

Y a-t-il des exceptions à mettre dans le pare feu windows afin que celui-ci ne bloque pas l'identification au moment de l'ouverture de session ? cela me parait étrange tout de même que le pare feu bloque un traffic réseau tout ce qui a de plus essentiel. Il n'y a aucun paramétrage particulier au niveau du pare feu je n'y ai pas touché.

Quelqu'un a une idée ? je ne voudrai pas laisser le serveur sans protection, vous comprendrez que c'est assez urgent !!

Merci de vos conseils

Le pare-feu de windows se comporte comme tout pare-feu normalement constitué : par défaut il bloque tout au moins en entrant, ce qui est "tout ce qui a de plus essentiel" pour les uns peut-etre un enorme trou potentiel pour les autres, et pour la plupart des admins un pare-feu qui ouvrirait de sa propre autorité et sans prévenir certains flux serait totalement inacceptable.
Si tu maitrises pas bien tout ça, Windows 2003 vient avec un assitant de configuration de la sécurité permettant en autre de paramétrer le firewall a minima pour ce que tu fais sur ton serveur : http://technet.microsoft.com/en-us [...] 84874.aspx

Merci pour ta réponse Pollo.
 
Je n'ai pas encore eu le temps de tester l'assistant mais j'avais trouvé ce lien qui donnait les ports à ouvrir dans le cas d'ouverture de session sur le domaine.
 
User Login and Authentication
A user network logon across a firewall uses the following:
• Microsoft-DS traffic (445/tcp, 445/udp)
• Kerberos authentication protocol (88/tcp, 88/udp)
• Lightweight Directory Access Protocol (LDAP) ping (389/udp)
• Domain Name System (DNS) (53/tcp, 53/udp)
 
 
Computer Login and Authentication
A computer logon to a domain controller uses the following:
• Microsoft-DS traffic (445/tcp, 445/udp)
• Kerberos authentication protocol (88/tcp, 88/udp)
• LDAP ping (389/udp)
• DNS (53/tcp, 53/udp)
 
Je retrouve également souvent une précision sur le fait de "fixer" le port RCP en modifiant une clef dans la base de registre mais je n'ai pas très bien saisi pourquoi il fallait le faire.

Il faut donc fixer deux numéros de port réseau (normalement aléatoire) dédiés à la réplication du catalogue entre différents serveurs 2003.

Cette fixation des ports se fait au niveau de la base de registre mais dans mon cas je n'en ai pas besoin. J'ai donc ouvert les différents ports ci-dessus avec en plus le port 123 pour le serveur de temps et là mes clients se logguent immédiatement et apparemment sans soucis.

Par contre, je ne comprends pas pourquoi lorsque je ping le serveur celui-i me répond, je pensais que par mesure de sécurité, le serveur ne répondait pas. Quel est le port éventuellement à bloquer pour masquer la présence du serveur sur le réseau ? et y a-t-il des inconvénients ?

L'ICMP (protocole du ping) est géré a part dans le pare-feu de XP/2003, dans les propriétés du part feu dans l'onglet avancé, et de base les réponses au paquet entrant sont activées.
Niveau sécu y'a franchement pas grand interet sur un LAN a desactiver ça completement, c'est vraiment pas ça qui va cacher ton serveur, les paramètres par défaut du pare-feu sont déjà durcis (ça limite vraiment a du ping de base) et pouvoir pinguer son serveur ben ça reste quand meme utile. Et il me semble de toutes façon qui si t'ouvres certains autres ports lié a l'AD (ou au partage de fichier je sais plus ) le ping est toujours autorisé par le pare-feu.

OK d'accord merci pour les précisions que tu apportes El pollo :-)

pareil a mon avis filtrer l'icmp sur un domaine c'est moyen...