Jump to content

2k - und NTLM


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

Ich habe ein ziemliches Problem mit Windows 2000 und Authentication.

Ich habe eine gemischte W2k und W2k3 Server Umgebung, die DCLs wurden gerade von 2000 auf 2003 upgedated.

Es sind auschließlich 2000er Clients mit allen aktuellen Patches im Einsatz.

 

Das Problem ist das sich Server untereinander und auch Clients am Sever immer noch mit NTLM authentifizieren obwohl das doch unter 2000 schon lange durch kerberos ersetzt worden sein sollte.

Ich kann nur kerberos benutzen da wir einiges Systeme haben die Impersonation und Delegation benutzen, und das wird ja nur von kerberos unterstützt.

 

Meine Frage lautet daher wie schalte ich NTLM Domänenweit ab ?

 

Vielen Danke für die Hife

 

Sebastian

Link zu diesem Kommentar

Clients mit 2000 und höher sollten selbständig das Kerberos Protokoll innerhalb des AD verwenden, Voraussetzung ist eine perfekt funktionierende Namensauflösung mittels DNS im Netzwerk. Einzige Ausnahme automatisc wo NTLM verwendet wird: Wenn über IP-Adressen und nicht über DNS-Namen connectet wird, denn Kerberos arbeitet mit Namen, nicht mit IP-Adressen.

 

@Urmel: es gibt auch in den Sicherheitsoptionen keine Möglichkeit, den Client auf Kerberos zu "zwingen", wie gesagt, das macht er normalerweise selber.

 

Frage: Woher weisst, du dass die Rechner NTLM machen, statt Kerberos? Hast du schon krbtray.exe aus den Support Tools benutzt?

 

Für Probleme mit Kerberos kann man ausserdem das detailiertere Logging aktivieren: http://support.microsoft.com/default.aspx?scid=kb;en-us;262177

 

Ausserdem solltest du auch so bei Problemen Einträge in den Logs finden, ohne den Key oben

 

 

grizzly999

Link zu diesem Kommentar

Hallo,

 

Danke für die aufschlussreiche Antwort grizzly. Die DNS Auflösung funktioniert hunderprozentig. Ich werde mal noch etwas ins Detail gehen vielleicht fällt einem noch was auf.

 

Wir haben eine Webapplikation programmiert die auf einem Webserver läuft und per

dotnet Klasse auf den Exchange Server zugreift und Kalender Informationen abholt. Diese werden in einer neuen Maske dargestellt und können vom User bearbeitet werden und wieder

auf den Exchangeserver zurückgeschrieben werden. Gleichzeitig werden gewisse Daten aus der selben Maske in eine SQL Datenbank geschrieben die auf einem anderen Server läuft auf dem auschließlich die Windows Authentifizierung aktiviert ist.

Die User authentifizieren sich am SQL Server per Impersonation und Delegation über den Webserver was nur von Kerberos unterstützt wird, und von NTLM nicht!

Soviel zur grundsätzlichen Umgebung.

 

Manchmal bekommt der User im Broswser folgende Fehlermeldung, der Fehler ist aber nicht reproduzierbar und tritt zufällig auf:

 

"System.Data.SqlClient.SqlException: Fehler bei der Anmeldung für den Benutzer '(null)'. Ursache: Keiner vertrauten SQL Server-Verbindung zugeordnet."

 

Ich konnte festellen das dies irgendwie mit der Authentifizierung und dem Impersonation/Delegation Prozess zusammenhängt.

Wenn der User die Kalendermaske aufruft, authentifiziert er sich normal am Webserver per Kerberos wie es sein soll, dies funktioniert in 70% der Fälle.

Aufeinmal sehe ich dann im Security Log vom Webserver wie ein NTLM anmeldeversuch vom selben User kommt weil er was im SQL Server speichern will, und paff kommt die obige Fehlermeldung weil NTLM natürlich nicht an den SQL Server delegiert werden kann.

Das ganze passiert aber nur wenn der User vorher die Exchange Webapplikation genutzt hat, andere Applikationen auf dem Webserver die auch in die SQL DB schreiben funktionieren einwandfrei, es funktioniert auch das schreiben von der Exchange Applikation aus nur wie gesagt in 30% der fälle klappt es nicht und ich weiss nicht warum, das größte Problem ist das ich den Fehler nicht reproduzieren kann.

Ich habe die Vermutung das das irgendwie mit der Anmeldung an Exchange zusammenhängt wenn der User sich die Kalenderinfos holt.

 

Und jetzt wollte ich eben alle Systeme dazu zwingen Kerberos zu benutzen dammit der Fehler weg geht und Imersonation/Delegation funktioniert.

 

Die Infos das NTLM zur Authentifizierung benutzt wird habe aus dem Securitylog.

 

