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 "Sigle-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.
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 kennen, 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. - 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.
Prüfpunkte
Da sie nun die Werkzeuge zur Hand haben, können wir verschiedene Prüfungen angehen, um der Ursache für plötzlich aufpoppende Authentifizierungsfenster auf den Leib zu rücken. Hier ein paar Ideen:
- Öffentliche Ordner
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. - 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) - 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. - Proxy-Einstellungen
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 - "Intranet/Trusted-Zone"
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. - Rund um Kerberos
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.
Prüfen Sie z.B. mit DumpSPN, dass die SPNs eindeutig und dem korrekten Konto zugewiesen sind. - 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. - Lokaler "Zwangsproxy"/VPN
Es wäre nicht das erste mal dass lokale Firewalls in Form von Virenscannern oder IE AddONs, die in den Transport reinschauen, eine Anmeldung behindern - DirectAccess
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
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. - AddOns
Zuletzt kann es natürlich auch ein Addon 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.
Weitere Links
- NetMon 3
- Fiddler
- IISDebugging
- STRACE
- 956531 Outlook 2007 prompts you repeatedly for a password under certain network conditions
