Design av datornätverk för skola

Relevanta dokument
Electrolux Vision ADMIN

SchoolSoft

SchoolSoft

SchoolSoft

Beskrivning av Metakatalog. Sundsvalls kommun

AppGate och Krisberedskapsmyndighetens basnivå för informationssäkerhet, BITS

SchoolSoft

Cisco WebEx: Standardprogramfix den [[DATE]]

Din guide till Windows 10

ENG-A1004: Information om studierna -övning, hösten 2014

Hur man skapar ett test i Test och quiz i Mondo 2.6

ShoreTel Communicator Överblick

Eldy Användarhandbo Table of Contents

Tjänsteportfölj IT-teamet

INNEHÅLLSFÖRTECKNING LOGGA IN HUR FÅR MAN ETT LÄRARKONTO? SKAPA LÄRARKONTO

ARKIV DIGITAL - att släktforska i färg

Tillgänglighetsguide Lunds kommun Komma igång Översikt av Guiden... 1

Kort användarmanual för Test och quiz i Mondo 2.0

Revisionsrapport 2010 Genomförd på uppdrag av revisorerna i Jönköpings kommun. Jönköpings kommun Granskning av användaradministrationen

Kom-i-gång med Movie Maker: Programmet finns under Program -> Tillbehör -> Underhållning

GEOSECMA for ArcGIS GSD datastruktur och import i en SDE geodatabas

Egen Enhet Skapa ditt egna gästinlogg

Processbeskrivning ITIL Change Management

Övningar i JavaScript del 3

Active Directory design Uppsala universitet

DIGITALISERINGSPLAN

Auktorisering och grupphantering. Projektplan

Molntjänster från Microsoft En checklista för vårdorganisationer i Sverige

Administrera filmer på Tandberg Content Server

Checklista förändringsledning best practice Mongara AB

BaraTrav Inställningar Version 1.3.4

Delmarknad 4: Privatmarknaden. - Bilaga till PTS marknadsöversikt för innovatörer

Kravspecifikation Batchbeställningar Version:

En kom i gång manual till SPF:s hemsidor

ANVÄNDARMANUAL TEST OCH QUIZ för Mondo 2.0 Version 1

Produktöversikt Boolware. SOFTWARE CORPORATION

En kom i gång manual till SPF:s hemsidor

Leverantörsbetalningar

Användarhandbok OESpeaker 1.0

Plus500CY Ltd. Säkerhets- och cookie policy

Processbeskrivning fakturahantering

Maingate Manager Användarhandledning

Att skapa och hantera systemdokumentation

Förstudie avveckling av EPi-Server för EBH-stödet

Kursbeskrivningar. Kursfakta för standardkurser

1: Apogee Preflight. Grundkunskaper för kursen För att kunna tillgodogöra sig kursen bör man ha grundläggande kunskaper om Apogee och prepressarbete.

Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk

Användarhandbok OSSpeaker 10.2 version 2

För att kunna utföra en variable data printning böhöver du följande filer:

CHECKLISTA FÖR NYA MEDARBETARE VID ONKOLOGI-PATOLOGI

Integritetspolicy Bokförlaget Nona

ANVÄNDARMANUAL. Version Euromed Networks AB. Årstaängsvägen 11, Stockholm. Tel (Juni 2006)

Integrationshandledning eped - läkemedelsinstruktioner

1(2) För kännedom; Fullmäktiges. presidium. uppföljning. barn- och. iakttagelser: finns. lokalt. Behov. Omorganisering. g renodlat tjänsterna

Guideline Sportident-systemet

Användarhandbok OESpeaker 10.2

BaraTrav Meny Version 1.2

Del 5: Rekommendationer och projektrapport

DETALJERAT PROGRAM FÖR UNDERVISNINGEN

Praktiska råd vid upphandling av tekniska produkter och tjänster. Södra teatern

Risk- och sårbarhetsanalys av SUNET Box för Karolinska Institutet

Avigilon Control Center Bruksanvisning till server. Version 6.2

SchoolSoft

SNABBGUIDE INSTALLATION AV LARMTABLÅ USM OCH BSM

Instruktioner för ansökan till VFU utomlands i Moveon Utbildningsvetenskapliga fakulteten

2 PROGRAMMERA EN KNAPP FÖR UPPDRAG

Övningar i JavaScript del 7

Anmälan av stipendier med systemet Personec F ESS

Guide till datadriven verksamhetsstyrning

EBITS Energibranschens Informations- & IT-säkerhetsgrupp

Handbok för programvaran. GoPal Navigator Version 4

Informationsattribut för inventering - gränspunkter

Producenter: anvisning om hur checklistan för kontroll av planen för egenkontroll och hur denna omsätts i praktiken fylls i

Handbok för programvaran. GoPal Navigator Version 4

Anvisning avseende e-postkommunikation för anställda inom

CAMPINGHANDBOKEN för campinggästen

Guide för hur bildar man en kaninhoppningsklubb ansluten till SKHRF. Även innehållande kunskap om hur man håller möten

INTEGRITETSPOLICY ADJURE AB

Kommunrevisionen: granskning av generella IT-kontroller 2014

Malltext Tredjepart- /Samarbetsavtal HSA och SITHS

Internationalisering inom fyrkantens gymnasieskolor

Rutin för domänvalidering. Verifiering av organisationer och ombud

Designprocessdagbok. Grupp 3; Maria Törnkvist, Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Flink- Sundin.

Integritetspolicy för givare

Tjänstebeskrivning. Tjänsteöversikt. Omfattning för Copilot Optimize-tjänster. Co ilot Optimize CAA Omfattning

MaxSea Time Zero version 1.2

Nyheter och ändringar i Adela Grundskola 4.2.0

Låneavtal för personlig elevdator

Kravspecifikation / Uppdragsbeskrivning

ANBUDSFÖRFRÅGAN. Ni inbjuds inkomma med anbud på webb-tv lösning för sändning av kommunfullmäktige. Datum

1 (2) Landstingets revisorer Dnr REV/31/06

Kravställ IT system på rätt sätt

Att ta emot internationella gäster på Vilda

Identifiering och autentisering

Valet mellan CISC och RISC processorn

SAMLAT PLANDOKUMENT FÖR LIKABEHANDLINGS- OCH VÄRDEGRUNDSARBETE 2014

MaxSea TimeZero. Snabbguide

Investerings prospekt

INTEGRITETSPOLICY. Uppgifter som samlas in när du använder våra tjänster

Information. ALLT ni BEHÖVER VETA OM SOCKGROSSISTENS försäljning. för SKOLKLASSER. Vi lämnar alltid ett års garanti på våra produkter

Transkript:

Design av datrnätverk för skla Design f cmputer netwrk fr schl Chris Drugidenis Krister Jakbssn Carls St Examensarbete inm Kmmunikatinssystem Högskleingenjör Degree Prject in Infrmatin Technlgy Stckhlm, Sweden 2011 Kurs IK121X, 15hp TRITA-ICT-EX-2011:136

Södermalmskyrkans kristna skla Design av datrnätverk för skla Design f cmputer netwrk fr schl KTH ICT Chris Drugidenis Krister Jakbssn Carls St

Innehållsförteckning Sammanfattning... 5 Abstract... 5 Förrd... 6 1. Intrduktin... 7 1.1 Syfte... 7 1.2 Omfattning... 7 1.3 Förkrtningar ch akrnymer... 7 1.4 UML & flödesdiagram... 8 4.1.1 UML... 8 4.1.2 Flödesdiagram... 9 1.5 Översikt av resterande dkumentatin...10 1.6 Referenslista...10 2. Inledning...10 3. Rapprtarkitektur, beskrivning ch representatin...11 4. Idé, mål ch avgränsningar...12 4.2 Bakgrund...12 4.3 Idé...13 4.4 Huvudmål...13 4.5 Extrauppgifter...13 4.5.1 Lösenrdsbyten...13 4.5.2 Uppdaterings distributin...13 4.5.3 Schema...14 4.6 Avgränsningar...14 5 Kravspecifikatin...14 5.1 Grupper...17 5.1.1 Gruppindelning i Active Directry ch Live@edu...17 5.1.2 Elever...17 5.1.3 Lärare...17 5.1.4 Administratörer...17 5.2 Funktiner i systemet...17 5.2.1 Live@edu användning & SSOprtal...17 5.2.2 Nya användare i systemet...19 5.2.3 Synkrnisering...19 5.2.4 Lösenrdsbyten...20 5.3 Ickefunktinella krav...21 Sida 2 av 62

