l'Ipcop, le Wifi et l'Active Directory...

[lereg]

Bonjour bonjour....

Je viens de mettre en place un active directory sur un petit reseau d'une dizaine de machines.
Le controleur est bien evidemment sur green. Les machines de green peuvent (re)joindre
ce domaine sans souci.

En revanche, les machine sur blue (wifi) ne le peuvent pas. (Le domaine xxxx est introuvable)

La config est la suivante :

192.168.0.1 -> Ipcop Green
192.168.20.1 -> Ipcop Blue
192.168.0.5 -> Domain Controler
192.168.20.2 -> Wifi Access Point (directement relié a l'interface blue de l'ipcop)

Toutes les machines green (DC y compris) sont sur le meme switch

Niveau firewall, onglet acces dmz, j'ai autorisé la machine de test sur blue (192.168.20.7) a acceder
au domain controler (192.168.0.5) sur tous les ports en TCP et UDP. Ce qui ne change rien.
Cette meme machine de test connectée sur green via une carte ethernet et avec une ip green
peut rejoindre le domaine.

Via le voisinnage reseau, les machines green se voient toutes (y compris le DC).

Evidemment, la machine de test une fois repassée en wifi, sur blue donc, ne voit qu'elle, via
le voisinnage reseau toujours.

Le DC est pingable depuis le wifi, et on peut y acceder a la machine via netbios par exemple.
(\\192.168.0.5...)

Le port 445 est il me semble abondemment utilise par AD. Serait t'il bloqué quelque part sur l'ipcop
a mon insu ? hmmm ???

Si quelqu'un peut m'eclairer, je continue de chercher de mon cote...!

Merci d'avance !

[loberty]

Bonsoir,

Je ne vais pas t"éclairer mais te donner des pistes.
Au cas où...

1. As tu vérifié que ton Wifi Access Point ne bloque rien ?
2. As tu regardé les logs de IPCOP côté paquets ?
3. As tu fais un sniffage de tes connexions côté blue, côté green pour voir ce qui se passe en comprenant avec une connexion directe sur GREEN ?
4. Je ne connaîs que très peu AD, mais n'y aurait il pas un moyen de définir quelle plage d'adresse à droite de se connecter au domaine, et donc tu serais en dehors de cette plage ?

Si cela peux t'aider.

A+

[lereg]

Merci pour les pistes ! Mais je sens que tu vas devoir m'eclairer d'avantage si tu veux bien

2. As tu regardé les logs de IPCOP côté paquets ?

Je dois avouer que je ne suis pas un specialiste de la chose...je suppose que cela doit se trouver
dans un /etc quelque chose mais...ou exactement ?

3. As tu fais un sniffage de tes connexions côté blue, côté green pour voir ce qui se passe en comprenant avec une connexion directe sur GREEN ?

Meme chose Je veux bien sniffer tant qu'on veut, mais dois utiliser un outil externe ? des noms ?

4. Je ne connaîs que très peu AD, mais n'y aurait il pas un moyen de définir quelle plage d'adresse à droite de se connecter au domaine, et donc tu serais en dehors de cette plage ?

Je verifie de ce pas....

Merci encore, et merci d'avance pour les eclaircissements

[loberty]

Bonsoir,

Ravi de t'aider.

Pour voir les logs c'est dans l'interface HTML d'IPCOP dans la partie JOURNAUX.
Pour sniffer, il existe de nombreux soft, moi j'utilise ethereal (http://www.ethereal.com/).

En fait, le but est de bien comprendre ce qui se passe entre l'AD ou le pc client.
Donc je te conseille de sniffer une connexion qui fonctionne.
Regarde ce que cela donne au niveau des échanges (ports utilisés, qui initie quoi).
Ensuite sniffes de nouveau sur la connexion qui échoue. peux être pourras alors tu voir ce qui se passe.

Encore une chose.
Tu as indiqué que les connexions BLUE => GREEN du type \\192.168.0.5 fonctionnent.
Mais la résolution de noms ?
Lorsque tu vas sur un AD, si ton PC client y accède par le nom cela peux ne pas fonctionner depuis ton PC une fois en blue.
Ta station en BLUE elle a bien un WINS ?

