none
Verständnisfragen DFL Windows 2012 R2 & NTLM, Verschlüsselung... RRS feed

  • Frage

  • Hallo!

    Ich habe mal ein paar Verständnisfragen. Wir möchten gerne von Domain & Forest Functional Level  von 2003 auf 2012 R2 gehen. Die DCs sind 2008 R2 Server.

    Mit 2012 R2 wird NTLM "abgeschaltet". Dieses gilt doch nur für NTLMv1, oder? Wie verhält es sich bei Applikationen, die eine AD-basierte Authentifizierung (z.B. Benutzeranmeldung) haben? Die müssen doch nicht zwingend Kerberos machen, oder?

    Die Abfrage von Software ob ein Benutzer z.B. bestimmte Mitgliedschaften in Gruppen hat ist doch rein LDAP, oder? Das bedeutet es hat mit dem Functional Level nichts weiter zu tun, da die höhe des Functional Levels keinen Einfluss auf die LDAP Abfrage hat, oder?

    Was hat es mit den Verschlüsselungen zu tun? DES, 3DES, NTCrypto, Sha512...? Was geht, was geht nicht? Worauf muss man dabei achten?  

    Danke

    Micha

    Dienstag, 8. November 2016 12:56

Antworten

  • Hi,
     
    Am 08.11.2016 um 14:54 schrieb dahawei:
    > Ich habe von ca. 1 Jahr von 2003R2 direkt auf 2012R2 gewechselt.
    > Folgende Policies (nicht abschliessend) solltest Du genau beachten:
     
    Wenn die Richtlinien schon editiert sind, werden sie durch die Migration
    nicht verändert. Wird ein 2012R2 AD /neu/ aufgebaut, dann sind alte
    Clients erst mal ausgeschlossen (siehe Abschluss Hinweis in der Promotion)
     
    Wenn die Richtlinien auf "nicht konfiguriert" stehen, ist das Default
    Verhalten eines 2012R2 Server so, daß sie für alte Clients angepasst
    qwerden müssen.
     
    > Ein kleiner Tipp: Verwende nie die "Domain Controller Policy"
     
    Dem widerspreche ich.
    Sie ist genau dafür da. Eigene baut man nur für den Fall der Ausnahmen,
    aber nicht grundsätzlich.
    Die Default Richtlinien (egal ob DDP oder DDCP) sind hardcodiert in den
    Systemen verankert und werden von einigen Prozesssen direkt angesprochen.
    Nutzt man eigene Richtlinien muss man immer händisch nacharbeiten, da
    die Routinen zwar in die DDCP/DDP schreiben, aber sie nicht aktiv sind
    und somit in der eigenen "aktiven" fehlen.
     
    > Ein weitere Grund ist, bei einem Disaster Fall (Forest Restore) kann
    > es sein, dass die Default Settings der Domain Contoller Policy
    > restored werden und Du danach diverse Probleme bekommst.
     
    Ein Desaster Recovery Scenario, daß nicht den Zustand wiederherstellt,
    den ich erwarte/möchte ist ein Desaster, aber kein Desaster Recovery.
    Da ist dann ein Fehler im Backup. Oder kein Mensch hat jemals die
    Richtlinien und deren Verlinkungen einzelnt gesichert.
     
    Davon abgesehen, habe ich seit 10 Jahren kein "Desaster Recovery" mehr
    in Prod erlebt. Zum Glück. Seit Virtualisierungzeiten und damit
    pauschalisierter Hardware kommt das nur noch vor, wenn die Hütte
    abgebrannt ist.
     
    > Wichtig: Die Domain Controller Policy sollte sich an Deiner Umgebung
    > orientieren und nicht was Microsoft als "Default" sieht...
     
    Logisch. Deswegen editiert man die DDP und DDCP und passt sie den
    eigenen Bedürfnissen an. Behält die Automatismen und filtert die
    Ausnhamen hintendran.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Dienstag, 8. November 2016 14:13

