Stageopdracht security Geautomatiseerde Active Directory OTAP‑documentatie

Yunex Traffic; Randstad; Hybrid; EUR 11,000 - 16,000; Part time

Job summary

Yunex Traffic zoekt een stagiair die AD/OTAP-omgevingdata automatiseert en documenteert. Je bouwt een pipeline die AD/OTAP-gegevens ophaalt, normaliseert en vergelijkt met referentiegegevens en publiceert als Markdown in Azure DevOps Wiki.

Je leert PowerShell-scripts, GPO-beleid en WMI-koppelingen te gebruiken, met logging en dry-run. Start februari 2027; gericht op beheer en audit.

Qualifications

• Kennis van OTAP-omgevingen en AD-structuur.
• Ervaring met het opstellen van documentatie en auditsporen.
• Affiniteit met DevOps-workflows en scripting.

Responsibilities

• Onttrekken en normaliseren van AD/OTAP-gegevens met PowerShell.
• Vergelijken tegen referentieomgevingen en rapporteren afwijkingen.
• Publiceren van resultaten als Markdown in Azure DevOps Wiki.

Skills

AD/OTAP data

Pipeline automation

Documentation

Audit support

Tools

PowerShell

Azure DevOps Wiki

GPO

WMI

Job description

Location:
Zoetermeer, NL, 2712 PN
Type of Employment: Hybrid - Full-time or Part-time
Career Level: Internship
Job Family: Engineering
Date posted: Sep 2, 2026

Geautomatiseerde Active Directory OTAP‑documentatie, driftcontrole en gecontroleerde synchronisatie via Azure DevOps Wiki

Documenttype: Opdrachtomschrijving / werkpakket

Doelgroep: Projectleider, systeembeheer, security, audit en beheerorganisatie

Scope: Active Directory, GPO, groepen, OU‑structuur en relevante delegaties binnen OTAP‑omgevingen

START FEBRUARI 2027 (september 2026 is niet meer mogelijk)

Aanleiding

Binnen de beheeromgeving bestaan meerdere Active Directory‑omgevingen met OTAP‑lagen. Per omgeving kunnen objecten zoals OU’s, groepen, groepsleden, GPO’s en GPO‑links handmatig of via beheeracties wijzigen. Hierdoor kan configuratiedrift ontstaan: Ontwikkel-, Test-, Acceptatie- en Productieomgevingen zijn dan niet meer gelijk ingericht, terwijl dit voor beheerbaarheid, reproduceerbaarheid en aantoonbaarheid juist gewenst is.

De wens is om deze drift automatisch zichtbaar te maken en de actuele gegevens centraal te publiceren in Azure DevOps Wiki. Waar afwijkingen ongewenst zijn, moet de oplossing ondersteunen bij het herstellen of synchroniseren van de verschillen.

Doel van de opdracht

Het doel is het realiseren van een geautomatiseerde pipeline die Active Directory‑data uit de OTAP‑omgevingen periodiek ophaalt, normaliseert, vergelijkt en publiceert als leesbare documentatie in Azure DevOps Wiki. Daarnaast moet de oplossing afwijkingen detecteren en rapporteren, met de mogelijkheid om verschillen gecontroleerd te herstellen volgens een vooraf vastgestelde veranderprocedure.

Functionele scope

• Organizational Units (OU’s), inclusief hiërarchie en beschrijving.
• Security groups en distributiegroepen.
• Groepslidmaatschappen, inclusief geneste groepen.
• Group Policy Objects (GPO’s), inclusief naam, status, eigenaar en relevante metadata.
• GPO‑links op domein-, site- en OU‑niveau, inclusief linkvolgorde en enforcement‑status.
• WMI‑filters en de koppeling tussen WMI‑filter en GPO.
• Service‑accounts en beheeraccounts binnen de afgesproken scope.
• Delegaties en relevante rechten op OU’s, GPO’s en groepen.
• Verschillen tussen OTAP‑lagen en/of tussen twee OTAP‑omgevingssets.

Omgevingsmodel

De opdracht gaat uit van OTAP‑lagen. Indien er twee omgevingssets aanwezig zijn, wordt per set dezelfde werkwijze toegepast. Per set moeten de lagen onderling vergelijkbaar zijn, tenzij er bewust en gedocumenteerd verschil is toegestaan.

Ontwikkeling (O): vroegtijdig signaleren van inrichting en wijzigingen.
Test (T): valideren of wijzigingen reproduceerbaar zijn.
Acceptatie (A): laatste controle vóór productie.
Productie (P): referentie of gecontroleerde doelomgeving.

De referentieomgeving moet vooraf worden afgesproken. De pipeline moet beide werkwijzen kunnen ondersteunen via configuratie.

Gewenste werkwijze

De oplossing werkt volgens een vaste cyclus: uitlezen, normaliseren, vergelijken, rapporteren en eventueel herstellen.

