25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet)

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Lokal behörighet/lokal säkerhet, NTFS-behörighet Lokal behörighet (ofta kallad lokal säkerhet) är knutet till filsystemet NTFS. Det är endast mappar och filer som kan åsättas lokal behörighet vilket skiljer lokal behörighet från delningsbehörighet. Lokal behörighet finns endast när man formaterar en volym med NTFS. Lokal behörighet kallas därför ofta NTFS-behörighet eller NTFS-säkerhet. I Microsoft-världen såg lokal säkerhet/lokal behörighet dagens ljus i och med HPFS386 som var en vidareutveckling av filsystemet HPFS (i OS/2). HPFS386 var ett tillägg till Microsoft LAN Manager for OS/2 och krävde, i motsats till OS/2, att datorn hade en Intel i386-processor. Lokal behörighet är mycket lik delningsbehörighet därför att samma grundbehörigheter används för både lokal behörighet och delningsbehörighet, med två tillägg. Det ena tillägget, jämfört med delningsbehörighet, har att göra med att mappar och filer på NTFS-volymer alltid har en ägarinna. Det andra tillägget har att göra med Microsofts försök att låta NTFS styras av POSIX-regler. Mappar och filer på NTFS-volymer har alltid ägarinna Ägarinnan är farlig både för sig själv och andra Det finns ett problem i detta med ägandeskap det är bestämt att den som äger ett objekt också kan ändra dess behörighetslista. Det behövs ingen livlig fantasi för att se att den som äger ett objekt då kan göra så att ingen har någon som helst behörighet till objektet (utom ägarinnan själv, som alltid kan ändra behörighetslistan). 911

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Enär behörigheten att ta över ägandeskapet även den kan tilldelas en grupp kan ägarinnan finna sig vara utan det tidigare ägda. POSIX stökar till det File Delete Child Behörigheten File Delete Child är mycket speciell eftersom den alltid följer med närhelst man åsätter Fullständig behörighet//full Control till en mapp på en NTFS-volym. Den är dessutom aldrig synlig så det är inte lätt att komma ihåg att den finns och vilken verkan den har (mer om det senare). Enligt Microsoft är det ett krav i POSIX att den som har Fullständig behörighet//full Control till en mapp alltid skall kunna ta bort alla filer i mappen oavsett vilka behörigheter som gäller för de enskilda filerna (inte ens Ingen behörighet//no Access åsatt en fil har någon verkan mot File Delete Child). File Delete Child är en viktig egenskap i NTFS och en som Microsoft inte har dokumenterat på ett bra sätt jag har bara sett den omtalad som File Delete Child i Microsofts egen kursdokumentation för Windows NT Server 3.5. Ett idogt sökande i bruksanvisningarna för Windows NT 4.0 och Microsoft Resource Kit för både Windows NT 3.5, 3.51, Windows NT Workstation 4.0, Windows NT Server 4.0 samt TechNet och MSDN och även på webben gav resultatet att File Delete Child aldrig nämns vid detta namn och att POSIX aldrig anges som källa. Det bästa stället jag fann var faktiskt bruksanvisningen Begrepp och planering//concepts and Planning. På sidan 148//138 finner vi följande text: Obs! Grupper och användare som har tilldelats behörigheten Fullständig behörighet för en katalog [mapp] kan ta bort filer i den katalogen [mappen] oavsett vilken behörighet som skyddar filen. Note Groups or users granted Full Control permission on a directory can delete files in that directory no matter what permissions protect the files. När jag för en tid sedan gjorde om sökningen efter information om File Delete Child hittade jag faktiskt en artikel i TechNet, artikel Q152763 betitlad SETUP: File Delete Child Directory Permission in NTFS. Den bekräftar det som tidigare var känt om File Delete Child. En liten miss kan noteras i artikeln: de 912

Förvald lokal behörighet för mappar (och nya filer i mapparna) blandar bort korten för oss genom att både tala om Fullständig behörighet//full Control och den som äger en mapp. Så här står det: The FDC permission is based on the concept that if a user owns a directory [folder], they should be able to delete files within that directory [folder], even if they do not have specific permissions for every file. Detta är synd eftersom det inte alls är ägandeskapet som är avgörande (undrar om det är just ägandeskapet som är viktigt för POSIX ). Om du tycker att File Delete Child verkar problematisk kommer du nedan att finna ett enkelt sätt att skydda sig mot dess verkningar, mer om det senare i detta kapitel. Över huvudtaget är min åsikt enkel den enda grupp som någonsin behöver behörigheten Fullständig behörighet//full Control är Administratörer//Administrators. För alla andra räcker det alltid med Ändra//Change. Förvald lokal behörighet för mappar (och nya filer i mapparna) File Delete Child kräver minst Ändra//Change som delningsbehörighet Om du vill att File Delete Child skall ha effekt när du delar ut en mapp för åtkomst via nätverket måste du åsätta mappen delningsbehörigheten Ändra//Change eller Fullständig behörighet//full Control. Både Ändra//Change eller Fullständig behörighet//full Control som delningsbehörigheter innehåller hjälpbehörigheten File Delete Child. File Delete Child är kopplad till den lokala behörigheten Fullständig behörighet//full Control och påverkar endast filer i samma mapp vilken åsatts den lokala behörigheten Fullständig behörighet//full Control. Ändra behörighet//change Permissions kräver Fullständig behörighet//full Control som delningsbehörighet För att ge dem som ansluter via nätverket möjlighet att utnyttja den lokala behörigheten Ändra behörighet//change Permissions måste delningsbehörigheten vara Fullständig behörighet//full 913

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Control. Endast delningsbehörigheten Fullständig behörighet//full Control innehåller behörigheten Ändra behörighet//change Permissions (som hjälpbehörighet). Både delningsbehörigheter och lokala behörigheter hanteras i behörighetslistor, Access Control List, ACL. Bli ägare//take Ownership kräver Fullständig behörighet//full Control som delningsbehörighet Skulle du vilja att man kan göra sig till ägarinna av mappar och filer även vid åtkomst via nätverket måste delningsbehörigheten vara Fullständig behörighet//full Control. Endast delningsbehörigheten Fullständig behörighet//full Control som innehåller hjälpbehörigheten Bli ägare//take Ownership. Eftersom det inte finns något ägarbegrepp i delningsbehörigheterna ingår denna behörighet som hjälpbehörighet, för att lättare förstå samspelet mellan delningsbehörigheter och lokala behörigheter. Fullständig behörighet//full Control Vid Fullständig behörighet är alla luckor öppna märk luckan märkt F (File Delete Child) som alltid följer med när någon tilldelas fullständig behörighet till mappen. 914