5.3.1 HTML API...21 5.3.2 PwerShell API...21 6 Arkitektur...21 6.1 Lager...23 6.2 Arkitektur gruppering...24 6.2.1 Klienter...25 6.2.2 Servrar...25 7 Implementatin...27 7.1 Grundläggande server system...27 7.1.1 Server 01...27 7.1.2 Server 02...27 7.1.3 Grundläggande nätverk...27 7.2 Bakmliggande system...28 7.2.1 DNS...28 7.2.2 Active Directry...28 7.2.3 DHCP...29 7.2.4 Webbserver IIS...29 7.2.5 Fileservices...29 7.2.6 Netwrk Plicy and Access Services...30 7.2.7 Windws Deplyment Server (WDS)...30 7.2.8 Windws Services Update Server (WSUS)...31 7.2.9 Windws PwerShell...31 7.2.10 My-SQL server...31 7.2.11 PHP...31 7.2.12 PHPMyAdmin...32 7.2.13 Grup Plicys...32 7.2.14 Windws AIK (WAIK)...32 7.3 Klient prgram...32 7.3.1 Internet Explrer 9...32 7.3.2 Lexia...32 7.3.3 GIMP...32 7.3.4 Office 2010...33 7.3.5 Adbe...33 7.3.6 Windws Mvie maker...33 7.4 Användarnamn...33 7.5 Single-sign-n (SSO) & SSOprtal...33 Sida 3 av 62

7.6 MySQL & PHPMyAdmin...34 7.7 Lösenrdsbyten...34 7.7.1 Lösenrdsbyten för alla användare...35 7.7.2 Lösenrdsbyten av lärare på elever...36 7.7.3 Skriva till fil samt uppdatera Active Directry & Windws Live...38 7.7.4 Lösenrdsvarningar...39 7.8 Synkrnisering...40 7.9 Plicys...44 7.9.1 Cmputer...45 7.9.2 Users...46 7.10 Förbättrad inlggning...49 7.11 Scriptstruktur...50 8 Frtsatt utveckling & kända prblem...51 8.1 Klienter...51 8.2 Plicys...52 8.3 SSOprtal & Live@edu...52 8.4 Flytta Exchange kntn...52 8.5 Lösenrsbyten...52 8.6 Synkrnisering...52 8.7 Windws Deplyment Service & unattended installatin...53 8.8 Schema nline...53 9 Slutsatser...53 10 Bilagr...54 10.1 Installatinsdetaljer...54 10.2 Enkla instruktiner för lösenrdsbyte...60 Sida 4 av 62

Sammanfattning I ett samhälle där alla bör förstå ch kunna använda sig av IT är sklan den plats där unga kanske för första gången får en chans att lära sig detta. Med den stundande nya grundskleplanen ska även lågstadieelever börja använda sig av datrer. Det ökar behvet av en fungerande ch bra IT miljö sm kan användas ch utnyttjas av alla. Men detta är ckså mycket resurskrävande. Ett sätt att undgå prblem sm kan uppstå, är att utnyttja sig av internet ch lika srters mlntjänster för att placera delar av IT miljön externt. Detta skapar ckså en ny srts flexibilitet sm inte gör ss lika platsberende. En sådan mlntjänst är Micrsfts Live@edu. Det är en gratistjänst för sklr sm vill utnyttja mlnet för lagring ch samtidigt kunna få tillgång till en del av Micrsft prgramvarr. Denna rapprt beskriver implementatinen av denna tjänst på en typiskt svensk grundskla. Abstract In a sciety where everyne shuld understand and knw hw t use IT the schls may be the first place where yung peple fr the first time gets a chance t learn hw t use this. With the upcming new elementary schl plan even elementary schl children have t start using cmputers. This increases the need f a well functining IT envirnment that can be used by everyne. But all this is als very resurce cnsuming. One way t avid the prblems that may ccur is t use the Internet and different type f clud services t mve parts f the IT envirnment externally. This als creates a new kind f flexibility that des nt make us as dependent n where we cnnect. Micrsfts Live@edu is a clud service that des all this. This is a free service that can be used by schls that want t take advantage f the clud fr strage but at same time get access t sme f Micrsft s sftware. This reprt describes the implementatin f this service in a typical Swedish schl. Sida 5 av 62

Förrd Denna rapprt är en del av det examensarbete vi genmförde på Kungliga Tekniska Högsklan våren 2011 sm km att kallas Design av datrnätverk för skla. Arbetet genmfördes på uppdrag av Södermalmskyrkans kristna skla ch uppgifterna vi ställdes inför blev en del av ett prjekt för att lösa sklans framtida IT behv. Vi är mycket nöjda med uppgifterna vi fick ch det resultat vi uppnådde ch känner att det hade en bra kppling till det vi lärt ss under tiden på Kungliga Tekniska Högsklan. Ett strt tack till Jimmy Spets ch Emmanuel Munz sm har representerat Södermalmskyrkans kristna skla ch sm även varit handledare under prjektet. Vi vill ckså tacka vår examinatr Anders Sjögren från Kungliga Tekniska Högsklan. Chris Drugidenis, Krister Jakbssn & Carls St Maj 2011 Kista Sida 6 av 62

1. Intrduktin Det här avsnittet behandlar prjektets syfte ch mfattning. Det innehåller även förklarningar till uttryck ch symbler sm används i den här rapprten. Vi rekmmenderar alla sm läser denna rapprt att studera detta avsnitt nggrant eftersm framförallt flödesdiagram ch UML används frekvent sm förklarande bilder till texten. 1.1 Syfte Syftet med prjektet var att implementera en fungerande lösning av Windws Live@edu tjänst hs uppdragsgivaren (Södermalmskyrkans Kristna skla) ch att förbättra inlggningstiderna för elevdatrerna på sklan. Detta kallade vi för huvudmålet. Utöver dessa två huvuduppgifter så fick ett antal extrauppgifter sm skulle undersökas ch i mån av tid även lösas. Dessa uppgifter var lösenrdsbyten, schema på live tjänsten ch uppdateringsdistributin i elevnätverket. 1.2 Omfattning Det här dkumentet mfattar de lösningar vi har tagit fram för att implementera Live@edu på sklan. Den mfattar all dkumentatin (inkluderat bilagr) sm överlämnades till uppdragsgivaren vid prjektavslutet. Det ska alltså utifrån denna rapprt vara möjligt att till str del replikera den lösning vi har tagit fram förutsatt att man har vissa förkunskaper inm Windws server ch prgrammering. Dkumentatinen mfattar alla funktiner sm är avsedda att fungera i lösningen sm levereras. Genm de krav sm ställdes från uppdragsgivaren har vi kunnat bygga upp våra lösningar ch även kunnat utgå från en mer specifik kravbild. Vidare täcker dkumentatinen upp arkitekturen kring hela lösningen i detalj. Syftet är även här att kunna replikera ch få en överblick på våra lösningar, alternativt ta brt funktinalitet, ch samtidigt se vad sm kmmer att påverkas i övriga delar av systemet. Slutligen avser dkumentatinen ckså att mfatta detaljerade förklaringar av de implementatiner vi levererar. Alla script, all kd, alla plicys ch prgramvarr finns det detaljerad dkumentatin m för att uppdragsgivaren eller annan tredje part ska kunna förstå lösningarna ch eventuella prblem sm kan rsakas på grund av deras uppbyggnad. Detta är ckså ett sätt för att kunna frtsätta utvecklingen av det system vi levererar. I bilagrna kan även specifika inställningar för de installatiner sm finns i systemen granskas. Detta eftersm systemet vi levererar är ett färdiginstallerat system där uppdragsgivaren inte har varit inblandad i installatinsmmenten. Den sm läser detta dkument bör redan ha en gd teknisk kunskap eftersm mycket av det sm nämns i rapprten används på en avancerad nivå i IT infrastrukturer. Det är alltså en sådan avancerad miljö detta system är ämnat för. 1.3 Förkrtningar ch akrnymer Mlnet: Mlnet är en benämning sm har börjat användas på senare år i IT sammanhang. När man pratar m mlnet pratar man egentligen m Internet. Men när man mer specifikt pratar m mlntjänster handlar det m att utnyttja nätet för att flytta infrastruktur sm man vanligtvis lagras lkalt. Det kan användas både för lagring eller för att utnyttja lika tjänster. Live@edu & Windws Live: Live@edu är den gratis mlntjänst sm Micrsft erbjuder till sklr för att bättre förbereda studenterna för framtidens arbetssätt inm IT. Tjänsten kmmer att beskrivas ytterligare i rapprten. Live@edu är en del av Windws Live sm ckså många gånger nämnas i texten. Mer infrmatin finns ckså hs [Micrsft]. Uppdragsgivaren: Avser vår uppdragsgivare, Södermalmskyrkans kristna skla sm representeras av Jimmy Spetz ch Emmanuel Munz. Sida 7 av 62

