Kennwortbox

"Normalerweise" melden sich Outlook, Lync und andere Programme im Netzwerk fast immer automatisch an. Active Directory und Windows stellen sehr elegant ein Single Identity" und "Single-SignOn" bereit. Windows Clients können sich an entsprechenden Diensten automatisch per NTLM oder Kerberos anmelden, wenn die Dienste dies unterstützen. Dennoch gibt es immer mal wieder den Fall, dass Outlook, Lync oder andere Programme die Eingabe von Anmeldedaten anfordern.

Das ist "normal", wenn Sie z.B. extern unterwegs sind und sie daher kein Kerberos-Ticket haben, ein Proxy die NTLM-Anmeldung stört oder der Dienst keine integrierte Anmeldung unterstützt. Es gibt aber noch weitere Ursachen, die eine automatische Anmeldung scheitern lassen. Diese Seite will die verschiedenen Möglichkeiten zur Fehlersuche vorstellen.

Sie sollten bei Kennwortboxen immer vorsichtig sein, insbesondere wenn UAC Kennworte abfragt, denn auch Keylogger und Malware versucht gerne mal Zugangsdaten abzugreifen.

Häufige Fehler

Ehe wir in das "Debugging" gehen will ich erst mal die gängigen Fehler nennen, die aus meiner Sicht am häufigsten die Ursache sind:

Prüfung Status

Konto gesperrt

Es mag Sie Überraschen, aber wenn Outlook auf die HTTP-Anfragen mehrfach 401 bekommt, dann geht es davon aus, dass das Kennwort falsch ist und fragt nach. Outlook kann dabei aber nicht unterscheiden, was der reale Grund war. Ein gesperrtes Konto ist ebenso möglich.

Kennwort Speichern = Tresor

Das erste Problem ist schon Windows selbst. Starten sie auf dem Client mal "Tresor"  (also den Benutzerkennworttresor) hat vielleicht mal jemand bei so einer Anfrage schon Benutzername/Kennwort eingegeben und dann "bitte speichern" gedrückt? Wenn der User dann sein AD-Kennwort ändert, dann kommt dieser Fehler. (und in der Regel wird das Konto auch ab und an gesperrt)

Wenn ein Client Mitglied der Domäne ist und der Anwender sich an der Domäne anmeldet, sollten alle Anmeldungen "integriert" funktionieren. Dennoch kann es früher ja schon mal gewesen sein, dass der Anwender unterwegs gearbeitet hat und eine frühere Kennwortbox ausgefüllt und das Kennwort gespeichert hat. Prüfen Sie daher den "Tresor" von Windows auf falsche gespeicherte Credentials.

Rund um Kerberos/NTLM

Seit Exchange 2010 SP2 ist es sehr einfach auch "Kerberos" für das CAS-Array zu nutzen. Kerberos wird intern auch gerne für die Anmeldung an Webseiten genutzt. Wenn die InternalURL aber auf einen Alias verweist, dann gibt es vielleicht keinen passenden SPN dafür. Oder es gibt von früheren Altinstallationen noch einen alten Server, der noch Reste hat und so Kerberos verhindert. Der Fallback zu NTLM funktionieren am Anfang gut aber je mehr Anwender auf den Server verlagert werden, desto eher kann es zu Kennwortboxen kommen. Kommen die Meldungen gehäuft am Morgen, wenn sich viele Benutzer gleichzeitig anmelden ?

OAB und Kerberos

Wenn Sie Exchange 2010 mit einem CAS-Array einsetzen, dann könnten Sie der Empfehlung gefolgt sein und Kerberos aktiviert haben (Siehe auch CAS und Kerberos). Dabei wird gerne übersehen, dass das Skript leider vergisst das "OAB"-Verzeichnis zu konvertieren. Meist startet Outlook sauber und es können alle Funktionen genutzt werden nur dass OAB aktualisiert sich nicht und manchmal kommt eben beim Versuch eine Kennwortbox.

Proxy-Server

Gerade wenn Sie Outlook über HTTP betreiben (RPC/HTTP oder MAPI/HTTP) und dabei über einen Proxy gehen, kann ein Proxy-Wechsel (Hochverfügbar, Loadbalancer) zwischendurch eine erneute Anmeldung erfordern. Das ist meist nicht der Fall, wenn Sie an einem Hotspot sind, der sie rauswirft und eben auf jede HTTP-Anfrage die Portalseite/Anmeldeseite liefert. Wenn die Anmeldung aber über einen normalen 403.1 geht, fragt Outlook nach.