Förvald lokal behörighet för mappar (och nya filer i mapparna) Ändra//Change Den lokala behörigheten Ändra//Change innebär att användaren tillåts göra det mesta med mappen det finns sällan anledning att ge användare mer omfattande behörighet än Ändra//Change. Du kanske tycker att bilden ovan är felaktig luckan File Delete Child (F) är ju öppen när man åsätter delningsbehörigheten Ändra//Change (RXWDF)?! Bilden är rätt enligt Microsoft är det först när man åsätter Fullständig behörighet//full Control som File Delete Child följer med. Dock gäller att delningsbehörigheten Ändra//Change släpper igenom File Delete Child (mer om delningsbehörigheter i nästa kapitel). 915

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Lägga till och Läsa//Add & Read Behörigheten Lägga till & Läsa är nästan samma som Lägga till skillnaden består i den förvalda behörigheten för filer i mappen. Den förvalda, sammansatta, behörigheten Lägga till och Läsa/ /Add & Read består av olika lokal behörighet för mappen och för nya filer i mappen. För mappen själv innebär Lägga till och Läsa//Add & Read grundbehörigheterna R, X och W. Nya filer i mappen får behörigheterna R och X. Resultatet blir att man kan lista innehållet i mappen, lägga till nya filer till mappen. De nya filerna i mappen kan läsas och om det är ett program (både gamla och nya Windows-program) kan det köras. 916

Förvald lokal behörighet för mappar (och nya filer i mapparna) Lägga till//add Den lokala mappbehörigheten Lägga till//add ger endast användaren möjlighet att lägga till nya filer till mappen. Behörighet för nya filer i mappen är inte angiven. Med den lokala behörigheten Lägga till//add gör vi oss en brevlåde-mapp. Denna mapp fungerar så att vi kan lägga till filer till mappen, men vi kan inte se vilka filer som finns i mappen. Vad gäller nya filer som upprättas i mappen anges ingen förvald behörighet till dem. Om ingen annan behörighet åsätts dessa filer kan de inte vare sig läsas, ändras eller hanteras på annat sätt. Läsa//Read Behörigheten Läsa//Read gör att användaren kan lista innehållet i mappen och förvald behörighet till filer i mappen blir även den Läsa//Read. Den lokala behörigheten Läsa//Read innebär att samma behörighet sätts för mappen och för nya filer i mappen. Eftersom 917

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Lista//List både Läsa//Read innefattar både R och X kan mappens innehåll (filnamn) listas och filerna i mappen kan läsas, kopieras och, om de är programfiler, köras. Behörigheten List gör att användaren kan lista innehållet i mappen, men ingen behörighet anges till nya filer i mappen. Skillnaden mellan behörigheten Läsa//Read och behörigheten Lista//List är att i det senare fallet åsätts ingen förvald behörighet för nya filer i mappen. Nya filer i mappen kommer alltså inte att ärva några filbehörigheter från inställningar för mappen. Ingen behörighet//no Access Delningsbehörigheten Ingen behörighet//no Access. Delningsbehörigheten Ingen behörighet//no Access innebär att dörren slås igen och den grupp/det konto som anges i behörighetsposten kan inte komma åt mappen/filen. Det hjälper inte om 918

Lokala grundbehörigheter kan fritt blandas gruppen/kontot förekommer i andra behörighetsposter, dörren är slutgiltigt stängd. Lokala grundbehörigheter kan fritt blandas Lokala behörigheter kan fritt blandas du är inte begränsad till att använda de sammansatta lokala behörigheterna för mappar och filer. Kringgå problemet med File Delete Child: RXWDPO Här har man åsatt alla grundbehörigheter till en mapp skillnaden mot Fullständig behörighet är den att man slipper fundera på File Delete Child. Vad gäller nya filer i mappen anges ingen förvald behörighet. I bilden har vi angivit mappbehörigheter på sådant sätt att File Delete Child inte spelar någon roll (File Delete Child följer endast med när vi använder Fullständig behörighet//full Control). Detta är alltså ett sätt att ange Fullständig behörighet//full Control, utan File Delete Child. För att kunna ange denna speciella blandning av grundbehörigheter väljer du Särskild behörighet för katalog [mapp]/ /Special Directory [Folder] Access i listan Typ av behörighet//type of Access, vilken du finner i dialogrutan för lokal behörighet: 919

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) För att ange de lokala grundbehörigheter man själv önskar för en mapp väljer man i listan Typ av behörighet//type of Access i dialogrutan ovan. Strax syns dialogruta i vilken du väljer lokala grundbehörigheter efter eget skön: Dialogrutan för att själv välja grundbehörigheter för en mapp på en NTFS-volym. 920

