none
Probleme mit Windows Authentifizierung nach ADFS Installation RRS feed

  • Frage

  • Hallo,

    wir haben nach der Installation von ADFS erhebliche Probleme beim Login mit Microsoft Outlook.

    Ursprünglich haben wir ADFS installiert, um ein SSO für die Office365 Produkte zu ermöglichen (Ohne Exchange). Ferner haben wir für das SSO noch ein DNS Eintrag (TXT) vorgenommen und in der Domäne den passenden UPN Eintrag vorgenommen.

    Nach diesen Arbeiten war es uns nicht mehr möglich mit dem Outlook Client eine Verbindung aufzubauen. Es wird permanent das Passwort abgefragt.

    Wir haben dann ADFS und sämtliche vorgenommene Änderungen wieder rückgängig gemacht. Jedoch ohne Erfolg. Der Login über OWA funktioniert jedoch hingegen.

    Wir gehen davon aus, dass durch die Installation von ADFS etwas an der Authentifizierung verändert wurde.

    PS: Es handelt sich um einen Exchange 2016 mit Outlook 2010er Clients.


    • Bearbeitet SADFR Montag, 27. Februar 2017 08:19
    Mittwoch, 15. Februar 2017 16:50

Antworten

  • > Richtig. Wir haben es nur auf dem Exchange installiert, da https ohnehin auf diesen Server aufläuft (OWA). Richtig, die beiden haben sonst nichts miteinander zu tun.

    Ganz schlechte Idee. ADFS bringt einen eigenen Webserver mit (http.sys) und stört damit den IIS, den Exchange braucht.

    Zuerst musst Du also sicherstellen, dass der ADFS-Webserver wirklich weg bzw. nicht mehr konfiguriert ist (macht IMHO "netsh http" usw).

    Danach musst Du eventuell die IIS-vDirs von Exchange neu erstellen lassen.

    Das ist aber nichts, was man auf die Schnelle mal in einem Forum erklärt. Also eventuell holst Du Dir einen Fachmann dazu.

    Und für die Zukunft: NIEMALS etwas anderes auf einem Exchangeserver installieren, außer Exchange. Auch keine anderen Windows Feature. Und schon gar nichts mit einem Webserver.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 16. Februar 2017 10:54