Alle Antworten

  • Die DCs sind 2008 R2 Server.

    Na dann wird es ja erst mal nichts mit 2012R2 ;-)

    Welche Cipher verfügbar sind, hat mir DFL/FFL erst mal nicht zu tun.

    Ob eine Software LDAP oder ADSI zur Abfrage von AD nutzt, kommt auf die Software selbst an.

    Hier ist ein bißchen Lektüre für Dich: https://blogs.technet.microsoft.com/askpfeplat/2012/04/09/a-few-things-you-should-know-about-raising-the-dfl-andor-ffl-to-windows-server-2008-r2/


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Dienstag, 8. November 2016 13:08
  • > Die DCs sind 2008 R2 Server.

    Na dann wird es ja erst mal nichts mit 2012R2 ;-)

    Ja, das stimmt  :-))

    Hatte vergessen zu erwähnen, dass wir natürlich auf 2012 R2 migrieren... ;-)


    Dienstag, 8. November 2016 13:31
  • Hallo

    Das ist richtig, bei 2012R2 und im übrigen auch bei anderen OS resp. Domain Level wurden Policies per Defautl (falls man die Default Settings nimmt) "abgeschaltet".

    Ich habe von ca. 1 Jahr von 2003R2 direkt auf 2012R2 gewechselt. Folgende Policies (nicht abschliessend) solltest Du genau beachten:

    Network security: Configure encryption types allowed for Kerberos
    Network security: LAN Manager authentication level
    Network security: Minimum session security for NTLM SSP based (including secure RPC) Clients
    Network security: Minimum session security for NTLM SSP based (including secure RPC) Servers

    Wichtig ist zu beachten, dass die Domain Controller Policy auf die Applikationen die verwendet werden abgestimmt sind. Braucht z.B. eine Applikation NTLMv1, dann musst Du entweder die Applikation auf V2 oder Kerberos umstellen oder eben die DC Policy. Das selber gilt bei DES etc.

    Ich hatte das Problem, dass vereinzelte Server (Exchange) noch alte Policy Settings hatten und diese nicht kompatibel mit der DC Policy waren... ging halt nichts mehr..

    Ein kleiner Tipp: Verwende nie die "Domain Controller Policy" sonder erstelle eine eigene und deaktiviere die Default Policy, so hast Du bei einem Update keine oder weniger Probleme da diese unverändert bleibt. Ein weitere Grund ist, bei einem Disaster Fall (Forest Restore) kann es sein, dass die Default Settings der Domain Contoller Policy restored werden und Du danach diverse Probleme bekommst.

    Wichtig: Die Domain Controller Policy sollte sich an Deiner Umgebung orientieren und nicht was Microsoft als "Default" sieht... wäre bei mir auch in die Hose gegangen..

    Gruss

    Dienstag, 8. November 2016 13:54
  • Hey! Vielen Dank schon mal für das Teilen Deiner Erfahrungen!!
    Dienstag, 8. November 2016 14:02
  • Hi,
     
    Am 08.11.2016 um 14:54 schrieb dahawei:
    > Ich habe von ca. 1 Jahr von 2003R2 direkt auf 2012R2 gewechselt.
    > Folgende Policies (nicht abschliessend) solltest Du genau beachten:
     
    Wenn die Richtlinien schon editiert sind, werden sie durch die Migration
    nicht verändert. Wird ein 2012R2 AD /neu/ aufgebaut, dann sind alte
    Clients erst mal ausgeschlossen (siehe Abschluss Hinweis in der Promotion)
     
    Wenn die Richtlinien auf "nicht konfiguriert" stehen, ist das Default
    Verhalten eines 2012R2 Server so, daß sie für alte Clients angepasst
    qwerden müssen.
     
    > Ein kleiner Tipp: Verwende nie die "Domain Controller Policy"
     
    Dem widerspreche ich.
    Sie ist genau dafür da. Eigene baut man nur für den Fall der Ausnahmen,
    aber nicht grundsätzlich.
    Die Default Richtlinien (egal ob DDP oder DDCP) sind hardcodiert in den
    Systemen verankert und werden von einigen Prozesssen direkt angesprochen.
    Nutzt man eigene Richtlinien muss man immer händisch nacharbeiten, da
    die Routinen zwar in die DDCP/DDP schreiben, aber sie nicht aktiv sind
    und somit in der eigenen "aktiven" fehlen.
     
    > Ein weitere Grund ist, bei einem Disaster Fall (Forest Restore) kann
    > es sein, dass die Default Settings der Domain Contoller Policy
    > restored werden und Du danach diverse Probleme bekommst.
     
    Ein Desaster Recovery Scenario, daß nicht den Zustand wiederherstellt,
    den ich erwarte/möchte ist ein Desaster, aber kein Desaster Recovery.
    Da ist dann ein Fehler im Backup. Oder kein Mensch hat jemals die
    Richtlinien und deren Verlinkungen einzelnt gesichert.
     
    Davon abgesehen, habe ich seit 10 Jahren kein "Desaster Recovery" mehr
    in Prod erlebt. Zum Glück. Seit Virtualisierungzeiten und damit
    pauschalisierter Hardware kommt das nur noch vor, wenn die Hütte
    abgebrannt ist.
     
    > Wichtig: Die Domain Controller Policy sollte sich an Deiner Umgebung
    > orientieren und nicht was Microsoft als "Default" sieht...
     
    Logisch. Deswegen editiert man die DDP und DDCP und passt sie den
    eigenen Bedürfnissen an. Behält die Automatismen und filtert die
    Ausnhamen hintendran.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Dienstag, 8. November 2016 14:13
  • >> Ein kleiner Tipp: Verwende nie die "Domain Controller Policy"
    >Dem widerspreche ich.
    Sie ist genau dafür da. Eigene baut man nur für den Fall der Ausnahmen,
    aber nicht grundsätzlich.
    Die Default Richtlinien (egal ob DDP oder DDCP) sind hardcodiert in den
    Systemen verankert und werden von einigen Prozesssen direkt angesprochen.
    Nutzt man eigene Richtlinien muss man immer händisch nacharbeiten, da
    die Routinen zwar in die DDCP/DDP schreiben, aber sie nicht aktiv sind

    und somit in der eigenen "aktiven" fehlen.

    >>Ich weiss nicht wie Deine Policy aussieht aber bei uns ist diese z. T. weit weg von heutigen MS Settings, ebenso auf Servern... wie gesagt kommt auf die Applikations Umgebung an. Daher erachte ich es als sicherer, nicht mit der Default Policy zu arbeiten. Somit bin ich unabhängig von irgendwelchen Veränderungen.

    Nutzt man eigene Richtlinien muss man immer händisch nacharbeiten
    >> Ich arbeite bei solchen Angelegenheiten lieber händisch und weiss daher genau was ich mache reps. was die Auswirkungen sind..

    Dienstag, 8. November 2016 15:02
  • Am 08.11.2016 um 16:02 schrieb dahawei:
    > Ich arbeite bei solchen Angelegenheiten lieber händisch und weiss
    > daher genau was ich mache reps. was die Auswirkungen sind..
     
    oder auch nicht direkt, warum es nicht geht :-)
    Am Ende geschmackssache und persönliche Vorliebe.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Dienstag, 8. November 2016 16:33