Lokala grundbehörigheter kan fritt blandas I dialogrutan ovan kan du fritt blanda olika lokala grundbehörigheter. Tänk på att det inte finns något vettighetsfilter i Windows NT du får sätta vilka behörigheter du önskar oavsett om de är vettiga eller inte. File Delete Child kan inte tas bort från Fullständig behörighet//full Control File Delete Child kan ses som en speciell grundbehörighet som alltid sitter ihop med Fullständig behörighet//full Control för mappar och inte kan ändras. Den speciella grundbehörigheten File Delete Child kan tänkas vara en del av Fullständig behörighet//full Control. En del som inte kan tas bort det är därför jag gjort dess kryssruta grå i bilden ovan. Kom ihåg: du kan aldrig se en dialogruta i Windows NT som visar File Delete Child du måste själv komma ihåg att den finns och vilken inverkan den har. Sätta behörighet så att man kan lägga till filer till en mapp och 921

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) ändra behörigheter för mappen Denna mapps lokala behörigheter (RXWP) har satts samman så att användaren kan lägga till filer i mappen (inte ta bort filer), samma som Lägga till//add, och ändra behörigheter för mappen. Inga förvalda behörigheter för nya filer i mappen anges. Detta exempel visar ett fall där man tycker sig ha behov av kunna lägga till filer till mappen och kunna ändra behörigheter till mappen. Mappen kan inte tas bort och dess ägandeskap kan inte tas över. Sammansatta lokala behörigheter för filer på en NTFS-volym Det finns fyra förvalda sammansatta lokala behörigheter för filer på en NTFS-volym: q Ingen behörighet//no Access q Ändra//Change q Läsa//Read q Fullständig behörighet//full Control Lokal filbehörighet Fullständig behörighet//full Control Grundbehörigheter R, X, W, D, P, O (samtliga lokala grundbehörigheter) All åtkomst av filen: läsa innehåll, köra program, ändra innehåll, ta bort filen samt möjlighet att ändra behörighetslistor (ACL), d.v.s. vem som har behörighet till den utdelade resursen och även att ta ägandeskap för filen. 922

Sammansatta lokala behörigheter för filer på en NTFS-volym Lokal filbehörighet Grundbehörigheter Ändra//Change R, X, W, D Läsa, ändra, ta bort vanliga filer. Köra, ändra och ta bort programfiler. Ändra filers attribut (skrivskydd, o.s.v.). Lokal filbehörighet Läsa//Read Grundbehörigheter R, X Läsa vanliga filer, köra program. Lista innehåll i undermappar. Lokal filbehörighet Ingen behörighet//no Access Grundbehörigheter N Ingen åtkomst av filen. När det gäller filer kommer den speciella behörigheten File Delete Child (F) inte att spela in den spelar endast roll för mappar (d.v.s. man kan inte hantera den enskilt för varje fil, den spelar roll för filer eftersom man kan ta bort dem om mappen har denna inställning). Fullständig behörighet//full Control Fullständig behörighet//full Control innehåller inga spärrar användaren får göra allt, även ändra behörigheter och ta över ägandeskapet av filen. Notera frånvaron av File Delete Child. Fullständig behörighet//full Control för filer på en NTFS-volym skiljer sig på en mycket viktig punkt från Fullständig behörighet/ /Full Control för mappar det finns ingen File Delete Child att ta hänsyn till när vi talar om filer. 923

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Ändra//Change När den lokala behörigheten Ändra//Change åsatts en viss fil innebär det möjlighet att läsa filen, ändra i den och ta bort den. Behörigheten Ändra//Change är den jag brukar förorda en vanlig användare behöver sällan mer omfattande privilegier. Eftersom behörigheten Skriva//Write (W) finns kan användaren ändra en fils attribut såsom skrivskydd, m.fl. Läsa//Read Behörigheten Läsa för denna fil innebär möjlighet att läsa innehållet eller köra filen om det är en programfil. Ändra filnamn kräver nödig behörighet för både mapp och fil För att kunna ändra namn på en fil måste behörigheterna R, W tilldelats en grupp för mappen samtidigt som de tilldelats R, D för filen. Det finns alltså ett samspel mellan mapp och fil när det gäller filnamn. Det är inte så svårt att föreställa sig att filnamnet samtidigt räknas till mappen (det ingår i mappens fillista) och till filen. 924

Behörigheten Exekvera [Köra]//Execute kan vara lurig Behörigheterna R och W för mappen för att ändra filnamn är inte så svåra att lista ut. Det var värre med R och D för filer. Jag hade en smula problem när jag testade byte av filnamn innan jag kom på att prova både R och D för filen. Min tolkning är att först läses filnamnet, det gamla namnet tas bort och sedan upprättas ett nytt. Detta beteende skulle kräva just R och D för filen. Behörigheten Exekvera [Köra]//Execute kan vara lurig För de filer som är program (WinWord.Exe, Excel.Exe, m.fl.) räcker det att sätta den lokala behörigheten Exekvera [Köra]/ /Execute (X) för att kunna köra dem. Eftersom Read//Läsa (R) inte behövs kan ingen kopiera programfilen över nätverket vilket kan vara skönt för en administratör att slippa oroa sig för. Det finns dock ett litet aber resonemanget ovan håller endast för nya Windows-program (Win32-program). För gamla Windows-program (Win16-program) och MS-DOS-program gäller att de inte kan köras under Windows NT om de inte minst har den lokala behörigheten Read//Läsa (R) och Exekvera [Köra]//Execute (X). Jag skulle anta att detta helt enkelt beror på hur Windows NT tillhandahåller möjlighet att köra gamla Windows-program och MS-DOS-program (m.h.a. NTVDM (Windows NT Virtual DOS Machine)) Ägarbyte kan medföra behörighetsförändringar När en mapp eller fil på en NTFS-volym byter ägarinna kan det medföra behörighetsförändringar. När en mapp byter ägarinna är det inte ovanligt att den nya ägarinnan tilldelas lokal behörighet Fullständig behörighet//full Control till mappen, filer och undermappar. Låt mig visa med ett par skärmdumpar vad som händer (i detta fall blir inte ändringarna av lokal behörighet så omfattande) när ett användarkonto tar över ägandeskapet av en mapp, dess filer och undermappar. Mappen d:\arbete\budget har följande lokal behörighet : 925

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Lokal behörighet till mappen d:\arbete\budget. Kontot ceciliac anges som ägarinna. Administratörer//Administrators: Fullständig behörighet//full Control Skapare ägare//creator Owner: Ändra//Change Användare//Users: Särskild behörighet (RWXO) (RWXO) R, X, W, D, F, P, O R, X, W, D R, X, W, O Som du ser har alla konton som är medlemmar av den lokala gruppen Användare//Users möjlighet att ta ägandeskap eftersom de tilldelats behörigheten Bli ägare//take Ownership. (Det går lika bra att använda den globala gruppen Domänanvändare//Domain Users.) Nu tar en annan användare, kontonamn irisi, över ägandeskapet av mappen och dess undermappar. Windows NT ställer alltid en kontrollfråga för att ge användaren möjlighet att ta över ägandeskapet för filer och undermappar också: 926

