LDAP Lese-Zugriff auf ActiveDirectory unterbinden

[WIN.ini]

Hi!
Ich hoffe hier hat vielleicht jemand ein ähnliches Thema begleitet und hat entsprechende Tipps und Infos.
Ich möchte gerne den standardmäßigen Zugriff via LDAP auf das AD verhindern.
Alle How-To's die ich dazu finde, erwähnen immer nur den List Object Mode und wie man diesen aktiviert.
Da wir jedoch einen Exchange Server einsetzen, ist der List Object Mode bereits aktiviert und es kann an die Berechtigung gehen. Hier schweigt jedoch jedes How-To.

Die beste Anleitung die ich finden konnte ist hier: Hiding Data in AD List Object Mode | IT Pro

Kann mir jemand bestätigen, dass die folgenden Befehle dafür sorgen, dass der LDAP Zugriff verweigert wird?
Die Befehle sind aus dem verlinkten Artikel und nur gering angepasst

Erster Befehl zum setzen der Berechtigung auf erster Ordnungseinheit (alle vorhandenen Rechte von Authentifizierte Benutzer entfernen und benötigte Lese-Rechte -ohne "List Contents"- setzen):

set DN="OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRPLO

Befehl zum Auslesen der Unter-OUs, welche berechtigt werden müssen

DSQUERY ou "OU=Benutzergruppe1,OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE" -scope onelevel > queryresult.txt

Anschließender Befehl um die Rechte zu setzen (Entfernen der Standardberechtigung "List Object" und "List Contents" für die Unter-OUs):

for /f "delims=" %I in (queryresult.txt) do set SP="Authenticated Users"&& DSACLS "%~I" /R %SP%&& DSACLS "%~I" /G %SP%:RCRP

Die Leseberechtigung für Admingruppen wieder setzen:

DSACLS "OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE" /G "Domain-Admins":LOLC

Diese Schritte müssten für alle Unter-OUs der Domäne wiederholt werden.

Ist das wirklich der beste und korrekte Weg?

Was ist mit den Unter-unter-OUs?

Via DSQUERY lese ich die Unter-OUs der OU "Benutzergruppe1" aus. Aber was ist mit den OUs, die noch weiter verschachtelt sind? Lasse ich das "-scope onelevel" weg, erhalte ich ALLE Unter-OUs -> sollte also funktionieren?

Nach meinem Verständnis würde das so aussehen:

Domäne wie folgt aufgebaut
Domänenname: FQDN.DER.DOMÄNE
OU's: "Benutzer" "Server" "Beispiel3" und natürlich alle Standard-OUs wie "Users","Computers","Domain Controllers" etc.
Unterhalb von "Benutzer" gibt es "Benutzergruppe1" und "Benutzergruppe2"
Unterhalb von "Benutzergruppe1" noch "Test"

Folgende Befehle werden abgesetzt:

set DN="OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRPLO
set DN="OU=Server,DC=FQDN,DC=DER,DC=DOMÄNE"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRPLO
set DN="OU=Beispiel3,DC=FQDN,DC=DER,DC=DOMÄNE"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRPLO

Das selbe wird auch für die Standard-OUs gemacht.
Alternativ müsste auch folgendes gehen (oder?):

DSQUERY ou "DC=FQDN,DC=DER,DC=DOMÄNE" -limit 0 -scope onelevel > queryresult.txt
for /f "delims=" %I in (queryresult.txt) do set DN="OU=%~I"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRPLO

Anschließend werden alle Unter-OUs ausgelesen:

DSQUERY ou "OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE" > queryresult1.txt
DSQUERY ou "OU=Server,DC=FQDN,DC=DER,DC=DOMÄNE" > queryresult2.txt
DSQUERY ou "OU=Beispiel3,DC=FQDN,DC=DER,DC=DOMÄNE" > queryresult3.txt

Der nächste Befehl ändert die entsprechenden Berechtigungen

for /f "delims=" %I in (queryresult1.txt) do set SP="Authenticated Users"&& DSACLS "%~I" /R %SP%&& DSACLS "%~I" /G %SP%:RCRP
for /f "delims=" %I in (queryresult2.txt) do set SP="Authenticated Users"&& DSACLS "%~I" /R %SP%&& DSACLS "%~I" /G %SP%:RCRP
for /f "delims=" %I in (queryresult3.txt) do set SP="Authenticated Users"&& DSACLS "%~I" /R %SP%&& DSACLS "%~I" /G %SP%:RCRP

LDAP für Admins wieder erlauben

DSQUERY ou "DC=rdl-ts,DC=farm,DC=rcom" -limit 0 > queryresult.txt
for /f "delims=" %I in (queryresult.txt) do DSACLS "OU=%~I" /G "Domain-Admins":LOLC

Sollte eine weitere Benutzergruppe z.B. Lesezugriff auf eine einzelne OU erhalten, wird letzter Befehl entsprechend angepasst:

