pingcastle - Ergebnisse umsetzen

[roccomarcy 20]

Hallo,

 

ich hatte vor kurzem erst ein Thema bzgl. SMB Signierung im Forum erstellt. Die Anpassung dazu habe ich noch nicht umgesetzt, da ich mit dem Tool pingcastle einen Bericht des aktuellen IST-Zustand gezogen haben.

Dabei sind folgende Punkte herausgekommen, die ich nun Stück für Stück abarbeiten möchte.

 

Ausgangslage (kopiert aus verlinktem Thema):

 

• Windows Server 2016 / 2019 (mehrere Domain-Controller, Dateiserver, App-Server, usw)
• Exchange 2016
• Windows 10 Pro
• verteilt über vers. Standorte

 

pingcastle-Ergebnisse:

 

1. Gesamtstruktur und Domänenfunktionsebene von 2012 auf 2016 anheben.
2. SMB v1 aktiviert auf den Domain-Controllern.
3. LAN Manager Authentication Level
4. SMB Signierung
5. administrative Konten in Protected Group hinzufügen (Tier0-Administratoren)
6. Änderung krbtgt Passwort
7. Benutzergruppe "Authentifizierte Benutzer" ist Mitglied von Pre-Windows 2000
8. Encryption Types für Kerberos anpassen - aktuell ist dort noch DES-CBC-CRC, DES-CBC-MD5 aktiviert.

 

Meine Frage hier bezieht sich auf die Reihenfolge und Kritikalität der Themen. Gibt es eine sinnvolle Reihenfolge die Änderungen durchzuführen oder kann ich nacheinander weg die Anpassung(en) durchführen?

[NorbertFe 2.032]

vor 7 Minuten schrieb roccomarcy:

• administrative Konten in Protected Group hinzufügen (Tier0-Administratoren)

Das wird in den wenigstens Fällen sinnvoll funktionieren, wenn man nicht vorher schon eine saubere Admin Trennung umgesetzt hat. 

 

1. Unkritisch

2. "normalerweise" unkritisch in der Umsetzung und aus Security Gründen definitiv schnellstmöglich umzusetzen. Und zwar nicht nur auf den Domänencontrollern, sondern auf ALLEN Systemen (Client, Member, DC und Drucker usw.)

3. Wenn Exchange mit Extended Protection im Einsatz sein sollte, dürfte sowieso kein LM mehr eingesetzt werden, so dass man das im Allgemeinen heutzutage problemlos auf 3 oder 4 konfigurieren kann.

4. Ja aktivieren. Jedes moderne System ab Vista kommt damit klar. Alle anderen Systeme auch, wenn sie nicht total veraltete Varianten nutzen. Aber das merkst du dann schon ;)

5. Siehe oben.

