Local administrator

Is het nou een goed of slecht idee om je eindgebruikers local administrator rechten te geven op hun endpoints?

Werkplek

De laatste jaren is de trend dat we eindgebruikers steeds meer vrijheid gegeven hebben op de systemen waar ze mee werken. Sterker nog, we hebben ze vaak Local Administrator gemaakt.

Niet op de laatste plaats doordat je gebruikers deze vrijheden ook in de privé sfeer gewend geraakt zijn door het gemak waarmee ze apps installeren op hun telefoons of eigen laptops. Veel software kent tegenwoordig gratis alternatieven en in een groeiend aantal gevallen is de gratis software misschien nog wel beter dan de betaalde alternatieven die op je zakelijke laptop staan.

Uiteindelijk zijn we zo ver gekomen dat we in veel gevallen de eindgebruiker ook local administrator (LA) gemaakt hebben op hun laptop zodat we zelf hun werkzaamheden uit kunnen voeren zoals zij dat willen.

Eerder in het BYOD stuk hintte ik al dat er ruimte was voor discussie op dit vlak.. Dus, is het verstrekken van LA autorisatie dan wel iets wat we echt moeten willen? En hebben we dan eigenlijk wel een keuze op dit vlak? Dat zijn de punten waar we in dit artikel eens naar gaan kijken.

Wat is een “Local Administrator”

Local administrator rechten zijn zoals iets als de sleutels van het huis.
Hier zijn de sleutels, succes!

Een gebruiker is local administrator als de hoogste rechten op het device zijn toegekend aan deze gebruiker. Een eerste verwarring hier is meteen al dat dit op een Intune (MEM) managed device eigenlijk al niet helemaal waar is.

Er zijn voldoende instellingen waarbij de instellingen die een local administrator zou maken aan bijvoorbeeld Windows Defender altijd overruled worden door de management instellingen vanuit Intune. Zoals bijvoorbeeld de “DisableLocalAdminMerge” setting die er voor zorgt dat de Defender instellingen van het managed profile altijd leidend zijn. (Zie hier meer van deze instellingen en bijvoorbeeld ook hier wat mogelijkheden met betrekking tot onder andere de firewall instellingen op je endpoints)

Maar, er zijn dus voldoende instellingen die een local admininistrator kan maken waar je niet direct of invloed over hebt. Niet op de laatste plaats het feit dat een LA zelf software kan installeren. Dit is vaak dan ook de reden waarom je deze rechten sowieso verstrekt aan je eindgebruikers.

Hier zit dan meteen ook het grootste security risico. Want niet alleen de software die de gebruiker zelf wil installeren kan dus gedraaid worden, maar ook allerlei malafide pakketten die soms onbewust of onbedoeld mee geïnstalleerd worden. (gelukkig zijn we alvast voor een heel eind verlost van allerlei search bars).

Wat een LA ook is in deze context, is een enkele entiteit met autorisatie over één device. een LA mag wel een oorsprong hebben in bijvoorbeeld een Azure AD, maar is LA op enkel zijn device en heeft in beginsel dus geen autorisatie op andere apparaten. Dat die autorisatie via allerlei routes alsnog gegeven kan worden is weer een heel ander verhaal.

Waarom zouden we een eindgebruiker “Local administrator” willen maken?

Local administrator rechten zetten de deur naar binnen op een kier
Zet je met LA rechten de deur open?

De voornaamste reden die we hiervoor horen is dat we de gebruiker de vrijheid willen geven om te werken zoals ze dat zelf willen. Het idee is dat wanneer je een gebruiker teveel beperkt ze buiten de normale IT om gaan werken en er een Shadow IT omgeving ontstaat waar je geen zicht en al helemaal geen controle over hebt.

De bovenstaande reden voer ik zelf ook wel eens aan, vooral ook omdat het alternatief (en eigenlijk de juiste werkwijze) een aanzienlijke investering in tijd gevolgd door aanzienlijk hogere onderhoudskosten met zich mee brengt.

De realiteit

De realiteit is dat het overgrote deel van de gebruikers met een relatief beperkte applicatie set overweg kan en ook helemaal niet de noodzaak heeft om daar van af te wijken. Echter, het inventariseren waar ze nou echt mee willen en moeten werken, zorgen dat ze daar volledig voor getraind worden en dat je die applicatie onderhoud (updates, wijzigende standaard configuraties en ga zo maar door) terwijl je ook nog eens de maandelijkse nieuwe gebruikers inleert in die werkplek is allemaal zo eenvoudig nog niet.

Dus, we pushen een aantal standaard applicaties, en of iemand nou de standaard notepad, of notepad++ gebruikt zal ons over het algemeen een worst wezen om het maar bot te omschrijven.

De snelste weg om ons daar als IT afdeling niet meer druk over te maken is de gebruiker het zelf maar uit te laten zoeken en ze de autorisatie geven om te installeren wat ze willen. De hele security afdeling slaapt vervolgens slecht, maar met de nodige monitoring en automatische mitigatie vanuit de Microsoft 365 E5 of E3 met de Security add-on kijken we met een iets geruster gevoel de andere kant op. (En hebben we ook daadwerkelijk aanzienlijk meer grip op de situatie, maar wel tegen de nodige kosten)

Waarom zouden we gebruikers geen local admin maken?

