Outlook 2016 - Verzweifelung wegen ständiger Abfrage Kennwort

1st Official Post

    Hallo Community,

    meine eigene Testfarm Exchange 2019 bringt mich zur Verzweifelung und kostet aktuell viele Nerven. :(

    Wir haben für interne Zwecke immer eine kleine Exchange DAG laufen bisher EX2016 (2 Knoten)
    Diese haben wir vor 1 Woche durch ein Exchange 2019 System der gleichen Art ersetzt, 2 Knoten jeder 64 GB RAM DAG

    Nachdem wir die Exchange 2016 sauber deinstalliert haben, können wir mit keinem Outlook mehr eine saubere Verbindung aufbauen.
    es kommt nach dem Start sofort die Frage nach dem Passwort über Windows Sicherheit.
    Man kann das Passwort auch 100 x eingeben und er fragt weiter.
    Wenn man die Passwort-Abfrage einfach weg klickt kann man arbeiten, die Mails im Posteingang werden synchronisiert aber z.B. eine Suche bringt sofort Fehlermeldung "da hat etwas nicht geklappt" und es kommt das Fenster zur Passwortabfrage.
    Man kann auch problemlos Mails beantworten ... die Kommunikation mit dem Server selbst über HTTP / Mapi scheint also zu laufen ..

    Was mich hier so frustriert ist das fehlen eines konkreten Hinweises auf den Fehler oder eine Fehlermeldung in irgendeinem Protokoll.
    Hier hoffe ich auf Eure Hilfe, vielleicht habe ich einfach noch nicht das richtige Protokoll gefunden.

    Fehlerbild :
    Outlook lokal und Outlook über Outlook-Anywhere von einem Remote Standort verlangen ständig nach dem Passwort bzw. Nutzername Passwort
    OWA über HTTPS und Active Sync bei Mobilgeräten laufen einwandfrei

    Zertifikat : ist gültig und eingebunden (aber Wildcard) lief aber bisher bei dem Exchange 2016 einwandfrei

    Bisherige Tests :

    - Autodiscover im Outlook / E-Mail Autokonfiguration alles OK. keine Fehler
    - alle virtuellen Verzeichnisse 2 x geprüft alles ok.
    - Auth für HTTPMapi versucht mit NTLM und mit "Verhandeln" keine Änderung

    auf den Exchange CAS in den Logs /Logging/MAPIHTTP / LoggingHTTP Proxy

    alles geprüft, man sieht die Connections aber keine Fehlermeldungen

    - DNS angepasst, per Hosts Datei auch mal einen Client direkt auf einen der beiden CAS gezwungen ...
    - Test des RCA von außen läuft ohne Probleme
    - Natürlich auch mal im Outlook alle Profile gelöscht, ein neues Profil angelegt usw.
    - Logging im Outlook aktiviert im Log sind auch keine Fehler zu sehen

    Den Outlook connectivity Test auf dem Exchange laufen lassen, der kleine Test läuft völlig ohne Fehler durch, der Deep Test erzeugt einen
    Fehler zu dem ich aber nichts im Web finde und der auch nicht auf das Problem hinweist.


    Vielleicht hat jemand von Euch noch einen Tip für mich wo man suchen könnte bzw. weiß jemand konkret in welchem Log solche Anmelde-Fehler auftauchen müssten.


    Viele Grüße

    Christian

    • Official Post

    Moin,

    das wird sich aus der Ferne schwer klären lassen. Dafür braucht es zu viel Hintergrundwissen vor Ort.

    Ich würde auf einem betroffenen Client "Fiddler" nutzen und den HTTPS-Traffic analyisieren. Eventuell findest Du dann einen Hinweis.

    Der Screenshot deutet auf einen nicht korrekt durchgeführten Mailbox-Move hin, kann aber nur schwer aus der Ferne tiefer analyisiert werden.

    Hallo Robert,

    vielen Dank .. dass mit dem Fiddler werde ich testen, vielleicht sieht man dort ob irgendwo ein Handshake oder etwas ähnliches abgelehnt wird.

    Ich hatte die Hoffnung das jemand hier im Forum (also entweder du oder Norbert :D ) so tief drin steckt und mir genau sagen kann in welchem der Logs
    man den Prozess der Anmeldung eines Outlook Clients über HTTPS / RPC-over-HTTP finden kann, ich finde bei MS nur eine Auflistung aller Logs,
    kann aber nicht genau sehen, in welchem konkret welche Vorgänge stehen.
    Irgendwo muss ja für jedes Mal Passwort eintippen ein Log Eintrag sein, der auf ein "Error" oder "not Accepted" läuft, nur habe ich das noch nicht gefunden um
    diesem Problem endlich näher zu kommen. :cursing:
    Es könnte ja sein, dass diese Anmeldungen auch schon im Log des IIS auf dem CAS stehen.

    Christian

    • Official Post

    In die IIS Logs kannst Du gerne schauen, dass wir Dir aber nicht so viel helfen. Da steht drin, dass abgelehnt wurde, aber nicht warum. Außerdem ist das Log i.d.R. so voll, dass Du Deine Einträge kaum finden wirst.

    Sinnvoller ist es hier meistens, die Suche auf dem Client zu beginnen, weil dort weniger drauf stattfindet und man besser erkennen kann, wann die Kennwort-Abfrage kommt. Die muss nicht zwingend im Hauptkonto und RPC/MAPI sein. Es kann ja auch aus EWS kommen, wenn z.B. im Hintergrund frei/belegt-Infos von einem Konto geladen werden, das es nicht mehr gibt. Oder vom OAB, falls da was schief ist.

    Auf dem Server müsstest Du viele Logs in hohem Umfang durchforsten, auf dem Client erst mal nur einen Ablauf checken.

    YFYI

    wir haben es nach 4 Tagen jetzt hinbekommen ...
    Ich hatte heute eine Remote Session mit einem befreundeten Exchange Consultant (danke @Ralf Tessmann ) und bin zusammen mit Ihm noch mal die komplette Konfig durchgegangen,
    da wir auch nach 2h keinen richtigen Fehler gesehen haben und alles korrekt konfiguriert war, sind wir dann Trial an Error an die Sachen gegangen die
    "eigentlich" i.o. waren wie z.B. das Wildcard Zertifikat.

    Nach dem Austausch des Wildcards gegen ein normales Zertifikat mit dem Public Name der Domäne als mail.domäne.de und dem passenden Autodiscover dazu lief auf einmal alles perfekt,
    obwohl auch mit dem Wildcard die RCA Tests und die Auto Ermittlung über das Outlook absolut keine Fehler gezeigt hatten.

    Als Fazit :
    Es sieht so aus als ob EX2019 nun mittlerweile generell kein Wildcard mehr haben will, bisher gab es ja nur Probleme bei Bindung an IMAP / POP SSL und SMTP.
    Mal sehen ob das noch jemand hier aus dem Forum verifizieren wird.

    Christian

    • Official Post

    Wobei es keine offizielle Aussage dazu gibt, dass Wildcard Zertifikate bei HTTPS nicht mehr funktionieren sollen. Im Gegenteil, wird im Artikel zum Erzeugen eines neuen Zertifikates sogar explizit ein Wildcard Cert benutzt:
    https://docs.microsoft.com/de-de/exchange…exchserver-2019
    https://docs.microsoft.com/de-de/exchange…exchserver-2019


    Natürlich gilt aus Sicherheitssicht gute Gründe gegen ein Wilcard-Cert, aber aus technischer eigentlich nicht. Allerdings darf man nicht vergessen, dass das Problem hier eventuell gar nicht Excvhange war, sondern Outlook, bzw. Windows auf dem Client!


    Nach der Aktionenbeschreibung könnte ich mir vorstellen, dass die Einstellung zur Authentifizierung zwischen IIS und Exchange nicht "synchron" waren. Das kann man teilweise über die GUI auch im IIS nicht sehen, wird aber stillschweigend bei solchen Aktionen mit korrigiert.


    Ich würde daher nun eine Gegenprüfung machen: Das Wild-Card Zertifikat wieder einrichten. Kommen die Probleme wieder, liegt es daran. Kommen die Problem nicht wieder, war es nicht die Ursache.