Share via

NTLM: Alte Zöpfe abschneiden ist nicht so einfach

  • Article

Hallo, hier ist nochmal der Herbert.

Wir sind in unserer Arbeit auf einen neuen Aspekt einer alten Geschichte gestoßen. Wir hatten ja schon gehofft, dass immer mehr Szenarien und Applikationen auf neue Anmeldemethoden wie Smartcards, Zertifikate und Kerberos umschwenken.

Es gibt noch etliche Szenarien, bei denen wegen fehlender Verbindung zu DCs oder Kompatibilitätsgründen mit älteren Systemen oder Applikationen NTLM verwendet werden muss. Dazu zählt Exchange, wenn RPC über HTTPS verwendet wird oder Web Proxy Szenarien. Bei letzteren kann man ab Microsoft ISA Server 2004 und Internet Explorer 7 auch Kerberos verwenden, was auch in Sachen Durchsatz Vorteile bringt wegen Ticket Caching.

Bei NTLM Anmeldungen in hoher Frequenz habt Ihr sicher schon gemerkt, dass eine künstliche Bremse im System ist. Es handelt sich im den Netlogon-Parameter „MaxConcurrentAPI“. Was wenig bekannt ist, dieser Parameter hat unerwartete Defaults abhängig von der Maschinenrolle:

- Mitglieds-Workstation: 1

- Mitglieds-Server: 2

- Domänen Controller: 1

Das Limit gilt pro Secure Channel. Nun können Mitglieder nur einen Secure Channel haben. Domänen Controller haben pro vertrauter Domäne einen Secure Channel. In vielen Fällen ist jedoch die Liste der Domänen, aus der die meisten Benutzer kommen, sehr kurz (zum Beispiel nur die Parent Domain). Immerhin kann ein Domain Controller innerhalb des Forests jede Domain direkt kontaktieren. Über Forestgrenzen hinweg wird jedoch den Trustpfaden gefolgt.

Nun kann man „MaxConcurrentAPI“ bis auf 10 anheben. Für Windows Server 2008 und Windows Server 2008 R2 gibt es einen Update, der die Grenze bis auf 150 anhebt:

975363          A time-out error occurs when many NTLM authentication requests are sent from a computer that is running Windows Server 2008 R2 or Windows 7 in a high latency network

Das sind also die Parameter zu den NTLM Authentifizierungen. Wie kann man nun diese Aktivitäten überwachen?

Es gibt seit Windows Server 2008 ein Performance Objekt „Netlogon“, mit dem Ihr die Auslastung und Antwortzeiten für NTLM Anmeldungen nachverfolgen kann. Für Windows Server 2003 könnt Ihr die nachrüsten:

928576          New performance counters for Windows Server 2003 let you monitor the performance of Netlogon authentication

In dem Artikel ist auch beschrieben, was die einzelnen Werte anzeigen. Da jeder Secure Channel eine eigene Instanz ist, könnt Ihr auf Domain Controllern die Aktivitäten bestimmter Domains recht genau nach verfolgen. Ihr seht zum Beispiel auch, wenn eine Trusted Domain mehrfach mit unterschiedlichen Domain Controllern auftaucht. Das kann ein Anzeichen sein, dass die Verbindung zum DC instabil ist.

Diese Performance Counter eignen sich auch für regelmäßige Performance-Überwachung und als Fehleranzeige:

Performance Counter

Empfehlung

Semaphore Waiters

Alle Semaphores sind in Beschlag, es gibt Anmeldungen, die warten müssen. Wenn der Zähler nicht 0 ist, sollte e seine Warnung geben.

Semaphore Holders

Hier wird die Anzahl der aktiven Anmeldungen gezählt. Man kann damit gut die Entwicklung der Last nachverfolgen im regelmäßigen Baselines. Wenn sich der Wert der „10“ oder “150” nähert, solltet Ihr aktiv werden.

Semaphore Acquires

Hier wird die Anzahl der Anmeldungen fortlaufend gezählt. Bei _Total bekommt Ihr die Gesamtaktivität. Auch dieser Counter ist interessant für das Baselining.

