Så här inaktiverar du användarkontokontroll (UAC) på Windows Server

• 20/08/2020
• 8 minuter att läsa
• • D
  • s

Den här artikeln introducerar hur du inaktiverar UAC (User Account Control) på Windows Server.

Originalproduktversion: Windows Server 2012 R2
Original KB-nummer: 2526083

Sammanfattning

Under vissa begränsade omständigheter kan inaktivera UAC på Windows Server vara en acceptabel och rekommenderad metod. Dessa omständigheter inträffar endast när alla följande villkor är uppfyllda:

• Endast administratörer får logga in på den Windows-baserade servern interaktivt på konsolen eller genom att använda fjärrskrivbordstjänster.
• Administratörer loggar bara in på den Windows-baserade servern för att utföra legitima systemadministrationsfunktioner på servern.

Om något av dessa villkor inte är sant bör UAC förbli aktiverat. till exempel, om servern aktiverar rollen Remote Desktop Services så att icke-administrativa användare kan logga in på servern för att köra applikationer, bör UAC förbli aktiverad. På samma sätt bör UAC förbli aktiverad om administratörer kör riskabla applikationer på servern som webbläsare, e-post klienter eller klienter för snabbmeddelanden, eller om administratörer utför andra åtgärder som bör göras från ett klientoperativsystem som Windows 7.

Mer information

UAC utformades för att hjälpa Windows-användare att gå mot att använda standard användarrättigheter som standard. UAC innehåller flera tekniker för att uppnå detta. Dessa tekniker inkluderar följande:

• Virtualisering av filer och register: När ett äldre program försöker skriva till skyddade områden i filsystemet eller i registret, omdirigerar Windows tyst och öppet åtkomsten till en del av filsystemet eller registret som användaren får ändra. Detta gör att många applikationer som kräver administrativa rättigheter för tidigare versioner av Windows kan köras framgångsrikt med endast standardanvändarrättigheter på Windows Server 2008 och senare versioner.
• Samma skrivbordshöjd: När en auktoriserad användare kör och höjer ett program , den resulterande processen beviljas mer kraftfulla rättigheter än den för den interaktiva skrivbordsanvändaren. Genom att kombinera höjd med UAC: s Filtered Token-funktion (se följande punkt) kan administratörer köra program med standardanvändarrättigheter och sedan endast höja de program som kräver administrativa rättigheter med samma användarkonto. (Den här samma användarhöjningsfunktionen är även känd som Admin Approval Mode.) Program kan också startas med förhöjda rättigheter genom att använda ett annat användarkonto så att en administratör kan utföra administrativa uppgifter på en standardanvändares skrivbord.
• Filtrerad token: När en användare som har administrativa eller andra kraftfulla behörigheter eller gruppmedlemskap loggar in, Windows skapar två åtkomsttoken för att representera användarkontot. Den ofiltrerade token har alla användarens gruppmedlemskap och privilegier, medan den filtrerade token representerar användaren med motsvarande standardanvändarrättigheter. Som standard används den filtrerade token för att köra användarens program. Den ofiltrerade token är endast associerad med förhöjda program. Ett konto som är medlem i gruppen Administratörer och som tar emot en filtrerad token när användaren loggar in kallas ett skyddat administratörskonto.
• UIPI (User Interface Privilege Isolation): UIPI förhindrar ett program med lägre privilegier från att skicka fönstermeddelanden som syntetiska mus- eller tangentbordshändelser till ett fönster som tillhör en högre privilegierad process och genom att styra den högre privilegierade processen.
• Protected Mode Internet Explorer (PMIE): PMIE är en fördjupad försvarsfunktion där Windows Internet Explorer arbetar i lågprivilegierat skyddat läge och inte kan skriva till de flesta områden i filsystemet eller i registret. Som standard är skyddat läge aktiverat när en användare surfar på webbplatser i Internet- eller Restricted Sites-zoner. PMIE gör det svårare för skadlig kod som infekterar en löpande instans av Internet Explorer att ändra användarens inställningar, till exempel genom att konfigurera sig själv för att starta varje gång användaren loggar in. PMIE är faktiskt inte en del av UAC. Det beror dock på UAC-funktioner som UIPI.
• Detektering av installatör: När en ny process håller på att startas utan administrativa rättigheter tillämpar Windows heuristik för att avgöra om den nya processen sannolikt kommer att vara en äldre installation program. Windows antar att äldre installationsprogram sannolikt kommer att misslyckas utan administrativa rättigheter.Därför uppmanar Windows proaktivt den interaktiva användaren att höja. Om användaren inte har administrativa referenser kan inte användaren köra programmet.

Om du inaktiverar användarkontokontrollen: Kör alla administratörer i policyinställningen för administratörsgodkännande, avaktiverar alla UAC-funktioner som beskrivs i det här avsnittet. Denna policyinställning är tillgänglig via datorns lokala säkerhetspolicy, säkerhetsinställningar, lokala policyer och sedan säkerhetsalternativ. Äldre applikationer som har standardanvändarrättigheter som förväntar sig att skriva till skyddade mappar eller registernycklar misslyckas. Filtrerade tokens skapas inte och alla program körs med fullständiga rättigheter för användaren som är inloggad på datorn. Detta inkluderar Internet Explorer eftersom skyddat läge är inaktiverat för alla säkerhetszoner.

