Windows Administration II. Solvikinredningar Report DA342G

Transkript

1 Windows Administration II Solvikinredningar Report DA342G Mikael Borg Niklas Alamäki Huhta Nicklas Mikkelinen Philip Lagerstrand Rasmus Joelsson Robin Sörensen Wilhelm Käll Spring term 2014

2 Contents 1 Introduction 3 2 Nätverk Topologi Site to Site VPN Remote access VPN Active Directory OU Struktur Säkerhetsgrupper Lösenordspolicies Filservrar Hemmamappar Delade Mappar Disk Quota Replikering VPN Backup Backup av Active Directory Backup av användarnas filer Backup av Exchange-servrar Off-Site Backup Tankar kring backuplösning Andra möjliga lösningar Underhåll Säkerhet Diskussion av programvara som använts Utrullning Klientdatorer - Referensdator Speglandet av en avbild Svarsfiler Utrullningsserver Centraliserade uppdateringar Epostlösning Exchange Server Säkerhetsaspekter Redundans Säkerhetskopiering Import av epost Problematik inom epost migrering

3 1 Introduction Denna rapport är uppdelad i rubriker, rubrikerna beskriver i sig vilken arbetsuppgift de olika gruppmedlemmarna har haft för sig. Författaren är beskriven under varje rubrik, om ingen författare angetts är det samma författare som i förra rubriken. Då rapporten förklarar varför vilka val som har valts krävs det grundläggande kunskap inom Datakommunikation, Server Administration och Windows Server för att förstå innehållet. 2 Nätverk Författare: Wilhelm Käll Figur 1. Nätverkstopologi Målsättningen med nätverket som skapades på de två olika siterna var att på ett effektivt sätt möjliggöra kommunikation mellan de olika enheterna på de två kontoren. Då tillgången till hårdvara var begränsad resulterade detta i att systemet som togs fram var tvunget att vara enkelt men ändå tillhandahålla den funktionalitet och stabilitet som krävs för att driften av system samt nätverk skulle vara effektivt. En målsättning för systemet var att alla de olika systemen skall kunna kommunicera med varandra oavsett vilken av de två siterna de befinner sig på. De olika systemen och användare skall i slutändan uppleva det som om de skulle befinna sig på ett och samma lokala nätverk, även om användaren skulle ansluta via VPN(Virtual Private Network) från Internet. 2.1 Topologi De två kontoren har varsinn router och switch som utgör fundamentet i nätverkstopologin. Samtliga enheter på de två siterna kommer att vara kopplade till samma switch på respektive 3

4 kontor. Då tillgångarna är begränsade används en router on a stick konfiguration. Subnätet /29 och /29 är publika, /24 och /24 privata. Servrar som är I behov av en publik adress kommer att bli tilldelade en av de publika adresserna. Övriga system kommer att få en privat IP-adress tilldelade sig via DHCP. På varje site finns det två nätverk, ett privat och ett publikt vars enheter går att nå från Internet. Enheter som befinner sig på ett av de två nätverken kommer även att tillhöra ett VLAN som används för att segmentera de två nätverken och dess tillhörande enheter. Troligen skulle ytterligare VLAN öka säkerheten, dock skulle ökade komplexiteten göra att det inte är en legitim säkerhetskontroll att implementera. Topologin som implementerades är som sagt väldigt enkel men uppfyller fortfarande de krav som ställs på infrastrukturen, dock finns det ett antal brister i desginen som skulle ha kunnat elimineras ifall mer hårdvara fanns att tillgå. I topologin saknas uppdelade core och distribution lager, hade dessa två lager existerat hade det funnits redundans som helt saknas i den nuvarande topologin. I en sådan design hade till exempel en router kunnat gå ner utan att en hel site saknar tillgång till Internet. Fördelen med den relativt enkla designen är att underhållet kräver mindre än vad det skulle göra om en mer komplex design hade implementerats. Ursprungligen var tanken att två brandväggar skulle filtrera trafiken som går in och ut till de två siterna. Brandväggarna implementerades dock aldrig. Av den anledningen har säkerheten blivit lidande när det kommer till filtrering vid ingångspunkterna på siterna. En lösning där trafik kan filtreras när den passerar routern hade kunnat vara fördelaktig. Ytterligare ett lager av filtrering av trafiken skulle sedan kunna skötas på lokal nivå genom mjukvarubrandväggar på klienter och servrar. 2.2 Site to Site VPN Alla enheter skall kunna kommunicera med varandra oavsett vilken site och nätverk de befinner sig på. Servrar på de olika siterna har ett behov av att kunna synkronisera diverse tjänster med varandra, till exempel Active Directory. Totalt finns det fyra olika nätverk som är i behov av att kunna kommunicera med varandra. Genom att implementera IPSec kan tunnlar mellan de två siterna etableras. Trafik som initieras från ett av de två nätverken på någon av siterna kommer att färdas via dessa tunnlar ifall slutdestinationen är något av de två nätverken på den andra siten. Trafiken som färdas via någon av tunnlarna kommer även att vara krypterad tack vare IPSec. Detta är fördelaktigt då känslig data kan komma att skickas mellan de olika systemen. Tunnlarna som etableras mellan de olika siterna kommer att färdas via Internet även om kommunikationen till synes kan verka lokal. En alternativ lösning skulle vara att skicka all trafik via en GREtunnel. Detta skulle vara enklare och möjligen flexiblare än att använda IPSec. Trafiken skulle dock vara enklare att avlyssna än i det skicket som det är nu. 2.3 Remote access VPN Två FreeBSD-servrar ansvarar för att tillhandahålla tillgång till de två nätverken via VPN. Enheter som ansluter till någon av de två servrarna kommer att ges tillgång till båda siterna. Då enheter på alla siter kan kommunicera med varandra via de befintliga tunnlarna kan anslutande klienter ges tillgång via FreeBSD-servrarna. De två servrarna agerar routrar för anslutande 4

