Microsoft test sudo-commando voor Windows Server 2025

Microsoft test een sudo-functie voor Windows Server 2025, zo blijkt uit een uitgelekte build van dat OS. De feature, die staat voor 'superuser do', laat gebruikers commando's in de terminal uitvoeren met verhoogde rechten. De functie is bekend van bijvoorbeeld Linux.

Microsoft deelde onlangs zijn eerste testbuild voor Windows Server 2025, hoewel een nieuwere build kort daarna werd uitgelekt via de Windows Update-servers. Dat meldde Microsoft-leaker Albacore als eerste en werd later bevestigd door WindowsLatest. De sudo-functie is in die latere, uitgelekte build te vinden onder in het instellingenmenu van Windows Server, onder 'System'.

Gebruikers dienen de sudo-functie handmatig in te schakelen voordat deze werkt. De feature verschijnt in de instellingen wanneer gebruikers de ontwikkelaarsmodus van de Windows Server 2025-testbuild inschakelen. De functie lijkt momenteel nog niet te werken in de testbuilds, zo meldt WindowsLatest, die ook screenshots van de feature publiceert.

Het sudo-commando zit al jarenlang in Linux en macOS. Gebruikers kunnen daarmee met verhoogde rechten commando's uitvoeren in de terminal. Met sudo is het bijvoorbeeld mogelijk om instellingen aan te passen die normaliter adminrechten of roottoegang nodig hebben. Met Linux kunnen gebruikers met het sudo-commando bijvoorbeeld updates installeren, apps deïnstalleren of systeeminstellingen aanpassen.

Het sudo-commando in Windows Server 2025. Bron: WindowsLatest

Reacties (85)

[Yzord]

Dit is niet om te trollen, maar kan dit zomaar? Ze vragen namelijk geld voor de licentie en proppen er steeds meer linuxachtige modules bij in welke toch onder een andere licentie vallen?

[ThomasG]

Ja. Er is namelijk geen licentie op een programma dat sudo heet. Ook is er niet één sudo programma. De GNU variant dat gebruikt worden door veen Linux distributies is bijvoorbeeld anders dan de BSD variant dat gebruikt wordt door BSD systemen en MacOS, en hebben totaal andere licenties. Microsoft komt nu met een eigen variant dat werkt binnen Windows.

[Soldaatje]

Volgens mij is de bron van sudo www.sudo.ws deze zit ook op mijn Arch Linux pc in ieder geval. De licentie is ISC-based. Microsoft heeft in 2009 wel een patent op het mechanisme gekregen, maar daar viel sudo toen niet onder omdat het zonder gui werkt.

[Reactie gewijzigd door Soldaatje op 23 juli 2024 16:10]

[Jerie]

