14 Användarkonton och kontoprinciper

Transkript

1 14 Användarkonton och kontoprinciper Användar- och grupphantering ligger till grund för all administration av nätverksoperativsystem, vare sig de heter Windows NT Server, Novell NetWare, Banyan Vines eller Unix. Det kan lugnt sägas att all tid du i förväg kan ägna åt att tänka igenom hur din organisation skall hantera användare och grupper sjufalt lönar sig i längden. Som grund och fundament för hantering av användarkonton i Windows NT-domäner ligger Kontoprinciperna//Account Policies. Dessa innefattar inställningar som gäller all kontohantering i en hel domän (eller på en icke-domänkontrollant). Exempel är lösenordslängd, hur ofta användare måste byta lösenord, med flera. Jag försöker uppnå följande med mitt sätt att hantera användarkonton och -grupper: q Givet personens för- och efternamn är det enkelt att finna ett kontonamn q Kontots namn skall följa samma regler som DNS-namn q Det skall framgå vilken plats i den organisatoriska hierarkin som personen intar q Användarkontot skall innehålla information om personens chef q Användarkontot har ett bäst-före-datum Regler och metoder för namngivning av användarkonton tas upp i kapitel

2 14 Användarkonton och kontoprinciper Användarkonton i Windows NT-domäner Användarkonton i Windows NT innehåller information nödvändig för Windows NT, innefattandes användarnamn (kontonamn), lösenord, gruppmedlemskap samt de användarrättigheter//user rights som åsatts själva användarkontot. Till skillnad från många andra operativsystem kräver Windows NT att man uppger kontonamn och lösenord för att kunna använda datorn man loggar in till Windows NT. Det finns ingen praktisk övre gräns för hur många användarkonton en användare kan ha, men det bör vara en absolut strävan att varje användare har ett enda användarkonto. Tvingande inloggning, att användaren måste ange användarnamn och lösenord vid inloggning, är en mycket viktig del av säkerhetssystemet i Windows NT. Det är via användarkontot och dess medlemskap i användargrupper som Windows NT kan avgöra vilka användarrättigheter och behörigheter kontot tilldelats och därmed medge eller neka önskad tillgång till resurser och objekt. Det ger också möjlighet att granska vad användaren gjort under det att hon varit inloggad på datorn (information om Granskning//Auditing studeras med Loggboken//Event Viewer). Den samvetsgranna och renläriga administratören av ett nätverk använder själv fler än ett konto. När hon administrerar nätverket använder hon sitt administratörskonto och när hon är vanlig användare har hon ett vanligt användarkonto. Man talar ibland om principen med lägsta möjliga privilegier alltså att använda ett konto som inte har mer omfattande privilegier än som krävs för att lösa varje enskild uppgift. Upprätta användarkonto Nya användarkonton kan vi upprätta genom att kopiera ett befintligt konto eller genom att upprätta ett helt nytt. Det är en god administratörsvana att upprätta ett antal mallkonton på vilka nya användarkonton baseras. För att upprätta ett nytt användarkonto kopierar man mallkontot. Det nya kontot ärver sedan inställningar från mallkontot. Innan användarkonton upprättas är det av vikt att man skapat riktlinjer för hur ex. konton och grupper skall benämnas (detta avhandlas i kapitel 20). Nya konton upprättas med hjälp av Kontohanteraren för 518

3 Användarkonton i Windows NT-domäner domäner//user Manager for Domains, kommandot Ny Användare//New User i menyn Användare//User. Dialogrutan för att upprätta ett nytt användarkonto (bilden är från en domänkontrollant i Windows NT 4.0). I bilden syns även knappen NW-kompatibel//NW Compat (se nedan). Inställning Användare//Username Kan vara upp till 20 tecken långt. Man bör begränsa sig till att använda enbart bokstäver och siffror (samt bindestreck). Använd gärna samma begränsningar som i DNS-namn (engelska bokstäver, siffror och bindestreck) Inställning Fullständigt namn//full Name Personens fullständiga namn Inställning Beskrivning//Description Lämplig beskrivning av användaren/konto. Kan ex. användas för att markera avdelningstillhörighet, vem som är chef, m.m. Inställning Lösenord/Bekräfta lösenordet//password/confirm Password Lösenordet får vara upp till 14 tecken långt och det är skiftlägeskänsligt, d.v.s. M är inte samma som m. Inställning Användaren måste ändra lösenord vid nästa inlogg- 519

4 14 Användarkonton och kontoprinciper ning//user Must Change Password at Next Logon Tvingar användaren att ändra lösenordet nästa gång hon loggar in (inträffar bara första gången efter att administratören kryssat i denna ruta). Inställning Användaren får inte ändra lösenord//user Cannot Change Password Hindrar användaren från att ändra lösenordet. Lämpligt om ett och samma konto används av flera personer. Administratören sköter då ändringen av lösenord. Inställning Lösenordet upphör aldrig att gälla//password Never Expires Kan vara bra för de konton som används för systemunderhåll, ex. fil- och mappduplicering. Kom bara ihåg att ändra lösenord för hand med lämpliga intervall. Inställning Inaktivt konto//account Disabled Förhindrar att kontot används. När ett konto skall tas bort bör det först inaktiveras för att verkligen bli säker på att det skall tas bort eftersom det inte går att återfå rättigheter och behörigheter, för ett borttaget konto. Inte ens genom att upprätta ett nytt konto med samma namn. Också användbart när man upprättar mallkonton vilka aldrig skall användas vid inloggning utan enbart för att upprätta nya konton. Inställning Låst konto//account Locked Out Syns inte vid upprättande av ett nytt användarkonto utan endast när man studerar inställningar för ett befintligt konto. När kontot låsts, av Windows NT, vid för många felaktiga inloggningsförsök kommer rutan att vara ikryssad. Kontot låses upp genom att ta bort krysset. Detta är enda användningen av denna inställning, man kan inte nyttja den för att låsa ute konton, (rutan Inaktivt konto är för detta ändamål). Inställning Grupper//Groups Ange de grupper som användarkontot skall vara medlem av. Inställning Profil//Profile Ange profil, inloggningsskript och hemmamapp för användarkontot. 520

