GPO: Deny Loggen Op As Een Service

Aanvallers die een domeinbeheerder compromitteren, zetten vaak een service in om persistente toegang te behouden; door deze accounts expliciet uit te sluiten van het recht om als service in te loggen, verdwijnt deze route voor privilege-escalatie en blijft de beheerlaag beschermd.

Implementatie

Deze configuratie kent alleen specifieke serviceaccounts het recht toe om als service te draaien, terwijl groepen zoals Domain Admins, Enterprise Admins en Guests bewust worden geweerd zodat zij geen services kunnen aanmaken of starten.

Vereisten

Een effectieve uitrol van het beleid om serviceaanmeldingen te blokkeren voor hooggeprivilegieerde accounts begint met een gedetailleerd overzicht van de Active Directory-structuur en de onderliggende beheerprocessen. De beheerder moet weten in welke OU’s werkstations, servers, jump hosts en beheerde leverancierssystemen zich bevinden, welke security filtering wordt toegepast en welke GPO’s elkaar mogelijk beïnvloeden. Alleen wanneer deze basisinformatie actueel is en centraal wordt gedocumenteerd in een architectuurhandboek, kan de organisatie aantonen dat het beleid consistent en reproduceerbaar wordt ingezet binnen de Nederlandse Baseline voor Veilige Cloud. Dit betekent dat zowel de enterprise architect als de CISO inzicht heeft in de technische scope, dat wijzigingen in OU-structuren tijdig worden gecommuniceerd en dat er een duidelijke koppeling bestaat met de segmentatieprincipes uit de BIO en het Rijksbrede Normenkader. Zonder deze overzichtelijkheid ontstaan er al snel grijze gebieden waarin systemen buiten de maatregel vallen en blijft het risico op privilege-escalatie bestaan.

Het tweede fundament is een volwassen serviceaccountstrategie. Elke applicatie die als Windows-service draait, dient gebruik te maken van een dedicated, minimaal geprivilegieerd account dat niet tot Domain Admins of andere Tier-0-rollen behoort. Deze accounts worden beheerd via een wachtwoordkluis of PAM-oplossing, kennen een verplicht rotatieschema, zijn onderworpen aan periodieke recertificatie en koppelen aan een applicatie-eigenaar die verantwoordelijk is voor lifecycle-management. De beheerorganisatie documenteert welke rechten elk serviceaccount bezit, hoe deze accounts worden aangemaakt, hoe lang ze geldig blijven en via welk proces de toegang wordt beëindigd. Zonder deze scheiding zouden beheerders alsnog eigen accounts gebruiken voor service-installaties, waarmee het volledige beveiligingsdoel wordt ondergraven en auditors geen sluitende keten van autorisatie kunnen reconstrueren.

Daarnaast zijn concrete technische basisvoorwaarden vereist: endpoints moeten draaien op ondersteunde Windows 10-, Windows 11- of recente Windows Server-versies en beschikken over de meest recente cumulative updates. Replicatie tussen domeincontrollers dient gezond te zijn, zodat de wijziging in het gebruikersrechtenbeleid binnen minuten overal actief is en niet vertraagd raakt door convergentieproblemen. Organisaties die Microsoft Intune, Configuration Manager, Ivanti of andere endpointbeheersystemen inzetten, moeten de interactie tussen deze platformen en de GPO expliciet testen om raceconditions en policy-flapping te vermijden. Ook is het noodzakelijk dat auditing op het aanmeldingsrecht al is ingeschakeld, zodat wijzigingen in de beveiligingsinstellingen onmiddellijk zichtbaar worden in zowel Event Viewer als het centrale SIEM-platform.

Tot slot vraagt deze maatregel om een integraal governanceproces. Het changeproces moet eisen dat elke wijziging in de lijst van geweigerde groepen wordt voorgelegd aan zowel security als operations, inclusief een risicoanalyse, een uitgewerkt testplan en een rollbackscenario dat in onder tien minuten kan worden uitgevoerd. Applicatie-eigenaren ontvangen vooraf communicatiemateriaal over mogelijke impact, servicedesks krijgen handelingsperspectief voor incidenten waarin een service niet meer start, en auditors krijgen toegang tot logging en bewijsstukken in het centrale dossier. Wanneer deze organisatorische randvoorwaarden zijn ingevuld en de betrokken teams hierin getraind zijn, ontstaat een solide basis om de configuratie zonder verrassingen uit te rollen en actief te onderhouden.

