Newsgroup: it.comp.reti.ip-admin
Titolo: Informazioni su Active Directory

Buongiorno,
scusate non so se sia il gruppo appropriato per questo tipo di
messaggio, comunque, al lavoro, abbiamo un server windows 2003 che ci
fa da active directory con DNS e DHCP, ora, siccome abbiamo installato
un nuovo firewall IPCOP vorremmo poter utilizzare i DNS e DHCP di
quest'ultimo. Leggendo la documentazione a riguardo Active Directory,
sembra che questo servizio richieda DNS e DHCP per funzionare. Ci
chiedevamo se fosse possibile "dirottare" il DNS ed il DHCP sul
firewall senza compromettere l'active directory, disabilitando questi
due servizi sul server windows 2003.
Grazie per le risposte e i consigli,
-- 
*Gianluca Francesco Signorotto*
Pubblic key = 
http://snipr.com/218nj

  due servizi sul server windows 2003.
No, il dns per AD e' *indispensabile*. Al limite, puoi impostare i
forwarders del server dns di 2k3 in modo che punti al dns di ipcop.
Se poi il dhcp di windows 2003 aggiorna le zone dns, potrebbe
aggiungersi il problema di configurare il dns di 2003 e il dhcp
di ipcop per l'aggiornamento dinamico delle zone.
Una domanda: perche' vorresti fare tutto cio'? Oltreutto, laddove
possibile e/o opportuno, e' meglio che il firewall... faccia solo
da firewall.
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 e' meglio che il firewall... faccia solo da firewall.
quoto al 100%; IPCop va benone in un ambiente SoHo con pochi clients
e/o senza un "dominio" AD, ma nella situazione in esame non credo sia
una scelta appropriata; a questo punto, meglio, MOLTO meglio utilizzare
m0n0wall o, volendo restare in ambito Microsoft, ISA Server

 da firewall.
Intanto vi ringrazio per le risposte che mi avete dato. Il fatto è che
vorremmo attivare le funzionalità di prova e url-filtering di IPCOP.
Il problema è che anche se configuriamo l'url-filtering, questo non
funziona a dovere, nel senso che sembra non filtri nulla. Per il proxi
siamo in alto mare e pensavamo, appunto che siccome il DNS e DHCP per
i client è il server AD, allora questa cosa bypassasse le impostazioni
di IPCOP... ci sembra molto strano in effetti, dato che per la nostra
rete locale il Gateway è, appunto, IPCOP.
Non è che sareste così gentili da darmi ancora delle dritte?
Grazie molte,


 vorremmo attivare le funzionalità di prova e url-filtering di IPCOP.
					^^^^
proxi


> proxi
proxy
:)

 proxy
gia' :-)


 portare avanti la risoluzione in maniera ricorsiva;
Mah, non sono d'accordo: interrogare i root server ogni volta
che bisogna risolvere un dominio esterno rallenta notevolmente
il tutto.


 il tutto.
