21 De tre viktigaste kontona: Administratör//Administrator, Gäst/ /Guest och System//System

Transkript

1 21 De tre viktigaste kontona: Administratör//Administrator, Gäst/ /Guest och System//System Förinstallerade konton De båda förinstallerade kontona Administratör//Administrator och Gäst//Guest visas i Kontohanteraren för domäner//user Manager for Domains. (Notera att kontot Gäst//Guest gjorts om till ett domänlokalt konto.) När Windows NT 3.51 eller 4.0 installeras upprättas alltid två användarkonton: Administratör//Administrator och Gäst//Guest. I Windows NT 3.51förinstalleras ytterligare ett konto Windows NT 3.51 fungerar litet annorlunda än Windows NT 4.0. När man installerar Windows NT Workstation 3.51 eller Windows NT Server 3.51 som ren server/medlemsserver i en domän eller i en datorarbetsgrupp upprättas ett tredje konto vid installation. Detta konto har inget förutbestämt namn utan det bestäms av den som installerar. Kontot görs, av Windows NT, till medlem av gruppen Administratörer//Administrators. Microsofts tanke med detta konto var, förmodligen, att det skulle användas i stället för kontot Administratör//Administrator. Det är synd att Microsoft tog bort detta konto i Windows NT 4.0 det hade nästan varit bättre att ta bort Administratör//Administrator eftersom det senare kontot är något för magiskt för min smak. 781

2 21 Kontona Administratör//Administrator, Gäst//Guest och System//System Administratör//Administrator I Windows NT-nätverk finns det många konton med namnet Administratör//Administrator På alla Windows NT-datorer med egen kontodatabas (d.v.s. alla Windows NT Workstation-datorer och alla fristående Windows NT Server-datorer, alltså alla icke-domänkontrollanter) finns det ett konto som vid installation ges namnet Administratör//Ad ministrator. Administratör//Administrator är allsmäktigt inom sin egen kontodatabas eftersom det är medlem av den lokala gruppen Administratörer//Administrators (det finns en sådan i varje kontodatabas). Det finns inget sätt för detta konto att verka utanför sin egen kontodatabas (det kan endast domänkontot Administratör//Administrator). Kanske har du, trots det just sagda, märkt att du kan vara inloggad med kontot Administratör//Administrator på en Windows NT-dator och komma åt en annan Windows NT-dator? Det går alldeles utmärkt så länge de olika kontona Administratör//Administrator har samma lösenord. Det går bra även mellan fristående Windows NT-domäner så länge lösenordet är det samma, något jag betraktar som en allvarlig felaktighet i Windows NT det borde spela roll vilken domän ett konto kommer från, inte enbart om det råkar finnas ett konto med samma kontonamn och lösenord i den egna domänen. I Windows NT 4.0 är det möjligt att ta bort kontot Administratör//Administrator från den lokala gruppen Administratörer/ /Administrators vilket kan vara ett sätt att höja säkerheten på Windows NT-datorer i oskyddade miljöer. Det som förenar alla dessa konton med namnet Administratör//Administrator är att deras SID har ett mycket likartat utseende. Det är inte hela SID som är lika, men de har samtliga samma RID, 500. Några exempel på olika SID för Administratör//Administrator på olika Windows NT-datorer: S S S S