5 klienter. Klienterna är konfigurerade för att kunna ansluta till någon av de två servrarna och sedan komma åt båda siterna. Klienter som tillhör Dalvik-siten ansluter lämpligvis till VPN-servern som befinner sig på den siten och vise versa. Om en klient använder sig av VPN-servern på Solvik-siten för att komma åt resurser på Dalvik-siten kommer detta innebära att trafiken måste färdas via IPSec-tunneln vilket resulterar i högre svarstider. Mjukvaran som används för att tillhandahålla Remote Access VPN-tjänsten är OpenVPN. Båda servrarna ansvarar för att upprätthålla driften av mjukvaran. När en klient ansluter till servern kommer OpenVPN att dela ut rutter till de olika nätverken till den anslutande klienten. När klienten vill nå enheter på något av nätverken kommer trafiken att först skickas till servern som sedan vidarebefodrar trafiken. OpenVPN kommer även att tilldela DNS-information för att namnuppslagningar skall fungera som de gör på det lokala nätverket. När en klient-dator har anslutit till någon av servrarna kan datorn ansluta till domänen. Den inloggade användaren kan sen ta del av de resurer som finns på nätverket som om användaren hade använt sin arbetsdator på kontoret. Problemet med den befintliga lösningen är att användaren själv måste välja vilken av siterna användaren skall ansluta till. Om möjligt hade en aningen mer elegant lösning varit ifall samtliga klienter hade anslutit till en och samma VPN-gateway som sedan dirigerar användaren till rätt site. Detta hade dock introducerat ett problem. Om servern som ansvarar för dirigering av klienterna hade gått ner kommer detta innebär att klienter inte kan ansluta över huvud taget. 3 Active Directory Författare: Philip Lagerstrand Active Directory (AD) valdes över andra katalogtjänster främst för att många tillhörande system, klientdistributionen och dess klienter, filserver, backup och också skulle använda sig utav Windows lösningar, vilket gjorde att Microsoft Active Directory kändes som ett naturligt val av katalogtsystem för att integrera dessa tjänster i systemet. Samt också för att det fanns mer erfarenhet av AD inom gruppen. AD:t administreras av totalt två stycken domänkontrollanter. En i varje site, Solvik och Dalvik. Utöver AD så sköts även distribution och uppdatering av klientdatorer från domänkontrollanterna, mer om detta i avsnittet för klientdistribution. DNS körs också på domänkontrollanterna i en zon, multipla zoner behövs ej eftersom bandbredden är tillräcklig och det administrativa arbetet behövs inte heller delas upp när det bara finns två IT avdelningar i företaget. 3.1 OU Struktur OU strukturen är ganska enkel, en OU för varje site, Solvik och Dalvik. Och sedan deras respektive avdelningar under varje. Separata OU:s gjordes också för att hålla säkerhetsgrupper och exchange specifika användare och grupper. 5

6 Solvik Ekonomi Försäljning IT Dalvik Ledning Produktutveckling Försäljning IT Ledning Produktutveckling Denna struktur ger möjligheter för bra granularitet av inställningar, GPO:er kan sättas för en hel site, en enskild avdelning i en site eller avdelningen i båda siterna. Den är också mer strömlinjeformad än om uppdelningen istället hade varit t.ex. Avdelning -> Site, eftersom det då hade blivit massor med onödiga Dalvik och Solvik OU:n under varje avdelning att hålla reda på. 3.2 Säkerhetsgrupper Totalt skapades 13 säkerhetsgrupper för användarhantering på AD:t. Fyra av dessa skapades som vanliga säkerhetsgrupper, en som består av alla användare i båda Solvik och Dalvik ifall det skulle behövas. En för Solvik respektive Dalvik vardera om bara användare från en site behövs. Och en för utvalda IT användare, som t.ex. kan användas för särskilda administratörsrättigheter som kanske inte alla IT användare bör ha tillgång till. Resten av grupperna är shadowgrupper, som i princip fungerar som vanliga säkerhetsgrupper, bortsett från det faktumet att dem automatiskt uppdaterar sina gruppmedlemmar utifrån medlemmar i specifika OU:s. Vilket sparar mycket tid av manuellt arbete vid tillägg/borttagning av användare, eftersom användaren bara behövs tas bort från ett ställe i AD:t istället för att behöva gå igenom varenda säkerhetsgrupp som användaren ska vara med i/tas bort från. En shadowgrupp skapades för varje avdelning i varje site, totalt nio stycken. 3.3 Lösenordspolicies Två olika lösenordspolicies konfigurerades med hjälp av GPO:er på AD-datorerna. En för medlemmar i IT OU:t och en för resten av användarna i Solvik och Dalvik som inte är med i IT OU:t. IT användarna har en egen, mer komplex lösenordspolicy eftersom de ansvarar för och administrerar servrarna och kritiska tjänster på företaget, och bör således förväntas ha mer komplexa lösenord än den gemene användaren i företaget. 4 Filservrar Författare: Rasmus Joelsson 6

