[AD] Probleem met Delegation

[Verwijderd]

OS: Windows 2003
Client: w2k en wXP

---

Binnen de AD maken wij gebruik van vastgestelde groepen, dit zijn groepen achter een specifieke OU waar maar een paar personen wijzigingen in aan kunnen brengen. Resterende gebruikers moeten deze groepen wel kunnen inzien.

Het probleem!

Doordat de gebruikers, die geen wijzigingen mogen aanbrengen, de groep wel mogen zien hebben ze het recht om groepen (uit een andere OU waarop ze wel rechten hebben) aan deze groep te hangen. En dit wil ik dus niet omdat ze niks mogen wijzigen aan deze vastgestelde groep (dus ook geen Member Of).

Ik heb al geprobeerd om de Schrijfrechten op alle Groepsobjecten te weigeren maar ook dit helpt niet.

Wie o wie kan mij op weg helpen.

[ Voor 3% gewijzigd door Verwijderd op 23-02-2007 12:31 ]

[Verwijderd]

ff kijken of ik je volg:

User A heeft rechten om groep A te wijzigen in OU A.
User B heeft rechten om groep B te wijzigen in OU B.

volgens jou kan user B group A ook wijzigen?

User B kan natuurlijk wel groep A toevoegen aan groep B (daar heb je hem immers rechten toe gegeven), volgens mij kan het niet andersom! Oftewel Group A wordt niet gewijzigd (member of) maar groep B wordt nog steeds gewijzigd (members).

[ Voor 55% gewijzigd door Verwijderd op 23-02-2007 12:48 ]

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 12:26:


Ik heb al geprobeerd om de Schrijfrechten op alle Groepsobjecten te weigeren maar ook dit helpt niet.

Wie o wie kan mij op weg helpen.

Kun je dan ook zien dat de groepen in hun ACL's die settings overgenomen hebben?
Zoniet, probeer dan eens op de groepobjecten zelf de ACL te editen.

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 12:33:
ff kijken of ik je volg:

User A heeft rechten om groep A te wijzigen in OU A.
User B heeft rechten om groep B te wijzigen in OU B.

volgens jou kan user B group A ook wijzigen?

User B kan natuurlijk wel groep A toevoegen aan groep B (daar heb je hem immers rechten toe gegeven), volgens mij kan het niet andersom! Oftewel Group A wordt niet gewijzigd (member of) maar groep B wordt nog steeds gewijzigd (members).

Samengevat:

User A heeft rechten om groep A te wijzigen in OU A maar B mag deze inzien.
User B heeft rechten om groep B te wijzigen in OU B

B kan kan een groep uit OU B aan groep A hangen. Dat wil ik niet!

bierliefhebber: Delegatie is op de betreffende groep gezet!

[ Voor 4% gewijzigd door Verwijderd op 23-02-2007 12:41 ]

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 12:40:
[...]
User A heeft rechten om groep A te wijzigen in OU A maar B mag deze inzien.
User B heeft rechten om groep B te wijzigen in OU B

B kan kan een groep uit OU B aan groep A hangen. Dat wil ik niet!

bierliefhebber: Delegatie is op de betreffende groep gezet!

elke user mag elke groep inzien. dus ik snap dat probleem niet zo. tik maar eens net group "domain admins" /domain als normale user...

Volgens jou kan user B een de groep B toevoegen aan groep A door de "member of" te wijzigen? Het lijkt me sterk dat dat zou kunnen als je je delegaties goed hebt gezet, maar ik zou het even moeten testen

edit: ik hoef het niet te testen eigenlijk. Als dat zou kunnen zou iemand die het rechten heeft een groep te wijzigen zichzelf ook admin kunnen maken. Er staat gewoon iets niet goed bij je delegaties...

[ Voor 12% gewijzigd door Verwijderd op 23-02-2007 12:50 ]

[Verwijderd]

Heb net een test uitgevoerd en mij lukt het niet als gebruiker met leesrechten zaken te wijzigen mbt groepslidmaatschap waar ik alleen read heb. Heb niet de delegationwizzard gebruikt maar simpel op parentnivo de groep toegevoegd die mag kijken en niet veranderen en dat ingesteld op "this object and all childobjects". No way dat als ik aanlog als lid van de groep die mag koekeloeren dat ik in staat ben om iets te veranderen aan de groepen in die OU. Maar dit lukte me niet met de wizzard.