Het innemen van local administrator rechten kan als een gevangenis voelen voor gebnruikers.
Voor sommige mensen voelt het als opgesloten worden (voornamelijk IT’ers gelukkig)

Als we geen grip houden op wat men installeert op hun systeem hebben we dus ook geen grip op waar die installers vandaan komen.

In het notepad++ voorbeeld van hier boven pakte dat in 2021 nog goed verkeerd uit toen er installers verspreid werden met malware.

Als de gebruiker enkel de officiële bron gebruikt is dit risico minder groot, maar we weten allemaal ook wel dat de eerste google link gebruikt zal worden voor het downloaden van de gezochte software.

Hiervoor heb ik kort stil gestaan bij het werk dat komt kijken bij het standaardiseren van het volledige applicatie landschap. Dit mag dan wel een hoop werk zijn, maar het bied zeker voordelen.

Wanneer je met een homogeen landschap kan werken is er meer mogelijk op het vlak van het standaardiseren van bijvoorbeeld je onboarding en adoptie trajecten. Daarnaast maakt het je landschap overzichtelijker en zaken als patch management voor applicaties op de endpoints eenvoudiger.

Veel aanvallen die starten via een device van een eindgebruiker gaan uit van een autorisatie niveau waarbij aanvullende tools (zonder tussenkomst van de eindgebruiker) geïnstalleerd kunnen worden om de aanval verder uit te breiden. Deze tactiek sluit je uit door de gebruiker deze autorisatie domweg niet te geven. Dat sluit het risico op een aanval via het endpoint niet uit, maar het verkleint de kans aanzienlijk.

Vanuit het perspectief van de eindgebruiker valt ook wel wat te zeggen voor een meer restrictieve omgeving. Het overgrote deel heeft niets met IT en wil gewoon hun werk doen, met goede instructies, goed geconfigureerde werkplekken en applicaties is al die vrijheid en de bijbehorende verantwoordelijkheid helemaal niet nodig.

Nuances

Nuances, je zou door de bomen het bos niet meer kunnen zien.
Er zijn altijd nuances

Er is niet één antwoord op of je je gebruikers local administrator wil maken ja/nee. Los van dat het sterk afhangt van wat voor soort organisatie je bent en wat voor type personeel er rondloopt heb je ook een zekere mate van vrijheid in hoeveel risico je wil/kan/mag lopen.

Los daarvan kan je prima differentiëren binnen je organisatie. Als je er voor gaat om gebruikers niet standaard LA autorisatie te geven wil dat niet direct zeggen dat je geen van je gebruikers dergelijke rechten geeft.

Je kan overwegen om een kleine groep “power-users” meer autorisatie te verstrekken zodat zij voor de curve kunnen werken met nieuwe tools die mogelijk later voor de rest beschikbaar gesteld kunnen worden.

Of mogelijk heb je een development team dat nou eenmaal meer vrijheden nodig heeft gezien de aard van de ontwikkelingen die ze doen.

En tot slot heb je natuurlijk ook je IT afdeling nog (eventueel). Los van het feit dat die er niet zo goed tegen kunnen om beperkt te worden op hun werkstations valt er ook wel wat te zeggen voor de vrijheid om alle tools te mogen gebruiken om de omgeving goed te laten functioneren. Daarnaast kan je er ook op vertrouwen dat ze bekend zijn met de materie en geen onnodige risico’s nemen.

Conclusie

En nu dan? Moeten we iedereen meteen de local administrator rechten afnemen? Of ligt het iets gecompliceerder?

Als je momenteel in de situatie zit waarbij je eindgebruikers allemaal LA zijn is de weg terug niet zonder risico en vergt het zeker de nodige planning en voorbereiding. Maar dat neemt niet weg dat een dergelijk traject niet de moeite waard kan zijn.

Vanuit security oogpunt zou het wenselijk zijn om de LA autorisatie enkel te verstrekken aan mensen waarvoor het functioneren ernstig verstoord wordt zonder die autorisatie. Maar je hebt dus ook sectoren waar veel vrijheid op de systemen waar ze mee werken onontbeerlijk is, in die gevallen zal het risico via andere routes gemitigeerd moeten worden.

In hoofdlijnen komt het er wat mij betreft op neer dat je voor een combinatie moet gaan. De teams die werken met een vaste set applicaties en processen wil je eigenlijk geen LA autorisatie geven, de toegevoegde waarde is marginaal en de risico’s te groot. In het kort krijg je dan dus een tweedeling in de organisatie, maar de basis is hetzelfde.

Iedereen begint met dezelfde laptop, de beheer tooling, monitoring, security tooling en de initiële set applicaties zijn voor de gehele organisatie gelijk, of anders functie gebaseerd. Een (zo klein mogelijk) deel van de organisatie geef je vervolgens aanvullend autorisatie zodat ze LA zijn op hun devices.

Je kan overwegen om deze (LA) gebruikers een stukje aanvullende instructie te geven. Eventueel kan je ze ook mogelijk ook nog te laten tekenen voor de aanvullende verantwoordelijkheid die je ze geeft. Deze vrijheid komt namelijk niet zonder de nodige plichten zoals het goed onderhouden van de software (overigens deels te automatiseren), maar ook extra waakzaamheid voor verdachte situaties bij het uitvoeren van de werkzaamheden.

Eén gedachte over “Local administrator”

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.