Een laatste vereiste betreft resourcing en volwassenheid in documentatie. Er moet tijd zijn voor periodieke reviews van de uitzonderingslijsten, voor actualisatie van architectuurdocumenten en voor het bijwerken van runbooks die door incidentrespons worden gebruikt. De organisatie stelt duidelijke KPI’s vast, zoals het aantal systemen waarop het beleid succesvol is toegepast, het aantal openstaande uitzonderingen en de maximale doorlooptijd voor autorisatie. Door deze randvoorwaarden op te nemen in zowel de security roadmap als het jaarplan van de beheerafdeling, wordt het beleid niet gezien als een eenmalige actie, maar als een structureel onderdeel van de besturing van de digitale weerbaarheid.

Implementatie

Gebruik PowerShell-script deny-logon-as-service.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie start met het creëren of bijwerken van een doelgericht Group Policy Object waarin duidelijk wordt beschreven dat dit beleid het aanmeldingsrecht voor services beperkt tot gecontroleerde accounts. Binnen Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment wordt de instelling "Deny log on as a service" geopend en worden hooggeprivilegieerde groepen zoals Domain Admins, Enterprise Admins, Schema Admins, lokale administrators en gasten expliciet toegevoegd. Om misconfiguraties te voorkomen, worden de groepen via hun SID’s vastgelegd; het meegeleverde PowerShell-script voert deze stap geautomatiseerd uit en controleert gelijk of er geen dubbele entries of ontbrekende SID’s zijn. Elke aanpassing wordt gelogd in het change-register en voorzien van een korte risicoafweging, zodat later exact kan worden aangetoond wat er is gewijzigd en waarom dat noodzakelijk was.

Vervolgens wordt de scope zorgvuldig gekozen. Het GPO wordt gelinkt aan OU’s waarin werkstations en ledenservers zich bevinden, terwijl Tier-0-componenten zoals domeincontrollers een apart, strenger beleid krijgen dat aansluit bij het tieringmodel. Security filtering waarborgt dat alleen gemanagede systemen de instelling ontvangen, terwijl WMI-filters kunnen helpen om oudere, niet-ondersteunde versies uit te sluiten en eerst te migreren. Vooraf wordt een pilotgroep samengesteld waarin representatieve systemen draaien, zodat compatibiliteit met bedrijfskritieke applicaties gecontroleerd kan worden voordat het beleid breed wordt uitgerold. Deze pilot omvat tevens systemen van ketenpartners en shared service centers, zodat afhankelijkheden met leveranciers vroegtijdig worden ondervangen.

Tijdens de pilotfase wordt het script `Invoke-Implementation` gebruikt om endpoints te controleren op resterende serviceaccounts die nog met beheerdersrechten draaien. Indien applicaties specifieke uitzonderingen vereisen, worden deze vastgelegd in een controlled exception register, inclusief eigenaar, einddatum en het compenserende controlemechanisme. De change-advisoryboard krijgt een samenvatting van de testresultaten, inclusief eventlog-verificatie (Security-log 4719 en 4739) en screenshots van `secpol.msc` waarin de instelling zichtbaar is. Pas na formele goedkeuring wordt de scope uitgebreid naar de volledige productie-OU en wordt het CAB-besluit gedeeld met audit en risk management, zodat zij weten dat het beleid aantoonbaar is getest.

Na de brede uitrol volgt een validatiefase. Beheerders gebruiken `gpresult /h` en het meegeleverde script om te bevestigen dat endpoints de correcte instelling hebben ontvangen en dat eventuele conflicterende lokale policies zijn overschreven. Daarnaast wordt gecontroleerd of automatiseringsplatformen zoals Intune Endpoint Security en Microsoft Defender for Endpoint geen tegengestelde configuraties pushen en of Azure Policy of SCCM-compliance baselines dezelfde instellingen naleven. Alle bevindingen worden vastgelegd in het implementatiedossier, samen met een rollbackplan waarmee het GPO tijdelijk kan worden uitgeschakeld mocht er onverwachte impact optreden. Door deze stappen zorgvuldig te doorlopen, blijft de maatregel reproduceerbaar, audit-proof en herhaalbaar voor toekomstige migraties naar nieuwe OU’s of tenants.

Tot slot wordt kennis geborgd via runbooks, instructievideo’s en overdrachtsessies voor beheerteams in verschillende shifts. Nieuwe medewerkers krijgen tijdens onboarding een praktische oefening waarin zij een testservice installeren, het geweigerde aanmeldingsrecht analyseren en leren hoe een gemotiveerde uitzondering wordt aangevraagd. Ook wordt een FAQ gepubliceerd waarin staat hoe leveranciersinstallaties veilig kunnen plaatsvinden zonder het beleid te schenden. Deze structurele kennisoverdracht voorkomt dat het beleid verwatert wanneer teams veranderen en zorgt ervoor dat de organisatie jaren na de eerste implementatie nog steeds dezelfde beveiligingskwaliteit levert.