Im Gegensatz zum MAPI/RPC Zugriff sind die Zugriffe auf OAB/EWS etc. Natürlich http Zugriffe (InternalURL). Ein Client sollte diese Dienste "direkt" erreichen, also nicht über einen Proxy gehen, der im IE eingetragen wurde. Oder per WPAD o.ä. hinterlegt wurde. Denn ein Proxy zerstört meist die NTLM Anmeldung

Es wäre auch nicht das erste mal dass lokale Firewalls in Form von Virenscannern oder IE Add-ons, die in den Transport reinschauen, eine Anmeldung behindern.

Netzwerk-Wackler"

In vielen Fällen ist es auch ein Loadbalancer, ein Adapter-Teaming o.ä., was dafür sorgt, dass der Client die Verbindung verliert und dann davon ausgeht, dass er "extern" ist. Über diesen Weg spricht er aber oft andere URLs mit anderen Authentifizierungsverfahren an, die er von intern gar nicht erreichen soll. Dazu zählen auch "Mehrfachverbindungen", also wenn ihr Notebook per LAN und WLAN im Netzwerk ist und eine Verbindung mal "wackelt". Sie können bei einigen Notebooks einstellen, dass bei einer aktiven LAN-Verbindung das WLAN nicht aktiv ist.

Office 365/ADFS-Token

Office 365 kommt immer häufiger zum Einsatz und es kann durchaus sein, dass sie per ADFS schon ein anderes Token bekommen haben. Das passiert gerne, wenn Sie Office 365 ProPlus über Office 365 lizenzieren aber ihr Postfach woanders liegt. Es hilft nicht, wenn Outlook dann das ADFS-Token der Office 365 ProPlus-Verbindung zum Exchange sendet.

Shared Mailbox gelöscht

Als Anwender können Sie in Outlook zusätzliche Postfächer öffnen, indem Sie diese im Profil hinzufügen.

Wird so ein Postfach dann später wieder gelöscht, dann bleibt es im Outlook Profil natürlich erhalten.

Public Folder/Öffentliche Ordner

Ein weitere Punkt sind Zugriffe auf öffentliche Ordner, die gerade bei einer Migration gerne Probleme verursachen, entweder weil Sie die öffentlichen Ordner "unsauber" zurückgebaut haben oder auf den Postfächern und Datenbanken noch auf Public Folder-Datenbanken verwiesen wird, die es nicht mehr gibt. Kontrollieren Sie den Default Public Folder Store auf den Postfachdatenbanken und ggfls. hilft es auch das Profil einmal "frisch" zu machen.

Kann es sein, dass der Client auf einen Server in einem anderen Standort zugreift, weil der Ordner lokal nicht vorhanden ist ?. Das passiert gerne mit "EForms", die von einem Admin vielleicht lokal angelegt werden aber damit in der gesamten Organisation "nutzbar" wird. Dummer nur, wenn dann Siteübergreifend oder Domainübergreifend die Anmeldung fehlt schlägt.

Internet Zoneneinstellungen IE, Internetzonen und Outlook

Wenn eine Applikation wie Outlook per RPC/HTTP, MAPI/HTTP kommuniziert oder die Exchange Web Services nutzt, ist WinHTTP der Unterbau und damit auch der HTTP-Proxy und die Authentifizierung relevant. Wenn die Ziel-URL nicht als "Intranet-Zone" definiert ist, werden die verschiedenen Clients weder NTLM noch Kerberos versuchen und stattdessen "Basic Auth" anbieten.

Die Einstellung im IE steuert, ob die URL (InternalURL) als "Trusted" angesehen wird, um überhaupt eine automatische Anmeldung zu unterstützen. Aber dann sollte zumindest eine manuelle Eingabe funktionieren. Da das bei ihnen wohl nicht geht, ist das auch kein Problem.

IIS Einstellungen

Natürlich kann es auch eine Einstellung auf dem Server sein. Falsche Einstellungen bei der Authentifizierung oder z.B. ein SSL-Zwang bei Autodiscover können den Client blockieren.

Outlook Anywhere

Lync nutzt Exchange und wenn die Messagebox einen "MAPI-COM.Server" als Titel hat, dann dürfte Outlook Anywhere nicht auf NTLM stehen. Prüfen Sie dann auf Exchange schnell mal die Einstellungen. Besonders gemeint sind unterschiedliche Einstellungen auf verschiedenen CAS-Servern.

[PS] C:\>Get-ExchangeServer |get-outlookanywhere |ft server, iisauth*
 