5 Användarkonton i Windows NT-domäner Inställning Tider//Hours Ange begränsningar i tid när användarkontot kan logga in till domänen. Inställning Inloggning på//logon To Kontot kan användas för att logga in från alla datorer eller upp till åtta namngivna datorer. Inställning Konto//Account Här kan man ange en bortre tidsgräns för kontots giltighet och man kan ange att kontot skall vara ett s.k. domänlokalt konto. Inställning Uppringning//Dialin Inställningar för huruvida användarkontot tillåts fjärransluta (Remote Access Service, RAS) till domänen. Inställning NW-kompatibel//NW Compat Inställningar för NetWare-kontot (om Services for NetWare, FPNW/DSMN, installerat och Windows NT skall underhålla även NetWare-konton). När man studerar ett befintligt konto ser man alltid 14 asterisker, *, i rutorna Lösenord/Bekräfta lösenordet//password/confirm Password, detta för att man inte skall ges någon ledtråd till lösenordets egentliga utseende. Domänlokala konton Domänlokala konton upprättas i en domän för användare i andra domäner som domänen inte har en domänkoppling till. Det kan vara andra Windows NT-domäner eller LAN Manager-domäner. Ett domänlokalt konto kan inte användas för att logga in lokalt i den domän där det upprättas, det vill säga kontot fungerar endast när användaren försöker nå servrar i den domänen från sin hemmadomän med sitt vanliga hemmakonto. Allt annat är samma, det vill säga lösenord måste bytas, gruppmedlemskap och användarrättigheter fungerar på samma sätt som vanliga domänkonton. Domänlokala konton kom till som ett sätt att ge användare av äldre operativsystem från Microsoft (läs: LAN Manager) tillgång till Windows NT-servrar över nätverket. 521

6 14 Användarkonton och kontoprinciper När jag försökt använda denna typ av konton inträffar något lustigt: kontot fungerar endast mot domänkontrollanter, inte fristående Windows NT Server. Om jag loggar in på en annan domän med samma namn som ett domänlokalt konto i den första domänen och försöker nå en icke-domänkontrollant i kontots domän beter sig den datorn som om kontot inte alls funnes eller felaktigt lösenord uppgivits (felmeddelande 1326). Försöker jag nå domänkontrollanter fungerar det hela som tänkt. (Undrar om detta är ytterligare en kvarleva från Windows NT Advanced Server där det endast fanns domänkontrollanter, inga fristående servrar ) Inställningar för användarkontots miljö (profil, inloggningsskript, sökväg till hemmamapp) Det som döljer sig bakom knappen Profil//Profile i dialogrutan för användarinformation brukar, vid första påseendet, orsaka en viss förvirring. Vi finner nämligen en ny dialogruta bakom denna knapp, en dialogruta i vilken man gör inställningar för tre ganska olika saker. Det blir inte bättre av att man måste välja den ena eller den andra i ena gruppen både-och fungerar inte. Dialogrutan för användarmiljö (nås genom att trycka på knappen Profil//Profile i dialogrutan för användarinformation). I ena gruppen, Användarprofiler//User Profiles, kan du välja att låta kontot få en kontoprofil, ett inloggningsskript eller båda. Den andra gruppen, Arbetskatalog//Home Directory, fungerar så att du måste välja en av de två Lokal sökväg//local Path och 522

7 Användarkonton i Windows NT-domäner Anslut till//connect To. Användarprofiler//User Profiles Sökväg för användarprofil//user Profile Path Användarprofiler används för att spara mjuka inställningar, såsom bakgrundsfärg, personliga programgrupper, upprättade nätförbindelser, etc. I Kontohanteraren för domäner//user Manager for Domains kan man ange att man vill spara användarkontots profil på en server för att ladda ned denna profil till vilken Windows NT-dator användaren än loggar in på. När man anger denna sökväg i ett mallkonto kan man dra nytta av en fördefinierad miljövariabel, Servername. När ett nytt konto skall upprättas anger administratören ett värde för Servername. Namn på inloggningsskript//logon Script Name När en användare loggar in på Windows NT är det möjligt att automatiskt köra ett inloggningsskript. Inloggningsskript används för att göra inställningar för aktuell användare. Microsoft anser att profiler är att föredra framför inloggningsskript, p.g.a. att profiler är kraftfullare. Inloggningsskript kan dock vara ett hjälpmedel vid följande situationer: q Användare som loggar in från MS-DOS, WfWG eller OS/2 q Man vill administrera gemensamma nätverksförbindelser för en grupp av användare q Vid uppgradering från en LAN Manager-miljö där man använt inloggningsskript. Ett inloggningsskript är oftast en kommandofil (batch-fil) (.bat eller.cmd), men även ett program kan användas som inloggningsskript. Om man använder ett program, måste man vara noga med att köra rätt plattformsversion av programmet eftersom Windows NT kan användas på Intel- och flera andra plattformar. Miljövariabeln Processor kan användas för att avgöra vilken plattform som användaren loggar in i från. Det finns ytterligare miljövariabler som kan användas i inloggningsskript för Windows NT Workstation: HomeDrive, HomePath, HomeShare, OS, UserDomain och UserName. Alla inloggningsskript som används skall placeras i mappen 523

8 14 Användarkonton och kontoprinciper %SystemRoot%\system32\repl\import\scripts (förutsatt att den mappen delas ut med resursnamnet netlogon, vilket är standard på alla domänkontrollanter). Administratören ansvarar för att ett inloggningsskript med rätt namn upprättas och finns i rätt mapp. Har man behov att ändra mapp för inloggningsskripten bör man först göra klart för sig hur de skall kopieras till alla domänkontrollanter så att de har samma mappstruktur. Glöm inte att användare endast skall ha möjlighet att köra inloggningsskript. Beroende på hur skript görs innebär detta behörigheten Läsa//Read eller endast Exekvera//Execute som lokal behörighet. Den domänkontrollant som validerar inloggning för användarkontot måste ha en kopia av inloggningsskriptet varför man måste tillse att alla inloggningsskript dupliceras till alla domänkontrollanter (alla Windows NT Server-datorer som är primär domänkontrollant eller reservdomänkontrollant). Arbetskatalog//Home Directory [arbetsmapp/hemmamapp] Arbetsmappen eller hemmamappen används för att lagra användares viktiga dokument. Hemmamappen kan upprättas antingen lokalt, på den egna datorn, eller på en serverdator. Fördelen med att ha viktiga dokument i en hemmamapp på en server är att säkerhetskopiering då blir enklare och lättare att administrera. Vanligast är att den enda som behörighet till sin egen hemmamapp är ägarinnans eget användarkonto. Om hemmamappen anges blir det denna som kommer att gälla som aktuell mapp när man startar en kommandotolk och även när man sparar filer via Arkiv.Spara//File.Save (förutsatt att det använda programmet inte har andra inställningar). q Skall hemmamappen vara lokal (på den dator där användaren loggar in) anges hela sökvägen, ex. c:\users\ellaj. q När man upprättar en hemmamapp på en server anger man sökvägen med ett UNC-namn, ex. \\gefion\users\ellaj. Om man arbetar med mallkonton kan det underlätta att ge hemmamappar samma namn som användarkontot. Detta medger att man då anger sökvägen med miljövariabeln UserName. I de flesta fall klarar Kontohanteraren för domäner//user Manager for Domains att göra en hemmamapp med hjälp av angiven sökvägen, skulle den inte klara det ges besked härom. 524