3 Administratör//Administrator Denna egenskap gör kontot en smula sårbart eftersom det inte är alltför svårt för en programmerare att ta reda på en Windows NT-dators grund-sid (delen före RID). Oavsett vad kontot Administratör//Administrator har för namn kan då en inkräktare fråga Windows NT-datorn efter namnet på kontot med SID = grund-sid-500. Slika program finns tillgängliga på Internet. Dock är det en allmänt vedertagen sanning att kontot Administratör//Administrator bör döpas om det håller en del inkräktare borta. Det finns bara ett domänkonto med namnet Administratör//Administrator I en Windows NT-domän finns det minst ett konto med namnet Administratör//Administrator. Troligen är inte detta det enda kontot med namnet, men detta konto har som sin grund-sid domänens grund-sid. Domänens grund-sid är samma som den primära domänkontrollantens grund-sid, det finns inget sätt att skilja dem åt. Liksom man kan säga att den primära domänkontrollanten bjuder domänen på sin kontodatabas utrymme för att i stället lagra hela domänens kontodatabas på detta ställe bjuder den också på sin grund-sid för att låta den bli hela domänens grund-sid. Domänkontot Administratör//Administrator har samma egenskap som alla andra domänkonton: det kan användas på alla datorer i hela domänen. Detta gör domänkontot Administratör/ /Administrator mäktigare än alla andra konton i domänen med samma namn. Det är alltså fullt möjligt i en icke-domänkontrollant att den lokala gruppen Administratörer//Administrators har två medlemmar med samma kontonamn: det lokala kontot Administratör/ /Administrator och domänkontot Administratör//Administrator. I de fall en lokal grupp har medlemmar som inte härstammar från samma kontodatabas visas detta genom att domännamnet skrivs före kontonamnet, följt av ett omvänt snedstreck: 783

4 21 Kontona Administratör//Administrator, Gäst//Guest och System//System När en medlem av en lokal grupp kommer från en annan kontodatabas än den egna visas alltid namnet på den andra domänen. När en Windows NT-dator just blivit medlem av en Windows NT-domän som icke-domänkontrollant ser medlemskapet i den lokala gruppen Administratörer//Administrators ut så här: När en icke-domänkontrollant görs till medlem av en Windows NT-domän kommer domänens globala grupp Domänadministratörer//Domain Admins att göras till medlem av den lokala gruppen Administratörer/ /Administrators. De lokala kontona Administratör//Administrator är allsmäktiga i sina egna kontodatabaser All den kraft som finns i kontot Administratör//Administrator fås genom medlemskap i den lokala gruppen Administratörer/ /Administrators. Tack vare detta medlemskap kan Administratör//Administrator användas för att hantera säkerhetsprinciper, upprätta, ändra och ta bort användarkonton och grupper, lägga till eller ta bort operativsystemstillägg, dela ut och ansluta till mappar, installera och ansluta till skrivare, partitionera och formatera hårddiskar, med mera. På samma sätt ges en domänadministratör makt på ickedomänkontrollanter: hennes användarkonto är med i den globala gruppen Domänadministratörer//Domain Admins vilken i sin tur är med i alla icke-domänkontrollanters lokala grupp Admini stratörer//administrators. Detta medlemskap hänger dock på en skör tråd: medlemskapet i den lokala gruppen Administratörer/ 784

5 Gäst//Guest /Administrators. Om den globala gruppen Domänadministratörer/ /Domain Admins tas bort från Administratörer//Administrators upphör domänadministratörers makt över datorn. De enda lokala konton som har makt att ta bort Domänadministratörer//Domain Admins från Administratörer//Administrators är medlemskonton i Administratörer//Administrators. Var alltså försiktig med vems konto som görs till medlem av denna grupp (vem som känner till lösenordet för det lokala kontot Administratör//Administrator). Vad gäller makt är det inget som skiljer kontot Administratör/ /Administrator från vilket annat konto som helst som också är medlem av Administratörer//Administrators. Den stora skillnaden mellan Administratör//Administrator och de administratörskonton du själv upprättar är att Administratör//Administrator inte kan låsas ute från inloggning oavsett hur många felaktiga inloggningsförsök någon gör med kontot. Med hjälp av verktyget PassProp i Windows NT Server 4.0 Resource Kit kan du ordna så att Administratör//Administrator låses ute vid för många felaktiga inloggningsförsök över nätverket, men inte lokalt (läs i kapitel 16 hur du använder PassProp). Kontot Administratör//Administrator kan ges ett annat namn, men det kan aldrig tas bort. I en miljö där säkerheten sitter i främsta rummet byter man ofta namn på detta konto för att inte bjuda på ett kontonamn för den som olovligen försöker ta sig i in i systemet. Gruppen Administratörer//Administrators får sin makt av Microsoft I kapitlen om grupper och användarrättigheter framgår det att den lokala gruppen Administratörer//Administrators får mycket av sin makt från indirekta/osynliga användarrättigheter. Det finns inte något sätt att göra någon annan grupp tillnärmelsevis lika mäktig som Administratörer//Administrators, vilket gör att du måste använda den för administration. Gäst//Guest Kontot Gäst//Guest får de rättigheter och behörigheter som åsatts gruppen Gäster//Guests. Kontot Gäst//Guest kan göra det enkelt och bekvämt för de användare som bara vid enstaka tillfällen behöver använda ett system. 785

