Edge Rolle auf TMG
Markus Meier
Vielleicht eine etwas "dumme" Frage. Möchte einfach Fehlern vorbeugen...
Mein Netzwerk:
Server 2008R2 AD/DNS/DHCP
Server 2008R2 Exchange 2010
Server 2008R2 TMG/Exchage 2010 Edge
Installationsvorgang inkl. Abonnement lief einwandfrei durch.
Nun bin ich eben nicht sicher, welche Regeln durch die Installation der Edge
Rolle auf dem TMG automatisch erstellt wurden. Wenn dies überhaupt passiert?
Muss ich weiterhin meinen Mailserver veröffentlichen und ausgehende und
eingehende Regeln erstellen?
Gruss und Danke,
Markus
Jens Baier
> Nun bin ich eben nicht sicher, welche Regeln durch die Installation der
> Edge
> Rolle auf dem TMG automatisch erstellt wurden. Wenn dies überhaupt
> passiert?
> Muss ich weiterhin meinen Mailserver veröffentlichen und ausgehende und
> eingehende Regeln erstellen?
Nein brauchst Du nicht:
http://technet.microsoft.com/en-us/library/ee338733.aspx
http://www.isaserver.org/tutorials/Installing-Configuring-Email-Hygiene-Solution-TMG-2010-Firewall-Part2.html
--
Gruss Jens
www.it-training-grote.de
www.forefront-tmg.de
https://mvp.support.microsoft.com/profile/Marc.Grote
http://blog.it-training-grote.de
Jens Mander
> Vielleicht eine etwas "dumme" Frage. Möchte einfach Fehlern vorbeugen...
gibt doch keine dummen fragen - nur dumme antworten!
;-)
> Mein Netzwerk:
> Server 2008R2 AD/DNS/DHCP
> Server 2008R2 Exchange 2010
> Server 2008R2 TMG/Exchage 2010 Edge
>
> Installationsvorgang inkl. Abonnement lief einwandfrei durch.
prima!
> Nun bin ich eben nicht sicher, welche Regeln durch die Installation der
> Edge
> Rolle auf dem TMG automatisch erstellt wurden. Wenn dies überhaupt
> passiert?
> Muss ich weiterhin meinen Mailserver veröffentlichen und ausgehende und
> eingehende Regeln erstellen?
checke mal deine systemrichtlinie gegen - hier sollte alles passende
aktiviert sein (Verschiedene/E-Mail-Richtlinie). sicherheitshalber kannst du
deinen tmg auf port 25 mal telnetten um zu sehen ob jemand @ home ist.
--
gruss, jens mander...
www.aixperts.de
www.forefront-tmg.de
www.hentrup.net
|<-|
Markus Meier
Dank an Euch beide für die prompten Antworten.
Sowie ich meine Situation interpretiere und gemäss Euren Antworten
kontrolliert habe, sollte alles zum Besten sein.
Sollte. Habe zwei Situationen die nicht funktionieren.
1. Mails werden intern empfangen und versandt. Mails werden von extern
empfangen. Mails werden aber NICHT nach extern versandt.
2. OWA Zugriff von extern klappt nicht. Hier habe ich bereits eine
"Diskussion" im Exchage Forum eröffnet.
Kurzer Hinweis:
Zugriff extern klapp nicht (Zertifikat wird angezeigt und OWA Maske
erscheint) Beim Versuch der Anmeldung erscheint Fehlermeldung:Die Seite kann
nicht angezeigt werden Fehlercode 500 interner Serverfehler. Die
Zertifikatkette wurde von einer nicht vertrauenswürdigen
Zertifizierungsstelle ausgestellt.
Gibt es hier ein "Art" wie ich kontrollieren kann ob der TMG meiner PKI
vertraut?
Irgendwie habe ich auch den Verdacht das der Fehler evtl. von der
Authentifizierung am TMG kommt.
Hier sind meine Einstellungen wie folgt:
Weblistener = HTML Formularauthentifizierung
Regel unter Authentifizierungsdelegierung = Standardauthentifizierung
Danke für Euren weiteren Support.
Gruss,
Markus
Jens Mander
> Gibt es hier ein "Art" wie ich kontrollieren kann ob der TMG meiner PKI
> vertraut?
was sagt denn der regel-testen-button auf der veröffentlichungsregel - dort
alles grün?
ansonsten bei zertifikaten kontrollieren, ob sie im richtigen speicher
liegen (computer-zertifikatsspeicher!).
Jens Baier
> 1. Mails werden intern empfangen und versandt. Mails werden von extern
> empfangen. Mails werden aber NICHT nach extern versandt.
was sagt denn das NAchrichtentracking vom Exchange? Was sagt ein Telnet vom
Exchange auf einen externen Mailserver? Wie sieht Deine E-Mail Policy aus?
> 2. OWA Zugriff von extern klappt nicht. Hier habe ich bereits eine
> "Diskussion" im Exchage Forum eröffnet.
Fuer OWA musst Du weiterhin eine Exchange Client Publishing anlegen, dass
macht die E-Mail Policy nicht, die ist ja nur fuer SMTP zustaendig
> Zugriff extern klapp nicht (Zertifikat wird angezeigt und OWA Maske
> erscheint) Beim Versuch der Anmeldung erscheint Fehlermeldung:Die Seite
> kann
> nicht angezeigt werden Fehlercode 500 interner Serverfehler. Die
> Zertifikatkette wurde von einer nicht vertrauenswürdigen
> Zertifizierungsstelle ausgestellt.
dann hast Du vermutlich auf der internen TMG Seite kein gueltiges Zertifikat
oder kein gueltiges Root CA Zertifikat in den richtigen Speicher importiert.
Die Meldung ist der Klassiker schlecht hin der auf sowas zeigt!
> Gibt es hier ein "Art" wie ich kontrollieren kann ob der TMG meiner PKI
> vertraut?
Ja, das Root CA Zertifikat im lokalen Zertifikatspeicher des TMG anklicken
und schauen ob alles prima ist. es gibt noch weitere Moeglichkeiten, aber
das ist die einfachste
> Weblistener = HTML Formularauthentifizierung
> Regel unter Authentifizierungsdelegierung = Standardauthentifizierung
OK
Markus Meier
> ansonsten bei zertifikaten kontrollieren, ob sie im richtigen speicher
> liegen (computer-zertifikatsspeicher!).
Habe extra nochmals kontrolliert und es liegen nun wirklich alle Zertifikate
im Lokalen Computerkonto.
> was sagt denn der regel-testen-button auf der veröffentlichungsregel - dort
> alles grün?
Nö, alles rot. Aber neuer Fehler: Zielprinzipalname ist falsch.
Habe mal meine Regel für OWA kurz notiert:
VON Beliebig
NACH webmail.xy.com
ursprümglichen Hostheader
Ursprung=Client
LISTENER Verbindung=SSL
Jede IP Adresse Zertifikat => Zertifikat inkl.
webmail.xy.com
Authentifizierung=HTML Formular...
Authentifizierungsprüfung=Active Directory
SSO aktiviert mit Eintrag .xy.com
LINKÜBERSETZUNG für diese Regel anwenden
AUTHENTIFIZIERUNGSREGEL=Standardauthentifizierung
ÖFFENTLICHER NAME Anforderung für folgende Websites=webmail.xy.com
PFADE /owa/* und /exchange/* und /public/* und /ecp/3
BRIDING Webserver Anforderung an SSL Port leiten
Mein TMG kann webmail.xy.com auflösen und zeigt auf meinen Exchange Server.
Wo ist der Punkt der falschen Konfiguration nun?
Danke und Gruss,
Markus
Markus Meier
Danke für diese Tipps. Nehme mal Punkt 2 vorweg. Hier habe ich Jens Mander
ausführlich geantwortet und neues Problem geschildert.
>was sagt denn das NAchrichtentracking vom Exchange? Was sagt ein Telnet vom
>Exchange auf einen externen Mailserver? Wie sieht Deine E-Mail Policy aus?
Telnet zu smtp.bsp.com 25 bekomme ich keinen Verbindungsaufbau! Dann am TMG
SMTP Regel erstellt vom EXCHANGE nach EXTERN. Dann klappt der Zugriff per
Telnet.
Werden aber weiterhin keine Mails versandt
E-Mail Policy auf dem TMG = External und Internal via Edge Abo erstellt.
Mein Sendeconnector Extern auf dem Exchange ist wie folgt konfiguriert:
Adressraum SMTP *
Netzwerk MX Datensätze des DNS inkl. Domänensicherheit aktivieren
Nachrichtenübermittlungs-Problemverfolgung gibt "nur" eine Warnung aus, dass
IPv6 Adressen nicht unterstützt werden.
Quellserver TMG
Leider bis dato kein Erfolg.
Wo liegt der Knackpunkt?
Gruss und Danke,
Markus
Jens Baier
> Adressraum SMTP *
> Netzwerk MX Datensätze des DNS inkl. Domänensicherheit aktivieren
DOmaenensicherheit muss raus
Jens Baier
> Nö, alles rot. Aber neuer Fehler: Zielprinzipalname ist falsch.
ein Klassiker
> NACH webmail.xy.com
> ursprümglichen Hostheader
> Ursprung=Client
und der Zertifikat CN ist auch auf webmail.xy.com ausgestellt? DNS funzt?
> ÖFFENTLICHER NAME Anforderung für folgende Websites=webmail.xy.com
Du arbeitest mit Split DNS oder HOSTS Datei da interner und externer Name
gleich sind?
Markus Meier
> und der Zertifikat CN ist auch auf webmail.xy.com ausgestellt?
Unter Anderem. Ist auch noch für diverse andere Subdomains ausgestellt.
DNS funzt?
Einwandfrei
> Du arbeitest mit Split DNS oder HOSTS Datei da interner und externer Name
> gleich sind?
Hmmmm... nslookup von extern auf webmail.xy.com zeigt auf die externe IP am
TMG
nslookup im internen Netz auf webmail.xy.com zeigt auf die interne IP des
Exchange.
Danke und Gruss,
Markus
Markus Meier
> DOmaenensicherheit muss raus
Leider immer noch nichts...
Warteschlange zeigt folgenden Fehler:
451 4.4.0 Primary target IP address responded with: ""451 5.7.3 Cannot
achieve Exchange Server authentication."" Attempted failover to alternate
host, but that did not succeed. Either there are no alternate hosts, or
delivery failed to all alternate hosts."
Hilft das zur Fehleranalyse? Edgesynchronisation zeigt 2x success.
Gruss und Dnake,
Markus
Jens Baier
> 451 4.4.0 Primary target IP address responded with: ""451 5.7.3 Cannot
> achieve Exchange Server authentication."" Attempted failover to alternate
> host, but that did not succeed. Either there are no alternate hosts, or
> delivery failed to all alternate hosts."
das ist also immer noch das Auth Problem. Hast Du dem Connector per
ADD-Adpermission gesagt, wer darauf zugreifen darf?
Jens Baier
>> und der Zertifikat CN ist auch auf webmail.xy.com ausgestellt?
> Unter Anderem. Ist auch noch für diverse andere Subdomains ausgestellt.
also SAN Zertifikat? Dann musst Du sicherstellen, dass der erste SAN dem
Namen im Feld "Nach" in der Regel entspricht
> Hmmmm... nslookup von extern auf webmail.xy.com zeigt auf die externe IP
> am
> TMG
OK
> nslookup im internen Netz auf webmail.xy.com zeigt auf die interne IP des
> Exchange.
OK
Markus Meier
Einmal mehr ich mich bei Dir für Deine Geduld bedanken. DANKE
> das ist also immer noch das Auth Problem. Hast Du dem Connector per
> ADD-Adpermission gesagt, wer darauf zugreifen darf?
Stehe hier total auf dem Schlauch. Dachte hier werden bei der Installation
gewisse "Grundrechte" mitgegeben?
(http://technet.microsoft.com/de-de/library/aa996395.aspx)
Muss ich jetzt jedem Benutzer gewisse Sendeconnectoren Rechte geben? Wie
lautet hier der genaue Befehl? Nur über Shell möglich?
Sorry Du siehst es sicherlich an meinen Antworten. Ich bin ein totaler Newbie!
Gruss,
Markus
Markus Meier
> also SAN Zertifikat? Dann musst Du sicherstellen, dass der erste SAN dem
> Namen im Feld "Nach" in der Regel entspricht
Der richtige 1 Eintrag und der Erfolg hat sich eingestellt. HURRA! DANKE
Nun stellt sich bi mir aber die Frage, warum soll (bzw. habe ich) ein
Zertifikat mit diversen Subdomains erstellt, wenn ich doch immer den 1.
Eintrag im "Nach" verwenden muss? War diese Arbeit vergebens?
Spreche ein Szenario an, wo ich einerseits owa.xy.com (1.Stelle),
webmail.xy.com und sharepoint.xy.com etc. im Zertifikat angegeben habe.
Habe ja jetzt einen DNS Eintrag erstellt welcher owa.xy.com auf meinen
Exchange Server verweisen lässt. Nun wenn ich jetzt meinen Sharepoint Server
(ist ungleich Exchange Server) mit dem gleichen Zertifikat veröffentlichen
will, stehe ich demnach im Regen?
Oder sehe ich als blutjunger Zertifikatsanhfänger da was falsch?
Danke und Gruss,
Markus
Jens Baier
>> Namen im Feld "Nach" in der Regel entspricht
> Der richtige 1 Eintrag und der Erfolg hat sich eingestellt. HURRA! DANKE
prima. Mit der SAN Unterstuetzung in ISA 2006 SP1 scheint es noch nicht so
weit gediehen zu sein!
Jens Baier
> Stehe hier total auf dem Schlauch. Dachte hier werden bei der Installation
> gewisse "Grundrechte" mitgegeben?
> (http://technet.microsoft.com/de-de/library/aa996395.aspx)
es ging um den Sendeconnector? Mails kommen nicht raus?! Kannst Du die
genaue Fehlermeldung in der SMTP Warteschlange nochmal posten und schauen
was zum Zeitpunkt des SMTP Verbindungsaufbaus auf dem TMG im Realtime
Logging protokolliert wird.
Bei einem Sendeconenctor musst Du eigentlich nichts mit der AD Auth machen,
nur beim Receive Connector
Markus Meier
Ja, es werden "nur" keine Mails nach extern versandt.
Warteschlangenfehler=451 4.4.0 Primary target IP address responded with:
""451 5.7.3 Cannot
achieve Exchange Server authentication."" Attempted failover to alternate
host, but that did not succeed. Either there are no alternate hosts, or
delivery failed to all alternate hosts."
Protokollierung TMG
Client IP = Exchange Server
Ziel IP = interne NIC des TMG
1. LDAPS(EdgeSync) initiierte Verbindung
2. LDAPS(EdgeSync) getrennte Verbindung
3. LDAPS(EdgeSync) verweigerte Verbindung Fehler: Ein nicht
SYN-Paket wurde verworfen, weil es von einer Quelle gesendet wurde, die über
keine vorhandene Verbindung mit TMG verfügt
4. DNS verweigerte Verbindung (durch Standardregel)
5. SMTP initiierte Verbindung
6. SMTP getrennte Verbindung
1.-3. und 5.-6. Regel=System
Ich habe an 1. Stelle meiner Firewallregeln einen DNS Eintrag von meinem
internen DNS Server zu meinem ISP. DNS funktioniert auch einwandfrei.
Danke und Gruss,
Markus
Jens Baier
> Warteschlangenfehler=451 4.4.0 Primary target IP address responded with:
> ""451 5.7.3 Cannot
> achieve Exchange Server authentication."" Attempted failover to alternate
> host, but that did not succeed. Either there are no alternate hosts, or
> delivery failed to all alternate hosts."
hmm, beim Sende Conenctor sollte das nicht so sein
Leitest Du an Smarthost weiter vom Edge Server oder nutzt Du MX?
> 1. LDAPS(EdgeSync) initiierte Verbindung
> 2. LDAPS(EdgeSync) getrennte Verbindung
> 3. LDAPS(EdgeSync) verweigerte Verbindung Fehler: Ein nicht
> SYN-Paket wurde verworfen, weil es von einer Quelle gesendet wurde, die
> über
> keine vorhandene Verbindung mit TMG verfügt
das ist aber nur das Sync des Hub Transport Servers mit dem Edge Server
Dienst. Sollte damit nichts zu tun haben!
> 4. DNS verweigerte Verbindung (durch
> Standardregel)
DNS scheint noch zu haken oder?
> 5. SMTP initiierte Verbindung
> 6. SMTP getrennte Verbindung
das ist OK!
> Ich habe an 1. Stelle meiner Firewallregeln einen DNS Eintrag von meinem
> internen DNS Server zu meinem ISP. DNS funktioniert auch einwandfrei.
OK, dann ist das unproblematisch
Den Artikel kennst Du?
http://technet.microsoft.com/en-us/library/ee513174.aspx
Markus Meier
>Mit der SAN Unterstuetzung in ISA 2006 SP1 scheint es noch nicht so
> weit gediehen zu sein!
Würdest Du mir empfehlen mein SAN Zertifikat zu deinstallieren und dann ein
Wildcard zu erstellen?
Wenn ja, hast Du per Zufall gleich die 2 entsprechenden Links mit einem hoto?
Danke und Gruss,
Markus
Jens Baier
> Würdest Du mir empfehlen mein SAN Zertifikat zu deinstallieren und dann
> ein
> Wildcard zu erstellen?
> Wenn ja, hast Du per Zufall gleich die 2 entsprechenden Links mit einem
> hoto?
ich finde SAN Zertifikat ganz praktisch, wenn es um unterschiedliche
Namespaces geht.
Du kannst das SAN jaa ggfs. nochmal neu erstellen und sicherstellen, dass
der richtige SAN als erstes drin steht:
http://www.it-training-grote.de/download/ex-certificate.pdf
Markus Meier
> hmm, beim Sende Conenctor sollte das nicht so sein
> Leitest Du an Smarthost weiter vom Edge Server oder nutzt Du MX?
Nutze MX...habe aber auch mal Smarthost zu meinem ISP eingestellt. Leider
gleicher Fehler.
> das ist aber nur das Sync des Hub Transport Servers mit dem Edge Server
> Dienst. Sollte damit nichts zu tun haben!
OK
> DNS scheint noch zu haken oder?
Hmmmm...Jein, laut Protokoll will mein Exchange eine DNS Abfrage zu meinem
TMG mit Edge Rolle machen. Ist das Standard? Theoretisch (so auf der NIC
eingestellt) sollen alle DNS Abfragen im internen Netz Richtung meinem DNS
Server gehen.
> Den Artikel kennst Du?
> http://technet.microsoft.com/en-us/library/ee513174.aspx
Kannt ich nicht. DANKE. Alle Einstellungen gecheckt und wenn nötig angepasst.
Leider immer noch der gleiche Fehler.
Evtl. sind diese 2 Hinweise noch wichtig (hoffe nicht dass dies am Schluss
relevant ist, ansonsten würde ich mich sofort entschuldigen)
1. Der Exchange wird als virtuelle Maschine unter Hyper-V betrieben.
2. Edge Virus/Malware Definitionen sind abgelaufen weil keine Lizenz.
(Grund=ist ein Aufbau eines Testnetzwerks)
Danke und Gruss,
Markus
Jens Mander
> ich finde SAN Zertifikat ganz praktisch, wenn es um unterschiedliche
> Namespaces geht.
> Du kannst das SAN jaa ggfs. nochmal neu erstellen und sicherstellen, dass
> der richtige SAN als erstes drin steht:
> http://www.it-training-grote.de/download/ex-certificate.pdf
auch ein blick wert:
http://blog.forefront-tmg.de/?p=250
:-)
Markus Meier
> ich finde SAN Zertifikat ganz praktisch, wenn es um unterschiedliche
> Namespaces geht.
> Du kannst das SAN jaa ggfs. nochmal neu erstellen und sicherstellen, dass
> der richtige SAN als erstes drin steht:
> http://www.it-training-grote.de/download/ex-certificate.pdf
Danke für den Link und die Antwort.
Gruss,
Markus
Markus Meier
> auch ein blick wert:
> http://blog.forefront-tmg.de/?p=250
Auch hier ein grosser DANK für die Links.
Gruss,
Markus
Markus Meier
E-Mail Richtlinie die durch den Assistenten auf dem TMG erstellt wurde hat
folgende Athentifizierungseinstellung beim Listener:
INTERN
Nur extern gesichert
EXTERN
TLS und Exchange Server
Ist das richtig so?
Jens Baier
> EXTERN
> TLS und Exchange Server
hier wird das Problem liegen dass der Exchange nur TLS macht! Stell das mal
um!
Markus Meier
> hier wird das Problem liegen dass der Exchange nur TLS macht! Stell das mal
> um!
Leider nein...Umstellung auf Standard und Exchange Authentifizierung hat
keinen Erfolg gebracht.
Liste hier nochmals meine Einstellungen für die 4 Sendeconnectoren auf:
SENDECONNECTOR EXCHANGE
Mein AD Standort to Internet
Adressraum SMTP *
Netzwerk MX-Datensätze
Quellserver TMG
Inbound to mein AD Standort
Adressraum SMTP -
Netzwerk Smarthost -
Quellserver TMG
E-MAIL RICHTLINIE
External
Listener Standard und Exchange Authentifizierung
Internal
Listener Extern gesichert (zB IPSec)
Bin ratlos.....
Danke und Gruss,
Markus
Markus Meier
Globale Einstellungen=>Transporteinstellungen=>Nachrichtenzustellung=>beide
Felder leer