Er zijn meerdere implementaties van dit idee inderdaad maar de macOS, BSD en Linux varianten delen dezelfde codebase. Het zijn geen forks maar ports. Changes worden ook upstream gebackport. Verschil is dat Linux en macOS gebruik maken van (ook zo'n gedrocht) PAM en BSD maakt gebruik van BSD Auth. Keuze van OS blijft overigens altijd een afweging van pros en cons.

[nowaychose]

Een heleboel distros nemen in de base image alleen software op die zeer permissive licenties hebben. Iets als Ubuntu mag je gewoon doorverkopen mits je de Ubuntu branding/references eruit haalt.

De sudo license https://www.sudo.ws/about/license/ zegt

Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

En MS zal niet deze code gebruiken. Het concept is al helemaal vrij.

[Reactie gewijzigd door nowaychose op 23 juli 2024 16:10]

[latka]

De kans dat deze sudo gebruikt wordt is 0%. De NT kernel lijkt niet eens op een Unix kernel, dus het overzetten van Sudo is kansloos. MS lift hier gewoon mee op de naam omdat iedereen die het nodig heeft dit kent. Het zal qua naam in ieder geval beter blijven hangen dan Ps-PowerApplet-asSuperUSERDO.cmd blijven plakken.

[Genosha]

Is dit niet gewoon een teken dat Microsoft steeds meer kijkt naar de mogelijkheden om de Windows kernel stabieler, compacter en efficiënter te maken? En dat kan alleen door hun eigen oude idee los te laten en dat van Unix te omarmen.

[GertMenkel]

Ik denk het niet. De ACLs van Windows zijn een stuk beter dan wat de meeste Linuxkernels gebruiken, ik denk niet dat Microsoft hun beveiligingsmodel gaat afzwakken om naar ESUID+EGUID terug te vallen.

[Gimmeabrake]

Linux kent ook ACLs: https://www.redhat.com/sysadmin/linux-access-control-lists. Desktop distros doen er standaard niet veel mee, daar volstaat het simpele model. Op servers zie ik het wel vaker gebruikt worden.

[GertMenkel]

De ACL's op bestandssystemen zijn inderdaad al een tijd lang uitgebreid, maar in de Windows-kernel zitten die ACL's ook op processen, threads, en diverse soorten handles. Dat zit al tijden in NT, ik geloof sinds Win2k of zelfs eerder. Op Linux is voor dat soort dingen maar beperkte ondersteuning aanwezig. Ook dingen als integrity levels zitten niet in Linux ingebakken.

Je kunt hetzelfde wel voor elkaar boxen met een hele hoop users/groepen+selinux+container-API's, zoals Android dat bijvoorbeeld doet, maar dat is toch een hele andere aanpak.

[Joep Lunaar]

Onder Linux wordt voor fijnmazige restricties/rechten veel gebruik gemaakt van capacities (privileges) control groups en security modules. Voor containers zijn daar heel wat implementaties die behoorlijk precies bepalen wat een proces al dan niet vermag.

Windows 3.1 kende overigens al security descriptors op vele resources.

[GertMenkel]

Dat klopt, maar ook daar eindig je vaak in de situatie waar je voor een bepaalde set rechten een losse groep moet opzetten. Je kunt dezelfde situatie bereiken, maar omdat je een hele set API's combineert, is het toch nog verrassend verraderlijk om privilege escalations uit containers te krijgen.

Ik wist niet dat Windows NT 3.1 (ik neem aan niet Windows 3.1) al aan security descriptors deed, ik dacht dat dat pas later kwam. Toont toch weer aan hoe solide Windows NT blijkt te zijn!

[GeroldM]

ACL's in NTFS zijn voornamelijk talrijker. Of dat beter is, dat zal de lezer moeten beslissen. Zelf ben ik van mening dat al die extra opties vaak conflicterend kunnen werken. Zeker als je drives tussen systemen moet verplaatsen. Iets wat helaas vaker voorkomt in mijn omgeving.

Die ACL ellende die je daarmee op je hals haalt, die zijn wel op te lossen met een stukje software, genaamd: SetACL Studio. Deze tool geeft namelijk geen reet wat voor ACLs er op dat moment bestaan voor het bestand, map of partitie dat problematisch is. Het overschrijft gewoon de huidige ACL instellingen met de ACL instellingen die je in SetACL Studio hebt gemaakt.

Dat heeft me een heleboel kopzorg betsaat. Maar als de maker van SetACL software een methode heeft om ACL simpelweg te overschrijven, dan zullen personen in de ongure kringen op het internet ook wel weet hebben van deze en mogelijk andere methodes die ACLs compleet kunnen negeren.

Beveiliging via ACLs is een goed en verstandig concept. Maar zoals vaker, bij Microsoft schort er wel eens wat aan de uitvoering. Een probleem dat vaak niet word onderwezen bij Microsoft certificeringen. Maakt het wel leuker om Microsoft-gecertificeerden te laten zien hoe snel en eenvoudig hun beveiligingsinstellingen zijn te omzeilen.

Meer is niet noodzakelijk beter. Het strict houden van de naleving van de toegangsregels is belangrijker dan de hoeveelheid. Linux heeft ook problemen op dat gebied. Maar minder erg, voor zover ik heb kunnen achterhalen. Nu ben ik de laatste die zal zeggen dat ik ben uitgeleerd op dat gebied. Maar tot op heden heb ik mijn omgeving (Windows, Linux en BSD) minder toegansproblemen gehad met Linux systemen dan met Windows systemen.

Jouw ervaring kan heel anders zijn, en dan zou ik graag daarover lezen in een vervolg-post. Mijn ervaring blijft tenslotte een n=1 ervaring.

[latka]

De Windows kernel is klein, compact en efficiënt. De win32/win64 saus erover is een draak van een API met veel te veel geneuzel en inconsistenties.

[Arrigi]

https://learn.microsoft.c...iners/system-requirements

Windows "Nano Server" draait gewoon in 40MB RAM. Da's blijkbaar iets minder dan Alpine Linux.

[Jay-v]

Ja dat mag zeker, zie GNU FAQ: https://www.gnu.org/licen...html#DoesTheGPLAllowMoney

[friket]

Zal vast een eigen Microsoft implementatie zijn. Denk niet dat ze de code rechtstreeks uit Linux ofzo halen, zal toch niet zomaar werken binnen andere terminal.

[Blokker_1999]

Het idee is natuurlijk niet exclusief voorbehouden aan de FOSS gemeenschap. Daarnaast hebben de meeste FOSS licenties geen enkel probleem als je de bijhorende software opneemt in een veel groter geheel dat niet volledig FOSS is.

[Jerie]

Linuxachtige modules"? Ik gebruik dit al zo'n 15 jaar op Windows.

De grap in dit geval is dst sudo in C is geschreven en veel LOC met heel veel features die het gros van de gebruikers niet nodig heeft. Spaghetti code bovendien. Kan veel netter, en er zijn dan ook al enkele betere implementaties (maar die zijn nooit 100% compatibel).

[jorisvergeerTBA]

Er is niks speciaals aan het idee van sudo. Microsoft heeft al jaren hun "uitvoeren als administrator" knop. Dat is in principe ook gewoon sudo. Alleen dan niet als voorvoegsel in de command line. Eigenlijk mis is dan nog een knop met "bewerken als administrator".

Het is overigens ook leuk om te zien hoe sudo zelf werkt op linux. Bij linux kan je executables namelijk de optie geven dat die naast de chmod van uitvoerbaar of niet uitvoerbaar, ook de flag dat die uitgevoerd word met de rechten van de eigenaar of als de aanroeper. En met root als eigenaar kan sudo daarmee, na het doen van een paar permissie checks, het volgende command uitvoeren als root of als elke andere user.

Weinig rare linux black magic, maar gewoon briljant simpel eigenlijk.

[Reactie gewijzigd door jorisvergeerTBA op 23 juli 2024 16:10]

[The Lord]

Inderdaad zou het een goede toevoeging zijn als met een optie 'Als administrator bewerken' een enkel bestand bewerkt kan worden (en dus enkel toegankelijk is in die sessie), waarvoor specifieke rechten nodig zijn, maar de gebruikte applicatie voor bewerken in user-space draait.

En ik vindt het zelf een slecht idee om 'sudo' te gebruiken aangezien er helemaal geen 'super user' is in Windows. 'addo' zou dan logischer zijn.

[beerse]

De commando's su en sudo staan in mijn gedachten niet voor SuperUser maar voor SetUser of SetUserDO.

Dat de default user waar je naar toe stapt dan de superuser (root, aka local-administrator) is dat is dan gewoon makkelijk.

Voor msWindows vraag ik mij wel af of de sudo dan de configureerbaarheid gaat krijgen zoals sudo heeft met de sudoers file (/etc/sudoers en omstreken). Ook vraag ik mij af of dit gebruikt kan gaan worden om zaken als een andere gebruiker uit te voeren.

Hopelijk is het niet alleen maar om de 'run as administrator' te voorzien van een wachtwoord in plaats van alleen maar <ok> klikken.

[BeyondThunder]

Wat is er mis met start > cmd > ctrl+shift + enter?

(edit; wellicht in een remote console wel handig)

[Reactie gewijzigd door BeyondThunder op 23 juli 2024 16:10]

[com2,1ghz]

Je noemt het zelf op. Een toetsencombinatie.
Nu kan het via cli

[BeyondThunder]

Ik doe heel veel via een elevated cli.
En die open ik altijd via start > cmd > ctrl+shift + enter
Muscle memory zeg maar.

[curkey]

Een hele cli sessie als admin kan soms een pijnlijke vergissing opleveren met bv een typo.

[BeyondThunder]

Op servers heb je 100% gelijk, maar ik werk uitsluitend op test client VM's. En die revert ik ook 10x per dag.

[_Pussycat_]

Echter zijn er ook mensen die dus op servers werken. Windows is niet speciaal voor jouw use-case ontwikkeld.

[nowaychose]

Vaak wil je alleen één specifiek ding doen met elevated rights.

[latka]

Ik ben benieuws wat ze met het windows environment (pad e.d.) doen als je sudo gebruikt. Als die, die van de gebuikers is dan voorzie ik weer hele nieuwe hacks ;-)