6 21 Kontona Administratör//Administrator, Gäst//Guest och System//System Vid installation får kontot Gäst//Guest ett tomt lösenord vilket är ett mycket dåligt val av Microsoft. Kontot Gäst//Guest kan, liksom Administratör//Administrator, ges ett annat namn, men det kan aldrig tas bort. I Windows NT 4.0 är kontot Gäst//Guest inaktiverat efter installation (gäller både Windows NT Workstation 4.0 och Windows NT Server 4.0). Windows NT 3.51 är återigen litet annorlunda: på Windows NT Workstation 3.51 är kontot Gäst//Guest aktiverat efter installation, inte på Windows NT Server Aktivera aldrig kontot Gäst//Guest (nästan aldrig) Alltid när jag berättar om kontot Gäst//Guest blir jag upprörd och vred jag har svårt att förstå att Microsoft förser Windows NT med en trojansk häst (bästa liknelsen för kontot Gäst//Guest). Du minns säkert att den trojanska hästen användes för att smuggla in grekiska krigare i det befästa Troja (samma natt slank de ur hästen och kunde besegra trojanerna). Precis så kan kontot Gäst//Guest användas: om det aktiveras (med tomt lösenord) kan administratörer inte se vem som bereder sig tillträde till domänen allt de ser är att kontot Gäst//Guest använts. Ett aktivt Gäst//Guest-konto har en nästan löjlig effekt Att aktivera kontot Gäst//Guest är att begå säkerhetsmässigt självmord. Hela säkerhetstänkandet i Windows NT-domäner skakas i sina grundvalar. Låt oss se vad som händer på en dator där gruppen Alla/ /Everyone har tilldelats användarrättigheten Åtkomst till den här datorn från nätverket//access this computer from network. Det finns två fall: 1. Användaren som försöker komma åt datorn har ett domänkonto i samma domän eller i en domän till vilken datorns domän har domänkoppling 2. Den användaren som försöker komma åt datorn har inte ett konto enligt första fallet (hon kanske finns på Internet, det kan vara en nätbuse) Om användaren i det första fallet uppger fel lösenord kommer hon att nekas åtkomst eftersom hennes konto finns, men lösenordet är fel. Håll i dig nu: oavsett vilket lösenord som uppges i det andra fallet medges tillträde till datorn (förutsatt att kontot 786

7 System//System (LocalSystem//LocalSystem) Gäst//Guest är aktivt och inte har ett lösenord)! Så här gör Windows NT när någon försöker nå en dator över nätverket: 1. Kontrollera med egen eller domänkontodatabas om användarkontot finns och om lösenordet i så fall stämmer. 2. Om kontot inte finns, kontrollera om kontot Gäst//Guest är aktivt. Om det är aktivt och saknar lösenord medges tillträde. 3. Om konto Gäst//Guest är aktivt och har ett lösenord kommer personen ombedjas uppge lösenordet (hon får också tillfälle att uppge sitt kontonamn, men det räcker med lösenordet för Gäst//Guest). Använd både hängslen och livrem Sätt ett svårt lösenord på Gäst//Guest så är du skyddad om kontot råkar aktiveras. Jag har t.o.m. sett någon föreslå att man skall inaktivera kontot, sätta dess bäst-före-datum till ett gånget datum, endast låta det logga in till en dator som inte finns (kanske!!-- --!! eller liknande). Om Gäster//Guests inte har Lokal inloggning//log on locally Om Gäster//Guests inte har användarrättigheten Lokal inloggning//log on locally uppträder något ganska (o)lustigt när man kopplar sig till den datorn om man uppger ett användarnamn som inte finns får man meddelandet: User has not been granted the requested logon type. Detta beror på att Windows NT alltid uppfattar okända konton som om de vore kontot Gäst//Guest enligt ovan. System//System (LocalSystem//LocalSystem) Specialkontot System//System är mycket riktigt ett väldigt speciellt konto. Det används vid installation av Windows NT, vid ändringar i kontodatabasen och av många (för att inte säga alla) tjänster//services (i Windows NT 3.51 var det tydligt eftersom titelraden i Programhanteraren//Program Manager innehöll dess hela kontonamn: NT Authority\System). Windows NT genomsyras av System och dess verkningar: när en administratör upprättar konton eller hanterar kontodatabasen 787