7 4.1 Hemmamappar Hemmappar för alla användare på företaget skapades under den delade mappen home. Användarnas hemmappar finns då i dess undermappar på filservern tillhörande den site användaren hör till. Övermappen skapades och delades ut för att det lättare skulle gå att ha användarnas hemmappar samlade på ett ställe och gå att komma åt dem från en annan dator. Det blir då lättare att hitta mapparna, och ger en tydlig och enhetlig struktur som ser likadan ut på båda filservrarna. Det är nödvändigt då användarnas hemmappar skapades på en av domänkontrollanterna. Rättigheterna sätts på mappen home och ärvs då till alla mappar som skapas i den mappen. Creator/owner och administratörer är de enda som har rättigheter. Det ger då en gemensam struktur och passande rättigheter för användarnas mappar som skapas i den mappen. För att uppnå enhetlighet och stabilitet sätts rättigheterna likadant på båda servrarna. Hemmapparna skapas och mappas från H: till användarens hemmapp. Det görs under profile fliken i användarnas kontoinställningar i Active Directory Users And Computers på domänkontrollanten. Det fick snabbt då användarna på respektive avdelning kunde markeras och få inställningen gjord samtligt. Genom att göra på detta sättet gick det lätt och smidigt att skapa hemmappar med inloggningsnamnen för alla användare i samma mapp på rätt server samtligt som de fick sin hemmapp mappad vid inloggning. Det skulle också gått att göra genom inställningar i GPO som är länkade till alla användare på respektive site. Detta är mer automatiserat och skulle vara ett enklare och säkrare sätt att skapa hemmappar på om en ny användare ska läggas till i systemet. På det sättet som jag använder nu för att skapa hemmappar blir det ett extra steg (som är snabbt och enkelt) i skapandeprocessen när en ny användare ska läggas till i domänen. Det andra sättet skulle kunna vara bättre då i och med att användaren endast behöver skapas och läggas till i en passande grupp som redan har en GPO aktiv på sig. Att lägga till användaren i en grupp är något som ändå behöver göras. Användaren får då sin hemmapp skapad och mappad automatiskt om inställningarna är korrekta och det fungerar för alla användare. Om man har detta konfigurerat rätt med GPO så att det redan fungerar är det nog ett bättre sätt, men jag tycker att det är mer krångligt och svårt att lyckas med att få det rätt och hitta bland alla inställningar som finns med GPO. Är det konfigurerat och fungerar är det lika bra att använda GPO. Mitt sätt blir ett kort extra steg i skapandet av ett nytt användarkonto, men det är enkelt och går snabbt. Därför tycker jag att om man har koll på hur processen går till och har stegen dokumenterade går det lika bra att använda mitt sätt, om inte GPO redan är konfigurerad för att utföra detta. 4.2 Delade Mappar De delade mapparna för avdelningarna skapades som undermappar till mappen shared. Så är det strukturerat på båda servrarna för att det lätt ska gå att hitta och identifiera de delade mapparna. De är döpa efter vilken avdelning som de tillhör för enkelhetens skull. Varje avdelning har en egen delad mapp på sin sites filserver. Mapparna skapades först på vanligt sätt i Explorer. Rättigheterna sattes och mapparna delades ut i share som finns i File And Storage Services under Server Manager. Det är nytt för 2012 års version av Windows Server, men det sättet som Microsoft rekommenderar. I början var det lite ovant, men sedan så funkde det bra. Allt som 7

8 behöver göras vid delandet av mappar finns med när man går igenom guiden där. Rättigheterna sattes på mapparna så att endast administratörer och avdelningen som mappen tillhör har tillgång till den. När guiden var klar var också allt som behövde göras för utdelandet av mapparna färdigt. Det fanns ett alternativ som hade gjort åtkomsten av datainnehållet i de delade mapparna krypterad när det skickades över nätverket. Ur säkerhets- och konfidentialitets-synpunkt så hade det varit bra att använda. Jag tänkte på stabilitet och ansåg att det hade ökat chansen för fel i systemet vid aktivering av flera funktioner. Det är inget krav på kryptering av delade filer och ingen information har uppkommit om att någon har inkräktat och äventyrat säkerheten på delade filer. Säkerheten sköts via server och nätverksåtkomst samt med filsystemsrättigheterna vilket jag tycker är tillräckligt för denna uppsättningen. Mappningen av de delade mapparna sköts så att dem kommer upp vid inloggning på en klientdator endast för avdelningen som den delade mappen hör till. Användarna kommer åt och kan gå in och ändra i sin delade mapp likadant oavsett vilken site se loggar in ifrån. Att mappningen endast kommer upp för avdelningen den hör till är bra både ur säkerhetssynpunkt och för att slippa förvirra användare då dem annars skulle gå upp flera mappar som de inte har åtkomst till. Mappningen gjordes genom att använda en GPO per site som uppdaterar mapparna och länkar till dem med network drivemaps. Första bokstaven i avdelningsnamnet används som drive letter för identifiering av drive maps, t ex E: för Ekonomi. Det ger en tydlig struktur och det blir lätt att förstå vart mappningen leder. Etikett som anger avdelningsnamnet används för extra förtydligande. Det skulle gått att använda endast en GPO för detta som täcker alla avdelningarna på båda siterna, men det blir en typ av säkerhet och redundans att ha en GPO för mappning av varje site. Ekonomi finns bara på Dalviks site och det skulle bli dumt om den fanns med även på solvik. Det blev lättare att hålla reda på vad som var kopplat var genom att dela upp det såhär. Då mapparna ändå replikeras så finns möjligheten att det hade fungerat bra att bara länka till en site och låta replikeringen göra resten. Säkerhet, stabilitet och struktur är viktigare tycker jag. Om det blev något fel med den ena siten så skulle det ha blivit det även på den andra om jag bara hade länkat till en av siterna och replikerat innehållet. Microsofts lösningar är de enda jag känner till och dem fungerar bra, därför ser jag ingen anledning att använda något annat. När det finns inbyggt i systemet är det bäst att använda det. Det enda jag kan tänka mig att ha gjort annorlunda är att skapat mapparna direkt i GPO istället för att skapat dem fysiskt först och sedan endast uppdaterat dem med GPO. Men det kändes mer naturligt och stabilt med rättigheter, delning osv. på detta sätt. 4.3 Disk Quota För att användare inte ska ha möjlighet att lagra mer data än 500 MB sattes en hard quota på home och gäller för alla existerande och senare nyskapade undermappar. Den begränsar så att det tar stopp och absolut inte går att överskrida maxgränsen för lagning på 500 MB som är satt på användarnas hemmappar. Alternativet soft quota hade inte vart lika hård och tillåtit användare att gå över maxgränsen lite. En gräns är en gräns, och det är bättre att ha tydliga riktlinjer för vad som gäller än att vara för snäll mot användarna. Det är annars lätt hänt att användare inte tar dig eller gränsen seriöst. Du ska ha respekt som en IT-tekniker. 8

