none
Microsoft Exchange Server Auth Certificate und ADFS/WAP RRS feed

  • Frage

  • Hallo zusammen,

    in einer Umgebung mit Exchange 2013 DAG, ADFS und WAP in der DMZ wird auf dem Exchange Server das Microsoft Exchange Server Auth Certificate bald ablaufen.

    In Umgebungen ohne ADFS habe ich es immer Problemlos erneuern können.

    Das Erneuern in dieser Umgebung führt dazu, dass danach keine Anmeldung per OWA oder ECP mehr möglich ist.

    Ist das Microsoft Exchange Server Auth Certificate mit an ADFS und/oder WAP gebunden?
    Muss hier ein zusätzlicher Schritt erfolgen?

    Vielen Dank für Tips und Anregungen im Voraus!

    Mittwoch, 22. August 2018 05:06

Antworten

  • Die Lösung für das Problem wurde gefunden...mehr oder weniger....

    Abwarten.

    Das Exchange Auth Zertifikat wurde wie vielfach auf verschiedenen Seiten beschrieben erneuert (wie z.B. diesem: http://www.messaginginsight.com/2017/06/03/setting-or-renewing-a-new-exchange-auth-certificate/ )und danach hies es abwarten.

    Nach etwas mehr als zwei Stunden gab es keine Fehlermeldungen mehr und der Zugriff war erfolgreich.

    Vom Techniker seitens Microsoft gab es keine nähere Erläurterung wie dies zu erklären ist. Aber der Lösungsansatz abwarten war bereits kommuniziert worden. In einem Betrieb mit 24/7 Produktionszeit und vielen auf OWA ausgelegten Prozessen ist so ein Zeitfenster natürlich nicht leicht zu finden.

    Grüße
    Mike

    • Als Antwort markiert M. Volkmann Dienstag, 4. September 2018 09:31
    Dienstag, 4. September 2018 09:31

Alle Antworten

  • Hallo M. Volkmann,

    Sieh Dir die offizielle Dokumentation:
    Active Directory Federation Services (AD FS) 2.0

    Gruß,

    Ivan Dragov


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.



    Donnerstag, 23. August 2018 05:02
  • Hallo Ivan,

    der Link ist unvollständig.
    Und es scheint sich um Doku zu Windows Server 2008 zu handeln.

    Das vorhandene ADFS ist auf Windows Server 2012. Die Exchange-Server auf 2012 R2.

    In den Dokumentationen zum OS bin ich bis jetzt nicht fündig geworden.

    Grüße

    Mike

    Donnerstag, 23. August 2018 05:09
  • Hallo Mike,

    Hast Du versucht, ein einzelnes Platzhalterzertifikat *.yourdomain.com für alle ADFS-, WAP- und Exchange-Publishing-Dienste zu verwenden, wie in diesem Thread vorgeschlagen:
    Certificate choices for Exchange 2013, ADFS and WAP
    Weitere Informationen zu Zertifikatanforderungen in der Office 365-Hybridkonfiguration werden in diesem Blogartikel beschrieben:
    Office 365 Hybrid Configuration Certificate Planning–ADFS, Exchange Web Services, OWA, OA??

    Gruß,

    Ivan Dragov


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Freitag, 24. August 2018 10:55
  • Hallo Ivan,

    es wurde inzwischen an Microsoft eskaliert.

    ADFS an sich funktioniert einwandfrei.
    Es wird mehr in Richtung Exchange recherchiert.

    Mir fallen nur ASP.NET Fehler (1309) im Eventlog nach dem publish des neuen Exchange Auth Certificate auf.

    Es ist aber keine fehlende Shared.config wie in diesem Artikel:

    https://support.microsoft.com/en-us/help/3099532/event-id-1309-and-you-can-t-access-owa-and-ecp-after-you-install-excha

    Hier die Fehlermeldung:

    Application information:

        Application domain: /LM/W3SVC/1/ROOT/owa-163-131804819150544090
        Trust level: Full

        Application Virtual Path: /owa
        Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\
        Machine name: Exchangeserver-1

     

      

    Process information:
        Process ID: 4384
        Process name: w3wp.exe
        Account name: NT-AUTORITÄT\SYSTEM

    Exception information:
        Exception type: AdfsConfigurationException
        Exception message: Encryption certificate is absent
       bei Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()
       bei Microsoft.Exchange.Security.Authentication.AdfsSessionSecurityTokenHandler.CreateTransforms()
       bei Microsoft.Exchange.Security.Authentication.AdfsFederationAuthModule.FederatedAuthentication_ServiceConfigurationCreated(Object sender, ServiceConfigurationCreatedEventArgs e)
       bei Microsoft.IdentityModel.Web.FederatedAuthentication.get_ServiceConfiguration()
       bei Microsoft.IdentityModel.Web.HttpModuleBase.Init(HttpApplication context)
       bei System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
       bei System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
       bei System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
       bei System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)



    Request information:
        Request URL: https://192.168.1.10:443/owa/healthcheck.htm
        Request path: /owa/healthcheck.htm
        User host address: 192.168.1.5
        User:  
        Is authenticated: False
        Authentication Type:  
        Thread account name: NT-AUTORITÄT\SYSTEM

    Thread information:
        Thread ID: 34
        Thread account name: NT-AUTORITÄT\SYSTEM
        Is impersonating: False
        Stack trace:    bei Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()
       bei Microsoft.Exchange.Security.Authentication.AdfsSessionSecurityTokenHandler.CreateTransforms()
       bei Microsoft.Exchange.Security.Authentication.AdfsFederationAuthModule.FederatedAuthentication_ServiceConfigurationCreated(Object sender, ServiceConfigurationCreatedEventArgs e)
       bei Microsoft.IdentityModel.Web.FederatedAuthentication.get_ServiceConfiguration()
       bei Microsoft.IdentityModel.Web.HttpModuleBase.Init(HttpApplication context)
       bei System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
       bei System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
       bei System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
       bei System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

    Ich werde berichten wie es weiter geht.

    Dienstag, 4. September 2018 05:41
  • Die Lösung für das Problem wurde gefunden...mehr oder weniger....

    Abwarten.

    Das Exchange Auth Zertifikat wurde wie vielfach auf verschiedenen Seiten beschrieben erneuert (wie z.B. diesem: http://www.messaginginsight.com/2017/06/03/setting-or-renewing-a-new-exchange-auth-certificate/ )und danach hies es abwarten.

    Nach etwas mehr als zwei Stunden gab es keine Fehlermeldungen mehr und der Zugriff war erfolgreich.

    Vom Techniker seitens Microsoft gab es keine nähere Erläurterung wie dies zu erklären ist. Aber der Lösungsansatz abwarten war bereits kommuniziert worden. In einem Betrieb mit 24/7 Produktionszeit und vielen auf OWA ausgelegten Prozessen ist so ein Zeitfenster natürlich nicht leicht zu finden.

    Grüße
    Mike

    • Als Antwort markiert M. Volkmann Dienstag, 4. September 2018 09:31
    Dienstag, 4. September 2018 09:31