De logica is volgens mij dat delegation of control bedoelt is om taken te delegeren en niet om te koekeloeren.

[ Voor 15% gewijzigd door Verwijderd op 23-02-2007 13:30 ]

[mutsje]

wat snap je niet aan read only? want dat is toch echt alleen read only

[Verwijderd]

mutsje schreef op vrijdag 23 februari 2007 @ 13:21:
wat snap je niet aan read only? want dat is toch echt alleen read only

Is dit aan mij gericht?

[Verwijderd]

Mmm vreemd, ik denk dat er dan toch structureel iets mis is. Ik heb op de OU nu een delegatie gezet en de objecten erven deze rechten, daarnaast krijgen de groepen ook extra (standaard) rechten toegewezen. Dit wil ik eigenlijk ook niet, ik wil alleen de betreffende OU rechten hebben. maar dat terzijde.

Daarnaast kan gebruiker B nog steeds een groep aan A hangen. Ik weet zeker dat de delegatie op de groep goed is ingesteld. Een voorbeeldje:

Ik heb een gebruiker 'test' toegevoegd aan de beveiliging (alleen lezen) van 'groep A' in 'OU A'. 'Test' is verder geen lid van andere groepen. Als extra alle schrijfrechten nog eens geweigerd.

Daarnaast dezelfde gebruiker 'test' lid gemaakt van een 'groep B' in 'OU B'. Deze 'groep B' mag hij wel wijzigen.

Toch mag hij nog steeds 'Groep B' aan 'groep A' hangen (via lid van).


Het lijkt wel of er alleen naar de delegaties van OU B wordt gekeken.
Mmmm, snap er niks van

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 13:02:
Heb net een test uitgevoerd en mij lukt het niet als gebruiker met leesrechten zaken te wijzigen mbt groepslidmaatschap waar ik alleen read heb. Heb niet de delegationwizzard gebruikt maar simpel op parentnivo de groep toegevoegd die mag kijken en niet veranderen en dat ingesteld op "this object and all childobjects". No way dat als ik aanlog als lid van de groep die mag koekeloeren dat ik in staat ben om iets te veranderen aan de groepen in die OU. Maar dit lukte me niet met de wizzard.

De logica is volgens mij dat delegation of control bedoelt is om taken te delegeren en niet om te koekeloeren.

Heb je wel geprobeerd een groep toe te voegen waarop de gebruiker schrijfrechten heeft.

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 13:33:
[...]


Heb je wel geprobeerd een groep toe te voegen waarop de gebruiker schrijfrechten heeft.

Ja, en dat lukt. Wat echter niet lukt is om die groep weer lid te maken van een groep waar ik alleen read heb. Wel kan ik groepen waar ik read op heb toevoegen aan de groep waar ik write op heb.

Ik zou er ook gek van worden hoor!!

[ Voor 4% gewijzigd door Verwijderd op 23-02-2007 13:44 ]

[Verwijderd]

Verwijderd schreef op vrijdag 23 februari 2007 @ 13:43:
[...]


Ja, en dat lukt. Wat echter niet lukt is om die groep weer lid te maken van een groep waar ik alleen read heb. Wel kan ik groepen waar ik read op heb toevoegen aan de groep waar ik write op heb.

Ik zou er ook gek van worden hoor!!

Wat bedoel je met ja, en dat lukt. Dat het lukt om een groep aan een readgroep te hangen? Oftewel heb je dan hetzelfde probleem als ik beschrijf of werkt het bij jou wel goed?

[Verwijderd]

Nee, aan een writegroep. Dus, Ik kan een groep waar ik write op heb een groep toevoegen waar ik read op heb. Andersom niet.

[Verwijderd]

Tsja dat is dus een AD eigenschap. Maar eens kijken hoe ik dat op ga lossen.

[sanfranjake]

Je hebt binnen AD onder advanced permissions als je klikt op Apply onto group objects

Write Members
Write memberOf

Normaal ben ik geen fan van deny-permissies, je zou van bovenaf de rechten aan kunnen pakken. Maar als het echt niet anders kan is het misschien een oplossing...

[Verwijderd]

sanfranjake schreef op zondag 25 februari 2007 @ 11:07:
Je hebt binnen AD onder advanced permissions als je klikt op Apply onto group objects

Write Members
Write memberOf