9 Användarkonton i Windows NT-domäner Lokal sökväg//local Path Det blir den mapp på den lokala datorn som har detta namn. Finns inte mappen blir det \Skrivbord//Desktop. Du måste skriva hela sökvägen och får inte använda UNC-namn. Enhetsbokstav krävs! Anslut till//connect To Du måste använda UNC-namn. Skulle användaren inte logga in från en Windows NT-dator kan du ändå använda miljövariabeln HomeShare i en kommandofil eller KiXtart för att plocka upp hemmamappen. Kopiera användarkonton Många gånger är det snabbare och enklare att kopiera ett befintligt konto än att upprätta ett helt nytt. Den största fördelen med att kopiera konton är att gruppmedlemskap kopieras till det nya kontot. Kontohanteraren för domäner//user Manager for Domains har ett kommando, Kopiera//Copy, i menyn Användare//User, avsett just för detta. Alla inställningar kopieras inte till det nya kontot, tabellen sammanfattar: Egenskap (knappnamn) Användarnamn//Username Fullständigt namn//full Name Beskrivning//Description Inställningar kopieras Nej Nej Kryssrutan Användaren måste ändra lösenord vid Ja nästa inloggning/- /User Must Change Password at Next Logon Kryssrutan Användaren får inte ändra lösenord/- Ja /User Cannot Change Password Egenskap (knappnamn) Inställningar kopieras Kryssrutan Lösenordet upphör aldrig att gälla/- Ja /Password Never Expires Kryssrutan Inaktivt konto//account Disabled Nej (inte ikryssad) Grupper//Groups Ja Ja 525

10 14 Användarkonton och kontoprinciper Profil//Profile Tider//Hours Inloggning på//logon to Konto//Account Uppringning//Dialin NW-kompatibel//NW Compat Ja Ja Ja Ja Ja Ja Inga av de användarrättigheter och behörigheter som åsatts ursprungskontot direkt kommer att kopieras till det nya kontot. Eftersom det nya kontot ändå blir medlem av samma grupper som ursprungskontot kommer den som använder det nya kontot att åtnjuta lämpliga rättigheter och behörigheter genom medlemskap i grupperna. Byta namn på användarkonton Det är fullt möjligt att byta namn på befintliga användarkonton, även de inbyggda kontona. Kontohanteraren//User Manager är dock inte gjord så att det går att byta namn på fler än ett konto i taget. När man byter namn på ett konto bibehålls alla tilldelade användarrättigheter//user rights, behörigheter och andra inställningar som åsatts kontot, endast själva kontonamnet ändras. Det inbyggda kontot Administratör//Administrator kan ges ett nytt namn, men det kan inte tas bort. Av säkerhetsskäl kan det vara en god idé att byta namn på detta konto. Om man byter namn på det måste en datorbuse försöka lista ut även kontonamnet och inte bara lösenordet för Administratör//Administrator. Inaktivera//disable och ta bort användarkonton Ett gott sätt att ta bort användarkonton är att först inaktivera//disable kontot och sedan, efter lämplig tid, ta bort. Vad som är lämplig tid är inte lätt att säga, men allt mellan trettio sekunder och trettio månader kan vara lämplig tid. Anledningen till att det är lämpligt att vänta med att ta bort kontot är att vi aldrig kan återskapa ett konto med samma nummer. Till skillnad från svenska personnummer är nämligen konton (och även grupper) i Windows NT försedda med ett garanterat unikt nummer, som dessutom aldrig återanvänds. Mer 526

11 Användarkonton i Windows NT-domäner om detta senare i kapitlet. Varje gång du tar bort ett konto eller grupp i Windows NT visas en dialogruta vars innebörd är att det inte går att upprätta ett nytt konto, en ny grupp, med samma unika nummer (SID). Varningstexten som visas när du försöker ta bort ett konto i Kontohanteraren för domäner (texten på svenska är en smula hopblandad, Microsoft räknar väl med att svenskar förstår ändå). Varningsrutan som visas när man försöker ta bort ett användarkonto (en snarlik text visas om man försöker ta bort en grupp). Det nummer som används kallas i Windows NT för Security Identifier, SID. Sett ur Windows NT:s synvinkel är konton med olika SID helt olika konton: oavsett om ett nytt konto råkar få samma namn som ett gammalt, numera borttaget, konto. Kontots SID finns i olika listor Det är kontots SID, aldrig namnet, som lagras av Windows NT när man gör ett användarkonto till medlem av globala grupper och även när kontot används direkt i behörighetslistor (Access Control List, ACL) för olika resurser. Windows NT visar namnen för oss människor eftersom de är lättare att arbeta med. För att kunna visa namnet måste det finnas ett konto med aktuell SID i domänens kontodatabas. Det är i stort sett vid ett enda tillfälle som Windows NT lagrar namnet på ett konto och inte dess SID: användarkonton för tjänster. När en tjänst ställs in att använda ett annat konto än System//System kommer kontots domän och namn att sparas i Registret//Registry, inte dess SID. När konton/grupper tas bort händer det att Windows NT visar namnet: Okänt konto//account Unknown i behörighetslistor. 527