Compliance

Deze maatregel sluit direct aan op het CIS Windows Benchmark Level 1 voorschrift dat vereist dat het gebruikersrecht "Deny log on as a service" wordt ingesteld voor alle hooggeprivilegieerde groepen. Voor Nederlandse overheidsorganisaties betekent het tevens een concrete invulling van BIO 09.02 en 09.02.03, waarin wordt geëist dat het uitrollen van software en het beheer van systeemcomponenten strikt wordt gecontroleerd. Door Domain Admins, Enterprise Admins en gasten het recht op service-aanmelding te ontzeggen, wordt voldaan aan de eis dat beheerfuncties gescheiden blijven van uitvoerende accounts en dat persistente toegangsvectoren structureel worden verminderd. Naast deze baselines ondersteunt de maatregel naleving van de AVG, specifiek artikel 32 omtrent passende technische en organisatorische maatregelen. Kwaadwillende services vormen immers een risico op ongeautoriseerde verwerking van persoonsgegevens; door het recht te beperken, toont de organisatie aan dat zij de verwerkingsomgeving hardent en de kans op datalekken verkleint. Ook sluit de instelling aan op het NCSC-principe van hardening en minimale functionaliteit, waarmee de organisatie kan laten zien dat zij leidende best practices volgt bij het beveiligen van Tier-0-accounts. Voor auditdoeleinden moet worden vastgelegd welke groepen in het beleid zijn opgenomen, welke uitzonderingen zijn toegestaan, hoe lang deze uitzonderingen geldig zijn en welke compenserende controles zijn ingericht. Auditteams verwachten een export van het GPO, een rapport uit het meegeleverde PowerShell-script en logging uit Event ID 4703, 4719 en 4739 waarmee wijzigingen in gebruikersrechten zichtbaar worden. Door deze bewijsstukken periodiek op te nemen in het compliance-dossier kan een auditor eenvoudig reconstrueren dat het beleid niet alleen is geconfigureerd, maar ook wordt bewaakt en bijgewerkt. Tot slot vormt deze instelling een aantoonbaar controlemiddel binnen beveiligingsraamwerken zoals ISO/IEC 27002 (controle 8.2 en 8.3) en het Rijksbrede Normenkader. Het laat zien dat de organisatie functiescheiding afdwingt, dat privilege-accumulatie wordt voorkomen en dat er een herhaalbare governancecyclus bestaat. Wie deze maatregel aantoonbaar en gedocumenteerd toepast, kan bij reviews en accountantsonderzoeken overtuigend laten zien dat persistente dreigingen via services structureel worden gemitigeerd en dat de Nederlandse Baseline voor Veilige Cloud op dit onderdeel volledig is ingevuld. Binnen ENSIA- en DigiD-assessments kan dezelfde maatregel worden aangevoerd als bewijs dat beheerrechten volgens het need-to-use-principe worden ingeperkt. Door het rapport van het script en de change-geschiedenis mee te sturen, voldoen organisaties aan de vraag om "control evidence" waarmee zij onderbouwen dat beheerfuncties niet gecombineerd worden met reguliere gebruikersactiviteiten. Dit past binnen het principe van taakroulatie dat door de Algemene Rekenkamer en het Ministerie van BZK wordt uitgevraagd bij periodieke onderzoeken. Daarnaast ondersteunt het blokkeren van serviceaanmeldingen de zero trust-principes waaraan veel ministeries momenteel werken. Onder zero trust hoort elke privilege-escalatie een expliciete goedkeuring en beperkte duur te hebben; deze maatregel toont aan dat persistente rechten niet automatisch worden verleend en dat alle uitzonderingen via een formeel proces verlopen. Daarmee levert de instelling een directe bijdrage aan het aantonen van volwassenheid binnen programma’s zoals Rijksbreed Zero Trust en NORA-implementaties. Door de maatregel te koppelen aan periodieke self-assessments (zoals ENSIA, IBD of BIO-audits) ontstaat een traceerbare lijn van beleid naar controls, meetresultaten en verbeteracties. Dit maakt het eenvoudiger om aantoonbaar te voldoen aan zowel nationale wetgeving als sectorale richtlijnen en geeft bestuurders vertrouwen dat de organisatie de juiste prioriteiten stelt.

Monitoring

Gebruik PowerShell-script deny-logon-as-service.ps1 (functie Invoke-Monitoring) – Controleren.