DSACLS "OU=Test,OU=Benutzergruppe1,OU=Benutzer,DC=FQDN,DC=DER,DC=DOMÄNE" /G "LDAP-Zugriff":LOLC

Das ist verdammt viel Text und viel Code.
Ich hoffe es hat sich jemand die Mühe gemacht das durchzulesen und kann mir eine Info geben.

Habe ich einen Denkfehler? Können die Befehle weiter optimiert werden oder z.B. als Script zusammengefasst werden? Gibt es einen Plan für die Disaster-Recovery?

Jede Antwort erhält ein herzliches Dankeschön!

 

[fdsonne]

Warum arbeitest du nicht mit Vererbung?

Auch halte ich es für nicht so "gut", die Standard OUs/Container zu nutzen...
Leg dir ne saubere Struktur an, diese berechtigst du sauber durch und entfernst dann einfach die "Authenticated Users" Gruppe von den Standard Ordnern - wenn überhaupt -> weil wenn da nix mehr drin ist, was für dich/euch relevant ist, DANN kannst du da auch nicht mehr wirklich was holen mit simplen RO Access.
In der neuen OU-Struktur, wo du dann alle User, Computer usw. rein packst, kannst du direkt die "Authenticated Users" Gruppe entsprechend nur noch so hinterlegen, wie du es wünscht...

Des weiteren besteht das AD aus "mehr" als nur bisschen User und Computer Objekten. Da gibts ne ganze Menge mehr Stellen, wo die "Authenticated Users" Gruppe hinterlegt ist - oder teils sogar Everyone. Bspw. bei jeder DNS Zone steht Everyone auf "Create all child objects". Der normal authentifizierte User kann via ADSI die Configuration DB einsehen usw.
Netlogon Share, GPOs usw. sind auch einsehbar, per default wirkt auch jede GPO auf "Authenticated Users" - und teilweise musst du da echt aufpassen, was du tust, sonst geht es einfach nicht mehr...


Bedenke allerdings, so 100% komplett weg ist nicht. User Objekte, benötigen teilweise einfach mindestens lesenden Zugriff. Teils auch gewisse Schreibende Berechtigungen (auf sich selbst bspw.)
Das Impliziert aber auch, dass so mancher Account in seiner Struktur eben auch Daten sehen kann von "Anderen" Accounts. Es sei denn, du brichst das wirklich 100% auf die jeweiligen Objekte runter...

 

[WIN.ini]

Vielen Dank für deine Antwort!
EIne völlig neue Möglichkeit, an die ich bisher noch gar nicht gedacht habe.
Das muss ich nochmal prüfen ob das ggf. nicht einfacher ist (sauberer auf jeden Fall).

Danke für die Anmerkungen, allerdings möchte ich lediglich die sensiblen Daten ausblenden. Ein einfacher User soll nicht auslesen können, welche weiteren Benutzer oder Server es gibt. Im NETLOGON liegt nichts besonderes, sodass der Lesezugriff in Ordnung ist.
Auch ist der Zugriff auf den ADSI Editor natürlich unterbunden sodass hier auch keine Gefahr lauert.
Ich denke mit der reinen Zugriffsbeschränkung der OUs ist mir schon sehr geholfen!
Durch die Neuanlage ist auch eine häppchenweise Umstellung möglich, was die Fehleranalyse natürlich einfacher macht.

Ich durchdenke das ganze nochmal bei Gelegenheit und melde mich vielleicht nochmal!

Ganz herzliche Grüße

 

[WIN.ini]

Huhu,

irgendwie klappt das nicht so ganz, wie ich mir das vorgestellt habe.
Ich habe heute angefangen eine parallele OU-Struktur in der Domäne aufzubauen.
Nach Erstellung der ersten OU bin ich direkt in die Eigenschaften gegangen, habe die Vererbung deaktiviert und sowohl "Authentifizierte Benutzer" als auch "Prä-2000-kompatibler-Zugriff" entfernt (an die dutzend anderen Gruppen und Konten habe ich mich vorerst nicht rangetraut).

Anhand des effektiven Zugriffs sehe ich auch, dass beliebige User den Inhalt nicht mehr auflisten können.

Allerdings werden diese Rechte nicht wie erwartet weiter vererbt.
Erstelle ich in der neuen Struktur eine Unter-OU hat diese wieder die Standard-Rechte. Gerade die Vererbung ist ja der große Vorteil bei deiner Methode.

Schalte ich die Vererbung auf der ersten OU wieder ein, schnappt er sich logischer Weise sofort wieder die (ungewollten) Rechte der Domäne.

Was mache ich falsch?

LG


EDIT:
Hab ein wenig recherchiert und folgende Seite gefunden: Vorsicht, Falle! Vererbung im AD | Mathom
Hier wird es genau erklärt! Sehr interessant. Ich muss also scheinbar in die AD-Schema Einstellungen eingreifen um die standardmäßig berechtigten Authentifizierten Benutzer bei Neuanlage einer OU zu entfernen.

 