6. Ja kannst du mit entsprechender Vorlaufzeit (innerhalb von 8h problemlos _2x_ ändern.

7. WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren.

8. Kann man "relativ" unkritisch auf die modernen Varianten umstellen/einschränken.

 

Bye

Norbert

[roccomarcy 20]

Hi Norbert,

 

erstmal vielen Dank für die schnelle Antwort. Wenn ich mir deine Liste anschaue, dann kann ich einen Großteil davon ohne größere Ängste umsetzen. Ich würde, wenn von eurer Sicht nichts dagegen spricht, mit den Encryption Types anfangen. Dann SMB v1 deaktivieren (ggf. vorher auf vers. DCs/Servern testen) sowie das LAN Manager Authentication Level anpassen.

Im weiteren Schritt das Funktionslevel anpassen und zum Schluss das Passwort für krbtgt anpassen. Was meinst du mit innerhalb von 8h problemlos 2x ändern? Reicht es nicht, wenn ich es einmal ändere und die Domänen-Controller replizieren sich?

 

Kann ich auf dem Exchange nachvollziehen, ob EP aktiv ist? Ich weiß, dass das mit einem Update reingekommen ist - habe hier aber manuell nichts aktiviert.

 

Bzgl. der Protected Groups - wir haben hier schon vers. Benutzergruppen (Server/Client/Verzeichnisdienst).

bearbeitet 19. Juni von roccomarcy

[testperson 1.675]

vor 3 Minuten schrieb NorbertFe:

7. WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren.

• Das Remote Desktop Gateway bzw. der NPS funktioniert dann erstmal nicht mehr, bis man das Computerkonto in die Gruppe aufnimmt
• https://www.mcseboard.de/topic/224297-welche-berechtigungen-zum-installieren-eines-managed-service-account-delegieren/?do=findComment&comment=1455564

[NorbertFe 2.032]

vor 6 Minuten schrieb roccomarcy:

Kann ich auf dem Exchange nachvollziehen, ob EP aktiv ist? Ich weiß, dass das mit einem Update reingekommen ist - habe hier aber manuell nichts aktiviert.

 

Wenn du Exchange 2019 mit CU14 betreibst, wurde es normalerweise selbständig aktiviert. Wenn du nachschauen willst:

https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/

vor 3 Minuten schrieb testperson:

Das Remote Desktop Gateway bzw. der NPS funktioniert dann erstmal nicht mehr, bis man das Computerkonto in die Gruppe aufnimmt

ADFS hat da auch ein paar Probleme, soweit ich mich erinnere. Muss mal nachschauen.

edit: Ja korrekt mein Group Managed Service Account für die ADFS Farm hat auch die erwähnte Gruppenmitgliedschaft. ;) 

bearbeitet 19. Juni von NorbertFe

[roccomarcy 20]

vor 1 Minute schrieb NorbertFe:

Wenn du Exchange 2019 mit CU14 betreibst, wurde es normalerweise selbständig aktiviert. Wenn du nachschauen willst:

https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/

ADFS hat da auch ein paar Probleme, soweit ich mich erinnere. Muss mal nachschauen.

 

Ich habe Exchange 2016 mit aktuellstem CU im Einsatz.

[NorbertFe 2.032]

vor 1 Minute schrieb roccomarcy:

Ich habe Exchange 2016 mit aktuellstem CU im Einsatz.

Dann musst du es manuell aktivieren:

https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/

 

Hätte dir das HealthCheckerscript auch verraten.

[cj_berlin 1.312]

vor 44 Minuten schrieb NorbertFe:

6. Ja kannst du mit entsprechender Vorlaufzeit (innerhalb von 8h problemlos _2x_ ändern.

10 Stunden und eine Minute, sofern die TGT-Lebensdauer nicht vom Default weg verändert wurde. 

vor 46 Minuten schrieb NorbertFe:

1. Unkritisch

wenn es wirklich 2012 ohne R2 ist, dann ist es nicht unkritisch, d.h. muss gemacht werden, zumindest bevor man mit Protected Users anfängt. Aber der Vorgang an sich ist in der Tat unkritisch.

[NorbertFe 2.032]

vor 11 Minuten schrieb cj_berlin:

10 Stunden und eine Minute, sofern die TGT-Lebensdauer nicht vom Default weg verändert wurde. 

vor 57 Minuten schrieb NorbertFe:

Ja, aber ich ging dabei davon aus, dass üblicherweise eine Arbeitszeit von 8h in Deutschland gilt. ;) Ansonsten hast du natürlich Recht.

 

vor 11 Minuten schrieb cj_berlin:

Aber der Vorgang an sich ist in der Tat unkritisch.

Aber auch von 2012 aus ist es im Allgemeinen "eher unkritisch". Oder an welcher STelle ist dir das mal auf die Füße gefallen.

bearbeitet 19. Juni von NorbertFe

[cj_berlin 1.312]

vor 2 Minuten schrieb NorbertFe:

Aber auch von 2012 aus ist es im Allgemeinen "eher unkritisch". Oder an welcher STelle ist dir das mal auf die Füße gefallen.

Noch nie. Aber mit 2012 hast Du ja noch keine volle Funktion bei Protected Users und keine Authentication Policies.

 

vor 2 Minuten schrieb NorbertFe:

