Trusted Relationship

[Razorh]

Om maar meteen met de deur in huis te vallen: ik heb het volgende
probleem:

Ik heb 2 servers (NT4) op verschillende subnetten. Deze moet worden
geconfigureerd voor een Trusted Relationship. Maar dit wil niet lukken
want
ik krijg de melding “Could not find domain controller for this domain”.
De servers kunnen elkaar wel pingen.

Het is de bedoeling om straks een soort van webmail op te zetten die
gegevens haalt uit ms exchange.

[Predator]

Had je dit al gevonden & getest
http://support.microsoft....spx?scid=KB;en-us;197808&

[ Voor 29% gewijzigd door Predator op 03-01-2003 16:02 ]

[Razorh]

Ja dat is al geprobeerd werkt niet.

[Brahiewahiewa]

Razorh schreef op 03 januari 2003 @ 16:05:
Ja dat is al geprobeerd werkt niet.

Welke poorten staan er open op de router tussen die twee subnets?

[Razorh]

135/TCP RPC
137/UDP NetBIOS Name
138/UDP NetBIOS Netlogon and Browsing
139/TCP NetBIOS Session
42/TCP WINS Replication

[luckyme_]

Kunnen die pdc's elkaar wel op naam (via WINS) vinden? Normaal gesproken moeten ze natuurlijk wel ergens een naam + ip van het andere domein vandaan halen.
Quick and dirty kan het natuurlijk ook via een LMHOST file, maar ik zou er voor kiezen om de twee wins omgevingen (je hebt er ongetwijfeld in elk domein een) met elkaar te laten repliceren.

[Brahiewahiewa]

Razorh schreef op 03 januari 2003 @ 16:19:
[...]42/TCP WINS Replication

Want? Beide servers zijn WINS server en ze repliceren?

[Equator]

Zorg dat er op elk subnet een WINS server aanwezig is, die een domain vermelding voor het andere domain heeft staan.
Dus in subnet a, met domain a, maak je een vermelding in WINS voor domain b op IP adres van de domain controller van domain b. En vise versa.

Heb je op die subnetten geen WINS draaien, maak dan een LMHOSTS file aan op elke server.
Dit moet je doen in c:\WINNT\SYSTEM32\Drivers\ETC\
met deze syntax:

code:

192.168.1.10     #PRE     #DOM:DOMAIN-A

op de andere:

code:

192.168.2.10     #PRE     #DOM:DOMAIN-B

het IP adres in deze file staan voor het IP adres van de domain controller van het andere domain. Daarachter staat #PRE. Dit houd in dat het PRE loaded is. Het wordt dus al snel geladen, waardoor vb: een trust goed tot stand kan komen.
Het gedeelte #DOM:DOMAIN-A staat voor de naam van het domain op het andere subnet.

Zoals Brahiewahiewa ook al melde, de tcp poort 42 hoeft niet open te staan wanneer je geen WINS replicatie hebt tussen de beide servers. Heb je dit wel, dan kan hij open blijven staan.

offtopic:
FYI
Statische WINS mappings worden NIET gerepliceerd

[Razorh]

Kijk ik heb hier een tekening gemaakt

[Brahiewahiewa]

Persoonlijk zou ik in deze situatie besluiten om OWA op de Exchange server te draaien en in de DMZ een reverse proxy neer te zetten (kan op ISA, Squid of Apache). Je compromitteert je DMZ nogal door RPC verkeer toe te laten; betekent nl dat als je IIS gehackt is, er ook meteen NetBIOS toegang tot je interne netwerk is

[ Voor 8% gewijzigd door Brahiewahiewa op 09-01-2003 10:43 . Reden: correctie ]

[Equator]

Als ik bovenstaand tekeningetje zie, dan vraag ik mij ook af waarom je er een trust relatie tussen wilt.
Ahh, dat lees ik al. OWA wil direct op de Exchange server rommelen natuurlijk..
Hmm, waarschijnlijk is de olossing van Brahiewahiewa beter.

[Razorh]

Brahiewahiewa goed idee alleen heb nog niet zo'n ervaring met reverse proxy

Trouwens dat IIS verhaal... vanuit wan wordt geconnect via alleen https, dan is er toch geen gevaar?

[ Voor 43% gewijzigd door Razorh op 09-01-2003 12:22 ]

[Razorh]

Kijk hier staat ongeveer het zelfde http://www.sans.org/rr/email/corp_email.php

[Brahiewahiewa]

Hmmz, als 't SANS instituut denkt dat dit een veilige configuratie dan zullen ze daar wel gelijk in hebben. Voorwaarde is idd wel dat je slechts zeer beperkte toegang tot je DMZ mag geven. Daarnaast zou'k op die OWA server ook IP-filters configureren zodat NetBIOS verkeer alleen met de PDC en de Exchange server mogelijk is.

Enniewee, wil je dan natuurlijk weten waarom die trust niet werkt. Vraagje: is die IIS in je DMZ eigenlijk wel een domain controller? (staat er niet bij in je tekeningetje). Andere vraag: kun je die IIS niet gewoon member van je XDOMAIN maken? Nog een andere vraag: heb je een WINS server in je interne netwerk? Zo ja: kun je in de tcp/ip properties van je IIS aangeven dattie zich bij die WINS server registreert?

[Razorh]

Kijk heb niet zoveel ervaring hier mee maar moet er een domaincontroller draaien op de webmail server?

[Brahiewahiewa]

Razorh schreef op 09 januari 2003 @ 16:14:
Kijk heb niet zoveel ervaring hier mee maar moet er een domaincontroller draaien op de webmail server?