Hasha: Innebär att man krypterar någt (i vårat fall lösenrd) med en viss krypteringsalgritm. UML: Unified Mdeling Language är en dkumentatinsmetd sm fta används inm systemutveckling men sm även visats sig användbar för att beskriva användarfall. Med UML bygger man upp en bild ch med relatiner till bjekt, för att beskriva dessa användarfall. DN: Distinguished name används inm Active Directry för att beskriva fullständing sökväg till ett bjekt (t.ex. en användare). Detta utnyttjas då man vill hämta specifik infrmatin från Active Directry. OU: Organizatinal unit är en katalg i Active Directry. DN kan till viss del bestå av en eller flera OU. Image: Avser en kpia av en installatin. Image filer kan sedan användas sm installatinsbjekt för andra enheter. Cache: Är en samling av data, ftast riginal data, sm lagras någnstans tillfälligt för att används vid ett senare tillfälle. Cachar snabbar fta upp prcesser, då de gör det möjligt att snabbare att hämta infrmatin ur minnet. Plicy: Plicy i vårat fall avser plicys sm används i Active Directry för att skapa lika regler för användare ch datrer. Detta är ett sätt för administratören att kntrllera ch begränsa systemet. Gateway: Är en plats sm kpplar ihp två lika nätverk. Kerbers: Kerbers är ett nätverksautentiseringsprtkll sm fta används vid lika säkra kmmunikatiner vilket avskaffar behvet av ett nätverksautentiseringsprtkll per applikatin. PwerShell: Ett script språk för Windws. Används för att autmatisera lika funktiner ch uppgifter. CLI: Cmmand line interface är en beteckning på ett gränssnitt sm styrs genm skriftliga kmmandn. Prfil path: Den plats där en användares filer sparas. 802.11G: Nätverksstandard för trådlöst nätverk. SSL: Säkerhetsmekanism för att kryptera kmmunikatin. 1.4 UML & flödesdiagram Detta avsnitt avser att förklara de UML ch flödesdiagrams symbler sm används i dkumentet. Vi har valt att använda ss av UML för att beskriva kraven i rapprten eftersm det har visat sig vara ett bra verktyg för detta. För script ch prgrammerings flöden har vi dck använt Micrsfts standard för flödesdiagram (ch regler enligt [Visi]) för att beskriva detta. Allt detta görs i Visi 2010. 4.1.1 UML Actr1 Sida 8 av 62

Grupp: Bilden symbliserar en grupp användare Uses: Uses används för att visa vad ett bjekt använder för att gå till nästa systemtjänst. «inherits» Inherits: Arvspil. Visar ett arvsberende. UseCase1 UseCase: Beskriver ett användarfall eller en systemtjänst sm används. Cmpnent1 Cmpnent: Är en symbl för lika kmpnenter sm används, t.ex. ett prgram. 4.1.2 Flödesdiagram Start/End: Används för att beskriva ett steg i prcessen sm ftast behöver användarens egna inmatning. T.ex. en inlggning. Decisin: Denna symbl används när lika val görs. En fråga ställs sm behöver ett ja eller nej svar. Prcess: Symbliserar en huvudprcess av någt slag. Kan tillexempel vara att ett script startar. Sida 9 av 62

Subprcess: Symbliserar att ett delmment i en prcess måste genmföras. T.ex. kntrllera en anslutning. Data: Data sm skickas till en annan instans. Cnnectr: Används för att visa vägen flödet följer. Nästa steg i prcessen. 1.5 Översikt av resterande dkumentatin Resterade delar av rapprten följer i beskrivningen här. Först kmmer en inledande del till arbetet. Därefter följer en förklarande del av rapprtens tre huvuddelar (kravspecifikatin, arkitektur ch implementatins) för att i detalj förklara syftet, skillnaden ch tankarna kring detta. Sedan kmmer en detaljerad beskrivning av prjektuppgiften ch alla deluppgifter. Därefter följer de tre huvudavsnitten efter varandra. Efter det så kmmer ett avsnitt med våra rekmmendatiner för vad vi trr man kan behöva frtsätta utveckla i systemet ch hur en möjlig frtsatt lösning kan se ut. Denna del innehåller ckså förklaringar av de kända prblem sm vi har upptäckt under våra tester, eller de svagheter vi känner till i lösningarna men inte har hunnit åtgärda i tid för leverens. Den sista delen är bilagr där vi har inkluderat detaljer kring installatiner sm finns på systemet vilket är av str betydelse för uppdragsgivaren då denne inte deltg under installatinsmmenten. Andra dkument sm följde med leveransen återfinns ckså i detta avsnitt. 1.6 Referenslista [Visi] http://ffice.micrsft.cm/en-us/visi-help/create-a-basic-flwchart-hp001207727.aspx (2011-06-06) [Micrsft] http://www.micrsft.cm/liveatedu/free-email-accunts.aspx (2011-06-06) [Live lgin] https://eduadmin.live.cm/?lcale=sv-se (2011-06-06) [Klient] http://windws.micrsft.cm/en-us/windws7/prducts/system-requirements (2011-06- 06) [Server] http://www.micrsft.cm/windwsserver2008/en/us/system-requirements.aspx (2011-06-06) [MySQL] http://dev.mysql.cm/ (2011-06-06) 2. Inledning Uppdragsgivaren Södermalmskyrkans kristna skla är en skla för årskurs F-9 sm ligger i Hammarbyhöjden utanför Stckhlm. Datrer ska finnas tillgängliga för sklans elever ch för att underlätta undervisningen skulle ett system sm gör det lättare för elever att arbeta hemifrån kmma väll till pass. Enligt den nya skllagen skall även elever på lågstadiet lära sig arbeta med datrer ch det finns ett växande behv av en IT miljö sm kan användas av alla, hela tiden. Flera ledande IT företaget så sm till exempel Micrsft ch Ggle menar att framtidens IT miljö ligger i det så kallade mlnet. Mlnet är ett begrepp sm används då man flyttar delar av IT infrastrukturen ut på Internet till externa leverantörer. Uppdragsgivaren har sett en tjänst från Micrsft sm heter Live@edu ch sm även är en del av Windws Live. Med den här tjänsten kmmer sklan att få ett gratis system sm gör det möjligt för Sida 10 av 62