En av vanliga missuppfattningar om UAC och i synnerhet om Same-desktop Elevation är att det förhindrar att malware installeras eller från att få administrativa rättigheter. För det första kan malware skrivas för att inte kräva administrativa rättigheter, och malware kan skrivas för att skriva bara till områden i användarens profil. Ännu viktigare, Samma skrivbordshöjning i UAC är inte en säkerhetsgräns och kan kapas av okontrollerad programvara som körs på samma skrivbord. Samma skrivbordshöjning bör betraktas som en bekvämhetsfunktion, och ur ett säkerhetsperspektiv bör skyddad administratör övervägas. motsvarande administratör. Däremot innebär användning av snabb användarbyte för att logga in på en annan session med ett administratörskonto en säkerhetsgräns mellan administratörskontot och standardanvändarsessionen.

För en Windows-baserad server där den enda anledningen till interaktiv inloggning är att administrera systemet, är målet om färre höjdmeddelanden inte genomförbart eller önskvärt. Systemadministrativa verktyg kräver legitimt administrativa rättigheter. När alla administrativa användares uppgifter kräver administrativa rättigheter och varje uppgift kan utlösa en höjdprompt är uppmaningarna bara ett hinder för produktiviteten. I detta sammanhang kan sådana uppmaningar inte främja målet att uppmuntra utveckling av applikationer som kräver vanliga användarrättigheter. Sådana uppmaningar förbättrar inte säkerhetsställningen. Istället uppmuntrar dessa uppmaningar bara användarna att klicka igenom dialogrutor utan att läsa dem.

Denna vägledning gäller endast välhanterade servrar där endast administrativa användare kan logga in interaktivt eller via fjärrskrivbordstjänster, och endast för utföra legitima administrativa funktioner. Om administratörer kör riskabla applikationer som webbläsare, e-postklienter eller snabbmeddelandeklienter eller utför andra åtgärder som ska utföras från ett klientoperativsystem, bör servern anses motsvara ett klientsystem. I det här fallet bör UAC förbli aktiverat som ett djupgående försvar.

Om standardanvändare loggar in på servern på konsolen eller via fjärrskrivbordstjänster för att köra applikationer, särskilt webbläsare, UAC bör förbli aktiverat för att stödja fil- och registervirtualisering och även Protected Mode Internet Explorer.

Ett annat alternativ för att undvika höjdmeddelanden utan att inaktivera UAC är att ställa in användarkontokontroll: Uppförande av höjdprompten för administratörer i Admin Godkännandes säkerhetspolicy till Elevate utan uppmaning. Genom att använda den här inställningen godkänns höjdförfrågningar tyst om användaren är medlem i administratörsgruppen. Det här alternativet gör också att PMIE och andra UAC-funktioner är aktiverade. Men inte alla åtgärder som kräver administrativa rättigheter begär förhöjning. Att använda den här inställningen kan resultera i att vissa av användarens program lyfts upp och andra inte, utan att det går att skilja mellan dem. De flesta konsolverktyg som kräver administrativa rättigheter förväntar sig att startas vid en kommandotolk eller annat program som är Sådana verktyg misslyckas bara när de startas vid en kommandotolk som inte är förhöjd.

Ytterligare effekter av att inaktivera UAC

• Om du försöker använda Windows Explorer för att bläddra till en katalog där du inte har läsbehörigheter, Explorer kommer att erbjuda att ändra katalogens behörigheter så att ditt användarkonto får tillgång till det permanent. Resultaten beror på om UAC är aktiverat. Mer information finns i När du klicka på Fortsätt för mappåtkomst i Windows Explorer, ditt användarkonto läggs till i ACL för mappen.
• Om UAC är inaktiverat fortsätter Windows Explorer att visa UAC-sköldikoner för objekt som kräver höjd och att inkludera Kör som administratör i sammanhangsmenyer för applikationer och programgenvägar. Eftersom UAC-höjdmekanismen är inaktiverad har dessa kommandon ingen effekt och applikationer körs i samma säkerhetskontext som användaren som är inloggad på.
• Om UAC är aktiverat, när konsolverktyget Runas.exe används för att starta ett program med ett användarkonto som är föremål för tokenfiltrering, programmet körs med användarens filtrerade token. Om UAC är inaktiverat körs programmet som startas med användarens fulla token.
• Om UAC är aktiverat kan lokala konton som är föremål för tokenfiltrering inte användas för fjärradministration via andra nätverksgränssnitt än Remote Desktop (till exempel via NET USE eller WinRM). Ett lokalt konto som autentiserar över ett sådant gränssnitt får endast de behörigheter som beviljas kontots filtrerade token. Om UAC är inaktiverad tas denna begränsning bort. (Begränsningen kan också tas bort med inställningen LocalAccountTokenFilterPolicy som beskrivs i KB951016.) Att ta bort denna begränsning kan öka risken för systemkompromiss i en miljö där många system har en administrativ lokal konto som har samma användarnamn och lösenord. Vi rekommenderar att du ser till att andra begränsningar används mot denna risk. Mer information om rekommenderade begränsningar finns i Mitigating Pass-the-Hash (PtH) -attacker och annan referensstöld, version 1 och 2.
• PsExec, användarkontokontroll och säkerhetsgränser
• När du väljer Fortsätt för mappåtkomst i Utforskaren läggs ditt användarkonto till ACL för mappen (KB 950934)