Monitoring van het beleid start met het verzamelen van telemetrie uit de Windows Security-log, specifiek Event ID’s 4703 (gebruikersrechten toegekend), 4719 (auditbeleid gewijzigd) en 4739 (domeinbeleid gewijzigd). Deze gebeurtenissen worden real-time gestreamd naar het SIEM of Microsoft Sentinel, waar een analytic rule controleert of het gebruikersrecht onverwacht wordt aangepast of als een systeem opeens een nieuwe service-accountgroep toestaat. De meegeleverde PowerShell-monitoringsfunctie leest regelmatig de effectieve rechten op endpoints uit, vergelijkt deze met de referentielijst en rapporteert afwijkingen inclusief device-naam, OU en tijdstip.

Naast loggebaseerde detectie is configuration drift-detectie noodzakelijk. Door middel van Microsoft Defender for Endpoint of Configuration Manager Compliance Settings wordt wekelijks gecontroleerd of de instelling nog aanwezig is en wordt bij afwijking automatisch een herstelactie voorbereid. Intune Endpoint Security-profielen kunnen aanvullende rapportages geven over devices die afwijken, waardoor ook hybride omgevingen volledig zichtbaar blijven. Alle resultaten worden vastgelegd in een Power BI-dashboard of een standaardrapport waarin trends, uitzonderingen en herstelacties worden bijgehouden.

Gedurende het jaar worden Key Risk Indicators vastgesteld, zoals het aantal systemen waarop het beleid ontbreekt, de gemiddelde tijd tot herstel en het aantal geautoriseerde uitzonderingen dat langer loopt dan de afgesproken einddatum. Deze indicatoren worden besproken in het security overleg en vormen input voor de halfjaarlijkse voortgangsrapportage van de Nederlandse Baseline voor Veilige Cloud. Indien het aantal afwijkingen stijgt, wordt een root-cause-analyse uitgevoerd om te bepalen of er nieuwe installatieprocedures, leverancierspackages of beheerhandelingen verantwoordelijk zijn.

Tot slot wordt monitoring uitgebreid met scenario-gebaseerde tests. Minimaal eenmaal per kwartaal wordt een gecontroleerde oefening uitgevoerd waarin een test-account probeert een service te registreren op een beheerd systeem. Het proces registreert de foutmelding, de tijd tot detectie in het SIEM en de tijd tot incidentrespons. De resultaten worden gedeeld met SOC, CSIRT en change management zodat iedereen weet dat de controles effectief zijn. Door deze continue monitoring en testcyclus blijft het beleid niet alleen op papier bestaan, maar levert het aantoonbaar bescherming tegen persistente dreigingen.

Als aanvullende borging worden alle monitoringsresultaten gekoppeld aan tickets in het ITSM-platform, zodat afwijkingen automatisch een incident of wijzigingsverzoek genereren. Dit maakt het mogelijk om service level agreements te meten en te rapporteren hoeveel tijd er verstrijkt tussen detectie en volledige herstelactie. Rapportages worden gedeeld met het bestuur, de privacy officer en de auditcommissie, waardoor monitoring een integraal onderdeel wordt van de bredere governancecyclus.

Omdat loggegevens persoonsgegevens kunnen bevatten, wordt voor monitoring een bewaartermijn en dataclassificatie vastgesteld. De organisatie documenteert dat de gegevens uitsluitend worden gebruikt voor beveiligingsdoeleinden en past waar mogelijk pseudonimisering toe voordat events naar centrale data lakes worden gestuurd. Deze aanpak sluit aan op AVG-verplichtingen en maakt het eenvoudiger om tijdens audits aan te tonen dat security monitoring in balans is met privacy.

Ten slotte wordt jaarlijks een maturiteitsbeoordeling uitgevoerd waarbij SOC-analisten, GPO-beheerders en risicomanagers gezamenlijk beoordelen of de gebruikte detectieregels nog aansluiten op de actuele dreigingsbeelden. Op basis van de resultaten kunnen nieuwe use-cases worden toegevoegd, zoals het koppelen van Defender for Identity-signalen of het verrijken van meldingen met CMDB-gegevens. Hierdoor groeit de effectiviteit van de monitoring mee met de professionaliseringsslag van de Nederlandse Baseline voor Veilige Cloud.

Remediatie