8 21 Kontona Administratör//Administrator, Gäst//Guest och System//System på något sätt är det alltid System som gör det på uppdrag av administratören. Detta syns tydligt i Registret//Registry där System anges som ägare till de delar av kontodatabasen som upprättades vid installation: kontona Administratör//Administrator, Gäst//Guest, alla inbyggda lokala grupper (Administratörer//Administrators, m.fl.), globala grupper på en primär domänkontrollant samt datorkontot för Windows NT-datorn. Samband mellan System//System och LocalSystem// LocalSystem På olika ställen i Windows NT ser du namnen System//System och LocalSystem//LocalSystem. När du hanterar lokal behörighet eller delningsbehörighet använder du System//System (där uppträder den som en grupp), när du hanterar användarkonton för tjänster//services ser du istället namnet LocalSystem//Local- System. Specialkontot System//System och LocalSystem//LocalSystem är samma konto (samma SID). System//System är namnet på själva kontot, LocalSystem//LocalSystem är kontots fullständiga namn. Det kanske blir klarare om jag visar denna, tänkta, bild från Kontohanteraren//User Manager: Om specialkontot System//System kunde betraktas i Kontohanteraren/ /User Manager skulle det se ut som i bilden. System//System är med i Administratörer//Administrators System//System är en sorts hedersmedlem i den lokala gruppen Administratörer//Administrators. När jag skriver hedersmedlem menar jag att det är fullvärdig medlem vad gäller privilegier, men tack vare sin status som specialkonto i Windows NT det inte avlägsnas från Administratörer//Administrators. Det finns heller inget enkelt sätt att avgöra att System//System faktiskt är medlem av Administratörer//Administrators. Ett sätt är att starta ett AT-jobb med växeln /interactive (om specialkontot 788

9 System//System (LocalSystem//LocalSystem) System//System används av tjänsten Schedule) och låta det starta en kommandotolk. Har man sedan tillgång till ett program som kan visa innehållet i nyckelkorten (Access Token) som delas ut vid inloggning (i detta fall lokal inloggning) ser man att System//System faktiskt räknas till gruppen Administratörer//Ad ministrators. (Jag har skrivit ett sådant program, men det är inte lämpat för allmänt bruk i sitt nuvarande skick.) System//System är inte med i Domänadministratörer//Domain Admins För den som använder globala grupper för tilldelning av behörigheter och användarrättigheter kan det vara skönt att veta att System//System inte är medlem i den globala gruppen Domänadministratörer//Domain Admins. Det är alltså riskfritt att använda denna grupp i behörighetsposter, vad gäller System/ /System. System//System är tilldelat många användarrättigheter//user rights Specialkontot System//System är tilldelat många användarrättigheter. Du kan dock inte använda Kontohanteraren//User Manager för att undersöka vilka användarättigheter eftersom kontot System//System inte visas i Kontohanteraren för domäner//user Manager for Domains. Det har tilldelats alla användarrättigheter utom Fjärravsluta Windows NT, Lägg till arbetsstationer till domän och Studera systemprestanda (samt förmodligen inte heller Åtkomst till den här datorn via nätverket). Dessa privilegier kan inte vi förändra, vi kan inte neka det medlemskap i Administratörer/ /Administrators och vi kan inte heller avlägsna de tilldelade användarrättigheterna. System//System kan inte användas för att nå en annan dator över nätverket LocalSystem//LocalSystem är det fullständiga namnet för specialkontot System//System. Det är ett träffande namn (tack för det, Microsoft) som väl beskriver en utmärkande egenskap för LocalSystem//LocalSystem: det kan inte användas för att nå andra datorer över nätverket. Det vill säga, om du har behov av att starta ett AT-jobb som ansluter till en annan dator över 789