Semaphore Timeouts

Eine Anmeldung hat länger als 45 Sekunden in der Schlange gewartet und gibt auf. Die Benutzeranmeldung schlägt fehl. Das ist en echter Fehler und sollte einen Alarm auslösen.

Average Semaphore Hold Time

Hier sieht man die durchschnittliche Anmeldezeit. Besonders bei einzelnen Instanzen kann man auch in der vertrauenden Domäne ein Performance Problem finden, eventuell gibt es einen „Wartekonvoi“ oder es gibt tatsächlich ein Latenzproblem mit dem Netz oder Lastproblem auf einem Benutzer-Domänen Controller. Das ist auch ein guter Wert für das Baseline-Monitoring.

Innerhalb eines Forests gehen die Anfragen wie gesagt direkt an die Benutzer-Domäne. Über Forest Grenzen hinweg folgt die Anmeldung jedoch dem Trust Pfad über die Forest Root Domain. Hier kann es dazu kommen, dass über die Trustkette eine hohe Last über einen Domänen Controller pro Domäne kanalisiert wird und damit ein Engpass geschaffen wird.

Ihr werdet jetzt vielleicht denken, das ist jetzt ja nicht so furchtbar viel Neues für jemanden der einen dicken Web Proxy Server betreut.

Nun sind wir aber eine Quelle von NTLM-Anmeldungen aufmerksam geworden, die schon eine ganze Zeit im System ist, aber wohl erst jetzt von Kunden eingeschaltet wird.

Seit Windows XP Service Pack 2 und Windows Server 2003 Service Pack 1 gibt es die Möglichkeit bei Anfragen an den RPC Endpoint Mapper eine Authentifizierung zu verlangen. Damit sollen Denial of Service und andere Angriffe an den Dienst unterbunden oder zumindest erschwert werden:

https://www.microsoft.com/germany/technet/datenbank/articles/600337_1.mspx#EQEAE

Die Implementierung verwendet immer NTLM zur Anmeldung. Bei Applikationen, die sich per dynamischen Endpoint über RPC oft (wieder) verbinden, kann es zu entsprechenden Engpässen kommen. Auch wenn man denkt, dass auf Applikationsebene alles über Kerberos laufen sollte.

Wir haben das neulich mit einem Kunden beobachtet mit Exchange MAPI Clients im Firmennetz. Outlook wird sich mit Kerberos angemeldet, aber die Endpoint Mapper Anfragen vorab an Store, NSPI, Referrer und so weiter haben für viele NTLM-Anmeldungen gesorgt. Zum Engpass kam es aber durch eine langsame Benutzer-Domäne und einen Rückstau beim Anmeldekonvoi. Der Kunde hat „MaxConcurrentAPI“ erhöht und setzt nun Performance Baselines für Netlogon ein. Über „nltest /SC_RESET“ sorgt er dafür, dass die Resource-Domänen Controller, dass die Secure Channels in der vertrauten Domäne unterschiedliche Domänen Controller verwenden.

Ein anderer Kunde hatte eine Anwendung mit DCOM zur Client-Server Kommunikation. In der Original-Konfiguration hat die Anwendung NTLM verwendet. Das konnten wir auf Kerberos ändern, und auch in diesem Fall hatte der Kunde auch „EnableAuthEpResolution“ auf 1 gestellt und deswegen noch eine hohe Zahl von NTLM Anmeldungen gesehen.

Beide Kunden hatten gedacht, dem alten Zopf NTLM schon entkommen zu sein. Das war leider ein Fall von zu früh gefreut.

Herbert Mauerer

Comments

  • Anonymous
    January 01, 2003
    Hallo! Wir haben neulich heraus gefunden, dass Windows 7 und Windows Server 2008 R2 bei EnableAuthEpResolution=1 Kerberos verwenden. Es gibt also einen Weg sowohl sicheres als auch skalierbaren RPC Endpoint Mapper zu verwenden. Einen schönen Sommer noch! Herbert Mauerer