Ja dit maakt uit, mocht je toch op wat voor manier dan ook malafide software starten, dan start die met dezelfde rechten als jij hebt, oftewel administrator rechten... (tuurlijk beperkt met UAC)... Maar er zijn nog genoeg zaken aan te passen...

Je bent altijd veiliger zonder admin rechten.

Ik zou je aanbevelen om jezelf als een onveilige gebruiker te beschouwen en wél een gewoon gebruikersaccount aan te maken. Niet omdat je niet weet wat je doet maar omdat *niemand* erin slaagt om altijd scherp te zijn. Als je een vermoeiende dag achter de rug hebt, en dan nog even op het verkeerde moment wordt afgeleid, dan zit een ongeluk in een heel klein hoekje. Dat kan echt de beste overkomen. Alleen zal de "beste" aan zichzelf toegeven dat hij niet feilloos is en beschermingen tegen dat soort ongelukjes inbouwen. Iemand die vindt dat hij dat niet nodig heeft loopt een grote kans om op een pijnlijke manier te leren dat ook hij het bij nader inzien toch nodig heeft. Het aanmaken van een account met beperkte rechten is in dat licht een no-brainer.

Onder het admin account kan en mag bijna alles, dus ook programma's ongecontroleerd op de achtergrond installeren, zoals troep!
Met een gebruikers account, dat niets mag installeren, ben je vele malen veiliger..............

Maar wanneer je als Admin bent ingelogd en UAC op de hoogste stand van beveiliging hebt geschoven, dan komt er toch elke keert een popup die vraagt om te bevestigen of je wel of niet iets wilt toestaan? Dan is het administrator account toch beveiligd met UAC? Wat voegt een standaard account dan nog toe?

Ik heb me er nog eens verder in verdiept en kom tot de conclusie dat er feitelijk 3 niveaus zijn in UAC:

1 - Een administrator account met UAC uitgeschakeld
2 - Een administrator account met UAC ingeschakeld
3 - Een standaard account met beperkte rechten

Optie 1 is natuurlijk het meest onveilig en optie 3 het veiligste. Maar optie 2 is wellicht het beste compromis tussen veiligheid en gebruiksgemak?

Als ik mezelf goed heb geïnformeerd dan draaien in het geval van optie 2 alle applicaties in een administrator account maar ZONDER administrator rechten!

Bron artikel hieronder: http://www.howtogeek.com/124754/htg-explains-why-you-shouldnt-disable-uac/):

"User Account Control helps fix the security architecture problems of past Windows versions. Users can use administrator accounts for day-to-day computing, but all applications running under the administrator account don’t run with full administrator access. For example, when using UAC, Internet Explorer and other web browsers don’t run with administrator privileges – this helps protect you from vulnerabilities in your browser and other applications.

The only price you pay for using UAC is seeing an occasional box that you have to click Yes to (or click No if you weren’t expecting a prompt.) This is easier than using a standard user account – you don’t have to manually launch applications as administrator, they’ll just present a UAC prompt when they require administrator access. You don’t have to type a password, either – just click a button. The UAC dialog is presented on a special, secure desktop that programs can’t access, which is why the screen appears grayed out when a UAC prompt appears"

Hier wordt dus feitelijk beweerd dat je in een administrator account kunt werken en dat alle applicaties niet met administrator rechten werken!

Zelf zie ik in onder Deze pc/eigenschappen/beveiliging ook 3 gebruikers vermeld:

1 - System
2 - NaamPC\gebruikersnaam
3 - NaamPC\Administrators

Dus ondanks het feit dat ik momenteel met slechts 1 (admin) account werk wordt er door Windows blijkbaar toch onderscheid gemaakt in de rechten waaronder applicaties draaien?

Opli het is wat gecompliceerder dan je denkt.

1/ Er zijn vele default users en groepen met Windows. High privileged processen tracht men te scheiden in risico gebieden.
https://msdn.microsoft.com/en-us/library/bb726980.aspx het is veel meer dan root en userland (standaard linux)
De ontwikkelingen met de er tussen geschakelde initd (selinux afkomstig van de NSA) Dan wel een docker ( cgroups) geeft meer recht aan high privileged services.