10 21 Kontona Administratör//Administrator, Gäst//Guest och System//System nätverket kan du inte använda System//System som konto för tjänsten Schedule. (Du skulle i och för sig kunna använda verktyget SU från Resource Kit för att logga in som en annan användare och låta tjänsten Schedule fortsätta använda System/ /System.) System//System har inget lösenord Specialkontot System//System har inget lösenord, så om det bara funnes ett sätt ange detta konto vid inloggning skulle en datorbuse kunna ställa till med mycket skada. Det finns inget sätt att ändra detta tomma lösenord. När tjänster använder System//System kan man visserligen ange ett lösenord, men det används inte av Windows NT. Tjänster använder System//System Tjänster//Services i Windows NT använder alltid (om ingen ändrat) specialkontot System//System som användarkonto. (Läs mer i kapitel 10 om tjänster.) Nästa inga tjänster behöver använda System//System Olika tjänster har olika behov av privilegier på en Windows NT-dator. Om det inte är alltför opraktiskt kan du använda ett enda konto, men inte specialkontot System//System för alla tjänster. Det svåra är att ta reda på vilka privilegier de olika tjänsterna behöver. Det minsta du bör göra är att byta användarkonto för tjänsten Schedule (AT-jobb), se mer nedan. Vilken lokal behörighet behöver System//System Det är vanligt att man likställer specialkontot System//System med gruppen Administratörer//Administrators vad gäller lokal behörighet. Med tanke på att System//System är livstidsmedlem i just den gruppen borde det inte finnas någon anledning att ha en särskild behörighetspost för System//System, men det gör det. Eftersom System//System används av tjänster kan vi begränsa åtkomst för System//System till de mappar där den verkligen måste kunna hantera filer. Det gör vi på följande sätt: I de mappar som System//System inte har något att skaffa lägger vi till en post i den lokala behörighetslistan: System//System: Ingen behörighet//no Access 790

11 Kontona har känd RID, System//System känd SID Denna post ser till att specialkontot inte får någon som helst tillgång till mappen. I de mappar som System//System behöver tillgång gör vi på ett annat sätt, antingen använder vi Administratörer//Administrators eller System//System direkt. Här ser vi en stor fördel med att i stället använda den globala gruppen Domänadministratörer//Domain Admins i behörighetsposter: System//System är inte medlem av denna grupp och får alltså inte del av dess behörighet. Tjänsten Schedule är måltavla för inkräktare Kontot System//System är tilldelat samtliga användarrättigheter och det är med i gruppen Administratörer//Administrators, vilket gör det mäktigare än Administratör//Administrator. Det finns ju inget sätt att påverka System//System vad gäller användarrättigheter (en administratör kan inte ta bort dem) eller medlemskapet i Administratörer//Administrators. Du vet också att tjänsten Schedule (AT-jobb) använder specialkontot System//System om du inte ändrar detta. Detta tillsammans gör att en inkräktares högsta dröm är att kunna starta en kommandotolk eller ett annat program (Kontohanteraren//User Manager) på en Windows NT-dator med hjälp av Schedule (AT). Du bör alltså välja ett annat konto som användarkonto för Schedule. Tänk först igenom vilken makt kontot måste ha på datorn för att kunna sköta sina åligganden. Kontona har känd RID, System//System känd SID De båda kontona Administratör//Administrator och Gäst//Guest har alltid samma RID, oavsett om de upprättas på en Windows NT Workstation eller en primär domänkontrollant. Specialkontot System//System, å sin sida, har alltid samma SID: Användarkonto SID RID (hex) Administratör/- S n1-n2-n (0x1F4) /Administrator Gäst//Guest S n1-n2-n (0x1F5) System//System S