A+

[Mister-Magoo]

Bonjour bonjour....
Le port 445 est il me semble abondemment utilise par AD. Serait t'il bloqué quelque part sur l'ipcop
a mon insu ? hmmm ???
Merci d'avance !

Le 445 est utilisé par IPCop pour l'interface graphique (serveur Web).
Or, d'une façon générale, Windows n'aime pas beaucoup que ce port soit utilisé par autre chose que lui-même

Sous Linux ou OSX, pas de problème, mais Windows n'aime pas du tout.
Tu devrais changer ce port par défaut par un autre, cela pourait t'éviter des conflits éventuels. Pour ce faire, regardes dans le post des Newbies en haut du forum

[lereg]

Quelque chose m'etonne tout de meme [Loberty] ...

Une machine XP Family (donc hors domaine et pour cause) sur bleu peut joindre sans probleme
le serveur AD en netbios (soit via l'ip soit via son nom dns)

La machine de test, celle qui est jointe au domaine ne le peut en revanche pas, meme si l'on
se logue en local sur cette derniere...

Etonnant non ?

[Mr Magoo]

Idem en modifiant le port HTTP de l'ipcop.

J'ai bien la resolution de nom en revanche sur la machine de test blue. mais ca ne change pas grand
chose a vrai dire

Bon, j'y retourne....!

[loberty]

Bonjour,

Tes dernières remarques me laisses perplexe.
L'énoncé du problème est-il le bon ?

Ta station qui est en BLUE et n'arrive pas à accéder à AD c'est quoi comme OS ?
Ton problème survient lors de la mise en domaine ou lorsque tu tentes de te logguer dans le domaine ?
Si j'ai bien compris la station est dans le domaine mais impossible d'y ouvrir une session...

Tu as regardé avec un sniffage ?

As tu essayé de mettre une autre station dans blue et de faire le test juste pour voir si cela n'est pas un problème propre à l'autre station.

A+

[lereg]

> Tes dernières remarques me laisses perplexe.
> L'énoncé du problème est-il le bon ?

Je me suis peut etre mal exprimé... la remarque concernant la machine xp home n'avait
rien n'a voir avec l'AD puisque c'etait un acces sous netbios. Je m'etonnais que le 2K ne puisse
plus faire de meme depuis qu'il avait ete "enregistré" sur le domaine.
("Pas de serveurs d'identification disponibles...")

Ta station qui est en BLUE et n'arrive pas à accéder à AD c'est quoi comme OS ?

2KPro/uk

> Ton problème survient lors de la mise en domaine ou lorsque tu tentes de te logguer dans le domaine ?

Impossible de contacter le domaine depuis blue. Ni pour "enregistrer" la machine dessus, ni pour se
logguer ensuite.

> Si j'ai bien compris la station est dans le domaine mais impossible d'y ouvrir une session...

Tout a fait. Enregistree via green et un superbe cable rj45. Mais via blue, rien a faire.

> Tu as regardé avec un sniffage ?

Suivant tes conseils, j'ai donc installé ethereal sur deux machines : celle en 2k et une en xp home
qui peut acceder au DC via netbios (comme cité precedemment)
L'acces depuis le XP home me donne 5 ou 6 lignes alors que l'acces depuis la 2k ne me donne qu'une
ligne qui a priori est un query vers le dns et point barre : une ligne only.

Je vais te poster ces lignes des que j'ai acces aux machines

> As tu essayé de mettre une autre station dans blue et de faire le test juste pour voir si cela n'est pas > un problème propre à l'autre station.

Je manque un peu de client potentiels a ce niveau malheureusement...

[loberty]

Si avec le 2000 tu as une seule ligne qui est du DNS, est-ce que le 2000 à reçu une réponse à sa requête DNS ?
Si oui qui à donné la réponse ?

2 possibilités :
. pas de dns disponible pour le 2000, donc il fait une requête et n'a pas de réponse
. le dns qui répond au 2000 ne connaît pas le AD

A+

[lereg]

concernant la possibilite numero 2 (qui annule la numero 1

Le controleur AD est lui meme DNS (avec redirecteur sur l'ipcop puisqu'il n'est pas question qu'il
s'occupe d'autre chose que de son domaine : dans les faits, s'il ne peut resoudre une requete, il passe
la main a l'ipcop, ce qui est le cas pour internet ou les machines en dns statique dudit ipcop)

Donc la station 2K contacte bien le dns de l'AD. Enfin en theorie. D'apres ce que j'ai compris
de ce qu'ethereal m'a annonce, la connexion semble se faire, mais il ne passe rien apres.

Il faut vraimment que je te poste les lignes en question...je vais le faire tout de suite...

[lereg]

Voici qui se passe lorsque j'essaie d'atteindre le serveur 192.168.0.5 via netbios (\\192.168.0.5)

Cote windows station, messagebox qui me dit que :

192.168.0.5 is not accessible

There are currently no logon servers available to service the logon request

Cote Ethereal, j'ai maintenant un bon paquet de données...lorsque j'exporte...

Trop sans doute pour les poster ici...je me permets de te les envoyer en prive !

Merci encore

[Kali Mero]

sur le même type d'install, jai exactement le même problème !

J'ai "résolu" (si on peut dire) provisoirement ce Pb en insérant les lignes suivantes :

/sbin/iptables -D FORWARD -p all -s X.X.0.0/12 -o eth0 -j ACCEPT
/sbin/iptables -I FORWARD -p all -s X.X.0.0/12 -o eth0 -j ACCEPT

echo "Bringing network up" (Lignes déjà existantes)
. /etc/rc.d/rc.netaddress.up

à la fin de : /etc/rc.d/rc.network

où : X.X.0.0/12 est mon réseau BLEU et eth0 la carte réseau VERT


J'ai fais cette bidouille après avoir lu quelques post sur ce sujet et avec mes faibles connaissances d'Iptables.
J'annule tout d'abord la règle pour ne pas l'avoir en double ????? ligne 1 (est-ce necessaire ?)
puis j'installe la règle (qui il me semble est un by-pass) LA SECURITE DOIT EN PRENDRE UN COUP !!

Cette mauvaise rustine fonctionne, mais il faut rebooter à chaque modification sur les accès Bleu ou DMZ

Si cela peut donner une idée et faire avancer le SMILBLICK (C) je suis preneur d'une solution PROPRE !

MERCI et bravo à l'équipe IPCOP pour leur réalisation.

[Kali Mero]

En effectuant quelques tests et de nombreux redémarrages d'IPCop (non modifiée), j'ai constaté que lors de l'initialisation (après un reboot), apparaissait l'erreur suivante :

------
------
------ (paquet de lignes "inintéressantes")
setting up IP Accounting
Setting IPCOP DMZ pinholes
/etc/rc.d/rc.network: line 74: xxxx Segmentation fault /usr/local/bin/setdmzholes
Setting up wireless firewall rules
Bringing network up
------
------
------

ou xxxx est un nombre à chaque fois différent.


Cela est-il normal ???
quelqu'un d'autre a-t-il la même chose ?
Cela a-t-il une influence sur le fait que l'on ne puisse joindre le réseau VERT depuis le BLEU en utilisant "ACCES A LA DMZ" ?

[Kali Mero]

Personne n' a constaté cette erreur ?

Si je suis le seul, quelqu'un a-t-il une idée sur son origine ?

Merci

[Franck78]

Salut,

setdmzholes lit le fichier de données "/var/ipcop/dmzholes/config".
Il y a de grande chance que celui ci soit vérolé ou contienne une combinaison de valeurs qui le fait planter...


Publies donc le contenu de ce fichier, que l'on puisse voir ce qui cause le segfault.
Ensuites efface son contenu avec un editeur (sans l'effacer sinon note avant les droits/perms).

Comme setdmzholes est 'suid root' il n'est pas géner par des droits qui auraient changé.



Bye