Server            IISAuthenticationMethods
------            ------------------------
CAS01             {Basic, Ntlm}
CAS02             {Basic, Ntlm}
CAS03             {Basic}

Bug in Outlook mit RPC/HTTP

Im April 2019 Update für Outlook hat Microsoft eine Schleife gefixt, bei der Outlook wohl immer wieder nach Anmelddaten gefragt hat.

Location: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security
Value Name: AllowRequestsInNeedPasswordBehavior
Type: DWORD

0= Verhindere den Versand von Anfragen, solange ein Kennwort erwartet wird
1= Legacy Provider können weiter Anfragen senden aber MAPI/HTTP sendet nicht
2= Legacy Provider können keine Anfragen senden aber MAPI/HTTP darf senden.
3= Beide können weiterhin Anfragen senden. Es könnte aber das Konto aussperren

Es ist natürlich immer eine gute Idee erst mal nach Updates zu forschen. Gerade bei Office Click2Run kann das schon sehr schnell eine Lösung bringen, da Microsoft anhand der Telemetrie-Daten wohl gut mitbekommt, wenn irgendwo Probleme zunehmen.

 

Anmeldeverfahren

Wenn Sie interne Server erreichen wollen und eine Anmeldung erforderlich ist, dann kann es natürlich daran liegen, dass der Server keine integrierte Anmeldung erlaubt. Es kann aber auch sein, dass Sie sich sehr wohl anmelden könnten aber der Server die Anmeldung nicht "verstanden" hat und ihnen dann als Fallback nur noch "Basic" anbietet. So etwas finden Sie wirklich nur, wenn Sie sich den HTTP-Header anschauen, z.B.: mit Fiddler.

Trust und RemoteServer

Ich hatte schon mit einem Supportfall zu tun, bei dem die Anmeldung über Trusts erfolgen musste. Das ist z.B.: bei Ressourceforest schnell mal der Fall. Prüfen Sie den Trust, z.B.: indem Sie eine Ressource (Webseite, Dateishare, Drucker) mit Authentifizierung ansprechen.

Uhrzeit

Eigentlich sollten alle Server im Unternehmen die gleiche korrekte Uhrzeit haben und auch die Zeitzone sollte "passen". Das ist besonders beim Einsatz von Kerberos schon erforderlich, da die Tokens eine Verfallszeit hat.

Direct Access

Es kann sein, dass hier ein Problem ist, wenn die Exchange 2010 Server per IPv6 auflösbar aber nicht erreichbar wären. Wenn der Client auf IPv4 zurück fällt, und UAG das nicht umsetzt, dann erreicht der Clients nichts. Das dürfte aber bei ihnen auch nicht zutreffen, da ja ein Anmeldedialog kommt.

Loadbalancer/Firewall

Auch ein Loadbalancer "könnte" Ursache sein, nämlich wenn Authentifizierungen nicht sauber durchgereicht werden, (weil der Clients z.B. NTLM statt Kerberos/Basic) verwendet und der Loadbalancer mit Source-NAT arbeiten muss. NTLM hat so seine Probleme mit Proxies, wenn diese den HTTP-Header verändern.

Auch TCP-Timeout-Einstellungen sollten immer so eingestellt sein, dass vom Client zum Server der Timeout immer kürzer wird. Eine vorgeschaltete Firewall und muss einen längeren Session-Timeout nutzen als ein zwischengeschalteter Proxy und der Exchange Server am Ende

Performance

Es kann natürlich auch ein Problem im Backend mit den Domain Controllern oder Exchange generelle sein. Microsoft hat dazu eine nette Seite veröffentlich.

Add-Ons

Zuletzt kann es natürlich auch ein Add-On sein, welches in Outlook geladen ist und für den Anmeldedialog verantwortlich sein. Auf die Schnelle können Sie Outlook einfach mal mit gedrückter "STRG"-Taste in den abgesicherten Mode starten.

In den meisten Probleme sollten Sie mit dieser Liste schon gefunden haben. Ansonsten bin ich an ihrer individuellen Lösung natürlich interessiert um sie hier zu ergänzen. Wenn damit das Problem noch nicht gelöst ist, dann dürfen Sie nun tiefer einsteigen.

Werkzeuge

