locked
How to publish Exchange 2003 (OWA/RPC over HTTPS) with Forefront TMG RRS feed

  • Frage

  • Edit: Sorry ich dachte in einem englischen Forum zu posten, die Antworten können auch in deutsch sein ;-)

    Hi Community,

    I have a manual about Forefront TMG but this describes only the Outlook Anyware publishing with exchange 2010. Before we get rid of our Exchange 2003, we have to install the TMG server first (and a couple of another dependencies) but for now I have to publish OWA and RPC over HTTPS based on  Exchange 2003 over Forefront TMG and I didn't found a tutorial how I have to configure the necessary listeners. I heard that there is no more need to configure two different listeners each for OWA and RPC in TMG, both services now can be published over one single listener. Can anyone send me a link to a tutorial, how it works in Forefront TMG?

    Thanks in advance & Bye Tom 



    Montag, 18. Juli 2011 15:01

Antworten

  • Hi,

    Die Veroeffentlichung von Outlook Anywhere ueber TMG mit Exchange 2003 unterscheidet sich nicht von der mit Exchange 2007 / 2010.
    Seit ISA 2006 SP1 brauchst Du nur noch einen Listener um OWA und OA zu veroeffentlichen. Wenn FBA fuer OWA verwendet wird, macht der TMG/ISA ein Fallback auf Basic Authentication: Diese musst Du dann auch am Exchange / Outlook einstellen. Wenn Du NTLM fuer OA haben willst,kannst Du das dann nicht ueber einen Listener realisieren, da das Fallback von FBA nur auf Basic Auth. stattfindet


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 18. Juli 2011 16:17

