AD Attribute rechten op Windows 2008 R2 DC

[X-DraGoN]

Wij hebben ons AD schema uitgebreid met aan nieuw attribuut genaamd 'PARTYID'. Dit zal later gebruikt worden voor automatisch rechten toe te kennen in een applicatie (die nog in ontwikkeling is). Omdat er zoveel gebruikers zijn willen we het invullen van de 'PARTYID' automatiseren en daarvoor willen we een service account gebruiken die zo min mogelijk rechten heeft, maw alleen rechten heeft om dat specifiek attribuut uit te lezen en aan te passen.
De te volgen procedure om dit op te stellen zou het volgende zijn:
ADSI edit gebruiken, naar de OU gaan waar alle gebruikers in zitten, rechts op klikken en properties opvragen.
Daarin kan je naar "Advanced" gaan en daar kies je voor "add", hier geef je dan mee welke service account je wilt gebruiken (bv. sa_partyid). Dan kan je de permissions gaan instellen, maar hier wordt het dus moeilijk, het "apply to" dropdown menuutje heeft zoveel entries dat ik door de bomen het bos niet meer zie. Bij de standaard geselecteerde "This object and all descendant Objects" vind je onze 'PARTYID' niet terug.

----------

Terwijl ik deze tekst aan het schrijven ben heb ik het antwoord reeds gevonden, blijkbaar is de allerlaatste optie in bovengenoemde dropdown menu "Descendant User Objects" en als je deze selecteert dan staat onze PARTYID er wél tussen.

Probleem opgelost dus!

[Question Mark]

Even nieuwsgierig, maar waarom gebruik je een zelf gedefineerd attribuut in je AD, en niet gewoon een groep om rechten uit te delen?

[redfoxert]

En als je het dan al op deze manier doet, waarom dan niet met een PowerShell script dat die waarde in AD wegschrijft?

[X-DraGoN]

redfoxert schreef op woensdag 18 september 2013 @ 08:56:
En als je het dan al op deze manier doet, waarom dan niet met een PowerShell script dat die waarde in AD wegschrijft?

Omdat diegene die dat programma wilt schrijven om te automatiseren geen ervaring heeft met Powershell en wel met .net (ik zelf ook nog niet)

en @ Question Mark: dat heb ik me nooit afgevraagd, management zei van het zo te doen

[Question Mark]

X-DraGoN schreef op woensdag 18 september 2013 @ 09:30:
[...]
en @ Question Mark: dat heb ik me nooit afgevraagd, management zei van het zo te doen

Management moet zich niet bemoeien met techniek.... punt...

Bij de eerstvolgende domeinmigratie of upgrade ga je hier ongetwijfeld tegenaan lopen... Je zult nu na elke schema-update moeten testen of je custom attribute niet opeens vernaggeld is...

[Semt-x]

Laat het management die technische keuze vooral vastleggen. Zodat ze over 5 jaar aan de domein migratie offerte kunnen zien wat deze keuze kost. (die prijs is exclusief de extra beheerinspanning gedurende het gebruik)
Het vormt voor mij de meest voorkomende reden om een AD migratie project te starten, ipv een simple upgrade. Dus zie jullie graag over een jaar of 5 als klant ;-)

[redfoxert]

X-DraGoN schreef op woensdag 18 september 2013 @ 09:30:
[...]


Omdat diegene die dat programma wilt schrijven om te automatiseren geen ervaring heeft met Powershell en wel met .net (ik zelf ook nog niet)

Powershell, .NET, VBscript ... maakt toch geen drol uit. De methode die je nu beschrijft is het handmatig aanpassen van een waarde. Als je dat automagisch kan laten doen door eender welke methode is het prima. Geen kennis van PowerShell is imo geen reden om niet met PowerShell te scripten. Voldoende voorbeelden op internet te vinden voor het aanpassen van (custom) AD attributes