AD Tiering Modell

[Chris_S04]

Hallo,

ich beschäftige mich derzeit damit das Tiering Modell in unser AD einzuführen.

Ich hab dazu eine kleine Teststellung gebaut. Im AD hab ich drei OUs "Tier 0" bis "Tier 2" und dort jeweils Unter-OUs "User", "Gruppen", "Computer". Tier 0 hat einen Server 2022 und einen Admin-User. Tier 1 auch einen Server 2022, einen Admin und einen User und Tier 2 zwei W10 Clients, einen Admin und einen User.

Den Rechnern habe ich GPOs zugewiesen, die festlegen, dass sich z.B. kein T0 und T1 Benutzer an T2 Maschinen anmelden kann (Batch, Dienst, RDP, lokal und Netzwerk). In T1 und T0 ähnlich, außer Netzwerkzugriff, der muss gegeben sein.

Wenn ich mich jetzt an einem der T2 Clients anmelden möchte als User aus T1 oder T0 dann darf ich das nicht, wie erwartet, auch erhöhte Rechte per UAC bekomme ich natürlich nicht (sind ja keine Admins in T2). Allerdings werden die Anmeldedaten der User aus T1 und T0 obwohl der Login verwährt ist, dennoch gespeichert. Wenn ich mir die entsprechenden Schlüssel aus der Reg exportiere und auf einer Linux Maschine per secretdump einsehe, sind dort die Anmeldedaten der User zu finden obwohl die Anmeldung nicht erlaubt ist und auch nicht klappt. Das sollte natürlich nicht sein, da hier eine fixe Trennung vorliegen sollte.

Habt ihr da einen Tipp, was ich ggf. falsch gemacht hab oder noch prüfen könnte? Wäre es ggf. besser statt der GPOs Authentication Policies (und evtl. Silos) zu verwenden?

Was mir auch noch nicht ganz einleuchtet ist ob ich Rechnern aus T2 z.B. verbieten kann auf die Admin-Shares eines T1 oder T0 Rechners zuzugreifen, wenn er die passenden Creds eingibt. Auch eine Remote PS-Session kann ich öffnen, wenn ich entsprechende Anmeldedaten angebe. Das würde ich aber gern verbieten. Ein Client eines niedrigeren Tiers sollte eine solche Verbindung in ein höheres Tier aufbauen können oder verstehe ich das falsch?

Schon Mal danke für eure Tipps

 

[DenB]

Hmm, ohne jetzt viel gelesen zu haben, weil ich kurz vorm Schlafen bin, ist das Modell nicht mehr aktuell

https://learn.microsoft.com/de-de/s...model#evolution-from-the-legacy-ad-tier-model

 

[crashbandicot]

In T1 und T0 ähnlich, außer Netzwerkzugriff, der muss gegeben sein.

Warum?

Ein Client eines niedrigeren Tiers sollte eine solche Verbindung in ein höheres Tier aufbauen können

Nein.

oder verstehe ich das falsch?

Ja.

Allerdings werden die Anmeldedaten der User aus T1 und T0 obwohl der Login verwährt ist, dennoch gespeichert. Wenn ich mir die entsprechenden Schlüssel aus der Reg exportiere und auf einer Linux Maschine per secretdump einsehe, sind dort die Anmeldedaten der User zu finden obwohl die Anmeldung nicht erlaubt ist und auch nicht klappt. Das sollte natürlich nicht sein, da hier eine fixe Trennung vorliegen sollte.

Du wirst technisch nicht verhindern können, dass ein (unbedarfter) Nutzer eine T0 Kennung auf einem T2 Client eingibt. Dass der Client diese eingegebenen Credentials dann jedoch zwischenspeichert, obwohl die Anmeldung und damit die Nutzung verboten ist, ist ein Verschulden von Microsoft. Es muss in die Köpfe der T0 und T1 Admins rein, dass Credentials von T0 nicht auf T1 und T2 und von T1 auf T2 eingegeben werden dürfen. Schulung, Schulung, Schulung!

 

[Chris_S04]

@crashbandicot
Danke für deine Antwort.

Ich verstehe gerade nicht, wieso ein T2 keinen Netzwerkzugriff auf T1 und T0 haben darf. Wenn in T0 die DCs stehen muss er sich ggü. diesen authentifizieren können, außerdem DNS etc.. Und in T1 stehen ja die Applikationsserver, auf die ein Client Zugriff benötigt. Wenn ich hier den Zugriff blockiere kann ja kein Client mehr einen Dienst in T0 oder T1 verwenden.