12 14 Användarkonton och kontoprinciper Detta betyder att Windows NT funnit en SID i behörighetslistan men inte kunnat finna denna SID i domänens kontodatabas och därmed inte heller namnet på kontot/gruppen. Med andra ord: inaktivera konton q SID:ar återanvänds aldrig q Ett nytt konto med samma namn som ett gammalt, borttaget, kontot har en annan SID än det gamla, det är ett helt annat konto q Windows NT spar kontons/gruppers SID i olika listor q Tar vi bort ett konto för tidigt blir det en massa jobb att göra ett nytt konto till medlem av olika grupper, ordna till behörighet för hemmamapp, o.a. q Inaktiverade konton kan inte användas för inloggning, de är inbrottssäkra Med det ovan anförda vill jag föreslå en administrativ regel: först inaktivera, sedan ta bort användarkonton, uppsägningar, eller vad det kan vara, kan ju återtas. När kontot är inaktiverat/vilande kan ingen använda det för inloggning, men alla inställningar är intakta. (Det finns ingen inbyggd möjlighet i Windows NT att inaktivera grupper, men det går att göra något liknande, läs mer om grupper i kapitel 23.) Ta bort konton Som nämnts ovan kommer ett konto som tas bort och återskapas med samma namn att tappa alla de inställningar av användarrät tigheter, behörighet, gruppmedlemskap, etc. som det ursprungliga kontot hade. Det är inte möjligt att ta bort de inbyggda kontona Administratör//Administrator och Gäst//Guest, man kan endast byta namn på dem. En liten finess kommer du att upptäcka när du tar bort konton/grupper om kontot/gruppen förekommer i behörighetslistor kommer Windows NT automatiskt avlägsna dessa behörighetsposter. Detta sker när du studerar behörighetsposten eftersom Windows NT i detta läge kontaktar en domänkontrollant för att kunna visa de kontonamn/gruppnamn som hör ihop med SID:arna i behörighetslistan (kom ihåg: det är endast SID:en för 528

13 Användarkonton i Windows NT-domäner kontot/gruppen som sparas). (Snyggt, Microsoft!) Security Identifier, SID och Relative Identifier, RID Vad gäller användarkonton och grupper av alla slag har de ett gemensamt de har alla varsin Security Identifier. En SID för konton eller grupper vi upprättar själva i Windows NT består av fyra delar: q Versionsnummer för SID (SID i Windows NT 4.0 har versionsnummer 1 och det kommer att gälla även i Windows NT 5.0) q Märkningsdel (talar om vilken del av Windows NT som upprättat konton/gruppen) q En unik del som bestäms vid installation av Windows NT (tre 32-bitars heltal som aldrig skall upprepas mellan installationer) (finns om kontot är ett användarkonto, en global grupp eller en ny lokal grupp) q Relative Identifier (32-bitars heltal, RID är ett löpnummer som börjar på och räknas upp till (2 32 )) Låt oss studera ett exempel (SID:ar skrivs alltid med S- just för att visa att de är SID:ar): S Versionsnummer 1 Märkningsdel 5-21 Unik del Relative Identifier, RID 4711 Märkningsdelen, 5-21, visar att det är Kontohanteraren//User Manager eller Kontohanteraren för domäner//user Manager for domains som använts för att åstadkomma denna SID. Den unika delen, , tillverkas vid installation av Windows NT. Microsoft använder en metod vilken skall tillse att det inte finns två Windows NTdatorer på detta jordklot som någonsin får samma unika del. Alla domänkonton och globala grupper i samma domän har samma unika del (och nya lokala grupper på PDC:n). Likaså har alla lokala konton och lokala grupper på datorer som är 529

