Outlook mit RPC over HTTPS funktioniert nach Migration nicht

[RobertWi 81]

Im IIS ist das Zert2 für https eingetragen. Unter Exchange 2003 und Outlook2010 lief es einwandfrei.

 

Ja klar, weil Exchange 2003 auch kein Autodiscover kennt und die Nicht-Postfach-Daten (=OAB F&B, usw.) aus öffentlichen Ordnern kommen.

 

Wenn ich das richtig verstanden habe, brauchen wir auf Zert2 noch den DNS Namen von Zert1, damit Outlook ohne Fehlermeldung startet ...

 

Das wäre eine mögliche Lösung, die aber möglicherweise dadurch erschwert wird, dass man Zertifikate mit internen URLs nicht mehr bei externen CAs kaufen kann.

 

Wie gesagt, ist eine kurze Antwort nicht möglich. Eventuell holt ihr Euch mal jemanden ins Haus, der das geradezieht und dann auch ausführlich erklärt. Denn offensichtlich liegen die Probleme nicht in der technischen Umsetzung, sondern im Verständnis davon. Und da hat sich zwischen Ex2003 und Ex2010 zu viel verändert, dass man das alte Wissen nur begrenzt nutzen kann.

[Dutch_OnE 36]

Hallo Robert,

 

kennst Du jemanden den man fragen kann, bzw. kann man Deine Dienstleistung buchen?

[RobertWi 81]

Moin,

 

ich mache das zwar grundsätzlich, bin nur zur Zeit so voll ausgelastet und sitze bei einem Kunden vor Ort, dass ich zwar gut nebenbei im Internet tippen kann (und sogar darf), aber nicht telefonieren und keine Fernwartungs-Tools verwenden darf.

[Worti 10]

moinsen,

 

Bei der Zertifikatsinstallation auf dem Exchange wurden neben dem Zert2 auch die thawte Zertifikate installiert?
Ansonsten ist das Zertifikat drin, dennoch nicht gültig weil der Herausgeber nicht verifiziert werden kann.

Bei der Fehlermeldung im Outlook auf den Clients:

Diese kommt, weil im IIS das Zert2 drin ist, respektive der Interne Name nicht darauf aufgeführt ist. Ein wechsel auf das Zert1 im IIS würde zwar die Fehlermeldung unterbinden, allerdings wäre dann im OWA die Meldung: Es besteht ein Problem mit dem Sicherhitszertifikat.

 

Lösungsansatz bei einem Zertifikat:

Das Zert2 aus dem Exchange Exportieren. Danach eine GPO erstellen, welche das Zertifikat auf den Clients in den vertrauenswürdigen Stammzertifikatsordner installiert.
Eventuell musst Du das thawte Primary Root CA, Thawte Premium Server CA gleich verteilen, da sonst das Zert zwar kopiert wird, aber die Clients dennoch nichts damit anfangen können weil sie den Herausgeber nicht kennen.

 

Damit kommt die Fehlermeldung beim Start von Outlook nicht mehr. GPO Aktualisieren nicht vergessen, wenn es erneuert wird.

 

Bei den Empfangsproblemen:

Im Exchange unter Serverkonfiguration, Hub-Transport, Empfangsconnectors den IP und Port Bereich Prüfen. Eventuell Port 587?

 

Gruss

[RobertWi 81]

Moin,

 

Lösungsansatz bei einem Zertifikat:

Das Zert2 aus dem Exchange Exportieren. Danach eine GPO erstellen, welche das Zertifikat auf den Clients in den vertrauenswürdigen Stammzertifikatsordner installiert.

 

das Kopieren eines "normalen" Zertifikates in die vertrauenswürdigen Stammzertifizierungsstellen ist nicht supportet (genauso wie die Nutzung eines Self-Sigened-Zertifikates). Es kann daher jetzt funktionieren und mit einem Update morgen nicht mehr.

 

Die saubere, supportete und sichere Lösung lautet daher, Namen im Zertifikat und URLs zueinander passend zu machen.

[Dutch_OnE 36]

Moin ...

 

Ich habe gestern es soweit eigentlich selbst hinbekommen.

1) Der Exchange war an ein Relay angebunden, welches den neuen Server nach der Umstellung noch nicht authorisiert hatte. D.h. alle Mails kommen nun an.

2) Zertifikat wollte ich ein UCC Multidomain von der PSW-Group nehmen.

 

 

Nun haben die mir erzählt, dass aber 2016 wohl keine *.local Domain Namen mehr genommen werden dürfen.

Ich habe auf allen meinen Server grundsätzlich noch *.local eingesetzt.

 

Laut diesem Link http://community.certbase.de/blogs/mg/archive/2008/12/07/umbenennen-einer-windows-server-2008-active-directory-dom-228-ne.aspx kann man die Domäne ja umbenennen. Hat das schon mal jemand gemacht?

 

Ist es überhaupt empfehlenswert seine Domain.local in eine Domain.de zu ändern?

 

Gruß Daniel

[RobertWi 81]

Moin,

 

das umbenennen von Domänen mit Exchange ist nicht supportet und führt i.d.R. zum Totalverlust.

 

Das ist aber auch nicht notwendig. Durch geschickten Einsatz von SplitDNS, zusätzlichen Namen im DNS und eventuell CNAME/SRV-Einträge kann man das auch nachträglich lösen. Ist nur aufwendiger, als vorher.

[Dutch_OnE 36]

Anbei mal meine aktuelle Situation:

 

kunde.de sei die lokale Domäne