2/ De UAC heeft met admin/non-admin veel meer (en wat hij niet afdekt) https://support.microsoft.com/nl-nl/kb/2526083.
"One of the common misconceptions about UAC and about Same-desktop Elevation in particular is that it prevents malware from being installed or from gaining administrative rights. First, malware can be written not to require administrative rights, and malware can be written to write just to areas in the user's profile. More important, Same-desktop Elevation in UAC is not a security boundary and can be hijacked by unprivileged software that runs on the same desktop. "

Malware is niet enkel een legacy programmaatje draaien, er zijn vele andere manieren.
Het isoleren van profile en meer zaken is nodig wil je een uitweg hebben als er wat mis is.
Uit jouw artikel: "UAC won’t prompt you anywhere near as much when you’re done setting up your computer." Waarom zou met dat artgument niet gewoon voor aparte account gaan. De admin is van die twee degene die je reddingsboei is.

Het probleem met UAC, is dat er ongeveer 1 keer per maand / 2 maanden een lek word gevonden om UACte omzeilen en de ---rechten van huidige gebruiker te krijgen--- wat dus Admin if Standaard kan zijn, afhankelijk van je keuze...

Maak er maar 4 van, die laatste moet je opsplitsen in:
3a - Een standaard account waarvandaan je, bij een prompt om admin naam en wachtwoord, die gegevens invult en daarmee, in dezelfde desktopomgeving, een "privilege escalation" uitvoert (binnen dat commando), bijvoorbeeld in taakbeheer (task manager) om de processen van alle gebruikers te kunnen zien
3b - Een standaard account waarbij je dit nooit doet. In plaats daarvan log je uit en weer in maar dan als admin, of gebruik je "switch user" (in beide gevallen krijgt het admin account een veel beter gescheiden dektopomgeving met eigen clipboard etc).

Hoeveel veiliger 3a t.o.v. 2 precies is, weet ik niet. Natuurlijk is 3b het veiligst, en dat heb ik heel lang gebruikt - maar de laatste jaren (sinds ik W7 gebruik, na XP), zwicht ik toch voor 3a.

Een gescheiden admin account is onontbeerlijk als je gewone account een keer gecompromitteerd raakt of jouw persoonlijke registry hive corrupt raakt. Ik gebruik het admin account ook om een betrouwbare kopie van de (unmounted) registry hives van mijn gewone accounts te maken. Om schade door ransomware te beperken kun je files die je toch nooit meer wilt wijzigen, vanuit het admin account read-only maken (met NTFS permissies natuurlijk) voor gewone accounts. Vanuit het admin account kun je dan nog gewoon beheertaken uitvoeren, zoals verplaatsen of vetwijderen, desgewenst na bestanden te hebben gearchiveerd.

UAC is sinds Windows 7 broken doordat Microsoft eigen programma's op een whitelist zet. Je het UAC-niveau omhoog zetten om dat te verhelpen (tenminste, in Win 7 en 8 is dat zo) maar in ieder geval op Windows 8 betekent dit dat er zomaar opties uit configuratieschermen verdwijnen verdwijnen zonder dat er zelfs maar een hint is dat ze überhaupt bestaan. In Windows 8 gaat dat o.a. over de optie tot het instellen van het netwerktype (privé / bedrijf / openbaar) - slechts een van de vele dingen die uitstekend werkten onder Win7 en die MS in Win8 gesloopt heeft <insert boze rant hier>.

Om optie 3b af te dwingen, kun je UAC uitschakelen, zeker voor mensen die ietwat digibeet zijn en toch wel op doorgaan klikken omdat ze vaak niet weten waarop ze klikken en waarvoor ze toestemming moeten geven. Dit is wat ik mensen aanleer om iets meer na te denken over wat ze installeren, tenslotte kun je met je autogordel om ook niet onder de motorkap duiken.

Oke, naar aanleiding van bovenstaande adviezen heb ik besloten toch maar (weer) in een standaard account te gaan werken.

Ik heb dus een 2e account aangemaakt, een standaard account, maar nu ontstaat er een probleem. Wanneer ik mij wil aanmelden in het nieuwe account dan duurt het aanmaken van het nieuwe account heel erg lang (20 minuten of langer) en krijg ik de melding "Dit duurt iets langer dan normaal, maar is bijna gereed".

Wanneer het nieuwe account eindelijk is aangemaakt (of niet?) wordt het scherm zwart en gebeurt er helemaal niets meer...

Ik druk dan op Windows toets+L en kom in het aanmeldscherm waar ik kan kiezen voor 1 van de 2 accounts. Kies ik voor het reeds eerder gemaakte account dan kan ik gewoon inloggen en werkt alles prima. Kies ik voor het nieuwe account dan wordt het scherm weer zwart (ik zie alleen de muis).

Als ik in het zwarte scherm naar taakbeheer ga (control,alt,delete werkt dus wel) dan krijg ik de volgende foutmelding:

"OXC0000022" plus de melding dat de taak niet uitgevoerd kan worden.

Ik besef dat dit topic nu een nieuwe wending neemt, maar is er iemand die dit probleem herkent en een oplossing weet?

Gemotiveerd door de argumenten dat een apart admin account beter is heb ik de stap maar eens gewaagd (windows 7):
- Image gemaakt
- Nieuw account aangemaakt met admin rechten
- Daarvandaan rechten van de vaste gebruiker verlaagd tot 'normaal account'.

Resultaat:
- Op het admin account kan ik alles opnieuw gaan instellen zoals beeldschermgrootte, thema, startmenu etc.etc.
- Op het normale account kan ik sommige programma's niet starten, omdat ie komt met 'vraag de netwerkbeheerder om meer rechten . Als ik dat programma dan start met rechtermuisknop, starten als Admin, dan komt ie met admin password, behoorlijk omslachtig om hele gewone programma's te starten.

Als dat de boel nou veiliger zou maken zou ik zeggen: ok, maar dat is niet zo, integendeel!
Want als ik (als gewone gebruiker) in 'uitvoeren' de regedit start, vraagt ie helemaal niet meer om toestemming (via UAC), maar start de regedit direct. Hetzelfde geldt voor services.msc en bijv voor het laten uitvoeren van een .reg bestand. Niks UAC meer, wat wel het geval is indien ik aan de normale gebruiker Admin rechten toeken.

Dit is werkelijk complete onzin. Als de gebruiker GEEN admin rechten heeft, kan ie zonder meer van alles verpesten door .reg bestandjes uit te voeren. Je zou toch echt verwachten dat er dan via UAC gevraagd zou worden om een password van de admin, maar dat gebeurt dus niet. Vrije toegang om alles te verzieken.

Conclusie: dit heeft geen zin, image weer terug gezet, ik blijf werken met een admin account en hoop maar dat alle andere maatregelen (oa de laatste versie van CryptoPrevent) me zullen behoeden voor narigheid.

Je bedoelt 0xC0000022 (begint met 0x, een aanduiding dat een hexadecimaal getal volgt).

Zoeken met Google lijkt erop te wijzen dan het om een permissieprobleem gaat waardoor een bepaalde DLL niet geladen kan worden.

Staat er ook bij welke taak niet uitgevoerd kan worden?

FOUT.

Onder C:\Users\<vaste_gebruiker_naam>\ bestaat een hele mapstructuur (jouw "profiel") met bijbehorende instellingen en historie, waar je, na die laatste stap (gebruikmakend van dat account) geen toegangsrechten meer op hebt (en dat geldt ook voor jouw persoonlijke deel van het register, opgeslagen in NTUSER.DAT in die map).

Gevolg zodra je inlogt: Windows maakt een nieuwe profielmap voor je aan (naast de oude), met bijv. de naam C:\Users\<vaste_gebruiker_naam.001>\ of iets dergelijks, kopieert daarin de instellingen uit C:\Users\Default\ en zet de NTFS permissies (toegangsrechten) goed. Daarmee heb je een "nieuw" account.