Alle Antworten

  • Hi,

    Die Veroeffentlichung von Outlook Anywhere ueber TMG mit Exchange 2003 unterscheidet sich nicht von der mit Exchange 2007 / 2010.
    Seit ISA 2006 SP1 brauchst Du nur noch einen Listener um OWA und OA zu veroeffentlichen. Wenn FBA fuer OWA verwendet wird, macht der TMG/ISA ein Fallback auf Basic Authentication: Diese musst Du dann auch am Exchange / Outlook einstellen. Wenn Du NTLM fuer OA haben willst,kannst Du das dann nicht ueber einen Listener realisieren, da das Fallback von FBA nur auf Basic Auth. stattfindet


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 18. Juli 2011 16:17
  • Hi Marc,

    > Wenn FBA fuer OWA verwendet wird, macht der TMG/ISA ein Fallback auf Basic Authentication:

    > Diese musst Du dann auch am Exchange / Outlook einstellen.

    Das ist bislang ja auch schon so gewesen, glaub ich. Auf alle Fälle haben wir in unserer Doku bzgl. RPCoverHTTPS stehen, dass die Authentifizierungsmethode auf Standardauthentifizierung stehen muss, zumindest bei RPC. Gibt es da bei OWA jetzt auch was zu beachten? Bin jetzt schon Zuhause aber ich denke das wird vermutlich in der IIS Konfiguration am Exchange eingestellt werden.

    Mir dümpelt da aber auch noch so eine Geschichte mit internen Mac Clients, welche kein AD Konto besitzen, durch den Kopf. Ich hatte früher mal das Problem, dass ich internen Clients immer den Exchange zu den für die Anmeldung erlaubten Hosts hinzufügen musste und das geht ja offensichtlich schlecht, wenn kein AD Konto existiert und da war die Lösung das Umstellung der Authentifizierungsmethode auf ... lange in Google Groups gesucht ... auf die Standardauthentifizierung und Deaktivierung der NTLM Authentifizierung (Groups: http://tinyurl.com/434o5kd) Demnach sollte das auch am Exchange schon so passen.

    Irgendwie redet niemand mehr über RPCoverHTPPS, gibts das so noch bzw. später im Exchange 2010?

    Thx & Bye Tom

    Montag, 18. Juli 2011 16:41
  • Hi,

    bei Exchange 2003 stellst Du das im Exchange System Manager ein - Server - Protokolle - virtueller HTTP Server. Der DS2MB Prozess schreibt dann die im AD eingétragenen Einstellungen in die Metabase vom IIS!
    Die Einstellung mit den MAC Clients, welche kein AD Konto haben kann eigentlich nur die berechtigung meinen, ueber den Exchange relayen zu duerfen. Da musst Du dann im Exchange System Manager der IP des MAC des relayen ueber den virtuellen SMTP Server erlauben.
    OWA/OA funzt auch mit nicht Domenen PC, man muss halt nur auf das Zertfikat achten, dass dieses gegen eine Trusted Root CA verifiziert werden kann und der CN korrekt ist.
    RPCoverHTTPS hiess es bis Exchange 2003. seit Exchange 2007 hat Microsoft RPC over HTTPS in Outlook Anywhere umbenannt - klingt schoener und ist fuer Entscheider besser zu verstehen :-)
    Die Technik ist bis auf kleine Unterschiede in Exchange 2007/2010 die gleiche wie in 2003


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 18. Juli 2011 16:55
  • Hi,

    > bei Exchange 2003 stellst Du das im Exchange System Manager ein - Server - Protokolle - virtueller HTTP Server.

    > Der DS2MB Prozess schreibt dann die im AD eingétragenen Einstellungen in die Metabase vom IIS!


    Okay, wusste ich nicht, wir haben das damals direkt im IIS gemacht, wie dem auch sei, es klappt ja aber ich schau mir das morgen mal an.

     

    > Die Einstellung mit den MAC Clients, welche kein AD Konto haben kann eigentlich nur die berechtigung meinen,

    > ueber den Exchange relayen zu duerfen. Da musst Du dann im Exchange System Manager der IP des MAC des

    > relayen ueber den virtuellen SMTP Server erlauben.

     

    Negativ, Entourage (der Microsoft Mail Client aus der Office Suite 2008 für Mac) basiert auf OWA und ist demnach nichts anderes als ein aufgemotztes OWA Frontend, welches noch so Features wie Offline Store etc besitzt. Angeschlossen an den Exchange wird das über die OWA URL, anmelden tut sich natürlich ein AD-Useraccount, der einen Alias am Exchange hat. Ein Relay brauchts da nicht dafür, der User könnte genau so gut über einen Browser auf sein Konto zugreifen aber weder Safari noch Firefox machen da wirklich Spaß. Der einzige Unterschied zum ISA/TMG veröffentlichten OWA besteht darin, dass der Zugriff eben nicht über den ISA/TMG stattfindet, wie sonst üblich, wenn OWA benutzt wird, sondern eben direkt auf den Exchange zugegriffen wird.

    BTW: Office 2011 für Mac hat wieder ein vollwertiges Outlook am Start aber dafür brauchts einen Exchange 2010 (bzw. mindestens 2007) und auf dem neuen Lion Mac OS läuft eh nur noch Office 2011, deswegen jetzt auch die Runderneuerung an allen Ecken. Der W2K DC muss weg, ein W2K8R2 DC muss her und der alte ISA will dann nicht mit Exchange 2010 usw. usf. Aber ich will nicht meckern, im Vergleich zu dem wie sich Apple so das Leben zukünftig vorstellt, ist Microsoft wirklich noch sympathisch. Das sind hochnäsige und arrogante Diktatoren, so was kannst du dir nicht vorstellen.

    Ich schau mir das morgen mal alles noch mal an.

    Thx & Bye Tom


    Montag, 18. Juli 2011 17:45
  • Hi,

    alles klar, mangels jemals Mac in der Hand gehabt zu haben basierte meine Aussage auf Vermutung, hatte mit der Aussage "ich internen Clients immer den Exchange zu den für die Anmeldung erlaubten Hosts hinzufügen musste" angenommen, dass Du damit das Relaying am SMTP Server meinst. Auf was bezieht sich denn diese Aussage genau? Wo muss man was eintragen? Bin neu- und wissbegierig. 


    regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
    Montag, 18. Juli 2011 18:02
  • alles klar, mangels jemals Mac in der Hand gehabt zu haben basierte meine Aussage auf Vermutung, hatte mit der Aussage "ich internen Clients immer den Exchange zu den für die Anmeldung erlaubten Hosts hinzufügen musste" angenommen, dass Du damit das Relaying am SMTP Server meinst. Auf was bezieht sich denn diese Aussage genau? Wo muss man was eintragen? Bin neu- und wissbegierig.

    das Problem hatte erst mal nichts mit Mac zu tun, das hat nahezu jeden Client betroffen, der sich im internen LAN über OWA mit dem Exchange verbinden wollte. Nahezu deswegen, weil es erst mal nur sporadisch auftrat. Es konnte aber festgestellt werden, dass die User, welche sich gemäß ihrer AD Konfiguration an allen Arbeitsstationen anmelden durften, davon nicht betroffen waren. Alle anderen User mussten im AD den Exchange in der Liste der zur Anmeldung erlaubten Stationen stehen haben, was erst mal nicht befriedigend gewesen ist. Das ganze wurde in unserem Setup dadurch verursacht, dass in der Exchange OWA IIS Konfiguration beide Authentifizierungsmethoden (NTLM (bzw. integrierte Windows Authentifizierung) und Standardauthentifizierung) aktiviert waren. Nachdem wir die NTLM Authentifizierungsmethode im IIS abgewählt hatten und nur noch die Standardauthentifizierung aktiv gelassen haben, war das Problem behoben.

    Soweit ich mich noch daran erinnere, habe ich damals herausgefunden, dass beim Mischbetrieb der beiden Methoden zuerst die stärkere integrierte Windows Authentifizierung (NTLM) verwendet wird, was vermutlich mehr Parameter des Useraccounts abfrägt, anstatt nur das Passwort zu verifizieren. Bei der Standardauthentifizierung scheint das jedoch nicht der Fall zu sein. Zumindest habe ich das so aus dem Verhalten abgeleitet. Laut Spezifikation unterscheidet sich die Standardauthentifizierung zur NTLM basierten Authentifizierung ja erst mal nur dadurch, dass die Anmeldeinformationen bei der Standardauthentifizierung nicht verschlüsselt übertragen werden, was bei SSL ja vernachlässigt werden kann, ob dahinter aber noch andere Argumente oder Parameter eines Benutzerobjekts berücksichtigt bzw. vernachlässigt werden, kann ich abschließend nicht mit Sicherheit sagen; den Anschein hatte es aber...

    Bye Tom

    Montag, 18. Juli 2011 18:39