elever att spara deras filer nline på Windws skydrive, läsa ch skriva E-pst på Outlk Live samt att använda Office Webb Apps (Excel, PwerPint, Wrd ch One Nte). Uppdragsgivaren gav ss i uppdrag att finna en lösning för att implementera Micrsfts Live@edu tjänst ch integrera den i elevernas IT miljö. Eftersm detta skulle innebära en str förändring i sklans befintliga miljö skulle ett fullskaligt marbete av det befintliga systemet göras där framförallt en av de viktigaste punkterna var att lösa prblemen med inlggningstiderna på sklans klienter sm idag är acceptabelt långa. För att dkumentera detta kmmer vi använda ss av dkumentatinsmetden UML samt utnyttja Micrsfts Visi standard för flödesdiagram. UML är en metd sm brukar användas vid mjukvaruutveckling, men sm har visats kunna användas lika väl vid systembeskrivningar. Med UML kmmer vi med bilder visa lika användarfall. Vi kmmer sedan medhjälp av dessa lika användarfall illustrera de prblem vi har fått i uppdrag att lösa ch sedan beskriva i detalj hur dessa ser ut ch fungerar. Med flödesdiagram kmmer vi beskriva våra script ch prgram sm skapats i samband med lösningen. 3. Rapprtarkitektur, beskrivning ch representatin För att strukturera upp rapprten ch för att kunna göra detta till en kmplett ch samlad dkumentatin av allt arbete har vi delat upp den i tre huvuddelar. På det här sättet anser vi läsaren får en bättre ch mer användarvänlig dkumentatinen ch alltid kan se helheten istället för att behöva slå upp lika delar i separata dkument. De tre huvuddelarna förklaras under rubrikerna här nedan. Kravspecifikatin Den första huvuddelen är kravspecifikatinen. Här beskriver vi först alla krav sm ställts ch illustrerar detta på ett övergirpande sätt. Sedan förklarar ch beskriver vi med bilder ch rd hur systemet är tänkt att användas av de lika aktörerna. Syftet med detta avsnitt är alltså att på ett detaljerat sätt ge instruktiner till hur vi har tänkt att man ska använda systemet ch på så sätt ckså lista all funktinalitet sm finns inbyggd. Ett exempel på detta är att vi t.ex. beskriver hur lösenrdsbyten går till. Arkitektur Syftet med denna del är att på ett detaljerat sätt lista ch ge en helhetsbild av allt det sm finns i systemet vi levererar. Det visar ckså sambandet mellan lika kmpnenter. Det kan ckså beskrivas sm en kartläggning av systemet. Detta illustreras på ett övergripande plan ch kan t.ex. utnyttjas m man vill replikera systemet. Om någt inte fungerar sm det ska, kan man ckså utnyttja detta avsnitt för att studera relatinerna ch se möjliga fel påverkningar. Implementatin Implementatins delens syfte är att utifrån de andra två huvuddelarna ge förklaringar till hur lösningarna fungerar rent tekniskt. Det är alltså den bakmliggande tekniken på våra lösningar sm vi beskriver här. Ett exempel är t.ex. att man i kravspecifikatinen har beskrivit hur man ska genmföra ett lösenrdsbyte, men i implementatins delen kan man studera hur script sm körs på servern är uppbyggda ch hanterar detta. Beskrivningar på exakt vilka script sm används, hur vi har tänkt när vi skapat dessa ch hur hela lösningen fungerar. Genm att studera denna del är alltså tanken att man sedan ska kunna göra ändringar eller frtsätta utveckla lösningarna genm att förstå våra tankar kring deras uppbyggnad. Sida 11 av 62

Vem har skrivit vad? I tabellen nedan visas vem sm skrivit m vilket mråde i rapprten. Ntera att detta nödvändigtvis inte behöver innebära att just denna persn ensam har varit ansvarigt för detta mråde i det praktiska arbetet, eftersm de flesta delar har löst gemensamt men denna persn har skrivit m det i rapprten. Listan var ett önskemål från uppdragsgivaren ch examinatrn för kunna återkppla vem sm gjrt vad lite lättare. CD = Chris Drugidenis KJ = Krister Jakbssn CS = Carls St Del Av: Del Av: Sammanfattning CD 7.2.11 CS Förrd Alla 7.2.12 CS Avsnitt 1. CD 7.2.13 CS Avsnitt 2. CD 7.2.14 CS Avsnitt 3. CD 7.3 CS Avsnitt 4 CD 7.4 KJ Avsnitt 5 KJ 7.5 CD 5.1 CD 7.6 CD 5.2.1 CD 7.7.1-3 CD 5.2.2 KJ 7.7.4 KJ 5.2.3 KJ 7.8 KJ 5.2.4 CD 7.9 KJ 5.3 KJ 7.10 CS Avsnitt 6 CS 7.11 KJ 7.1 KJ 8.1 CS 7.2.1 CS 8.2 KJ 7.2.2 KJ 8.3 CD 7.2.3 CS 8.4 KJ 7.2.4 CS 8.5 CS 7.2.5 KJ 8.6 KJ 7.2.6 CS 8.7 CS 7.2.7 CS 8.8 CS 7.2.8 CS Avsnitt 9 Alla 7.2.9 KJ 10.1 KJ & CS 7.2.10 CS 10.2 CD 4. Idé, mål ch avgränsningar Detta avsnitt beskriver mer i detalj uppgifterna vi ställdes inför. 4.2 Bakgrund Södermalmskyrkans kristna skla sm har årskurserna F-9 gav ss i uppgift att arbeta fram en fungerande implementatin av Micrsfts Live@edu tjänst till sklan. De ville även sm en del i detta att vi skulle förbättra inlggningstiderna på elevdatrerna i sklan. Sklan har en visin att kunna flytta ut stra delar av elevverksamheten till mlnet. Sm en del i detta vill de använda sig av Micrsfts Live@edu tjänst. Det var just den här tjänsten sklan ville att vi Sida 12 av 62

skulle implementera. Vi behövde alltså inte analysera ch ge förslag på andra mlntjänster. Sklan vill ge eleverna möjlighet att kmma åt deras filer även utifrån sklans nätverk samt att lärare enklare ska kunna kmmunicera med eleverna via någn webbtjänst. Tjänsten från Micrsft skulle kunna vara lösningen på allt detta. 4.3 Idé För att implementera denna tjänst på bästa sätt skulle vi vara tvungna att marbeta det befintliga nätet för att både kartlägga den bästa men ckså mest effektiva lösningen. Detta innebar att skapa ett helt nytt Active Directry i grunden. Vi valde framförallt denna lösning framförallt för att vi skulle få en bättre kntrll på vad sm körs på elevdatrerna ch för då kunna förbättra inlggningen. Men vi valde den ckså för vi skulle använda en ny dmän. Med detta arbete skulle vi även behöva ta fram nya rutiner ch script för hur elever ch klasser ska kunna skapas i Active Directry ch Windws Live. Lösningen kmmer att kräva två stycken serverar sm båda kör perativsystemet Windws server 2008 R2. Dessa benämns i dkumentet sm server01 ch server02. 4.4 Huvudmål En fungerande webbtjänst för inlggning på Micrsft Live@edu tjänst tillgänglig för elever ch lärare. Tjänsten ska gå att ta i bruk efter prjektet. Det ska gå att ansluta sig till tjänsten både innanför ch utanför sklans nät. I bästa mån snabba upp inlggningstiderna för eleverna. Dkumentera lösningarna skriftligt på svenska samt dkumentera rutiner för överlämning till uppdragsgivaren vid prjektavslut. Detta avser denna rapprt att göra. 4.5 Extrauppgifter Utöver huvudmålet ville uppdragsgivaren att vi skulle titta på ett antal extrauppgifter. Dessa extrauppgifter var prblem sm sklan hade även innan det arbete vi genmförde, men sm de hade en förhppning att vi skulle finna lösningar på när vi genmförde prjektet. Det finns inget krav på att dessa behövde lösas. 4.5.1 Lösenrdsbyten Det fanns två scenarin av lösenrdsbyten sm behövde lösas. Syftet med båda dessa är framförallt att avlasta administratören. Det första scenarit är det då lärare ska kunna byta lösenrd för eleverna när de har glömt brt det. Uppdragsgivaren vill ha lösning (eller förslag) där man via lärarnätet ska kunna lgga in ch byta lösenrd för enskilda elever. Det andra scenarit är det då uppdragsgivaren vill få en lösning (eller förslag) på hur eleverna ska kunna byta lösenrd själva antingen på uppmaning av administratören, att lösenrdet har utgått (antal dagar satt till 40) eller för att läraren har bytt lösenrd åt dem. Då ska eleven själv kunna gå in ch välja ett lösenrd sm denne kmmer ihåg. Kravet är att lösenrdet ska ha viss kmplexitet ch att eleverna ska få byta lösenrdet med jämna mellanrum sm en del av utbildningsprcessen i smart datranvändande. 4.5.2 Uppdaterings distributin Att titta på en lösning (eller förslag) för att uppdatera elevdatrerna (sklans klienter). Uppdragsgivaren vill att vi tittar på ett sätt att autmatisera detta via en nätverkslösning. Förslagsvis används Windws Server Update Service från Server 2008 R2. Sida 13 av 62

