Notifications
Clear all

Outlook Client Zertifiaktfehler an Exchange 2016 - findet Zertifikat des Providers  

  RSS

(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
16. Oktober 2020 17:22  

Hallo,

in unserer Umgebung sind mehrere Clients (Outlook 2016 und 2019) and einen Exchange 2016 angebunden. Immer wieder erhalten die Cleints die Meldung "Zertifikatfehler" (mehrmals am Tag). Der Outlook Client scheint sich das Zertifiakt unseres Providers zu ziehen und dort ist unser Autodiscover URL "autodiscover.contoso.com" und otulook.contoso.com" nicht aufgeführt. NSlookup zeigt in diesem Fall den exchange korrekt an. Im Verbindungsstatus des Clients sind die Verbindungen https://outlook.contoso.com getrennt.

Alle Vorgänge im Frankys Tutorial zu "Zertifikate konfigurieren sind überprüft und ok (alle URL sowie die DNS Zonen)

Für einen Cleint habe ich ExcludeSCPLookup aktiviert. Dies hat für einige Stunden funktioniert, dann kam der Fehler wieder.

Wenn ich die Serveranfrage des Clients abbreche, IPConfig /Flushdns und /renew durchführe, dann bekoomt der Cleint die Verbindung meistens wieder zurück.

 

Externer Zugang auf Exchange hat  keine Probleme.

Hat jemand eine Idee? Ich suche schon seit Wochen.


Zitat
Schlagwörter für Thema
(@carstengeh)
Active Member
Beigetreten: 7 Monaten zuvor
Beiträge: 12
17. Oktober 2020 12:52  

Hallo,

hört sich für mich nach DNS an. Welche DNS Einstellungen wurden an den Clients denn gemacht? Wenn da was anderes, als der interne DNS drinsteht kann es da immer wieder zu Problemen kommen. DNS Anfragen nach Extern sollten immer per Forward vom DNS Server gemacht werden, nicht vom Client.

 

Gruß


AntwortZitat
(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
17. Oktober 2020 14:08  

@carstengeh, an den Clients wurden keine Einstellungen verändert. Nur am Exchange wurden die DNS Zonen für autodiscover.contoso.com und outlook.contoso.com erstellt wie im Beitrag von Frank erläutert. Wenn ich das Zertifiakt in der Fehlermeldung anschaue, dann ist der Antragsteller unsere feste IP (also der Hoster). Die Clients sollten bei Abfrage von autodiscover... oder outlook... nur den lokalen Exchange server finden (funktioniert über nslookup bei den Clients immer) Ich verstehe nicht, warum die Clients das Zertifiakt des Hosters erhalten. Das Netzwerk wurde 2018 aufgesetzt und es gab bis ca. Anfang des Jahres diesen Fehler nicht. Der Fehler trat dann irgendwann immer wieder auf, ohne das in den Einstellungen etwas geändert wurde. Der Fehler tritt auf bei einem Client mit Outlook 2016 und bei einem Client mit Outlook 2019.


AntwortZitat
(@carstengeh)
Active Member
Beigetreten: 7 Monaten zuvor
Beiträge: 12
17. Oktober 2020 14:15  

@tlutz

Auch wenn nichts geändert wurde schaue doch einfach mal was die DNS Einstellungen an den Clients sind. Ich sage das deswegen, weil ich bei unserem Server Upgrade vor ein paar Jahre genau das selbe Problem hatte und es lief am Ende auf falsche DNS Einstellungen hinaus. Natürlich kann es bei dir was Anderes sein, aber wie gesagt, hört sich halt sehr nach DNS an.

Damals bin ich der Sache nur mit Wireshark auf die Spur gekommen. Da konnte ich genau gesehen, dass die Clients den falschen DNS kontaktiert haben. Vielleicht hilft dir das auch weiter.

 

Gruß

Diese r Beitrag wurde geändert 1 Monat zuvor von carstengeh

AntwortZitat
(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
19. Oktober 2020 10:03  

@carstengeh

ich dachte auch an einen DNS-Fehler, da ich das Problem manchmal durhc Ipconfig /renew behebne kann. Allerdings sehe ich keinen Fehler in der Konfiguration. Am Client zeigt mir ipconfig wie auch nslookup immer den richtigen Server. Outlook.contoso.com findet immer den Exchange Server, aber Outlook selbst findet ihn anscheinend manchmal nicht. Hast Du einen Vorschlag was ich noch prüfen könnte? Wireshark habe ich noch nicht ausprobiert.

 

Grüße


AntwortZitat
(@carstengeh)
Active Member
Beigetreten: 7 Monaten zuvor
Beiträge: 12
19. Oktober 2020 10:39  
Veröffentlicht von: @tlutz

@carstengeh

ich dachte auch an einen DNS-Fehler, da ich das Problem manchmal durhc Ipconfig /renew behebne kann. Allerdings sehe ich keinen Fehler in der Konfiguration.

Da ich leider immer noch nicht weiß, was deine Konfiguration ist, ist es schwer hier Ratschläge zu geben. Wireshark ist die Beste, die mir gerade einfällt. Für mehr bräuchte man wirklich mehr Infos zum Aufbau, Konfiguration etc.

Gruß 


AntwortZitat
(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
19. Oktober 2020 15:16  

@carstengeh

ich habe jetzt Wireshark mal laufen lassen- Da ist mir aufgefallen, dass der Client eine Anfrage an den DNS-Server stellt nach unserem alten Domainencontroller. Der neue Name ist XXXX01, der alte war YYYYY01. den server YYYYY01 gibt es schon seit 2 Jahren nicht mehr. Ich habe keine Ahnung, wo ich da suchen soll, um den Eintrag YYYYY01 zu löschen.

 

Ein nslookup auf den alten Server YYYYY01 zeigt mir den neuen Server XXXX01 und die korrekte IP. Da liegt wohl der erste Fehler, aber ich weiß nicht wo ich das einstellen kann

Gruß

Diese r Beitrag wurde geändert 1 Monat zuvor von TLutz

AntwortZitat
Frank Zöchling
(@franky)
Admin
Beigetreten: 11 Jahren zuvor
Beiträge: 403
19. Oktober 2020 21:10  

Servus,

wie Carsten schon ganz richtig geschrieben hat, es liegt am DNS. Schau mal in das Autodiscover Whitepaper und zwar ganz konkret bei dem Punkt "Autodiscover Root Domain Abfrage":

https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/

Gruß,

Frank


AntwortZitat
Monthy
(@monthy)
Estimable Member
Beigetreten: 1 Jahr zuvor
Beiträge: 101
23. Oktober 2020 09:26  

Hi,

 

ggf liegt auch an einer ggf nicht sauber bereinigten AD Server Konfig (Sites & Services).
Hier darf es keine Verweise auf den alten DC mehr geben. Weiterhin gibt es ggf. auch noch einen Static DNS Record mit dem alten Servernamen des DC's

Wenn ihr O365 Lizenzen nutzt und ggf ADFS konfiguriert habt, kann es auch sein, dass der Client Autodiscover in die Cloud macht. Das war bei uns der Fall und wir mussten es per GPO deaktivieren.

Der Client macht Autodiscover eben nicht nur bei der Autoermittlung zur Einrichtung von Outlook, sondern auch regelmäßig im Hintergrund.

Prüf es auf einem Problemclient mit "Fiddler", sonst kannst du nicht in den SSL Traffic sehen.

Monthy

Diese r Beitrag wurde geändert 1 Monat zuvor 2 times von Monthy

Ich komme aus einer Zeit, in der aus einer Cloud noch Regen kam!


AntwortZitat
(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
28. Oktober 2020 11:42  

@monthy,

DC und Exchange server wurden vor einiger Zeit neu aufgesetzt. Ich finde keinerlei Hinweise auf den alten Exchange server. Per GPO habe ich am Client auch die Root Domain Abfrage deaktiviert. Ich erhalte immer noch sporadisch die Fehler. Habe jetzt Fiddler mal durchlaufen lassen. Die Abfragen gehen immer nach outlook.contoso.com und alles läuft prima (bzw. "Tunnel to outlook.contoso.com:443") CN ist dann autodiscover.contoso.com und "Subject Alt Names" ist outlook.contoso.com und autodiscover.contoso.com.

Beim Auftreten des Zertifikatsfehlers sehe ich "Tunnel to outlook.office365.com:443" CN ist dann outlook.com von Microsoft und die Liste der Subject Alt Names ist lang mit Einträgen wie outlook.com, office365.com...

Die Verbindung von meinem Outlook Client zum Server besteht momentan noch, wenn ich die Zertifikatswarnung wegklicke.

Keine Ahnung wo diese Office 365 Geschichte herkommt. Das haben wir nie eingesetzt. Könnte dies das Problem sein?

 

Thomas


AntwortZitat
(@tlutz)
Active Member
Beigetreten: 1 Jahr zuvor
Beiträge: 7
30. Oktober 2020 12:27  

Hallo,

ich habe weiter recherchiert und möglicherweise eine Lösung gefunden, die auch für Andere hilfreich sein könnte. Microsoft hat wohl das Autodiscover Verhalten geändert, wodurch Outlook versucht, ein Office365 Konto zu finden. Beschreibung und Lösungsansatz Siehe hier: https://wissen.qualityhosting.de/s/article/geaendertes-autodiscover-verhalten-in-outlook

Ich habe den Registry Eintrag entsprechend der Anleitung geändert, aber das Verhalten von Outlook blieb gleich. Dann habe ich das Profil neu erstellt. Jetzt läuft der Problem-Client seit ca. 48h, ohne dass dieses Problem auftritt. Ich beobachte weiter, aber dies könnte die Lösung sein

 

Thomas

 


AntwortZitat

Share: