Sicherheitshinweis SSL-Zertifikat Outlook 2013 in Verbindung mit Exchange 2013

[MHeiss2003 11]

Hallöchen,

leider komme ich bei einem Kunden nicht weiter. Das Szenario sieht wie folgt aus: 2012 R2 DC, 2012 R2 Server mit Exchange 2013 Standard, 20 Win 8.1 Pro Client mit Outlook 2013.

Ich habe bei DF ein Wildcard Zertifikat geordert, dass auf *.kundendomain.com lautet. Den Antrag hierzu habe ich über die Exchange Verwaltungskonsole durchgeführt. Ausgewählt hatte ich das Platzhalterzertifikat mit der Stammdomäne kundendomain.com

Nachdem ich das Zertifikat wieder über die Exchange Verwaltungskonsole eingespielt hatte, fingen die Probleme bei den Clients an. Es erscheint in regelmäßigen Abständen, vor allem aber kurz nach der Anmeldung bzw. dem Öffnen von Outlook, ein Sicherheitshinweis, der mit sagt, dass der Server nicht mit dem Namen der Webseite auf dem Zertifikat übereinstimmt. Das ist auch so bestätigt, denn die Meldung spricht ganz oben in diesem Hinweisfenster von dem internen Server srv05.internedomaene.local und auf dem Zertifikat steht ja der externe Name.

Über Get-Outlookprovider bekomme ich als Server srv05.internedomaene.local und Als Prinzipalname msstd:*.kundendomain.com

Habe auch schon den Artikel auf www.it-dienstleistungen.de mit dem Thema "MS Exchange Problem: Servername und Name im Zertifikat stimmen nicht überein" durchgearbeitet, allerdings kann ich den Punkt "AutoDiscoverVirtualDirectory" nicht ausführen, da es diese Funktion offensichtlich in Exchange 2013 nicht mehr gibt, wie ich in einem TechNet gelesen habe.

Was kann ich tun, damit diese Meldungen endlich verschwinden?

 

Danke und Grüße

Mario

bearbeitet 19. Mai 2014 von MHeiss2003

[testperson 1.680]

Hi,

 

SplitDNS konfigurieren und die URLs der virtuellen Verzeichnisse entsprechend konfigurieren.

Set-/Get-AutoDiscoverVirtualDirectory gibt es seit Exchange 2013 nicht mehr.

 

Gruß

Jan

[MHeiss2003 11]

Hi,

 

danke erst mal für Deinen Ansatz.

Auf dem DNS-Server existiert bereits eine eigene Zone, die auf den externen Namen lautet, also "remote.kundendomain.com" in der sich wiederum ein Host mit der internen Server IP befindet, das sollte die Split.-DNS Konfiguration sein. Kläre mich bitte auf, wenn ich hier irgendwas falsch verstehe. Pinge ich von intern die externe Url "remote.kundendomain.com" erhalte ich die korrekte interne IP-Adresse zurück.

Meinst Du mit URL der virtuellen Verzeichnisse alle? Die sollen dann wohl alle auf "remote.kundendomain.com" laufen und keine Unterscheidung mehr nach intern und extern vornehmen?

 

Grüße

[testperson 1.680]

Hi,

 

ja korrekt. Und ebenfalls: Set-ClientAccessServer -Identity <CAS01> -AutodiscoverServiceInternalUri https://remote.kundendomain.com

 

Gruß

Jan

[RobertWi 81]

Moin,

 

Du musst auch die URLs für den Webservices und das OAB korrekt konfigurieren. Die und den Autodiscover SCP (Set-ClienAccessServer) brauchst Du für Outlook zwingend.

 

Außerdem solltest Du die OWA- und ECP-URL anpassen. Die brauchst Du zwar nicht zwingend für Outlook, die URLs werden aber an anderen Stellen eingeblendet (z.B. im Backstage-Bereich von Outlook).

[MHeiss2003 11]

Danke auch Dir RobertWi. Ist der CAS01 der Exchange Server selber?

 

Ich beantworte meine Frage gleich selber, sorry: Nachdem wir einen Exchange Server mit Client Access haben, ist es in unserem Fall der Exchange Server, der hier zu verwenden ist. Habe den Set-ClientAccessServer Befehl abgesetzt.