4.5.3 Schema Att schemat för eleverna ska finns tillgängligt i Windws Live@edu. Efter att Live@edu tjänsten finns på plats skulle en bra lösning för eleverna vara m de kunde kmma åt sitt schema genm denna webbtjänst (i Outlk) istället för på en separat plats. 4.6 Avgränsningar Prjektet hade en del avgränsningar sm är värda att nämna för att du sm läser helt ska förstå den utgångspunkt vi hade. Först ch främst så hade elever ch lärare separata nät. Detta medförde att vi inte behövde ta hänsyn till säkerheten på samma sätt sm m alla befann sig på samma nätverk. Säkerheten i lösningarna var inte lika viktigt sm funktinaliteten. Eftersm alla sm ska använda systemet inte har flerårig datrvana skulle detta finnas i åtanke när vi tg fram våra lösningar. Försöka använda Windws perativsystem genmgående i lösningarna. 5 Kravspecifikatin Kravspecifikatinen avser att visa de lika kraven systemet har ch den funktinalitet sm hanteras. Vi kmmer inte fkusera på Live@edu tjänstens funktinalitet i detalj eftersm Micrsft erbjuder dkumentatin m detta själva. Vi kmmer däremt illustrera vissa användarfall sm direkt berör Live@edu tjänsten för att visa hur den fungerar i just det här systemet. Tjänsten kan delvis ändras ch kan framförallt användas på lika sätt berende på hur man valde att integrera den. Vi vill därför visa den funktinalitet vi ansåg vara nödvändig att utnyttja. Detta illustreras ckså för att ge en helhetsbild av systemet. Kraven sm ställdes illustreras i bilden nedan. Det är viktigt att ntera att lärare ch elever nästan har samma möjligheter ch tillgångar till resurserna i systemet. Sida 14 av 62

E-pst Outlk live Office 365 Dkument redigering Office 2010 Skydrive Elev Fillagring Mina dkument Använda klientdatrer med åtkmst till internet Klientdatr Byta lösenrd www.sksnline.se/ passwrd «inherits» Enkel inlggning SSOPrtal Byta lösenrd på elev www.sksnline.se/ resetpasswrd Lärare «inherits» Skapa användare adduser.ps1 Synchrnisera användarna mt live@edu Sync.ps1 Administratör Installera m datrer Uppdatera perativsystem Sida 15 av 62

Bilden nedan illustrerar en ännu mer detaljerad versin av kravfallen ch finns i syfte för uppdragsgivaren sm kan behöva utnyttja detta. E-pst Outlk live Dkument redigering Office 365 Office 2010 Live@edu Skydrive Windws file services Elev Fillagring Mina dkument DHCP Använda klientdatrer med åtkmst till internet Klientdatr Gateway DNS «inherits» Byta lösenrd Enkel inlggning www.sksnline.se/ passwrd SSOPrtal Webserver Server1 Active Directry Server2 Byta lösenrd på elev www.sksnline.se/ resetpasswrd Lärare «inherits» Skapa användare Synchrnisera användarna mt live@edu adduser.ps1 Sync.ps1 PwerShell Administratör Installera m datrer WAIK WDS Uppdatera perativsystem WSUS Sida 16 av 62

5.1 Grupper Slutanvändarna mfattar tre lika grupper (aktörer). Dessa beskrivs nedan (avsnitt 5.1.2-5.1.4) för att ge förståelse för vilka delar sm kan användas av vilken/vilka grupper ch vilka avgränsningar sm har gjrts. Det finns dck en signifikant annan betydelse av grupper sm handlar m indelningarna i Active Directry ch Windws live sm beskrivs i 5.1.1. 5.1.1 Gruppindelning i Active Directry ch Live@edu Grupper ändvänds i dubbel bemärkelse i systemet. Den ena typen är aktörerna (avsnitt 5.1.2-5.1.4), den andra är den avgränsning sm görs mellan lika användare i Active Directry medhjälp av grupper. För att skilja användare åt (förutm med användarnamn) använder vi lika grupper. Grupperna kan bestå av klass, specialklass, lärare, administratör eller årskurs. Ytterligare grupper kan sedan skapas utefter sklans egna behv. Dessa grupper kmmer senare ckså synkrniseras med Live@edu för att få ett enhetligt system. De kan senare även användas sm mailgrupper. 5.1.2 Elever Gruppen Elever avser alla sklans elever ch rör årskurs F-9. Det finns ingen skillnad på elever sm skapas i Active Directry. Skillnaden görs enbart i vilka grupper de tillhör. Elever med särskilda behv separeras alltså genm grupptillhörighet. 5.1.3 Lärare Gruppen Larare avser sklans lärare ch kmmer i Active Directry få namnet larare eftersm vi vill undvika svenska tecken i de lösningar vi tagit fram. Lärare ch elever sitter på separata LAN ch lika dmäner, men vi måste ändå ha med lärarna i den här dmänen eftersm enbart denna är knuten till Live@edu. 5.1.4 Administratörer Gruppen Administratrs avser sklans administratörer. Det har skapats tre kntn sm har fullständigt behörighet. Sedan finns ett antal kntn sm har specifika uppgifter att genmföra, så sm lösenrdsbyten ch annat. Dessa kntn finns endast med i en specifik biliga sm överlämnas till uppdragsgivaren vid slutet av prjektet ch inte i denna rapprt av pga. säkerhetsskäl då den även innehåller lösenrd. 5.2 Funktiner i systemet Alla de funktiner sm systemet hanterar kmmer beskrivas nedan. Vi kmmer alltså illustrera hur vi har tänkt att systemet ska användas av de lika aktörerna. 5.2.1 Live@edu användning & SSOprtal Live@edu är den stra delen i systemet sm levereras. Vi har även valt att lägga till Micrsft Single- Sign- On lösning på live tjänsten för att förenkla inlggningen ch den kan studeras mer i avsnitt 7.3. Systemet är avsett att fungera i Internet Explrer 9. Scenari 1 Användare på sklans klienter Användaren lggar in på sklans klienter ch har där tillgång till Internet Explrer 9. Alla startsidr på klienterna ska vara satta till http://www.sksnline.se. Användaren blir där direkt skickade till SSOprtal ch får upp ett inlggningsfönster. Användaren lggar in med sitt användarnamn (utan @sksnline.se) ch lösenrd. Verifiering kmmer då ske mt Active Directry. Om inlggningen lyckades får användaren tillgång till SSOprtal sidan. Startsidan (SSOprtal) har fem lika delar numrerade i bilden nedan. I respektive del förklaras ckså funktinaliteten sm tjänsten erbjuder. Sida 17 av 62

1 Lösenrdsvarning: Denna textrad visar hur många dagar användaren har på sig att byta lösenrd. Om användaren är inm 5 dagar kmmer denna text visas annars kmmer fältet vara blankt. Om användaren inte byter lösenrd inm den angivna tidsperiden kmmer denna autmatiskt skickas till sidan för lösenrdsbyten (avsnitt 5.2.4) ch inte längre ha tillgång till Live@edu. Användaren måste då byta lösenrdet för att få tillgång till Live@edu igen. För infrmatin m hur funktinen är uppbyggd se avsnitt 7.5.4. 2 Micrsft Outlk Live: Denna ikn är en länk direkt till Micrsft webbmail (Outlk live). Webmailen är kpplad till ett specifikt användarknt men eftersm live tjänsten även synkrniserar grupper (t.ex. klasser) från Active Directry kan användaren ckså ta emt mail sm är skickade till en specifik grupp. Webmailen följer Micrsft standard gränssnitt ch har inte mdifierats utav ss. För mer detaljerad användning av Outlk Live, se Micrsft dkumentatin. 3 Micrsft Office Web Apps: Denna ikn är en länk till Micrsft Office 365, alltså Office Web Apps. Office 365 erbjuder användaren en enklare versin av Office prgrammen Excel, Wrd, PwerPint ch One Nte. Det system vi levererar avseende klienterna inkluderar inte One Nte i basinstallatinen. Detta prgram kmmer därför inte vara av användning för eleverna i sklan för tillfället. Användaren kan i Office 365 välja att skapa ett dkument, editera ch spara detta på Skydrive eller i deras hemkatalg (Mina dkument). Om dkumentet lagras på Skydrive kan detta öppnas ch editeras från Office 2010, ch när det sparas igen kmmer Skydrive versinen att uppdateras. Användaren kan ckså välja att spara från Office 2010 direkt till Skydrive. Detta görs genm att klicka Arkiv -> Spara & Skicka -> Spara till webben -> Lgga in. Här måste användaren lgga in med sitt Windws live knt. Detta är ett av få ställen där användaren måste använda sitt fullständiga (alltså även @sksnline) användarnamn till exempel abcdef00@sksnline.se. När denna är inlggad kan användaren alltså spara direkt till Skydrive. För mer detaljerad användning av Office 365, se Micrsft dkumentatin. Sida 18 av 62