12 21 Kontona Administratör//Administrator, Gäst//Guest och System//System Du kanske undrar hur Windows NT vet att kontot Administratör/ /Administrator har RID = 500 och kontot Gäst//Guest har RID = 501. Svaret är att Microsoft har bestämt att dessa konton (och flera andra konton och grupper) skall ha bestämda och på förhand givna värden på RID. Du kommer att märka att alla inbyggda (av Microsoft förinstallerade) konton och grupper samtliga har en RID-del som är mindre än När Windows NT installeras sätter Microsoft RID-räknaren till 1000 så att det första kontot eller gruppen vi själva upprättar får RID = 1000 (även datorkonton har en SID så det kan hända att ett sådant får den första RID:en, ex. om du installerar en PDC). Det är lättare att spara information om att kontona med RID = 500 och 501 är Administratör//Administrator och Gäst//Guest än att spara den RID som användare givit konton med speciella egenskaper. Därför kan de inte tas bort. Gäst//Guest kan dock göras om till ett domänlokalt konto (även Administratör//Administrator). Om man bara skall tänka i termer av allt skall gå fort måste det gå mycket snabbare att jämföra ett kontos RID med att fast värde (500 eller 501) än ett sparat värde. Dessutom om RID för Administratör och Gäst sparades i Registret//Registry skulle någon datorbuse kunna ändra denna information så att ett annat konto uppfattades som Administratör//Administrator. Kontot System//System har en SID som inte alls ser ut som ett vanligt kontos eller en vanlig grupps SID. Med ledning av det jag tidigare skrivit drar man slutsatsen att det inte är Kontohanteraren//User Manager (i någon form) som upprättat System//System (dennas konton börjar alltid S ). Däremot, siffran fem i SID:en anger att det är ett Windows NT-konto. Du kommer att få stifta bekantskap med SID:ar som hör grupper till vilka Windows NT anser höra världen till i kapitel 23. Hjälpfrågor 1. Hur många olika konton med namnet Administratör//Administrator (och RID = 500) finns det sammanlagt i en viss Windows NT-domän? 2. Varför har alla konton Administratör//Administrator RID 792

13 Hjälpfrågor = 500? 3. Vad är det som gör Administratör//Administrator på den primära domänkontrollanten speciellt? 4. Vad händer om man avlägsnar den globala gruppen Domänadministratörer//Domain Admins ur den lokala gruppen Administratörer//Administrators på domänkontrollanterna (på den primära domänkontrollanten)? 5. Vad händer om man avlägsnar den globala gruppen Domänadministratörer//Domain Admins ur den lokala gruppen Administratörer//Administrators på en icke-domänkontrollant? 6. Finns det något sätt som gör att kontot Administratör//Administrator kan låsas ute vid för många felaktiga inloggningsförsök? 7. Är det möjligt att avlägsna privilegier från kontot Administratör//Administrator? 8. Författaren anser att det enda som borde hända om domänkontot Gäst//Guest aktiveras är att just detta konto kan användas för inloggning i domänen, inget mer. Vad händer egentligen? 9. Kan kontot Gäst//Guest helt tas bort? 10.Vad kan man göra för att minska skadorna om man skulle råka aktivera Gäst//Guest? 11.Kan kontot System//System helt tas bort? 793

14 21 Kontona Administratör//Administrator, Gäst//Guest och System//System 12.Vad är det som gör kontot System//System så speciellt? 13.Eftersom System//System är med i Administratörer//Administrators är det svårt att stänga det ute från mappar man inte vill att det skall ha tillgång till, eller? 14.Varför bör inte tjänster//services använda kontot System/ /System? 15.Hur förhåller sig namnen System och LocalSystem till varandra? 794