extDomain.de ist eine Webseite, bei der der A-Rekord auf meine offizielle IP zeigt. Wird z.B. für Webaccess genutzt. (https://extDomain.de/owa)

mailDomain.de ist die richtige E-Mail Domäne.

 

Für die Domäne extDomain habe ich ein offizielles Zertifikat von psw-group.

Dort steht aber nur der Name https://extDomain.de, was dazu führt, wenn ich dieses im IIS einbinde, dass OWA ok ist, aber die lokalen Outlook Verbindungen und Https over RPC jeweils eine Fehlermeldung werfen.

 

Frage: Reicht das Zertifikat mit diesem einen Eintrag überhaupt?

Oder müssen dort weitere wie z.B. autodiscover, lokaler Servername, usw. rein?

 

Gibt es eine alternative Möglichkeit dieses mit dem srv Eintrag zu ermöglichen?

 

 

 

Gruß Daniel

bearbeitet 15. Januar 2013 von Dutch_OnE

[Dutch_OnE 36]

Hallo Robert,

 

nun habe ich die DNS Zone extDomain.de auf meinem DNS Server angelegt. Dort habe ich nach Anleitung den SRV Eintrag hinzugefügt.

Wenn ich nslookup aufrufe und den query auf srv mache, bekomme ich bei _autodiscover._tcp.extDomain.de als srv Hostname meinen lokalen Server mit fqdn angezeigt.(mail-server.kunde.de)

 

Wenn ich nun Outlook im LAN starte kommt aber weiterhin eine Zertifikatsmeldung. (Der Name auf dem Sicherheitszertifikat ist ungültig ...)

Es steht ganz oben mail-server.kunde.de, während auf dem Zertifikat ja nur extDomain.de steht. Dachte das dafür der srv Eintrag da ist.

 

Dementsprechend funktioniert das Outlook mit HTTPS over RPC auch nicht.

 

Habe ich etwas falsch gemacht, bzw. muss ich einfach nur länger warten bis das DNS richtig greift?

 

Gruß Daniel

[RobertWi 81]

Hallo Daniel,

 

interne Clients (= AD-Clients) raten Autodiscover nicht im DNS, sondern bekommen über AD den sog. SCP mitgeteilt:

 

 

Get-ClientAccessServer | ft Name,Autodiscoverserviceinternaluri -Autosize

 

Damit siehst Du die SCP-Adresse, die muss dann natürlich auch angepasst werden und in DNS stimmen.

[Dutch_OnE 36]

Guten Morgen,

 

ich habe die Abfrage ausgeführt und folgendes Ergebnis bekommen.

 

Name:

Mail-Server

AutoDiscoverServiceInternalURL:

https://mail-server.kunde.de/autodiscover/autodiscover.xml

 

Wenn ich den jetzt auf https://extDomain.de/autodiscover/autodiscover.xml drehe dann läuft die Abfrage doch eigentlich ins Leere, da es diese URL ja nicht gibt. Aber durch den A-Record komme ich dann zurück zu meiner IP und dann über SRV Eintrag auf meinen Server.

 

Habe ich das soweit richtig verstanden?

 

Im Internet findet man Anleitungen, was echt unglaublich ist.

z.B. im IIS die Clientzertifikate für RPC ignorieren

oder mit set-outlookprovider den certprincipal Namen überschreiben ;)

 

Geholfen hat das jedenfalls nichts.

 

Gruß Daniel

[RobertWi 81]

Der AD-Client nimmt die URL aus dem SCP und landet gar nicht beim SRV. Der SRV heißt ja "_autodiscover._tcp.domäne.de" und die URL heißt "extdomain.de".

[Dutch_OnE 36]

Ich habe folgendes herausgefunden:

 

test-outlookwebservices hatte einen Fehler für die externe URL im EWS.

Das lag an einem Routingproblem, denn die Anfrage von intern ist beim Router gelandet und nicht beim Mail-Server.

Nachdem das korrigiert war funktionieren die Webservices einwandfrei.

 

Danach habe ich dann:

Set-ClientAccessServer mail-server2010 -AutoDiscoverServiceInternalUri https://extDomain.de/Autodiscover/Autodiscover.xml

ausgeführt.

 

Das Outlook macht aber leider immer noch den Zertifkatfehler. Er erwartet mail-server.kunde.de und es steht extDomain.de im Feld "Ausgestellt für"

bearbeitet 16. Januar 2013 von Dutch_OnE

[RobertWi 81]

Outlook ruft ja nicht nur Autodiscover auf, sondern auch andere URLs (Verfügbarkeitsdienst, OAB, EWS). Diese URLs musst Du auch anpassen.

 

Am besten mal in Outlook via "E-Mail-Autokonfiguration testen..." überprüfen.

[Dutch_OnE 36]

Outlook Auto Konfiguration -> Erfolgreich ...

 

Ich habe auch schon für die 3 "Bereiche" EXPR, EXCH, WEB auch den CertPrincipalName auf extDomain.de geändert.

Die anderen URLs sind intern auf mail-server.kunde.de und extern auf extDomain.de gestellt. (die verschiedenen Unterordner natürlich angepasst)

 

 

HTTPS over RPC funktioniert nun auf einmal.

Ich habe im Outlook die Exchange Proxyeinstellungen auf Standardauthentifzierung gestellt und dort noch im Proxy msstd:extDomain.de eingetragen.

 

Nur wird jetzt in den LAN Outlook noch die Zertifikatsfehlermeldung angezeigt.

bearbeitet 16. Januar 2013 von Dutch_OnE