17
Benutzern das Browsen im Active Directory verbieten
Guten Morgen,
ich möchte unser AD gerne in verschiedene Ebenen unterteilen.
Ziel ist es, dass in bestimmten OU, die Administratoren eines Kunden auch selbst Benutzer anlegen und mit Gruppen verknüpfen dürfen.
Damit der Kunde nur die OUs sieht für die er auch berechtigt ist, habe ich eine entsprechende Gruppe gebaut und hier auf die OUs, welche er nicht sehen soll eine entsprechende Berechtigung gesetzt.
Mein Problem aktuell ist allerdings noch, wenn der Kunde z.B. in einer Gruppe neu Mitglieder hinzufügen will und er nach einem Namen sucht, den es auch in OUs gibt, welche er nicht einsehen kann, dann kann er diesen Benutzer auch der Gruppe zuweisen.
Ich würde gerne erreichen können, wenn der Kunde einen User sucht um diesen zu berechtigen, dass er dann beim Suchen auch nur die Benutzer aus der OU finden kann für die er auch berechtigt ist.
Das geht son bisschen in Richtung Mandantenfähigkeit.
Hat da jemand eine Idee von Euch wie ich das AD Konfigurieren muss, damit ich mein Ziel mit dem Browsen erreichen kann?
Herzlichen Dank
ich möchte unser AD gerne in verschiedene Ebenen unterteilen.
Ziel ist es, dass in bestimmten OU, die Administratoren eines Kunden auch selbst Benutzer anlegen und mit Gruppen verknüpfen dürfen.
Damit der Kunde nur die OUs sieht für die er auch berechtigt ist, habe ich eine entsprechende Gruppe gebaut und hier auf die OUs, welche er nicht sehen soll eine entsprechende Berechtigung gesetzt.
Mein Problem aktuell ist allerdings noch, wenn der Kunde z.B. in einer Gruppe neu Mitglieder hinzufügen will und er nach einem Namen sucht, den es auch in OUs gibt, welche er nicht einsehen kann, dann kann er diesen Benutzer auch der Gruppe zuweisen.
Ich würde gerne erreichen können, wenn der Kunde einen User sucht um diesen zu berechtigen, dass er dann beim Suchen auch nur die Benutzer aus der OU finden kann für die er auch berechtigt ist.
Das geht son bisschen in Richtung Mandantenfähigkeit.
Hat da jemand eine Idee von Euch wie ich das AD Konfigurieren muss, damit ich mein Ziel mit dem Browsen erreichen kann?
Herzlichen Dank
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: 568083
Url: https://administrator.de/forum/benutzern-das-browsen-im-active-directory-verbieten-568083.html
Ausgedruckt am: 24.12.2024 um 12:12 Uhr
17 Kommentare
Neuester Kommentar
hi,
genau diese Anleitung funktioniert nicht.
Er sieht die OU dann nicht mehr aber die User findet er weiterhin über das "Browsen".
genau diese Anleitung funktioniert nicht.
Er sieht die OU dann nicht mehr aber die User findet er weiterhin über das "Browsen".
Hi,
wenn man das nur so wie in dieser Anleitung macht, dann ist klar, dass das nicht geht.
Man muss nachträglich unter "Erweitert" diese Verweigern-ACE bearbeiten und bei "Anwenden auf" aus "Nur dieses Objekt" dann "Dieses und alle untergeordneten Objekte" machen. Dann sollte das funktionieren.
E.
wenn man das nur so wie in dieser Anleitung macht, dann ist klar, dass das nicht geht.
Man muss nachträglich unter "Erweitert" diese Verweigern-ACE bearbeiten und bei "Anwenden auf" aus "Nur dieses Objekt" dann "Dieses und alle untergeordneten Objekte" machen. Dann sollte das funktionieren.
E.
hi
das habe ich mir schon gedacht und es auch auf alle unteren Objekte angewendet nur hat es keine Wirkung.
Er kann weiterhin danach suchen....
das habe ich mir schon gedacht und es auch auf alle unteren Objekte angewendet nur hat es keine Wirkung.
Er kann weiterhin danach suchen....
Ich habe das soeben extra nochmal für Dich durchgespielt: Bei mir funktioniert das so.
Irgendwas musst Du also falsch machen.
- User sieht diese OU gar nicht erst
- Beim Bearbeiten der Gruppe --> Mitglieder --> Hinzufügen werden keine Benutzer aus der gesperrten OU-Struktur angezeigt/gefunden
- beim allgemeinen Suchen im AD werden keine Benutzer aus der gesperrten OU-Struktur gefunden
Irgendwas musst Du also falsch machen.
mmmh oder es wird durch ein anderes Recht oder Gruppe überschrieben.
Ich teste mich mal durch und melde mich was es war.
Vielen Dank erstmal für deine Mühe.
Ich teste mich mal durch und melde mich was es war.
Vielen Dank erstmal für deine Mühe.
Ein "verweigern" kann nicht übersteuert werden. Es sei denn, die ACL ist "korrupt" und die Verweigern-ACE stehen nicht am Anfang der ACL.
N'Abend.
Nennt sich Active Directory List Object Mode:
https://social.technet.microsoft.com/wiki/contents/articles/29558.active ...
Ich rate zur Vorsicht bei der Umsetzung, das ist nichts, was man mit zwei Mausklicks in der Kaffeepause umsetzen könnte.
Cheers,
jsysde
Nennt sich Active Directory List Object Mode:
https://social.technet.microsoft.com/wiki/contents/articles/29558.active ...
Ich rate zur Vorsicht bei der Umsetzung, das ist nichts, was man mit zwei Mausklicks in der Kaffeepause umsetzen könnte.
Cheers,
jsysde
Sorry für die späte Rückmeldung.
Also irgendwas oder irgendwer hat bei uns im AD tatsächlich Änderungen vorgenommen.
Wenn ich in die ACL Berechtigungen unter "Überwachen" reinschaue, dann sind da 5-6 Einträge drin. In einer frisch installierten Domäne sind dort nur 2 Einträge drin und dann auch mit komplett anderen Berechtigungen.
Unterbreche ich nun als Test mal die Vererbung auf einer OU und nehme diese Eintrage raus, dann ist alles genauso wie es sein soll.
Bleibt die große Frage wer hat da was gesetzt.
Trotzdem erstmal vielen Dank für die Hilfe ich muss jetzt mal schauen wie ich das bereinigt bekomme.
Also irgendwas oder irgendwer hat bei uns im AD tatsächlich Änderungen vorgenommen.
Wenn ich in die ACL Berechtigungen unter "Überwachen" reinschaue, dann sind da 5-6 Einträge drin. In einer frisch installierten Domäne sind dort nur 2 Einträge drin und dann auch mit komplett anderen Berechtigungen.
Unterbreche ich nun als Test mal die Vererbung auf einer OU und nehme diese Eintrage raus, dann ist alles genauso wie es sein soll.
Bleibt die große Frage wer hat da was gesetzt.
Trotzdem erstmal vielen Dank für die Hilfe ich muss jetzt mal schauen wie ich das bereinigt bekomme.
Das komische ist, dass ich nichts finden kann, welches diesen Fehler hervorruft.
Der User kann weiterhin browsen obwohl es die Gruppe im verbietet.
was kann denn da konfiguriert sein, was das auslösen kann? Es muss ja irgendwas "mächtigeres" darüber stehen, was das macht.
Der User kann weiterhin browsen obwohl es die Gruppe im verbietet.
was kann denn da konfiguriert sein, was das auslösen kann? Es muss ja irgendwas "mächtigeres" darüber stehen, was das macht.
Vergleiche mit einem Out of the Box System.
Das einzige was ich gefunden habe ist unter den ACL Berechtigungen im Reiter Überwachung.
Da sind die beiden default Werte nicht drin sondern 6 andere Weitere.
Wenn ich diese mal komplett lösche, dann geht es mit mal und meine Einstellungen greifen.
Aber unter "Überwachung"? Das setzt doch keine Berechtigungen oder?
Da sind die beiden default Werte nicht drin sondern 6 andere Weitere.
Wenn ich diese mal komplett lösche, dann geht es mit mal und meine Einstellungen greifen.
Aber unter "Überwachung"? Das setzt doch keine Berechtigungen oder?
Ich hatte schon geschrieben,
Das würde erklären.
Es sei denn, die ACL ist "korrupt"
Wenn man die Überwachung ändert, dann wird die ACL neu gespeichert. Dabei werden dann die Verweigern-ACE an der Spitze der ACL gespeichert. Und damit wirken sie wieder bevorzugt vor den Gewähren-ACE.Das würde erklären.
Ich hab den Fehler gefunden.
Also in der Echtumgebung schaut die OU Struktur so aus
Kunde 1
Benutzer
Kunde 2
Benutzer
Usw usw.
Wenn ich jetzt nicht möchte, dass Kunde 1 die User von Kunde 2 Finden kann, dann hätte ich jetzt ja auf die OU Kunde 2 meine Gruppe gesetzt, hätte die auf alles verweigern und auf vererben auf die unteren Objekte gesetzt und dann wäre das gut gewesen.
Das Funktioniert auch, wenn der Benutzer direkt unter Kunde 2 liegt, aber wenn der Benutzer in der OU Benutzer liegt wird er trotz Vererbung und allem gefunden.
Ich habe das dann auch mal in meiner "out of the Box" Domain nachgebaut. Wenn ich die Gruppe direkt auf die OU Benutzer setze unter Kunde 2 dann wird der jeweilige Benutzer auch nicht beim Browsen gefunden. Sobald ich die Gruppe aber wieder eine OU ebene höher setze wird er gleich wieder gefunden.
Und dabei ist es egal ob die Berechtigungen runtervererbt werden oder nicht.
Das darf doch aber so nicht sein oder?
Also in der Echtumgebung schaut die OU Struktur so aus
Kunde 1
Benutzer
Kunde 2
Benutzer
Usw usw.
Wenn ich jetzt nicht möchte, dass Kunde 1 die User von Kunde 2 Finden kann, dann hätte ich jetzt ja auf die OU Kunde 2 meine Gruppe gesetzt, hätte die auf alles verweigern und auf vererben auf die unteren Objekte gesetzt und dann wäre das gut gewesen.
Das Funktioniert auch, wenn der Benutzer direkt unter Kunde 2 liegt, aber wenn der Benutzer in der OU Benutzer liegt wird er trotz Vererbung und allem gefunden.
Ich habe das dann auch mal in meiner "out of the Box" Domain nachgebaut. Wenn ich die Gruppe direkt auf die OU Benutzer setze unter Kunde 2 dann wird der jeweilige Benutzer auch nicht beim Browsen gefunden. Sobald ich die Gruppe aber wieder eine OU ebene höher setze wird er gleich wieder gefunden.
Und dabei ist es egal ob die Berechtigungen runtervererbt werden oder nicht.
Das darf doch aber so nicht sein oder?
Eine These von mir:
So wie wir formulieren, so denken und - vor allem - verstehen wir auch das, was wir da ausdrücken wollen, bzw. auszudrücken versuchen.
Mit anderen Worten: Wenn man nicht in der Lage ist, etwas was klar und korrekt zu artikulieren, dann hat man es auch nicht verstanden.
Wenn ich Deinen Text korrekt "übersetzt" habe:
Du machst etwas falsch. Du gehst von falschen Annahmen aus. Mit beidem täuschst Du Dich dann selbst.
Entweder ist die ACL-Vererbung aktiv oder nicht. Entweder werden ACE vererbt oder nicht. Da braucht man nicht denken, sondern einfach nur nachschauen, was effektiv ist. Wenn Du also die ACL einer OU bearbeitet hast, mit dem Ziel, dass eine bestimmte ACE an bestimmte Objekte vererbt werden soll, dann kannst Du doch ganz einfach ein einem solchen Objekt exemplarisch überprüfen, ob die ACL dieses Objekts die betreffende ACE aus der ACL der übergeordneten OU tatsächlich so geerbt hat, wie Du es annimmst, dass es so sein müsste.
So wie wir formulieren, so denken und - vor allem - verstehen wir auch das, was wir da ausdrücken wollen, bzw. auszudrücken versuchen.
Mit anderen Worten: Wenn man nicht in der Lage ist, etwas was klar und korrekt zu artikulieren, dann hat man es auch nicht verstanden.
... dann hätte ich jetzt ja auf die OU Kunde 2 meine Gruppe gesetzt, hätte die auf alles verweigern und auf vererben auf die unteren Objekte gesetzt und dann wäre das gut gewesen.
Auf eine OU eine Gruppe setzen .... Ja, klar. Wer so denkt, kommt nicht weit. Sorry.Wenn ich Deinen Text korrekt "übersetzt" habe:
Du machst etwas falsch. Du gehst von falschen Annahmen aus. Mit beidem täuschst Du Dich dann selbst.
Entweder ist die ACL-Vererbung aktiv oder nicht. Entweder werden ACE vererbt oder nicht. Da braucht man nicht denken, sondern einfach nur nachschauen, was effektiv ist. Wenn Du also die ACL einer OU bearbeitet hast, mit dem Ziel, dass eine bestimmte ACE an bestimmte Objekte vererbt werden soll, dann kannst Du doch ganz einfach ein einem solchen Objekt exemplarisch überprüfen, ob die ACL dieses Objekts die betreffende ACE aus der ACL der übergeordneten OU tatsächlich so geerbt hat, wie Du es annimmst, dass es so sein müsste.
ja die Vererbung funktioniert auch, nur wenn du die Berechtigung von oben nach unten Vererbst und unten per Default aber die Gruppe "Authentifizierte Benutzer" mit Leserechten drin steht, dann kommt genau das dabei raus, was ich versuche zu schildern.
Nein, bei mir nicht.
ja die Vererbung funktioniert auch,
Wie hast Du das überprüft?
