10
Outlook Login nach Neustart von Extern notwendig
Hallo,
ich habe einen Exchange 201 CU 19 und Outlook 2016 / 2013 Clients (Win7/Win10). Seit ein paar Tagen kommt folgendes Phänomen:
Wenn ein Benutzer extern sein Outlook öffnet, muss er seine Zugangsdaten eintragen.
Bei der Analyse habe ich mir autodiscover angeschaut. Der Microsoft Onlinetest war mit Warnungen abgeschlossen
Autodiscover war über domain.de nicht möglich, sondern nur über autodiscover.domain.de. Klar, wie ca. X Millionen auch
ist da natürlich die Webseite gehostet.
Dann ist mir aufgefallen, wenn ich mein Laptop neu start und Outlook öffnen und einen Verbindungstest unternehme, kommt
das Kennwortpopup bei dem Punkt https://autodicover.domain.de/autodiscover/autodiscover.xml
Wenn ich mich manuell einlogge kommt Code 600. Teilwiese kam bei den Tests über das Verbindungstool Code 401 und mal
Code 200.
Wenn ich per VPN Verbunden war, ging es zu 100% immer.
Die Frage, die ich mir stelle ist: Warum?
Ich sehe keinen Punkt, der Mir Aufschluß geben könnte, woran es liegt.
Der genaue Zeitpunkt konnte nicht gestgestellt werden, seit dem es aufgetreten ist. In den Eventlogs fand ich auch
keine großen Auffälligkeiten.
P.S:: 24.7 wurde z.B. KB4092041 installiert (nichts bei google gefunen), oder KB3175339.
ich habe einen Exchange 201 CU 19 und Outlook 2016 / 2013 Clients (Win7/Win10). Seit ein paar Tagen kommt folgendes Phänomen:
Wenn ein Benutzer extern sein Outlook öffnet, muss er seine Zugangsdaten eintragen.
Bei der Analyse habe ich mir autodiscover angeschaut. Der Microsoft Onlinetest war mit Warnungen abgeschlossen
Autodiscover war über domain.de nicht möglich, sondern nur über autodiscover.domain.de. Klar, wie ca. X Millionen auch
ist da natürlich die Webseite gehostet.
Dann ist mir aufgefallen, wenn ich mein Laptop neu start und Outlook öffnen und einen Verbindungstest unternehme, kommt
das Kennwortpopup bei dem Punkt https://autodicover.domain.de/autodiscover/autodiscover.xml
Wenn ich mich manuell einlogge kommt Code 600. Teilwiese kam bei den Tests über das Verbindungstool Code 401 und mal
Code 200.
Wenn ich per VPN Verbunden war, ging es zu 100% immer.
Die Frage, die ich mir stelle ist: Warum?
Ich sehe keinen Punkt, der Mir Aufschluß geben könnte, woran es liegt.
Der genaue Zeitpunkt konnte nicht gestgestellt werden, seit dem es aufgetreten ist. In den Eventlogs fand ich auch
keine großen Auffälligkeiten.
P.S:: 24.7 wurde z.B. KB4092041 installiert (nichts bei google gefunen), oder KB3175339.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 382737
Url: https://administrator.de/contentid/382737
Printed on: April 16, 2024 at 16:04 o'clock
10 Comments
Latest comment
Moin...
Wenn ein Benutzer extern sein Outlook öffnet, muss er seine Zugangsdaten eintragen.
hm...
Bei der Analyse habe ich mir autodiscover angeschaut. Der Microsoft Onlinetest war mit Warnungen abgeschlossen
und welche warnungen genau?
Autodiscover war über domain.de nicht möglich, sondern nur über autodiscover.domain.de. Klar, wie ca. X Millionen auch
ist da natürlich die Webseite gehostet.
autodiscover.domain.de. ist doch ok... es kommt ja auch auf deine exchange config an... und auf dein zertifikat... was steht den da drin?
Dann ist mir aufgefallen, wenn ich mein Laptop neu start und Outlook öffnen und einen Verbindungstest unternehme, kommt
das Kennwortpopup bei dem Punkt https://autodicover.domain.de/autodiscover/autodiscover.xml
ok...
Wenn ich mich manuell einlogge kommt Code 600. Teilwiese kam bei den Tests über das Verbindungstool Code 401 und mal
Code 200.
Wenn ich per VPN Verbunden war, ging es zu 100% immer.
richtig...
Die Frage, die ich mir stelle ist: Warum?
ich vermute du hast ein problem mit deinem zertifikat... was ist den mit deinem owa?
Ich sehe keinen Punkt, der Mir Aufschluß geben könnte, woran es liegt.
Der genaue Zeitpunkt konnte nicht gestgestellt werden, seit dem es aufgetreten ist. In den Eventlogs fand ich auch
keine großen Auffälligkeiten.
P.S:: 24.7 wurde z.B. KB4092041 installiert (nichts bei google gefunen), oder KB3175339.
Frank
Zitat von @derLenhart:
Hallo,
ich habe einen Exchange 201 CU 19 und Outlook 2016 / 2013 Clients (Win7/Win10). Seit ein paar Tagen kommt folgendes Phänomen:
was nu.. einen exchange 2013?Hallo,
ich habe einen Exchange 201 CU 19 und Outlook 2016 / 2013 Clients (Win7/Win10). Seit ein paar Tagen kommt folgendes Phänomen:
Wenn ein Benutzer extern sein Outlook öffnet, muss er seine Zugangsdaten eintragen.
Bei der Analyse habe ich mir autodiscover angeschaut. Der Microsoft Onlinetest war mit Warnungen abgeschlossen
Autodiscover war über domain.de nicht möglich, sondern nur über autodiscover.domain.de. Klar, wie ca. X Millionen auch
ist da natürlich die Webseite gehostet.
Dann ist mir aufgefallen, wenn ich mein Laptop neu start und Outlook öffnen und einen Verbindungstest unternehme, kommt
das Kennwortpopup bei dem Punkt https://autodicover.domain.de/autodiscover/autodiscover.xml
Wenn ich mich manuell einlogge kommt Code 600. Teilwiese kam bei den Tests über das Verbindungstool Code 401 und mal
Code 200.
Wenn ich per VPN Verbunden war, ging es zu 100% immer.
Die Frage, die ich mir stelle ist: Warum?
Ich sehe keinen Punkt, der Mir Aufschluß geben könnte, woran es liegt.
Der genaue Zeitpunkt konnte nicht gestgestellt werden, seit dem es aufgetreten ist. In den Eventlogs fand ich auch
keine großen Auffälligkeiten.
P.S:: 24.7 wurde z.B. KB4092041 installiert (nichts bei google gefunen), oder KB3175339.
Hallo Frank,
ja, der Server ist Exchange 2013 CU 19. B
Bei der Warnun des connectivitätstest ging es wirklich nur darum, dass "bemängelt" wurde, dass Outlook zuerst hier guckt...
https://domain.de/autodiscover/autodiscover.xml und nichts finden (da es hier ja um die reine Firmenwebseite geht) und dann hier sucht:
https://autodicover.domain.de/autodiscover/autodiscover.xml und fündig wird.
Insofern, würde ich dies als eine Standardwarung betrachten, wenn das Hosting extern liegt und der Exchange bei einem selber.
Das Zertifikat ist ein Wildcardzertifikat für die Domäne, sprich *.domain.de.
autodiscover ist ein CNAME für outlook.domain.de (wobei ich auch ein SRV Eintrag probiert hatte).
Es gibt keine Zertifikatswarnung und ein Abwurd über OWA funktioniert ohne Probleme. intern/extern.
Ich benutze Split-DNS, sprich intern den Servernamen mit einem selbstsignierten Zertifikat mit dem DNS Namen des Servers in der Domäne (srv123.local) und extern das "offizielle" Zertifikat.
Den Server habe ich durch Wechsel des Jobs übernommen und zunächst hatte er nur internes DNS und war nur runimentär konfiguriert, weswegen iPhone sich nicht mehr "normal" verbinden könnten (klar, Zertifikat und DNS) bzw. Outlook 2016 sich nicht gut einbinden ließ (autodiscover).
Der Exchange wird dann durch die Firewall Port 443 forwared/NAT.
Das läuft nun soweit besser. Nur seit 1-2 Wochen kamen sporadisch die Rückmeldungen wegen PopUps. Bei meinem Laptop war es gestern, wie gesagt, zu 100% rekonstruierbar, dass es bei jedem Neustart und öffnen von Outlook von extern die PopUp Warnung kam beim öffnen und Autodiscover.
Das Zertifikat ist von Digicert 2048Bit/SHA2
Ich hoffe, die Infos helfen Dir weiter.
ja, der Server ist Exchange 2013 CU 19. B
Bei der Warnun des connectivitätstest ging es wirklich nur darum, dass "bemängelt" wurde, dass Outlook zuerst hier guckt...
https://domain.de/autodiscover/autodiscover.xml und nichts finden (da es hier ja um die reine Firmenwebseite geht) und dann hier sucht:
https://autodicover.domain.de/autodiscover/autodiscover.xml und fündig wird.
Insofern, würde ich dies als eine Standardwarung betrachten, wenn das Hosting extern liegt und der Exchange bei einem selber.
Das Zertifikat ist ein Wildcardzertifikat für die Domäne, sprich *.domain.de.
autodiscover ist ein CNAME für outlook.domain.de (wobei ich auch ein SRV Eintrag probiert hatte).
Es gibt keine Zertifikatswarnung und ein Abwurd über OWA funktioniert ohne Probleme. intern/extern.
Ich benutze Split-DNS, sprich intern den Servernamen mit einem selbstsignierten Zertifikat mit dem DNS Namen des Servers in der Domäne (srv123.local) und extern das "offizielle" Zertifikat.
Den Server habe ich durch Wechsel des Jobs übernommen und zunächst hatte er nur internes DNS und war nur runimentär konfiguriert, weswegen iPhone sich nicht mehr "normal" verbinden könnten (klar, Zertifikat und DNS) bzw. Outlook 2016 sich nicht gut einbinden ließ (autodiscover).
Der Exchange wird dann durch die Firewall Port 443 forwared/NAT.
Das läuft nun soweit besser. Nur seit 1-2 Wochen kamen sporadisch die Rückmeldungen wegen PopUps. Bei meinem Laptop war es gestern, wie gesagt, zu 100% rekonstruierbar, dass es bei jedem Neustart und öffnen von Outlook von extern die PopUp Warnung kam beim öffnen und Autodiscover.
Das Zertifikat ist von Digicert 2048Bit/SHA2
Ich hoffe, die Infos helfen Dir weiter.
Noch ein Hinweis. Ich habe es eben auf einem anderen Gerät probiert. Ich habe die Kennwortabfrage einmal abgebrochen und outlook dann geschlossen. Es erschien einmal kurz beim Schließen die Meldung:
"Konfiguieren von ich@domain.de" zulassen, sprich eine Umleitungsmittelung, die ich nicht bestätigen kann.
Meinst Du, es kommt daher? Ich kann die Meldung aber nicht bestätigen.
"Konfiguieren von ich@domain.de" zulassen, sprich eine Umleitungsmittelung, die ich nicht bestätigen kann.
Meinst Du, es kommt daher? Ich kann die Meldung aber nicht bestätigen.
Tritt das Problem bei allen Clients auf?
Hallo,
soweit ich es rekonstruieren konnte tritt es bei jedem Client auf. Es scheint auch nicht am Autodiscover zu liegen. Ich habe als Test den DNS Record im WAN entfernt. Die Anmeldung im Outlook dauerte, nachdem die Auflösung nicht mehr möglich war, länger, da der Client zunächst den internen Server versuchte zu kontaktieren, aber dann kam ebenfalls das Passwordpromt.
Ich habe den Verdacht dass es an der Authentifizierungsmethode am Exchange liegt von "irgendeinem" virtuellen Directory. Intern klappt es sofort (wohl NTLM), extern nicht.
Zum Beispiel outlookanywhere verwendet Negotiate für extern, intern wird ntlm verwendet.
soweit ich es rekonstruieren konnte tritt es bei jedem Client auf. Es scheint auch nicht am Autodiscover zu liegen. Ich habe als Test den DNS Record im WAN entfernt. Die Anmeldung im Outlook dauerte, nachdem die Auflösung nicht mehr möglich war, länger, da der Client zunächst den internen Server versuchte zu kontaktieren, aber dann kam ebenfalls das Passwordpromt.
Ich habe den Verdacht dass es an der Authentifizierungsmethode am Exchange liegt von "irgendeinem" virtuellen Directory. Intern klappt es sofort (wohl NTLM), extern nicht.
Zum Beispiel outlookanywhere verwendet Negotiate für extern, intern wird ntlm verwendet.
Moin...
was sagt den der exchange mit seinen logs dazu?
Ich habe den Verdacht dass es an der Authentifizierungsmethode am Exchange liegt von "irgendeinem" virtuellen Directory. Intern klappt es sofort (wohl NTLM), extern nicht.
Zum Beispiel outlookanywhere verwendet Negotiate für extern, intern wird ntlm verwendet.
Frank
Zitat von @derLenhart:
Hallo,
soweit ich es rekonstruieren konnte tritt es bei jedem Client auf. Es scheint auch nicht am Autodiscover zu liegen. Ich habe als Test den DNS Record im WAN entfernt. Die Anmeldung im Outlook dauerte, nachdem die Auflösung nicht mehr möglich war, länger, da der Client zunächst den internen Server versuchte zu kontaktieren, aber dann kam ebenfalls das Passwordpromt.
öhhh... intern wäre doch richtig, und sollte sofort gehen!Hallo,
soweit ich es rekonstruieren konnte tritt es bei jedem Client auf. Es scheint auch nicht am Autodiscover zu liegen. Ich habe als Test den DNS Record im WAN entfernt. Die Anmeldung im Outlook dauerte, nachdem die Auflösung nicht mehr möglich war, länger, da der Client zunächst den internen Server versuchte zu kontaktieren, aber dann kam ebenfalls das Passwordpromt.
was sagt den der exchange mit seinen logs dazu?
Ich habe den Verdacht dass es an der Authentifizierungsmethode am Exchange liegt von "irgendeinem" virtuellen Directory. Intern klappt es sofort (wohl NTLM), extern nicht.
Zum Beispiel outlookanywhere verwendet Negotiate für extern, intern wird ntlm verwendet.
Hallo,
zu Deiner Frage: Es bezog sich wirklich auf den Zugriff von extern. Ich habe extern Autodiscover entfernt (war auch nicht mehr auflösbar) und dann dauert es lange, da der Client zunächst versucht über den internen Server zu gehen, dann nimmt er die externe URL outlook.domain.de. Sobald er über outlook.domain.de geht, kommt das Promt.
Mir erschließt sich das Zusammenspiel an dieser Stelle nicht. Welchen Pfad versucht Exchange da zu über das WAN zu öffnen.
Deshalb die Vermutung mit einem Problem in der Authentifizierung.
zu Deiner Frage: Es bezog sich wirklich auf den Zugriff von extern. Ich habe extern Autodiscover entfernt (war auch nicht mehr auflösbar) und dann dauert es lange, da der Client zunächst versucht über den internen Server zu gehen, dann nimmt er die externe URL outlook.domain.de. Sobald er über outlook.domain.de geht, kommt das Promt.
Mir erschließt sich das Zusammenspiel an dieser Stelle nicht. Welchen Pfad versucht Exchange da zu über das WAN zu öffnen.
Deshalb die Vermutung mit einem Problem in der Authentifizierung.
Noch eine Anmerkung von der Outlookverbindungen:
RCP/HTTP (SSL wird aber verwendet) wird die Verbindung verwendet und Auth ist Nego [anonym]
RCP/HTTP (SSL wird aber verwendet) wird die Verbindung verwendet und Auth ist Nego [anonym]
Ich habe testweise die externe Authentifizierung auf NTLM geändert. Das Verhalten hat sich nicht geändert.
Mir ist bei NTLM in der Verbindungsübersicht vom Outlook aufgefallen, dass während des Anmeldeprozesses der interne Servername unter
dem ProxyServer erscheint. Nach der erfolgreichen Authentifizierung steht das outlook.domain.de
In den Exchangeservereinstellungen (Outlook Anywhere und Virtual Directories) konnte ich jedoch keinen Hinweis über einen Eintragfehler finden.
Mir ist bei NTLM in der Verbindungsübersicht vom Outlook aufgefallen, dass während des Anmeldeprozesses der interne Servername unter
dem ProxyServer erscheint. Nach der erfolgreichen Authentifizierung steht das outlook.domain.de
In den Exchangeservereinstellungen (Outlook Anywhere und Virtual Directories) konnte ich jedoch keinen Hinweis über einen Eintragfehler finden.
Ich habe einmal komplett die Einstellungen der „virtual directory“ neu gesetzt und einen iisreset vorgenommen und danach hat es sich normalisiert.
