Hallo zusammen,
Ich habe ein kleines Problem mit internen Outlook-Clients. Beim Start von selbigen bekommen die Clients immer noch eine Sicherheitswarnung die Bestätigt werden muss. Das stört die Kollegen.
Nach der erfolgreichen Verabschiedung des SBS2011 , ahbe ich Server 2019 mit AD und Exchange 2019 in Dienst gestellt.
Habe für den Zugriff von extern auf OWA eine Domain mit entsprechenden SSL-Zertifikat. Das läuft auch alles bestens.
Meine internen Outlook-Clients verbinden sich vernünftig über die interne MAPI URL, finden aber anscheinend nicht das von der eigenen AD CA ausgestellte Zertifikat für den Exchange-Server, sondern kommen immer mit einer mit JA zu bestätigenden Sicherheitswarnung "Es besteht ein Problem mit dem Sicherheitszertifikat der Website. ...stammt von einer vertrauenswürdigen Quelle + Datum ist gültig... ABER ..Der Name auf dem Zertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein."
Im DNS der AD ist die externe Zone eingetragen mit dem Server, die internen Angaben eigentlich auch.
Was könnte ich vergessen oder falsch haben, was die Meldung erscheinen lässt???
Vielen Dank für Ideen und Tipps.
Hallo Stefan,
Habe ich das richtig verstanden: Du verwendest für extern (OWA) und intern (outlook) verschiedene Zertifikate?
Generell würde ich mir das gelieferte Zertifikat im Outlook mal genau ansehen, vor allem die gültige Domain. Und als nächstes versuchen herauszufinden, über welche Domain / Subdomain Outlook tatsächlich verbindet. Könnte Autodiscover ein Problem sein?
Viele Grüße,
Stefan
Hallo Stefan.
Ohne weitere Infos ist da eine Fehlersuche etwas müssig.
Welcher Server verursacht denn die Fehlermeldung? Der Name steht in der Regel oben in der Meldung.
Und welches Zertifikat wird denn jetzt gezogen? Innerhalb der Fehlermeldung mal auf Zertifikat anzeigen.
Dann den Antragsteller ermitteln. Wenn's das eigene Zertifikat ist, evtl. die Liste der alternativen Antragsteller erweitern.
Gruß
Thomas
Probleme sind nur Lösungen in Arbeitskleidung.
Ist das Zertifikat im IE importiert, unter vertrauenswürdige Herausgeber/Stammzertifizierungsstellen?
Gruß
Habe für den Zugriff von extern auf OWA eine Domain mit entsprechenden SSL-Zertifikat. Das läuft auch alles bestens.
Meine internen Outlook-Clients verbinden sich vernünftig über die interne MAPI URL, finden aber anscheinend nicht das von der eigenen AD CA ausgestellte Zertifikat für den Exchange-Server, sondern kommen immer mit einer mit JA zu bestätigenden Sicherheitswarnung "Es besteht ein Problem mit dem Sicherheitszertifikat der Website. ...stammt von einer vertrauenswürdigen Quelle + Datum ist gültig... ABER ..Der Name auf dem Zertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein."Im DNS der AD ist die externe Zone eingetragen mit dem Server, die internen Angaben eigentlich auch.
Was könnte ich vergessen oder falsch haben, was die Meldung erscheinen lässt???
Vielen Dank für Ideen und Tipps.
Hi Stefan!
Von Extern funktioniert es also! Dann ist glücklicherweise nur intern das Problem, was du schnell lösen kannst:
DNS-Name der externen Domain zeigt vermutlich schon auf die interne IP des Exchange-Servers? Auch der Autodiscover-Record intern?
Wenn dem so ist, stimmen nur deine URL-Adressen für intern im Exchange nicht und gehören angepasst. Hat mich mal viel Herzklopfen bei einer großen Firma mit über 100 Mitarbeitern gekostet, aber ging am Ende gut dank einem Skript von Franky aus.
Für den Exchange 2019 nur die Zeile1 ändern die noch für E2016 ist, sowie die 4 Variablen darunter:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;
$servername = "emailserver.internedomain.local"
$internalhostname = "mail.externedomain.at"
$externalhostname = "mail.externedomain.at"
$autodiscoverhostname = "autodiscover.externedomain.at"
$owainturl = "https://" + "$internalhostname" + "/owa"
$owaexturl = "https://" + "$externalhostname" + "/owa"
$ecpinturl = "https://" + "$internalhostname" + "/ecp"
$ecpexturl = "https://" + "$externalhostname" + "/ecp"
$ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx"
$ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx"
$easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync"
$easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync"
$oabinturl = "https://" + "$internalhostname" + "/OAB"
$oabexturl = "https://" + "$externalhostname" + "/OAB"
$mapiinturl = "https://" + "$internalhostname" + "/mapi"
$mapiexturl = "https://" + "$externalhostname" + "/mapi"
$aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml"
Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl
Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl
Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl
Get-ActiveSyncVirtualDirectory -Server $servername | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl
Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl
Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'
Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri
Danach nur ein wenig warten (1 Min) und erneut intern versuchen.
Wird dein Problem vermutlich lösen.
Hallo zusammen, danke schonmal für die Hinweise. Ich überprüfe jetzt alles Stück für Stück.
Beim Autodiscover-Test im Outlook, greift er zuerst auf das externe autodiscover zu ..mit Fehler, dann erfolgreich die interne URL.
Beim Outlook-Start zieht er sich zuerst das SSL-Zertifikat der externen Seite und meckert zu Recht, das der Name des Exchangeservers nicht mit im externen Zertifikat steht.
Wie kriege ich es konfiguriert, das Outlook nur via internem autodiscover schaut???
lg aus Berlin
Outlook fragt autodiscover zuerst nach der Email-Domain ab. Wenn dein Email @stefanweber.com wäre, dann sieht Outlook zuerst nach autodiscover.stefanweber.com ab. Wenn Outlook merkt, dass der A-Record nicht funktioniert oder existiert, fragt Outlook nach dem SRV-Eintrag zu Autodiscover ab.
In Zeiten endloser Domains auf einem sicheren Zertifikat per LetsEncrypt, gibst du die Autodiscover.stefanweber.com auf das Zertifikat sowie die ZugriffsURL zum OWA (zB mail.stefanweber.com).
Damit sind mal die externen funktionstüchtig. Damit das intern noch funktioniert, musst du dem DNS-Server, der per DHCP intern vergeben wird, auch sagen, dass autodiscover und mail.stefanweber.com auf die interne IP des Exchange Servers läuft (zB 192.168.1.10)
Dann ist intern und extern gleich und Outlook dürfte nix mehr zu unsicheren Zugriffen sagen.
Kannst du das testen? Weißt du wie/was/wann mit DNS Server?
Moin alle aus dem kalten Hamburg, uns ist noch was schlimmeres zugestoßen auf der Suche nach der Lösung, für das gleiche Problem, haben wir ein neues Zertifikat erzeugt und das alte gelöscht im Exchange 2019, danach neu gestartet und den Rest mag ich gar nicht mehr schreiben... Also wenn wir jetzt auf den ECP wollen gibt es vom IE auf dem Ex-Server gemeckere, wenn mann es umgehen will, wird erlaubt aber weißer screen, immer noch Zertifikatsproblem, ich glaube ich habe mich klassisch selber ausgeschlossen... kennt jemand einen Schlüsseldienst ?
Guten Abend zusammen,
habe gerade das gleiche Problem: externer Zugriff per OWA super Dank SAN-Zertifikat. Outlook intern meckert, weil der Hostname nicht auf dem Zertifikat steht.
Damit das intern noch funktioniert, musst du dem DNS-Server, der per DHCP intern vergeben wird, auch sagen, dass autodiscover und mail.stefanweber.com auf die interne IP des Exchange Servers läuft (zB 192.168.1.10)
Irgendwie stehe ich gerade auf der Leitung. Wo packe ich das ins DNS? Einfach bei den Forward-Lookupzonen unter meiner lokalen Domain als Host (A)-Record? Aber dann heißt er doch autodiscover.extdomain.tld.intdomain.local??? Das macht ja keinen Sinn...?!?
Vielen Dank für Eure Hilfe
Ok. Nochmal in Ruhe nachgedacht und einen Schritt weitergekommen.
Habe noch die Zone autodiscover.extdomain.tld angelegt und dort den Host (A)-Record (IP) für meinen DNS eingetragen. Der NS-Record stand automatisch drin.
ABER:
Outlook schreit immer noch, dass das Zertifikat falsch ist...
Hi!
Einfacher Fehler, hatte ich zuletzt auch.
Wenns extern gut funktioniert, wird intern der interne Computername+Domäne verwendet.
Das ist eine Einstellung bei den URL-Adressen.
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershell-konfigurieren/
Nur zur Sicherheit, lass dir mal alle URLs anzeigen:
https://www.frankysweb.de/exchange-2016-dns-namen-fr-zertifikate-ermitteln-quick-dirty/
Bei der Abfrage deiner DNS-Namen im Exchange wirst du fündig, wer für den internen Computernamen zuständig ist. Den dann einfach auch abändern.
Danach funktionierts auch intern richtig.
Bitte lass mich wissen, was passiert wenn du INTERN machst:
ping autodiscover.stefanweber.com machst? (Bzw. deine Remote-Exchange-Adresse)
Sowie Ping mail.stefanweber.com (bzw. deine Remote-Exchange-Adresse).
Würde gerne wissen, mit welchen IP-Adressen diese Exchange-URLs intern aufgelöst werden.
Danke
Aber dann heißt er doch autodiscover.extdomain.tld.intdomain.local??? Das macht ja keinen Sinn...?!?
richtig. Deswegen legt man entweder die externe Zone auch lokal an (mit Nachteilen, dass du alle externen Hosts auch intern pflegen musst), oder du nutzt mehrere Hostzonen. Also Zone autodiscover.extdomain.tld mit einem leeren A-Record der auf die interne IP deines Exchangeservers zeigt (und das ganze noch für den zugriffsnamen owa o.ä.)
Abgesehen davon, schau mal was dir
get-clientaccessservice | fl *uri*
ausgibt. Sollte da noch der interne Hostname zurückkommen, dann setz den korrekt.
Abgesehen davon, schau mal was dir
get-clientaccessservice | fl *uri*ausgibt. Sollte da noch der interne Hostname zurückkommen, dann setz den korrekt.
Liefert sauber die externe autodiscover Adresse...
Outlook meckert jetzt auch nicht mehr.
Hab jetzt aber ein ganz anderes Problem, von dem ich noch nicht weiß, ob es irgendwie damit zusammenhängt:
Die Clients haben kein Internet.
nslookup liefer als Standardserver den Domain Server. www.wdr.de liefert auch die richtige IP.
Versuch ich ein Ping auf www.wdr.de bekomme ich die richtige Ip angezeigt, es gibt aber nur Zeitüberschreitung. Das ist von der Adresse unabhängig. Netzwerk steht auf Domänennetzwerk. Beim Server habe ich dazu den verzögerten Start eingestellt, damit auch dieser im Domänennetzwerk ist...
Outlook meckert jetzt auch nicht mehr.
Aha... Na dann is ja irgendwie logisch.
ersuch ich ein Ping auf www.wdr.de bekomme ich die richtige Ip angezeigt, es gibt aber nur Zeitüberschreitung. Das ist von der Adresse unabhängig
Na vielleicht dürfen die Clients einfach nicht per Ping durch die Firewall. ;) Mal ehrlich, wie soll man denn auf so eine Beschreibung antworten?
Stimmt, hast Recht... ?
Die für mich selbstverständlichen Themen (wie testweises Ausschalten der Firewall) habe ich gar nicht erst erwähnt.
Keine Ahnung was es war - ein Neustart des Servers hat das Problem behoben...
Vielen Dank für Deine Unterstützung.