4 Skydrive: Denna ikn är en länk till Windws live Skydrive. Skydrive är den mlnbaserade lagringstjänst sm Micrsft erbjuder eleverna. Användaren kan välja att spara sina filer här m de t.ex. vill kmma åt dem hemifrån. Om en lärare vill skapa en specifik uppgift för en grupp användare väljer denne att dela filen med en den specifika gruppen (t.ex. en klass). Alla användare sm är medlemmar i den gruppen kmmer då få en mapp på sin skydrive där de ska läsa filen. För mer detaljerad användning av Skydrive se Micrsft dkumentatin. 5 Lösenrdsbyte: Denna ikn är en länk för att kmma till lösenrdsbyte för alla användare. Se avsnitt 5.2.5 för mer infrmatin m detta. Scenari 2 Användare lggar in hemifrån För tillfället gör vi ingen skillnad på m användaren lggar in hemifrån eller via sklans egna klienter just vad gäller Live@edu tjänsten. Se därför Scenari 1 även för inlggning hemifrån. Tjänsten är avsedd att användas på Internet Explrer 9 men är även testat på Firefx 4 där den fungerar felfritt. Det kan därför lämnas sm rekmmendatin till elever sm vill ansluta sig hemifrån att båda dessa webbläsare går bra att använda. 5.2.2 Nya användare i systemet För att skapa en ny användare behöver användaren endast skapas i Active Directry. Infrmatinen sm finns i Active Directry kmmer att synkrniseras med övriga system. Det enklaste sättet att skapa en enskild användare på är genm att använda sig av server manager på servern för att skapa en användare. Användare ska läggas i OU Anvandare. Vid behv av att skapa en str mängd användare sm tillexempel en hel klass med elever kan man använda sig av PwerShell scriptet adduser.ps1 sm skapades under detta prjekt. Scriptet tar emt en kmmaseparerad fil där infrmatin m elevens namn, persnnummer, klass samt årskurs skall finnas med (exakt i den rdningen). Scriptet skapar då användaren ch en grupp med samma namn sm klassen användaren går i (förutsatt en sådan grupp inte existerar) samt gör användaren medlem i denna grupp. När användare skapas med adduser.ps1 scripten skapas dem utifrån vissa kriterier. Standarden vi har skapat för användarnamn är tre bkstäver från förnamnet, tre bkstäver från efternamnet ch födelseår med två siffrr. Ett exempel på detta är t.ex. Jhn De (fiktivt namn) född 1950 skulle få användarnamnet jhde50. För mer detaljer m hur scriptet fungerar se avsnitt 7.2. 5.2.3 Synkrnisering För att kunna synkrnisera infrmatinen sm finns i Active Directry till Live@edu har vi skapat ett PwerShell script med namnet sync.ps1. Scriptet ansluter sig till Live@edu ch jämför infrmatinen sm finns där med den sm finns i Active Directry. Den uppdaterar sedan Live@edu med det sm saknas. Den infrmatin sm hanteras är vilka användare sm finns, vilka grupper sm finns ch vilka användare sm är medlem i vilka grupper. Scriptet utgår från infrmatinen i Active Directry vilket gör att en användare sm finns i Live@edu men inte i Active Directry kmmer att raderas. En användare sm dck finns i Active Directry men inte i Live@edu kmmer att skapas i Live@edu. Pågrund av att scriptet inte klarar av att hämta lösenrd så genereras ett nytt lösenrd varje gång en användare behöver skapas. Både Live@edu ch Active Directry uppdateras med detta lösenrd. Scriptet uppdaterar även SQL databasen med lämpliga tabeller. D.v.s. scriptet lägger till ch tar brt användaren även här. Sida 19 av 62

5.2.4 Lösenrdsbyten Lösenrdsbyten är en str del i systemet ch mfattar en ganska kmplex lösning. Användarfallen har dck skapats med åtanke att vara så enkla sm möjligt. Det finns två lika scenarin av lösenrdsbyten sm illustreras nedan. Scenari 1 Lösenrdsbyten för elever ch lärare I det första scenarit så har både elever ch lärare möjlighet att byta lösenrd. Det gör detta genm att gå till sidan http://www.sksnline.se/passwrd. De navigerar hit genm webbläsaren direkt eller via iknen på SSOprtal. Detta kan alltså göras även när användaren arbetar hemifrån. De börjar med att lgga in på sidan med deras nuvarande användarnamn ch lösenrd för att verifiera sig själva. Sedan får de välja ett nytt löserd utifrån specifika kriterier. För att ändra dessa kriterier se avsnitt 7.5.1. Kriterierna för lösenrdsbyte är för närvarande satte till: Minst 6 tecken Minst 1 str bkstav Minst 1 siffra Minst 1 liten bkstav Får inte ha använts tidigare (kntrllerar 20 senaste) Får inte innehålla användarnamnet Får endast innehålla bkstäverna A-Z samt siffrr. Alla dessa kriterier måste uppfyllas för att lösenrdsbytet ska lyckas. Lösenrdet måste även repeteras för att bekräfta att det man skrev var rätt. Sedan klickar användaren på iknen Byt lösenrd för att server scripten ska ta över. Vid ett lösenrdsbyte tar det ca 1 minut för lösenrdet att uppdateras. Det kmmer då uppdateras både i Active Directry ch i Windws live. För detaljerade förklaringar av hur lösenrdbytet går till av systemet se avsnitt 7.5.1 i rapprten. Scenari 2 Lärare byter lösenrd för elever: Det andra scenarit rör när eleverna har glömt deras lösenrd ch en lärare kan skapa en nytt åt dem. Eleven måste dck kunna sitta användarnamn. Läraren navigerar till sidan http://www.sksnline.se/resetpasswrd i en webbläsare. När denne lggar in verifieras först att läraren faktiskt är en lärare innan denne skickas vidare till en sök sida. Här söker läraren på elevernas användarnamn utan @sksnline.se. När läraren klickar på sök knappen skickas denne till nästa sida. Det viktiga är att den sökta användaren stavas rätt ch för att systemet ska kunna ge en träff, eftersm det inte finns någn srts matchning på sökningen. Här finns det flera scenarin sm kan inträffa berende på sökningen. Om läraren sökt på en elev sm inte finns, eller har lämnat fältet blankt kmmer texten Användaren finns inte, gå tillbaka ch sök igen returneras. Man kan då antingen välja att klicka på knappen Tillbaka till söksidan för att gå tillbaka eller knappen lgga ut för att gå ur alla sidr. Om läraren har sökt på en användare sm ckså är lärare eller administratör kmmer texten Du har inte behörighet att ändra den här användarens lösenrd returneras. Det var ett krav från uppdragsgivaren att lärare inte ska kunna byta lösenrd på varandra. Lösningen på detta blir istället att administratören får göra det. Sida 20 av 62