15 Förslag till svar på frågor Förslag till svar på frågor 1. Hur många olika konton med namnet Administratör//Administrator (och RID = 500) finns det sammanlagt i en viss Windows NT-domän? Minst ett (på den primära domänkontrollanten)! I en Windows NT-domän finns det ett konto vid namn (ursprungligt) Administratör//Administrator i varje unik kontodatabas på Windows NT-datorerna. Den primära domänkontrollanten (PDC) och reservdomänkontrollanterna delar på samma kontodatabas så de delar alltså på ett konto vid namn Administratör//Administrator. Alla Windows NT Workstation och alla Windows NT Server installerade som fristående server (icke-domänkontrollanter) har sina egna kontodatabaser med ett konto benämnt Administratör//Administrator i varje. 2. Varför har alla konton Administratör//Administrator RID = 500? Alla konton vid namn Administratör//Administrator har RID = 500 därför att Microsoft reserverat denna RID för detta konto. Inga andra konton eller grupper har RID = 500. Alla konton och grupper vi själva upprättar får RID = 1000 och högre. 3. Vad är det som gör Administratör//Administrator på den primära domänkontrollanten speciellt? Administratör//Administrator på den primära domänkontrollanten är det enda inbyggda administratörskontot som kan verka över hela domänen, på alla Windows NT-datorer. Detta konto är medlem av den inbyggda globala gruppen Domänadministratörer//Domain Admins vilken i sin tur är medlem av domänens alla grupper vid namn Administratörer//Administrators. På så sätt är detta konto unikt (vid 795

16 21 Kontona Administratör//Administrator, Gäst//Guest och System//System installation, sedan kan man lätt göra fler systrar till det, det finns dock en egenskap som just detta konto är ensamt: det kan inte låsas ute). 4. Vad händer om man avlägsnar den globala gruppen Domänadministratörer//Domain Admins ur den lokala gruppen Administratörer//Administrators på domänkontrollanterna (på den primära domänkontrollanten)? All kraft hos administratörer utgår från medlemskap i den lokala gruppen Administratörer//Administrators genom direkt eller indirekt medlemskap. Om den globala gruppen Domänadministratörer//Domain Admins tas bort ut den lokala gruppen Administratörer//Administrators har administratörerna inte längre någon makt över domänkontrollanterna (om det inte finns något administratörskonto som självt är medlem av Administratörer//Administrators). Kanske är det därför som Microsoft alltid gör kontot Administratör//Administrator till medlem av Administratörer//Administrators? 5. Vad händer om man avlägsnar den globala gruppen Domänadministratörer//Domain Admins ur den lokala gruppen Administratörer//Administrators på en icke-domänkontrollant? Om man avlägsnar den globala gruppen Domänadministratörer//Domain Admins ur den lokala gruppen Administratörer//Administrators på en icke-domänkontrollant förlorar domänens administratörer all makt över den Windows NTdatorn. Var alltså försiktig med vilka som ges tillgång till kontot Administratör//Administrator på icke-domänkontrollanter. 6. Finns det något sätt som gör att kontot Administratör//Administrator kan låsas ute vid för många felaktiga inloggningsförsök? Med hjälp av verktyget PassProp från Microsoft Windows NT Resource Kit kan man ställa in Windows NT så att kontot Administratör//Administrator kan låsas ute vid för många felaktiga inloggningsförsök. Denna utelåsning påverkar endast nätverksinloggning vilket verkar sunt då attacker oftast torde komma den vägen. 7. Är det möjligt att avlägsna privilegier från kontot Administratör//Administrator? De privilegier som kontot Administratör//Administrator 796

