locked
Outlook Anywhere über Client-Zertifikate? RRS feed

  • Frage

  • Hi,
     
    funktioniert die Authentifizierung von OutlookAnywhere via ISA/TMG gegen
    Ex2010 mit Client-Zertifikaten abzusichern?
     
    Im Exch7/10 sehe ich nur Basic/NTLM zur Auswahl.
     
    Oder auch: Welche Möglichkeit(en) habe ich, um sicher zu stellen, dass
    Outlook Anywhere nur von den auserwählten Client-PCs (z.B. durch Ausstattung
    mit Client-Zertifikat) funktioniert?
     
    Gibt es dazu Dokus? Ich bin nicht fündig geworden...
     
    --
     
    Besten Dank,
    Jens
     
     

    Regards, Jens Klein
    • Bearbeitet Robert Breitenhofer Dienstag, 5. Oktober 2010 07:44 Titel wurde Quoted-Printable decoded
    Freitag, 3. September 2010 09:38

Alle Antworten

  • Hi Jens,

    Outlook Anywhere geht nur mit Benutzername und Kennwort, da Outlook nicht die Möglichkeit bereitstellt ein Zertifikat auszuwählen.

    Eine Einschränkung auf Clients geht leider nicht wirklich mit TMG, mit UAG sollte da mehr machbar sein.

    Gruß

    Christian

     

     


    Christian Groebner MVP Forefront
    Freitag, 3. September 2010 09:42
  • moin jens,

    mit den boardmitteln von tmg geht's nicht. bei einem kunden haben wir mal was mit ipsec drunter "gebastelt".

    bei uag kannst du passende endpoint-richtlinien ablaufen lassen und somit die clients beschränken imho.


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 3. September 2010 09:45
  • aber alternativ kannst du natürlich ein client-2-site-vpn bauen, dies mit zertifikaten absichern und nur den zugriff auf den exchanger limitieren. ist dann zwar kein outlook anywhere im klassischen sinne, würde aber gehen!
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Freitag, 3. September 2010 10:23
  • Hallo Jens,
     
    von dieser VPN-Lösung möchte man ja weg.
     
    Vielen Dank für die Infos.
     
    Jens Klein
     
     

    Regards, Jens Klein
    Montag, 6. September 2010 07:41
  • Hi,

    dann bleibt Dir nur UAG und die Endpoint Detection Policies. Damit kannst Du prima fuer Windows, MAC und *NIX Clients festlegen, welche Voraussetzungen erfuellt sein muessen, damit Clients eine Verbindung aufbauen koennen.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Montag, 6. September 2010 07:52
  • Hallo Marc,
     
    wie bringe ich den meinem Outlook-Client bei, dass er ein Cert hochzeigen
    soll, wenn er EAS startet?
    Da steht doch nur Standard- und NTLM-Auth. zur Auswahl?
     
    --
     
    Besten Dank,
    Jens
     
     

    Regards, Jens Klein
    Montag, 6. September 2010 08:40
  • Hi,

    gar nicht, weil Outlook das nicht kann, aber du könntest mit UAG Client-Policys festlegen, um so die Clients auf bestimmte Clients festzulegen.

    Gruß

    Christian


    Christian Groebner MVP Forefront
    Montag, 6. September 2010 08:42
  • Hi,

    Wie Christian anfangs schon schrub, kannst Du im OA kein Zertifikat hinterlegen, aber mit Hilfe von UAG kannst Du in den Endpoint Policies fetlegen, welche Richtlinien ein Client erfuellen muss. Beim ersten Aufruf des Clients werden dann die UAG Endpoint Detection Komponenten installiert und damit kannst Du dann UAG seitig alles festlegen was das Herz begehrt udn die Clients einschraenken. Schau mal wegen UAG:
    http://www.it-training-grote.de/download/Forefront-UAG.pdf


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Montag, 6. September 2010 08:58
  • Hi ihr beiden,
     
    >>> wie bringe ich den meinem Outlook-Client bei, dass er ein Cert
    >>> hochzeigen
    >>> soll, wenn er EAS startet?
    >>> Da steht doch nur Standard- und NTLM-Auth. zur Auswahl?
    [..]
    >> dann bleibt Dir nur UAG und die Endpoint Detection Policies. Damit kannst
    >> Du prima fuer
    >> Windows, MAC und *NIX Clients festlegen, welche Voraussetzungen erfuellt
    >> sein muessen,
    >> damit Clients eine Verbindung aufbauen koennen.
    [..]
    > gar nicht, weil Outlook das nicht kann, aber du könntest mit UAG
    > Client-Policys festlegen,
    > um so die Clients auf bestimmte Clients festzulegen.
     
    ich werfe jetzt einfach mal folgende Stichworte in den Raum und Ihr sagt
    mir, ob das für euch praktikabel wäre:
     
    Outlook Anywhere over:
     
    IPsec + Client-Certs und DirectAccess//VPN
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Montag, 6. September 2010 08:58
  • Hi Tobias,

    DirectAccess waere geil, zumal Du dann schon die NTLM/Kerberos Authentifizierung mit Client Zertifikaten fuer die beiden DirectAccess Tunnel hast.
    TMG kann auch DirectAccess "publishen". Sehe als einzigen Haken bei DirectAccess nur, dass die Implementierung recht aufwaendig ist und man zwei Public IPv4 IPs braucht, welche auch IP technisch aufeinander folgen muessen.
    Das ganze koennte man dann sogar ohne Forefront UAG realisieren.


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Montag, 6. September 2010 09:08
  • Hi Marc,
     
    > DirectAccess waere geil,
     
    nanana, da ist aber jemand scharf auf DA.. ;)
     
     
    > Sehe als einzigen Haken bei DirectAccess nur, dass die Implementierung
    > recht aufwaendig ist
     
    Nicht aufwendiger als z.B. RPCoverHTTPs
     
    Der EBSv2 hätte und evtl. einer der nächsten SBS wird DirectAccess
    vorkonfiguriert haben, und dass nur bei einer IP (s.u.)
     
     
    > und man zwei Public IPv4 IPs braucht, welche auch IP technisch aufeinander
    > folgen muessen.
     
    Braucht man nur, wenn man alle Features von DA benötigt - DA über IP-HTTPS
    benötigt nur 1 IP und ist zwar nicht so performant wie die anderen
    Verbindungsmöglichkeiten (da HTTPS-Konvertierung) aber ausreichend für viele
    Unternehmen.
     
    S.a.: DirectAccess-Handbuch für Erstbenutzer - Konnektivität
    http://technet.microsoft.com/de-de/library/dd637795.aspx
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Montag, 6. September 2010 09:31
  • ipsec + clients zertifikate (ohne da) hatte ich oben schon erwähnt. funzt, so einem die mtu nicht in die suppe spuckt (wie bei meinem kunden kürzlich).
    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 6. September 2010 09:34
  • Hi Tobias,

    na klar, DA ist cool :-)
    http://www.it-training-grote.de/download/FF-UAG-DA.pdf
    Sicherlich waere IP-HTTPS eine Alternative und ist ja auch der letzte Fallback von DA nach 6to4 und Teredo, aber die Performance Einbussen liegen bei gefuehlten 40-60% bei getesteten Dateitransfers.
    Und ich finde eine DA Implementierung nicht vergleichbar mit RPCoverHTTPS, das mag aber gefuehlt sein, wenn man RPCoverHTTPS schon Dutzende Male implementiert hat :-)
    EBSv2? Cool, wird das eingestampfte Produkt nun doch wieder neu belebt?


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Montag, 6. September 2010 09:36
  • ebs v2 wäre o.k. - solange sie nur nicht tmg auf sbs wieder hauen!

    hihi - gelle tobias?!

    *ggg*


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 6. September 2010 09:40
  • Hi Marc,
     
    > Sicherlich waere IP-HTTPS eine Alternative und ist ja auch der letzte
    > Fallback von DA nach 6to4 und Teredo,
    > aber die Performance Einbussen liegen bei gefuehlten 40-60% bei getesteten
    > Dateitransfers.
     
    Wer es performanter braucht, muss investieren. Wer mit einer
    Basis-Versorgung (übergangsweise) leben kann, nimmt den kleinsten Nenner.
     
     
    > Und ich finde eine DA Implementierung nicht vergleichbar mit RPCoverHTTPS,
    > das mag aber gefuehlt sein,
    > wenn man RPCoverHTTPS schon Dutzende Male implementiert hat :-)
     
    Wenn ich mir ab und an die fehlerhaften RPCoverHTTPS-Implementierungen und
    dessen Fragesteller anschaue, ist für manche selbst das noch
    "Rocket-Science".. ;)
     
    Es gibt für beides jedoch ausgiebige Implementationsguides (fundiertes
    Basiswissen zu Netzwerktechnologien vorausgesetzt)
     
     
    > EBSv2? Cool, wird das eingestampfte Produkt nun doch wieder neu belebt?
     
    nein, leider nicht (das ich wüsste). Es wäre ein klasse Produkt geworden,
    aber vermutlich durch die einsichtige "to-the-Cloud" Brille von Microsoft
    leider eingestampft.
     
    Dabei wären vorbereitete VMs (im OV-Format - s.
    http://en.wikipedia.org/wiki/Open_Virtualization_Format - wie zeitweise
    angedacht) für eine andere "to-the-cloud" Strategie, nämlich IaaS -
    "Infrastructure as a Service"
    (s.a.http://de.wikipedia.org/wiki/Everything_as_a_Service oder. ) geradezu
    ideal gewesen. Einfach die nötigen Infrastrukturdienste nach Best Practice
    in einer virtuellen Umgebung (egal ob "on premise", "private cloud" oder
    "external cloud") ausgerollt, noch an die gewünschten Gegenbenheiten
    angepasst und los gehts, ohne viel immer wiederkehrende. gleichbleibende und
    deswegen standardisierbaren Vorarbeiten, was kosten spaart und
    Implementierungs- und Sicherheitsfehler minimiert.
     
    Aber nun denn, müssen wir halt noch ein bischen drauf warten.. ;)
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Montag, 6. September 2010 10:08
  • Hi,
     
    >aber die Performance Einbussen [...]
     
    Da kann ich nur zustimmen, leider.
    Jungs, danke für die Infos!
     
    Nächste Frage:
    Wer hat schon den UAG ohne Dom-Mitgliedschaft (geht das überhaupt?) in der
    DMZ hinter anderer Firewall (CP) stehend mit RPCoverHTTPS und
    Client-Zertifikaten eingerichtet?
     
    Oder auch: Wird der UAG langsam mehr eingesetzt oder ist es eher wie beim
    IAG die seltene Ausnahme?
     
    --
     
    Besten Dank,
    Jens
     
     

    Regards, Jens Klein
    Montag, 6. September 2010 10:26
  • moin jens,

    uag muss domain-member sein!

    die anfragen häufen sich - iag hatte ich vlt. 5 anfragen seit rtm. 5 anfragen zu uag hatte ich alleine schon im ersten quartal 2010. somit schlage ich mich wie marc momentan mit dem gerät herum wie man so schön sagt.

    ;-)


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 6. September 2010 10:29
  • Hi,

    Ne, UAG geht nur mit Domain Member. Anfragen bzgl. UAG werden immer merh und das Schattendasein des IAG Nachfolgers scheint ein Ende zu haben.
    Eine RPCoverHTTPS Implementierung mit UAG ist sehr stark dem Assistenten von ISA/TMG angelehnt, nur die erweiterten Moeglichkeiten sind betraechtlich!


    regards Marc Grote aka Jens Baier - www.nt-faq.de - www.it-training-grote.de - www.forefront-tmg.de
    Montag, 6. September 2010 10:45
  • Hi,
     
    > UAG werden immer mehr und das Schattendasein des IAG Nachfolgers scheint
    > ein Ende zu haben.
    das ist auch mein Eindruck. Die Anfragen kommen unerwartet oft. Also werd
    ich's mir wohl auch anschauen.  :-)
     
    --
     
    Besten Dank,
    Jens
     
     

    Regards, Jens Klein
    Montag, 6. September 2010 11:21
  • tu das - viel spass damit!

    ;-)


    gruss, jens mander aka karsten hentrup - www.aixperts.de - www.forefront-tmg.de - www.hentrup.net |<-|
    Montag, 6. September 2010 11:23