Om läraren har sökt på en elev sm finns i Active Directry kmmer texten Du byter lösenrd på Förnamn, Efternamn (användarnamn) returneras. Läraren ska då först kntrllera att det är rätt persn sm denne har sökt fram. Om detta stämmer ska knappen Generera nytt lösenrd användas. Detta genererar ett lösenrd sm ges till eleven. Det kmmer då gälla tills eleven själv väljer att byta det på samma sätt sm i scenari 1. Om användaren sm söktes fram var fel kan läraren återigen använda sig av knappen Tillbaka till söksidan för att gå tillbaka eller knappen lgga ut för att gå ur alla sidr. Vid ett lösenrdsbyte tar det ca 1 minut för lösenrdet att uppdateras. Det kmmer då uppdateras både i Active Directry ch i Windws live. För detaljerade förklaringar av hur lösenrdbytet går till av systemet se avsnitt 7.5.2. 5.3 Ickefunktinella krav Live@edu har ett flertal lika gränssnitt för knfigurering, under denna rubrik kmmer de gränssnitt sm vi har använt ss av förklaras. 5.3.1 HTML API Service Management Prtal för Live@edu finns tillgänglig på [Live lgin] för att lgga in behöver man ett administratörsknt. I denna prtal är det möjligt att bl.a. manuellt skapa användare ch grupper, lägga till ch ta brt användare från grupper samt skapa ch knfigurera filter för email. 5.3.2 PwerShell API Det är möjligt att via PwerShell ansluta till Live@edu för att utföra lika uppgifter sm exempelvis att skapa kntn ch grupper m.m. Anslutningen görs till en av Micrsfts Exchange servrar. Nästan alla kmmandn sm finns i Micrsfts API för Exchange är möjliga att använda. Eftersm detta API använder sig av ett CLI är det enkelt att skapa script ch autmatisera arbetet med Live@edu. 6 Arkitektur Med hjälp av arkitekturen kan man se relatinen mellan lika prgram i systemet. Alla kmpnenter sm tas upp i denna del är grundläggande för funktinaliteten av hela systemet. Tredjepartsprgram sm sklans anser vara viktiga kan installeras i efterhand ch kmmer inte att tas upp i arkitekturen. Systemet består av två servrar (server01 ch server02) ch flera klienter. Servrar ch klienter har lika mjukvarr installerade, både Micrsfts egna men även från tredjepart. Till detta hör även att servrarna har lika serverrller installerade, för att leverera den funktinaliteten sm behövs i systemet. Hårdvaran kmmer inte att beskrivas, det enda kravet sm ställdes var att servrar ch klienter uppfyller kraven från Micrsft. För klienterna gäller [klient] ch servrar gäller [Server]. Sida 21 av 62

Grup Plicies Netwrk Plicy and Access Server File Services DNS Task Scheduler Sklan-Server01 Webbserver Active Directry DHCP MySQL PHPMyAdmin IExplrer Pwershell Lexia PHP Active Directry DHCP Webbserver Sklan-Server02 WDS WSUS WAIK Sida 22 av 62

IExplrer Grup Plicies DHCP Windws Mvie Maker WSUS Klient GIMP Office 2010 Adbe Klienter är datrerna sm är anslutna internt i dmänen. 6.1 Lager Arkitekturen visar både i vilket lager en prgramvara eller serverrll ingår ch lagrets berende i förhållande till systemets funktinalitet. Vi illustrerar hur varje lager är uppbyggt ch hur alla prgram ch rller är uppdelade i bilden nedan. Sida 23 av 62

Klient Server Externa Prgram Adbe GIMP PHP PHPMyAdmin MySQL Lexia Windws Prgram Office 2010 Internet Explrer 9 Internet Explrer 9 Windws AIK Windws Mvie Maker Pwershell Plicy Grup Plicies Grup Plicies DNS IIS WSUS Rller Netwrk Plicy and Access Services WDS DHCP File Services Active Directry Server01 är den server sm har de flesta rller (framförallt kritiska sm Active Directry) ch möjliggör för användarna sm är anslutna via klienterna att ha internetaccess ch tillgång till nätverket. Server02 är en server sm bara är tillgängligt internt inm dmänen. Serverns funktinalitet är att underlätta administratrns uppgifter genm Windws Server Update Service (WSUS) ch Windws Deplyment Server (WDS). Externa Prgram Windws Prgram Plicyn är alla regler sm knfigurerats för klienterna sm appliceras vid inlggning. Paketdiagrammet till höger grupperar alla liknande kmpnenter ch visar berendet mellan paket. Plicy 6.2 Arkitektur gruppering I detta avsnitt visas varje prgramvara sm finns installerad på klienter ch server samt de tillägg sm har gjrts för att prgrammet ska fungera i enlighet med kraven. Rller Sida 24 av 62

Servrarna har flera serverrller sm installerats ch knfigurerats för att anpassas till andra installerade prgram ch knfiguratiner i servrarna. Serverrllerna visas endast med de tillägg sm har gjrts vid installatinen, inte standardknfiguratin sm inte ändrades. 6.2.1 Klienter En lista på de prgrammen sm installerade på klienterna. GIMP Office 2010 Micrsft Wrd Micrsft Excel Micrsft PwerPint Adbe Adbe Reader Adbe Flash Player Windws Mvie Maker Internet Explrer 9 6.2.2 Servrar Prgram ch rller sm finns installerade på Server01 AD Dmain Services DHCP DNS Glbal Catalg File Services File Server Distributed File System DFS Namespaces DFS Replicatin Netwrk Plicy and Access services Ruting and Remte Access Web Server(IIS) Cmmn http Features Static Cntent Default Dcument Directry Brwsing HTTP Errrs HTTP Redirectin WebDAV Publishing Applicatin Develpment ASP.NET.NET Extensibility ASP CGI ISAPI Extensins ISAPI Filters Server Side Includes Health and Diagnstics Sida 25 av 62

HTTP Lgging Request Mnitr Security Basic Authenticatin Windws Authenticatin Digest Authenticatin Client Certificate Mapping Authenticatin IIS Client Certificate Mapping Authenticatin URL Authrizatin Request Filtering IP and Dmain Restrictins Perfrmance Static Cntent Cmpressin Management Tls IIS Management Cnsle IIS Management Script and Tls Management Service IIS 6 Management Cmpatibility IIS 6 Metabase Cmpatibility IIS 6 WMI Cmpatibility IIS 6 Scripting Tls IIS 6 Management Tls Management Tls Management Service Mangement Cnsle IExplrer 9 Pwershell 2.0 MySQL Server Lexia PHP LDAP MyPHPadmin Grup Plicies Alla plicies finns listade under avsnitt 7.7. Prgram ch rller sm finns installerade på Server02. Active Directry Dmain Services Windws Deplyment Server Deplyment Server Transprt Server WSUS Update prducts Office 2010 Silverlight Micrsft Security essentials Windws Windws 7 Windws Defender Sida 26 av 62

Update Classificatin Critical Updates Definitin Updates Security Updates Service Packs Web Server(IIS) Cmmn http Features Static Cntent Default Dcument Directry Brwsing HTTP Errrs Management Tls Management Service Mangement Cnsle WAIK 7 Implementatin Denna del avser att förklara varför systemet är uppbyggt sm det är, vilka script vi har skapat, när de används ch hur vi tänkt kring skapandet av dem. 7.1 Grundläggande server system I detta prjekt har vi använt ss av två stycken virtuella servrar sm båda använder sig av perativsystemet Windws server 2008 R2. Anledningen till varför vi valt ett Micrsft perativsystem istället för ett annat perativsystem sm t.ex. Linux är pågrund av fördelarna med att kunna ansluta till Live@edu med PwerShell samt att vi ville använda ss av Active Directry. Det var ckså ett önskemål från uppdragsgivaren att i största mån använda Micrsft Operativsystem i hela systemet. Den främsta anledningen till varför vi har valt att använda virtuella servrar är för att det passade bäst in i kyrkans befintliga nätverk samt att det inte krävde extra hårdvara. 7.1.1 Server 01 Första servern används till Active Directry, DHCP, DNS, webbserver (IIS), filserver samt att den agerar gateway för klienterna. Active Directry hanterar dmänen sksnline.se. Klienterna ansluter sig till denna dmän ch får då IP- adress ch DNS infrmatin. DNS servern agerar även ut mt internet så att http://www.sksnline.se även kan nås utifrån. Internet infrmatin service 7 används sm webbserver till SSOprtal samt för sidrna för att byta lösenrd. Anledningen till varför en filserver används är för att lagra användarkntn för användarna. 7.1.2 Server 02 Den andra servern använder precis sm första servern Active Directry ch eftersm att de ingår i samma dmän så synkrniseras infrmatinen sm sparas i Active Directry mellan dessa två servrar. Denna server använder sig dessutm av Windws Deplyment Service (WDS) ch Windws Server Update Service (WSUS). WDS används för att installera m klienterna vid behv ch WSUS används för att uppdatera klienterna när Micrsft släpper uppdateringar. 7.1.3 Grundläggande nätverk Nätverket i sklan är uppdelat i två lika nät, elevnätet ch lärarnätet. Det nätverk sm vi arbetade med var enbart elevnätet. Det nätverket består av både kabelanslutna ch trådlöst anslutna datrer. Både server01 ch server02 är kpplade till elevnätet, men server01 är dessutm kpplat till internet Sida 27 av 62

