Benutzer mit den meisten Antworten
Reverse Proxy TMG 2010 / Exchange 2010 - Problem

Frage
-
Hi Leute,
ich habe ein grundlegendes Problem mit TMG 2010 (SP2) als Reverse-Proxy zur Absicherung von unserem Exchange 2010 (SP2).
Hier unsere Konstellation:
internes Netz: 192.168.119.0 /24
äußeres - Netz: 192.168.115.0 /24 (in dem Sinne keine DMZ, da alles durch dieses Netzwerk durch muss)
getrennt werden die beiden Netze durch einen LANCOM. Auch das Gateway ins Internet ist ein weiterer LANCOM (alles über Port 443 der festen IP geht auf den TMG).
1 x Exchange 2010 SP2 mit allen Rollen (außer Unified Messaging) auf Server 2008 R2 Standard im "inneren" Netz.
OWA / ecp und ActiveSync-Authentifizierung steht auf "Integrierte Windows Authentifizierung" und "Standardauthentifizierung")1 x interne CA auf Server 2008 R2 Standard im "inneren" Netz.
1 x TMG 2010 (SP2) mit einer NIC (Hyper-V) auf Server 2008 R2 Standard im äußeren Netz.
feste IP-Adresse für owa.domain.com
Also los gehts, ich habe ein Zertifikat für die Webdienste an unserer CA angefordert bzw. ausgestellt. Dort sind interne (server.domain.local) wie externe URL (owa.domain.com) eingetragen (auch der autodiscover Eintrag ist vorhanden.)
Zertifikat wurde exportiert und in den lokalen Speicher des TMG importiert. (ohne Probleme)
Danach habe ich mich als erstes dem Listener gewidmet und nannte diesen SSL-Listener mit dem selbst erstellten Zertifikat.
Einstellungen wie folgt:
- Netzwerke intern (habe ja nur eine NIC)
- Authentifizierung (HTML-Formularauthentifizierung, Methode zur Prüfung (LDAP (ActiveDirectory)
- SSO ist deaktiviertDann habe ich die host-Datei auf dem TMG um einen EIntrag ergänzt. (interner FQDN des Exchange und IP 192.168.115.x damit Portforwarding auf dem LANCOM eingerichtet werden kann)
Dann habe ich die üblichen 3 Exchange Webclientzugriffe veröffentlicht und dabei den o.g. Listener verwendet sowie den FQDN des Exchange (server.domain.local), Standardauthentifizierung und die Regel wird angewendet auf "owa.domain.com"
Dann noch LDAP(s) Ports freigegeben und eine Gruppe OWA-Benutzer angelegt. (funktionierte alles ohne Probleme)
Redirect habe ich erstmal noch gelassen, denn ich will alle möglichen Störfaktoren ausschließen)
So und nun kommts:
- OWA ist von extern und intern voll funktionsfähig und erreichbar. (*/Exchange und */public laufen auf einen Fehler "500 interner Serverfehler" beim Regeltest
- ActiveSync funktioniert nicht. (Regeltest läuft ohne Beanstandung durch)
- Outlook Anywhere funktioniert auch nicht. (*/OAB und */rpc laufen auf einen Fehler "500 interner Serverfehler" beim Regeltest)Wo habe ich was übersehen oder vergessen? Könnt ihr mir weiterhelfen?
Vielen Dank schon mal....
Montag, 19. November 2012 13:22
Antworten
-
Hi,
wegen EAS: Da scheint der Name des Zertifikats nicht dem Namen zu entsprechen welchen Du im Windows Mobile Phone eintraegst. Der Name im Mailprofil muss dem CN/SAN des Zertifikats entsprechen
wegen Outlook Anywhere: Da Du ein Zertifikat Deiner internen CA verwendest muss das Root CA Zertifikat im Zertifikatspeicher der vertrauenswuerdigen Stammzertifizierungsstellen des Computers existieren der Outlook Anywhere nutzen sollregards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert D.Jung Dienstag, 20. November 2012 10:58
Montag, 19. November 2012 15:49 -
Hi,
hast Du im LDAP Set am TMG sowohl NETBIOS Domain als auch den UPN Domain Namen hinterlegt? Am Outlook meldest Du Dich mit NETBIOSDOMAIN\user oder User@Domaene.tld an?
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert D.Jung Dienstag, 20. November 2012 10:59
Dienstag, 20. November 2012 10:34
Alle Antworten
-
Hi,
nach den Schilderungen sehe ich auch erst mal keinen Fehler. Was sagt denn https://testexchangeconnectivity.com und was siehst Du im Live Log des TMG Server zum Zeipunkt des Verbindungsaufbaus von einem Mobile Phone oder Outlook Anywhere?
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
Montag, 19. November 2012 14:36 -
Hi Marc,
vielen Dank für deine Antwort.
Im TMG-Log kommen folgende Meldungen beim Verbindungsversuch via WindowsPhone7:
Firewalldienst Status: Der Vorgang wurde erfolgreich beendet. Quelle: Intern (IP-Adresse-WP7:41773) Ziel: Lokaler Host (IP-Adresse-TMG-intern:443) Protokoll: HTTPS
- Anzahl der gesendeten Bytes: Anzahl der empfangenen Bytes:: 0
- Verarbeitungszeit: 0msUrsprüngliche Client-IP: IP-Adresse-WP7
und der hier:
Protokolltyp: Firewalldienst Status: Nach dem Senden eines RST-Pakets durch einen Peer erfolgte ein Verbindungsabbruch. Quelle: Intern (IP-Adresse-WP7:41773) Ziel: Lokaler Host (IP-Adresse-TMG-intern:443) Protokoll: HTTPS
- Anzahl der gesendeten Bytes: Anzahl der empfangenen Bytes:: 2754
- Verarbeitungszeit: Ursprüngliche Client-IP: IP-Adresse-WP7
Und hier der Connectivity-Test: (Active-Sync)
Attempting to resolve the host name domain.com in DNS. The host name resolved successfully. Weitere Details Testing TCP port 443 on host domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Testschritte ExRCA is attempting to obtain the SSL certificate from remote server domain.com on port 443. ExRCA successfully obtained the remote SSL certificate. Weitere Details Validating the certificate name. Certificate name validation failed. Und Outlook Anywhere:
RPC/HTTP-Konnektivität wird getestet. Fehler beim RPC/HTTP-Test. Testschritte Attempting to resolve the host name owa.domain.com in DNS. The host name resolved successfully. Weitere Details Testing TCP port 443 on host owa.domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Testschritte ExRCA is attempting to obtain the SSL certificate from remote server owa.domain.com on port 443. ExRCA successfully obtained the remote SSL certificate. Weitere Details Validating the certificate name. The certificate name was validated successfully. Weitere Details Certificate trust is being validated. Certificate trust validation failed. Testschritte ExRCA is attempting to build certificate chains for certificate CN=server.domain.local, OU=OU, O=Name, L=Ort, S=Bayern, C=DE. A certificate chain couldn't be constructed for the certificate. Weitere Details The certificate chain couldn't be built. You may be missing required intermediate certificates.
Vielleicht ist noch anzumerken, dass es ohne TMG problemlos funktioniert! Also RPC over HTTPS und ActiveSync- Bearbeitet D.Jung Montag, 19. November 2012 15:12
Montag, 19. November 2012 15:04 -
Hi,
wegen EAS: Da scheint der Name des Zertifikats nicht dem Namen zu entsprechen welchen Du im Windows Mobile Phone eintraegst. Der Name im Mailprofil muss dem CN/SAN des Zertifikats entsprechen
wegen Outlook Anywhere: Da Du ein Zertifikat Deiner internen CA verwendest muss das Root CA Zertifikat im Zertifikatspeicher der vertrauenswuerdigen Stammzertifizierungsstellen des Computers existieren der Outlook Anywhere nutzen sollregards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert D.Jung Dienstag, 20. November 2012 10:58
Montag, 19. November 2012 15:49 -
Hi,
Danke für deinen Tip, ich habe nun ein neues Zertifikat ausgestellt und darin den CN auf owa.domain.com geändert. Hat auch den ersten Anschein gemacht das es funktionierte. (Die Tests laufen auf dem TMG schon mal erfolgreich durch - nur ActiveSync komischerweise nicht mehr. 505 HTTP-Version wird nicht unterstützt)
Beim Exchange Connectivity-Test ist leider noch das Gleiche zu sehen.
Das mit dem RootCa Zertifikat auf den RPC-Clients hatte ich schon vorher gemacht und ist auf den Clients die von außerhalb darauf zugreifen wollen bereits im Computerspeicher hinterlegt. (funktioniert auch, da er beim Verbinden auf owa nicht meckert und es als vertrauenswürdig einstuft)
Edit: Geschafft (ActiveSync): Es lag tatsächlich an der LDAP-Authentifizierung. Man darf am Endgerät zur Authentifizierung nicht domain.local eingeben sondern lediglich domain.- Bearbeitet D.Jung Dienstag, 20. November 2012 08:24
Dienstag, 20. November 2012 08:07 -
Hi,
die Meldung 505 kommt von einem echten Device oder testexchangeconnectivity.com?
Probierst Du EAS mit einem Domaenen Admin Account? Welchen Typ Zertifikat hast Du ausgestellt fuer den TMG (welches Template, Template Version, CNG Key?regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
Dienstag, 20. November 2012 08:32 -
Die Fehlermeldung 505 HTTP wurde vom TMG selbst ausgegeben. Beim Regeltest.
ActiveSync funktioniert mittlerweile ohne Probleme (siehe meinen letzten Post der Edit-Eintrag)
Mein Problem liegt derzeit "nur" noch beim Outlook Anywhere.
Zum Zertifikat:
WebServer Template v3,Nochmal Edit: Kann es nicht sein, dass die Authentifizierung einfach nicht funktioniert ebenso wie beim ActiveSync?
- Bearbeitet D.Jung Dienstag, 20. November 2012 10:00
Dienstag, 20. November 2012 09:47 -
Hi,
hast Du im LDAP Set am TMG sowohl NETBIOS Domain als auch den UPN Domain Namen hinterlegt? Am Outlook meldest Du Dich mit NETBIOSDOMAIN\user oder User@Domaene.tld an?
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert D.Jung Dienstag, 20. November 2012 10:59
Dienstag, 20. November 2012 10:34 -
Pah, da war das Problem:
Ich habe fälschlicherweise als UPN den domain.local und nicht domain.tld angegeben am TMG LDAP-Setting....
NETBIOS ist richtig eingegeben worden, aber den anderen hatte ich vor lauter Domain- hin / her falsch eingegeben.Und beim Outlook Anywhere habe ich wie gewöhnlich den UPN genommen,... DANKE! :-)
Also kommen die Fehlermeldungen ( testexchangeconnectivity.com) daher dass ich die Zertifikate selbst ausgestellt habe und meine Probleme wurden durch das neue Zertifikat mit dem neuen CN und den LDAP UPN Einstellungen am TMG behoben.
Vielen Dank Marc......
Dienstag, 20. November 2012 10:58