none
Noch etwas zu beachten beim Anheben des Domänen- und Forest-Funktionslevels ?? RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen, 

    Über die letzten Monate haben wir in unserem Netzwerk sämtliche Windows 2003 DC's nacheinander gegen Windows 2008 R2 DC's ausgetauscht. Da wir ein recht heterogenes Netzwerk haben (inkl. Unix, Linux, Mac-Osx) hatte ich eigentlich schon mit ein paar Kommunikationsschwierigkeiten gerechnet. Tatsächlich gab es nur mit einer Anwendung Probleme bei der Kommunikation mit den 2008er DC's. Die Probleme sind inzwischen ausgeräumt und obwohl wir beim Audit-Logging auch diverse NTLM Zugriffe tracen gibt es keine weiteren Probleme bei der Kommunikation der Systeme mit dem AD. 

    Nun steht als letzter Schritt noch die Umstellung der Domänen- und Forest Funktionslevel an. Ich bin mir klar, dass wir dann im Nachhinein keine Windows2003 DC's mehr installieren können. Gibt es sonst noch irgendwas zu beachten? Ändert die Umstellung des Levels noch etwas an der Kommunikation zwischen den Clients zu den DC'S? eventuelle Änderungen in der Default Domain oder Domain Controller Policy was uns im Nachhinein noch in unserer heterogenen Umgebung in die Suppe spucken könnte?

    Oder können wir es einfach bedenkenlos tun, da in den ganzen Wochen kein Bedarf an 2003er DC's aufgekommen ist. 

    Grüße

    Antonio

    Freitag, 25. Januar 2013 18:55

