none
SBS 2011 - .local und externe Domäne mit Zertifikaten für EAS/OWA verheiraten RRS feed

  • Frage

  • Ich habe hier einen Small Business Server 2011 Standard ohne Split DNS noch mit einer lokalen Domänenstruktur "domäne.local".



    Nun kommt die Anforderung, dass mobile Endgeräte per EAS mit dem Exchange gekoppelt werden sollen.

    Unter anderem aktuelle iPhones (meines Wissens nach seit IOS 10.3) lassen selbstsignierte Zertifikate nicht mehr zu.

    Bei Exchange Servern außerhalb SBS, welche mit Split DNS konfiguriert sind, ist es eigentlich soweit klar für mich und habe ich auch schon erfolgreich gemacht.

    Bei dem SBS bin ich mir unsicher und würde mich über Hilfestellung freuen.


    Da sich interne Namen ja schon länger nicht mehr in die Zertifikate aufnehmen lassen, stellt sich mir die Frage, welchen Weg ich nun einschlagen kann oder gar muss.


    1. Kann ich die externen und internen URls der Verzeichnisse (OWA, ECP, EAS, OAB, welche vergessen?) auf mail.domäne.de gleichziehen?

    Das Zertifikat müsste dann wohl mail.domäne.de und autodiscover.domäne.de enthalten.

    Ich kenne zwar den Hinweis auf ein Single Name Zertifikat mit dem autodiscover Eintrag via SRV. Aber soweit ich das verstanden habe, wertet wohl primär Outlook diesen aus; Smartphones und andere Anwendungen allerdings im Zweifel nicht. Es ist aber auch nicht das Thema ein Zertifikat mit 2 Namen zu beantragen.

    Allerdings weiß ich nicht, was dann mit der "Sites" Seite in einem SBS Netz passiert, da "Sites" ja nun ebenfalls nicht im Zertifikat aufgenommen werden kann. Dieses Feature wird zwar überhaupt nicht aktiv genutzt, aber ich weiß nicht, ob das dann zu Problemen führen kann.

    Was dann zur 2. Frage führt, ob ich einfach für die internen Namen bzw. "Sites" ein internes Zertifikat bzw. das bestehende einfach weiter nutzen kann und nur für die externen URLs das gekaufte zum Einsatz kommt?!

    Was dann zu letzten Frage führt, wie ich denn die jeweiligen Zertifikate an ihre entsprechenden Dienste binde?

    Der Exchange Assistent zur Bindung der Dienste macht doch intern und extern soweit ich weiß, was ich dann ja vermeiden müsste.

    Gruß


    Freitag, 24. November 2017 15:42

Antworten

  • Hallo Evgenij, 

    danke, dass Du noch mitliest. :-)

    Du hast Recht, ein get-ClientAcessServer verweist noch auf den internen Namen.

    Ich habe an der Stelle mit set-ClientAccessServer nun den neuen Eintrag gesetzt.

    Bei bestehenden Outlook Profilen kommt z.B. bei einem Emailsendevorgang, aber immer noch die Fehlermeldung auf den abweichenden Namen. Eine Erstellung eines neuen Profils bringt ebenfalls keine Besserung.

    Was habe ich übersehen?

    • Als Antwort markiert MyPublicUser Dienstag, 5. Dezember 2017 14:59
    Freitag, 1. Dezember 2017 10:12
  • Lege mal ein neues Profil an. Funktioniert der Autodiscover dabei ordentlich? Wird das Exchange-Profil gefunden und ohne manuelle Hilfe eingerichtet? Wenn ja, bei den betroffenen Usern das Profil neu einrichten.
    • Als Antwort markiert MyPublicUser Dienstag, 5. Dezember 2017 14:57
    Montag, 4. Dezember 2017 18:50