Ja, aber ich ging dabei davon aus, dass üblicherweise eine Arbeitszeit von 8h in Deutschland gilt. ;) Ansonsten hast du natürlich Recht.

Diese Arbeitszeit gilt aber nicht für Service- und Computer-Accounts  

bearbeitet 19. Juni von cj_berlin

[NorbertFe 2.032]

vor 2 Minuten schrieb cj_berlin:

Diese Arbeitszeit gilt aber nicht für Service- und Computer-Accounts  

Ach hör doch auf  Natürlich auch die brauchen mal Feierabend.

[roccomarcy 20]

vor 46 Minuten schrieb NorbertFe:

Dann musst du es manuell aktivieren:

https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/

 

Hätte dir das HealthCheckerscript auch verraten.

 

Moin,

 

ich hab mir das mal etwas angeschaut - muss auf jeden Fall auf meinem Exchange TLS 1.2 via Skript aktivieren. Bin dann über div. Beiträge bei Microsoft darüber gestolpert, dass das bei den Clients auch aktiv sein muss. Das sollte es aber ja eh per se - oder muss ich hier auch was vorbereiten? Wenn ich die üblichen PS-Skripts abfeuere, dann kommt aus der Registry auf dem Client nichts zurück. Kann ich das irgendwo valide prüfen?

 

Und es wird wohl NTLM v2 vorrausgesetzt. Ich habe via Gruppenrichtlinie ja noch folgendes konfiguriert.

 

 

Laut Registry wird am Client auch NTLM v2 verwendet.

 

[NorbertFe 2.032]

vor 3 Minuten schrieb roccomarcy:

Das sollte es aber ja eh per se - oder muss ich hier auch was vorbereiten?

Wenn du nicht noch mit XP unterwegs sein solltest, ist eigentlich TLS 1.2 bei allen Clients seit Windows 8.1 (afair) per default aktiv.

NTLM hab ich doch oben gesagt, dass du das zwingend benötigst, damit EP mit Exchange funktioniert.

vor 4 Minuten schrieb roccomarcy:

Wenn ich die üblichen PS-Skripts abfeuere, dann kommt aus der Registry auf dem Client nichts zurück. Kann ich das irgendwo valide prüfen?

Da ich die üblichen PS-Skripte nicht kenne, die du da nutzt, kann ich dazu nix sagen. Aber ansonsten, wenn du es abschaltest melden sich deine User recht schnell ;)

[roccomarcy 20]

Gerade eben schrieb NorbertFe:

NTLM hab ich doch oben gesagt, dass du das zwingend benötigst, damit EP mit Exchange funktioniert.

 

Ja, das hast du gesagt. Aber was bedeutet das im Detail? Ich hatte ja einen Auszug aus der GPO oben gepostet und einen Screenshot aus der Registry. Bin ich damit auf der 'sicheren' Seite für EP? Oder lauf ich damit auf ein Problem? Laut GPO ist NTLM v2 ja aktiv, wenn ausgehandelt?

[NorbertFe 2.032]

https://learn.microsoft.com/de-de/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-extended-protection?view=exchserver-2019#ntlm-version-requirements

 

Zitat

Wenn auf Ihren Clients nach der Aktivierung des erweiterten Schutzes Kennwortaufforderungen angezeigt werden, sollten Sie den folgenden Registrierungsschlüssel und wert auf Ihrem Client und auf der Exchange Server-Seite überprüfen:

Registrierungsschlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Registrierungswert: LmCompatibilityLevel

Es wird empfohlen, ihn auf den Wert festzulegen, der 5ist Send NTLMv2 response only. Refuse LM & NTLM. Es muss mindestens auf einen Wert festgelegt werden, der ist 3Send NTLMv2 response only.

 

 

 

vor 8 Minuten schrieb roccomarcy:

Laut Registry wird am Client auch NTLM v2 verwendet.

 

Dein Screenshot zeigt aber was anderes. Siehe oben (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa   LmCompatibilityLevel) 

bearbeitet 19. Juni von NorbertFe