3
ActiveDirectory Lesezugriff für bestimmte Benutzerobjekte verhindern
Hallo an alle IT-Professionals (und die, die es werden wollen),
in der OU "Adminkonten" befinden sich Benutzerkonten an welche administrative Rechte delegiert wurden. Authentifierzte Benutzer können per default den Inhalt
der OU sowie Benutzerattribute lesen.
Aus Sicherheitsgründen ist es jedoch sinnvoll, dass eben nicht jeder z.B. den Anmeldenamen eines solchen Kontos auslesen kann, sondern dass
dieses Recht für eine bestimmte Gruppe delegiert wird.
Es geht hier also nicht darum, prinzipiell ein bestimmtes Attribut zu verstecken, sondern für einen bestimmten Bereich zu bestimmen, wer was darf.
Per default sind "Authentifizierte Benutzer" mit dem Leserechte für die OU ausgestattet (nur dieses Objekt). Entfernt man das Leserecht für diese
Gruppe, wird sie komplett aus der ACL-Liste entfernt, da keine weiteren Rechte eingetragen sind. Ergebnis:
Die OU wird unter Active Direcotry-Benutzer und -Computer nicht mehr im "Navigation Pane" (linke Seite) angezeigt, jedoch weiterhin im Hauptfenster
mit geändertem Icon und der Typ-Bezeichnung "unbekannt". Das Problem dabei ist, dass sich die Benutzer und dessen Eigenschaften innerhalb der OU
nach wie vor durch einen authentifzierten Benutzer anzeigen lassen (z.b. über die Suchfunktion), denn jeder neu erstellte Benutzer bekommt eine
Default-ACL und in dieser sind wieder die "Authentifizierte Benutzer" eingetragen".
Das ändern der Default-ACL über das AD-Schema wäre unsinnig, es würde für alle neu angelegten Benutzer gelten.
Mögliche Lösungen:
-händisch oder per Task (Skript) die ACL-Liste der Benutzer unter der OU "Adminkonten" bearbeiten (Authentifizierte Benutzer raus, Berechtigunsgruppe rein)
-alle Benutzer, die nicht Objekte und deren Attribute in der OU "Adminkonten" lesen sollen, werden in eine Gruppe gepackt (AD_Adminkonten_DenyRead) und
diese dann in die OU-ACL eingetragen (Deny Read, dieses und alle untergeordneten Objekte)
Hat alles seine Vor- und Nachteile. Welche Lösung habt ihr parat, bzw. was empfehlt ihr?
kurz zu der Umgebung: Windows Server 2008 R2
Viele Grüße,
in der OU "Adminkonten" befinden sich Benutzerkonten an welche administrative Rechte delegiert wurden. Authentifierzte Benutzer können per default den Inhalt
der OU sowie Benutzerattribute lesen.
Aus Sicherheitsgründen ist es jedoch sinnvoll, dass eben nicht jeder z.B. den Anmeldenamen eines solchen Kontos auslesen kann, sondern dass
dieses Recht für eine bestimmte Gruppe delegiert wird.
Es geht hier also nicht darum, prinzipiell ein bestimmtes Attribut zu verstecken, sondern für einen bestimmten Bereich zu bestimmen, wer was darf.
Per default sind "Authentifizierte Benutzer" mit dem Leserechte für die OU ausgestattet (nur dieses Objekt). Entfernt man das Leserecht für diese
Gruppe, wird sie komplett aus der ACL-Liste entfernt, da keine weiteren Rechte eingetragen sind. Ergebnis:
Die OU wird unter Active Direcotry-Benutzer und -Computer nicht mehr im "Navigation Pane" (linke Seite) angezeigt, jedoch weiterhin im Hauptfenster
mit geändertem Icon und der Typ-Bezeichnung "unbekannt". Das Problem dabei ist, dass sich die Benutzer und dessen Eigenschaften innerhalb der OU
nach wie vor durch einen authentifzierten Benutzer anzeigen lassen (z.b. über die Suchfunktion), denn jeder neu erstellte Benutzer bekommt eine
Default-ACL und in dieser sind wieder die "Authentifizierte Benutzer" eingetragen".
Das ändern der Default-ACL über das AD-Schema wäre unsinnig, es würde für alle neu angelegten Benutzer gelten.
Mögliche Lösungen:
-händisch oder per Task (Skript) die ACL-Liste der Benutzer unter der OU "Adminkonten" bearbeiten (Authentifizierte Benutzer raus, Berechtigunsgruppe rein)
-alle Benutzer, die nicht Objekte und deren Attribute in der OU "Adminkonten" lesen sollen, werden in eine Gruppe gepackt (AD_Adminkonten_DenyRead) und
diese dann in die OU-ACL eingetragen (Deny Read, dieses und alle untergeordneten Objekte)
Hat alles seine Vor- und Nachteile. Welche Lösung habt ihr parat, bzw. was empfehlt ihr?
kurz zu der Umgebung: Windows Server 2008 R2
Viele Grüße,
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 185073
Url: https://administrator.de/contentid/185073
Ausgedruckt am: 26.11.2024 um 22:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo
ich wäre für diese Lösung. Aber Sicherheit durch verstecken ist nei eine gute Lösung. Sichere Passwörter sollten meiner bescheidenen Meinung ausreichen.
Grüße
-alle Benutzer, die nicht Objekte und deren Attribute in der OU "Adminkonten
ich wäre für diese Lösung. Aber Sicherheit durch verstecken ist nei eine gute Lösung. Sichere Passwörter sollten meiner bescheidenen Meinung ausreichen.
Grüße
Es ist nicht wirklich trivial, hier eine einfache Lösung zu finden.
Auch ist schwer abzuschätzen, welche Auswirkungen die Änderungen haben könnten, z.B. für bestimmte Programme die auf das AD zugreifen.
Hilfreich war für mich auch folgender Link:
http://www.faq-o-matic.net/2011/03/24/vorsicht-falle-vererbung-im-ad/
Hier hilft wohl nur ausprobieren, sich vorsichtig herantasten und vor allem gut dokumentieren.
Änderungen im AD-Schema kommen für mich zu diesem Zweck nicht in Frage, eher würde ich ein Script schreiben welches als Task
regelmäßig die gewünschten Berechtigungsänderungen vornimmt (falls Berechtigungsänderungen auf OU-Ebene nicht ausreichen sollten, da Benutzerobjekte per default die Vererbung deaktiviert haben).
Auch ist schwer abzuschätzen, welche Auswirkungen die Änderungen haben könnten, z.B. für bestimmte Programme die auf das AD zugreifen.
Hilfreich war für mich auch folgender Link:
http://www.faq-o-matic.net/2011/03/24/vorsicht-falle-vererbung-im-ad/
Hier hilft wohl nur ausprobieren, sich vorsichtig herantasten und vor allem gut dokumentieren.
Änderungen im AD-Schema kommen für mich zu diesem Zweck nicht in Frage, eher würde ich ein Script schreiben welches als Task
regelmäßig die gewünschten Berechtigungsänderungen vornimmt (falls Berechtigungsänderungen auf OU-Ebene nicht ausreichen sollten, da Benutzerobjekte per default die Vererbung deaktiviert haben).
Zitat von @lenny4me:
Hallo
> -alle Benutzer, die nicht Objekte und deren Attribute in der OU "Adminkonten
ich wäre für diese Lösung. Aber Sicherheit durch verstecken ist nei eine gute Lösung. Sichere Passwörter
sollten meiner bescheidenen Meinung ausreichen.
Grüße
Hallo
> -alle Benutzer, die nicht Objekte und deren Attribute in der OU "Adminkonten
ich wäre für diese Lösung. Aber Sicherheit durch verstecken ist nei eine gute Lösung. Sichere Passwörter
sollten meiner bescheidenen Meinung ausreichen.
Grüße
Ein Grund zum Verstecken des Anmeldenamens bestimmter AD-Accounts wäre z.B. das Vermeiden von Denial of Service-Attacken. Versucht z.B. ein Angreifer, der bereits den Anmeldenamen weiß, eine wiederholte Authentifizierung mit falschem Passwort, so kann es bei den entsprechenden Richtlinien dazu führen, dass dieser Account gesperrt wird.
Wird dieser Account eingesetzt, um z.B. einen wichtigen Task (Backup etc.) auszuführen....nun, es muss jeder selbst entscheiden und Aufwand/Risiko abwägen.