caching e deleghe, questi sconosciuti

 
Anche io uso IpCop, ma i client utilizzano esclusivamente il DNS interno 
(replicato su due DC). Questo è configurato in modo da forwardare le 
query con esito negativo verso il DNS di IpCop, che a sua volta è stato 
configurato con i DNS esterni del nostro provider (che discorso contorto 
=D )
Per quanto riguarda il DHCP, è configurato 80-20 su un DC e IpCop.
Parlando di IpCop, io mi trovo molto molto bene. Ho provato pfsense, ma 
lavorare con BSD e non con Linux era uno stress continuo, specialmente 
in caso di emergenza.
Utilizzo le seguenti funzioni:
- Proxy (con gli addon advanced proxy e urlfilter)
- OpenVPN (con l'addon zerina)
- traffic shaping e qos (con gli addon layer7, p2pblock, qos_ng e msnlogger)
- ntop, per controllare in 3 secondi netti chi sta utilizzando la banda 
e con cosa (emule, http, posta etc...)
e altre cose che ora non ricordo
L'unica pecca è che nei progetti degli sviluppatori non ci sia, a breve 
termine, il supporto di più wan contemporaneamente, facendo cadere il 
progetto nell'area SOHO :((

Skull ha scritto:


Ah, deleghe non so, non arrivo a queste conoscienze riguardo il dns,
per cio' che riguarda il catching ok, ma non mi ha mai portato
chissa' quale beneficio...


 chissa' quale beneficio...
...rispetto al catching dei dns dei provider, che suppongo "tenga"
qualcosina in piu' rispetto alla cache del dns locale.


 chissa' quale beneficio...
Dipende da dove cerchi i vantaggi e come li "pesi"...
Alla prima risoluzione di un dominio .com, per dire, il tuo DNS 
interroga i root, i quali forniscono i dati di delega per i .com, i 
quali a loro volta forniscono i dati di delega per l'autorità del 
dominio che interroghi.
Alla seconda risoluzione di un .com, i dati di delega li hai già 
cachati, quindi il tuo DNS riparte direttamente dai DNS del TLD.
Siccome i TLD utilizzati di norma non son poi molti, in pratica dopo una 
manciata di interrogazioni, finisci per avere tutti i TLD in cache.
Indubbiamente, rispetto al caso forwarder (1 interrogazione al 
forwarder, che il resto fa lui), hai di media 1 interrogazione in più (1 
al TLD per i dati di delega e l all'autoritativo per il dominio cercato).
Ma se le latenze della linea sono appena decenti, difficile si possa 
percepire una gran differenza.
Che prestazionalmente non sia la stessa cosa è indubbio.
Ma è anche indubbio che ha il grosso pregio che la risoluzione dipende 
solo dalla tua connettività (come tutto il resto) e non da possibili 
problemi/rallentamenti/whatever incontrati da un DNS pubblico ed in 
quanto tale esposto al pubblico ludibrio.
E, fidati, se ritieni che sia cosa indifferente non hai la più pallida 
idea di cosa veda passare un DNS pubblico oggi come oggi :-D

 idea di cosa veda passare un DNS pubblico oggi come oggi :-D
che so... queries per TLD tipo ".intra", ".local", ".lan" oppure per
indirizzi IP in RFC-1918 :D ??

 "tenga" qualcosina in piu' rispetto alla cache del dns locale.
NO

 il tutto.
il tuo DNS conserva in cache le varie informazioni ottenute durante
il processo di risoluzione di ciascuna query per cui NON interrogherà
i root servers "ogni volta che deve risolvere un dominio"; giusto per
farti un esempio; supponi di richiedere l'indirizzo di 
www.cisco.com
il tuo DNS inizia chiedendo ai root-servers quale sia tale indirizzo;
i root servers rispondono con la lista dei gTLD servers che sono
autoritativi per ".com"; il tuo DNS mette in cache tale lista e procede
richiedendo ai gTLD l'indirizzo in questione; i gTLD rispondono
fornendo la lista dei DNS autoritativi per "
cisco.com
"; il tuo DNS
di nuovo, mette in cache tale lista e procede richiedendo ai DNS
di "
cisco.com
" l'indirizzo richiesto che finalmente viene ritornato
ed anche questo messo in cache
ora.. supponi di voler chiedere l'indirizzo di 
www.3com.com
 il tuo
DNS controlla in cache, scopre di non avere informazioni relative
a 
3com.com
 ma sa quali sono i DNS autoritativi per ".com" quindi
parte direttamente con una query verso i gTLD
se poi volessi "tagliare" ulteriormente, non è che ci voglia tanto
alla fine della fiera, per BIND basta qualcosa di questo tipo
// root zone
zone "." {
  type slave;
  file "root.db";
  notify yes;
  masters {
    192.5.5.241;
    192.228.79.201;
    192.33.4.12;
  };
};
// inaddr.arpa zone
zone "in-addr.arpa" {
  type slave;
  file "inaddr.db";
  notify yes;
  masters {
    192.5.5.241;
    192.33.4.12;
  };
};
ma la stessa cosa può essere fatta anche con il DNS di windows
senza troppi problemi; in questo caso si tratterà di eliminare i root
hints e l'eventuale root zone (.) e poi creare come secondarie le
zone "." ed "in-addr.arpa" specificando come server primari quelli
visti sopra

 NO
Su', non mi diventare "d'Itriano", pero'. Un giorno che servira', mi
muniro' della bibbia del sysadmin dns. :-)


ObiWan ha scritto:
Denghiu' per le info. :-)


 Non è che sareste così gentili da darmi ancora delle dritte?
Bisogna IMHO vedere se i client passano per il proxy in "transparent",
o se quest'ultimo e' impostato sui client, se la porta 80 e' chiusa in
virtu' della presenza del proxy, e vattelapesca... :-)


 virtu' della presenza del proxy, e vattelapesca... :-)
Abbiamo letto sul forum di IPCOP che al fine di usare le funzionalita`
di proxy (c'e` anche il proxy trasparente) bisogna che il DNS di IPCOP
sia attivo sulla GREEN... in pratica tutti i client dovrebbero
ricevere, tramite il DHCP di W2k3, l'indirizzo di IPCOP come DNS.
Facendo cosi` pero`, crediamo appunto che poi i vari client non
possano piu` accedere all'AD :-( ... se per esempio impostassimo anche
su W2003, il DNS di IPCOP e dal DHCP di W2k3.
E` proprio un bel rompicapo.


 E` proprio un bel rompicapo.
Io non direi. Non fasciarti la testa prima di romperla! ;-)


 opportuamente configurato per NON usare dei forwarders.
In che senso, scusa? Se capisco bene, dovrei configurare l'interfaccia
RED affinche non sia settato ne dns primario ne secondario?
Attualmente sulla RED abbiamo impostato i DNS di OpenDNS... ci
sembrava la cosa piu` giusta.


 sembrava la cosa piu` giusta.
Non so come "ragiona" ipcop, ma lasciamo perdere le interfacce del
firewall: il dns prescinde da tutto questo (a perte che il servizio
sara' presumo accessibile solo sulla GREEN, questo e' chiaro).
Semplicemente, nella configurazione del dns di ipcop (che usa, bind? Nun
lo saccio...), non bisognerebbe indicare i server d'inoltro. Se ce li
lasci, comunque, non succede nulla, per le finalita' a cui vuoi
arrivare: semmai, affini dopo (non e' in questa fase importante, e
non lo e' in futuro).


 non lo e' in futuro).
OK, ora mi e` molto piu` chiaro... ci proveremo. E` che dobbiamo
studiarcela bene prima di commettere errori. Comunque grazie per le
dritte e per la pazienza.
