Benutzer mit den meisten Antworten
[Exchange 2013] Kein login bei OWA und ECP möglich nach zertifikatsumstellung

Frage
-
Hallo liebe Techneter,
ich habe folgendes Problem und versuche es möglichst gut zu beschreiben da ich hier wohl keine Bilder posten darf bis mein Konto überprüft wurde:
Ich habe meine URL`s der virtuellen Verzeichnisse angepasst und ein Zertifikat erstellt (SSL von lets encrypt) und die Dienste POP,IMAP,SMTP, IIS an das Zertifikat gebunden. Autodiscover funktioniert alles bestens, externe Anbindung Smartphone/Outlook alles okay. Nur leider funktioniert OWA und ECP extern sowie intern nicht mehr. Wenn ich die Seiten aufrufe komm ich auf die Login-Seite und nachdem ich Benutzername und Passwort eingegeben habe lande ich sofort wieder auf der Login Seite. das ist bei OWA und ECP so. Gebe ich ein falsches Kennwort ein erkennt er auch dass das Passwort falsch war. Ich kämpfe nun seit 2 vollen tagen daran, aber ich weiss nicht mehr weiter. ich habe schon die Virtuellen Verzeichnisse von OWA und ECP neu erstellt, leider ohne Erfolg.
Die Bindings der Default Website sieht folgendermaßen aus:
http *:80:
net.pipe *
net.msmq localhost
msmq.formatname localhos
net.tcp 808:*
http 127.0.0.1:80:
https 127.0.0.1:443: ssl
https *:443: sslFlags=0Bei den Protokollen 443 ist das neue Zertifikat hinterlegt.
Hier die Bindings der Exchange Backend Webseite:
http *:81:
net.pipe *
https *:444: sslFlags=0Ich hatte gestern auch nochmal ein neues Zertifikat vom Exchange generieren lassen weil auf einer Support Seite von Microsoft stand das dies eine Ursache sein kann. Das neue Zertifikat habe ich am Port 444 auf der Backend Seite gebunden aber auch das half nichts.
Die Authentifizierungseinstellungen auf der Default-Seite sehen folgendermaßen aus:
OWA: Formularauthentifizierung und Standardauthentifizierung ausgewählt
ECP: Formularauthentifizierung , Standardauthentifizierung und Anonyme Authentifizierung ausgewählt
Die Authentifizierungseinstellungen auf der Exchange Backend -Seite sehen folgendermaßen aus:
OWA: Anonyme Authentifizierung und Windowsauthentifizierung
ECP: Anonyme Authentifizierung und Windowsauthentifizierung
Würde mich freuen wenn mir wer weiterhelfen könnte, die letzten Nächte waren sehr kurz bei mir und ich weiss nicht weiter :)
Gruss Martin
- Bearbeitet MartinLoe Dienstag, 31. Januar 2017 13:29
- Typ geändert Yavor TanevMicrosoft contingent staff Freitag, 3. Februar 2017 14:53
- Typ geändert NobbyausHBModerator Freitag, 17. Februar 2017 19:31 Aktuelle Antwort
- Bearbeitet Yavor TanevMicrosoft contingent staff Montag, 20. Februar 2017 13:32 Titel repariert
- Typ geändert Yavor TanevMicrosoft contingent staff Freitag, 24. Februar 2017 07:55
- Typ geändert NobbyausHBModerator Freitag, 24. Februar 2017 13:34 Aktuelle Antwort
Antworten
-
Also, ich wollte wenigstens mal Rückmeldung geben :) es funktioniert wieder alles wie es soll, es war keine Neuinstallation notwendig.ich hatte ja oben die Authentifizierungseinstellungen gepostet die ich aus der EXchange Management Shell hatte. Nun wollte ich ein letztes mal ochmal schauen und habe mir diesmal die Authentifizierungseinstellungen nochmal genau angeguckt aber im IIS.
Und siehe da die Authentifizierungseinstellungen waren anders als mir die Management Shell ausgegeben hat. nachdem ich die Auth Einstellungen im IIS gesetzt habe und nicht per EMS und einen Neustart durchgeführt habe läuft wieder alles bestens :)
Gruss Martin
- Als Antwort markiert NobbyausHBModerator Freitag, 24. Februar 2017 13:36
Alle Antworten
-
Hallo Martin,
wo hast Du denn die Authentifizierungsmethoden eingestellt und geprüft?
Im IIS-Manager, Exchange PowerShell oder über die ECP Seite?Die Kombination Forms-based und Standard funktionieren nicht zusammen.
Was liefern
Get-OwaVirtualDirectory -Server DEINEXCHANGESERVER | fl *auth*
Get-EcpVirtualDirectory -Server DEINEXCHANGESERVER | fl *auth*
als Ergebnis?
Aktivieren der Foms-Based Authentifizierung:
get-owavirtualDirectory -Server DEINEXCHANGESERVER | set-owavirtualDirectory -FormsAuthentication $true -BasicAuthentication $false
&
get-ecpvirtualDirectory -Server DEINEXCHANGESERVER | set-ecpvirtualDirectory -FormsAuthentication $true -BasicAuthentication $false
iisreset
Gruß Malte
- Als Antwort vorgeschlagen daniel299 Mittwoch, 8. Juli 2020 18:23
-
Moin,
dass Du die BackEnd-Website angefsst hast, ist natürlich bedauerlich. Am FrontEnd ist Dein Problem möglicherweise dies:
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com -
Hallo Evgenij,hallo Malte
jetzt wollte ich mit Freude hier mitteilen das ich zumindestens ein Fehler gefunden habe und sehe das du auch schon den Link gepostet hast :) Hatte keine Benachrichtigung bekommen über dein Post. Also die Lösung war wirklich das es ein KSp Zertifikat war. Ich komme zumindestens wieder auf OWA und ECP.
Jetzt habe ich noch folgendes Problem:
Wenn ich mich bei OWA einlogge kommt ein HTTP 404 Fehler und er ist auf folgender Seite "https://mail.domäne.de/owa/auth/errorFE.aspx httpCode=404#ReturnUrl=/owa/">https: //mail.domäne.de/owa/auth/errorFE.aspxhttpCode=404#ReturnUrl=/owa/
Klicke ich auf mehr Details erscheint dies:
X-ClientId: DSOS - GOTD - G0QQ - KQXPQARHG
X-FEServer: MAILSERVER
Date: 15.02.2017 07:04:33Klicke ich dann aber auf Seite aktualisieren, bin ich im OWA drin und er ist auf:
"https://mail.domöne.de/owa/#path=/mail"
Logge ich mich aus und sofort wieder ein geht er sofort ins OWA und alles ist okay. Phänomen bei sämtlichen Clients.
Beim ECP sieht es ähnlich aus, wenn ich mich dort einlogge kommt kommt auch HTTP 404:
Serverfehler in der Anwendung /ecp.
Die Ressource kann nicht gefunden werden.
Beschreibung: HTTP 404. Die gesuchte Ressource oder eine ihrer Abhängigkeiten wurde möglicherweise entfernt, umbenannt oder ist vorübergehend nicht verfügbar. Überprüfen Sie folgende URL, und stellen Sie sicher, dass sie richtig geschrieben wurde.
Angeforderter URL: /ecp/login.aspx
Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.6.1087.0
und er ist auf Seite: https://mail.domäne.de/ecp/login.aspx?ReturnUrl=%2fecp%2f
tippe ich dann im Browser https://mail.domäne.de/ecp ein bin ich auch wieder sauber im ECP drin.
Hier die Auth-Einstellungen von OWA und ECP:
Identity : MAILSERVER\owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication : True
WindowsAuthentication : False
DigestAuthentication : False
FormsAuthentication : True
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}Identity : MAILSERVER\owa (Exchange Back End)
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
BasicAuthentication : False
WindowsAuthentication : True
DigestAuthentication : False
FormsAuthentication : False
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}Identity : MAILSERVER\ecp (Exchange Back End)
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated}
BasicAuthentication : False
WindowsAuthentication : True
DigestAuthentication : False
FormsAuthentication : False
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}Identity : MAILSERVER\ecp (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication : True
WindowsAuthentication : False
DigestAuthentication : False
FormsAuthentication : True
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}Jemand evtl. ne Idee was das der Grund des Fehlers ist ?
Gruss schonmal
- Bearbeitet MartinLoe Mittwoch, 15. Februar 2017 08:34 Zusatzinformationen eingefügt
-
Hallo Martin,
ich glaube, der Umfang dieser Fehler geht über die Möglichkeiten die wir hier haben hinaus. Es ist ja eine Operation am "offenen Herzen". Es gibt die Möglichkeit die VirtualDirectory neu zu erstellen. Hier fehlen mir aber einige Informationen um alle Abhängigkeiten abschätzen zu können.
Was ist zwischen Client und CAS-Rolle? NLB?
Welche Exchange Version?
Mir ist es zu heikel, einfach hier zu posten wie man die virtuellen Webverzeichnisse neu erstellt, denn wenn Dir da ein Fehler unterläuft, können wir keinen Support leisten.
Nur soviel: Der Suchstring "remove-owavirtualdirectory" und "new-virtualdirectory".
Die Ursache muss also nicht in der Exchangekonfiguration liegen. Sei also bitte vorsichtig und habe immer einen Plan B.
Gruß Malte
-
-
Also, ich wollte wenigstens mal Rückmeldung geben :) es funktioniert wieder alles wie es soll, es war keine Neuinstallation notwendig.ich hatte ja oben die Authentifizierungseinstellungen gepostet die ich aus der EXchange Management Shell hatte. Nun wollte ich ein letztes mal ochmal schauen und habe mir diesmal die Authentifizierungseinstellungen nochmal genau angeguckt aber im IIS.
Und siehe da die Authentifizierungseinstellungen waren anders als mir die Management Shell ausgegeben hat. nachdem ich die Auth Einstellungen im IIS gesetzt habe und nicht per EMS und einen Neustart durchgeführt habe läuft wieder alles bestens :)
Gruss Martin
- Als Antwort markiert NobbyausHBModerator Freitag, 24. Februar 2017 13:36
-
So ungewöhnlich ist es nicht. Wenn die Einstellungen der Webverzeichnisse im IIS Manager durchgeführt werden, kann es die Exchangekonfiguration nicht mitbekommen.
Der IIS Manager speichert die Konfiguration lokal auf der Maschine. Die Konfiguration über die Exchange Verwaltungstools wird AD abgelegt und von den Exchange Servern übernommen.
Also in der Praxis: Die Konfigurationsmöglichkeiten im IIS Manager für Exchange Server ist "nur zum Schauen, nicht zum Anfassen". Alle Konfigurationsapassungen sollten immer mit den Exchange Tools erfolgen. Ausnahme die Aktivierung/Deaktivierung der IIS Logs.
Gruß Malte
-
Auch wenn der Thread etwas älter ist, würde ich gerne mit einem Tipp antworten, weil der Umstieg von SHA1 zu SHA2 auf zu diesem Fehlerbild führen.
Er bezieht sich auf die Tatsache, dass der Exchange 2013 (auch CU 15) nicht vollständig mit SHA2-Zertifikaten umgehen kann.
Hierbei spielen zwei Faktoren eine Rolle.
Erstens liegt die Schwäche beim Umgang mit den Zertifkaten in FBA-Authentifzierung (Benutzername + Kennwort-Eingabe) im OWA bzw. ECP.
Exterm verkürzt : Das OWA ist die eigentliche Anlaufstelle jeder Anmeldung - ganz gleich ob ECP ausgewählt oder nicht. Das Formular nimmt die Eingabe des Benutzers entgegen, verarbeitet diese und leitet wieder auf /owa zurück. Sollte die Anmeldung erfolgreich sein, wird ein Cookie abgelegt, was das Formular /owa ausliest und das Postfach resp. ECP öffnet.
Genau mit dem Cookie liegt die Wurzel an der ständigen Loop. Auch das Cookie wird verschlüsselt, sollte dies mit einem reinen SHA2-Zertikfat samt SHA2-Zertifikatskette verschlüsselt sein, hat OWA ein Problem. Es entschlüsselt es nicht richtig und verwirft die Anmeldung und man wird zur Anmeldung aufgefordert.
Mit dem zweiten Teil wird es fatal. Das SHA2 wird vom OWA nicht vollständig unterstützt, und zwar genau dann, wenn die gesamte Kette von der CA (mit ggf. Sub-CAs) bis einschließlich des Zertifikats vom OWA und ECP mittels des "Microsoft Software Key Storage Provider" , kurz KSP, erstelt wurde.
Es ist der Provider, der mit der Cryptography API: Next Generation (CNG) verwendet wird - von dort kennt man vielleicht das CNG, wenn man Requests in Windows mit dem SnapIn der Zertifikate erstellt.
Es geschieht gerne mal im Rahmen des Umstiegs wegen der Abkündigung vom alten Provider Microsoft RSA SChannel Cryptographic Provider, der bekannt für seine SHA1-Zerts ist, dass er gegen den Nachfolger Microsoft Software Key Storage Provider ersetzt wird.
Der IE unter Win 10, FF und Chrome verweigern oder erschweren gerne schon den Zugang zu solchen Seiten.
Genau in der eigenen PKI, wo der oder (Sub)-CA alle den Key Storage Provider verwenden, kann das leider eine böse Falle werden.
Abhilfe:
-) man kann in der eigenen PKI eine SubCA mit Microsoft RSA SChannel Cryptographic Provider belassen. Diese Mischung aus CA und SubCA mit unteschiedlichen Providern soll den Anmelde-Loop vermeiden. Muss ich noch testen.
-) Vorsorge bei Beschaffung kommerzieller Zertifikate. Das dürfte in der Regel keine großen Schwierigkeiten bereiten. Mittels certutil -store my <SerienNrDesZerts> kann der Provider ermittelt werden.
Wenn die Anmelde-Loop eintritt, besteht meistens eine kostenlose Rücknahmemöglichkeit beim Austeller für 30 Tage.
Nachfolgend der Link, der das wunderschön erfasst hat: https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/