Ägarbyte kan medföra behörighetsförändringar Kontrollfråga från Windows NT vid ägarbyte. Den nya användaren är nu ägarinna av mappen och upprättar filer i den. Vi har en behörighetspost för Skapare ägare//creator Owner: alltså kommer kontonamnet för ägarinnan återfinns i behörighetslistan. Så kommer ytterligare en användare, kontonamn annikaa, och gör sig till ägarinna av hela mappträdet från huvudmappen och ned (befintliga filer och undermappar). Behörighetslistan för mappen d:\arbete\budget\budget98 ser nu ut så här: Lokal behörighet för mappen d:\arbete\budget\budget98. Som du ser i bilden är det kontot annikaa som är ägarinna till mappen. Du ser också en post för kontot irisi, vilket kanske förvånar?! Förklaringen är att kontot irisi tidigare var ägarinna av hela mappträdet, från d:\arbete\budget och nedåt. När hon ägde mappträdet upprättade hon ett antal undermappar och filer, bland dem mappen d:\arbete\budget\budget98. Eftersom behörighetsposten Skapare ägare//creator Owner Ändra//Change fanns från början tilldelades kontot irisi dessa behörigheter när användaren upprättade mappen. 927

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Behörigheter som inte ärvs Du ser något intressant i bilden om du tittar noga på posten för irisi ser du att efter behörigheterna för mappen, (RWXD) står det en asterisk, *. Asterisken innebär att denna behörighetspost inte kommer att ärvas av nya undermappar som upprättas i denna mapp. Detta är mycket bra och jag ser det som bevis för att någon ägnat en smula eftertanke åt detta med specialgruppen Skapare ägare//creator Owner och hur den skall hanteras. Behörighetsposter för Skapare ägare//creator Owner gäller enbart för nya mappar/filer Det finns en stor skillnad mellan behörighetsposter för specialgruppen Skapare ägare//creator Owner och andra grupper: poster för Skapare ägare//creator Owner gäller inte för den mapp som posten finns i. Det låter underligt, men om jag säger att behörighetsposter för gruppen enbart gäller nya mappar och filer som upprättas i den mapp i vilken behörighetsposten finns, kanske det blir tydligare? Ett exempel kanske behövs, låt oss betrakta en mapp med följande behörighetslista: Administratörer//Administrators: (R, X, W) (R, X) Lägga till och Läsa//Add & Read Skapare ägare//creator Owner: (R, X, W, D) (R, X, W, D) Ändra//Change Mappen är upprättad av en medlem av gruppen Administratörer/ /Administrators så det är denna som äger mappen. En viktig förutsättning: modermappen till denna mapp får inte ha en behörighetspost där Administratörer//Administrators har tilldelats Fullständig behörighet//full Control för då stör vår gamla ovän File Delete Child resonemanget. Då till frågan: vad kan en medlem av gruppen Administratörer//Administrators göra med denna mapp? Som du redan funderat ut har inte behörighetsposten för Skapare ägare//creator Owner någon inverkan så den enda behörighetsposten som återstår är den som tilldelar Administratörer//Administrators behörigheten Lägga till & Läsa (R, X, W). De får alltså inte ta bort mappen vilket man skulle kunna förledas att tro med tanke på behörighetsposten för 928