9 Det fungerar och ser ut som att det är en disk som endast har 500 MB i lagringsutrymme på nätverkslagningen. För att kunna sätta disk qouta behövde en extra funktion installeras på servrarna. Konfigurationen var grymt smidig och det fungerar riktigt bra. Det fanns möjlighet att ställa in så att det rapporterades bl a via mejl när användarna höll på att fylla upp sitt diskutrymme till max på hemmappen. Det skulle vara en bra funktion på riktigt vid ett skarpt läge, men i vårt fall kändes det inte så viktigt. Att installera SMTP bara på grund av den tjänsten kändes som lite onödigt arbete, men det är en bra funktion. Ingen användare har kommit i närheten av gränsen på våra system. 500 MB är ganska mycket plats för en hemmapp, lite beroende på vad användaren ska lagra såklart. Exempelvis videofiler tar mycket utrymme. Då Microsoft tillhandahåller funktionalitet och förklaring i sina system för att utföra hanteringen av utrymmesbegränsningen för användarnas hemmappar behövs det ingen tredjepartsmjukvara för detta ändamål. Inte vet jag något annat alternativ heller Replikering Genom att installera och använda DFS Replication från Microsoft går det att ska enhetlighet mellan servrarna på ett smidigt sätt. Båda filervrarna är med i en replikeringsgrupp. Replikering är konfigurerad så att det sker på shared, där alla delade undermappar för avdelningarna är placerade. Alla ändringar på innehållet i de delade mapparna replikeras mellan siterna. Det betyder att skapas en fil och får lite ändringar i sig på fsdalvik (dalviks filserver) är filen likadan på fssolvik när replikering har skett från fsdalvik till fssolvik. Det som replikeras är rättigheter och mapparna med dess innehåll. Samma delade mappar med rättigheter och innehåll finns alltså filservrarna på båda siterna. Användarna kan från sina klientdatorer i domänen komma åt sina delade mappar på samma sätt oavsett vilken site de befinner sig på. Replikeringen är schemalagd att utföras med full nätverksanvändning måndag till söndag mellan 00:00 och 03:00 för att inte störa det dagliga arbetet. Beroende på hur mycket ändringar det har blivit i de delade mapparna kan det bli ganska kraftig bandbreddsanvändning som segar upp nätverket mycket. Därför kändes det bäst att köra replikeringen på natten då det förmodligen inte är någon som arbetar. För de delade mapparna tillhörande avdelningarna fungerar replikeringen grymt bra, och det är bara de användare som ska ha tillgång till mapparna som kommer åt dem, precis som innan replikeringen. Rättigheterna för företagets delade mappar sattes likadant på båda filservrarna för att undvika problem. Replikering är ett bra sätt att uppnå redundans på filer, som en extra säkerhet. Det är nästa lika bra som en backup, så jag tycker att det är riktigt smidigt när det fungerar. Jag provade också att sätta upp replikering på hemmapparna likadant som jag gjorde på de delade mapparna. Det kunde vara bra att ha som en extra backup, om en filserver gick ner så skulle hemmappen ändå finnas med samma innehåll på den andra servern. Även om det inte skulle vara någon network drivemap till den så hade den ändå gått att komma åt hemmappen med samma innehåll för användaren genom att skriva exempelvis den delade sökvägen \\fssolvik\home\akme. 9

10 Efter att replikering hade aktiverats för home så försvann hemmappar och länkningen till network drivemaps slutade att fungera korrekt. Därför fick jag ta bort replikeringen och hemmapparna för att på nytt skapa mapparna på samma sätt igen. Replikgeringen av hemmappar ställde till med problem av någon konstig anledning. Det var lite tråkigt, men replikering av hemmappar var inget krav. Det viktigaste var att hemmapparna gick att komma åt och mappades ordentligt vilket snart fungerade utmärkt igen för alla användare med de nya hemmapparna. 4.5 VPN För att det ska gå att komma åt filer och mappar från vilken plats som helst i världen bara man har tillräcklig internetåtkomst har Willhelm Käll satt upp VPN anslutningar, för mer information om detta se hans del om nätverksuppsättningen. Bara användarna kommer in på företagets nätverk med sina datorer så får de upp de nätverksutdelade mapparna precis som vanligt. 5 Backup Författare: Robin Sörensen Tanken bakom backuplösningen för Solvik Inredningar var att automatisera all form av backup för att underlätta arbetet för systemadministratörerna. Detta innebär att systemadministratören inte behöver göra någon backup manuellt när allting är konfigurerat, all backup körs dessutom med hjälp av de verktyg som finns tillgängliga i Windows Server Redundans är ett genomgående tema i den lösning grupp 4 implementerat åt Solvik Inredningar, och därför görs även backupen redundant. Backupen kommer att lagras på en dedikerad backupserver. Siten Solvik kör all sin backup till den backupserver som befinner sig inom samma site och Dalvik kör backup till Dalviks backupserver. Användarnas filer säkerhetskopieras en gång per dag, måndag till fredag, till separata mappar (måndag har en egen mapp, tisdag har en egen mapp osv.). På filservrarna är shadow copies konfigurerat för att ge användarna möjlighet att återställa sina egna filer. Backup av active directory görs dagligen. Mellan Solvik och Dalviks backupservrar körs replikering, vilket ger en off-site backup för de båda siterna, denna replikering äger rum under nattid. 5.1 Backup av Active Directory Active directory kommer säkerhetskopieras varje dag efter arbetstid. Backupen startas (för Solviks domänkontrollant) och (för Dalviks domänkontrollant) och körs till den är klar, denna backup är en full server för att Solvik Inredningar ska kunna återskapa domänkontrollanterna ifall servrarna skulle t.ex. krascha eller saboteras, denna typ av backup möjliggör även att information av användarnas konto och vad de har tillgång till (rättigheter genom säkerhetsgrupper) säkerhetskopieras. För att förhindra att objekt i domänkontrollanten tas bort oavsiktligt har även recycle bin aktiverats, vilket möjliggör återställning av oavsiktligt borttagna objekt. Eftersom backupen görs över nätverket kommer varje backup ersättas av den backup som görs senast. Denna backup körs med hjälp av Windows Server Backup och är schemalagd att köras efter arbetstid för att inte sluka bandbredd för användarna. Backupen körs till siternas respektive backupserver. 10