[fdsonne]

Change Default OU permissions in Active Directory TheITBros
-> du musst noch die default Settings anpassen

 

[WIN.ini]

Die Default Werte sind angepasst, das funktioniert jetzt bei neuangelegten OUs, allerdings werden natürlich trotzdem noch von der überliegenden OU, bzw. von der Root-Domäne die Rechte vererbt. Deaktiviere ich die Vererbung, stimmen die Rechte.
Aus dem Root bekomme ich die Rechte vermutlich nie raus, weil wenn ich dort Anpassungen vornehme, zerschießt er mir ja die ganze unterliegende Berechtigung, nehme ich an?
Aber wenn man weiß, dass man bei neuen OUs auf erster Ebene noch einmal die Vererbung deaktivieren muss, sollte das kein Problem sein.

Wie ist das nun mit den Default-OUs wie "Users" "Computers" "Domain Controllers" etc. Diese kann ich ja nicht einfach neu anlegen (bzw. möchte ich das nicht). Hier kann ich die Rechte einfach manuell entziehen, oder?

LG und vielen Dank!

 

[lisastein]

Ja die Rechte auf Default-OUs kannst Du manuell setzen in der AD.

 

[WIN.ini]

Ich muss das Thema nochmal hochholen, da ich mittlerweile doch auf ein Problem gestoßen bin, welches höchstwahrscheinlich mit meinen Änderungen zu tun hat.

Wie besprochen habe ich eine neue OU-Struktur angelegt mit entsprechenden Rechten. Via LDAP kann ich hier auch keine Informationen mehr auslesen.
Die Anmeldung der User schien problemlos und alles funktionierte normal.
Mittlerweile stelle ich jedoch fest, dass unsere GPOs nicht mehr greifen.
Sprich Änderungen werden nicht übernommen und komplett neu angelegte User ziehen sich gar keine Einstellungen.
Natürlich wurden alle GPOs mit der neuen Struktur verknüpft.

In der Sicherheitsfilterung sind die standardmäßigen "authentifizierten Benutzer" hinterlegt. Ich habe hier natürlich direkt einen Zusammenhang vermutet und dies um eine Sicherheitsgruppe mit entsprechenden Benutzern erweitert (auch unter Delegation sind die Leserechte [inkl. Computerkonto] korrekt hinterlegt). Leider brachte das keine Besserung.

Kann es sein, dass die GPO direkt davon betroffen ist, dass authentifizierte Benutzer jetzt nicht mehr auf der OU berechtigt sind? Falls ja, welche Sicherheitsgruppe muss ich nachträglich berechtigen, damit GPOs wieder greifen?

Vielen Dank!

 

[WIN.ini]

Nach stundenlanger Recherche habe ich eigentlich genau mein Problem gefunden: [SOLVED] Securing our AD by removing Authenticated Users from an OU breaks Group Policy - Spiceworks

Die scheinbare Lösung ist der letzte Post

As an AD Search still shows up all users for the domain (with no details but the users itself, their display name is too much info in my case) it's not good enough for me.... so i researched again and found this article here Who broke my user GPOs? | Ask Premier Field Engineering (PFE) Platforms where i found the little info about "domain computers" need access to the GPO's (for the files, nothing to do with AD permissions). So i combined a bit and give it again a try and set the permissions suggested by benutne not to authenticated users but to "domain computers" ... voila, no users found in AD Search but GPO are applied successfully.

Allerdings klappt es trotzdem nicht. Ich habe sowohl auf die erste OU, als auch auf die Unter-OU in welcher die User liegen, die Sicherheitsrechte für "Domänencomputer" allgemein auf Lesen gesetzt (das inkludiert genannte Rechte).
Dennoch erhalte ich bei einen gpupdate die Meldung "Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Benutzername konnte nicht aufgelöst werden." bzw. bei einem gpresult "INFO: Der Benutzer hat keine RSoP-Daten."

 

[WIN.ini]

Ich hab's!!

Um es kurz zu fassen: Nicht nur "Domänencomputer" benötigen entsprechende Leserechte, auch das eigentliche Objekt um das geht (sprich der Benutzer) benötigt Leserechte auf seine eigene OU.

Da es in meinem Fall glücklicherweise für jede OU auch eine entsprechende Benutzergruppe gibt, brauch ich einfach nur diese Sicherheitsgruppe mit Leserechten für den eigenen Container ausstatten.

GPOs greifen korrekt, LDAP Zugriff ist nicht möglich (interessanter Weise sogar nicht mal auf die eigene OU [obwohl hier ja jetzt Leserechte verteilt sind] da die Rechte auf erster Ebene schon nicht erteilt sind).


Vielen Dank an alle Beteiligten!