Nee, dat hoeft niet persé. Maar dat moet wel als je een trust wilt maken; trusts kun je alleen maken tussen domains. Komen we dus op de vraag: "Waarom wil je een trust?". Als dat is om mbv de Exchange Service account, de OWA service te kunnen draaien, is de oplossing veel eenvoudiger. Dan maak je namelijk de IIS een member server van je domain (feitelijk is dat ook een trust relatie, maar da's alleen voor kniesoren van belang ).
Om succesvol het domain te kunnen joinen moet je wèl op de tcp properties van je IIS de interne WINS server opgeven, anders kannie het domain niet vinden. 't Kan zijn dat je je firewall nog moet aanpassen om antwoorden op WINS queries toe te staan naar het IP-adres van je IIS

[Razorh]

Je zegt dus een member maken van het domein met IIS maar zoals ik al had verteld hij ziet dat domein dus niet van uit webmail. Ik kan gewoon wel de servers pingen en zien op netwerkomgeving, maar het domein waar ze aanhangen zie ik gewoon weg niet.

[Verwijderd]

Brahiewahiewa schreef op 09 January 2003 @ 14:52:
Nog een andere vraag: heb je een WINS server in je interne netwerk? Zo ja: kun je in de tcp/ip properties van je IIS aangeven dattie zich bij die WINS server registreert?

kan die port 42 weer dicht en moet een andere winsport weer open (geen idee welke uit mijn hoofd )

dit beantwoord direct je vraag van hierboven... (tenzij idd je ook nog een winsserver in je dmz hebt gezet... helemaal al niet wenselijk), je kan geen wins lookup doen...

[ Voor 19% gewijzigd door Verwijderd op 10-01-2003 10:55 ]

[Razorh]

dus je zegt dus dat het waarschijnlijk in de firewall/router zit (sonicwall).
Dan zou ik idd graag weten welke andere poort open moet

[ Voor 28% gewijzigd door Razorh op 10-01-2003 11:47 ]

[Verwijderd]

google moet het antwoord wel hebben... zoek ff naar portlist oid...

[Brahiewahiewa]

UDP137, UDP138 en TCP139
Volgens je posting van 3 januari staan die al open

[Razorh]

Ja precies, ik dacht al nog meer poorten?
Ik kom er volgens mij nog steeds niet uit....
Domein kan niet gevonden worden dus trusten lukt niet.
Poorten staan de goeie open...

[Verwijderd]

1512 tcp wins Microsoft's Windows Internet Name Service
1512 udp wins Microsoft's Windows Internet Name Service

[Razorh]

En dat is dan dus van dmz naar lan toch?

[Razorh]

Geprobeerd maar maakt geen verschil aaaaghhr ik wordt gek

[Brahiewahiewa]

Volgens mij moet je eens wat nauwkeuriger omschrijven wat je nu eigelijk probeert. Probeer je nog steeds die trust aan te maken? Zo ja, hoe doe je dat (op welke machine, welk programma, welke menu opties)? Of probeer je nu het domain te joinen met je web server?
En heb je nu al het IP-adres van je WINS server toegevoegd op de TCP/IP-properties van je web server?

[Verwijderd]

zie je geen firewall drops oid...
en zo nee gebruik dan eens een netwerkmonitor...

[ Voor 44% gewijzigd door Verwijderd op 10-01-2003 15:29 ]

[Razorh]

Zou het kunnen zijn dat sp6 niet geinstalleerd is dat ie dit doet? (op webmail dan)

[Razorh]

Ok vergeet dat trusten...
Ik wil kunnen inloggen op het xdomain van uit server webmail. Ik zie het xdomain in netwerkomgeving maar als ik daar naar toe ga zie ik geen enkele computer in dat domain.
Hoe kan dit terwijl server a en b en nog wat clients in dit domein zitten.

[ Voor 21% gewijzigd door Razorh op 10-01-2003 16:46 ]

[Brahiewahiewa]

Dat is omdat je geen browse master voor dat domain vindt.
Probeer eens Start | Run | \\servera

[Razorh]

thx dat werkt gewoon, nu ga ik even kijken of de rest nog lukt..

[Verwijderd]

Razorh schreef op 10 januari 2003 @ 16:21:
Zou het kunnen zijn dat sp6 niet geinstalleerd is dat ie dit doet? (op webmail dan)

btw sp5 in een dmz?

[Razorh]

Ok ik heb precies gevonden hoe het verder moet: http://www.microsoft.com/...xchange55/plan/ekmgem.asp

Maar ik kan geen appendix A of B vinden (zie einde document) Of ben ik nu zo scheel?

[Razorh]

En waarom heb je 2 netwerkkaarten nodig?

[Brahiewahiewa]

Razorh schreef op 15 januari 2003 @ 09:14:
En waarom heb je 2 netwerkkaarten nodig?

Die tweede NIC wordt dus gebruikt voor het NetBIOS en MAPI verkeer omdat - zoals je zelf gemerkt hebt - het best wel lastig is om dat over je firewall te routeren.
Wat dat betreft is het een discutabel ontwerp: als iemand doordringt in je DMZ en er in slaagt je OWA front-end te hacken, dan zittie dus ook meteen in je interne net; je DMZ heeft maar zeer beperkte toegevoegde waarde op deze manier.
Zoals ik ruim een week geleden al opmerkte is het veel veiliger om OWA op je Exchange server te draaien en in je DMZ een reverse proxy op te nemen. Maar dat zeg ik niet weer want dan zou ik in herhaling vervallen.

[Razorh]

Tja , maar dat is helaas niet wat de baas wil

[Brahiewahiewa]

Razorh schreef op 17 January 2003 @ 11:26:
Tja , maar dat is helaas niet wat de baas wil

Misschien moet je met de baas dan eens de discussie aangaan waarom hij dit wil en wat de implicaties van die keuze zijn. Als je alleen een technische oplossing had gezocht, had je dit topic wel in NT gepost, en niet in PNS