Einzelnen User über LDAP beschränken

[zahni 554]

Hi,

 

ich versuche gerade  verzweifelt einen einzelnen User im AD so zu beschränken. dass er nur  Objekte  und deren Properties in einer  OU auflisten darf.

Über  das Recht  "Verweigern"  im AD  auf  der  höchsten Ebene  komme ich irgendwie  nicht  weiter. Er listet mir dann zwar  unter DC=DOMAIN  keine Objekte auf, nehme ich aber eine beliebige OU  (OU=meine OU,DC=Domain)  klappt es wieder. Das AD  wurde ursprünglich unter 200 erstellt. Der Funktion Level steht z.Z. auf 2008. Mit  LDP getestet.

 

Ist ein wenig Neuland für mich. Vielleicht kann mit ein  AD-Spezi hier mal auf die Sprünge helfen.

 

Danke Euch im Voraus.

 

-Zahni

[NilsK 2.958]

Moin,

 

das ist auch alles andere als trivial ...

 

Du hast es an der Stelle schon mit stark erweiterten Anforderungen an die Berechtigungen zu tun. Einen User derart stark in seinen Berechtigungen einzuschränken, ist möglich, aber sehr aufwändig. Du bewegst dich damit außerdem schnell in einem Bereich, der nicht oder "nicht mehr richtig" durch Microsoft supportet werden wird.

 

Mit Verweigerungen solltest du nicht arbeiten, weil dadurch schnell unkontrollierbare Situationen entstehen. Das gilt nicht nur im AD, sondern für alle Berechtigungen.

 

Du benötigst für sowas viel Zeit, eine separierte Laborumgebung, grundlegende Scripting-Kenntnisse (niemals manuell einstellen, nur per dsacls) und ein Werkzeug, das dir die Berechtigungen sinnvoll anzeigt (z.B. LIZA von Philipp Föckeler).

 

[Liza: Berechtigungen in Active Directory analysieren | faq-o-matic.net]
http://www.faq-o-matic.net/2010/04/06/liza-berechtigungen-in-active-directory-analysieren/

 

[ice:2010 AD-Delegation – die Folien und Skripts | faq-o-matic.net]
http://www.faq-o-matic.net/2010/08/14/ice2010-ad-delegation-die-folien-und-skripts/

 

[berechtigungen in Active Directory dokumentieren | faq-o-matic.net]
http://www.faq-o-matic.net/2013/05/27/berechtigungen-in-active-directory-dokumentieren/

 

[AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net]
http://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/

 

Gruß, Nils

[daabm 1.366]

Als Ergänzung zu Nils: "List Object Mode" könnte Dein Problem lösen, ist aber eine globale AD-Einstellung in den dsHeuristics. Alternativ überall AuthUsers rauswerfen und auch "Prä-Windows 2000-kompatibler Zugriff" leeren.

Alles nicht so ganz trivial :)

 

(Wir bauen das grad für unsere Kunden - das Fachkonzept hat schon 180 Seiten...)

[zahni 554]

Ich danke Euch. Nein, an den Default-Setting wollen wir nicht rumschrauben. Eigentlich soll auch nur eine ganz bestimmte Anforderung umgesetzt werden:

Das Konto soll nur einen bestimmen Teil das AD einsehen können, da es von einem externen Dienstleister verwendet wird.

 

Wenn es nicht "einfach" geht, dann lassen wir es.

[daabm 1.366]

Zahni, "List Object Mode" gibt es schon seit W2K als Alternative zu "List Content". Und supported ist es auch - "rumschrauben" ist da das falsche Wort :) Bedeutet halt eine gründliche Planung der ACLs.

[zahni 554]

Wir schauen mal. Ich bin mir nur nicht sicher, ob das konkrete Problem den Aufwand rechtfertigt. Mein Kollege kann das ja mal in seiner Testumgebung mal testen.

[Doso 77]

Deine Anforderung ist sehr komplex und nicht "eben so" umsetzbar, der Teufel steckt hier im Detail. Selbst wenn er in eine OU nicht rein kommt, die Objekte darunter kann er u.U. dann doch wieder lesen.

 

Bei der Erstellung eines Nutzerobjeks im AD erhalten automatisch alle anderen Nutzer Leserechte auf einen Teil seiner Attribute. Das wird nicht vererbt, das wird automatisch explizit am Benutzerobjekt angegeben. Wir hatten die Vorgabe das bei einer OU unbedingt zu verhindern, das Nutzer diese Infos auslesen können. Wir synchronisieren Daten aus einem anderen Verzeichnisdienst, geht leider nicht anders.

 

Das ging letztlich nur über eine Änderung im AD Schema (gefährlich) und durch manuelles setzen von Berechtigungen auf diese OU. Es funktioniert, aber ob das noch von MS supported ist, wage ich zu bezweifeln. Habe es halt gut dokumentiert, aber was muss das muss.

[NilsK 2.958]

Moin,

 

also, sagen wir es kurz: "einfach" ist das nicht zu haben.

 

Wenn man eine "harte" Anforderung hat, kriegt man das hin. Dann muss man aber realistisch noch an -zig andere Ecken ran, aus denen ein "nicht vertrauenwürdiger Externer" tiefen Einblick in das Netzwerk nehmen könnte: neben Exchange gibt es ja auch noch andere Applikationen, die Daten aus dem AD per Proxykonto abgreifen ...

 

Gruß, Nils

[daabm 1.366]

Bei der Erstellung eines Nutzerobjeks im AD erhalten automatisch alle anderen Nutzer Leserechte auf einen Teil seiner Attribute. Das wird nicht vererbt, das wird automatisch explizit am Benutzerobjekt angegeben.

Genau dafür entfernen wir AuthUsers aus dem Default-SD relevanter Klassen, und List Object Mode sorgt dafür, daß das Traversal Checking aktiviert wird - hat er "oben" keine Rechte, sieht er auch "unten" nichts mehr :)

[zahni 554]

Wir haben und entschieden das so zu lassen wie es ist.

So "extern" ist der DL auch wieder nicht (es der DL unserer "Mutter").

 

Haben trotzdem Danke an Alle für die Hilfe. Ich habe durchaus was dazugelernt :D

bearbeitet 25. März 2015 von zahni

[daabm 1.366]

Eure Mutter? (Blödsinn wieder gelöscht....)

bearbeitet 25. März 2015 von daabm

[zahni 554]

Oder Papa..