14 14 Användarkonton och kontoprinciper icke-domänkontrollanter samma unika del. Det finns inget sätt att förutse dessa tre tal och man kan inte heller se på dem om de tillhör en domän eller en icke-domänkontrollant. RID-delen, 4711, säger oss att detta är ett konto eller grupp som är upprättat av en administratör. Nästa konto eller grupp som upprättas i denna domän eller på denna icke-domänkontrollant får RID-nummer I kapitel 5 jämför jag RID med gammaldags kölappar, en sådan där rulle man river av en gul kölapp från. När man fått det man önskat slänger man ofta lappen i en liten papperskorg på disken. Så fungerar även RID-lapparna. Skillnaden är ganska liten: RID-rullen består av drygt fyra miljarder lappar ( stycken) och RID-lappen slängs i ett svart hål efter användandet. Skulle RID-rullen ta slut måste Windows NT installeras om: då fås en ny SID och RID sätts till (Tänk på att en gammal säkerhetskopia kan skriva över ett nyare RID-värde i Registret//Registry.) Det finns inget sätt att avgöra om denna SID hör till ett lokalt användarkonto på en Windows NT Workstation, ett domänkonto, en lokal grupp på en fristående Windows NT Server, en kontrollantlokal grupp eller en global grupp på den primära domänkontrollanten. När Windows NT installeras sätts RID så att det första kontot/den första gruppen du själv upprättar får RID nummer 1000 (det första kontot, nummer 1000, blir det egna datorkontot för den primära domänkontrollanten om du installerar en domän). Därefter ökar RID med ett för varje nytt konto/ny grupp som upprättas. RID ändras inte när ett konto eller grupp tas bort, den räknas endast upp och endast när ett nytt konto eller ny grupp upprättas. Anledningen till detta är att man inte av misstag skall kunna upprätta ett konto för en ny användare som råkar få samma SID och därmed samma privilegier som ett gammalt, borttaget, konto, ens om kontona får samma namn. Man kan ex. råka in i ett läge där VD:n, vilkens konto har alla privilegier på nätet, avgår. Något senare, när alla glömt förra VD:n börjar en person med snarlikt namn på företaget och man upprättar ett användarkonto för henne med samma namn som VD:ns konto hade. Detta nya konto får under inga omständigheter ärva privilegierna från VD:ns konto. De två användarkonton som Windows NT upprättar vid installation, Administratör//Administrator och Gäst//Guest har 530

15 Windows NT-datorer har datorkonton i en Windows NT-domän fast, förutbestämd, RID: Användarkonto SID RID (hex.) Administratör/- S n1-n2-n (0x1F4) /Administrator Gäst//Guest S n1-n2-n (0x1F5) Det finns en liten begreppsförvirring vad gäller användningen av ordet SID: ibland används det för hela numret, andra gånger för att beskriva delen före RID. Jag skall försöka kalla delen före RID för grund-sid och kalla grund-sid (S n1-n2-n3) tillsammans med RID för SID eller hela SID (kontots hela SID). Delen med de tre heltalen (n1-n2-n3) är just den del som bestäms vid installationen (för domänen vid installationen av den primära domänkontrollanten). Windows NT-datorer har datorkonton i en Windows NT-domän I domänens kontodatabas finns det ett datorkonto för varje Windows NT-dator i domänen. Kontot har samma namn som datorn, med ett dollartecken ($) på slutet. Datorkontot används för att upprätta en secure channel mellan datorn och en domänkontrollant. Kontoprinciper//Account Policies Varje kontodatabas innehåller en uppsättning regler som styr användning av lösenord och inloggning. Reglerna i domänens kontodatabas gäller självklart för alla domänkonton och inloggningsförsök med dessa konton, oavsett vilken dator man råkar använda för att logga in. Om du loggar in till domänen från en Windows NT-dator med ditt domänkonto spelar det alltså ingen roll vilka regler som gäller för lokala konton på den datorn inloggningen lyder under domänens kontoregler/kontoprinciper. Med hjälp av goda inställningar för kontoprinciper kan du göra mycket för säkerheten i ditt nätverk. Kom dock ihåg att du ensam inte kan agera brandvägg i din organisation alla måste samarbeta. Det bästa är om kraven på säkerhet kommer uppifrån då ser de till alla följer era regler! Hantering av kontoprinciper är förbehållet medlemmar i Administratörer//Administrators. 531

16 14 Användarkonton och kontoprinciper Vad styr kontoreglerna/kontoprinciperna Kontoreglerna skulle kunnas säga vara två uppsättningar regler: en uppsättning för lösenorden; deras längd, ålder, m.m. och en uppsättning för inloggningsförsök och utloggning; hur många felaktiga försök som kan godtas utan att kontot spärras, om användarna skall loggas ut automatiskt när deras tid är ute, m.m. Hantera kontosäkerhet/kontoprinciper Med en viss naturlighet är det Kontohanteraren för domäner//user Manager for Domains som används för att hantera domänens kontoregler. Du finner inställningarna i menyvalet Konto//Account i menyn Principer//Policies: Kontoprinciperna ovan skulle kunna vara ganska vettiga i en normal Windows NT-domän. Kontoprinciper//Account Policies lägger en grund för domänens hantering för sådana saker som lösenords längd, hur gamla lösenord får bli innan de måste bytas, m.m. Förändringar i Kontoprinciper//Account Policies träder i kraft nästa gång en användare loggar in. 532

17 Kontoprinciper//Account Policies Inställning Maximiålder//Maximum Password Age Den tid ett lösenord kan användas innan användaren måste byta Värden Aldrig eller dagar Inställning Minimiålder//Minimum Password Age Den minsta tiden mellan två byten av lösenord Värden Tillåt ändringar nu eller dagar Inställning Minsta längd för lösenord//minimum Password Length Det minsta antal tecken ett lösenord kan innehålla Värden Tillåt tomt lösenord eller 1-14 tecken Inställning Unika lösenord//password Uniqueness Det antal redan använda lösenord som systemet kommer ihåg. Användaren tillåts inte använda ett gammalt lösenord igen innan minst så här många nya använts Värden Jämför inte med gamla lösenord eller 1-24 gamla lösenord Inställning Inga utelåsta konton//no account lockout Användaren låses aldrig ute från systemet, oavsett hur många gånger användaren försökt logga in med fel lösenord Värden Ifylld/icke ifylld Inställning Utelåsta efter//account lockout Största antal felaktiga inloggningsförsök som godtas innan kontot låses ute Värden Inställning Återställ räknare efter//reset count after Längsta tid (minuter) som kan förflyta mellan två felaktiga inloggningsförsök (d.v.s. för att de av systemet skall räknas samman för att stämmas av mot inställningen för Utelåsta efter). Ex. fem försök gör att nätbusar kan göra fyra försök, vänta den tid du ställt in här och sedan göra fyra nya försök) Värden

18 14 Användarkonton och kontoprinciper Inställning Utelåsningsvaraktighet//Lockout Duration Om Alltid väljs måste en Administratör//Administrator låsa upp kontot (via Kontohanteraren//User Manager). Varaktighet anger en tid under vilken kontot är utelåst/spärrat Värden Alltid eller (minuter) Inställning Koppla automatiskt från fjärranvändaren på servern när inloggningstiden går ut//forcibly disconnect remote users from server when logon hours expire Om ett kontos tillåtna inloggningstid är begränsat åstadkommer ett kryss i denna ruta att användarens konto kopplas från vid utgången av den tillåtna tiden Inställning Användare måste logga in för att ändra lösenord//users must log on in order to change password Kryss i denna betyder att en användare inte kan ändra ett utgånget lösenord själv (eftersom detta kräver att användaren loggar in), utan administratören måste byta lösenord åt användaren Vilka kontoprinciper bör gälla Något att tänka på för era egna beslut vad gäller kontoprinciper. Kom ihåg: det viktiga är inte att göra som jag föreslår utan att era egna regler passar er verksamhet. Regler för lösenord Det finns fyra regler för lösenord: q Maximiålder//Maximum Password Age q Minimiålder//Minimum Password Age q Minsta längd för lösenord//minimum Password Length q Unika lösenord//password Uniqueness Lösenords ålder Det finns fler än en återförsäljare av datorer och programvara i Sverige som gör betydande inkomster var sjätte vecka då ringer kunder och ber om hjälp att ändra lösenorden i Windows NT. Sex veckor råkar vara den förvalda tiden för lösenords ålder i Windows NT Server. Fjorton dagar före bytet får användaren en första påminnelse om att lösenordet snart skall bytas. Denna 534

19 Kontoprinciper//Account Policies första påminnelse kan styras om hon använder Windows NT Workstation 4.0. Tiden för första påminnelse ändras genom att lägga till ett värde i Registret//Registry på klienten. Värdet skall läggas till i nyckeln: HKey_Local_Machine \Software\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon\ Namnet skall vara PasswordExpiryWarning och datatypen skall vara DWord-värde//DWord Value (Reg_DWord. Dess innehåll sätter du till det antal dagar före lösenordets upphörande som den första påminnelsen skall skickas. Hur länge måste jag vänta innan jag kan byta tillbaka Inställningen Minimiålder//Minimum Password Age är verkligen smart. Den tar hand om de användare (i likhet med författaren under en period) som har ett favoritlösenord. Vid lösenordsbyte bytte jag snällt lösenord, bara för att snabbt byta tillbaka till mitt favoritlösenord. Om systemet mindes ett antal gamla lösenord bytte jag i rask takt detta antal lösenord tills jag kunde använda mitt favoritlösenord igen. Att hantera ett antal lösenord för att kunna komma tillbaka till favoriten var inga problem: jag gav dem ett löpnummer (password1, password2, password3, ). I Windows NT kan en administratör, med inställningen Minimiålder//Minimum Password Age, ställa in lösenordsreglerna så att man inte omedelbart kan byta lösenord, utan måste låta det nya lösenordet gälla det antal dygn som anges. Då är det bara att ge upp sitt favoritlösenord och rätta in sig i ledet. Lösenords längd De flesta administratörer delar säkert uppfattningen att längre lösenord är svårare att knäcka och därmed säkrare. Det verkar som om lösenord i Windows NT bör vara mycket längre än sju tecken (använd helst fjorton tecken långa lösenord). Enligt vissa uppgifter, som skymtat förbi i elposttrafiken, är det ganska lätt att knäcka de första sju tecknen i Windows NT:s lösenord. Å andra sidan: när lösenord blir för långa och krångliga är det lätt hänt att de skrivs ned på gula lappar. 535

20 14 Användarkonton och kontoprinciper Hur många gamla lösenord skall systemet hålla reda på så att jag inte återanvänder mitt favoritlösenord För att se till att användaren faktiskt använder olika lösenord använder du inställningen Unika lösenord//password Uniqueness. Den primära domänkontrollanten kommer då att spara så många gamla lösenord som Unika lösenord//password Uniqueness anger för att jämföra dem med nya lösenord. Ett gammalt lösenord kan inte återanvändas förrän detta antal använts. Denna inställning görs lämpligen i samklang med Minimiålder//Minimum Password Age. Regler för inloggning/utloggning Inloggningsförsök och tvingad utloggning styrs av sex olika regler: q Inga utelåsta konton//no account lockout q Utelåsta efter//account lockout q Återställ räknare efter//reset count after q Utelåsningsvaraktighet//Lockout Duration q Koppla automatiskt från fjärranvändaren på servern när inloggningstiden går ut//forcibly disconnect remote users from server when logon hours expire q Användare måste logga in för att ändra lösenord//users must log on in order to change password Skall konton kunna låsas ute Jag tror att det är en god idé att konton verkligen skall kunna låses ute/spärras om någon gör för många felaktiga inloggningsförsök med användarkonton. Även om du inte misstror dina användare kan utelåsning åtminstone tjäna som en påminnelse att lösenorden är oerhört viktiga för användaren. Å andra sidan har vi problemet med nätbusar som försöker blockera resurser (Denial of Service, DoS). Om dina användares konton kan låsas ute kommer nätbusens attacker inriktas just på att åstadkomma denna utelåsning. Hur många inloggningsförsök är rimligt Hur många felaktiga inloggningsförsök du skall medge innan kontot låses ute/spärras beror på vilka säkerhetskrav er organi- 536

21 Kontoprinciper//Account Policies sation har. Väg säkerhetskrav mot användarnas och din egen bekvämlighet (om du måste låsa upp deras konton varje de spärras). Skall räknare återställas med automatik Min administrativa filosofi är att jag vill veta vad som händer i nätverket. Därför vill jag gärna ha ett högt värde på återställningen av räknaren för felaktiga inloggningsförsök. Administratören skall låsa upp kontot Jag föredrar att användaren ringer och berättar att hennes konto låsts ute än att jag ser det i Loggboken//Event Viewer senare. Användarna slängs ut efter inloggningstiden Genom att ge användarkonton tillräcklig tid att utföra sina sysslor kan jag hjälpa dem som glömmer logga ut genom att låta domänkontrollanterna koppla ifrån dem automatiskt. Lösenordsändringar kan endast ske efter inloggning Denna inställning innehåller en fälla. Om dina användare måste logga in för att kunna ändra lösenord måste denna inställning svara mot inställningen Användaren måste ändra lösenord vid nästa inloggning//user Must Change Password at Next Logon för enskilda användarkonton. Om båda är ikryssade kommer användaren inte kunna ändra lösenordet och därmed inte bli inloggad till domänen. Gissa vem hon ringer då? Kontot Administratör//Administrator kan inte låsas ute/spärras OBS! Administratörskontot kan inte låsas ute. Det administratörskonto som upprättades vid installationen kan inte spärras (för lokal inloggning, dock kan det spärras för inloggning över nätverket, om du använder PassProp). (Läs i kapitel 16 om PassProp.) Detta för att administratören skall kunna låsa upp konton som kräver hjälp för att låsas upp. Läs mer om detta kontos unika egenskaper i kapitel

22 14 Användarkonton och kontoprinciper Service Pack 3 medförde nya möjligheter Kryptera kontodatabasen med SysKey.Exe Verktyget SysKey.Exe ger dig möjlighet att kryptera kontodatabasen så att den blir oanvändbar för den som inte har rätt nyckel. Systemet är efter användning av SysKey.Exe inte längre startbart utan krypteringsnyckeln. Tanken med SysKey.Exe är alltså att även om kontodatabasen stjäls är den krypterad vilket gör att den inte kan användas. En mycket viktig sak: krypteringen kan inte göras ogjord! Har du en gång krypterat kontodatabasen kan du inte använda SysKey.Exe för att dekryptera den. Det enda sättet att återställa den är från säkerhetskopior gjorde före krypteringen (se nedan om reparationsdiskett), vilket naturligtvis medför att alla nya konton och alla andra förändringar du gjort sedan krypteringen går förlorade. Vad gäller nyckeln själv kan man välja olika sätt att förvara den vilket medger olika möjligheter för datorn att starta: q Låta SysKey.Exe tillverka en slumpmässig systemnyckel och spara den på datorns hårddisk. Systemnyckeln behandlas så att det skall vara omöjligt att återställa den i ursprunglig form (Microsoft kallar detta: a complex obfuscation algorithm). Datorn kan i detta fall starta utan mänskligt ingripande. q Spara systemnyckeln som SysKey.Exe tillverkat på en diskett. Vid varje systemstart måste denna diskett användas (Windows NT kommer att be om den innan inloggningsdialogen visas). Mellan användningarna bör disketten förvaras på ett säkert ställe (på samma ställe som ni har era säkerhetskopior och reparationsdisketter). q Från ett lösenord givet av en administratör tillverkar Sys- Key.Exe en systemnyckel. Den välkända algoritmen Message Digest 5 (MD5) används för att få fram en huvudnyckel för att skydda lösenordet. Vid varje systemstart kommer Windows NT att be om systemnyckeln. 538

23 Service Pack 3 medförde nya möjligheter Programmet SysKey.Exe. Du måste kryptera varje domänkontrollant för sig Vi är vana vid att alla ändringar som rör kontodatabasen automatiskt förs över till alla reservdomänkontrollanter från den primära domänkontrollanten av tjänsten NetLogon. Så fungerar det inte med krypteringen i SysKey.Exe. Du måste alltså kryptera varje domänkontrollant för sig. Säkerhetskopiera kontodatabasen före kryptering Innan du krypterar kontodatabasen måste du säkerhetskopiera den. Du gör det med RDisk.Exe eller RegBack. Mer information Mer information finner du i TechNet-artikel Q Striktare lösenord I Service Pack 3 för Windows NT 4.0, den är inte tillgänglig för Windows NT 3.51, skickade Microsoft med en fil, PassFilt.DLL, vilken gör att det lösenord som används måste följa hårdare regler än tidigare. PassFilt.DLL gör att lösenord måste följa dessa regler: q Lösenordet måste vara minst sex tecken långt (det bör vara längre) q Lösenordet måste innehålla tecken från minst tre (helst alla fyra) av dessa fyra teckenklasser (det är inte begränsat till dessa fyra): Stora bokstäver ur det engelska alfabetet A.. Z 539

24 14 Användarkonton och kontoprinciper Små bokstäver ur det engelska alfabetet a.. z Siffror Skiljetecken m.fl. punkt, utropstecken, q Lösenordet får inte innehålla kontonamnet och inte heller någon del av användarens namn (förnamn eller efternamn). Microsoft har gjort PassFilt.DLL så att dessa regler inte kan ändras, men det går att tillverka en slik fil själv (se nedan). Låt mig lägga till en regel som drar fördel av det faktum att vi inte har engelska som modersmål: q Lösenordet bör innehålla en eller flera svenska/nordiska bokstäver det gör det svårare för utom-nordiska personer att gissa lösenordet Installera PassFilt.DLL PassFilt.DLL skall finnas på alla de Windows NT-datorer som har en egen, aktiv, kontodatabas. I en Windows NT-domän skulle det räcka med att installera PassFilt.DLL på den primära domänkontrollanten, alla Windows NT Workstation och de Windows NT Server som inte är domänkontrollanter. Med tanke på att alla i gruppen domänkontrollanter kan bli primär domänkontrollant får vi en enkel regel för installation av PassFilt.DLL: PassFilt.DLL installeras på alla Windows NT-datorer (oavsett om de är Windows NT Workstation eller Windows NT Server och oavsett om de är domänkontrollanter eller inte). 1. Troligen räcker det med att lägga på Service Pack 3 (eller det senaste Service Pack du har efter Service Pack 3) för att PassFilt.DLL skall kopieras till Windows NT:s systemmapp (%SystemRoot%\System32). Finns den inte där så leta rätt på den och kopiera dit den. 2. Upprepa punkt 1 på alla Windows NT-datorer i ert nätverk. Nu skall vi ändra i Registret//Registry alltså säkerhetskopierar vi detsamma först. 3. Säkerhetskopiera Registret//Registry på samma datorer som i punkten ovan. Nu måste vi använda RegEdt32.Exe (den äldre registereditorn 540

25 Service Pack 3 medförde nya möjligheter som fanns redan i Windows NT 3.51), det är bara den som kan upprätta värden av den typ vi behöver. 4. Starta RegEdt32.Exe och öppna nyckeln HKey_Local_Machine\ System\ CurrentControlSet\ Control\ Lsa\ RegEdt32.Exe med nyckeln \Lsa öppen. 5. Syns värdet Notification Packages i det högra fönstret? I så fall hoppar du över nästa två punkter (punkt 6 och 7) och fortsätter med punkt Eftersom värdet Notification Packages inte fanns måste den upprättas. I menyn Redigera//Edit väljer du Lägg till värde//add Value. Följande dialogruta visas: 541