Alle Antworten

  • Moin,

    zwischen selbstsignierten Zertifikaten und solchen aus einer öffentlichen CA stehen noch die Zertifikate aus einer privaten CA. Eine solche hast Du mit dem SBS zwangsläufig am Start und kannst daraus beliebige SAN-Zertifikate ausstellen.

    Das Root-Zertifikat muss auf den iOS-Endgeräten explizit für vertrauenswürdig erklärt werden (Einstellungen - Allgemein - Info - Zertifikatsvertrauenseinstellungen).

    Exchange hat vom Hause aus nicht verschiedene virtuelle Verzeichnisse für intern und extern. Du kannst theoretisch aber welche anlegen, auch wenn ich in diesem Fall davon abraten würde. Split DNS kann man mit SBS durchaus betreiben, so wie Du es oben formuliert hast.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert MyPublicUser Montag, 27. November 2017 12:22
    • Tag als Antwort aufgehoben MyPublicUser Freitag, 1. Dezember 2017 09:45
    Freitag, 24. November 2017 18:55
  • Moin,

    Sorry, war unsauber formuliert von mir. Eigene CA ist mir klar, aber hatte ich nicht erwähnt, da es im Ergebnis (nicht vertrauenswürdig) gleich ist. Die Installation auf den Endgeräten würde ich vermeiden wollen. Dennoch danke für den Hinweis darauf.

    Ok, ich kann also zusammenfassen, dass ich Split DNS auf SBS machen kann, wie man es auf "Standard" Servern nutzt und es gibt keine SBS spezifischen Probleme in dem Zusammenhang (Sites / Companyweb etc).

    Eine angenehme Woche noch. :-)

    Montag, 27. November 2017 10:27
  • Moin,

    muss mich noch einmal melden. Hoffe das liest noch mal jemand.

    Nun ist das Zertifikat auf die Domains mail.domaene.de und autodiscover.domaene.de installliert an alle Dienste im Exchange gebunden, im IIS sehe ich auch die Bindung auf der Default Seite.

    Im DNS des SBS sind die Zonen mail.domaene.de und autodiscover.domaene.de mit Hosteintrag auf die IP des SBS DC/Exchange gesetzt.

    Nun meckert leider Outlook (2010), dass der Name nicht mit dem Zertifikatsnamen übereinstimmt. Dauer und Austeller sind gültig, aber der Name stimmt nicht, da Outlook nicht via mail.domaene.de bzw.  autodiscover.domaene.de drauf zugreift, sondern via dem internen Namen.

    Wie gewöhne ich das Outlook ab?

    Im Verbindungsstatus sehe ich, dass Outlook via RPC/TCP reinkommt. Müsste es nun nicht via HTTPs kommen?


    Freitag, 1. Dezember 2017 09:48
  • Moin,

    nein, interne Clients bekommen bei Exchange 2010 standardmäßig das CASArray-Objekt für den RPC-Zugrif  rausgereicht. Bei RPC spielt aber auch das SSL-Zertifikat keine Rolle. Vermutlich ist es der SCP im AD, der die Autodiscover-URL noch mit dem lokalen Namen zurück gibt. Das musst Du noch anpassen (Set-ClientAccessServer)


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    Freitag, 1. Dezember 2017 10:00
  • Hallo Evgenij, 

    danke, dass Du noch mitliest. :-)

    Du hast Recht, ein get-ClientAcessServer verweist noch auf den internen Namen.

    Ich habe an der Stelle mit set-ClientAccessServer nun den neuen Eintrag gesetzt.

    Bei bestehenden Outlook Profilen kommt z.B. bei einem Emailsendevorgang, aber immer noch die Fehlermeldung auf den abweichenden Namen. Eine Erstellung eines neuen Profils bringt ebenfalls keine Besserung.

    Was habe ich übersehen?

    • Als Antwort markiert MyPublicUser Dienstag, 5. Dezember 2017 14:59
    Freitag, 1. Dezember 2017 10:12
  • Hallo,

    bitte mal abgleichen:

    Get-OwaVirtualDirectory | fl *url*

    mit

    Get-AutodiscoverVirtualDirectory | fl *url*

    Freitag, 1. Dezember 2017 11:06
  • Update:  Die Hosts sollten gleich lauten, sonst meckert OL wegen Abweichung zwischen den CN und SANs im Cert mit den Hostnamen in der Konfiguration.

    Freitag, 1. Dezember 2017 11:08
  • Update 2: Für die SmartPhones hilft es sehr, wenn der SRV-Record beim Provider abgelegt wird, derart dass:

    _autodiscover._tcp.<deine_domain>.<TLD> => <sbs2011-externe-Adresse>

     priority       = 0
     weight         = 5
     port           = 443

    gilt. Damit finden die SmartPhones zum Exhange 2010 schnell und selbst den Weg.

    Freitag, 1. Dezember 2017 11:15
  • get-OwaVirtualDirectory bringt intern und extern die mail.domaene.de

    get-AutodiscoverVirtualDirectory bringt überhaupt keine Einträge.

    Ich dachte letztere hätte ich mit set-ClientAccessServer gesetzt?!

    Freitag, 1. Dezember 2017 12:17
  • Ähm, get-help Get-AutodiscoverVirtualDirectory & get-help Get-ClientAccessServer....

    In Stichworten ein paar Antworten:

    > 1. Kann ich die externen und internen URls der Verzeichnisse (OWA, ECP, EAS, OAB, welche vergessen?) auf mail.domäne.de gleichziehen?

    Ja, alle gleichziehen. Beim SBS beginnt der entscheidende Hostname mit remote.<..> - genau der wird genommen.

    >Das Zertifikat müsste dann wohl mail.domäne.de und autodiscover.domäne.de enthalten.

    Nicht notwendigerweise. - siehe oben, halte dich an remote.

    >Allerdings weiß ich nicht, was dann mit der "Sites" Seite in einem SBS Netz passiert, da "Sites" ja nun ebenfalls nicht im Zertifikat aufgenommen werden kann. Dieses Feature wird zwar überhaupt nicht aktiv genutzt, aber ich weiß nicht, ob das dann zu Problemen führen kann.

    Zu keinen. "Sites" gehört zu SharePoint.

    >Was dann zur 2. Frage führt, ob ich einfach für die internen Namen bzw. "Sites" ein internes Zertifikat bzw. das bestehende einfach weiter nutzen kann und nur für die externen URLs das gekaufte zum Einsatz kommt?!

    Antwort siehe oben und weiter unten.

    >Was dann zu letzten Frage führt, wie ich denn die jeweiligen Zertifikate an ihre entsprechenden Dienste binde?

    Siehe dir die Certs an, welche für Exchange-Dienste verwendet werden mit Get-ExchangeCertificate.

    Erstelle ein Request für ein Cert aus dem IIS mit remote.<>. Erhalte ein Cert von einer CA, schließe den Request im IIS-Manager ab.

    Lege die Dienste des neuen Certs fest, am besten dann wohl alle.

    get-help Enable-ExchangeCertificate -Examples

    Freitag, 1. Dezember 2017 13:10
  • Ähm, get-help Get-AutodiscoverVirtualDirectory & get-help Get-ClientAccessServer....

    Ok, Wink ist angekommen. Ich bin da weiß Gott nicht sattelfest und deswegen für Hilfestellung dankbar.

    Die Urls für das AutodiscoverVirtualDirectory wurden nun intern und extern ebenfalls gesetzt und sind nun somit gleich wie oben von Dir angesprochen.

    >Nicht notwendigerweise. - siehe oben, halte dich an remote.

    Das Zertifikat gibt es ja nun schon und wurde auf mail.<> ausgestellt. Im SBS Manager unter Netzwerk Konnektivität wurde auch mail.<> definiert. Das Webserverzertifikat wird dort ebenfalls als vertrauenswürdig aufgeführt.

    >Zu keinen. "Sites" gehört zu SharePoint.

    Ok. Danke. SharePoint wird nicht genutzt. SBS wurde seinerzeit der günstigen Anschaffung in Bezug auf Exchange gewählt, wie wahrscheinlich bei vielen.

    Der Request wurde aus dem EWS Zertifikats Assistenten beantragt und dort auch beendet. Gebunden an IMAP, POP, IIS, SMTP. 

    Freitag, 1. Dezember 2017 13:39
  • Da hier jetzt doch über einige Post hinweg die Infos von mir so reintröpfeln (sorry), 

    der Lesbarkeit noch einmal eine Zusammenfassung wie Stand der Dinge ist:

    Das Comodo Zertifikat enthält die Domains

    mail.DOMÄNE.de
    autodiscover.DOMÄNE.de

    Die Urls auf dem Exchange lauten nun:

    InternalUrl : https://mail.DOMÄNE.de/Microsoft-Server-ActiveSync
    ExternalUrl : https://mail.DOMÄNE.de/Microsoft-Server-ActiveSync

    InternalUrl : https://mail.DOMÄNE.de/Autodiscover/Autodiscover.xml
    ExternalUrl : https://mail.DOMÄNE.de/Autodiscover/Autodiscover.xml

    InternalUrl : https://mail.DOMÄNE.de/ECP
    ExternalUrl : https://mail.DOMÄNE.de/ECP

    InternalUrl : https://mail.DOMÄNE.de/OAB
    ExternalUrl : https://mail.DOMÄNE.de/OAB

    InternalUrl : https://mail.DOMÄNE.de/EWS/Exchange.asmx
    ExternalUrl : https://mail.DOMÄNE.de/EWS/Exchange.asmx

    AutoDiscoverServiceInternalUri : https://mail.DOMÄNE.de/Autodiscover/Autodiscover.xml


    Im DNS des SBS zusätzlich zur Domäne.local sind weitere 2 Domains

    mail.DOMÄNE.de
    autodiscover.DOMÄNE.de

    angelegt, mit jeweils einem Hosteintrag auf die interne IP des SBS/Exchange Servers.

    Beim Provider sind 2 Subdomains

    mail.DOMÄNE.de
    autodiscover.DOMÄNE.de

    angelegt mit der externen festen IP des SBS/Exchange Servers.

    Im Exchange 2010 Manager wurde der Request angelegt und nach Erhalt des Comodo Zertifikats darüber beendet und an die Dienste Pop/IMAP/SMTP/IIS gebunden.

    Im SBS Manager - Netzwerk - Konnektiviät 

    ... ist das mail.DOMÄNE.de Zertifikat (als vertrauenswürdig) hinterlegt
    ... ist der Internetdomänenname auf mail.DOMÄNE.de festgelegt

    im IIS ist bei den Bindungen zur Default Website auf 443 (*, sowie 127.0.0.1) das mail.DOMÄNE.de Zertifikat gebunden

    Zugriffe per Outlook Anywhere von extern funktionieren
    Zugriffe per EAS (iPhones/iPads) von extern funktionieren.

    Der Microsoft Remote Connectivity Analyzer bestätigt das auch und beendet Exchange Active Sync & Autodiscover, sowie Outlook Connectiviy und Autodiscover erfolgreich.

    DNS extern löst auf externe IP auf.
    DNS intern löst auf interne IP auf.

    OWA funktioniert extern wie intern ohne Fehlermeldung.

    Outlook intern funktioniert grundsätzlich auch, bringt aber eben besagte Zertifikatswarnung wg. abweichendem Namen des erwarteten Servers.
    (Spricht den internen Namen an, statt mail.DOMÄNE.de)

    Der Outlook Verbindungsstatus weist keinen Proxyeintrag auf, sondern nur den internen Servernamen auf. Verbindungsprotokoll ist RPC/TCP.

    Ich hoffe das hilft für eine besseren Überblick.

    Freitag, 1. Dezember 2017 15:56
  • Nach den ganzen Änderungen auch einen Reboot gemacht?

    Ich finde es merkwürdig, dass mail. statt remote. verwendet wird. Könnte gerade bei den SBS-Assistenten zu Problemen führen (muss es aber nicht).

    Freitag, 1. Dezember 2017 17:33
  • Freitag Abend wurde noch ein Reboot gemacht.

    Die Rückmeldungen sind widersprüchlich.

    2 Kollegen bekommen keine Meldung mehr, bei 2 anderen Kollegen taucht sie sehr wohl noch auf.

    Montag, 4. Dezember 2017 14:24
  • Lege mal ein neues Profil an. Funktioniert der Autodiscover dabei ordentlich? Wird das Exchange-Profil gefunden und ohne manuelle Hilfe eingerichtet? Wenn ja, bei den betroffenen Usern das Profil neu einrichten.
    • Als Antwort markiert MyPublicUser Dienstag, 5. Dezember 2017 14:57
    Montag, 4. Dezember 2017 18:50
  • Autodiscover rennt. Da gibt es keine Probleme.

    Ein neues Profil angelegt und bis jetzt keine Warnmeldungen mehr. Ich hoffe es bleibt so.

    Dienstag, 5. Dezember 2017 15:01