Alle Antworten

  • Hi,

    du kannst lediglich keine neuen 2003er DC´s mehr hinzufügen, bestehende können bleiben. Oh Sorry, das hast ja geschrieben..
    Nö, dann gibt's nichts weiter zu beachten :) An den Policys ändert sich nichts mehr, bzw. ist kompatibel. Rauf mit den ebenen :)

    Grüße, Stephan


    Stephan Ertel - MCITP/MCSA -

    Samstag, 26. Januar 2013 08:21
  • Anderungen an den "Domänen- und Forest-Funktionslevels" betreffen immer nur die Kommunikation zwischen den Domain Controllern untereinander, nie die Kommunikation zwischen Client und Domain Controller.

    Lediglich ein paar alte 3rd-Party Verwaltungstools für Active Directory könnten ggf. in seltenen Fällen von einer Umstellung betroffen sein und sollten vorher mit dem jeweiligen Hersteller abgesprochen und bei Bedarf aktualisiert werden.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Samstag, 26. Januar 2013 09:51
  • Hi,

    Am 25.01.2013 19:55, schrieb Antonio_R:

    Oder können wir es einfach bedenkenlos tun, da in den ganzen Wochen
    kein Bedarf an 2003er DC's aufgekommen ist.

    Ich muss mal allen widersprechen, die sich gerade gemeldet haben.
    Ab 2008 R2 ist es das erste Mal, daß auch CLIENTS! von der Änderung des Domänen Levels betroffen sind.

    Der Sichere Kanal, den jeder Client mit dem DC aufbaut für die Vertrauensstellung und letztlich für die Verschachtelung der Domänengruppen in die LOKALEN Gruppe der Maschine kann nach der Anhebung nur noch per Kerberos aufgebaut werden.

    Was bedeutet das? Alle, die das nicht können fliegen aus der Domäne raus und stehen danach nur noch in einer Workgroup, SMB/Dateizugriff ist weiterhin möglich.

    Wen triffts?
    - NT4, u.U. Samba FileServer,

    Falls du also alte Clients hast, dann kannst du dich danach nur noch mit lokalen Accounts anmelden -> doppelte Pflege der BEnutzer + Anmeldescript im Autostart (I gitt ...)
    oder dein FileServer mit Samba läuft und nicht Kerberos nutzt, dann ist der kein Domänenmitglied mehr und kann die Berechtigugnen für die Domänengruppen nicht mehr nutzen. Paff!

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 26. Januar 2013 11:10
  • Hi Tobias,

    Am 26.01.2013 10:51, schrieb Tobias Redelberger:

    nie die Kommunikation zwischen Client und Domain Controller.

    falsch. Leider ... :-( ab 2008 R2 Secure Channel nur noch per Kerberos.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 26. Januar 2013 11:10
  • Hi,

    Am 26.01.2013 09:21, schrieb Stephan Ertel:

    Nö, dann gibt's nichts weiter zu beachten :)

    Sag das bitte nicht in einem Industriebetrieb, bei dem stehen imm er noch NT Kisten rum, und die fliegen ihm um die Ohren.
    Die kann er auch nicht tauschen, da hängen Maschinen und Zertifizierungen dran und gehören ihm oft garnicht, bzw. er darf sie nicht anfassen, weil dann jeglicher Support für die 2-stellige Mio Maschine ausfällt.

    Ich weiss nicht, ob du bis zu dem Betrag der beim Ausfall der Maschine entsteht versichert bist ;-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Samstag, 26. Januar 2013 11:10
  • Hi,

    na ja - ganz so "unbedenklich" ist das Anheben des Domain Functional Levels dann auch wieder nicht. So wird zum Beispiel das krbtgt-Account Kennwort beim Anheben des DFLvon Windows Server 2003 auf Windows Server 2008 erneuert, um AES für die TGT-Verschlüsselung nutzen zu können als auch für GSS-SPNEGO. So, wie ich das erlebt habe, schmeckt diese Änderung ab und an einigen Linux/Unix Kerberos Implementierungen nicht, wenn diese an die AD angebunden sind.

    Siehe dazu auch: 

    - http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx
    - http://technet.microsoft.com/en-us/library/cc749438(WS.10).aspx

    Ergo: Da Du wie oben angesprochen einige Linux/Unix Geräte in der Umgebung hast, die vermutlich per Kerberos an die Domäne angebunden sind (keytab etwa), schaue Dir diese Systeme vor dem Anheben des DFL einmal genauer an.

    Ansonsten beschreibt der zweite Artikel oben noch den Effekt der AES-Verschlüsselung auf die CPU-Last der DCs. Sollte nur in größeren Umgebungen relevant sein - wir kennen hier die Größenordnung Deiner Umgebung nicht. :-)

    Viele Grüße
    Fabian

    Samstag, 26. Januar 2013 23:58
    Beantworter
  • > Ab 2008 R2 ist es das erste Mal, daß auch CLIENTS! von der Änderung des Domänen Levels betroffen sind

    [..]

    > ab 2008 R2 Secure Channel nur noch per Kerberos

    @Mark: Kannst Du uns bitte die offizielle Quelle dafür posten?

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Montag, 28. Januar 2013 09:59
  •  
    > @Mark: Kannst Du uns bitte die offizielle Quelle dafür posten?
     
    Hier findest einige weiterführende Links:
     
    Hab mir die aber nicht alle angeschaut ;-)
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Montag, 28. Januar 2013 11:34
  • Hi zusammen,

    vorab: Kann es sein, daß hier aktuell Posts nur mit starker Verzögerung angezeigt werden? Die ganzen letzten 5 Beiträge habe ich jetzt erst auf dem Schirm, obwohl sie viel früher gepostet wurden...

    Zum Thema:

    Hier geht gerade einiges durcheinander. Was sich verändert hat seit Windows Server 2008 R2 in Bezug auf den Secure Channel, ist die "strong-key protection": http://blogs.technet.com/b/deds/archive/2010/04/07/was-ende-des-lebenszyklus-bedeuten-kann.aspx
    Hierbei geht es um die Schlüssellänge, nicht um die Verschlüsselungsart.

    Verändert hat sich das auch nicht mit dem DFL/FFL, sondern mit Einführung eines Windows Server 2008 R2 DCs, denn der Secure Channel ist hier hard-coded mit dieser Verschlüsselungsstärke geschützt. Die GPO dafür greift für die Systeme nicht mehr.

    Die Änderungen in Bezug auf Kerberos habe ich oben beschrieben.

    Viele Grüße
    Fabian

    Montag, 28. Januar 2013 11:36
    Beantworter
  • Hallo

    Vielen Dank für die vielen Antworten.

    Wie ich den letzten Post vom Fabian verstanden habe, sollte ja die Änderung der Schlüssellänge keine negativen Auswirkungen auf die Client-Kommunikation haben, solange die Verschlüsselungsart gleich bleibt.

    Die Antworten haben mir jetzt soweit geholfen, dass ich schonmal nicht leichtfertig das Function-Level anheben werde. :-)

    Wir haben ein relativ großes Netzwerk, welches über die Jahre auch im Bereich der angebundenen Systeme gewachsen ist. Sich die Systeme anschauen, wie es der Fabian vorgeschlagen hat, wird da etwas schwierig, da die einzelnen Systeme über viele Bereiche verteilt sind und das eine relativ undankbare Aufgabe wird. Eher würde mir der Ansatz gefallen, wenn man auf den DC's die Kommunikation so überwachen könnte um die eventuell gefährdeten Systeme zu ermitteln und anchließend gezielt anzusprechen.

    Eigentlich hatte ich gehofft, dass das Anheben relativ problemlos vonstatten gehen könnte, da es ja keinen Weg mehr zurück gibt und Microsoft einen dadurch quasi ja vor vollendete Tatsachen stellt, wenn es wirklich kracht.

    Zumindest eine nachträgliche Aufweichung der Kommunikation über Policies wäre hier sinnvoll. So ist es ja wirklich ein Risiko, die Funktion-Level zu ändern, wenn man ältere Systeme im Netz hat, die auch nicht so leicht zu erfassen sind.

    Ich habe mir jetzt mal die genannten Artikel durchgelesen, aber einen direkten Hinweis auf die Änderung der Kommunikation habe ich nicht gefunden. Das ist mehr eine allgmeine Beschreibung der verschiedenen Funktion-Level. So richtig schlüssig bin ich mir aktuell also noch nicht.

    Viele Grüße

    Antonio

    Montag, 28. Januar 2013 11:55
  • Hi,

    Am 28.01.2013 10:59, schrieb Tobias Redelberger:

    @Mark: Kannst Du uns bitte die offizielle Quelle dafür posten?

    Ich kann dir einen Screenshot meiner NT4 Workstation schicken, bei dem es jetzt nicht mehr geht und die GPOs sind alle so konfiguriert, daß sich selbst ein DOS 6.22 an den DC per SMB verbindet.

    Das Domänenkonto steht im lusrmgr für Benutzer/Administratoren als "DOMAIN\Konto unbekannt"

    http://technet.microsoft.com/en-us/library/cc767899.aspx
    | Before a user logs on at an NT Workstation, the Workstation will
    | attempt to validate its Machine Account and create (Discover) a
    | secure channel to a Resource Domain server.

    Ich bin ja keiner der IP vorwärts und rückwärts spricht, aber ich finde es aus meiner Sicht erklärbar, wenn sowohl im Request als auch in der die Response im NegotiateFlag, u.A. das drin steht:

    O:  (.................0..............) NOT supports strong keys.
    P:  (................0...............) NOT supports transitive trusts.

    Zwischen Workstation und Domäne besteht IMHO dieselbe Technik für den Trust wie zwischen Domänen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Montag, 28. Januar 2013 16:56
  • Am 28.01.2013 schrieb Antonio_R:
    Hi,

    Eigentlich hatte ich gehofft, dass das Anheben relativ problemlos vonstatten gehen könnte, da es ja keinen Weg mehr zurück gibt und Microsoft einen dadurch quasi ja vor vollendete Tatsachen stellt, wenn es wirklich kracht.

    Warum gibts keinen Weg zurück? Gerade bei solchen Szenarien sollte man ein
    vernünftiges Restore in der Hinterhand haben. Und ja, sowas muß vorab
    geplant und hinterher überwacht werden.

    Zumindest eine nachträgliche Aufweichung der Kommunikation über Policies wäre hier sinnvoll. So ist es ja wirklich ein Risiko, die Funktion-Level zu ändern, wenn man ältere Systeme im Netz hat, die auch nicht so leicht zu erfassen sind.

    Deswegen schaut man sich vorab erstmal seine "älteren" Systeme an und
    entscheidet dann.

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you
    with experience.

    Dienstag, 29. Januar 2013 21:45
  • Ich kann dir einen Screenshot meiner NT4 Workstation schicken, bei dem es jetzt nicht mehr geht und die GPOs sind alle so konfiguriert, daß sich selbst ein DOS 6.22 an den DC per SMB verbindet.

    Das Domänenkonto steht im lusrmgr für Benutzer/Administratoren als "DOMAIN\Konto unbekannt"

    http://technet.microsoft.com/en-us/library/cc767899.aspx
    | Before a user logs on at an NT Workstation, the Workstation will
    | attempt to validate its Machine Account and create (Discover) a
    | secure channel to a Resource Domain server.

    Ich bin ja keiner der IP vorwärts und rückwärts spricht, aber ich finde es aus meiner Sicht erklärbar, wenn sowohl im Request als auch in der die Response im NegotiateFlag, u.A. das drin steht:

    O:  (.................0..............) NOT supports strong keys.
    P:  (................0...............) NOT supports transitive trusts.

    Zwischen Workstation und Domäne besteht IMHO dieselbe Technik für den Trust wie zwischen Domänen.

    Tschö
    Mark


    Siehe meine Antwort oben - das hat nichts mit der Kerberos Verschlüsselung zu tun. Und ist unabhängig vom DFL / FFL.

    Viele Grüße
    Fabian

    Mittwoch, 30. Januar 2013 11:13
    Beantworter
  • Hi,

    Am 30.01.2013 12:13, schrieb Fabian Müller [MSFT]:

    Siehe meine Antwort oben - das hat nichts mit der Kerberos
    Verschlüsselung zu tun.

    ok, wenn aber nun der Strong Key von 2008 R2 gefordert wird was ja hardcoded ist, das steht im Artikel und du hast es auch gesagt, und NT4 diesen nicht unterstützt, dann kann ich mich nicht als Domänen Benutzer an einer NT4 Kiste anmelden.
    Egal ob Kerberos oder StrongKey/Schlüssellängen Problem.

    Und ist unabhängig vom DFL / FFL.

    das habe ich auch in diesem letzten Posting nicht behauptet. Wenn es der Server ist und nicht der Function Level kann ich damit prima leben.

    Trotzdem gibt es keine offizielle Ausssage von MS, daß NT4 als Workstation rausfliegt. Ich kann aber aus Praxiserfahrung und auch nach dem NetMon Capture nichts anderes feststellen.

    Wenn Kerberos nichts mit dem StrongKey zu tun hat, dann Asche auf mein Haupt, ändert aber für mich nichts an der Tatsache, daß NT4 keinen StrongKey kann und damit die DomänenMitgliedschaft am Ar*** ist.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Mittwoch, 30. Januar 2013 12:30
  • Moin, moin,

    ich nehme Bezug auf Deine letzte Rückmeldung:

    Mark Heitbrink [MVP]:
    >> ok, wenn aber nun der Strong Key von 2008 R2 gefordert wird was ja hardcoded ist, das steht im Artikel und du hast es
    >> auch gesagt, und NT4 diesen nicht unterstützt, dann kann ich mich nicht als Domänen Benutzer an einer NT4 Kiste anmelden.
    >> Egal ob Kerberos oder StrongKey/Schlüssellängen Problem.

    Ich lege deshalb so großen Wert auf die Unterscheidung, da es für den TO irrelevant ist. Denn er hat *aktuell* schon ausschließlich Windows Server 2008 R2 DCs in seiner Umgebung. D.h. die Fragestellung, ob die hart-codierte "strong-key protection" Windows NT Maschinen oder ältere Samba Versionen abschneidet, ist nicht mehr von Bedeutung. *Wenn* das Problem beim TO aufgetreten wäre, dann in der Vergangenheit. Nämlich spätestens zu dem Zeitpunkt, als der letzte Windows Server 2003 DC abgeschaltet wurde.

    Da es keine Probleme gab, ist Deine Angabe zwar eine sinnvolle Zusatzinformation, hat aber nichts mit dem Szenario des TO zu tun.

    Mark Heitbrink [MVP]:
    >> das habe ich auch in diesem letzten Posting nicht behauptet. Wenn es der Server ist und nicht der Function Level kann ich damit prima leben.

    Ohne Haare spalten zu wollen ;-) - doch, das hast Du:

    Samstag, 26. Januar 2013 11:10
    Mark Heitbrink [MVP]

    >> Ich muss mal allen widersprechen, die sich gerade gemeldet haben.
    >> Ab 2008 R2 ist es das erste Mal, daß auch CLIENTS! von der Änderung des Domänen Levels betroffen sind.

    >> Der Sichere Kanal, den jeder Client mit dem DC aufbaut für die Vertrauensstellung und letztlich für die Verschachtelung der Domänengruppen in die LOKALEN Gruppe der Maschine kann nach der Anhebung nur noch per Kerberos aufgebaut werden.

    Nur darum nehme ich ja Bezug auf diese Fragestellung.

    Mark Heitbrink [MVP]
    >> Trotzdem gibt es keine offizielle Ausssage von MS, daß NT4 als Workstation rausfliegt. Ich kann aber aus Praxiserfahrung und auch nach dem NetMon Capture nichts anderes feststellen.

    Das ist korrekt und diesen Punkt habe ich auch nicht infrage gestellt. Sondern den Kontext.

    P.S.: Auf die Diskussion, ob man Windows NT Maschinen o.ä. alte Betriebssysteme in seiner Produktionsumgebung betreiben sollte, gehe ich hier einmal nicht weiter ein. Nur soviel: Wer die Systeme nicht kapselt / isoliert, handelt aus Sicherheitssicht in selbstmörderischer Absicht. Es gibt meiner Erfahrung nach genügend Varianten, die Windows NT Maschinen auch ohne Zugriff auf die Domänen-Ressourcen bei Bedarf isoliert zu betreiben.

    Viele Grüße
    Fabian

    Donnerstag, 31. Januar 2013 08:18
    Beantworter
  • Moin,

    Am 31.01.2013 09:18, schrieb Fabian Müller [MSFT]:

    Ohne Haare spalten zu wollen ;-) - doch, das hast Du:

    Erbsen zählen? Kein Problem ...
    Nein, habe ich nicht. das war in dem davor, deswegen habe ich tatsächlich "im letzten" geschrieben. :-)

    Trotzdem gibt es keine offizielle Ausssage von MS, daß NT4 als
    Workstation rausfliegt. Ich kann aber aus Praxiserfahrung und auch
    nach dem NetMon Capture nichts anderes feststellen.

    Das ist korrekt und diesen Punkt habe ich auch nicht infrage
    gestellt. Sondern den Kontext.

    Die Korrektur nehme ich gerne an. Das ist wieder das Ding mit Ursache
    und Wirkung man integriert neue Server und hebt den Level an, danach
    geht es nicht mehr ...

    Aber davon mal ab: Warum steht in keinem der Blogs/TechnetArtikel etc.
    daß NT4 Workstations betroffen sind? Warum wird immer nur von vertrauten
    Domänen gesprochen?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 31. Januar 2013 08:53
  • Hi Mark,

    na ja - spitz formuliert werden vermutlich aus demselben Grund keine Aussagen zu Windows NT mehr gemacht, warum auch keine Passagen zu Windows 3.11, Windows 95 oder Windows 98SE zu finden sind.

    Das Betriebssystem ist (wenn ich mich recht entsinne) seit ca. 8 Jahren aus dem Support. Es finden keinerlei Funktionstests neuer Produkte gegen diese Betriebssysteme mehr statt. Daher gibt es schlichtweg keinerlei belastbarer Aussagen zu dem Thema - es sei denn, zum Zeitpunkt des Support LifeCycle waren bestimmte Punkte schon klar.

    Viele Grüße
    Fabian

    Freitag, 1. Februar 2013 06:41
    Beantworter
  • Hi,

    Am 01.02.2013 07:41, schrieb Fabian Müller [MSFT]:

    na ja - spitz formuliert werden vermutlich aus demselben Grund keine
    Aussagen zu Windows NT mehr gemacht, warum auch keine Passagen zu
    Windows 3.11, Windows 95 oder Windows 98SE zu finden sind.

    Stimmt auch wieder. Ich hätte halt nur gedacht, daß wenn schon NT4 Trusts angesprochen werden, die ja das gleiche Support Schicksal haben, auch die Workstation mitgenannt werden könnte.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Freitag, 1. Februar 2013 08:30
  • Hallo,

    ich habe diese Diskussion gelesen, weil wir auch unsere alten 2003er DC ablösen wollen und auch noch WinNT4.0 im Einsatz haben (Laserschneidmaschine).

    In meiner Testumgebung (ein 2003 DC + ein 2008 R2 DC + ein WinNT4.0 SP6) war nach dem demoten des 2003er DC der Zugriff von NT4.0 nicht mehr möglich. DFL war immer noch Windows Server 2003.

    Ich habe dann entsprechend den Hinweisen in dem Dokument "Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains" ( http://www.microsoft.com/en-us/download/details.aspx?id=6170 ) per GPO

    Microsoft network server: Digitally sign communications (always) : deaktiviert

    Domain member: Digitally encrypt or sign secure channel data (always) : deaktiviert

    Allow cryptography algorithms compatible with Windows NT 4.0 : aktiviert

    Nach Gpupdate auf dem Server und Neustart der NT4.0 Workstation konnte ich mich wieder anmelden.

    Auch nach dem Heraufstufen der DFL auf Windows Server 2008 R2 kann man sich noch anmelden.

    Nach dem oben geschriebenen und meinem eigenen Test bin ich jetzt etwas verwirrt.

    Mann kann also doch noch WinNt4.0 als Domänenmitglied in einer 2008 R2 Domäne betreiben?

    Viele Grüße

    Matthias

    Freitag, 29. November 2013 10:21
  • Hi,

    Am 29.11.2013 11:21, schrieb MatthiasF60:

    In meiner Testumgebung (ein 2003 DC + ein 2008 R2 DC + ein WinNT4.0
    SP6) war nach dem demoten des 2003er DC der Zugriff von NT4.0 nicht
    mehr möglich. DFL war immer noch Windows Server 2003.

    Das ist richtig so. Es ist nicht der DFL oder FFL, sondern der 2008R2, der keinen Sicheren Kanal mehr ohne Kerberos bereitstellt.

    Mann kann also doch noch WinNt4.0 als Domänenmitglied in einer 2008
    R2 Domäne betreiben?

    Jetzt bin ich selbst überrascht. Muss ich mal testen. Danke!

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Freitag, 29. November 2013 11:24
  • Hi zusammen,

    zwei Gedanken dazu:

    1) in dem Blog (http://blogs.technet.com/b/deds/archive/2010/04/07/was-ende-des-lebenszyklus-bedeuten-kann.aspx ) ist die Rede von Trusts (DC zu DC Kommunikation), nicht von Clients. Gleichzeitig wurden jedoch seitens Microsoft keinerlei Funktionstests von Windows NT 4.0 gegen Windows Server 2008 R2 durchgeführt. Das bedeutet, daß selbst wenn ein Domain Join o.ä. noch möglich ist, nicht unbedingt alle weiteren Aktionen innerhalb einer Domäne funktionieren.

    2) Wer die Standard-Sicherheit des OS in dieser Art und Weise heruntersetzt, hat ein weit erhöhtes Risiko für Angriffe, die auf schwache Verschlüsselung usw. zielen. Es sei also an dieser Stelle explizit davon abgeraten.

    Viele Grüße

    Fabian

    Freitag, 29. November 2013 14:44
    Beantworter
  • Am 29.11.2013 12:24, schrieb Mark Heitbrink [MVP]:

    Jetzt bin ich selbst überrascht. Muss ich mal testen. Danke!

    Geht.

    Ich dreh mich noch mal um 180° habe, dann den Kreis vollendet und behaupte jetzt, daß man sich zumindest immer noch anmelden kann.
    Ich habe verschiedenste Richtlinien probiert, aber konnte mich nach dem JoinDomain nie anmelden.

    Ich habs jetzt noch mal durchgespielt:
    Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen
    Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) = deaktiviert

    Die reicht. Anmeldung geht, net use kein Problem :-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Freitag, 29. November 2013 16:26