26 14 Användarkonton och kontoprinciper Dialogrutan för att lägga till ett nytt värde i RegEdt32.Exe. 7. Skriv Notification Packages i rutan Namn på värde//value Name, välj Reg_Multi_SZ som datatyp. 8. Dubbelklicka på namnet Notification Packages, skriv dit PASSFILT sist, på en egen rad. 9. Tryck på OK överallt och avsluta registereditorn. 10.Starta om Windows NT för att den nya inställningen skall börja gälla. Mer information Mer information finner du i TechNet-artikel Q How to Enable Strong Password Functionality in Windows NT. Skulle du ha behov av andra regler än dem som finns i PassFilt.dll kan du skriva en egen.dll som gör detta. I TechNet-artikel Q HowTo: Password Change Filtering & Notification in Windows NT finner du ännu mer information och även källkod. Byta lösenord Användare av Windows NT byter lösenord genom att trycka Ctrl+Alt+Del för att kalla fram utloggningsfönstret och sedan trycka på knappen Byt lösenord//change Password. Administratörer kan byta lösenord för det egna konto med hjälp av Kontohanteraren för domäner//user Manager for Domains (Kontohanteraren//User Manager i Windows NT Workstation). (Net User kan också användas för att byta lösenord.) Vid byte av lösenord kontaktar den lokala datorn alltid den primära domänkontrollanten (det är endast på den ändringar av domänens kontodatabas kan ske). Liksom vid inloggning är det inte lösenordet självt (i klartext) som skickas över nätverket, utan i stället lösenordet i krypterad form, i OWF-form. (Microsoft 542