Alle Antworten

  • Moin,

    verstehe ich das richtig: Du hast einen lokalen Exchange und zusätzlich ADFS für Office 365?

    Welchen TXT-Eintrag habt ihr da vorgenommen, da ist eigentlich nichts erforderlich (zumindest nichts dauerhaftes).

    Ein lokaler Exchange und ADFS für Office 365 haben normalerweise keine Verbindung. ADFS ändert auch nichts an der Authentifizierung im Exchange.

    Oder habt ihr ADFS etwas auf dem Exchange selbst installiert?


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 15. Februar 2017 19:10
  • verstehe ich das richtig: Du hast einen lokalen Exchange und zusätzlich ADFS für Office 365?

    Richtig. Damit die User sich beim Öffnen von Office Plus nicht ständig einloggen müssen. Hier hatten wir von Microsoft einen Beitrag gefunden wie wir dies mit einem SSO lösen können.

    Welchen TXT-Eintrag habt ihr da vorgenommen, da ist eigentlich nichts erforderlich (zumindest nichts dauerhaftes).

    Ist laut Microsoft erforderlich, damit man die Domain in Office365 hinzufügen kann. Hat mit ADFS nichts zu tun.

    Ein lokaler Exchange und ADFS für Office 365 haben normalerweise keine Verbindung. ADFS ändert auch nichts an der Authentifizierung im Exchange.

    Richtig. Wir haben es nur auf dem Exchange installiert, da https ohnehin auf diesen Server aufläuft (OWA). Richtig, die beiden haben sonst nichts miteinander zu tun.

    Oder habt ihr ADFS etwas auf dem Exchange selbst installiert?

    Wir haben die Rolle über den Server Manager installiert.

    Mittwoch, 15. Februar 2017 19:28
  • Einen kleinen Schritt sind wir weiter.

    Wenn wir die Autodiscover.xml abrufen, dann werden wir ebenfalls zur Eingabe des Passwortes aufgefordert.

    Rufen wir die autodiscover über servername/autodiscover/autodiscover.XML ab, dann funktioniert das Ganze auch ohne Eingabe eines Passwortes.

    Rufen wir die Datei von extern über externedomain.de/autodiscover/autodiscover.XML ab, dann funktioniert das auch, jedoch unter Eingabe von Benutzer und Passwort

    Rufen wir die Datei von intern über externedomain.de/autodiscover/autodiscover.XML ab, dann funktioniert das leider nicht. Es erscheint eine Passwortabfrage, jedoch wird das Passwort nicht akzeptiert. Das wird wohl auch genau das Problem sein warum das mit den Outlook Clients nicht funktioniert.

    Im DNS haben wir eine Forward Lookup Zone angelegt und zeigen mit dem externen Domänennamen auf den internen Exchange Server. Das Ganze machen wir weil wir für die Kommunikation ein echtes Zertifikat einsetzen.

    Mittwoch, 15. Februar 2017 22:50
  • > Richtig. Wir haben es nur auf dem Exchange installiert, da https ohnehin auf diesen Server aufläuft (OWA). Richtig, die beiden haben sonst nichts miteinander zu tun.

    Ganz schlechte Idee. ADFS bringt einen eigenen Webserver mit (http.sys) und stört damit den IIS, den Exchange braucht.

    Zuerst musst Du also sicherstellen, dass der ADFS-Webserver wirklich weg bzw. nicht mehr konfiguriert ist (macht IMHO "netsh http" usw).

    Danach musst Du eventuell die IIS-vDirs von Exchange neu erstellen lassen.

    Das ist aber nichts, was man auf die Schnelle mal in einem Forum erklärt. Also eventuell holst Du Dir einen Fachmann dazu.

    Und für die Zukunft: NIEMALS etwas anderes auf einem Exchangeserver installieren, außer Exchange. Auch keine anderen Windows Feature. Und schon gar nichts mit einem Webserver.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 16. Februar 2017 10:54
  • OK. Das war uns nicht klar.

    Mittlerweile konnten wir das Problem temporär lösen.

    Wenn wir im IIS für das MAPI und RPC die Authentifizierung auf Standardauthentifizierung setzen und Windows Authentifizierung deaktivieren, dann funktioniert es wieder. Jedoch gehen wir nicht davon aus, dass dies der Standard ist, oder?

    Donnerstag, 16. Februar 2017 11:32
  • Ich habe nun über netsh http show urlacl das ganze geprüft. Dort tauchen noch einige adfs Links auf. Zusätzlich ist anscheinend noch die interne Windows  Datenbank installiert. Diese würden wir als erstes deinstallieren.

    Reicht es aus die URL´s im urlacl mit netsh http delete urlacl "url" zu löschen, oder sind hier noch weitere Schritte notwendig um den IIS wieder sauber zu bekommen? Wäre dies das richtige Vorgehen?

    Donnerstag, 16. Februar 2017 12:31
  • Grundsätzliche solltest Du keine Änderungen am IIS vornehmen. Die Einstellungen im IIS müssen zur Konfiguration in Exchange passen.

    Daher sind die Einstellungen bis auf wenige Ausnahmen immer über die Exchange Werkzeuge durchführen. Schau Dir dort mal die Authentifzierungseinstellungen der vDirs an.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 16. Februar 2017 16:01
  • Habe die Einstellungen nun auch über die Exchange Management Shell angepasst, sodass im internen Netzwerk auch nur die Standardauthentifizierung genutzt wird. Das funktioniert nun auch so weit. Bleibt nur die Frage offen, wie wir die Windows Authentifizierung wieder zum laufen bekommen.
    Donnerstag, 16. Februar 2017 16:03
  • Ich habe den Server nun noch einmal geprüft und es ist so weit alles entfernt was mit ADFS zu tun hatte. Das einzige was nun weiterhin nicht funktioniert, ist die Windows Authentifizierung im IIS. So lange diese aktiv ist können sich die Nutzer nicht mehr mit ihrem Outlook am Exchange anmelden. Deaktivieren wir diese läuft alles problemlos. Allerdings wird dies wohl kaum eine empfohlene Konfiguration des Exchange Servers sein. Deshalb nun die Frage: Wie bekommen wir die Windows Authentifizierung vom IIS wieder lauffähig?
    Sonntag, 19. Februar 2017 23:14
  • Wir sind hier leider nicht wirklich weitergekommen. Hier nochmal die Schritte die wir durchgeführt haben:

    Wir haben einen Exchange 2016 auf einen Server 2012 R2 in eine Umgebung mit Exchange 2010 auf SBS 2012 installiert und die Postfächer vom Exchange 2010 auf den Exchange 2016 migriert. Danach funktionierte alles problemlos. Anschließend haben wir ADFS auf dem Exchange 2016 installiert.

    Daraufhin fiel sofort die Windows Authentifizierung auf dem Exchange 2016 aus und User konnten sich nicht mehr anmelden. Das Ändern der Authenfizierung auf Standardauthentifizierung hat zumindest das Problem behoben, dass die User sich nicht mehr anmelden konnten. Außerdem haben wir ADFS wieder vom Exchange 2016 entfernt.

    Nach einigen Versuchen, die Windows Authentifizierung wieder lauffähig zu bekommen, haben wir uns dazu entschieden, einen neuen Server 2012 R2 mit Exchange 2016 zu installieren und die Postfächer auf den neuen Exchange zu migrieren. Allerdings hat dies leider keinen Effekt gehabt. Die Windows Authentifizierung funktioniert auch auf dem neuen Exchange nicht.

    Wenn wir ein Postfach auf den SBS 2011 verschieben, funktioniert die Windows Authentifizierung, die beim SBS aktiv ist, problemlos. Sobald wir das Postfach zurück auf den neuen Exchange 2016 verschieben, bekommen die User wieder dauernd die Passwortabfrage.

    Mit get-outlookanywhere habe ich die Konfiguration geprüft. Diese war in allen Punkten identisch, bis auf dass der Exchange 2010 kein SSL für interne Clients verlangt und keinen internen Hostnamen eingetragen hat. Bei den Exchange 2016 ist der interne Hostname identisch zum externen Hostnamen eingetragen.

    Deshalb stellt sich mir nun die Frage, ob der Exchange die internen Clients, die alle über den externen Hostnamen zugreifen, als externe Clients behandelt und deshalb ohne Windows Authentifizierung arbeitet oder ob der Exchange die internen und externen Clients anhand anderer Merkmale unterscheidet.

     Hat jemand noch eine Idee was die Ursache für dieses Problem sein könnte und wie wir es beheben können?

    Montag, 27. Februar 2017 09:40
  • Hallo TMSD,

    Der SBS2011 beinhaltet einen Exchange Server 2010und dieser unterstützt direkte MAPI Verbindungen über RPC. Das hat sich mit Einführung vom 2013er Exchange geändert. Hier erfolgt die Clientverbindung immer über HTTPS.

    Wenn Ihr also ein Postfach auf den 2010er verlagert, dann kann der Outlook Client eine Verbindung über RPC/MAPI zum Server herstellen. Dabei wird NTLM oder Kerberos genutzt. Ein Postfach auf 2013/2016 muss über HTTP zugreifen.
    Ich gehe davon aus, dass:
    get-outlookanywhere -Server 2016er-Server
    Get-MapiVirtualDirectory | fl *url,*aut*
    die richtigen URLs und Authentifizierungsmethoden zurück liefert.

    Outlook greift auf die Konfiguration des IExplorers zurück. Wenn die URLs des 2016er Exchange nicht in der Liste der Zone "lokales Intranet" enthalten ist, wird auch keine integrierte Authentifizierung funktionieren und es kommt regelmäßig ein Anmeldeprompt.
    Nach manuellen Tests (einfach https://deineurl/* in die IExplorerzone eintragen), kann diese Einstellung über GPOs verteilen (Danach kann der Anwender die Zone nicht mehr selbst verwalten).

    Gruß Malte

    Montag, 27. Februar 2017 12:28
  • Die zurückgegebenen URL´s mit den Befehlen get-outlookanywhere und get-mapivirtualdirectory sind die richtigen und die Authentifizierungsmethoden waren auch richtig eingestellt, bis ich sie auf Standard umgestellt habe. Das mit der Zone lokales Internet müsste ich prüfen, aber es wundert mich schon, dass es zwei Wochen lang problemlos lief, bis wir ADFS auf dem Exchange 2016 installiert haben.
    Montag, 27. Februar 2017 14:37
  • Am 27.02.2017 um 15:37 schrieb TMSD:

    es wundert mich schon, dass es zwei Wochen lang problemlos lief, bis wir ADFS auf dem Exchange 2016 installiert haben.

    Wie dir schon gesagt wurde, ist das "Nicht-Funktionieren" danach kein Grund zum wundern, sondern eher zu erwarten. Wenns gar nicht geht, würd ich einfach einen neuen Server aufsetzen und die Postfächer umziehen.

    Bye
    Norbert

    Montag, 27. Februar 2017 20:56
  • Hallo Norbert,

    wir haben bereits einen neuen Exchange installiert und die Postfächer komplett auf diesen verschoben. Allerdings bleibt der Fehler der gleiche.

    Montag, 27. Februar 2017 21:28
  • Am 27.02.2017 um 22:28 schrieb TMSD:

    Hallo Norbert,

    wir haben bereits einen neuen Exchange installiert und die Postfächer komplett auf diesen verschoben. Allerdings bleibt der Fehler der gleiche.

    Nur die Postfächer verschoben, oder auch die ganze Konfiguration auf dem neuen Server vorgenommen? Ist der alte Server jetzt schon weg?

    Bye
    Norbert

    Montag, 27. Februar 2017 21:34
  • Wir haben die Postfächer verschoben, den neuen Exchange konfiguriert und den alten erstmal noch in der Exchange Organisation gelassen. Müssen wir den alten Exchange 2016 komplett entfernen um hier eine Änderung zu sehen?
    Dienstag, 28. Februar 2017 08:08
  • Am 28.02.2017 um 09:08 schrieb TMSD:

    Wir haben die Postfächer verschoben, den neuen Exchange konfiguriert und den alten erstmal noch in der Exchange Organisation gelassen. Müssen wir den alten Exchange 2016 komplett entfernen um hier eine Änderung zu sehen?

    Wozu ist der alte denn noch da?

    Bye
    Norbert

    Dienstag, 28. Februar 2017 16:06
  • So wir sind jetzt hier etwas weiter. Der Exchange 2016 ist nun der alleinige Exchange in der Umgebung. Daraufhin funktionierte die Windowsauthentifizierung auch wieder für alle Clients. Ca zwei Wochen später ist diese allerdings wieder ausgefallen. ADFS ist in der Umgebung auch nicht mehr im Einsatz

    Mittwoch, 22. März 2017 15:20
  • Entschuldigt die etwas unqualifizierte Antwort, aber so eine Installation fällt auf jeden Fall in die Kategorie:

    Kann man so machen, ist dann aber ***** (suboptimal).

    Interessant sind die allgemeinen Begründungen, warum man es für eine sinnvolle Lösung hält, AD FS auf einem Exchange Server zur Verfügung zu stellen.

    Bei der Nutzung von unterschiedlichen Web Applikationen auf einem IIS sollte man sich schon mit der Abhängigkeiten und Vererbungen einer web.config auskennen.

    Es ist aber schön zu sehen, dass diese Konfiguration inzwischen aufgelöst wurde.

    Gruß,
    Thomas


    Thomas Stensitzki - MCSM, MCM, MCSE, MCSA, MCITP - Blog: http://justcantgetenough.granikos.eu/

    Mittwoch, 22. März 2017 15:34