Im übrigen wird mir auch vom SQL Server bestätigt das jemand sich auf anonymen Weg versucht hat anzumelden da ich folgende Fehlermeldung vom SQL Server bekomme wenn ein User die obige Fehlermeldung hat:

 

Eine anonyme Sitzung mit hergestellter Verbindung von SQLServer hat versucht, einen LSA-Richtlinienhandle auf diesem Computer zu öffnen. Der Versuch wurde mit STATUS_ACCESS_DENIED zurückgewiesen, um die Verbreitung von sicherheitssensitiven Informationen nan einen anonymen Anrufer zu verhindern.

Der Anwendungsfehler, der diesen Versuch verursacht hat, sollte behoben werden. Wenden Sie sich an den Hersteller der Anwendung. Als temporären Workaround kann diese Sicherheitserkennung durch Setzen des DWORD Werts HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TurnOffAnonymousBlock auf 1 aufgehoben werden.

Diese Meldung wird höchstens einmal pro Tag protokolliert.

 

Und ein anonymer Versuch kommt nur dann zustande wenn der User aufgrund von NTLM AUthentifizierung nicht delegiert werden konnte.

 

So ich hoffe ich konnte euch irgendwie begreiflich machen wo das Problem herrürt. Ich bin mir inzwischen sicher das das Problem von der Authentifizierung herürt. Und die Standard Lösungsvorschläge zu dem Nullfehler bin ich schon durchgegangen.

 

Ich hoffe jemand weis noch eine Antwort ich bin jedenfalls mit meinem Latein am Ende.

 

Gruß

Sebastian

Link zu diesem Kommentar

grizzly meinte

es gibt auch in den Sicherheitsoptionen keine Möglichkeit, den Client auf Kerberos zu "zwingen", wie gesagt, das macht er normalerweise selber.

 

Da hast du natürlich Recht.

Hab mich wohl einfach von der Frage leiten lassen, wo NTLM abgedreht - respektive v2 erzwungen wird, und das wäre da.

Wie ich nun sehe, ganz andere Baustelle - aber bei der Fragestellung :confused:

Link zu diesem Kommentar

Irgendwas ist krum bei dir, denn so wie Grizzly sagte, verwenden W2K Pro und XP, sofern sie nicht mit NT 4.0 Servern/Workstations kommunizieren, immer Kerberos. NTLM wurde zur Abwärtskompatibilität nach beibehalten.

 

Aber zieh' dir mal folgende Group Policy Einstellung rein:

 

Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit Clients, Diensten und Programmen auftreten

10. Netzwerksicherheit: LAN Manager-Authentifizierungsebene

a. Hintergrund

 

Bei der LAN Manager (LM)-Authentifizierung handelt es sich um das Protokoll, anhand dessen Windows-Clients bei Netzwerkvorgängen, darunter Domänenbeitritte, der Zugriff auf Netzwerkressourcen sowie die Benutzer- oder Computerauthentifizierung, authentifiziert werden. Die LM-Authentifizierungsebene bestimmt, welches Challenge/Response-Authentifizierungsprotokoll zwischen den Client- und Server-Computern ausgehandelt wird. Über die LM-Authentifizierungsebene wird außerdem bestimmt, welche Authentifizierungsprotokolle der Client für die Verhandlung verwendet, bzw. welche dieser Protokolle der Server akzeptiert. Mögliche Einstellungen sind:

• LM- und NTLM-Antworten senden: Clients verwenden die LM- und NTLM-Authentifizierung und nie die NTLMv2-Sitzungssicherheit; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt): Clients verwenden LM- und NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLM-Antworten senden: Clients verwenden nur NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLMv2-Antworten senden: Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLMv2-Antworten senden/LM verweigern: Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller verweigern LM (sie akzeptieren nur NTLM- und NTLMv2-Authentifizierung).

• Nur NTLMv2-Antworten senden/LM NTLM verweigern: Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller verweigern LM und NTLM (sie akzeptieren nur NTLMv2-Authentifizierung).

Eine bewährte Vorgehensweise ist, auf NTLMv2-fähige Clients und Domänencontroller aufzurüsten und anschließend die NTLMv2-Authentifizierung zu aktivieren. Weitere Informationen zu LM-Authentifizierungsebenen finden Sie in folgendem Artikel der Microsoft Knowledge Base:

 

 

 

 

Zu finden ist die Einstellung unter Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen\Netzwerksicherheit\LAN Manager-Authentifizierungsebene

 

 

Eventuell kannst du was bewirken, wenn du nur noch NTLMv2 erzwingst...ich würde das aber erstmals ausgiebig astesten.

 

 

Vielleicht könnte dir aber auch folgender Artikel weiterhelfen:

How to configure IIS to support both Kerberos and NTLM authentication

 

 

Gruss

Velius

Link zu diesem Kommentar

Hallo,

 