Als je de groepslidmaatschappen van accounts wijzigt, is les 1 dat dit consequenties kan hebben voor toegang tot mappen, bestanden, register, software en devices.

Zie boven.

Dan zijn dat programma's die met een stomme installer zijn geïnstalleerd. Ik kom nog maar weinig programma's tegen die, na installatie door een lid van de Administrators groep, niet goed werken voor een gewoon gebruikersaccount.

Kun je wat voorbeelden geven?

Die aanname is geheel onjuist.

Ja mooi hè? Ik vind het ideaal, veel minder UAC meldingen.

Nee hoor. Je kunt alleen maar wijzigingen aanbrengen op die zaken waar je schrijfrechten op hebt. In het register bijvoorbeeld kun je alleen keys, value names en values wijzigen onder HKCU (HKEY_CURRENT_USER) of verwijzingen daarnaar (in elk geval HKEY_USERS\<jouw_SID>\, waarbij "jouw_SID" iets is als S-1-5-21-nnnnnnnnnn-nnnnnnnnnn-nnnnnnnnnn-RID en waarbij RID een uniek getal is voor jouw account terwijl al die nnn voor elk account non-standard op jouw PC hetzelfde zijn).

De UAC meldingen bij het opstarten van regedit als admin zijn betuttelend en nergens voor nodig. Die melding hoort pas te komen op het moment dat je iets probeert te wijzigen waar je geen schrijfrechten op hebt. Bijv. c:\windows\system32\lusrmgr.msc kan ik gewoon opstarten als non-admin, pas als ik iets probeer te wijzigen dat niet mag, komt de melding dat ik onvoldoende rechten heb. Zo werkt het ook bij bestandspermissies. Waarom niet bij regedit?

Nog link ook, want third-party-tools geven geen UAC melding als je als admin het register opent; je zou dan de indruk kunnen hebben dat je niets kunt wijzigen - maar je kunt ook dan gewoon jouw eigen settings (onder HKCU) wijzigen.

Nieuw in W7 (t.o.v. XP) is overigens dat je, als ordinary user, de security eventlog mag bekijken (onder XP had je ook geen leesrechten daarop).

Een non-admin account behoedt je standaard, helaas, niet voor ransomware - want ransomware versleutelt jouw bestanden en juist geen systeembestanden (dan zou je niet meer in kunnen loggen om, na betaling, je bestanden te decrypten).

Zie onderaan https://www.security.nl/posting/471698/Werken+in+admin+account%3F#posting471785 waarom ik een admin account aanraad.

Ik werk daar zelf overigens al mee sinds NT4, d.w.z. ca. 1999; toen was het wel heel vaak tobben om programma's aan de praat te krijgen die admin rechten verwachtten. Maar Borland C++ Builder en zelfs Delphi 5 heb ik zo aan de praat gekregen. Voordeel: je weet zeker dat je, als programmeur, niets per ongeluk wijzigt aan globale instellingen en/of libraries. En als je je eigen data op de D: schijf zet, en het profiel ook daarnaartoe redirect (of roaming profiles gebruikt in een serveromgeving) en schrijfrechten op C: zoveel mogelijk inperkt, hoef je drive C: alleen maar te backuppen als je een herinstallatie (of image terugzetten) teveel werk vindt.

UAC is geen security boundary en op verschillende manieren te omzeilen.
Standaard werken met een non-privileged user, en switchen naar de admin user voor specifieke noden is nog steeds de veiligste oplossing.

Erik, de taak Taskmgr.exe kan niet worden uitgevoerd. Dat is toch vreemd lijkt mij, want mijn systeem draait in het admin account prima en daar wordt dit proces toch ook gebruikt?