Behörigheten för Skapare ägare//creator Owner byts ut Skapare ägare//creator Owner. Behörigheten för Skapare ägare//creator Owner byts ut Det är viktigt att du gör klart för dig hur behörighetsposter för Skapare ägare//creator Owner hanteras. Kom ihåg: Skapare ägare//creator Owner kan endast i behörighetsposter för mappar, inte filer, i NTFS. Antag att administratörerna gör en ny undermapp i mappen d:\arbete\budget med namn d:\arbete\budget\mallar. De ger den en behörighetslista som ser ut så här: Skapare ägare//creator Owner: R, X, W, D Ändra//Change Användare//Users: (R, X, W) (R, X) Lägga till och Läsa//Add & Read Tanken med mappen Mallar är att den skall innehålla mallar för budgetarbetet. Alla användare (d.v.s. den lokala gruppen Användare//Users) har behörighet att lägga till filer i mappen och att läsa innehållet i dessa (nya) filer. Den som upprättar en ny fil i mappen äger också filen varvid behörighetsposten för Skapare ägare//creator Owner gör sig gällande. Det som sker är att namnet på det konto som användes när filen upprättades kommer att ersätta Skapare ägare//creator Owner i behörighetslistan. Låt oss ta ett exempel. Cecilia Cinnober, med kontonamnet ceciliac, upprättar filen MarknadsMall.Dot i mappen. Denna fils behörighetslista kommer att se ut så här: ceciliac: Ändra//Change R, X, W, D Användare//Users: Läsa//Read R, X Samma sak händer alltid när du använder Skapare ägare//creator Owner. Jag har inte bestämt mig för om jag tycker att detta är bra eller dåligt jag kan se en nackdel i det att vid ägarbyte finns denna post kvar i behörighetslistan. Det hade förmodligen varit smidigare om posten fortfarande avsåg Skapare ägare//creator Owner. Jag inser att detta skulle ta längre tid att hantera (för Windows NT), men det hade givit Skapare ägare//creator Owner fler användningsmöjligheter. 929

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Skapare ägare//creator Owner blir alltid enskilda konton nästan alltid När det finns en post för Skapare ägare//creator Owner blir alltid enskilda användarkonton listade som ägarinna till mappen/filen som de upprättar. Det finns ett undantag till denna regel om kontot som upprättar en mapp eller fil är medlem av den lokala gruppen Administratörer//Administrators kommer denna grupp att anges som ägarinna. Man kan tycka att det vore väldigt behändigt om det alltid vore så att en grupp angavs som ägarinna i stället för ett enskilt konto. Om detta låtit sig göra vore det enkelt att låta flera personer hantera mappar och dokument på samma sätt som är fallet för Administratörer//Administrators. Problemet som infinner sig är att det inte är lätt att välja vilken grupp som skall bli ägarinna. Alla konton i en Windows NT-domän är med i den globala gruppen Domänanvändare//Domain Users vilken i sin tur är med i domänens alla lokala grupper Användare//Users. Gruppen Användare//Users är alltså inget bra val eftersom den omfattar alla användare i domänen det skulle inte vara någon skillnad mellan Skapare ägare//creator Owner och Användare//Users så vi skulle lika gärna kunna använda gruppen Användare//Users. Det kanske skulle vara möjligt att låta den primära gruppen anges som ägarinna (alla konton måste vara medlem av minst en global grupp, endast globala grupper kan anges som primär grupp)? Problemet är då att ett enskild användarkonto endast har en primär grupp hur skulle man välja vilken grupp som skall vara primär? Behovet är säkert dessutom olika i tiden under en tid har användaren huvudsakligen en viss syssla (en primär grupp) för att senare byta. Resultatet skull bli en myckenhet administration. Dessutom finns begreppet primär grupp till enkom för POSIX och Macintosh så det skulle innebära stora tillägg till Windows NT för att få det hela att fungera. Behörighetsposten för Skapare ägare//creator Owner läggs samman med posten för den som blir ägarinna Skulle det vara så att mappen både innehåller en behörighetspost för det användarkonto (eller Administratörer//Administrators) som sedan upprättar en fil kommer dessa båda behörighetsposter att läggas samman. Ett exempel: ange följande behörighet till 930

Behörigheten för Skapare ägare//creator Owner byts ut en mapp: Administratörer//Administrators: (R, X, W) (R, X) Lägga till och Läsa//Add & Read Skapare ägare//creator Owner: (R, X, W, D) (R, X, W, D) Ändra//Change När sedan en medlem av Administratörer//Administrators upprättar en ny undermapp i mappen kommer undermappen att få följande behörighet: Administratörer//Administrators: (R, X, W, D) (R, X) Särskild behörighet//special Access Skapare ägare//creator Owner: R, X, W, D Ändra//Change Som du ser lägga de båda behörighetsposterna samman eftersom det användarkonto som upprättade den mappen är medlem av gruppen Administratörer//Administrators. Den nya behörighetsposten bildas slikt: Administratörer//Administrators: R, X, W Lägga till och Läsa//Add & Read Skapare ägare//creator Owner: R, X, W, D Ändra//Change Sammanlagd behörighet till mappen R, X, W, D En ny fil upprättad i mappen får följande behörighetslista: Administratörer//Administrators: R, X, W, D Ändra//Change Som du ser är Windows NT intelligent nog att känna igen som den sammansatta behörigheten Ändra//Change i R, X, W och D. Verktyget SubInACL från Microsoft Resource Kit kan byta ägarinna för mappar och filer Verktyget SubInACL från Microsoft Resource kan byta ut ägarinnan för en mapp, fil eller nyckel i Registret//Registry mot ett annat konto eller grupp. (Läs om SubInACL i kapitel 16.) 931

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Tillåt inte ägarbyte Sammanfattningsvis tycker jag att detta med ägarbyte inte skall tillåtas i en Windows NT-domän. Administratörerna måste alltså, med lämplig lokal behörighet och delningsbehörighet, se till att ägarbyte aldrig tillåts ske. Å andra sidan innebär detta merarbete eftersom vi i stället blir tvungna att upprätta fler grupper så att den tänkta gruppen möjlig filägarinna redan från början ges nödiga behörigheter till mappar och filer på en NTFS-volym. Var ser man lokala behörigheter Lokala behörigheter kan man åsätta mappar och filer närhelst man önskar det finns ingen direkt koppling till resursdelning. Befintliga lokala behörigheter undersöker eller ändrar man genom att markera mappen, ta fram snabbmenyn, välja Egenskaper//Properties (eller Dela ut//sharing, om det är en mapp), öppna fliken Säkerhet//Security och sedan trycka på Behörighet//Permissions. Lokal behörighet för mappen d:\users (och nya filer i nappen). Notera att det står Behörigheter för Katalog [mapp]//directory Permissions i dialogrutan. Du ser också att en mapps ägarinna syns i dialogrutan. 932