Anmeldedialoge bedeute fast immer, dass ein Netzwerkzugriff ein Problem hat. Dabei ist eine Verbindung möglich, da es ja kein "Timeout" ist, aber das angesprochene System meldet, dass der Client nicht angemeldet werden konnte. Entsprechend sind drei Hilfsmittel hier die erste Wahl um rauszubekommen, wer da angesprochen wird:

  • Anmeldefenster
    Schauen Sie sich das Fenster genau an. In der Überschrift finden sie oft den Servernamen oder die URL, die genau angesprochen wird. Es muss gar nicht immer Exchange sein, der Anmeldedaten verlangt.
  • NETSTAT mit den Optionen "-o" bzw. "-b"
    Dieses "Bordmittel" erlaubt ihnen auch eine Anzeige der aktuellen TCP-Verbindungen. Da die meisten Anmeldeprozesse TCP nutzen, können Sie somit zumindest die Liste der Zielserver einschränken.
  • IPCONFIG mit Option "/flushdns" oder "/displaydns"
    Wenn der Zugriff auf den Server nicht per IP-Adresse erfolgt, dann können Sie den lokalen DNS-Cache einfach löschen (/flushdns) und dann einfach einmal falsche Daten eintragen, bestätigen und dann mit "/displaydns" schauen, welche System aufgelöst wurden.
  • Internet Explorer
    Wenn Sie den Server und die URL können, dann kann ein Zugriff per Browser (mit und ohne Proxy) schon ein passender Test sein, um genauere Daten zu erhalten. Oft ist die Fehlermeldung hier schon ein erster Anhaltspunkt
  • NetMon 3 (Installation erforderlich)
    Mit NetMon können Sie auf dem Client oder am Switch (Mirror-Port) natürlich auch die Pakete mitschneiden. Viele Protokolle sind an sich unverschlüsselt (nur das Kennwort selbst ist gesichert). Netmon 3.4 auf dem Client kann zudem auf den "Prozess" herunter filtern, so dass Sie recht einfach bei der Eingabe von falschen Credentials auch sehen, welche Aktivität das auslöst.
  • Fiddler (Installation erforderlich)
    Sollte das verwendete Protokoll natürlich HTTPS sein, dann sehen Sie mit NETMON nicht mehr die Inhalte, Auch bei HTTP ist es nicht immer einfach, die Pakete im Netmon zu finden. Dann kommen Applikationstools wie Fiddler gerade recht, welche auf dem PC sich als "Proxy" einschleifen können und nach entsprechender Aktivierung auch HTTPS aufschlüsseln können. Hier sehen Sie dann auch die angebotene Authentifizierung und gesendeten Daten. Oft sogar auch eine beschreibende Fehlermeldung, die ein Prozess nicht anzeigt. Der reagiert ja nur auf den "401.3 Access Denied".
  • Sysinternals Procmon (Installation erforderlich)
    Diese kleine Tool kann die Aktionen von Programmen mit protokollieren. Filtern Sie hier auf "Netzwerk" um die entsprechenden Kommunikationswege zu erfahren
  • IISLog
    Wenn der Zugriff per HTTP auf einen Webserver erfolgt, dann kann auch ein Blick in die Logs des Webservers hilfreich sein. Hier müssen zumindest die Zugriffe mit der 401.3 Fehlermeldung sichtbar sein. Ansonsten kommt der Client ja schon gar nicht da hin. Zudem ist hier natürlich die angesprochene URL interessant. Das sollten Sie auch sehen, wenn die Verbindung selbst per SSL verschlüsselt ist.

Tipp: Geben Sie in der Anmeldebox einmal gültige Anmeldedaten eines komplett anderen Benutzers ein. Diesen Zugriff sollten Sie im IISlog dann sehr einfach finden.

get-cssite | `
   %{ `
      Test-CsKerberosAccountAssignment `
         -Identity $_.identity
   }
  • Die Applikation selbst
    Einige Programme erlauben ja selbst ein Logging (z.B. Lync) und sollten daher auf diese Funktionen überprüft werden. Oft bekommt man hier sehr schnell eine Information, welche Funktion fehl schlägt.
  • Eventlog
    Auch das Windows Eventlog ist immer wieder gerne ein Platz, an dem Anwendungen (z.B. Outlook) weitere Informationen hinterlegen.
  • IIS Request Tracking
    Der IIS 7.5 hat eine nette Funktion, mit der Sie auf dem Webserver einzelne Request genauer nachverfolgen können. Siehe auch IISDebugging
  • STRACE
    Erlaubt lokal im "WinHTTP" einen Trace zu aktivieren und die Requests vorher abzufangen.

Es gibt sicher noch jede Menge andere Werkzeuge. Dies hier sind aber die auch von mir häufig eingesetzten Tools.

Weitere Links