Ik vermoed dat dit een gevolg fout is. Waarschijnlijk was er (nog) geen "shell" en heb je geprobeerd task manager te starten (die hoort gewoon te werken voor normale gebruikers, alleen zie je dan uitsluitend de processen die onder jouw naam werken.

Heb je wellicht ooit permissies op mappen gewijzigd op jouw systeem?

Je kunt proberen sfc /scannow te draaien (als admin, vanuit een elevated command prompt, zie https://support.microsoft.com/en-us/kb/929833).

Erik, ik heb wel eens permissies op mappen veranderd ben ik bang... maar weet echt niet meer op welke.

De sfc/scannow scan heb ik gedraaid; deze heeft geen fouten gevonden.

Enig idee hoe ik nu verder kan?

Hoewel ik nog geen vergelijkbaar artikel kan vinden zoals [1] (waarin niet staat dat het ook geldt voor Windows 10), bevestigt [2] (van 1 week geleden! Hoezo is W10 nog beta en is elke huidige gebruiker een beta-tester...) dat "secedit.exe" ook meekomt met Windows 10 en kennelijk nog wordt ondersteund.

Secedit.exe is een programma dat, op basis van een database naar keuze, je systeem v.w.b. veel beveiligingsinstellingen (o.a. NTFS en registerpermissies) kan configureren. Je kunt daarmee ook een "diff" doen, d.w.z. de afwijkingen t.o.v. een gewenste situatie tonen. Het is een krachtige commandline tool, niet bepaald geschikt voor beginners.

Onderaan [3] vind je instructies die, naar verluidt, de permissies restoren naar de default waarden (gebruik op eigen risico, ik heb geen ervaring met wat op deze pagina staat - wel met secedit, maar in een ver verleden).

Overigens denk ik dat je, gezien:
- de problemen die je meldt,
- de wijzigingen die je hebt aangebracht,
- je vermoedelijk geen grondige kennis hebt van NTFS permissies en SDDL [4],
je Windows 10 waarschijnlijk beter helemaal overnieuw kunt installeren. En daarna meteen 1 of meer gewone accounts aanmaken, en het initiële admin account daarna slechts gebruiken waar het eigenlijk voor bedoeld was en is: beheertaken.

[1] https://technet.microsoft.com/en-us/library/hh875548%28v=ws.11%29.aspx
[2] https://technet.microsoft.com/en-us/itpro/windows/keep-secure/security-policy-settings
[3] https://www.winhelp.us/ntfs-permissions-in-windows.html
[4] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379567%28v=vs.85%29.aspx

Prima opgemerkt Erik over dat niet moeten veranderen van de originele asmin/eigenaar. Het is niet de zichtbare naam die leidend is voor alle interne security afhandeling maar die lange ogenschijnlijke random string. Voor opslaglocatie wordt weer wel de zichtbare naam gebruikt.

Het is net als me die nummertjes id-jes gid-jes een vertaalslag die er tussen zit. Zoiets zie je veel vaker gebeuren. Verwarrend en een valkuil voor onverwachte fouten.

Nu zal er van alles met de originele admin/eigenaar geïnstalleerd zijn en door de admin eigenschap zaken gezet zijn.

Als optie terug wil zal hij die hernoem en admin attribuut verwijdering moeten zien terug te draaien. Voor een restricted user een nieuwe zelf opgevoerde gebruiken.

Ik vraag me wel af of die string van de standaard admin niet een mogelijke aanvalsvector is. Ik verwacht dat hij overal gelijk is. Zoiets als die string van de god-mode

Vooraf: hieronder ga ik uit van een "losse" PC, d.w.z. eentje die geen lid is van een AD domein.

Van oudsher heeft het Administrator account een RID van 500 (decimaal).

Als ik me niet vergis kun je, via het netwerk, inloggen met ofwel de gebruikersnaam, ofwel de SID. Ook meen ik me te herinneren dat het computer-afhankelijke-deel van de SID kan worden opgevraagd zonder te zijn aangemeld.

Het is dus kortzichtig als je uitsluitend het Administrator account hernoemt (want als dat account een zwak of hergebruikt wachtwoord heeft, wandelt een aanvaller zo naar binnen door de SID, eindigend op "-500", te genruiken indien aanmelden met de naam "Administrator" niet lukt).

Een probleem kan ook zijn dat account lockout niet werkt op het Administrator account (of dit in de nu ondersteunde Windows versies, bij inloggen via het netwerk, nog zo is, weet ik niet uit mijn hoofd).

Wel weet ik dat, met ingang van XP, je met een account met leeg wachtwoord (ook Administrator en andere accounts die lid zijn van de groep Administrators), niet via het netwerk kunt inloggen - dus uitsluitend interactief (maar dat zou ook wel eens Remote Desktop kunnen omvatten).

In Windows hebben het Administrator en het Guest account een vaste RID (resp. 500 en 501). Van later aangemaakte accounts (dus ook het eerste account tijdens Windows installatie) is de RID een oplopend nummer dat begint met 1024.

Als je bang bent dat het Administrator account een aanvalsvector vormt, zijn er verschillende methoden om risico's te verlagen:

- Je kunt het Administrator account disablen, maar zorg dan wel dat er minstens 1 ander account bestaat dat lid is van de groep Administrators (waar je in elk geval interactie mee kunt inloggen).

- Als je alleen bang bent voor netwerkaanvallen (denk aan laptop en onveilige netwerken) kun je het Administrator account wachtwoordloos laten (maar check dan wel dat aanmelden via RDP niet werkt). Tenzij je FDE gebruikt en de PC altijd helemaal uitzet, raad ik dit overigens af.

- Idem, alleen netwerkaanvallen: je kunt het privilege om in te loggen via het netwerk verwijderen uit de groep Administrators, en dit privilege, naar keuze, toevoegen aan een of meer individuele leden van die groep - maar dan niet aan Administrator natuurlijk.

- Door het permanent disablen van de "Server" service loop je sowieso veel minder risico op netwerkgebaseerde aanvallen. Op PC's die ik beheer staat die service nooit aan.

- Je kunt natuurlijk ook een lang, uniek en niet te raden (bijv. met KeePass gegenereerd) wachwoord op het Administrator account zetten. Desnoods op een briefje geschreven in het accu compartiment of zo. Dan hoef je je ook geen zorgen te maken om brute-force aanvallen via het netwerk - ook als die eindeloos door kunnen gaan omdat account-lockout niet werkt.

Bedankt allemaal voor de tips! Ik heb van alles geprobeerd wat hierboven is aangegeven, niets helpt...

Googelen op "new user account windows black screen" leert mij dat dit probleem vaker voorkomt. Ik ben er in ieder geval nu klaar mee, ik blijf werken in mijn admin account. Mijn computer is gereedschap om mijn werk te doen, en dit alles kost veel te veel tijd voor mij.

In het verleden heb ik vaker problemen gehad met gebruikersaccounts en rechten e.d. De nieuwe installtie van W10 deze week heeft die problemen niet opgelost, dus ik ga het nu maar eens proberen in een admin account voorlopig.

Soms worden legitieme sites gehackt, zoals nu.nl (http://www.nu.nl/internet/2763447/korte-tijd-malware-verspreid-via-nunl.html) en kan je volkomen te goeder trouw toch rotzooi oplopen.
Daarom je rechten als gebruiker in principe beperken tot wat echt noodzakelijk is.

Oke, een nieuwe update van TS:

Het zat mij toch niet helemaal lekker dat werken in een admin account, dus ik heb verder gezocht op Google. Ik vond een progje om mijn Windows permissies te resetten.

Ik heb het gedraaid en warempel; daarna kon ik een nieuw gebruikersaccount aanmaken!

Blijkbaar zat daar dus het probleem, in ooit door mij aangepaste permissies!

Na het aanmaken van een het nieuwe account kreeg ik een enorme Windows update voor de kiezen, maar nu lijkt alles toch goed te werken. Ik heb het eerste admin account nu omgezet in een standaardaccount ook dat lijkt na opnieuw opstarten nu goed te werken.

Nu nog alle Windows 10 meuk (welke gedeeltelijk opnieuw is geinstaleerd) er af gooien....

Goede ingeving opti. Mooi dat je er door heen bent.. Je hoeft het niet zelf geweest te zijn kan ook malware geweest zijn.
De ervaringen of het goed blijft gaan en welk progje je gebruikt hebt kan voor een andere / lotgenoot interessant zijn. Die zal zich wel melden.