none
[Exchange 2013] Kein login bei OWA und ECP möglich nach zertifikatsumstellung RRS feed

  • 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=0

    Bei den Protokollen 443 ist das neue Zertifikat hinterlegt.

    Hier die Bindings der Exchange Backend Webseite:

    http *:81:
    net.pipe *
    https *:444: sslFlags=0

    Ich 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



    Dienstag, 31. Januar 2017 12:49

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

    Freitag, 24. Februar 2017 11:17

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
    Freitag, 10. Februar 2017 15:45
  • Moin,

    dass Du die BackEnd-Website angefsst hast, ist natürlich bedauerlich. Am FrontEnd ist Dein Problem möglicherweise dies:

    https://support.microsoft.com/en-us/help/3032024/outlook-web-app-and-ecp-redirect-to-the-fba-page-in-exchange-server-2013


    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

    Freitag, 10. Februar 2017 16:01
  • 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:33

    Klicke 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
    Mittwoch, 15. Februar 2017 07:29
  • 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

    Donnerstag, 16. Februar 2017 22:48
  • Hallo Malte,

    also die OWA und ECP Virtualdirectory habe ich schon neu erstellt, brachte bis dato kein Erfolg. Diese Vorgehensweise liest man sehr oft im netz bei http Fehlern im OWA. Aber leider half das bei mir nichts.

    Freitag, 17. Februar 2017 12:40
  • Moin,

    ich würde einen neuen Exchange mit dem aktuellen CU15 installieren, die Mailboxen verschieben, dann den Exchange deinstallieren und den Server rausnehmen.

    Hat noch keiner gefragt - ist das Physik oder eine VM?

    ;)


    Gruß Norbert

    Freitag, 17. Februar 2017 19:31
    Moderator
  • 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

    Freitag, 24. Februar 2017 11:17
  • Hallo,

    das ist zwar mehr als ungewöhnlich aber danke für die Rückmeldung.

    Teilst du uns bitte noch mit, ob das eine physische Maschine oder VM ist?

    Bitte nach der Installation des nächsten RU wieder prüfen!

    ;)


    Gruß Norbert

    Freitag, 24. Februar 2017 13:36
    Moderator
  • 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

    Freitag, 24. Februar 2017 20:13
  • 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/
    Dienstag, 25. Juli 2017 22:31