Ändra befintlig lokal behörighet för mappar och filer Lokal behörighet kan studeras både från Den här datorn//my Computer och/eller Windows NT-utforskaren//Windows NT Explorer. Om du studerar bilden ser du att det efter namnet på den sammansatta lokala behörighet finns två parenteser. Dessa finns alltid med när det gäller lokal behörighet. Den första parentesen innehåller grundbehörigheterna för mappen, den andra parentesen visar grundbehörigheter för nya filer i mappen. Ändra befintlig lokal behörighet för mappar och filer Befintlig lokal behörighet kan när som helst ändras. Om du använder dialogrutan för att ändra behörighet kommer du att märka att den endast kan byta ut befintlig uppsättning behörigheter du kan inte lägga till en ny behörighetspost och få Windows NT att lägga till den till behörighetslistor för befintliga filer och undermappar. Windows NT kommer att alltid att ta den nya behörighetslistan och genomföra den i hela mappträdet. Detta kan låta skumt för den som kan NetWare. I NetWare är det enkelt att ändra behörighetslistor genom att lägga till nya behörighetsposter eller ta bort befintliga det är en okänd konst för Den här datorn//my Computer och Windows NT-utforskaren//Windows NT Explorer (läs dock om CACLs.Exe och XCACLs.Exe nedan). Byta ut behörigheter för befintliga filer i samma mapp Dialogrutan för att ange eller ändra behörighetsposter. Rutan för att 933

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) byta ut befintliga behörighetslistor för befintliga filer är ikryssad. Önskar du byta ut (du kan endast byta ut inte ändra) behörighetslistor för filer i denna mapp och filer i undermappar kryssar du i rutan Ersätt behörigheter för befintliga filer//replace Permissions on Existing Files. Befintliga filer i denna mapp (endast i denna mapp, inte i undermappar) kommer då att tilldelas de behörigheter som står i den andra parentesen (om de skulle vara olika för filer och mappar). Enligt rutan ovan får befintliga filer i mappen följande uppsättning lokal behörighet: Administratörer//Administrators: Fullständig behörighet//full Control Användare//Users: Ändra//Change R, X, W, D, P, O R, X, W, D Byta ut behörigheter för befintliga undermappar (endast mappar) Dialogrutan för att ange eller ändra behörighetsposter. Rutan för att byta ut befintliga behörighetslistor för undermappar är ikryssad. Önskar du byta ut (du kan endast byta ut inte ändra) behörighetslistor för undermappar kryssar du i rutan Ersätt behörigheter för alla underkataloger [undermappar]//replace Permissions on Existing Subdirectories [Subfolders]. Befintliga undermappar kommer då att tilldelas de behörigheter som står i den första parentesen (om de skulle vara olika för mappar och filer). Enligt rutan ovan får befintliga undermappar följande upp- 934

Ändra befintlig lokal behörighet för mappar och filer sättning lokal behörighet: Administratörer//Administrators: Fullständig behörighet//full Control Användare//Users: Ändra//Change R, X, W, D, P, O R, X, W, D Denna uppsättning gäller för mappen själv om du studerar en undermapps behörighetsinställningar i Windows NT kommer du att se samma sak som i bilden ovan. Byta ut behörigheter för alla filer och undermappar i hela mappträdet Den som önskar byta ut behörigheter för alla filer och mappar i ett mappträd måste kryssa i båda rutorna. Ett kryss i båda rutorna i dialogrutan gör att samtliga filer i mappen, undermappar och filer i undermapparna påverkas av förändringen. Filer i mappen och i undermapparna kommer att få samma behörighetslista som tidigare blev fallet för filerna i samma mapp. Alla undermappar får behörighetslistor med samma innehåll som ovan. CACLs.Exe är ett kommandoradsverktyg för att hantera lokal behörighet I ett mappträd som fungerar väl med avseende på behörigheter kanske du inte är trakterad av utsikten att behöva byta ut alla behörighetslistor om du bara skulle vilja göra en liten förändring. Då kan kommandoradsverktyget CACLs.Exe vara till stor hjälp. 935

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) CACLs.Exe är en del av Windows NT, du finner det i mappen %SystemRoot%\System32\. Med CACLs.Exe kan du ändra i en befintlig behörighetslista, du behöver inte byta ut den helt och hållet. Vi skall se ett exempel på hur det används. Mappen d:\arbete\acl-test får tjäna som testmapp, den har just nu denna behörighetslista: Behörighetslistan för d:\arbete\acl-test. Låt oss använda CACLs.Exe för att ge gruppen Serveransvariga//Server Operators Fullständig behörighet//full Control i mappen. Vi öppnar en Kommandotolk//Command Prompt och skriver: cacls cacls "d:\arbete\acl-test" /t /e /g "Server Operators":F namn på programmet "d:\arbete\acl-test" mappen som skall hanteras (citattecknen inte absolut nödvändiga i detta fall). CACLs.Exe kan även hantera UNC-namn. /t (tree) genomför ändringarna i denna mapp och alla undermappar /e (edit) byt inte ut behörighetslistan, ändra i den /g (grant) medge behörighet "Server Operators":F namn på grupp som avses; F innebär Fullständig behörighet//full Control Om du skrivit allt rätt kommer CACLs.Exe kvittera kommandot 936