17 Förslag till svar på frågor åtnjuter är dels dolda sådana som Microsoft tilldelat detta konto direkt, dels användarrättigheter tilldelade detta konto och dels privilegier, dolda och synliga, som tilldelats gruppen Administratörer//Administrators. Tabellen sammanfattar våra möjligheter att styra dessa: Privilegier Dolda privilegier tilldelade kontot av Microsoft Inga Användarrättigheter tilldelade kontot Möjligheter för administratörer att ändra Fullständiga Dolda privilegier tilldelade gruppen Administratörer//Administrators av Microsoft Inga Användarrättigheter tilldelade gruppen Administratörer// Administrators Fullständiga 8. Författaren anser att det enda som borde hända om domänkontot Gäst//Guest aktiveras är att just detta konto kan användas för inloggning i domänen, inget mer. Vad händer egentligen? När domänkontot Gäst//Guest aktiveras händer det uppenbara: kontot blir användbart för inloggning i domänen, både lokal inloggning och nätverksinloggning. Dessutom händer något som kanske inte är uppenbart: vi har släppt in den hemska draken Alla//Everyone i vår trädgård. Skulle det dessutom vara så att kontot Gäst//Guest inte har något lösenord har vi släppt in Alla//Everyone i vårt hus. Detta något oväntade beteende kommer sig av att Windows NT är så skrivet att om någon med ett okänt kontonamn (kanske från ett fartyg på internationellt vatten, med uppringd anslutning till Internet) försöker komma åt en Windows NTdator undersöker Windows NT först om kontot Gäst//Guest är aktivt. Är kontot aktivt och har ett lösenord erbjuds den okända att uppge detta lösenord. Om kontot Gäst//Guest inte har något lösenord hoppas detta andra steg över och den okända medges tillgång till datorn utan att besväras med frågor om lösenord. Detta beteende kan vi enkelt undvika genom att se till att gruppen Domänanvändare//Domain Users (eller Användare//Users) tilldelas användarrättigheten 797

18 21 Kontona Administratör//Administrator, Gäst//Guest och System//System Åtkomst till den här datorn från nätverket//access this computer from network i stället för Alla//Everyone. 9. Kan kontot Gäst//Guest helt tas bort? Nej, det finns inget sätt att ta bort kontot Gäst//Guest. Detta trots att det finns Windows NT-nätverk som drivits i åratal utan att någonsin haft behov att aktivera kontot. 10.Vad kan man göra för att minska skadorna om man skulle råka aktivera Gäst//Guest? Förutom att aldrig använda specialgruppen Alla//Everyone till något annat ändamål än granskning//auditing kan man skydda sig genom att: q q q q q Sätta ett omöjligt lösenord på Gäst//Guest Göra om Gäst//Guest till ett domänlokalt konto Ta bort alla inloggningstider från kontot Ange att kontot endast kan logga in från datorer som inte finns Ange ett bäst-före-datum som redan passerat 11.Kan kontot System//System helt tas bort? Inte en chans. Det inbyggda specialkontot System//System syns över huvudtaget inte i Kontohanteraren för domäner//user Manager for Domains så det går inte att göra något alls med det. 12.Vad är det som gör kontot System//System så speciellt? Microsoft har gjort kontot System//System kraftfullare på den lokala datorn än något annat konto i Windows NT tack och lov kan det inte verka över nätverket; det är tilldelat de allra flesta användarrättigheter, det är ständig medlem av gruppen Administratörer//Administrators (medlemskapet låter sig inte rubba). Endast System//System är tilldelat behörighet till kontodatabasen i Registret//Registry. 13.Eftersom System//System är med i Administratörer//Administrators är det svårt att stänga det ute från mappar man inte vill att det skall ha tillgång till, eller? För det första, endast NTFS innehåller lokal behörighet och därmed möjlighet att styra åtkomst. Vanligen ger man 798

19 Förslag till svar på frågor gruppen Domänadministratörer//Domain Admins (eller Administratörer//Administrators) obegränsad tillgång till alla viktiga mappar. Det kan dock vara fördelaktigt att utestänga kontot System//System från de mappar i vilka det inte har något att skaffa. Detta görs med behörighetsposten System//System: Ingen behörighet//no Access Märk att det inte finns något sätt att ge System//System lägre lokal behörighet (men inte Ingen behörighet//no Access) till någon mapp där gruppen Administratörer//Administrators tilldelats behörighet. Se därför till att även ge Administratörer/ /Administrators minsta möjliga lokal behörighet till mappar och filer. Bättre är att använda Domänadministratörer//Domain Admins i behörighetsposter eftersom System//System inte är med i den gruppen. 14.Varför bör inte tjänster//services använda kontot System/ /System? Eftersom System//System har så stor makt på den lokala datorn bör det användas så litet som möjligt. 15.Hur förhåller sig namnen System och LocalSystem till varandra? Om System//System vore ett vanligt konto vore System kontonamnet och LocalSystem hela namnet på användaren. 799

20 21 Kontona Administratör//Administrator, Gäst//Guest och System//System 800