Danke schonmal für die Antworten, einige KB Artikel kenne ich schon ein paar sind mir auch neu werde mich da mal einlesen. Ich habe am Anfang die Frage etwas anders gestellt weil ich dachte man kann einer 2k domäne mit nem einfachen Trick beibringen das sie nur Kerberos benutzen soll, was ja das eigentlich Ziel ist. Denn wie schon erwähnt würde ich am liebsten NTLM komplett abschalten da es nicht kompatibel mit Delegation und Impersonation ist.

 

Was mich noch interessieren würde ob jemand eine Idee hat warum ein 2k Client/Server in einer reinen 2k/2k3 domäne ntlm zur authentifizierung benutzt.

 

Danke

 

Sebastian

Link zu diesem Kommentar

 

Was mich noch interessieren würde ob jemand eine Idee hat warum ein 2k Client/Server in einer reinen 2k/2k3 domäne ntlm zur authentifizierung benutzt.

 

Danke

 

Sebastian

 

 

Das tun sie (sollten sie) auch nicht:

 

NTLM authentication

 

In Windows 2000, NTLM is used as the authentication protocol for transactions between two computers in a domain, where one or both computers is running Windows NT 4.0 or earlier.

 

Windows 2000 is installed in a mixed-mode network configuration by default. A mixed-mode network configuration uses any combination of Windows NT 4.0 and Windows 2000. If you do not have a mixed-mode network, you can disable NTLM authentication by switching to native mode at a domain controller.

 

As examples, the following configurations would use NTLM as the authentication mechanism:

 

* A Windows 2000 Professional client authenticating to a Windows NT 4.0 domain controller.

* A Windows NT 4.0 Workstation client authenticating to a Windows 2000 domain controller.

* A Windows NT 4.0 Workstation client authenticating to a Windows NT 4.0 domain controller.

* Users in a Windows NT 4.0 domain authenticating to a Windows 2000 domain.

 

In addition, NTLM is the authentication protocol for computers that are not participating in a domain, such as stand-alone servers and workgroups.

 

For more information about NTLM authentication, see the Windows 2000 Server Resource Kit documentation.

 

http://www.microsoft.com/windows2000/en/advanced/help/default.asp?url=/windows2000/en/advanced/help/sag_SEconceptsUnAuthNTLM.htm

 

 

Ausserdem habe ich das bei uns gecheckt, und in gewissen Richtungen ist bei uns nur Kerberos V5 öffen, NTLM aber definitv nicht, und trotzdem klappt alles.

 

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/779885d9-e5e9-4f27-9c14-5bbe77b056ba.mspx

Link zu diesem Kommentar

Könnte sein, dass das Problem beim Handling mit dem Kerberos Protokoll selbst liegt. :suspect:

 

Suchergenbisse in der MS KB mit delegation/imerpersonation & Kerberos:

 

Troubleshooting Kerberos Errors

Delegation & Impersonation: Impersonation Levels

 

 

Gruss

Velius

 

P.S.: Vielleicht noch aufschlussreicher:

Troubleshooting Kerberos Delegation

 

The appendices detail diagnostic tools and give examples of how to resolve problems in typical IIS to SQL delegation scenarios.
Link zu diesem Kommentar

Ne Menge Links und Zitate, die man sich hätte sparen können - lesen sollte wohl jeder können ;)

Schick wäre es, ala grizzly-style das knapp zusammenzufassen -das hat Style in meinen Augen so wie in den entsprechenden NG*'s üblich.

Ich wünsche mir zusammenfasssungen. kurz und bündig.

Alles andere ist überflüßig und langatmig, zeilenweise zu zitieren.

Wen einem Member das abverlangt wird, sollte ein Expert das schon längst beherrschen, es gibt welche die das können.

Meine Meinung, die man nicht zwangsweise teilen muss. ;)

HtH

Link zu diesem Kommentar

Hallo,

 

Danke für die vielen Antworten. Leider ist das Problem bis jetzt immer noch nicht gelöst.

Inzwischen konnte ich festellen das das Problem nicht nur mit Exchange auftritt sondern allgemein die Delegierung manchmal fehlschlägt. Wie gesagt in 60 Prozent der Fälle klappts ansonsten nicht.

Leider ist im Client Security Tab der Erreignissanzeige nicht ersichtlich warum der Client plötzlich mit NTLM an den Server geht. Man kann nur am Server sehen wenn ein Client mit NTLM ankommt aber leider nicht warum. kerbtray hilft mir da auch nicht weiter weil die Tickets ja passen sonst würde die delegierung ja gar nicht klappen.

 

Gibt es vielleicht irgendein Tool das die Authentifizierung noch genauer protokolliert.

Die Events der lokalen Sicherheitsrichtlinie habe ich schon aufs Maximum aufgebohrt.

 

Danke

Sebastian

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...