27 Om man förlorar lösenordet för (det enda) administratörskontot använder alltså inte någon Challenge/Response-teknik vid byte av lösenord.) Om man förlorar lösenordet för (det enda) administratörskontot Skulle det hampa sig så att man förlorar (det lät så trist med glömmer) lösenordet till sitt enda administratörskonto finns det olika sätt att rätta till det. Det häftigaste (i meningen mest förstörande) är att använda reparationsdisketten//emergency Repair Disk. Denna innehåller kontona Administratör//Administrator och Gäst//Guest med de lösenord dessa konton hade då disketten senast uppdaterades. Dessutom kommer alla globala och lokala grupper du själv upprättat gå förlorade. Blir du tvungen att återskapa dessa går inte det eftersom de inte får samma SID (eller åtminstone osannolikt) som de gamla kontona/grupperna trots att namnen är samma. Detta gör i sin tur att behörighetslistor (i vilka endast SID finns) måste göras om med andra ord: en katastrof. I avsaknad av en färsk säkerhetskopia av kontodatabasen är reparationsdisketten förmodligen alltför mycket förstörande för att bli ditt första val. På Internet kan du hitta flera som erbjuder sin hjälp i utbyte mot pengar. Ett slikt verktyg är NTLocksmith från Winternals Software ( (Bakom Winternals Software finns herrar Mark Russinovich och Bryce Cogswell.) Återställa konton från reparations//emergency Repair-disketten Om lösenordet för Administratör//Administrator skulle gå förlorat kan man återställa det ursprungliga lösenordet från en reparations//emergency Repair-diskett eller en reparations//emergency Repair-mapp. Denna åtgärd tar bort alla användarkonton och grupper inklusive deras rättigheter och behörigheter samt återställer kontodatabasen till det utseende den hade direkt efter installation av Windows NT. Ett enkelt sätt att undvika detta är självklart att ha fler än ett användarkonto med administratörsprivilegier. Återställa konton från säkerhetskopior Om lösenordet för Administratör//Administrator skulle gå förlorat, men man har tillgång till ett användarkonto med rättighet 543

