none
Please help with Microsoft Federation Gateway Setup RRS feed

  • Frage

  • Hello,

    I need some help please for something i didn't get to work.
    It makes me crazy... ;)

    Site A:
    2x Exchange 2010 Mailbox Server in a DAG: ExData1 and ExData2
    2x Exchange 2010 Client Access and HUB Server in a NLB Cluster: ExCAS1 and ExCAS2. NLB-Name: ExCAS
    Mail-Domain: site-a.com

    Site B:
    1x Exchange 2013 Server (Mailbox, CAS, HUB)
    Mail-Domain: site-b.com

    Between both Sites exists a VPN Connection. So my Exchange Servers are able to reach and resolve each other internally.
    Proxy exists on both Sites. But there is no Proxy configured in Exchange and my CAS-Exchange-Servers on both Sites are able to get in the Internet without Proxy.
    On all CAS Servers "WSSecurity" Authentication is set to "true" for EWS and Autodiscover Virtual Directory
    On my external DNS Servers is a Host-A Entry with "autodiscover.domain.com" pointing to Public IP.

    What i have done so far:
    1. Exported Exchange Certificates (issued from an internal CA) and imported it on the other Exchange Servers
    2. Created a new Federation Trust on both Sites
    3. Placed a TXT DNS Record on my external DNS Server
    4. Enabled Federation Trust on both Sites
    5. Added Organisation Relationship on both Sites

    Because there is a trust between both Domains with Conditional Forwarder DNS Records like "autodiscover" are resolved to there internal IPs.

    Unfortunatelly i did not get it worked. No Free. No Busy.
    So please help me to do some Troubleshooting here?

    Thanks!

    Kind Regards
    Marco

    Montag, 21. März 2016 15:03

Antworten

  • Hallo,

    also ich denke ich habe es hingebracht.

    Wie geschrieben musste ich für den Reverse Proxy auf Site A noch eine Ausnahme machen, damit das EWS Verzeichnis direkt zugänglich ist.

    Anschließend funktionierte es zwar noch nicht, aber folgender Befehl brachte mich auf die Fährte (ausgeführt von Site A):

    Test-OrganizationRelationship site-b.com -UserIdentity user@site-a.com -verbose

    Fehlermeldung:
    --------------------
    VERBOSE: [03:03:39.406 GMT] Test-OrganizationRelationship : The delegation token was successfully generated.

    VERBOSE: [03:03:39.422 GMT] Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service is being called
     to determine the remote organization relationship settings.
    VERBOSE: [03:03:39.422 GMT] Test-OrganizationRelationship : The client will call the Microsoft Exchange Autodiscover
    service using the following URL: https://autodiscover.site-b.com/autodiscover/autodiscover.svc/WSSecurity.

    VERBOSE: [03:03:39.438 GMT] Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service failed to be called at 'https://autodiscover.site-b.com/autodiscover/autodiscover.svc/WSSecurity' because the following error occurred: SoapException.Code =
    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd:InvalidSecurity
    --------------------

    Nach etwas googeln stieß ich auf folgenden MS KB:
    https://support.microsoft.com/en-us/kb/2752387

    Ich habe mit folgenden Befehlen geprüft, ob "WSSecurityAuthentication" aktiviert war:
    Get-AutoDiscoverVirtualDirectory | fl name, WSSecurityAuthentication
    Get-WebServicesVirtualDirectory | fl name, WSSecurityAuthentication

    Obwohl beide auf "True" standen, habe ich das ganze einfach nochmal gesetzt:
    Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication $True
    Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $True

    Anschließend noch ein "iisreset" und auch Free/Busy von der anderen Richtung funktionierte auf Anhieb.

    Eine schwere Geburt.

    Ich versuche jetzt noch rauszufinden, was wirklich zur Lösung des Problems beigetragen hat und welche Dinge überflüssig waren (z. B. Externer autodiscover-DNS Eintrag, FYDIBOHF255SPDLT-DNS Eintrag, Basic Authentication im EWS Verzeichnis)

    Danke.

    Gruß

    Marco


    • Bearbeitet Treeeman Dienstag, 22. März 2016 11:58
    • Als Antwort markiert Treeeman Mittwoch, 23. März 2016 05:38
    Dienstag, 22. März 2016 11:53