Ansonsten bin ich mittlerweile auch so weit, dass das wohl Mist seitens MS ist. Der User wird nämlich authentifiziert, die Creds gesichert und dann wird die Anmeldung erst blockiert.

Die Sache mit Schulung verstehe ich, aber ich kann mich darauf nicht verlassen, dass das auch so gelebt wird, deshalb kommt das für mich leider nicht infrage. Da frage ich mich ein wenig wieso MS das so handhabt. Das ist nämlich imho ungenügend und das Tiering Modell dadurch eben auch nicht wirklich sicher, weil es durch menschliche Unzulässigkeit einfach ausgehebelt werden könnte.

Ich werde Mal testen ob mir Authentication Policies hier ggf. weiterhelfen können. Außerdem werde ich die Gruppen der T0-, T1- und T2-Admins zu den Protected Users hinzufügen. Einen "Notfall"-Admin werde ich aber noch beibehalten, der kein Protected User ist.

 

[crashbandicot]

Ich verstehe gerade nicht, wieso ein T2 keinen Netzwerkzugriff auf T1 und T0 haben darf. Wenn in T0 die DCs stehen muss er sich ggü. diesen authentifizieren können, außerdem DNS etc.. Und in T1 stehen ja die Applikationsserver, auf die ein Client Zugriff benötigt. Wenn ich hier den Zugriff blockiere kann ja kein Client mehr einen Dienst in T0 oder T1 verwenden.

Sorry, dann habe ich dich falsch verstanden. Natürlich benötigen Clients (T2) netzwerkseitigen Zugriffen auf Applikationsserver (T1) oder Domain Controller (T0). Allerdings sollte man sich dabei ausschließlich auf wirklich benötigte Ports beschränken, also beispielsweise 443/tcp für Webserver oder 88/tcp für Kerberos.

Da frage ich mich ein wenig wieso MS das so handhabt. Das ist nämlich imho ungenügend und das Tiering Modell dadurch eben auch nicht wirklich sicher, weil es durch menschliche Unzulässigkeit einfach ausgehebelt werden könnte.

Ungewollte Anmeldungen lassen sich reduzieren, wenn z.B. 3389/tcp (RDP) gar nicht erst von T2 auf T1/T0 möglich ist. Der T1/T0 Admin kann dann zwar versuchen eine RDP-Verbindung aufzubauen, da diese aber nicht hergestellt werden kann, hat der T1/T0 Admin gar nicht erst die Möglichkeit seine Anmeldedaten zu hinterlegen. Für administrative Freigaben, PowerShell Remote, etc. gilt dies analog.

Außerdem werde ich die Gruppen der T0-, T1- und T2-Admins zu den Protected Users hinzufügen.

Guter Punkt, aber leider auch aufwendig. Mitglieder der 'Protected Users' Gruppe können z.B. kein NTLM mehr nutzen. Abgesehen davon, dass man NTLM eh nicht mehr nutzen sollte, weiß ich aber aus der Praxis, dass das nicht überall geht. Des Weiteren kannst du bestimmte Servicekonten nicht in die Gruppe aufnehmen, da dann keine 'Credential Delegation' mehr funktioniert (Stichwort SPN). Sind alles keine riesigen Hindernisse, erfordern aber mehr Aufwand als einfach nur eine Gruppe zu vergeben.

 

[Chris_S04]

Ja, dass die Ports noch beschränkt werden, kommt dann auch noch durch Anpassung der Netzwerkpolicies. Das steht auch auf der Agenda.

Und klar würde ich dann RDP oder PS-Remote etc. von T2 nach oben sperren, dazu sind die PAWs da. Aber, wenn jemand sich per T1/T0-User/Admin an einer T2-Workstation lokal anmeldet oder die Daten in die UAC eingibt, werden die trotzdem gecached und das ist imho komplett überflüssig. Aber wie gesagt dafür teste ich Mal Authentication Policies und ggf Silos. Aber auch das finde ich seitens MS nicht so ganz zuende gedacht, da ich hier nicht vernünftig mit Gruppen arbeiten kann.

Bei den Protected Users muss ich Mal sehen, was damit ggf. nicht gehen. Denke für reine Administrationszwecke sehe ich da erst Mal wenig Probleme, wird sich dann zeigen. Und ja, Dienstkonten dürfen keine Protected User sein, das weiß ich, dafür möchte eben die Managed Service Accounts nutzen.