28 14 Användarkonton och kontoprinciper att återlagra filer kan man återlagra en kopia av kontodatabasen från band. Gruppen Ansvariga för säkerhetskopiering//backup Operators tilldelades nödiga rättigheter vid installation. Har du dessutom inrättat dina servrar så att de säkerhetskopierar Registret//Registry (i vilket kontodatabasen är en del) med verktyget RegBack.Exe och lagrar ett antal generationer kan RegRest.Exe återlagra en kontodatabas med ett tidigare lösenord, kanske t.o.m. utan att ställa till med någon skada. Hjälpfrågor 1. Måste man alltid uppge ett användarkonto och lösenord för att kunna använda Windows NT (logga in)? 2. Sker det någonsin att lösenord skickas i klartext i Windows NT-nätverk (icke-uppringt)? 3. Vad innebär regeln om minsta möjliga privilegier? 4. Varför kan det fördelaktigt att begränsa namn på konton på samma sätt som DNS-namn? 5. Vilket eller vilka inbyggda verktyg används för att upprätta användarkonton i Windows NT? 6. För vilka av användarnamn, fullständigt namn, lösenord m.fl. spelar det någon roll hur man använder stora och små bokstäver? 7. Kan en administratör låsa ett konto med Kontohanteraren för domäner//user Manager for Domains? 8. Kan man använda domänlokala konton från en Windows NT Workstation i samma domän för att logga in till domänen? 544

29 Hjälpfrågor 9. Varför är det enkelt och bekvämt att kopiera ett befintligt användarkonto när ett nytt skall upprättas? 10.Kan man byta namn på ett användarkonto? 11.Vad är Security Identifier, SID? 12.Varför bör man första inaktivera ett användarkonton innan det slutligt tas bort? 13.Vilken funktion har RID-delen av en SID? 14.Varför är reparationsdisketten farlig och bör förvaras inlåst? 545

30 14 Användarkonton och kontoprinciper Förslag till svar på frågor 1. Måste man alltid uppge ett användarkonto och lösenord för att kunna använda Windows NT (logga in)? Ja och nej. Om du inte ändrat någon inställning måste du alltid uppge användarkonto och lösenord. Genom att ändra i Registret//Registry kan man ställa in en enskild Windows NT-dator att automatiskt använda ett visst användarkonto och därtill hörande lösenord. I detta fall sparas lösenordet i klartext i Registret//Registry på den datorn. Ändringen kan göras för hand eller med hjälp av ett verktyg i Microsoft Windows NT Resource Kit. 2. Sker det någonsin att lösenord skickas i klartext i Windows NT-nätverk (icke-uppringt)? Nej, och ja. Normalt skickas aldrig lösenord i klartext i ett Windows NT-nätverk, inte ens vid lösenordsbyte. Däremot är Windows NT skrivet att kunna samarbeta med andra typer av SMB-servrar/klienter varför man faktiskt kan ställa in Windows NT att skicka lösenord i klartext. Detta var grund för en form av attack under Med Service Pack 3 för Windows NT 4.0 installerad kan detta endast ske om du ändrar en inställning i Registret//Registry. Se TechNet-artikel Q för mer information. (Motsvarande rättning finns även för Windows 95, se Q ) 3. Vad innebär regeln om minsta möjliga privilegier? Med regeln om minsta möjliga privilegier menar man att en administratör (det är oftast de som berörs) alltid bör sträva efter att använda ett konto med just den kraft hon behöver för att lösa den aktuella uppgiften. I praktiken använder hon nog oftast ett konto som är medlem av Domänadministratörer/ /Domain Admins, vilket har mycket omfattande privilegier 546

31 Förslag till svar på frågor (genom sina medlemskap i alla lokala grupper med namn Administratörer//Administrators). 4. Varför kan det fördelaktigt att begränsa namn på konton på samma sätt som DNS-namn? DNS-namn är begränsade till att använda det engelska alfabetet (A-Z), siffror och bindestreck. Windows NT har inga som helst problem att använda nordiska tecken, men andra program kan ha det. Dessutom används TCP/IP alltmer som nätverksprotokoll vilket gör att kontonamn som följer DNS-standard inte behöver omvandlas av NetBIOS over TCP/IP. 5. Vilket eller vilka inbyggda verktyg används för att upprätta användarkonton i Windows NT? På Windows NT Workstation använder man Kontohanteraren/ /User Manager för att upprätta konton. I Windows NT Server heter verktyget Kontohanteraren för domäner//user Manager for Domains. Detta senare verktyg kan dessutom användas för att, över nätverket, upprätta konton på antingen Windows NT Workstation eller Windows NT Server. 6. För vilka av användarnamn, fullständigt namn, lösenord m.fl. spelar det någon roll hur man använder stora och små bokstäver? Windows NT lagrar alla uppgifter precis som man skriver in dem. När man sedan anger kontonamn och annat kan man fritt blanda stora och små bokstäver, med ett undantag: lösenordet måste alltid skrivas med samma blandning av stora och små bokstäver som man använde när man skrev in lösenordet första gången. 7. Kan en administratör låsa ett konto med Kontohanteraren för domäner//user Manager for Domains? Nej, en administratör kan aldrig låsa ett konto. Ett konto låses av Windows NT om man ställt in kontoprinciper att endast tillåta ett visst antal felaktiga försök och dessa överskrids. Då kan administratören låsa upp kontot med Kontohanteraren för domäner//user Manager for Domains. Finns behovet att inte tillåta att ett konto används för inloggning kan kontot inaktiveras eller man kan ange att det 547