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.

Häufigste 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:

  • Gespeicherte Kennworte/Tresor
    Wenn ein Client Mitglied der Domäne ist und der Anwender sich an der Domäne anmeldet, sollten alle Anmeldunggen "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.
  • 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.
  • 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 garnicht erreichen soll.
  • Office 365/ADFS-Token
    Office 365 kommt immer häufiger zum Einatz 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.

Wenn damit das Problem noch nicht gelöst ist, dann können 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.

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.
  • 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}
  • 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
  • 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
    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 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.

Weitere Links