• Uitlezen: PowerShell haalt AD‑ en GPO‑data op uit elke OTAP‑laag.
• Normaliseren: Omgevingsspecifieke waarden worden gefilterd of gemarkeerd.
• Vergelijken: Objecten, attributen, links en lidmaatschappen worden vergeleken met de referentie.
• Publiceren: Resultaten worden gepubliceerd naar Azure DevOps Wiki in Markdown.
• Herstellen: Afwijkingen worden optioneel via gecontroleerde scripts hersteld.

Azure DevOps‑inrichting

• Repository voor scripts, configuratiebestanden, templates en uitzonderingenlijst.
• Pipeline voor periodieke en handmatige uitvoering.
• Wiki‑pagina’s voor actuele AD‑documentatie per omgeving en objecttype.
• Driftpagina met samenvatting van verschillen.
• Historie via Git‑commits.
• Pipelinevariabelen of secure variables voor verbindingen en credentials.

Rapportage in de Wiki

De Wiki moet een bruikbare beheer- en auditrapportage zijn.

• Dashboard: samenvatting van laatste pipeline‑run, status per OTAP‑laag, aantal afwijkingen.
• OU‑structuur: boomstructuur per omgeving, inclusief verschillen.
• Groepen: overzicht van groepen, leden, nesting en verschillen.
• GPO’s: overzicht van GPO’s, links, status, WMI‑filters en afwijkingen.
• Driftrapport: concrete verschillen tussen omgevingen.
• Uitzonderingen: bewust toegestane verschillen met reden, eigenaar en datum.

Synchronisatie en herstel

Herstel gebeurt gecontroleerd. Automatisch herstellen is alleen toegestaan voor objecten die als veilig zijn geclassificeerd.

• Detectie van ontbrekende, extra of afwijkende objecten.
• Genereren van herstelacties als PowerShell‑voorstel of pull request.
• Dry‑run mechanisme.
• Geen directe verwijderingen zonder goedkeuring.
• Logging van alle herstelacties.
• Productie‑aanpassingen verlopen via changeproces.

Niet‑functionele eisen

• Herleidbaarheid: elke pipeline‑run moet herleidbaar zijn.
• Veiligheid: credentials via secure storage.
• Least privilege: minimale benodigde rechten.
• Leesbaarheid: Wiki‑output moet begrijpelijk zijn.
• Reproduceerbaarheid: dezelfde input → dezelfde output.
• Auditbaarheid: verschillen en herstelacties moeten aantoonbaar zijn.

Acceptatiecriteria

• AD‑ en GPO‑data uit alle OTAP‑lagen kan worden uitgelezen.
• De Wiki automatisch wordt gevuld met actuele documentatie.
• Verschillen duidelijk zichtbaar zijn in een driftrapport.
• Bewust toegestane verschillen niet als fout worden gerapporteerd.
• Er een dry‑run mechanisme is.
• Herstelacties reproduceerbaar en gelogd zijn.
• De pipeline handmatig en periodiek uitvoerbaar is.
• Scripts en configuratie in versiebeheer staan.
• Er beheerdocumentatie aanwezig is.

Deliverables

• Azure DevOps repository: scripts, configuratie, templates, README.
• Pipeline: YAML‑pipeline voor periodieke en handmatige uitvoering.
• AD‑exportmodule: PowerShell‑module voor uitlezen van AD‑objecten.
• Compare‑module: logica voor driftanalyse.
• Wiki‑generator: Markdown‑output.
• Herstelvoorstellen: scripts of rapportage met synchronisatieacties.
• Beheerdocumentatie: uitleg voor draaien, aanpassen en troubleshooten.

Randvoorwaarden

• Netwerktoegang vanaf pipeline‑runner naar domeincontrollers.
• Benodigde PowerShell‑modules beschikbaar.
• Serviceaccount of managed identity met voldoende rechten.
• Afgesproken referentieomgeving per objecttype.
• Lijst met bewust toegestane verschillen.
• Changeproces voor wijzigingen richting Acceptatie en Productie.

Buiten scope

• Automatisch verwijderen in Productie zonder goedkeuring.
• Functionele beoordeling van GPO‑instellingen.
• Vervangen van bestaande change‑ en releaseprocessen.
• Volledige IAM‑governance.
• Real‑time synchronisatie.

Samenvatting

De Azure DevOps‑pipeline haalt actuele AD‑data op, zet deze om naar duidelijke Wiki‑documentatie en maakt afwijkingen zichtbaar. Afwijkingen kunnen gecontroleerd worden hersteld, waardoor OTAP‑omgevingen aantoonbaar gelijk blijven of bewust afwijken. Dit vormt één centrale plek voor beheer, audit en projectoverdracht: actueel, reproduceerbaar en aantoonbaar.