11 5.2 Backup av användarnas filer Användarnas filer kommer säkerhetskopieras på två olika sätt. Det första sättet avser att köra en fullständig backup av användarnas delade mappar och hemmappar. Denna backup körs varje måndag, tisdag, onsdag, torsdag och fredag till separata mappar på siternas respektive backupserver. De separata mapparna innebär att måndagens backup går till en mapp som heter måndag (exempel för Solvik \\BackupSolvik\BackupSolvik\FilserverSolvik\Monday), tisdagens backup skickas till en mapp med namnet tisdag (exempel för Dalvik \\BackupDalvik\BackupDalvik\FilserverDalvik\Tuesday) osv. Detta görs för att kunna återhämta filer som blivit skapade inom en vecka, vilket var ett krav som Solvik Inredningar hade på backuplösningen. Denna typ av backup är inte möjlig genom mjukvaran Windows Server Backup, och därför skapades 5 skript (ett för varje dag), som säkerhetskopierar användarnas filer, och dessa schemalagdes genom Windows schemaläggare. Det andra sättet som användarnas filer kommer säkerhetskopieras är genom shadow copies, detta innebär att användarna själva kan återställa filer som de oavsiktligt tagit bort från sin hem-mapp eller en delad katalog. Shadow copies körs till en separat disk (i labben är detta en partition, men det är meningen att det ska vara en separat fysisk disk), då detta är best practice när det gäller shadow copies (Microsoft Technet, 2005). Shadow copies underlättar arbetet för en systemadministratör då användarna själva kan återskapa sina filer vid oavsiktlig borttagning. I ett mindre företag (<10 anställda) med få användare kan en systemadministratör hjälpa att återställa filer, men på ett stort företag, där kanske många användare oavsiktligt tar bort filer, underlättar shadow copies. Shadow Copies körs två gånger per dag (7.00 och 12.00) under arbetstid, detta för att säkerställa att nyskapade filer finns tillgängliga att återhämta vid oavsiktlig borttagning. En guide för hur användarna återställer sina filer finns i solvikinredningar4 s Wiki, och kan därifrån skrivas ut för att delas ut till användarna. 5.3 Backup av Exchange-servrar På grund av bristande hårdvara kunde ingen full server -backup köras på Exchange-servrarna. De diskar som gruppen blev tilldelade var på 150 GB. Då övriga backups körts fanns inte utrymme för att täcka upp det diskutrymme som krävdes för en full server -backup av Exchangeservrarna (75 GB per server). Istället konfigurerades redundans av dessa servrar, vilket innebär att om en server går ner så tar den andra servern över. För att återskapa den Exchange-server som kraschat ominstalleras denna server och ansluts sedan till domänen genom de guider som finns på wikin. Tankarna kring redundans av dessa servrar täcks upp i Exchange-delen i denna rapport. 5.4 Off-Site Backup Off-site backup används om någon av siterna skulle utsättas för en katastrof (brand osv.) och då finns backup av båda siternas data på Solvik och Dalviks backupservrar. Denna lösning möjliggörs genom att använda tjänsten DFSR, vilket efter konfiguration speglar (replikerar) det innehåll som finns på Dalviks backupserver till Solviks backupserver och vice versa. Denna lösning gör det möjligt att fullständigt återhämta en av siterna från totalt haveri. 11

12 5.5 Tankar kring backuplösning Tanken med denna lösning var att kunna automatisera säkerhetskopiering för att underlätta arbetet för systemadministratören, samt att all backup är schemalagd att köras efter arbetstid för att inte sluka den bandbredd Solvik Inredningar använder sig av under arbetstid. Tanken med att enbart använda Windows egna mjukvaror var för att hålla lösningen enkel och att inte behöva köpa övriga licenser (utöver Windows Server 2012) för att få en fungerande backuplösning. Redundans finns då de båda servrarna replikerar till varandra och därför finns det ingen singlepoint-of-failure i backup-lösningen (förutsatt att inte båda siterna brinner ner samtidigt) Andra möjliga lösningar Andra backuplösningar skulle kunna vara att backup körs till en egen lokal hårddisk på de olika servrarna. Denna lösning hade inte dragit någon bandbredd, då alla säkerhetskopieringar skulle gjorts lokalt. Detta skulle dock leda till att katastrofhanteringen blev sämre, t.ex. att en av siterna brinner ner till grunden, då det inte skulle finnas någon off-site backup. Det skulle även göra det svårare att återställa en domänkontrollant om det enbart gjordes lokal backup, då en total återställning görs när t.ex. en hårddisk havererat (vilket skulle innebära att den säkerhetskopian som befann sig på hårddisken också förstörts). Den lösning som implementerats gällande domänens backup har gjorts när säkerhet kontra bandbredd vägts mot varandra. Då säkerhet vägde tyngst får bandbredden lida när alla backups körs. Säkerhet i detta avseende menas att säkerhetskopior skyddas mot katastrofer, som när en av siterna brann ner, och gör att säkerhetskopior alltid finns tillgängliga. Med denna off-site backuplösning elimineras risken för att data förstörs permanent, då data lagras på en annan geografisk plats. 5.6 Underhåll När denna lösning för backup är konfigurerad sköts allt automatiskt genom schemaläggning. Det underhåll som krävs är det initiala arbetet där alla säkerhetskopieringar schemaläggs, backupscript skrivs och schemaläggs. I Wikin finns även information om backup och återställningar. Denna information innebär steg-för-steg-guider för återställning av domänkontrollant och användares filer samt allmän information om när backup av de olika servrarna körs. 5.7 Säkerhet För att göra en backup till servrarna krävs ett administratörkonto. Detsamma gäller för tillgång till serverdatorerna som erbjuder dessa tjänster till domänen. 5.8 Diskussion av programvara som använts Den programvara som valt till backuplösningen är Windows Server 2012 och verktygen Windows Server Backup och DFSR. Windows Server Backup 2012 valdes för att alla andra servrar i domänen använder sig av detta OS, vilket underlättar vid anställning av systemadministratörer då de enbart behöver lära sig/kunna ett system. Tjänsten DFSR används för att replikera filerna mellan de båda backupservrarna för att erbjuda domänen off-site backup. Shadow copies användes för att användarna själva ska kunna återställa filer som blivit oavsiktligt borttagna, vilket underlättar arbetet för systemadministratören. 12