Alle Antworten

  • you also exported the ca certificate from the Domains and put it to the trusted Root certification authorities from the Other Domain? Sounds like you only exchanged the Exchange certs. but domain a dont Trust the cert from Domain b :)

    Ich bin viel mobil unterwegs. Verzeiht die manchmal mangelnde Rechtschreibung. :-)

    Montag, 21. März 2016 23:22
  • I exported the Root-CA-Certificate from Site A (which comes from an internal CA) and imported it on Site B (as Trusted Root Authority and intermediate Authority) and vice versa. So i am able to access my URLs (https://autodiscover..., https://servername..., OWA and EWS-Directory, etc.) from one Site to the other Site without any Certificate Warning.

    Thanks!

    • Bearbeitet Treeeman Dienstag, 22. März 2016 06:42
    Dienstag, 22. März 2016 06:14
  • Ich mach mal auf Deutsch weiter, wir sind hier im Deutschen Forum.

    Wenn Federation eingerichtet wird, stellt Microsoft in Redmond das Zertifikat aus.

    ;)


    Gruß Norbert

    Dienstag, 22. März 2016 09:05
    Moderator
  • Ups. Dann machen wir Deutsch weiter. Auch ok. ;)

    Beim Einrichten des Federation Trusts wurde automatisch ein entsprechendes Federation Certificate erstellt.
    Wie bereits geschrieben, existiert der Federation Trust mit dem Microsoft Federation Gateway bereits.
    Ein Thumbprint wurde zurückgegeben und als TXT File auf meinem externen DNS abgelegt.
    Das abschließende Aktivieren des Federation Trusts war dann auch möglich und ich konnte dann problemlos meine Organisationsbeziehung zur Remote Domäne anlegen.

    Ich habe gestern noch das ein oder andere angepasst.

    User von Site B können Free/Busy Zeiten von Site A abrufen... irgendwie.
    Ich habe gestern noch festellen müssen, dass auf Seite B noch der externe Host-A Eintrag "autodiscover.site-b.com" fehlte und habe den am externen DNS nachgepflegt. Wobei ich mir nicht sicher bin, ob das wirklich notwendig gewesen wäre. Autodiscover wird extern nicht genutzt. Evtl. braucht das MFG diesen Eintrag?!

    Außerdem habe ich gesehen, dass in der "Organisationsbeziehung" eine Anwendungs-URI "FYDIBOHF255SPDLT.site-a.com" bzw. "FYDIBOHF255SPDLT.site-b.com" auftaucht. Diese konnte kein Exchange auflösen. Hier habe ich entsprechende Host-A Einträge in meinen internen DNS Servern hinzugefügt, damit diese Namen mit der internen IP aufgelöst werden und somit über den bestehenden VPN Tunnel gehen.

    Anschließend kam im OWA von Site B zumindest ein neuer Fehler, dass der Remote-Exchange-Server "beschäftigt" sei. Nach etwas googeln und suchen stellte ich dann fest, dass auf den Exchange Servern in Site A im EWS Verzeichnis im IIS die Standardauthentifizierung aktiviert war, das Probleme machen kann und per Default eigentlich deaktiviert ist. Das habe ich daher gestern Abend noch deaktiviert. Seit heute früh, ohne weiteres zutun, funktioniert zumindest jetzt die eine Richtung.

    An der anderen Richtung arbeite ich noch.
    Wobei ich hier zwischenzeitlich erfahren habe, dass ein Reverse Proxy eingesetzt wird und externe Zugriffe auf "owa.site-a.com/EWS/exchange.asmx" scheinbar nicht direkt zu meinen Exchange Servern durchgeht. Nach meinem Verständnis benötigt aber das MFG genau diesen Zugriff.

    Danke.

    Dienstag, 22. März 2016 10:13
  • Hallo,

    also ich denke ich habe es hingebracht.

    Wie geschrieben musste ich für den Reverse Proxy auf Site A noch eine Ausnahme machen, damit das EWS Verzeichnis direkt zugänglich ist.

    Anschließend funktionierte es zwar noch nicht, aber folgender Befehl brachte mich auf die Fährte (ausgeführt von Site A):

    Test-OrganizationRelationship site-b.com -UserIdentity user@site-a.com -verbose

    Fehlermeldung:
    --------------------
    VERBOSE: [03:03:39.406 GMT] Test-OrganizationRelationship : The delegation token was successfully generated.

    VERBOSE: [03:03:39.422 GMT] Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service is being called
     to determine the remote organization relationship settings.
    VERBOSE: [03:03:39.422 GMT] Test-OrganizationRelationship : The client will call the Microsoft Exchange Autodiscover
    service using the following URL: https://autodiscover.site-b.com/autodiscover/autodiscover.svc/WSSecurity.

    VERBOSE: [03:03:39.438 GMT] Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service failed to be called at 'https://autodiscover.site-b.com/autodiscover/autodiscover.svc/WSSecurity' because the following error occurred: SoapException.Code =
    http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd:InvalidSecurity
    --------------------

    Nach etwas googeln stieß ich auf folgenden MS KB:
    https://support.microsoft.com/en-us/kb/2752387

    Ich habe mit folgenden Befehlen geprüft, ob "WSSecurityAuthentication" aktiviert war:
    Get-AutoDiscoverVirtualDirectory | fl name, WSSecurityAuthentication
    Get-WebServicesVirtualDirectory | fl name, WSSecurityAuthentication

    Obwohl beide auf "True" standen, habe ich das ganze einfach nochmal gesetzt:
    Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication $True
    Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $True

    Anschließend noch ein "iisreset" und auch Free/Busy von der anderen Richtung funktionierte auf Anhieb.

    Eine schwere Geburt.

    Ich versuche jetzt noch rauszufinden, was wirklich zur Lösung des Problems beigetragen hat und welche Dinge überflüssig waren (z. B. Externer autodiscover-DNS Eintrag, FYDIBOHF255SPDLT-DNS Eintrag, Basic Authentication im EWS Verzeichnis)

    Danke.

    Gruß

    Marco


    • Bearbeitet Treeeman Dienstag, 22. März 2016 11:58
    • Als Antwort markiert Treeeman Mittwoch, 23. März 2016 05:38
    Dienstag, 22. März 2016 11:53
  • Autodiscover etc müssen klappen.

    Du kannst auch in die Zeitfalle getappt sein, da die Zertifikate von MS nicht UTC sondern PST Zeit haben.

    ;)


    Gruß Norbert

    Dienstag, 22. März 2016 12:03
    Moderator
  • Zeitfalle?
    Bedeutet das ich hätte das Problem einfach aussitzen können oder habe ich unbewusst was gemacht?

    Danke.

    Dienstag, 22. März 2016 13:01
  • Ja, es gibt da ein (bekanntes) Problem wegen des Zeitunterschiedes DE - USA Westküste.

    Ich warte mittlerweile immer einen Tag.

    ;)


    Gruß Norbert

    Dienstag, 22. März 2016 16:08
    Moderator
  • Alles klar.
    Dann werde ich mir das für die Zukunft auch angewöhnen.

    Danke nochmal.

    Mittwoch, 23. März 2016 05:38