Ändra befintlig lokal behörighet för mappar och filer med namnet på de mappar och filer som den processar. Resultatet kan beskådas på vanligt sätt: Resultatet av att använda CACLs.Exe för att ge Serveransvariga//Server Operators Fullständig behörighet//full Control till mappen. Mer information om CACLs.Exe får de genom att skriva cacls i en kommandotolk eller genom att söka på ordet cacls i hjälpsystemet. Om du använder CACLs.Exe i en kommandofil kommer du kanske att störas av att den ofta begär att man skall kvittera dess handlingar (framför allt om det handlar om behörighetslistor för flera mappar och filer). För att kringgå detta kan du använda det gamla knepet att skicka ett y med hjälp av echo och en pipe till kommandot: echo y cacls. XCACLs.Exe och SubInACL.Exe är kommandoradsverktyg från Resource Kit för att hantera lokal behörighet XCACLs.Exe Verktyget XCACLs.Exe kan allt som CACLs.Exe kan och litet mer. XCACLs.Exe är inte begränsat till att hantera de förvalda, sammansatta, behörigheterna utan kan hantera alla lokala grundbehörigheter (inte File Delete Child det hade ju varit alltför bra). Läs i kapitel 16 hur du kan använda XCACLs.Exe. Låt oss använda den för att ge gruppen Kontoansvariga/ /Account Operators den sammansatta behörigheten Lägga till och Läsa//Add & Read till mappen d:\arbete\acl-test. xcacls "d:\arbete\acl-test" /t /e /c /g "Account Operators":EX;EXW /y 937

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Återigen blev det som vi tänkt oss när vi studerar behörighetslistan. Resultatet av XCACLs.Exe. SubInACL.Exe Som så ofta i Windows NT Server 4.0 Resource Kit finns det verktyg som har överlappande användning även verktyget SubInACL kan användas för att ändra i en befintlig behörighetslista. Låt oss byta ut Serveransvariga//Server Operators mot Skrivaransvariga//Print Operators. subinacl /subdirectories "d:\arbete\acl-test" /replace="server operators"="print operators" Resultatet: 938

Hjälpfrågor SubInACL har bytt ut Serveransvariga//Server Operators mot Skrivaransvariga//Print Operators. Skydda filerna på Windows NT:s systempartition//system Partition På en Intel-dator utgörs Windows NT:s systempartition//system Partition av filerna: q NTLdr q Boot.Ini q NTDetect.Com Dessa filer bör du skydda från obehörig åtkomst genom följande lokal behörighet: Domänadministratörer//Domain Admins Ändra//Change (I Microsofts modell används Administratörer//Administrators i stället för Domänadministratörer//Domain Admins.) Inga andra grupper skall ha någon behörighet till filerna. Endast Domänadministratörer//Domain Admins (Administratörer/ /Administrators) kommer nu att kunna ändra i dem. Som ett extra skydd kan du fundera över om du hellre vill ha följande behörighetspost för lokal behörighet: Domänadministratörer//Domain Admins R, X, W Denna post gör att filerna inte av misstag kan tas bort. 939

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Du kanske undrar om Windows NT verkligen kan starta med denna inställning vem är inloggad under det att Windows NT startar? Svaret är att under systemstart är ingen inloggad (kanske räknas specialkontot System//System som inloggat). Dessutom: det spelar ingen större roll vilken lokal behörighet som är åsatt filerna i systemvolymen//system partition. Det minimala NTFS-filsystem som finns i NTLdr bryr sig inte om lokal behörighet. Du skulle kunna ha denna behörighetslista för de tre filerna ovan: Alla//Everyone Ingen behörighet/- /No Access Hjälpfrågor 1. Vad är lokal behörighet? 2. Varför måste en volym vara NTFS-formaterad för att kunna använda lokal behörighet? 3. Vilken lokal behörighet är lämplig för skrivare? 4. Finns det något sätt att ändra i en befintlig behörighetslista, måste den alltid bytas ut? 5. En nyformaterad NTFS-volym har en mycket enkel struktur för lokal behörighet gruppen Alla//Everyone har åsatts Fullständig behörighet//full Control. Vad händer om du byter detta till Ingen behörighet//no Access för samma grupp? 6. Varför finns det en ägarinna till mappar och filer på NTFSvolymer? 7. Varför kan man inte ge bort mappar och filer, utan ägandeskap måste alltid tas över av den blivande ägarinnan? 940

Hjälpfrågor 8. Vad används verktygen CACLs.Exe, XCACLs.Exe och SubInACL.Exe till? 9. Hur kan det komma sig att det inte spelar någon roll vilken behörighet man åsätter filerna i Windows NT:s systemvolym/ /system partition (ntldr, boot.ini, ntdetect.com på Intel)? 10.Vad innebär det att en behörighetspost för en mapp anger Ej angiven//not specified för nya filer/mappar i mappen (jmf bilden)? Behörighetspost för mapp med behörigheten för nya filer/mappar satt till: Ej angiven//not specified. 11.Hur bestäms vem som äger en ny fil/mapp på en NTFSvolym? 12.Hur uppför sig File Delete Child? 13.Kan en administratör, med hjälp av lokal behörighet, göra så att användare inte ser vissa undermappar till en utdelad mapp? 941

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) 14.Varför går det inte att köra gamla Windows-program (Win16) om man inte minst har både Exekvera [Köra]//Execute och Läsa//Read till programfilerna (det räcker med Exekvera [Köra]//Execute för nya program)? 15.Hur kan du göra för att kringgå problemet med File Delete Child, men ändå tilldela Fullständig behörighet//full Control (eller nästan Fullständig behörighet//full Control)? 16.Kan vanliga användare någonsin ändra behörighetslistor för lokal behörighet? 942