[BeyondThunder]

Die zullen gelezen worden van de sessie, dus van de "admin". Net zoals het nu ook is.
(denk ik)

[latka]

Tsja, onder Unix moet je daarvoor toch echt nog een extra optie zetten.

[Raymond Deen]

Ik (als hoofdzakelijk Windowsgebruiker) zeg dat Windows gebruikers vaak minder security oriented zijn als Linux gebruikers.
Standaard een elevated prompt opnen is eigenlijk precies wat niet de bedoeling was...

[BeyondThunder]

Ja, 9 van de 10 keer om een oplossing te testen.
Daarna scripten en automatiseren.

[Gropah]

Ookal ben je admin, het is goed om je er bewust van te zijn wanneer je die rechten daadwerkelijk nodig hebt. Het gevaar van altijd in een elevated termincal/cmd/powershell/etc te doen, is dat je per ongeluk operatie kan uitvoeren die je niet zou moeten willen, per ongeluk bestanden verwijderd, of andere dingen die je niet standaard zou moeten kunnen.

[joost00719]

Ja en dan moet je 't pad weer opnieuw opzoeken

[com2,1ghz]

Dat kan nog altijd. Maar met sudo kan je binnen dezelfde cli blijven en alleen enkele commands elevated uitvoeren ipv alles.