13 6 Utrullning Författare Niklas Alamäki Huhta Ett välförberett IT-arbetslag kan smidigt tillgodose företagets klientdatorer med operativsystem som behövs för det dagliga arbetet. Att sömlöst kunna installera ett flertal klientdatorer, med minimalt ingripande från administratör, är både tidseffektivt som det är attraktivt. Det finns många alternativ, vid utrullning av operativsystem- och programvara, och antalet tillvägagångssätt skiljer sig slutligen beroende på infrastrukturens designkrav. Målet med utrullning av operativsystem för solvikinredningar4 är att obemannat kunna installera operativsystemet Windows 7 Professional x64, med förbestämd programvara, på samtliga klientdatorer i verksamheten. I den här delen av rapporten kommer följande koncept och komponenter att förklaras, valideras och diskuteras: Klientdatorer - Referensdator och avbild Svarsfil för obemannad installation Utrullningsserver Centraliserade uppdateringar 6.1 Klientdatorer - Referensdator Författare: Niklas Alamäki Huhta Klientmaskinerna inom verksamheten är ett flertal virtuella maskiner som körs under en VMware ESXi värd-maskin på varsin site (Solvik och Dalvik). Totalt installeras tio klientmaskiner (fem för varsin site) med identisk virtuell hårdvara. Därmed är samtliga klientmaskiner aktuella för installation av referensdatorns avbild. En referensdator, i utrullningssammanhang, är den datorn som alla andra datorer kommer att installeras efter. För solvikinredningar4 är referensdatorn en virtuell maskin som har konfigureras som mall för att senare klonas och distribueras till samtliga klientdatorer inom verksamheten. Fördelen med att göra en malldator för utrullning är att kunna skräddarsy datorn för att bäst passa programanvändningen inom organisationens klienter. 6.2 Speglandet av en avbild Författare: Niklas Alamäki Huhta Efter all förbestämd konfiguration har utförts på referensdatorn måste datorn förberedas för utrullning. Med hjälp av Microsofts System Preperation Tool (sysprep) förbereds referensdatorn genom att ta bort all unik datorinformation så att installationsavbilden kan användas av andra datorer. 13