Gebruik PowerShell-script deny-logon-as-service.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring aangeeft dat het gebruikersrecht onbedoeld is gewijzigd of dat een endpoint de instelling mist, wordt direct het remediatiepad gestart. Het PowerShell-script voert een herstelactie uit waarbij het GPO opnieuw wordt afgedwongen, lokale beveiligingsdatabases worden herbouwd en een rapport wordt aangemaakt met tijdstip, hostnaam en toegepaste wijzigingen. Deze automatische herstelactie wordt gecombineerd met een change-notificatie zodat het beheerteam inzicht krijgt in de frequentie van afwijkingen en de onderliggende oorzaak kan onderzoeken.

Na de technische herstelling volgt een root-cause-analyse. Hierbij wordt beoordeeld of een beheerder, leverancier of geautomatiseerd proces de instelling heeft aangepast en of er sprake is van onbewuste fouten of bewust omzeilen van het beleid. Bevindingen worden vastgelegd in het exception register en gedeeld met security governance, zodat terugkerende patronen kunnen worden aangepakt via procesverbeteringen of aanvullende training. Indien nodig wordt een lessons-learned-sessie georganiseerd waarin betrokken teams bespreken hoe vergelijkbare incidenten kunnen worden voorkomen.

Remediatie omvat ook het begeleiden van applicatie-eigenaren wanneer legitieme services niet meer starten. Het beheerteam beschikt over een draaiboek waarin stap voor stap staat hoe een tijdelijke uitzondering wordt aangevraagd, welke compenserende maatregelen verplicht zijn (bijvoorbeeld versnelde logging of extra process-controles) en binnen welke termijn de uitzondering opnieuw moet worden beoordeeld. Zo blijft de balans tussen continuïteit en veiligheid behouden zonder dat het beveiligingsprincipe structureel wordt losgelaten.

Voor kritieke systemen wordt een parallel scenario beschreven waarin, bij uitval van meerdere services, het beleid tijdelijk kan worden teruggedraaid via een emergency change. Deze noodprocedure bevat duidelijke criteria, benoemt de beslissingsbevoegde (bijvoorbeeld de CISO of de verantwoordelijk diensthoofd) en eist dat het beleid binnen maximaal 24 uur opnieuw wordt geactiveerd. Door deze afspraken vooraf vast te leggen, blijft zelfs tijdens grote verstoringen helder hoe de beveiligingsmaatregel wordt hersteld.

Alle remediatie-acties worden geëvalueerd aan de hand van KPI’s zoals tijd tot detectie, tijd tot herstel en het aantal heropeningen. De resultaten voeden de continue verbetercyclus van de Nederlandse Baseline voor Veilige Cloud en vormen input voor kwartaalrapportages richting bestuur en audit. Deze transparantie maakt duidelijk dat de organisatie niet alleen maatregelen invoert, maar ze ook actief onderhoudt en verbetert zodra er afwijkingen optreden.

Om de doorlooptijd te verkorten wordt remediatie geïntegreerd met geautomatiseerde workflows in het ITSM-platform. Zodra het script een afwijking corrigeert, maakt het automatisch een incident aan, voegt technische logbestanden toe en wijst de case toe aan het verantwoordelijke team. Hierdoor kan de analist zich richten op de root-cause-analyse in plaats van op handmatige administratie, terwijl audittrail en rapportages automatisch worden opgebouwd.

Leveranciers en ketenpartners worden meegenomen in dit proces door contractueel vast te leggen dat zij geen services mogen installeren met hooggeprivilegieerde accounts. Wanneer tijdens remediatie blijkt dat een externe partij toch van de policy is afgeweken, kan de organisatie dit koppelen aan de afgesproken sancties of verbetermaatregelen binnen het leveranciersmanagement. Dit zorgt ervoor dat de beveiligingsmaatregel niet ophoudt bij de organisatiegrens, maar de volledige keten beschermt.

Gedurende het jaar worden de remediatie-ervaringen besproken in het security-architectenoverleg. Lessen uit incidenten worden vertaald naar nieuwe ontwerpprincipes, aanvullende controles of verbeterde documentatie. Zo ontstaat een feedbacklus waarbij elke afwijking leidt tot meetbare verbetering van processen, tooling en bewustwording, volledig in lijn met de kwaliteitsambitie van de Nederlandse Baseline voor Veilige Cloud.

Compliance & Frameworks

• CIS M365: Control Windows - Service logon (L1) -
• BIO: 09.02.03 -

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Door Domain Admins, Enterprise Admins en gasten te blokkeren voor serviceaanmeldingen wordt de belangrijkste route voor persistente malware afgesloten, blijven audits tevreden en kan de maatregel met één GPO en het meegeleverde script binnen enkele uren worden uitgerold.

• Implementatietijd: 3 uur
• FTE required: 0.01 FTE