[webhalla]

Wat is er mis met het runas commando?

Runas is a command-line tool that is built into Windows Server 2003 and Windows Vista. To use runas at the command line, open a command prompt, type runas with the appropriate parameters, and then press ENTER.

https://learn.microsoft.c...nd-2012/cc771525(v=ws.11)

Off-topic ik heb al jaren een sudo.bat in het search path die met runas een commando venster opent onder een ander account met andere rechten.

[GoBieN-Be]

Misschien kan je met sudo de commando's wel uitvoeren onder je eigen user-context.
Met Run-As voer je die uit in de context van de andere user, bijvoorbeeld netwerk schijven zijn dan niet beschikbaar.

[wildhagen]

Ten eerste is het omslachtiger om het middels zo'n shortcut te doen.

Ten tweede, en dat is belangrijker, start je dan de hele command prompt met elevated permissies, terwijl je met sudo echt alleen dat ene specifieke commando (of desnoods een set commando's) elevated uitvoert.

Vanuit security oogpunt (principle of least privilege) wil je zo min mogelijk elevated doen, en dan is sudo dus een betere optie dan jouw voorstel.

[BeyondThunder]

Dat is inderdaad de theorie, maar als je in de IT werkt dan weet je dat het in de praktijk anders gaat.

[Reactie gewijzigd door BeyondThunder op 23 juli 2024 16:10]

[Caelorum]

Eh? Ik werk als ontwikkelaar en heb echt misschien eens per dag een elevated command nodig. De rest van de tijd kan ik zonder. Op Windows dan he.

[latka]

Een standaard gebruiker onder windows mag al vrij veel, dus dat zegt niet zo veel.

[Caelorum]

Klopt en daarmee is het dus nog verbazingwekkender dat iemand aangeeft niet met de gewone command prompt te kunnen werken en in de praktijk dus met elevated command prompt te werken.

[BeyondThunder]

Enkel als dat nodig is uiteraard. En als desktop beheerder, applicatie specialist is dat best vaak op een dag. Al is het enkel om de ccmcache folder te checken.

edit;
Maar verder heb je gelijk, meestal zelfs als SYSTEM (psexec -s -i cmd) om na te kunnen spelen wat de CCM client doet. en te kijken waar het fout gaat.

[Reactie gewijzigd door BeyondThunder op 23 juli 2024 16:10]

[BeyondThunder]

Ik werk als beheerder en ik heb dat meer dan 10x per dag nodig (Om een oplossing te testen)

[Caelorum]

Prima, maar scheef dan niet de hele IT over 1 kam. Ik hoef ook alleen maar die admin rechten als ik weer eens de build server kan fixen, omdat die vage shit aan het doen is. De rest van de tijd dus niet nodig.

[BlaDeKke]

Dus je bent een administrator, en je hebt vaak administrator rechten nodig. Straf, ongehoord.

[RobertMe]

Nu weet ik niet wat Windows hier van gaat bakken. Maar bij de echte sudo kun je nog steeds een elevated (interactive) shell openen met "sudo -i". Dan draait de shell zelf dus wel elevated, en dus ook alle commando's die je in de shell uitvoert. Maar de terminal emulator (oftewel: de GUI) draait dan nog steeds gewoon als user. Terwijl met jouw optie cmd ook als admin draait. Als cmd als (UI) programma "lek" is dan heb je daarmee dus nog steeds een probleem. Terwijl dat met een interactive sudo (shell) niet het geval is.

[Dennisb1]

Dan moet je totaal opnieuw beginnen in plaats van direct verder te werken in de directory waar je al in zit bijvoorbeeld. Vooral met PowerShell met plug-ins ben je wel ff bezig.

[The Realone]

Omdat je op die manier een hele shell elevated start ipv een enkel commando. Dat komt toch wat beter overeen met het least-privileged principe dat we graag zien.

[Haribo112]

Exact. Het is het verschil tussen `sudo <command>` en `sudo su` en dan je <command>

[schoene]

Ik gebruik daar al jaren gsudo voor: https://github.com/gerardog/gsudo

[zzzzap]

met windows 10 / 11 makkelijk te installeren met:
winget install gsudo

[Reactie gewijzigd door zzzzap op 23 juli 2024 16:10]

[BushWhacker]

Die gebruik ik ook.
Werkt goed.

[nehal3m]

Dat maakt het een stuk makkelijker om commando’s alsnog met verhoogde privileges uit te voeren, ik heb best vaak dat ik PowerShell of cmd opnieuw moet starten (start, zoek, rechtsklik, start als admin, credentials, commando nogmaals). Ik hoop dat je dan straks ook “sudo !!” kunt doen om sudo aan je commando te prependen.

[lenwar]

Je kunt ook gewoon runas /user:administrator <commando> doen 😊

[McBacon]

Dat is alleen nog steeds niet elevated, dat voer je gewoon uit met normale gebruikersrechten. Net als dat een random .exe dubbelklikken niet meteen met elevated privileges draait ook al is het huidige account een admin, daar zit altijd nog UAC voor. Met "runas /user:administrator" krijg je via de groep Administrators gewoon meer rechten op bepaalde mappen (zoals Program Files en ProgramData), maar je kan nog steeds niks direct aanmaken/verwijderen onder bijvoorbeeld system32 en dat kan met een echt elevated prompt dus wel.

[lenwar]

Maar dat is juist het hele idee ervan.
De output is als jezelf.

Je voert alleen het commando met verhoogde rechten uit, maar de output van het commando is als jezelf. Anders kun je te veel stuk maken.

Dit is met sudo ook zo. (De stdout en stdrerr van het sudo-commando zijn van jezelf)

Edit: compileer maar een bestand dat zaken verwijderd in een directory waar alleen de Administrator-gebruiker/groep dingen kan verwijderen. Dat gaat gewoon werken.
(Ik neem geen verantwoordelijkheid voor de gevolgen!!)

[Reactie gewijzigd door lenwar op 23 juli 2024 16:10]

[McBacon]

voert alleen het commando met verhoogde rechten uit

Nou nee, met runas dus niet. Mijn punt is juist dat Administrators-groep != elevated en met runas kan je maximaal dat eerste bereiken. Jij reageerde op @nehal3m die zegt "start als admin", dat betekent voor Windows dus elevated en niet "draai als de Administrator user (maar wel met normale gebruikersrechten)".

[lenwar]

Ik ben zelf een Linux engineer, maar ik heb altijd begrepen dat je dan bijvoorbeeld met Windows:

runas /user:administrator regedit

En dan dus regedit kunt uitvoeren met Admin-rechten. Dat klopt dan dus niet?

[McBacon]

Nee dat klopt wel, maar je hebt voor het overgrote deel van regedit dus net geen "elevated" permissions nodig. Alles wat binnen HKEY_CURRENT_USER staat kan je zelfs zonder de normale "unelevated" admin privileges aanpassen. Met "runas administrator" is HKCU dus in de context van de admin user i.p.v. jouw eigen ingelogde account, en heb je dankzij de Administrators-groep ook rechten op HKEY_LOCAL_MACHINE enzo.

Je kan het misschien wel een klein beetje vergelijken met SELinux: zelfs als root kun je niet alles zomaar doen. Op Windows draait alles van de Administrator user ("root") standaard in een user context, je moet expliciet via een UAC prompt aangeven dat iets met volledige admin privileges mag draaien (elevated dus, soort van "setenforce 0" voor dat ene proces). Met sudo zullen ze je straks 1 specifiek commando elevated uit laten voeren, en ik gok dat je daarbij ook zelf lid moet zijn van een Administrators-groep (á la /etc/sudoers).

[lenwar]

Even de hkcu natuurlijk in het midden gelaten.

https://learn.microsoft.c...nd-2012/cc771525(v=ws.11)

Hier staat toch echt dat je ‘als een andere gebruiker’ een commando uitvoert. Met de bijbehorende groepen natuurlijk als extra privileges.
Dus stel dat ik runas /user:administrator cmd uitvoer. Dan heb ik een commandprompt als de gebruiker ‘Administrator’. En niet als mezelf met de groepen van de Administrator.

Ik dacht trouwens dat er ook zaken als de SYSTEM-user draaide? Dat is toch waar de kernel en de drivers als lopen?

SELinux is echt compleet wat anders en staat redelijk naast gebruikers. Dat zijn kernel-calls die worden afgevangen voor processen.
Je kunt de facto ook inderdaad zaken ook met users doen, maar het gaat veel verder dan dat.

Je kunt bijvoorbeeld sturen welk proces, welk ander proces mag benaderen en hoe. Of een proces netwerkverbinding mag openen, gebruiken, omleiden, sluiten, analyseren, enz. Maar ook of een proces bijvoorbeeld data mag injecteren/lezen/manipuleren in pipes of sockets en dergelijke, die in bepaalde contexten draaien, onafhankelijk van de bijbehorende gebruikers. Al kun je optioneel ook gebruikers aan specifieke context-doelen en bronnen hangen.

[kdekker]

Je draait onder user administrator. Doe naar runas /user:administrator cmd en kijk onder wel account je draait.

Op *nix varianten ben je in principe nog jezelf, maar met root rechten (of net wat je instelt voor sudo). Sudo is veel meer te tunen dan runas en kan zelfs zonder user prompt voor password iets doen.

Overigens is in Windows explorer.exe nooit elevated te starten, ook niet als user administrator (niet via runas, maar ook niet als je echt ingelogged bent als die user)

[BeyondThunder]

Dat zeg ik, start > cmd > ctrl+shift + enter
(test maar eens, is echt supersnel)

[nehal3m]

Sneller, ja. Dank voor de tip! Echter moet ik dan nog wel navigeren naar waar ik was en een commando copypasten, dat moet beter kunnen.

[Noxious]

Er is al:
PS> Start-Process <command> -Verb runAs

Dat kan zelfs afgekort als:
PS> saps <command> -v runAs

[GeeBee]

Ik heb zo goed als nul verstand van Linux, maar dit ‘Triviant-weetje’ weet ik dan weer wel.
sudo = substitute user do en niet superuser do.

[Reactie gewijzigd door GeeBee op 23 juli 2024 16:10]

[jaenster]

Grappig, ik dacht altijd dat het switch user was, omdat je met su ook een andere user kan worden dan root

[beerse]

substitute,switch of set, er zullen meer s-woorden ingevuld kunnen worden.
Laat het in ieder geval duidelijk zijn dat het niet om de superuser gaat, dat is slechts de default/standaard user omdat die er altijd is.

[friket]

Wel een fijne verbetering als dat zo is. Hoe vaak ik niet een terminal heb gestart en dan blijkbaar voor een of andere commando weer admin rechten nodig heb, moet je weer een aparte terminal starten met administrator rechten. Hadden ze al veel eerder mogen "overnemen" van Linux en consorten. Hopelijk komt het ook naar de desktop.

[boner]

runas administrator .....

[Luchtbakker]

Maar welke SU wil je in Windows creëeren dan? Normaal is in Linux een root user een admin, en met SU ben je een root/system. Maar binnen windows is voor een gebruiker een admin het hoogst haalbare, omdat system rechten enkel nodig zijn voor bepaalde Windows services.

Of ik mis iets.

[GNID]

Laat ook maar ...

[Reactie gewijzigd door GNID op 23 juli 2024 16:10]

[segil]

Windows had natuurlijk al een vorm van sudo, namelijk UAC. Waarbij je voor elke systeemwijziging een UAC prompt krijgt. De gevoeligheid kan je zelf instellen. Verder, als je je eigen account local user maakt en geen admin, dan moet je voor de meeste aanpassingen credentials opgeven van een local admin account.