Normaal ben ik geen fan van deny-permissies, je zou van bovenaf de rechten aan kunnen pakken. Maar als het echt niet anders kan is het misschien een oplossing...

Dit had ik al geprobeerd, zie eerste post (... Ik heb al geprobeerd om de Schrijfrechten op alle
Groepsobjecten te weigeren maar ook dit helpt niet ... )

Het lijkt er op dat er alleen gekeken wordt naar de rechten van groep B en niet naar de rechten van groep A

[Verwijderd]

volgens mij heeft bierliefhebber je de oplossing al aangedragen. Niet de wizzard gebruiken...

[Verwijderd]

Verwijderd schreef op dinsdag 27 februari 2007 @ 13:57:
volgens mij heeft bierliefhebber je de oplossing al aangedragen. Niet de wizzard gebruiken...

Deze gebruik ik toch helemaal niet . Ik verwijder alle rechten van het groepsobject en voeg mijn testgebruiker toe en deze geef ik lees-rechten + deny alle Groeps-object schrijfrechten (waaronder dus ook memberOF)!

Toch kan ik nog steeds met deze testgebruiker een groep toevoegen (Member OF) waarop deze gebruiker wel rechten heeft.

[Verwijderd]

mja, dat bierliefhebber het wel voor elkaar krijgt en jij niet, geeft mij alleen maar de info dat jij iets niet goed doet. No offense, just an observation

member of property zou ook met het recht om groepen te wijzigen niet uitgegeven moeten worden, aangezien je dan jezelf aan de groep kan toevoegen en die groep member of kan maken van de domain admin groep. Iets wat natuurlijk totaal tegen het security model van microsoft ingaat. Ik kan me dan ook niets anders voorstellen dat jij ergens een fout maakt.

Als ik jou was zou ik alle rechten weghalen (voor die delegatie groepen) en kijken wat je dan kan wijzigen. Is dat niets meer, dan opnieuw stap voor stap de rechten zetten en telkens testen wat je wel en niet kan.

[Verwijderd]

Verwijderd schreef op dinsdag 27 februari 2007 @ 15:31:
mja, dat bierliefhebber het wel voor elkaar krijgt en jij niet, geeft mij alleen maar de info dat jij iets niet goed doet. No offense, just an observation

member of property zou ook met het recht om groepen te wijzigen niet uitgegeven moeten worden, aangezien je dan jezelf aan de groep kan toevoegen en die groep member of kan maken van de domain admin groep. Iets wat natuurlijk totaal tegen het security model van microsoft ingaat. Ik kan me dan ook niets anders voorstellen dat jij ergens een fout maakt.

Als ik jou was zou ik alle rechten weghalen (voor die delegatie groepen) en kijken wat je dan kan wijzigen. Is dat niets meer, dan opnieuw stap voor stap de rechten zetten en telkens testen wat je wel en niet kan.

Er staat helemaal nergens dat Bierliefhebber het wel voor elkaar heeft gekregen, lees hieronder ...

Ja, en dat lukt. Wat echter niet lukt is om die groep weer lid te maken van een groep waar ik alleen read heb. Wel kan ik groepen waar ik read op heb toevoegen aan de groep waar ik write op heb.

Doordat hij de groepen waar hij read op heeft nog steeds toe kan voegen aan de groep waar hij write op heeft, simuleert hij hetzelfde probleem als ik heb.

[Verwijderd]

[Doordat hij de groepen waar hij read op heeft nog steeds toe kan voegen aan de groep waar hij write op heeft, simuleert hij hetzelfde probleem als ik heb.

ummm da's gewoon de werking van delegatie en precies zoals het hoort te werken.

Je mag een groep editen, dus je mag er groepen aan toevoegen (members).

Echter hij kan niet bij een groep waar hij write heeft, de wijzigen zodat de write groep lid wordt van de read groep! (member of)

[Verwijderd]

Je stelt dus dat een clubje in staat is om een groep waar zij write op hebben kunnen toevoegen aan een club waar ze alleen maar read op hebben. Dat kan gewoon echt niet! Het gaat geheel tegen de idee achter security in. Als ik dat zou meemaken zou ik helemaal gek worden!!

Als ik jou was zou ik een een OU struktuur maken buiten alle anderen bij wijze van test om te zien of je het daar wel voor elkaar krijgt.

[ Voor 95% gewijzigd door Verwijderd op 28-02-2007 07:02 ]