sebastian.f 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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 Zitieren
Das Urmel 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 Vorschlag - schau mal in den Sicherheitseinstellungen für Domains und Dom-Controller nach. Zitieren
sebastian.f 10 Geschrieben 11. August 2005 Autor Melden Geschrieben 11. August 2005 Hallo Urmel Ich verstehe jetzt nicht ganz, was soll ich in den Sicherheitseinstellungen ändern? Die Benutzerrechte stimmen ja wie sie sind mir geht es eher um das Authentifizierungsprotokoll. Falls du Prä Windows Authentifizierung meinst da ist nichts aktiviert. Gruß Sebastian Zitieren
Das Urmel 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 Letzter Versuch :mad: Du suchst die Sicherheitsrichtlinien für Domains und Domaincontroller Da wirst du wahrscheinlich die Lan-Manager Authentifizierungsebene umstellen wollen Zitieren
grizzly999 11 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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 Zitieren
sebastian.f 10 Geschrieben 11. August 2005 Autor Melden Geschrieben 11. August 2005 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 Zitieren
grizzly999 11 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 Da heißt es mal KB wälzen und suchen, dazu krbtray auf den Rechnern (auch IIS und SQL benutzen) und vielleicht zu sniffen. http://support.microsoft.com/default.aspx?scid=kb;en-us;319723 http://support.microsoft.com/kb/247931/ http://support.microsoft.com/default.aspx?scid=kb;en-us;839569 ... grizzly999 Zitieren
Das Urmel 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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 Zitieren
Velius 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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-Authentifizierungsebenea. 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 Zitieren
sebastian.f 10 Geschrieben 11. August 2005 Autor Melden Geschrieben 11. August 2005 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 Zitieren
Velius 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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 Zitieren
Velius 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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. Zitieren
Das Urmel 10 Geschrieben 11. August 2005 Melden Geschrieben 11. August 2005 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 Zitieren
Velius 10 Geschrieben 12. August 2005 Melden Geschrieben 12. August 2005 Meine Meinung, die man nicht zwangsweise teilen muss. ;) HtH Stimmt, also behalte sie für dich. ;) Abegesehen davon will ich mich ja nicht darüber beschweren, was du so hier alles (überflüssiges) postest. Zitieren
sebastian.f 10 Geschrieben 16. August 2005 Autor Melden Geschrieben 16. August 2005 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 Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.