Wenn ich nun Get-ClientAccessServer -Identity "Cas-01" | ft AutoDiscoverServiceInternalUri eingebe erhalte ich:

https://remote.kundendomain.com

 

Die virtuellen Verzeichnisse bis auf Powershell habe ich alle auf https://remote.kundendomain.com angepasst.

 

Sollte es das gewesen sein?

 

Vielen Dank an Euch.

bearbeitet 19. Mai 2014 von MHeiss2003

[RobertWi 81]

Ja. ;)

 

Wenn alle Deine CAS-Server im gleichen AD-Standort sind, ist das einfacher:

 

Get-ClientAccessServer | Set-ClientAccessServer -AutodiscoverServiceInternalUri https://remote.kundendomain.com

[testperson 1.680]

In deinem Fall vermutlich ja.

[MHeiss2003 11]

Hallöchen,

leider muss ich das Thema nochmals aufwärmen. Die Probleme haben sich leider nicht aufgelöst. Folgende Probleme existieren momentan noch:

 

1. Outlook 2013 meldet beim Einrichten eines neuen E-Mail Profils mit Exchange Konto in der Domäne folgendes: "Fehler beim Anmelden. Überprüfen Sie die Netzwerkverbindung sowie den Server- und Postfachnamen. Es steht keine Verbindung mit Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbinden sein, um diesen Vorgang abzuschließen".
2. Einige bereits eingerichtet Konten über Outlook 2013 keine Kalendereinträge anderer Benutzer sehen, trotz Berechtigung, oder aber Sie können den Abwesenheits Assistenten nicht benutzen.
    Über OWA funktioniert der Assistent problemlos und ohne Fehler.

zu 1.: Wenn ich in die manuelle Konfiguration des Exchange Kontos gehe, dann fehlen bei "Weitere Einstellungen | Verbindungen" sämtliche Einträge bzw. ist erst gar kein Haken gesetzt bei "Verbindung mit Microsoft Exchange über http herstellen. Setze ich den Haken und ergänze die Informationen "Exchange-Proxyserver" mit "remote.kundendomain.com" und "Prinzipalnamen" mit "msstd:remote.kundendomain.com", dann klappt die Verbindung zum Exchange sofort und ohne Probleme.

 

Was muss ich tun, damit diese Einträge auch gesetzt werden? Offensichtlich braucht das Konto die Einstellungen zum Zugriff selbst intern. Von Exchange 2010 bin ich das zwar anders gewohnt, vielleicht liegt aber auch ein Konfigurationsfehler vor?

 

Wäre dankbar für Hilfe.

 

Danke Euch.

Mario

 

 

Problem gelöst.

 

 

 

Die Lösung enthalte ich Euch nicht vor.

 

Get-ClientAccessServer | ft

 

Hier war AutoDiscoverServiceInternalUri auf https://remote.kundendomain.com gestanden

 

Set-ClientAccessServer -Identity 'SERVERNAME CAS' -AutoDiscoverServiceInternalUri "https://remote.kundendomain.com/Autodiscover/Autodiscover.xml"

 

Brachte den gewünschten Erfolg. Outlook verbindet sich nun automatisch intern mit dem Postfach, Kalendereinträge sind ebenfalls aus einem anderen Postfach sichtbar und der Abwesenheits-Assistent funktioniert auch.

bearbeitet 11. Juni 2014 von MHeiss2003

[RobertWi 81]

OK. Jan und ich sind natürlich davon ausgegangen, dass Du Dir vorher den dort eingestellten Wert anschaust und darin nur den Hostnamen änderst, den Rest der URL aber übernimmst. Zumal die Option ja "AutodiscoverServiceInternalUri" heißt, und nicht "AutodiscoverServiceInternalFQDN" oder "AutodiscoverServiceInternalHostname". ;)

 

Das Du einfach nur blind den Befehl übernimmst und die Einstellung damit auf einen komplett falschen Wert setzt, hatte wohl niemand auf dem Schirm. Entschuldige bitte die Verwirrung.