14 Efter Sysprep har körts görs en omstart på referensdatorn. Datorn startas sedan upp i WinPEmiljö - med hjälp av en WinPE CD/DVD - där själva avbilden kommer att fångas upp av programmet Imagex. Imagex kan installeras antingen som del av paketet Windows Automated Installation Toolkit (WAIK), eller som en fristående systemkomponent. Beroende på om referensdatorn, och resten av klientmaskinerna, har tillräckligt med hårddiskutrymme för WAIKpaketet kan beslut om installation dras i enlighet med detta. För solvikinredningar4 installerades hela WAIK-paketet på referensdatorn vilket i återblick kan anses vara onödigt slöseri med hårddiskutrymme då endast Imagex-komponenten behövs för att fånga en avbild av referensdatorn. När Imagex har fångat upp en avbild av referensdatorn sparas denna avbild som en.wim fil som är redo för utrullning av utrullningsservern. Utrullningsscenariot som solvikinredningar4 har arbetat inom kallas Build-to-Plan och dokumenteras av Microsoft TechNet. ( 6.3 Svarsfiler Författare: Mikael Borg Under en obemannad installation så kan svarsfiler användas för att förse installationsprocessen med svarsalternativ och input. Således krävs det ingen inverkan från en administratör när väl installationsprocessen är påbörjad. Dessa svarsfiler förekommer ofta som enkla text- eller XMLfiler. Således är det fullt möjligt att redigera dessa för hand i en texteditor, men det kan rekommenderas att använda specifika applikationer för att underlätta denna arbetsuppgift. I en Windows-miljö så kan Windows System Image Manager- WIM användas. Denna applikation representerar svarsfilen som ett tomt ark där ett flertal olika komponenter kan läggas till i ett antal olika pass. Modulerna i sig kan vara väldigt specifikt riktade på ett enskilt pass, så som exempelvis Generalize-, OOBE- eller Specialize-passet, men de kan också vara generella komponenter som går att anpassa för ett flertal pass under Windows installationen. Nedan följer viktiga utdrag ur den svarsfil som projektet använder. Den kompletta svarsfilen finns att hitta i projektets wiki under titeln Answer File. Följande komponenter finns under passet Specialize. Med hjälp av Microsoft-Windows-Shell- Setup komponenten så anpassas attributer så som datornamn och produktnyckel. Detta sker likt följande. Components 1 <component name=" M i c r o s o f t Windows S e c u r i t y SPP UX" [... ] > <ComputerName > </ ComputerName > <ProductKey >XXXX XXXX XXXX XXXX X7GG2</ ProductKey > [... ] </ component > Användandet av en asterisk inom datornamnet innebär att ett unikt datornamn kommer slumpas ut vid varje användning av svarsfilen. Produktnyckeln angivs också här för att kunna genomföra installationsprocessen utan några hinder. Dock krävs följande komponent och sträng för att förhindra att operativsystem automatiskt aktiverar nyckeln. Detta är ett viktigt krav då projektet inte har tillgång till några ytterligare nycklar till klientmaskinerna. 14

15 Components 2 <component name=" M i c r o s o f t Windows S e c u r i t y SPP UX" [... ] > < S k i p A u t o A c t i v a t i o n > t r u e </ S k i p A u t o A c t i v a t i o n > </ component > För att underlätta hanteringar av nya klientmaskiner inom domänen används följande satser. Components 3 <component name=" M i c r o s o f t Windows U n a t t e n d e d J o i n " [... ] > < I d e n t i f i c a t i o n > < C r e d e n t i a l s > <Domain> s o l v i k i n r e d n i n g a r 4. nsa. h i s. se </ Domain> <Password >S 3 </ Password > <Username > A d m i n i s t r a t o r </ Username > </ C r e d e n t i a l s > <DebugJoin > t r u e </ DebugJoin > <JoinDomain > s o l v i k i n r e d n i n g a r 4. nsa. h i s. se </ JoinDomain > </ I d e n t i f i c a t i o n > </ component > Denna uppsättning tillåter klientmaskinen att autentisera sig med de angivna användaruppgifterna mot domänen vid genomförd installation och gå med i projektets domän. Slutligen i Specialize passet konfigureras även brandväggen för att tillåta RemoteDesktop. Hela svarsfilen är uppbyggd på ett liknande sätt. I passet WindowsPE anpassas operativsystemets språk samt att Microsofts slutanvändaravtal accepteras. Språket konfigureras även i passet OOBESystem, tillsammans med lokala kontoinställningar samt tidszon. Många av de komponenter och strängar som konfigureras och anpassas är väldigt tydliga och kräver ingen extra förklaring. Således rekommenderas det för den intresserade läsaren att undersöka svarsfilen på eget initiativ på projektets wikisida. 6.4 Utrullningsserver Författare: Mikael Borg För att skapa en miljö kapabel till automatiska utrullningar av operativsystem och mjukvara krävs någon form av server som hanterar nätverksanrop och hanteringen av systemavbilder och svarsfiler. Det finns ett flertal olika sätt att skapa denna utrullningsserver. Då Solvikmiljön sedan tidigare består av Windows-maskiner sammanbundna med Active Directory så togs beslutet att dra nytta av Windows Deployment Services - WDS. Denna Microsoft tjänst representerar ett smidigt sätt att implementera utrullning i en Windows miljö. För att möjliggöra utrullning på både Solvik samt Dalvik, installeras tjänsten på båda domänkontrollanterna. Dessa förses sedan med den avbild som tidigare gjorts av referensmaskinen samt den svarsfil som diskuterats i tidigare avsnitt. Här krävs även en bootfil i form av boot.wim, som går att hitta på vilken vanlig installationsskiva för Windows 7 som helst. När sedan en maskin väljer att nätverksboota och autentisera sig mot utrullningsservern, så får den tillgång till dessa avbilder och kan från den punkten genomföra en obemannad installation. Denna uppsättning är en implementation av tjocka klienter. Detta innebär att till skillnad från tunna klienter, så installeras mjukvara på klientdatorerna och att de rustas upp till en god nivå av 15

16 funktionalitet. Således kommer en stor mängd data behöva överföras från servrarna till klientmaskinerna som önskar genomföra en obemannad installation. Detta kan självfallet vara en stor belastning för nätverket medan denna process är igång. Dock så bör det jämföras med tunna klienter. I detta fallet så skulle inga större applikationer eller mjukvara installeras på klientmaskinerna. De skulle enbart vara ett skal, som sedan kontaktar utrullningservern kontinuerligt för kunna använda applikationer och utnyttja funktionalitet. Denna implementation skulle således representera ett mindre behov av kraftfulla klientmaskiner, men skulle sätta en större press på nätverket under en vanlig arbetsdag. Om en tunn klient skulle tappa kontakt med den relevanta servern, finns också risken att funktionalitet tappas. Då all mjukvara redan finns färdiginstallerad och konfigurerad på en tjock klient, så betyder anslutningen till utrullningsservern efter utrullningen har skett väldigt lite. I Solvik miljön sker det att nätverket är väldigt ansträngd och belastat av trafik som kommer från bland annat backup-servern. Därav betraktas tjocka klienter som en passade lösning för projektet, då denna implementation sätter mindre press på nätverket i längden. Under projektets gång så uppstod det vissa problem med utrullningsservern. Efter efterforskning och felsökning insåg utrullningslaget att det kunde förekomma vissa krockar mellan WDS och andra tjänster så som DNS, om de implementerades på samma maskin. Detta berodde på en portnummer-konflikt, där de båda nämnda tjänsterna försöker använda överlappande intervaller av portnummer. Dock kan detta motverkas genom att manuellt konfigurera de båda tjänsterna att använda olika urval av portnummer. 6.5 Centraliserade uppdateringar Författare: Niklas Alamäki Huhta En komplett utrullningsmiljö behöver centraliserade uppdateringar för samtliga klientdatorer i verksamheten. För att klienter inte ska behöva dra beslut om vilka uppdateringar är relevanta för dom sköts detta via Windows Server Update Services (WSUS). WSUS är en servermjukvara som installeras på en Windows servermaskin och sköter all synkronisering, nedladdning och installation av aktuella Windows uppdateringar till klientmaskinerna inom verksamheten. WSUS har installerats på domänkontrollanterna Solvik och Dalvik och via en Group Policy Object (GPO) har klientmaskiner inom domänen konfigurerats för sömlös nedladdning och installation av Windows uppdateringar. Beslutet om att använda WSUS för Windows uppdateringar var enhälligt då inga andra lösningar passade en eftersträvad enkelhet lika väl. Då uppdateringar för programvara även hade spelat en stor roll, för helheten av utrullningsinfrastrukturen, fanns det dock inga attraktiva alternativ. Windows SCCM 2012 hade löst klient uppdateringar för diverse programvara, dock krävdes ytterligare licenser och nycklar som solvikinredningar4 inte hann efterfråga. Dålig planering förblir roten av problematiken i detta skede. 7 Epostlösning Författare: Nicklas Mikkelinen 16

17 Då de båda företagen behöver e-post men ändå kan klassas som mindre företag, valdes att använda en mailserver per site vilka ingick i en redundans. 7.1 Exchange Server Microsoft Exchange 2013 valdes som mailserver för det breda stödet och sammarbetet med de flesta tjänster i en Windows-miljö valdes över 2010 på grund av de nyimplementerade Lync stödet, så att användare även kan utnyttja tjänsten om så skulle önskas. Att välja Exchange är förutom en kostnadsfråga nästan det självklara valet när det kommer till e-post i en Windowsmiljö. Att knyta en Exchange-server mot en Active Directory databas underlättar skapandet av användare och lösenordshantering. När en ny användare skapas i Active Directory kan denne även hittas via Exchange-serverns kontrollpanel och behåller alla parametrar som till exempel telefonnummer. Det underlättar även om en användare slutar på företaget och får sitt konto inaktiverat eller borttaget. Detta speglas då direkt till mailkontot, dvs det kräver mindre administration och det finns mindre utrymme för misstag. Exchange ger automatiskt kalender, adressbok och en webmail när den installeras, ett par klick senare så är en SMTP server igång så att e-post även kan konfigureras i e-post program. Att jämnföra detta med postfix som kräver mycket mer konfiguration och inte har i närheten på samma interoperabilitiet som Exchange har tillsammans med Active Directory gör valet väldigt lätt. Inte bara blir det mindre administrativt jobb utan även i felsökningssyfte då det finns extremt mycket dokumentation och även experkonsulter inom området. Att en användare sen har samma lösenord för att "logga in på datorn" och till sin e-post, kalender och addressbok gör det lättare för en användare att komma ihåg sitt lösenord, och underlättar även för lösenordpolicies där lösenord byts. Många e-post klienter eller smartphones har också stöd för exchange i en autodiscovery funktion och smartphones länkar ofta både kalender och addressbok med telefonen automatiskt. Detta gör det lättare för användare att se sina möten, kontakta andra på företaget och när de slutar försvinner kontakterna. 7.2 Säkerhetsaspekter Då exchange är relativt säkert från första början, lås att använda SMTP servrar för endast autentiserade användare, SSL, självsignerade certifikat och liknande är det inte jättemycket som behövs funderas på i en exchangelösning. Anti-spamm är också implementerat som standard i Microsoft Exchange, det som tåls att tänka över skulle vara någon typ anti-virus skydd på datorn i sig. Då mailen lagras i en databas på själva epost servern så finns det möjligheter att det sprider sig Redundans En större del av säkerheten i är återställning av e-post och redundans, mailsystem när de väl är igång skall för en användare aldrig gå ner, dvs det skall alltid gå att skicka e-post. För att återställa e-post sattes recovery databases upp på båda siterna, detta skapar kopior av databaserna som inte går att använda. Om dessa kopior, eller arkiv skulle behövas kan en administratör extrahera specifika mail eller en hel mailbox. En annan lösning skulle vart att använda sig utav In-Place hold mailboxar. Dessa är egentligen till för att ta reda på om en användare läcker information ut ur företaget, men fungerar även för att återställa e-post via. Detta kräver dock att Enterprise varianterna av Windows Server används. 17

18 För att säkerställa en fullständig redundans användes DAG(Database Availability Groups) tillsammans med Windows egna Clustrade system, detta innebär att alla mailservrar som ingår i denna DAG delar e-post databas, så fort en av servrarna går ner används ett internt röstsystem som anger vilken server som skall ta över databasen. På detta sätt märker användarna aldrig att tjänsten går ner och ger administratören tid att arbeta med återställning eller ominstallation av säkerhetskopior Säkerhetskopiering Då hårdvara inte tillät fullständig säkerhetskopiering av e-post servrarna var detta inte möjligt. Målet var däremot att göra bare-metal säkerhetskopior, mot en extern backupserver i nätverket. 7.3 Import av epost Då filtyperna redan var i linux format, så kan det antas att en dovecot eller liknande server har använts tidigare. För att migrera filerna behövde alla konton skapas och aktiveras i exchange servern, att lägga till kontona var inga större problem då det är direkt relaterat till AD och går att bulkskapa, dock så var inte lösenorden skapade i ADt utan skulle sättas av användare vid inloggning. Ett powershell kommando löste detta. Powershell Bulk change passwords get a d u s e r f i l t e r s e a r c h b a s e "OU= Solvik,DC= s o l v i k i n r e d n i n g a r 4,DC=nsa,DC = h i s,dc= se " Set ADAccountPassword R e s e t NewPassword ( ConvertTo S e c u r e S T r i n g A s P l a i n T e x t " Syp9393 " Force ) Detta ändrade lösenordet på alla användare i hela ADt till Syp9393, det går att filtrera mer men i en labbmiljö där alla lösenord är lika var detta en lättare lösning. En dovecot installation skedde på en av DNS/VPN maskinerna som redan använde sig utav FreeBSD och sedan ett script som hämtade informationen från tar arkivet och skapade dessa användare. När detta var klart fanns en fungerande mailserver med alla de gamla användarnas e-post och konton upsatta, alla med lösenordet Syp9393. För att migrera över till Exchange databasen så användes imapsync. imapsync synkroniserade och flyttade över eposten till det respektive kontot på exchange-servern. (Notera att impasync inte klarar av lika hårda SSL krav och liknande så detta var tvunget att stängas av.) En annan lösning som kan vara lite mer omständig är att använda sig utav programvaran Aid4Mail, denna använder sig utav klientvarianten av Outlook, och gör om de gamla mapparna till PST boxar, dessa måste sen importeras via exchange för att fungera Problematik inom epost migrering Den största problematiken med att migrera e-postsystem är UTF stödet, text och bilagor kan bli korrupta/garbled samt att alla användare använder sig utav samma användarnamn. Då de flesta e-post system använder olika sätt att lagra databaser eller e-post så kan det vara problematiskt att konvertera till just det användare nyttjar. Detta är en omständig process, speciellt om den gamla e-post servern inte är igång. Det smartaste är att migrera från en fungerande e-post server till den nyaste med t.ex imapsync eller att exportera till ett format den nya epostservern klarar av. I laborationen så var det inte så många mail som behövde synkroniseras/flyttas, i ett verkligt scenario så kan det vara extremt mycket data vilket leder till att detta kan ta extremt lång tid samt bilagor hanteras inte alltid på samma sätt av alla epostsystem. Däremot så är det ju så att 18

19 e-post som inte är krytperad lagras oftast i plain-text så det går nästan alltid att återställa om man har ett arkiv med e-posten, om än tidskrävande. 19