av den anledningen att vi använder den sm gateway. Det trådlösa nätverket använder sig av standarden 802.11g ch saknar autentisering. Bilden nedanför visar hur elevnätet ser ut. Observera att bilden visar en lgisk vy ch att de två servrarna egentligen är virutaliserade i samma datr. Klient Server02 Server01 Internet Elevnät Klient Klient 7.2 Bakmliggande system Det finns en hel del lika system sm är kritiska för att användarfallen ska fungera krrekt. Vi har listat de här nedan ch förklarat vad de gör ch används till. 7.2.1 DNS Gör det möjligt att översätta IP adresser till dmännamn. Sklans dmän har en egen DNS server sm vi har knfigurerat sm kan översätta ch bearbeta anrp mt webbsidr på dmänen http://www.sksnline.se. Andra sidr sm servern inte har infrmatin m vidarebefrdras till en högre DNS server, sm i sin tur kan göra samma peratin tills man skickas till rätt server sm tillhandahåller sidan ch skickar svaret tillbaka klienten sm frågade. DNS är ckså ett krav för att Active Directry ska fungera. Vi har knfigurerat vår DNS på så sätt att Active Directry fungerar i dmänen sksnline.se. Vi har även skapat adressen http://www.sksnline.se sm skall användas för att kmma åt SSOprtal sidan. Eftersm det skall vara möjligt att kmma åt denna sida även utifrån internet har vi valt att vidarebefrdra all DNS infrmatin till två av företaget Gdaddys DNS servrar. Anledningen till detta är för att dmännamnet sksnline.se är registrerat hs Gdaddy. 7.2.2 Active Directry Är en katalgtjänst, liknande LDAP (Lightweight Directry Access Prtcl), sm innehåller infrmatin m användare, datrer mm i dmänen. Vi har valt att skapa ett helt nytt Active Directry sm baseras på dmänen sksnline.se. Detta Active Directry är tänkt att ha alla användare under OU Anvandare. Detta inkluderar även lärare ch administratörer. Sedan kmmer vi använda ss av grupper (se avsnitt 5.1.1) för att dela in eleverna i klasser ch årskurser. Dessa kmmer att ligga i OU grupper. För att sklans klienter ska få alla grupp plicys sm vi har knfigurerat måste klienterna ligga i ett OU sm heter Klienter. Sida 28 av 62

Sksnline.se Grupper Klienter Anvandare Grupp Datr Användare 7.2.3 DHCP Dynamic Hst Cnfiguratin Prtcl är ett prtkll sm tilldelar IP adresser till servrar ch klienter sm är med i dmänen. Det möjliggör för klienter att göra anrp mt DNSen ch ha tillgång till Internet. Vår DHCP är knfigurerad för att dela ut IP adresser mellan 192.168.251.3-254 med en nätmask på 255.255.255.0. Vi har även knfigurerat DHCP att tala m för klienterna att gateway ut mt internet finns på 192.168.251.1 samt att det finns DNS på samma adress. 7.2.4 Webbserver IIS Micrsft Internet Infrmatin Server är Micrsfts egen webbserver. Genm denna server kan användarna både innanför ch utanför dmänen kmma åt sidr sm skapats ch lagts upp på IIS. Ytterligare knfiguratiner sm access, befgenhet ch extra funktinalitet på sidr kan knfigureras här. IIS är en mycket viktigt del i det här systemet eftersm den både hanterar Live@edu inlggningen ch lösenrdsbyten. Alla sidr sm man vill styra från IIS har vi valt att lägga i C:\inetpub\wwwrt. Här finns sedan underkatalger med de lika sidr vi har skapat för systemet sm t.ex. \SSOprtal ch \resetpasswrd. IIS är knfigurerad för att även använda sig av PHP för att framförallt hantera lösenrdsbyten. Men detta kan självklart utnyttjas m man vill frtsätta utveckla andra sidr med PHP. Vi har aktiverat SSL så att all kmmunikatin sker krypterat. 7.2.5 Fileservices Rllens uppgift är att skapa en fillagringsplats i nätverket. I detta system har vi använt ss av en sådan fillagringsplats för att spara prfilinfrmatin för användarnas användarkntn. När en användare lggar in på en datr hämtas de filer sm behövs ch när användaren lggar ut sparas filerna på servern igen. Även användarnas Mina dkument katalger sparas i denna fillagringsplats, men endast de filer sm användaren öppnar från mina dkument laddas ner till datrn. Att spara all data på en ch samma plats i nätverket kan ha många fördelar framförallt blir det enkelt att göra backup. Vi har valt att även spara användarnas bakgrundsbild samt skärmsläckare på denna plats vilket gör att en administratör kan ändra bakgrundsbild eller skärmsläckare för alla användare endast genm att ersätta den gamla bilden med en ny. Det finns tre katalger i fillagringsplatsen sm vi har skapat Bakgrund, Redirect ch Redirect everyne. Katalgen med namnet bakgrund används för att spara bakgrundsbild samt skärmsläckare till användarna. Administratörer har läs ch skriv rättigheter till denna katalg medans vanliga användare endast har läs rättigheter till denna katalg. Sida 29 av 62

I katalgen redirect skapas det en ny katalg för varje användare sm skapas ch lggar in. Den skapade katalgen får samma namn sm användaren ch i denna katalg sparas användarens mina dkument samt prfil filer. Endast användaren själv har rättigheter till dessa filer. I katalgen redirect everyne finns det en katalg sm heter desktp. Hit är användarnas skrivbrd vidarebefrdrade för att förhindra användarna från att spara filer på skrivbrdet. De har endast läs rättigheter till denna katalg medans administratörer har fulla rättigheter. \\sksnline.se\ prfiles\ Bakgrund Bakgrund.jpg Screensave.scr Appdata Redirect <namn på användare> Dcuments Raming prfile.v2 Redirect everyne Desktp 7.2.6 Netwrk Plicy and Access Services Servern har två nätverkskrt, det ena för extern trafik ch det andra för intern trafik. För att klienter ska ha internetaccess måste servern agera sm Netwrk Address Translatr (NAT) ruter sm översätter interna adresser till externa. På så sätt kan trafiken åka ut externt, ch när servern sedan tar får svar, översätta den till intern trafik ch vidarebefrdra till det interna nätet. Anledningarna till varför vi använder ss av detta är pga. att vi inte har tillräckligt många externa IP adresser till klienterna samt att det även ger ett svagt skydd mt virus ch ht från internet. 7.2.7 Windws Deplyment Server (WDS) Windws Deplyment Server möjliggör installatin av Windws perativsystem via nätverket. Det är ett anpassningsbart sätt att installera Windws på dmänens klienter eftersm administratören på egen hand kan knfigurera ch välja inställningar sm den slutgiltiga installatinsfilen ska ha. Installatinen kan även göras helt bevakad. WDS var inget sm vi hade sm krav att implementera i systemet från början men någt vi ändå har försökt inkludera för att göra det mer kmplett. Vi har dck valt att i den slutgiltiga leveransen inte inkludera någn image fil på en fungerande installatin, eftersm sklan hade färdiga imager för detta sedan tidigare. WDS rllen är dck installerad på server02 ch kan börja användas direkt. Sida 30 av 62