Förslag till svar på frågor Förslag till svar på frågor 1. Vad är lokal behörighet? Lokal behörighet finns bara på mappar och filer om volymen formateras med NTFS. Liksom delningsbehörighet tilldelas lokal behörighet till användargrupper (samma grupper som delningsbehörighet). Det finns fler fasta lokala behörigheter, bland dem samma som delningsbehörigheterna Ingen behörighet//no Access, Läsa//Read, Ändra//Change och Fullständig behörighet//full Control. Mappar och filer kan ges olika uppsättning lokal behörighet (olika åtkomst, olika grupper). Det finns alltid en ägarinna av mappar och filer på en NTFS-volym och man kan med specialgruppen Skapare ägare//creator Owner lösa åtkomstproblem elegant och lättadministrerat. Lokal behörighet är alltid verksam, oavsett om användaren loggar in lokalt eller via nätverket. 2. Varför måste en volym vara NTFS-formaterad för att kunna använda lokal behörighet? Lokal behörighet finns endast i NTFS. Det fanns visserligen lokal behörighet i HPFS386 för OS/2 LAN Manager, men detta filsystem kan inte användas i Windows NT. 3. Vilken lokal behörighet är lämplig för skrivare? Lokal behörighet finns bara för mappar och filer på NTFSvolymer det är alltså inte möjligt att åsätta skrivare lokal behörighet. Visserligen påminner skrivarbehörighet mycket om lokal behörighet, men låt oss hålla isär begreppen. Mappar på FAT-volymer och andra resurser kan endast åsättas delningsbehörighet. 943

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) 4. Finns det något sätt att ändra i en befintlig behörighetslista, måste den alltid bytas ut? Det enda sättet att ändra i en befintlig behörighetslista är med hjälp av verktygen CACLs.Exe eller XCACLs.Exe. CACLs.Exe ingår i Windows NT, XCACLs.Exe är en del av Windows NT Server 4.0 Resource Kit. Båda är kommandoradsverktyg och kräver sin kvinna. 5. En nyformaterad NTFS-volym har en mycket enkel struktur för lokal behörighet gruppen Alla//Everyone har åsatts Fullständig behörighet//full Control. Vad händer om du byter detta till Ingen behörighet//no Access för samma grupp? Eftersom behörigheten Ingen behörighet//no Access har större tyngd än de andra behörigheterna medför detta att ingen användare kan komma åt volymen. Skulle volymen i fråga vara startpartitionen//boot partition kommer datorn inte kunna starta! Skulle detta inträffa måste man installera om Windows NT. (I tidigare versioner av Windows NT fanns det möjlighet att använda reparationsförfarandet för att ändra de lokala behörigheterna.) ERD Commander från Systems Internals kan vara behjälplig i slika fall. 6. Varför finns det en ägarinna till mappar och filer på NTFSvolymer? Ägandeskap är kopplat till spårbarhet man vill alltså kunna avgöra vem som gjort vad med filer och annat. 7. Varför kan man inte ge bort mappar och filer, utan ägandeskap måste alltid tas över av den blivande ägarinnan? Återigen är ägandeskap kopplat till spårbarhet. En datorbuse skall inte kunna ställa till ofog och sedan sopa upp spåren efter sig genom att överföra ägandeskapet av filer och mappar till någon annan. Likaså kan ägandeskapet vara avslöjande om någon olovandes (men med nödig behörighet) tagit över ägandeskap av en fil för att tillgodogöra sig dess innehåll. 8. Vad används verktygen CACLs.Exe, XCACLs.Exe och SubInACL.Exe till? Dessa tre verktyg är samtliga kommandoradsverktyg för att hantera lokal behörighet (SubInACL kan även hantera behörighetslistor för Registret//Registry). CACLs.Exe följer 944

Förslag till svar på frågor med Windows NT, de andra finns i Microsoft Windows NT 4.0 Resource Kit. CACLs och XCACLs kan användas för att ändra i behörighetslistor för ett mappträd man behöver alltså inte ersätta hela listan. SubInACL kan inte åsätta behörighet det kan byta ut en grupp eller ett konto mot ett annat i en befintlig behörighetspost. Det kan dessutom hantera behörighetslistor för nycklar i Registret//Registry, något som inte vare sig CACLs eller XCACLs klarar. 9. Hur kan det komma sig att det inte spelar någon roll vilken behörighet man åsätter filerna i Windows NT:s systemvolym/ /system partition (ntldr, boot.ini, ntdetect.com på Intel)? När Windows NT startar läses först startsektorn av BIOS, vilket inte förstår lokal behörighet. Därefter läses NTLdr in (av BIOS). NTLdr innehåller mini-filsystem för FAT och NTFS för att kunna läsa filer från disk (tillräckligt omfattande filsystem för att komma åt innehållet i filerna). Mini-filsystemet för NTFS innehåller ingen del som hanterar lokal behörighet varför det inte spelar någon roll för denna första del av starten vilken lokal behörighet som är åsatt filerna på systemvolymen//system partition (systemvolymen//system partition på ARC-datorer måste vara FAT, kanske för att NTLdr:s syster, OSLoader.Exe, inte fått ett mini-filsystem för NTFS). 10.Vad innebär det att en behörighetspost för en mapp anger Ej angiven//not specified för nya filer/mappar i mappen (jmf bilden)? 945

25 Lokal behörighet//local Security (lokal säkerhet, NTFS-behörighet) Behörighetspost för mapp med behörigheten för nya filer/mappar satt till: Ej angiven//not specified. Om en behörighetspost för en mapp anger behörighet till nya filer och mappar i mappen såsom: Ej angiven//not specified innebär detta helt enkelt att denna behörighetspost inte kommer att återfinnas i behörighetslistan för nya filer och mappar till den befintliga. Vilken behörighet som kommer att gälla för nya filer och mappar bestäms alltså av andra behörighetsposter. 11.Hur bestäms vem som äger en ny fil/mapp på en NTFSvolym? Grundregeln för vem som äger en ny fil eller mapp på en NTFS-volym är att den som upprättar filen/mappen också äger den. D.v.s. det användarkonto som användes när filen/mappen upprättas kommer att anges som ägarinna. Ett undantag finns: om användarkontot, direkt eller indirekt, är medlem av den lokala gruppen Administratörer//Administrators kommer denna grupp att bli ägarinna. 946