IT-Diplom afgangsrapport

Transkript

1 IT-Diplom afgangsrapport Synkronisering og vedligehold af brugerstyring Replikering fra AD til ADAM EVA Lasse Frederiksen Kongens Lyngby 2009 IMM-B.Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax Side 2 af 72

3 1 Forord Denne rapport er resultatet af min indsats i eksamensperioden fra 1. september 2008 til 1. februar Rapporten er udført som afsluttende eksamensprojekt for studieretningen Diplom-IT på Danmarks Tekniske Universitet. Opgavens formål er at belyse den studerendes færdigheder indenfor projektarbejde, med softwareudvikling som hovedformål. Som del af softwareudviklingen indgår analyse, design, implementering og test, og der skal igennem forløbet skabes en sammenhæng imellem disse faser. Projektarbejdet og softwareudviklingen er udført i samarbejde med virksomheden DONG Energy A/S. Rapporten er underlagt DTU s standard samarbejdsaftale for Diplom- og Kandidateksamensprojekter. Lasse Frederiksen s Underskrift Side 3 af 72

4 2 Indholdsfortegnelse 1 Forord Indholdsfortegnelse Indledning EVA Introduktion til Active Directory (AD) Baggrund Struktur LDAP Eksempel på brug Introduktion til Active Directory Application Mode (ADAM) POWER Projekt Web (PPW) Process in Quality (PinQ) Arbejdsmetode Unified Process Backup Versionsstyring Tidsplan Analyse Struktur i Active Directory Struktur i Active Directory Application Mode (ADAM) Overordnet systemsammenhæng Use Cases Use Case Forbind til et directory med EVA Use Case Browse objekter Side 4 af 72

5 4.4.3 Use Case Repliker bruger Use Case - Søg Use Case Flyt brugerobjekt (ADAM) Supplerende kravspecifikation Introduktion Generel beskrivelse Specifikke krav Domæne Model PPW Indledende undersøgelser Projektmodel og arbejdsmetode Filstyring på PPW Bruger- og Adgangsstyring Design Software arkitektur GUI (Graphical User Interface) Funktionalitet Primær-funktionalitet Sekundær-funktionalitet LDAP (Lightweight Directory Access Protocol) LDAP-Opslag LDAP-Skema Sekvens diagrammer XML UML-klassediagram Beskyttelse af kodeord Side 5 af 72

6 6 Implementering GUI (Graphical User Interface) LDAP-kald Browse objekter (træstruktur og objektliste) Opsætning og sikkerhed XML Automatisk replikering Søgning Test Whitebox Test Blackbox Test Konklusion Udviklingsmuligheder Bilag Use Case Diagram (EVA) Use Case Opret nyt objekt (ADAM) Use Case Slet objekt (ADAM) Use Case Disable/Enable brugerobjekt (ADAM) Use Case Omdøb objekt (ADAM) Sekvens diagrammer Litteraturliste Brugervejledning Connect to Active Directory (AD) Connect to Active Directory Application Mode (ADAM) Viewing object-attributes Setting an OU as Import Folder Side 6 af 72

7 9.4.5 Selecting objects for replication Replication Creating new objects Moving objects Deleting objects Searching Configuring EVA PPW Ideoplæg Funktionsliste Lotus QuickPlace (I produktion) SWOT Analyse Lotus QuickPlace (I produktion) SWOT Analyse Microsoft SharePoint (I produktion) Side 7 af 72

8 3 Indledning Denne rapport, samt projektet omkring brugerstyring, er lavet i forbindelse med et større projekt hos DONG Energy A/S (fremover kun benævnt DONG Energy). Det overordnede projekt i DONG Energy omhandler udviklingen af et Projekt Web til forretningsenheden POWER, heraf navnet POWER Projekt Web. Dette projekt vil blive omtalt som PPW i denne rapport. Det ønskes, at PPW bliver et fælles system (med web-adgang), hvor medarbejdere og eksterne parter kan samarbejde om igangværende projekter, og f.eks. gøre brug af fildeling, meddelelser osv. For at sikre, at det kun er personer med et arbejdsmæssigt behov, der får adgang til PPW, skal der oprettes en central bruger- og rettighedsstyring. Det ønskes, at både interne medarbejdere og eksterne parter samles i en fælles adgangsgivende instans til PPW. Da de interne medarbejdere, og muligvis nogle af de eksterne parter, allerede er oprettede i DONG Energys system Active Directory (AD), bør brugerobjekterne kunne kopieres herfra. I dette afsnit af rapporten beskrives, hvordan DONG Energy benytter deres egenudviklede projektmodel, PinQ 1, til udvikling og håndtering af projekter. Denne projektmodel vil blive benyttet på PPW, hvorimod underprojektet EVA (replikering af brugerobjekter) vil benytte projektmodellen UP 2. Denne rapport beskriver overordnet brugerstyringen, der skal benyttes i PPW, hvordan denne håndteres og derefter primært omkring udviklingen af applikationen EVA. 3.1 EVA Formålet med EVA er hovedsageligt at kunne replikere og dermed flytte brugere fra Microsoft Active Directory (AD) til Microsoft Active Directory Application Mode (ADAM). Microsoft har på nuværende tidspunkt ikke selv frigivet et værktøj, der understøtter muligheden for at replikere objekter fra et AD til et ADAM. I mange virksomheder, der benytter et Microsoft miljø, er det centrale brugersystem opbygget i et Microsoft Active Directory. EVA skal gøre det muligt, at kunne opdatere et ADAM med brugerobjekter direkte fra et AD. Dette vil bevirke, at blandt andet brugeroplysninger kun skal vedligeholdes ét centralt sted, nemlig i Active Directory. EVA er tiltænkt som et hjælpeværktøj til de administratorer, der skal vedligeholde brugerstyringen i et eller flere forskellige miljøer af Microsoft Active Directory Application Mode (ADAM). Det er desuden tiltænkt, at EVA løbende kan holde ADAM instansen opdateret med brugeroplysningerne fra AD et. Dette gøres ved at sætte et afviklingstidpunkt for en fast overførsel (replikering), der opdaterer brugerobjekterne. I PPW er det planlagt med en natlig replikering. 1 Process in Quality (PinQ udtales Pink) - (Projektmodel internt i DONG Energy A/S) 2 Unified Process Side 8 af 72

9 3.2 Introduktion til Active Directory (AD) AD et er et software Directory. I et directory kan der gemmes informationer omkring udvalgte elementer og objekter, eksempelvis som i en telefonbog. Active Directory er specielt optimeret til at gemme informationer om personer, computere, adgangsforhold, printere, programmer osv Baggrund Microsoft lancerede Active Directory i midten af 1990 erne. Dette var for at forbedre den brugeradministration, der blev benyttet under Windows NT-systemet. Den daværende administration bestod i, at brugervedligeholdelsen - med blandt andet adgangsforhold - skulle vedligeholdes på hver enkelt maskine. Microsoft udviklede AD et for at give mulighed for en centralisering af brugeradministrationen i større Windowsmiljøer. Det var dog først med lanceringen af Windows 2000 Server (ca. år 2000), at Active Directory blev inkluderet som fast element i operativsystemet Struktur Strukturen i et Active Directory bygger på en hierarkisk struktur. I denne struktur kan blandt andet indgå: Skove (forests) overordnet objekt der indeholder alle domæner, grupper og andre objekter. Domæner (trees) hver domæne (tree) kan indeholde grupper, objekter mm. OrganizationalUnits et mappeobjekt, der kan benyttes til at indeholde og strukturere andre objekter. Grupper benyttes til at gruppere objekter eller andre grupper. Benyttes til sikkerhed eller distribution. Objekter et individuelt objekt med specifikke attributter (f.eks. en bruger, en computer eller en printer). Strukturen i AD er objektorienteret, og nye objekter kan tilføjes efter behov LDAP Microsoft Active Directory benytter blandt andet LDAP protokollen (Lightweight Directory Access Protocol), en protokol der benyttes til forespørgsler fra en applikation til en directory service. LDAP protokollen bygger på X.500 protokollen og blev udviklet i starten af 1990 erne på Michigan Universitetet. LDAP benytter TCP/IP ved netværkstrafik, i modsætning til den tidligere version af X.500 der benyttede OSI 3 til kommunikation via netværk. Den nuværende X.500 protokol er senere udvidet og understøtter i dag også TCP/IP Eksempel på brug En af funktionerne, som Active Directory benyttes til, er at validere brugeradgange. Dette sker blandt andet, når en bruger logger på en Windows-maskine der er tilsluttet et Microsoft-miljø (domæne). Når brugeren skriver sit brugernavn og kodeord valideres dette imod AD et. Windows-maskinen får da besked om hvilke rettigheder brugeren har fået tildelt, om der må logges på maskinen osv. Ligeledes kan Windows herigennem bestemme f.eks. hvilke netværksområder der er adgang til. 3 OSI - Open Systems Interconnection. ISO s forsøg på at standardisere netværkstrafik. Opfundet i Side 9 af 72

10 3.3 Introduktion til Active Directory Application Mode (ADAM) Active Directory Application Mode (ADAM) er, af Microsoft, udviklet til at være et supplement til Active Directory (AD). ADAM er tiltænkt til, at kunne validere brugeradgange i applikationer, hvor AD oprindeligt baserer sig på at validere brugeradgange på operativsystemer. Styrken ved ADAM er, at der kan sameksistere mange forskellige instanser ved siden af hinanden, hvor der kun kan være et AD. ADAM kan derfor benyttes til programvalidering, der kræver en specifik brugerstruktur. ADAM er kendetegnet ved at være fleksibelt i oprettelse af nye instanser og omstrukturering af objekter. 3.4 POWER Projekt Web (PPW) I forretningsenheden POWER er der taget beslutning om at udvikle et projekt web. Med projekt web menes en form for samarbejdsportal som f.eks. DTU s CampusNet. Det skal være muligt at benytte PPW i forbindelse med projekter, der involverer både interne medarbejdere og eksterne samarbejdsparter. Ved sådanne projekter, er det ofte nødvendigt at udveksle filer, mails, mødereferater mm. Grunden til, at PPW kun vil blive benyttet ved projekter med eksterne samarbejdsparter er, at interne projekter ofte benytter fællesdrev eller andre former for fildeling. Der eksisterer i dag allerede to projekt webs i POWER. Lotus QuickPlace, der benyttes på Sjælland (forhenværende virksomhed Energi E2) og Microsoft SharePoint, der benyttes på Fyn og Jylland (forhenværende virksomhed Elsam). Meningen med at oprette et nyt projekt web er at kunne konsolidere de to nuværende systemer ind i et enkelt system. Der er nedsat en projektgruppe med en tilhørende projektleder til styringen af projektet. Undertegnede er inddraget i projektgruppen til at kunne klarlægge eventuelle IT tekniske spørgsmål, der må opstå, og for at hjælpe med at definere kravspecifikationen til implementeringen af den nye løsning PPW. Det er muligt, at selve implementeringen af PPW på et senere tidspunkt udliciteres til en ekstern virksomhed, hvorimod implementeringen af EVA håndteres af undertegnede. 3.5 Process in Quality (PinQ) Ved projekter i DONG Energy skal den interne projektmodel PinQ følges. Denne model er udviklet internt i organisationen og bliver benyttet ved alle projekter over en vis økonomisk størrelse. PPW udvikles ved brug af projektmodellen PinQ. PinQ modellen består af 5 faser, hvoraf hver fase består af en eller flere underfaser. Figur Hovedfaser i PinQ Den indledende fase kaldes ide-fasen. Denne fase skal fremme den oprindelige idé, hvorpå der senere skal baseres et projekt. Input til denne fase kan blandt andet være krav fra myndigheder, kundehenvendelser, udbud, evalueringer mv. Alt input i denne fase samles i en overordnet projektide. Projektideen for PPW kan ses på bilag (Det skal bemærkes, at projektideen er skrevet af projektlederen for PPW, Jørgen Stock Melchior). Side 10 af 72

11 Den næste fase i PinQ projektmodellen er Analyse-fasen. Denne fase sørger for at belyse nogle af de uklarheder, der vil være i forbindelse med projektideen. Delpunkterne, der bør gennemgås i denne fase, afhænger af hvilket slags projekt, der ønskes. Af forskellige typer projekter kan blandt andet nævnes tekniske projekter, anlægsprojekter og forretningsprojekter. Ved analyse-fasens afslutning skal det endelige projektforslag afleveres. Projekter af en vis økonomisk størrelse skal godkendes af et lederudvalg, før næste fase påbegyndes. Analysefasen i PPW er også benyttet til at påbegynde UP på underprojektet EVA. Modningsfasen er den første fase, hvor der bliver tale om et konkret projekt. Idéen er blevet godkendt og oprettet som et projekt. I modningsfasen skal alle krav til projektet fastslås, der skal indhentes godkendelser ved de instanser, hvor det er påkrævet, og projektet skal planlægges og styres. Udførelsesfasen er den del, hvor alle krav til projektet er opstillet og den endelige realisering af projektet foregår. Dette kan for projekter blandt andet omfatte opbygning, montage, implementering, idriftsættelse og udlicitering. Denne fase afsluttes ved, at det udførte arbejde overdrages til ejeren af projektet. I den sidste fase, Evalueringsfasen, er det muligt for alle involverede parter i projektet at vurdere de enkelte elementer og se dem som en helhed. Afhængig af projekttypen vil dette normalt indbefatte projektgennemførelse, forretningsmodel og kundetilfredshed. 3.6 Arbejdsmetode I dette projekt omkring udarbejdelse af EVA har undertegnede arbejdet efter Unified Process-modellen (UP). Alle møder omkring tilblivelsen af PPW har fulgt PinQ modellen, og det har været nødvendigt at benytte denne model ved omtale og udvikling af PPW, mens udviklingen af EVA har fulgt UP-modellen. Fra projektets start har der været holdt møder og workshops omkring udviklingen af PPW. Undertegnede har blandt andet udført en SWOT-analyse 4 på baggrund af de nuværende systemer, der i dag bruges til formålet i DONG Energy. Denne kan ses i bilag Undertegnede har yderligere analyseret funktionaliteten i to af de mest udbredte systemer, der benyttes internt i koncernen. Funktionerne er blevet analyseret og klarlagt, og på baggrund af dette er de ønskede funktionaliteter i det nye system blevet specificeret i en kravspecifikation. Undertegnede har fungeret som den IT-kyndige person i projektet, og har samtidig været indgangsvinkel til alle de tekniske spørgsmål, der har været omkring tilblivelsen af PPW. Resten af projektgruppen er ansat på forretningssiden og har derfor bidraget med input til den fremtidige brug af systemet. Samtidig har der været holdt møder omkring implementeringen af EVA samt hvilke funktioner, der skulle være indeholdt i denne applikation. Funktionskravene til EVA er blevet specificeret af undertegnede samt en ekstern konsulent med ekspertise indenfor brug af Active Directory og ADAM. Disse er blandt andet baseret på, hvilke objekttyper der bør kunne overføres fra AD til ADAM Unified Process Unified Process (UP) er en udbredt softwareudviklingsproces, der ofte benyttes ved objektorienteret softwareudvikling. UP bygger på UML beskrivelsessproget. Der er fire faser i UP-udviklingsprocessen; Inception, Elaboration, Construction og Transition. Hver fase er en iterativ proces. 4 SWOT: Strengths, Weaknesses, Opportunities, Threats. Anerkendt metode til strategiudvikling. Side 11 af 72

12 I fasen inception klarlægges de grundlæggende krav og ideer til systemet. Alle krav der opstilles til systemet, i denne fase, udarbejdes som use cases. Det skal, i denne fase, yderligere fastslås hvorvidt udviklingsprojektet skal gennemføres eller ej. Fasen Elaboration benyttes til at fastslå arkitekturen og de endelige krav til systemet. Både analyse og design af systemet skal afsluttes i denne fase. Der bør implementeres nogle dele af de tidligere udarbejdede use cases, for at sikre at gennemførslen af projektet stadig er muligt. Construction fasen bruges til at implementere resten af systemet (nogle delelementer bør allerede være implementeret fra elaboration). Hovedformålet med denne fase er, at færdiggøre systemet og teste hvorvidt de ønskede funktioner fungerer efter hensigten. Dokumentation og eventuelle manualer skal også skrives i denne fase. Den sidste fase, Transition, bruges til overlevering af det endelige system til slutbrugeren. Ved problemer med produktet, der ikke har vist sig under testene, benyttes de sidste iterationer i denne fase til at rette fejl og mangler Backup Alle filer, der arbejdes på I dette projekt, befinder sig på et fællesområde. Dette bevirker, at der tages en daglig backup af alle data. Disse data gemmes som standard i 5 år, og derfor er der ikke gjort manuelle tiltag for yderligere at sikre data Versionsstyring Da det kun er undertegnede, der arbejder på udviklingen af EVA, vil versionsstyring ikke blive et problem. Hvis der bliver brug for at finde tidligere versioner af filer, kan den eksisterende backup facilitet benyttes. Det skal dog pointeres, at den færdige kode skal gemmes i DONG Energys interne system til udviklingsopgaver. Hvis der havde været flere udviklere, ville dette system med fordel kunne være benyttet til versionsstyring og parallelt arbejde i filer Tidsplan Selvom der arbejdes ud fra udviklingsprocessen UP, er det valgt at opdele tidsplanen i analyse, design, implementering, test og diverse. Opdelingen er sket med henblik på, at virksomhedsvejlederen også har fulgt fremskridtet og tidsplanerne, selvom UP-modellen ikke er kendt. Figur Tidsplan for udviklingen af softwareprojektet EVA. Side 12 af 72

13 4 Analyse 4.1 Struktur i Active Directory I DONG Energy benyttes Microsofts Active Directory til at validere brugere, computere og tilhørsforhold på det interne netværk. Når en bruger tænder en computer og logger på Microsoft Windows Vista, benyttes Microsoft Active Directory til at validere brugerens brugernavn og kodeord på netværket. Det samme gør sig gældende med adgangsforhold til netværksdrev og specifikke applikationer. Alle brugerobjekter i Active Directory er sorteret under en Organizational Unit (OU) der er navngivet BRUGERE (niveau 1). Under denne OU findes alle de forskellige forretningsenheder i DONG Energy også som OU ere (niveau 2). Og herunder er OU erne navngivet efter de interne lokationsnavne, hvor medarbejderne organisatorisk hører til (niveau 3). Alle enkelte brugerobjekter i DONG Energy findes derfor i fjerde niveau i AD et, nemlig: BRUGERE Forretningsenhed Lokation Brugerobjekt. Billedet til højre viser et udsnit af strukturen i DONG Energys Active Directory. Som det ses på billedet, er der en OU i første niveau, der kaldes Groups. Denne OU indeholder alle adgangsforhold til diverse fil-områder (Fil-share) og applikationer (Application permission groups). I hver af disse OU ere findes en del forskellige sikkerhedsgrupper (Security Groups, SG), der benyttes til at styre adgangsforhold. En sikkerhedsgruppe har forskellige elementer, der kan kontrolleres, heriblandt en liste over medlemmer i gruppen. Dette kan både være brugerobjekter, men også andre sikkerhedsgrupper. Figur Udsnit af Active Directory Ved at kunne tilføje andre sikkerhedsgrupper, kan vedligeholdelsen af gruppetilhørsforholdene lettes betydeligt. Dette gør det muligt at oprette en sikkerhedsgruppe for f.eks. hver lokation, og tilføje alle brugerobjekter fra lokationen til denne. Hvis alle på en lokation skal have adgang til det samme fil-område, kan den oprettede sikkerhedsgruppe lægges ind som medlem af fil-området. Derved får alle brugere i den oprettede lokationssikkerhedsgruppe adgang til fil-området. 4.2 Struktur i Active Directory Application Mode (ADAM) Opbygningen i ADAM kan strukturmæssigt foretages på samme måde som et AD. Der er samme mulighed for objekter, og strukturen vil også i et ADAM som oftest bestå af OrganizationalUnits (OUs). Det er op til administratoren af ADAM, at opbygge den struktur, der ønskes. Strukturændringer i et AD, der fungerer i et produktionsmiljø, vil ofte have konsekvenser for brugere, tilladelser, software mm. Derfor er det yderst sjældent, at et AD s struktur ændres efter det er taget i brug. Ved brug af et ADAM kan den opbyggede struktur oftest ændres lettere end i et AD, da ADAM normalt benyttes til et specifikt Side 13 af 72

14 formål (et enkelt system). Hvis der er flere systemer, der benytter ADAM, vil der oftest være flere instanser af ADAM, et til hvert system. Opbygningen af strukturen i ADAM, der skal bruges i forbindelse med PPW og EVA, kræver en diskussion i projektgruppen for PPW. Nedenstående skal derfor kun ses som et forslag til, hvordan strukturen kan laves. Dette forslag bygger på at have tre overordnede OrganizationalUnits (OUs). En til interne medarbejdere i DONG Energy POWER, en til eksterne brugere og en til sikkerhedsgrupper. Der er oprettet en skitse af den tiltænkte struktur på figuren Den OU, der er tiltænkt at indeholde alle de interne brugere i DONG Energy POWER, bør navngives POWER. Ved at vælge dette navn kan der på et senere tidspunkt tilføjes andre forretningsenheder i DONG Energy, hvis disse ønsker adgang til at benytte PPW. Underopdelingen i POWER (OU) kan evt. struktureres ud fra lokationerne og derefter igen afdelingerne. Derved opnås der en allerede kendt strukturering for administratoren af ADAM. De eksterne brugere af PPW bør placeres i en OU i niveau 2, som POWER (OU) og gives et passende navn, f.eks. eksterne. Underopdelingen i denne OU bør være efter hvilket firma, de eksterne brugere arbejder for, og hvis behovet opstår, en derefter passende underopdeling. Det kunne tænkes, at den sidste underopdeling kunne være efter afdeling eller placering (land) f.eks. Vattenfall Danmark, Sverige, Norge. Administratoren af ADAM bør kunne oprette OrganizationalUnits for at kunne vedligeholde ovenstående struktur, hvis denne vælges implementeret. Figur Tiltænkt struktur i ADAM Sikkerhedsgrupperne bør oprettes i en OU for sig. Ved at opdele brugere og grupper hver for sig allerede på niveau 2 i ADAM, giver det en mere intuitiv opdeling og struktur. Understrukturen for Grupper (OU) kan yderligere opdeles i hvert projekt (evt. efter navn), der findes på PPW. Under hvert projektnavn (OU) vil da findes de sikkerhedsgrupper (SG), der er tilknyttet det aktuelle projekt. Administratoren bør kunne oprette sikkerhedsgrupper til projekter efter behov. Sikkerhedsgrupperne skal håndtere brugernes rettigheder på PPW; Brugere med adgang til PPW på et enkelte projekt, læse- og skriverettigheder i mapper osv. Side 14 af 72

15 4.3 Overordnet systemsammenhæng For at give et billede af hvordan systemet er tiltænkt, er nedenstående figur medtaget i rapporten. Figuren kan give læseren et hurtigt overblik over, hvordan valideringen og bruger-replikeringen er tiltænkt projektet PPW. Figur Overordnet systemsammenhæng. De interne medarbejdere og de eksterne parter, der skal benytte PPW, skal angive brugernavn og adgangskode for at tilgå systemet. De indtastede oplysninger valideres mod en central ADAM instans. ADAM vedligeholdes ved, at administratoren replikerer brugerobjekter (med EVA) fra AD. De brugerobjekter, der replikeres til ADAM, skal derefter flyttes til den korrekte OrganizationalUnit (OU) og føjes til de påkrævede sikkerhedsgrupper (SG) manuelt af administratoren. 4.4 Use Cases I dette afsnit vil alle de udarbejdede use cases for applikationen EVA blive beskrevet. Modellen UP, der benyttes i dette projekt, bygger primært på udvikling ud fra use cases. Disse benyttes til at opstille krav og specificere den funktionalitet, der ønskes i den endelige løsning. Alle use cases herunder er opdateret og vedligeholdt igennem hele projektet, da use cases kan ændre sig løbende gennem de forskellige iterationer. Et samlet use case diagram over alle funktionerne i EVA kan ses i bilag 9.1. Grundet de mange use cases er der kun udvalgt nogle stykker, der vises i det nedenstående. De resterende use cases, der ikke vises, er vedlagt i bilag til Side 15 af 72

16 4.4.1 Use Case Forbind til et directory med EVA Use Case Navn Tilslut til et directory med EVA Mål Directoriet tilsluttes, brugeren godkendes og EVA starter uden fejl Scope System Niveau Primær Prækonditioner Brugeren er tilknyttet en sikkerhedsgruppe med tilladelse til at forbinde og eventuelt at udføre ændringer i AD et og benytter en valideret Windows session. Succes postkondition Programmet EVA vises for brugeren, og der er forbundet til det valgte directory Fejl postkondition Programmet giver en fejlbesked Primær aktør Systemadministrator for ADAM Trigger Programmet EVA ønskes forbundet til et directory Normalforløb Trin Aktivitet 1 Brugerens brugernavn tages fra de indtastede data i settings 2 Systemet godkender medlemskab af en sikkerhedsgruppe med tilstrækkelige rettigheder til at læse i directoriet, og henter topnoden. 3 Applikationens GUI opdateres til tilsluttet med topnode Alternative forløb 2.a Fejl i godkendelsen af brugerens medlemskab i den korrekte sikkerhedsgruppe i AD et. Der vises en fejl Prioritet Høj Performance Max 2 sekunder pr. godkendelse Frekvens 5-10 gange om dagen System Sekvens Diagram Forbind til et directory med EVA Side 16 af 72

17 4.4.2 Use Case Browse objekter Use Case Navn Browse objekter Mål Objekterne vises i EVA Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at læse fra AD og ADAM. Brugeren er logget ind i EVA. Succes postkondition Objekterne vises i EVA Fejl postkondition Programmet giver en fejl om, at objekterne ikke er tilgængelige Primær aktør Systemadministrator for ADAM Trigger Det ønskes at gennemse (browse) objekterne Normalforløb Trin Aktivitet 1 Der tilsluttet til AD et eller ADAM 2 Objekterne vises i en træstruktur og/eller en liste i EVA Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 2.a Der opstår en fejl ved at vise objekterne. En fejl vises Prioritet Høj Performance Max 10 sekunder pr. visning Frekvens Flere gange dagligt System Sekvens Diagram Browse objekter Side 17 af 72

18 4.4.3 Use Case Repliker bruger Use Case Navn Repliker bruger Mål Det valgte brugerobjekt replikeres fra AD til ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at læse fra AD og skrive i ADAM. Brugeren er logget ind i EVA. Succes postkondition Det replikerede brugerobjekt fremgår i ADAM Fejl postkondition Programmet giver en fejl om, at replikeringen er mislykket Primær aktør Systemadministrator for ADAM Trigger En manuel replikering ønskes Normalforløb Trin Aktivitet 1 Der tilsluttet til AD et 2 Brugerobjektet der ønskes replikeret findes (browse) 3 Brugerobjektet sættes i kø til replikering 4 Der tilsluttes til ADAM 5 Replikeringen startes og der ventes til denne er færdig 6 Brugerobjektet fremgår i ADAM import-folderen Alternative forløb 1.a, 4.a Fejl ved tilslutning. En fejlbesked vises til brugeren 3.a Der opstår en fejl ved at sætte brugerobjektet i kø 5.a Der opstår en fejl ved replikering. En fejlbesked bliver vist Prioritet Høj Performance Max 3 sekunder pr. brugerobjekt, hvis de tages enkeltvis Frekvens Flere gange dagligt System Sekvens Diagram Repliker bruger Side 18 af 72

19 4.4.4 Use Case - Søg Use Case Navn Søg Mål At kunne fremsøge objekter i AD og ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at læse fra AD og ADAM. Brugeren er logget ind i EVA. Succes postkondition Det søgte objekt fremkommer i søgningen Fejl postkondition Det søgte objekt findes ikke under søgningen. Primær aktør Systemadministrator for ADAM Trigger Et specifikt objekt ønskes fundet Normalforløb Trin Aktivitet 1 Der tilsluttet til AD eller ADAM, afhængigt af hvor søgningen ønskes udført 2 Søgefunktionen åbnes 3 Der indtastes specifikationer omkring objektet der ønskes fundet 4 Objekter der matcher specifikationerne fremkommer i en liste Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 3.a Der opstår en fejl under søgningen. En fejl vises til brugeren Prioritet Lav Performance Max 10 sekunder pr. søgning Frekvens Flere gange dagligt System Sekvens Diagram Søg Side 19 af 72

20 4.4.5 Use Case Flyt brugerobjekt (ADAM) Use Case Navn Flyt brugerobjekt (ADAM) Mål At kunne flytte brugerobjekter rundt i ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at skrive i ADAM. Brugeren er logget ind i EVA Succes postkondition Objektet flyttes fra en OU 5 til en anden OU i ADAM Fejl postkondition Objektet flyttes ikke Primær aktør Systemadministrator for ADAM Trigger Et objekt ønskes flyttet til anden placering i ADAM Normalforløb Trin Aktivitet 1 Der tilsluttes til ADAM 2 Der browses til placeringen hvor objektet findes 3 Objektet markeres og der trykkes flyt 4 Et nyt vindue vises, hvor den nye placering i ADAM vælges 5 Flytningen godkendes ved klik på OK Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 5.a Der opstår en fejl under flytningen. En fejl vises til brugeren Prioritet Lav Performance Max 1 sekunder pr. flytning Frekvens Flere gange dagligt System Sekvens Diagram Flyt brugerobjekt (ADAM) 5 Organisational Unit (En form for mappe-objekt i ADAMs struktur) Side 20 af 72

21 4.5 Supplerende kravspecifikation Introduktion Den supplerende kravspecifikation indeholder de krav til løsningen, der ikke er blevet fremstillet som use cases Generel beskrivelse Den tilsigtede løsning, applikationen EVA, har til formål at give adgang til replikering af objekter fra Microsofts Active Directory til Microsoft Active Directory Application Mode. Microsoft har ikke selv leveret et værktøj, der kan håndtere denne problemstilling. Ved at kunne replikere blandt andet brugerobjekter fra AD til ADAM, skal vedligeholdelsen af disse kun foregå ét sted. Muligheden for at kunne oprette en automatisk overførsel af udvalgte objekter fra AD til ADAM skal kunne virkeliggøres ved brug af Windows Scheduled Task eller lignende Specifikke krav Perspektiv: Løsningen er afhængig af forbindelsen til et Active Directory og et Active Directory Application Mode. Program Funktioner: Tilslutning til AD / ADAM Browse objekter i AD / ADAM Repliker brugerobjekt fra AD til ADAM Søg i AD / ADAM Opret nyt objekt (ADAM) Slet objekt (ADAM) Disable / Enable brugerobjekt (ADAM) Flyt brugerobjekt (ADAM) Omdøb objekt (ADAM) Mulighed for batch replikering Bruger-karakteristika: Løsningen skal kunne benyttes af brugere, der i forvejen er bekendt med Microsoft Active Directory og opbygningen af dette. Hvis ovenstående er kendt, skal funktionerne navngives, så de er selvforklarende og lette at bruge. Brugervenlighed: Det er vigtigt, at farverne, der benyttes i den grafiske brugerflade, ikke inkluderer farver, der kan medføre problemer for farveblinde. Funktioner, der medfører ændringer, hvorved data går tabt (f.eks. sletning af objekter), skal altid godkendes, før de udføres. Begrænsninger: For at brugere kan benytte løsningen, skal de være medlem af en sikkerhedsgruppe, der giver de nødvendige rettigheder i den respektive ADAM instans. Sikkerhedsgruppen bør styres fra Active Directory et. Ved tilslutning valideres brugeren imod ovenstående AD sikkerhedsgruppe. Rettigheder til brug af EVA vil blive tildelt af DONG Energys ServiceDesk, efter godkendelse fra systemejeren. Side 21 af 72

22 Fejlhåndtering: Der skal i opsætningen af løsningen være mulighed for at angive placeringen af en log fil. Når en sådan er angivet, bør alle aktioner, der foretages i løsningen, blive gemt i denne. Hver aktion, der gemmes, skal ydermere tilføjes et tidsstempel og evt. et brugernavn på aktøren. Performance: I forbindelse med afvikling er EVA applikationen ikke tidskritisk, forstået på den måde, at replikering m.v. ikke absolut skal have svartider på mindre end et sekund. Applikationen anses for at høre til den type administrator funktioner, der har lav prioritet. Svartiderne for de forskellige events vil afhænge af både systembelastning, opkobling og antal objekter, der skal vedligeholdes/replikeres, men det er tilstræbt at optimere koden, så netværksbelastningen bliver så lille som mulig og dermed giver en rimelig hurtig svartid. Tests har vist, at de fleste funktioner kan afvikles på mellem 1 og 3 sekunder, hvilket anses som acceptabelt. Programmeringssprog: Programmeringssproget C# (udtales C-Sharp) er blevet benyttet til udviklingen af denne applikation. Dette er valgt, da DONG Energy baserer de fleste systemarkitekturer på Microsoft platforme, og C# er netop udviklet af Microsoft. Ydermere benyttes XML til filhåndtering af de objekter, der skal replikeres fra Active Directory til Active Directory Application Mode. Systemkrav: Computer m. skærm, keyboard og mus. Netværk, styret med domæne. Windows operativsystem (Windows XP eller Windows Vista)..NET Framework 2.0 eller højere. Brugere med læse- og skriveadgang til Microsoft AD og Microsoft ADAM. Side 22 af 72

23 4.6 Domæne Model Domæne modellen, der vises nedenstående, er en fortolkning af det fysiske område, som systemet skal bygge over. Modellen har ikke noget med den endelige software at gøre, men giver et billede af de fysiske elementer, der skal indgå og samarbejde med systemet. Nedenstående model er udviklet baseret på en gennemgang af ovenstående use cases og er til stor hjælp, bl.a. når der skal udvikles klassediagrammer i designfasen. Figur Domæne model Side 23 af 72

24 4.7 PPW I forbindelse med Ide og Analyse-fasen (projektmodellen PinQ) er der holdt møder omkring klarlægning og udvikling af det nye projekt web Indledende undersøgelser I det tidlige forløb har der været sat fokus på de nuværende projekt webs, Lotus QuickPlace og Microsoft SharePoint. Undertegnede har analyseret og klarlagt de funktioner, der i dag benyttes i disse to systemer. Alle funktionerne, der benyttes i Lotus QuickPlace, er opstillet på listeform og kan ses i bilag Funktionerne i Microsoft SharePoint er ikke opstillet i punktform, da brugen af dette projekt web begrænser sig til fildeling med eksterne parter. For yderligere at klarlægge brugernes behov til et nyt projekt web er der udført en SWOT analyse for Lotus QuickPlace og Microsoft SharePoint. Det skal dog bemærkes, at SWOT analysen er dannet ud fra de nuværende systemer og funktionerne implementeret i disse. Der er mange funktioner i begge systemer, der ikke anvendes i produktionsmiljøet i dag. Analysen er blevet diskuteret i projektgruppen og har bidraget til de enkelte projektdeltageres systemforståelse af de nuværende systemer. SWOT analysen kan ses i bilag Det bør noteres, at projektgruppen har vurderet, hvorvidt systemet Omada (SAP), ville kunne benyttes til at løse problemstillingerne i PPW. Der har på nuværende tidspunkt ikke været en dybdegående analyse af Omada, men det er den generelle opfattelse i projektgruppen, at dette system er et specielt værktøj, der er forbeholdt SAP projekter. Sammen med en anden projektdeltager er der afholdt interviewmøder med brugerne af de nuværende projekt webs, og svarene er sammen med de andre undersøgelser efterfølgende blevet brugt til at påbegynde definitionen af det nye PPW Projektmodel og arbejdsmetode Arbejdsprocedurerne i den færdige løsning bør følge og underbygge den generelle projektmodel, der er specificeret i DONG Energy (PinQ). Det bør tilstræbes, at procedurer og arbejdsmetoder beskrevet i PinQ også benyttes på PPW for at lette arbejdsgangen i projekterne, også selvom eksterne parter involveres. Filstrukturen tilhørende hvert projekt på PPW bør opdeles på en måde, så den generelle projektmodel følges. Det kan være en overordnet mappeopdeling tilhørende hver projektfase. Den valgte mappestruktur bør oprettes automatisk ved oprettelsen af et nyt projekt. Alle filer oprettet i den aktuelle projektfase bør placeres i den tilhørende mappe. Hvis der yderligere er behov for en specifik understruktur i en mappe, bør projektlederen eller en dertil udpeget person kunne oprette og ændre på mappestrukturen. I den færdige løsning bør muligheden for at publicere dokumenter med en gyldig fra -dato være implementeret. Dette vil bevirke, at der altid er mulighed for at se, hvordan et givet projekt har set ud på givne tidspunkter i projektforløbet. Uanset om det er 2 år tilbage i tiden, eller om det er 14 dage frem i tiden Filstyring på PPW Den fysiske placering af filerne, der benyttes på PPW, bør være på en separat server. Alle filer tilhørende det aktuelle projekt bør placeres der. Dette vil sikre kontinuitet for filerne i projektet. Ved hvert faseskift skal alle filer Side 24 af 72

25 overføres til de interne systemer i DONG Energy POWER (PONDUS og Mdoc). Filerne placeres i de interne systemer afhængigt af filtypernes korrekte arkivsystem. Dette vil sikre, at alle dokumenter findes i arkivsystemerne, også fra afsluttede projektfaser i igangværende projekter. Det bør diskuteres, hvordan systemet skal håndtere filer, der oprindeligt er placeret i andre systemer. Skal disse checkes ud eller sættes inaktive i disse systemer, så længe projektet arbejder på filerne i PPW? Når arbejdet med filerne er færdigt, skal filerne placeres i de oprindelige systemer og dermed checkes ind for editering af andre brugere igen. Dette bør automatisk ske, hvis projektet skifter projektfase, da filerne så bør gemmes i arkivsystemerne. Det bør diskuteres, hvordan referencer til filer i andre systemer skal håndteres på PPW Bruger- og Adgangsstyring Tilføjelsen og håndteringen af nye brugere og adgange på PPW bør håndteres af enten en udpeget PPW administrator eller af en af IT afdelingerne i DONG Energy. Adgange på hvert projekt bør være projektlederens ansvar. Projektlederen eller en udvalgt person i projektet bør kunne bede om adgang for nye brugere, såfremt dette ønskes. Hvis brugeren allerede eksisterer i DONG Energys brugerkatalog (AD) bør brugerobjektet kunne benyttes herfra. Brugerkataloget til styringen af PPW skal være enten AD eller ADAM, hvor sidstnævnte stemmer overens med udviklingen af applikationen EVA til håndtering af adgange og brugere. ADAM vil være bedst egnet til PPW, da strukturen kan ændres uden de store konsekvenser. Dette er ikke nødvendigvis det samme med et AD. Rettighedsstyring til at vise og eventuelt ændre og oprette filer bør besluttes af det individuelle projekt. Opsætningen af adgange skal da håndteres af PPW administratoren. Adgangsrettigheder bør besluttes af projektlederen ved oprettelsen af et nyt projekt. Rettigheder bør håndteres på mappeniveau. Dermed sikres det, at udenforstående brugere ikke har mulighed for at se filer eller filnavne på eventuelt fortrolige filer. Som minimum bør der for hver mappe kunne gives følgende rettigheder: Ingen adgang. Læseadgang (read). Læse- / skriveadgang (read/write). Side 25 af 72

26 5 Design I dette afsnit beskrives, hvordan den endelige struktur i systemet EVA ønskes implementeret. Ved at gennemgå designfasen med basis i ovenstående analysefase, bliver implementeringsarbejdet lettet betydeligt. Implementeringen lettes ved udvikling af bl.a. sekvensdiagrammer og et klassediagram for at gøre programmeringen mere overskuelig og struktureret. 5.1 Software arkitektur 3-lagsmodellen er valgt ved implementeringen af applikationens arkitektur. Dette betyder, at applikationen er opdelt i lag, som inkluderer GUI (Graphical User Interface), applikations kode og LDAP kode. GUI inkluderer alle visuelle formularer, der vises for brugeren. Ydermere er alle events til formularerne også inkluderet i disse filer (knap-tryk mm.). Applikations kode indeholder alle funktioner i koden, som ikke benytter sig direkte af GUI-laget. Dette lag omfatter den primære programkode (logik) og benyttes til at kommunikere mellem GUI-laget og LDAP-laget. GUI (Graphical User Interface) Application Code LDAP kode dette lag benyttes til alle forespørgsler, der skal udføres i forbindelse med LDAP protokollen. Dette betyder generelt alle kald til AD/ADAM. Ved at benytte ovenstående opdeling bliver der en klar adskillelse mellem opbygning og logik i applikationen. Dette kan på et senere tidspunkt være med til at lette arbejdet for andre programmører, der skal implementere ændringer til funktioner eller andet i applikationen. LDAP Code AD / ADAM Kommunikationen med AD og ADAM foregår via LDAP Figur Lagsmodellen protokollen, som håndteres fra det tredje og nederste lag, således at applikationens funktioner ikke skal tage højde for dette. Hvis der på et senere tidspunkt er grund til at optimere LDAP kaldene, eller helt udskifte LDAP-laget med en anden protokol, klares dette nemt ved udskiftning af det tredje lag. Side 26 af 72

27 5.2 GUI (Graphical User Interface) Brugergrænsefladen til systemet er det øverste lag i applikationen. Det er fra dette lag, at brugeren har mulighed for at benytte programmet igennem tryk på taster, skærmknapper, osv. Det er vigtigt med en simpel og effektiv struktur af det visuelle lag, så brugeren får en god og intuitiv oplevelse ved brug af applikationen. Det er essentielt at have designet det overordnede visuelle layout samt alle primære funktioner til applikationen inden udviklingen starter. Det første udkast til det nye visuelle design er baseret på det allerede eksisterende design i MMC (Microsoft Management Console). Da funktionaliteten i applikationen generelt er en udvidelse af eksisterende funktionaliteter brugt i MMC, blev dette design fundet anvendeligt og derfor benyttet som udgangspunkt for den nye applikation. Tree structure of OU s Top-Menu List of objects contained in selected OU I toppen af applikation findes en menulinje, som indeholder en række brugerfunktioner. En sådan menulinje er kendt fra andre programmer, og denne defacto standard er derfor en klar fordel for nye brugere af applikationen. List of replication items Figur Tiltænkt layout til GUI Den midterste del af applikationen er opdelt i to sidestillede vinduer. Det venstre vindue er valgt til at indeholde en træstruktur af OU-objekter fra det tilsluttede directory (AD eller ADAM). Det højre vindue vil blive brugt til at liste forekomsten af de objekter, der er indeholdt i den valgte container (OU), f.eks. objekter såsom brugere, sikkerheds-grupper, computere osv. Den eneste design forskel mellem MMC og EVA er det ekstra vindue, der er tilføjet i bunden af applikationen. Dette vindue er tænkt til at kunne indeholde en liste over de elementer, der er udvalgt til replikering fra AD til ADAM. Denne liste vil være oprettet af elementer gemt i en XML-fil, som vil blive gennemgået nærmere i det efterfølgende. 5.3 Funktionalitet Funktionaliteten af applikationen kan overordnet deles i to grupper: de primære og de sekundære funktionaliteter. De primære funktionaliteter vil bestå af nyudviklede muligheder, der ikke er at finde i andre applikationer, samt anden funktionalitet, som disse baserer sig på. De sekundære vil bestå af funktionaliteter, der kan findes i andet software på markedet, og som ikke indgår sammen med de primære funktionaliteter Primær-funktionalitet Replikering med og uden brug af GUI Det skal være muligt at replikere objekter fra AD til ADAM. Hvis der skal replikeres objekter, hvor der gøres brug af GUI, skal replikeringen startes manuelt ved tryk på en knap. Listen med objekter, der bliver replikeret, skal fremgå klart af applikationen. Yderligere skal det fremgå, hvor langt processen er, mens replikeringen foretages. Side 27 af 72

28 Hvis der ikke gøres brug af GUI (dvs. ved batch afvikling), skal det være muligt at køre applikationen med et argument indeholdende stien til en XML-fil. Denne fil skal så indeholde alle de objekter, der skal replikeres. Dette implementeres af hensyn til en automatiseret natlig replikering, der skal holde ADAM opdateret med de nyeste ændringer og tilføjelser. XML-fil Til ikke-gui afvikling gøres der brug af en XML-fil, som indeholder alle de objekter, der er markeret til replikering. Det skal være muligt at tilføje og fjerne objekter fra listen, og det skal yderligere være muligt at kunne eksportere den nuværende XML-fil, som herefter kan bruges under den natlige (batch) replikering. Log-fil Der skal oprettes en fil til lagring af alle tilføjelser, ændringer og eventuelle fejl, der forekommer via applikationen. Dette sikrer, at der ved uforudsete resultater findes en mulighed for fejl-søgning af IT-specialister, også selv om personerne ikke direkte kender til programmeringen bag applikationen. Indstillinger Programmet opretter forbindelse til AD og ADAM, og indstillingerne for disse forbindelser skal gemmes. Dette skal gøres af applikationen, og specielt kodeordet for at oprette forbindelsen skal sikres. Dette kan ske ved at gemme værdien enten i registreringsdatabasen under HKCU, da denne og underliggende værdier kun kan læses af den aktuelle bruger, eller ved at kryptere kodeordet og gemme det i en fil. Det skal være muligt at gemme hvilke attributter, der skal replikeres for de valgte objekter. Det skal ydermere være muligt at tilføje og fjerne attributter, da disse kan være forskellige fra system til system. Dette kan også håndteres af ovenstående XML-fil Sekundær-funktionalitet Browse objekter Mus og keyboard skal kunne benyttes til at browse sig igennem alle de forskellige elementer fra det tilsluttede directory. Dette er tiltænkt at skulle fungere på samme måde som ved brug af MMC (Microsoft Management Console). I MMC benyttes en træstruktur til at browse OU-objekter og en dertil hørende liste indeholdende alle underelementer til en valgt OU. Oprettelse af objekter (OU og Grupper) Ved brug af GUI skal det være muligt at oprette nye OU er samt grupper. Ved oprettelse af disse objekter skal der angives et minimum af information, der gemmes i de påkrævede attributter. Hvis der er yderligere attributter, der skal udfyldes, kan dette klares efterfølgende via vedligeholdelsesfunktionen. Flytning af objekter Objekter skal kunne flyttes til andre placeringer (OU er), da objekter ofte placeres efter forskellige regler fra directory til directory. Denne funktionalitet skal bruges i forbindelse med GUI-delen af applikationen. Sletning af objekter Side 28 af 72

29 Det skal være muligt at slette objekter fra det tilsluttede directory. Dette kan bl.a. være nødvendigt, hvis der er sket fejl i en synkronisering af brugere fra AD til ADAM, eller hvis f.eks. en medarbejdet er stoppet i virksomheden og dermed ikke længere skal have adgang til systemets funktioner. Visning af attributter Applikationen skal indeholde en funktionalitet, der gør det let at få vist attributter hørende til et valgt objekt. Da et directory baserer sig på information omkring objekterne, er det yderst vigtigt, at der som minimum vises de vigtigste attributter fra hvert objekt. Søgning Da der ofte forekommer mange elementer i en stor træstruktur, vil det være godt at kunne søge efter specifikke elementer. Der skal kunne søges i alle attributter, der indeholder klar tekst. Søgningen skal kunne udføres på alle elementer. 5.4 LDAP (Lightweight Directory Access Protocol) I applikationen benyttes LDAP-protokollen til kommunikation med det tilsluttede directory. Denne protokol er valgt, da den er let tilgængelig og forholdsvis let at implementere. Til information kan det nævnes, at LDAP bygger på standard TCP/IP protokollen LDAP-Opslag LDAP laget bliver nederste lag i applikationen, og det benyttes af alle de ovenstående lag. Dette lag skal håndtere alle forespørgsler, der foretages til AD og ADAM. Disse forespørgsler kan blandt andet inkludere: Visning af objekter Søgning efter objekter og attributter Oprettelse af objekter Ændring af objekter Ovenstående er kun nogle af de forespørgsler, der skal håndteres af LDAP laget i applikationen. Det ønskes, at applikationslaget indeholdende LDAP funktioner bliver opdelt i klasser efter den funktionalitet, der udføres op imod AD eller ADAM. Dette vil sikre en lettere tilgang for videreudvikling af applikationen efter dette projekts afslutning LDAP-Skema LDAP-skemaet består af en række attributter, der kan defineres på en sådan måde, at der dannes objekter. Det er disse objekttyper, der afgør hvilke data, der kan sendes til og fra AD og ADAM. Ved replikering af objekttypen User (bruger) fra AD til ADAM kan der opstå problemer ved manuelt at angive værdien af attributten objectsid. Denne attribut er unik for alle objekter af typen User, og sættes derfor normalt automatisk af systemet. Det er derfor besluttet at benytte objekttypen userproxyfull i stedet for User, da dette Side 29 af 72

30 objekt tillader, at alle attributter manuelt kan sættes. Objektet userproxyfull kan håndtere alle attributter, som objektet User benytter. UserProxyFull objektet har yderligere en egenskab, der endnu ikke er nævnt. Ved validering af et userproxyfull objekt (f.eks. en brugervalidering på PPW) sender ADAM i realiteten valideringsforespørgslen videre til det bagvedliggende Active Directory, der enten godkender eller afviser valideringen. Af samme grund vil et brugerobjekt, der f.eks. er disabled i AD et, blive afvist selvom valideringen umiddelbart foregår op imod et ADAM. Alle andre attributter tilhørende userproxyfull håndteres internt i ADAM (navn, beskrivelse osv.). 5.5 Sekvens diagrammer Sekvens diagrammer benyttes af programmørerne, når de specificerede funktioner skal implementeres. Diagrammerne beskriver, hvordan funktionerne udføres klasserne imellem. Opbygningen af sekvens diagrammerne er delt i tre dele. Den visuelle del af applikationen; Graphical User Interface (GUI), applikationsdelen og håndteringen af LDAP-forbindelser. Alle funktioner i GUI-delen af applikationen er baseret på events. Det betyder, at applikationen er inaktiv indtil brugeren interagerer med den visuelle overflade, f.eks. ved tastatur input, knap-tryk, valg i menuer, osv. Når en event opstår i GUI-delen, håndteres det enten direkte i egen klasse, eller der kaldes en klasse og funktion fra applikationskode-delen. Nedenstående sekvens diagrammer vil ikke afbilde den implementerede kode fuldstændig, da der kan forekomme små forskelligheder fra sekvens diagrammet til den egentlige implementering i koden, hvor f.eks. navngivning, parametre og deslige kan være forskellige. En del af de medfølgende parametre fra implementeringen fremgår således ikke af sekvens diagrammerne grundet hensyn til overskueligheden. Ved alle nedenstående sekvens diagrammer er det forudsat, at brugeren allerede har startet applikationen og er tilsluttet enten AD eller ADAM. Sekvens diagrammer, der ikke umiddelbart findes nedenstående, kan findes i de vedlagte bilag. Side 30 af 72

31 Side 31 af 72

32 5.6 XML Ved eksport og import af objekter fra AD og ADAM benyttes XML. Dette er valgt, da XML er oplagt til lagring af data, der kan benyttes af flere forskellige programtyper, og som samtidig til en vis grad kan siges at være i almindelig læsbar format. XML filen, der skal indeholde alle elementerne, skal følge layoutet vist på figur Dette sikrer let læsbarhed samt en enkel integrering til andre applikationer, der skal kunne benytte denne type fil. Hvert element i filen skal være distinguishedname-attributten for objektet, og skal derfor være omkranset af <OU>. <?xml version="1.0" encoding="utf-8"?> <ReplicationList> <OU>distinguishedname</OU> <OU>distinguishedname</OU> <OU>distinguishedname</OU> </ReplicationList> Figur XML layout Side 32 af 72

33 5.7 UML-klassediagram Klassediagrammet beskriver sammenhængen i applikationen klasserne imellem. Hver klasse indeholder nogle attributter og nogle metoder. Nedenstående diagram eksempel giver et billede af, hvordan applikationens klasser er struktureret. Det skal noteres, at klassediagrammet er generet af Microsoft Visual Studio 2008 i slutningen af projektet. Tidligere versioner af diagrammet er ikke medtaget. Et klassediagram ændrer sig løbende igennem udviklingen af applikationen, og ved hver ændring af attributter eller metoder skal diagrammet opdateres. Nedenstående klassediagram er skaleret ned, grundet de mange klasser. Det originale klassediagram kan findes på vedlagte CD, under implementeringsprojektet. Figur Klassediagram Side 33 af 72

34 5.8 Beskyttelse af kodeord Det er påkrævet, at der indtastes brugernavn og kodeord for at kunne benytte applikationen med AD og ADAM, og det er derfor vigtigt, at kodeordene beskyttes effektivt fra uautoriseret adgang. Adgangskoderne gemmes i en XML-lignende fil, der automatisk håndteres af applikationen. Dette betyder også, at resten af indholdet af filen kan læses direkte som klar-tekst, hvis man som bruger har adgang til filen. Der er 2 niveauer af sikkerhed, der beskytter filen og kodeordene fra uautoriseret adgang. I DONG Energy benyttes styresystemet Microsoft Windows Vista. Der benyttes central brugerstyring med specifikke rettigheder tildelt igennem AD et. Enhver bruger, der benytter EVA applikationen, vil få oprettet en personlig profil, indeholdende netop deres specifikke indstillinger. Denne profil gemmes herefter under brugerens egen brugerprofil på harddisken, hvorpå applikationen afvikles. Det betyder, at kun system-administratorer og brugeren selv har adgang til det pågældende område og underfoldere på maskinens harddisk, hvorpå filen befinder sig. Dette niveau af sikkerhed styres af rettighederne tildelt brugerne fra AD et, og kan derfor betegnes som den første sikkerhed for at beskytte filen og dens indhold. Selvom ovenstående beskytter adgangskontrollen fra andre brugere med normale rettigheder, har det været et ønske, at systemadministratorer heller ikke har mulighed for at finde kodeordet direkte i filen. Af denne grund er det valgt at kryptere kodeordet i filen. Krypteringen skal håndteres af EVA applikationen på en sådan måde, at det indtastede kodeord automatisk krypteres. Endvidere skal applikationen dekryptere kodeordet og benytte det til oprettelse af LDAP-forbindelserne, uden at kodeordet vises for brugeren. AES (Advanced Encryption Standard) er valgt til at kryptere/dekryptere kodeordet. AES krypterings algoritmen er også kendt under navnet Rijndael algoritmen, som er en symmetrisk blok krypteringsalgoritme, der betragtes som amerikansk standard i dag, og som stadig anses som sikker. Algoritmeteorien bag AES kan ses på nedenstående figur. Figuren er et udklip fra kursus-materialet fra kursus Kryptologi 1 side 37. Materialet er skrevet af Lars R. Knudsen og er udleveret via CampusNet på DTU. Figur AES kryptering Nedenstående metode vil blive benyttet, når et kodeord skal krypteres til brugeres fil. Side 34 af 72

35 Den kombinerer brugerens indtastede kodeord med en udvalgt IV (Initial Value), der kun kendes af programmøren. De to værdier kombineres på en specifik måde i algoritmen og krypteres derefter til en tekst, der ikke umiddelbart kan læses. Kodeord indtastet af brugeren IV Grunden til brugen af IV i algoritmen er, at der er igangværende projekter uden IV, der udregner krypterede værdier af tilfældige ord og tekster. Både den krypterede og den normale tekst gemmes i frit tilgængelige databaser, og evt. krypterede værdier kan derved hurtigt brydes ved opslag i en sådan tabel. Ved at vælge en unik IV, vil det besværliggøre brugen af disse databaser, hvis indhold kaldes rainbow-tables. Et uautoriseret angreb af denne type kaldes for et dictionary attack. Kombiner værdier Gem data Figur Kryptering af kodeord Sikkerheden kunne yderligere øges ved indførelse af en tabel indeholdende forskelligt dannede IV s til hver bruger. Hvis dette blev indført, ville alle krypterede kodeværdier være endnu sværere at bryde ved brug af rainbow-tables, da hver bruger så ville have forskellige kryteringsnøgler. Det krypterede kodeord kunne yderligere hashes, som ved normale kodeords-checks, men grunden til, at det ikke ønskes her, er at undgå, at brugerne skal indtaste deres kodeord ved starten af programmet. Gjorde man dette, ville kodeordet først blive krypteret med en IV og derefter hashed, men det er ikke muligt at dekryptere en hash-værdi, og det ville derfor ikke være muligt at oprette LDAP-forbindelsen uden at kodeordet skulle indtastes og kontrolleres ved hver brug af programmet. Krypterede data Ekstrakt kodeord IV Når applikationen skal oprette LDAP-forbindelsen, udføres det som vist ved metoden til højre. De krypterede data indlæses fra indstillings-filen og IV tilføres direkte fra program-koden. Ved brug af AES standarden kan kodeordet nu dekrypteres på samme måde som ved krypteringen. Brugerens kodeord kan nu benyttes af applikationen, ganske som hvis brugeren havde indtastet det i klar-tekst. Brugerens kodeord Figur Dekryptering af kodeord Hvis kodeordet er forkert indtastet, eller brugeren har ændret kodeordet i AD et uden tilsvarende at ændre det i applikationen, vil der blive vist en fejl-meddelelse om, at forkert brugernavn/kodeord er indtastet. Side 35 af 72

36 6 Implementering I dette afsnit vil jeg gennemgå de mest interessante funktioner, der er blevet implementeret i projektet. Hele kildekoden til EVA applikationen kan findes på den vedlagte CD. Til yderligere belysning af visse dele af implementeringen, vil der i det nedenstående blive suppleret med dele af koden sammen med en forklarende tekst, primært for at lette forståelsen af funktionaliteten. Implementeringen af applikationen EVA er foretaget i Microsoft Visual Studio 2008 ved hjælp af programmeringssproget C#. Applikationens filstruktur, der indeholder alle de implementerede klasser og tilhørende funktioner, er opdelt i den tidligere nævnte 3-lagsstruktur. Dette giver et bedre overblik og bedre kontrol af klasserne og deres interaktion med hinanden. 6.1 GUI (Graphical User Interface) Den grafiske brugerflade, der er implementeret i projektet, består af forskellige visuelle elementer fra Microsoft Visual Studio 2008 s standard komponenter. Der er oprettet visuelle formularer, der skal benyttes ved forskellige funktionaliteter i EVA applikationen. Der findes f.eks. en formular, der benyttes ved oprettelse af nye objekter, hvor der er behov for at brugeren kan indtaste nogle påkrævede værdier. De elementer, der benyttes i hoved-formularen, er: Top-menu med dropdown-menuer, der fungerer som knapper (menustriptop). Træstruktur, hvor OU-elementer vises ved tilsluttet directory (treeviewbrowser). Liste, hvor alle CN (brugere, grupper, PCere mm.) elementer vises ved tilsluttet directory (listviewobjects). Liste, hvor alle replikeringsobjekter fremgår (listboxreplicationitems). Alle elementer, der kan findes på formularer indeholdende GUI, er implementeret med drag-n-drop værktøjet i Microsoft Visual Studio Formularerne benytter sig af events til at interagere med brugeren. Events er f.eks. tastetryk, tryk på knapper eller valg af liste-elementer. Når der i applikationen gøres brug af GUI, vil der ved fejl fremkomme en dialogboks med en beskrivende fejlmeddelelse, så brugeren på en enkel måde kan søge og rette årsagen til fejlen. Alle standard fejlmeddelelser fremkommer på det sprog, der benyttes af operativsystemet, idet fejlmeddelelserne hentes direkte fra programstacken, der benyttes af operativsystemet for at håndtere og køre applikationen, mens applikationsspecifikke fejlmeddelelser altid vises på engelsk. Derfor kan der på et dansk operativsystem fremkomme både danske og engelske fejlmeddelelser, afhængig af, hvilken type fejl, der er tale om. Fejlmeddelelsen vil også blive skrevet i logfilen på det pågældende sprog. Selve applikationen er udelukkende implementeret på engelsk. Side 36 af 72

37 6.2 LDAP-kald Der er forskellige muligheder for at benytte LDAP-kald fra Windows-miljøer og C#. Med udgivelsen af.net v. 2.0 blev der frigivet den funktionalitet, der kendes som System.DirectoryServices (fremover omtalt som SDS). SDS er et API 6, der er udviklet for at forenkle brugen af LDAP-kald i.net applikationer. Før frigivelsen af SDS, blev ADSI 7 API et ofte benyttet til kommunikation over LDAP. Dog skal det bemærkes, at SDS bygger på ADSI API et, og derfor kan benytte alle funktioner derfra. For at håndteringen af LDAP forbindelserne bliver udført så optimalt som muligt, benyttes System.DirectoryServices (SDS) i denne implementering. For at kunne benytte SDS i C# kræver det, at API et inkluderes i projektet i Microsoft Visual Studio 2008 samt, at der i klasserne, der benytter API et, inkluderes nedenstående linje i toppen af klassen. using System.DirectoryServices; For at håndtere LDAP forbindelserne så pænt som muligt i koden, bør forbindelserne altid være omkranset af en USING -sætning. Dette bevirker, at forbindelserne og objekterne omkranset af USING bliver ordentligt lukket og fjernet fra hukommelsen efter endt brug. SDS indeholder mange forskellige klasser og funktioner, der kan gøre LDAP kommunikationen lettere end ved direkte brug af ADSI. De to klasser, der er mest brugt i denne implementering er: DirectoryEntry den primære klasse, der benyttes til læsning og skrivning af attributter vedrørende LDAPobjekter. DirectoryEntry baserer sig på ADSI s IAD interface, og benytter funktionerne PropertyCollection og PropertyValueCollection til at hente og læse attributter. DirectorySearcher denne klasse giver forskellige muligheder for at søge efter objekter eller attributter. DirectorySearcher benytter et DirectoryEntry objekt til at definere startpunktet og forbindelsen for søgningen. Denne klasse benytter SearchResultCollection til at læse de fundne objekter. For at kunne benytte SDS skal der oprettes en ny instans af den klasse i SDS, der kaldes DirectoryEntry. Sikkerheden angives ved oprettelsen af hver enkelt af LDAP-forbindelserne. I dette projekt benyttes der normalt sikkerheden af typen AuthenticationTypes.Secure, da dette sikrer at brugeroplysningerne ikke sendes som læsbar-tekst, når de sendes over netværket. AuthenticationTypes.Secure benytter SSPI 8 validering, der benytter Windows Negotiate Protocol. Dette betyder, at der vælges imellem Kerberos og NTLM validering afhængigt af det directory, der forbindes til. 6.3 Browse objekter (træstruktur og objektliste) Der er to felter, der benyttes til at browse objekter fra det tilsluttede directory, nemlig treeviewbrowser og listviewobjects. TreeViewBrowser er en træstruktur, der bl.a. kendes fra Windows Stifinder. Træstrukturen er 6 Application Programming Interface 7 Active Directory Service Interfaces; API til brug i Visual Basic, C, C#, C++ osv. Ældre API end SDS. 8 Windows Security Support Provider Interface Side 37 af 72

38 implementeret til kun at indeholde OrganizationalUnits (OU er), da disse skaber den ønskede mappe/undermappe struktur. TreeViewBrowser er implementeret til at fungere på events. Der er fire events, der benyttes til opdatering af elementerne: adtoolstripmenuitem_click() (Connect-knap til AD / ADAM / ADAM-Test) treeviewbrowser_beforeexpand() (Før visning af understruktur (tryk på +)) treeviewbrowser_nodemouseclick() (Ved musetryk på et element) treeviewbrowser_afterselect() (Efter et element (OU) bliver valgt) Disse fire funktioner vil blive gennemgået i detaljer i det nedenstående. adtoolstripmenuitem_click(): Denne funktion udføres, når der tilsluttes til et valgt directory. Fra start fjernes alle tidligere noder (elementer) fra træstrukturen. Herefter oprettes en instans af LDAP.TreeView ved brug af følgende kode, og opdateringen af træstrukturen startes ved brug af funktionen ldaptv.buildldaptree(). LDAP.TreeView ldaptv = new LDAP.TreeView(); ldaptv.buildldaptree(treeviewbrowser); Hele klassen LDAP.TreeView er oprettet til kun at opdatere elementer i træstrukturen. Når der oprettes en ny instans af LDAP.TreeView, oprettes der automatisk en ny instans af Application_code.Connection(). Connection-klassen holder styr på, hvilket directory der skal forbindes til, samt detaljer omkring brugernavn, kodeord, import-folder osv. Disse oplysninger bruges til at oprette forbindelsen via. LDAP. Når forbindelsen er oprettet, og der er kontrolleret hvorvidt den fungerer efter hensigten, oprettes den øverste node i træstrukturen. Denne oprettes og opkaldes efter domænet, der er tilsluttet til. Denne node kendes også som forest -noden, da denne indeholder alle underliggende noder. Se nedenstående kode: using (DirectoryEntry DE = new DirectoryEntry(conn.getDomain(), conn.get )) { // Force the Connection DE.RefreshCache(); // Add the Root-Node and the corresponding Images TopNode = TV.Nodes.Add(conn.getDomain()); TopNode.ImageIndex = li.getldapimageindex("forest"); TopNode.SelectedImageIndex = li.getldapimageindex("forest"); TopNode.Tag = DE; // Apply the 'Top-Level' list of Domains AddAllDomains(); } // Expand the Root-Node TopNode.Expand(); Side 38 af 72

39 Der kontrolleres nu, hvilket domæne, der er forbundet til. Dette udføres af funktionen AddAllDomains(). Denne funktion kontrollerer, hvorvidt det er et Active Directory eller et ADAM, der forbindes til. Hvis det er et AD og ikke et ADAM, er det muligt at benytte en attribut i AD et til at finde andre tilsluttede domæner. Attributten er benævnt namingcontexts. Hvis der tilsluttes til et ADAM, kontrolleres der ikke for parallelle domæner. Der tilføjes én eller flere noder afhængigt af evt. parallelle domæner. Tilsidst opdateres træstrukturen på GUI en ved at sende alle de fundne objekter tilbage til formularen. treeviewbrowser_beforeexpand(): Denne event håndterer, at hentning af underelementer udføres inden træstrukturen udvides til at skulle vise de hentede underelementer. Klassen LDAP.TreeView kaldes derefter igen, og denne gang benyttes funktionen LDAP.treeViewBrowser_BeforeExpand(). Der kontrolleres om noden har nogle undernoder, da der ved alle OU-elementer tilføjes en dummy-node, så der er mulighed for at kunne udvide og hente eventuelle undernoder. Hvis der kun findes en enkelt undernode med navnet ***DUMMY-NODE***, fjernes denne. Der tilsluttes til det pågældende directory og alle underelementer til den valgte node hentes. Dette inkluderer både OU s, groups, users, mm. Det er dog kun OU erne, der tilføjes træstrukturen. Ved kun at hente et niveau i træstrukturen af gangen, er hastigheden på opdateringen af strukturen langt hurtigere, end hvis hele strukturen skal dannes ved tilslutning til directoriet. Test på netværket har vist, at det tager omkring 1-2 minutter at hente hele strukturen, hvorimod et enkelt niveau kan hentes på ca. 1-3 sekunder. Hastigheden er en væsentlig faktor for brugeroplevelsen med applikationen. treeviewbrowser_nodemouseclick(): Denne event opstår, når der klikkes på et node-element i træstrukturen. Først kontrolleres hvilken museknap, der trykkes på (højre / venstre). Ved venstreklik skal der ikke ske noget, mens der ved højreklik kontrolleres, hvilket element der er klikket på. Der skelnes mellem domænenoderne, som er i niveau to (lige under forest) og OU-elementerne i niveau 3 i træstrukturen. Grunden til, at der skelnes mellem de forskellige elementer er, at der skal vises forskellige menuer afhængigt af objektet, der klikkes på. Ved klik på andre elementer end de ovenfor nævnte skal der hverken ske noget ved venstre eller højreklik. Menuerne er objekt-specifikke og indeholder funktioner, der kan benyttes sammen med det givne objekt. Dette kan f.eks. være flyt objekt, slet objekt, egenskaber, mv. treeviewbrowser_afterselect(): AfterSelect-event eksekveres, når en OU vælges. Dette håndterer opdateringen af listviewobjects vinduet. Først fjernes elementer, der allerede optræder i listen, og der instantieres en ny instans af LDAP.ListView. Denne klasse håndterer på samme måde som LDAP.TreeView opdateringen af de objekter, der skal vises i ListView. Ved instantieringen af LDAP.ListView klassen oprettes en ny instans af Connection-klassen, der er nævnt ovenstående. Denne klasse håndterer forbindelsesindstillingerne for LDAP-forbindelsen. For at finde alle underobjekter til den valgte OU, tilsluttes først til denne ved brug af DistinguishedName-attributten. Herefter benyttes DirectorySearcher til at finde alle objekter, der optræder i første underniveau til den valgte OU. Der oprettes fire ArrayLists, der benyttes til at udføre en sortering af elementerne. Disse lister er oprettet til følgende elementer: Groups, Users, Computers og Others. Da søgningen ikke tager højde for at sortere elementerne efter type, kontrolleres hver af de fundne elementer og tilføjes til den tilhørende array-liste. Dette gør, at hver liste nemt kan tilføjes listviewobjects-listen, og at elementerne derfor allerede er sorteret efter type. Dette gælder selvfølgelig kun, hvis der optræder forskellige typer af elementer i den givne OU. Side 39 af 72

40 Hastigheden er grunden til, at DirectorySearcher benyttes til at finde underobjekterne i en enkelt OU. Diverse tests har bekræftet, at overførslen af elementer går meget hurtigere ved at benytte DirectorySearcher end ved at finde og hente alle underelementerne ved brug af DirectoryEntrys attribut Childs. Grunden til dette er, at ved brug af Childs -attributten skal der oprettes en specifik forbindelse til hvert enkelt objekt, hvilket ikke er nødvendigt med DirectorySearcher. Ved at benytte DirectorySearcher kan det yderligere specificeres, hvilke attributter der skal hentes ved overførslen, i stedet for at hente alle attributter tilhørende objektet. Ved ovenstående søgning hentes fire attributter på de fundne objekter: samaccountname, distinguishedname, objectcategory og description. DirectorySearcher DS = new DirectorySearcher(DE); // Set the Filter Option for a Group DS.Filter = "(objectcategory=*)"; // Set the Properties to Load for a Group DS.PropertiesToLoad.Add("sAMAccountName"); DS.PropertiesToLoad.Add("distinguishedname"); DS.PropertiesToLoad.Add("objectCategory"); DS.PropertiesToLoad.Add("description"); // Set the rest of the Search Options DS.PageSize = 1000; DS.SearchScope = SearchScope.OneLevel; DS.ServerPageTimeLimit = TimeSpan.FromSeconds(2); Attributten distinguishedname tilknyttes hvert element på listviewobjects-listen, da denne tekst-streng indeholder den direkte LDAP-sti til objektet. Distinguishedname attributten for hvert liste-element benyttes blandt andet, når der skal vises Egenskaber (kan vises ved at dobbeltklikke på elementet, eller vælge Egenskaber fra højrekliksmenuen) for et valgt liste-element. 6.4 Opsætning og sikkerhed Brugeren gøres opmærksom på, at indstillingerne for applikationen skal opsættes ved første programkørsel. Uden tilstrækkelig opsætningen af applikationen, kan der ikke tilsluttes korrekt til de valgte directories, og der vil opstå fejlmeddelelser der vises til brugeren. Opsætningen af applikationen kan foretages igennem den oprettede formular GUI.FormSettings. Denne indeholder felter, hvori der kan indtastes de nødvendige værdier for at applikationen kan køre korrekt. Formularen består af fire faneblade. AD Connection Dette faneblad skal indeholde alle de forbindelsesindstillinger der er nødvendige for tilslutning til AD et. Dette inkluderer Path, Username, Password og Connection type. Alle felterne er defineret som almindelige tekstfelter, hvor brugeren kan indtaste alle former for tegn. Feltet Connection type bruges til at angive, hvilken form for sikkerhed der skal benyttes til valideringen af LDAP-forbindelsen. Standarden for forbindelserne til AD og ADAM er i dette projekt AuthenticationTypes.Secure, som beskrevet tidligere. ADAM Production Dette faneblad indeholder, som AD Connection, specifikke egenskaber for forbindelsen til ADAM produktionsmiljøet. Af andre tekstfelter fra det ovenstående faneblad, kan nævnes User class type, Import-OU og Disabled-OU. Værdien User class type skal indeholde det type Side 40 af 72

41 objekt, der ønskes, at bruger-objekter bliver synkroniseret til. Værdien vil normalt være UserProxyFull, som er nævnt tidligere. ADAM Test Samme indstillinger som ADAM Produktion, men er beregnet til at indeholde indstillingerne for test-miljøet. Replication Dette faneblad indeholder en check-liste, hvor alle de objekt-attributter, der ønskes replikeret fra AD til ADAM, kan vælges. Denne liste er dannet ud fra en XML-fil, der kan findes under installationsbiblioteket til EVA. Den er implementeret manuelt, og der er ikke pt. lavet en grafisk-mulighed for at tilføje eller fjerne elementer. Dette kan dog klares manuelt ved at redigere i filen. På fanebladet findes yderligere stien til den XML-fil, der indeholder replikeringsobjekterne samt stien til Log-filen. I formularen GUI.FormSettings gøres brug af eventet FormSettings_Load(), der automatisk udføres, når formularen startes og vises for brugeren. Her indlæses alle indstillingerne, og de gemmes i tekstfelterne på formularen. Dette bevirker, at brugeren umiddelbart kan se og dermed ændre i værdierne. Hvis et kodeord er sat, bliver det vist som ****** (6 stjerner), også selv om det er krypteret. Hvis formularen lukkes ved brug af OK -knappen, kontrolleres og gemmes alle de værdier, der er ændret. Hvis formularen lukkes på anden vis, gemmes ændringer ikke. Til at gemme alle indtastede indstillinger, og for at gøre dem unikke for hver enkelt bruger, benyttes Settings filen i projektets Properties namespace. Dette namespace fremkom med.net Framework 2.0, og kan benyttes til at gemme både bruger- og programindstillinger mellem sessionerne af en applikation. Ved at benytte denne funktion minimeres administrationen af indstillingerne, da applikationen selv håndterer data. Der er fire værdier, der skal angives for hver enkelt indstilling, som skal gemmes af programmet. Name navnet på indstillingen. Type værdi-typen, der skal gemmes (string, int, osv.) Scope skal det være en bruger- eller en programindstilling (User, Application) Value værdien af den pågældende indstilling. Ovenstående værdier kan også ses på figur 6.4.1, hvor der er medtaget nogle værdier af indstillingerne. Figur Udsnit af indstillingerne Side 41 af 72

42 Det er nemt at indlæse data fra Settings filen, og nedenfor vises, hvordan en indstilling indlæses. I dette tilfælde læses værdien af indstillingsfeltet med navnet ADConnType. Det kan ses af ovenstående figur 6.4.1, at denne værdi vil være teksten Secure. Denne tekst indlæses og vises i tekstfeltet tadconnectiontype på formularen. tadconnectiontype.text = EVA.Properties.Settings.Default.ADConnType; Værdier kan gemmes i Settings-filen på samme måde, som der kan læses fra den. Nedenfor vises, hvordan der først udføres en kontrol af, hvorvidt værdien er blevet ændret, og hvis dette er tilfældet, gemmes den nye værdi i det angivne felt i Settings-filen. if (!tadconnectiontype.text.equals(eva.properties.settings.default.adconntype)) { EVA.Properties.Settings.Default.ADConnType = tadconnectiontype.text; } Sikkerheden, der benyttes til at kryptere kodeord, er i designet beskrevet i detaljer. Da det på nuværende tidspunkt vil være alt for tidskrævende for undertegnede at implementere sikkerheden i C# som designet, har jeg valgt at benytte en sikkerheds-klasse fundet på internettet. Det er sikret, at kravene stemmer overens med kravene i designet. Da det ikke er undertegnede, der har implementeret denne klasse, vil den ikke blive gennemgået yderligere,. Det er muligt at finde yderligere detaljer om klassen på internettet ved at benytte hyperlinket fra litteraturlisten. 6.5 XML Der er pt. to steder i applikationen, hvor XML benyttes, nemlig: replikeringslisten og replikerings-attribut-listen. For at applikationen kan håndtere XML, er klassen Application_code.XMLManager implementeret. Ved brug af denne klasse, kan der både læses og skrives til XML-filerne. Ved instantiering af klassen kontrolleres den angivne sti for filen for, om hvorvidt filen eksisterer. Hvis den ikke eksisterer, oprettes der en tom XML fil. Det er efterfølgende muligt både at læse og skrive indholdet af den angivne fil ved brug af: XmlTextWriter XTW; XmlTextReader XTR; Funktionen getreplicationlist() benyttes til at læse XML filen, der indeholder listen med objekter, der skal replikeres fra AD til ADAM. Denne funktion returnerer alle objekterne i en ArrayList, der nemt kan bearbejdes fra andre klasser i applikationen. // Create an ArrayList containing the Replication Elements of the XMLFile ArrayList AL = new ArrayList(); XTR = new XmlTextReader(sXMLFilePath); while (XTR.Read()) { // Read the Value of the Line and Add it to the ArrayList if (XTR.Value.Contains("user") XTR.Value.Contains("CN") ) { AL.Add(XTR.Value); // Go to next Attribute in the XMLFile XTR.MoveToNextAttribute(); Side 42 af 72

43 } } return AL; Som det ses af ovenstående eksempel, loopes der igennem hele XML filen med XTR.Read() funktionen. Denne funktion er en funktion sat til rådighed af XMLTextReader klassen, der er instantieret. XTR.Read() læser én linje i XML filen af gangen, indtil der ikke er flere linjer. I hver linje kontrolleres så hvilket element, der er tale om, og hvis det er et replikeringselement, tilføjes dette til Array-listen, der sidst i funktionen afleverer alle elementerne. Funktionen getattributelist() benyttes ved indlæsning af, hvilke attributter der skal replikeres for objekterne ved replikering mellem AD og ADAM. Denne funktion fungerer umiddelbart på samme måde som ovenstående funktion. Forskellen består i, at getattributelist() ikke afleverer en ArrayList, men en Dictionary. Dictionary<string, bool> AL = new Dictionary<string, bool>(); En Dictionary udmærker sig ved at være en hash-liste bestående af en key og en value. Dette betyder, at en key kun kan optræde én gang. I dette tilfælde er attribut-navnet (string) valgt som key. Den value, der yderligere indlæses, er af typen bool, og værdien er true eller false afhængigt af, hvorvidt attributten skal være krydset af under GUI.FormSettings. Fordelen ved at benytte en dictionary når der skal repræsenteres både en key og en value, er hastigheden. Da dictionary-listen er implementeret som en hash-tabel, er hastigheden ved at finde et element i listen ud fra en key, tæt på 0(1). 6.6 Automatisk replikering Der er implementeret to muligheder for replikering af brugere fra AD til ADAM. Ved brug af GUI eller ved brug af en kommando-linje til automatisk replikering. Det er sidstnævnte, der omtales i dette implementeringsafsnit. Implementeringen af replikering uden GUI er foretaget ved at opfange, hvorvidt brugeren ønsker at starte replikeringen direkte og derved undlade at starte GUI en. For at starte en replikering direkte, skal applikationen startes med de tilhørende specifikke argumenter. Der skal i alt bruges 4 argumenter. Første argument skal være teksten replicate. Næste argument er stien på den XML fil der indeholder objekterne, der skal replikeres. Dette argument skal ende på.xml. Tredje argument skal være tegnene ->. Fjerde argument skal være ét af de to ord production eller test for at angive, hvilken ADAM instans der replikeres til (Produktions- eller Testmiljøet). Den udfyldte kommandolinie for at replikere objekterne fra en XML fil til ADAM test-miljøet kan ses nedenstående: EVA.exe "replicate" "C:\program files\eva\xml\replicationlist.xml" "->" "test" Herefter oprettes en ny instans af klassen Application_code.Replication. Denne instans kontrollerer hvorvidt GUI en er startet. Der oprettes en ny tråd, der håndterer selve replikeringen af objekter. Hvis der replikeres uden brug af GUI, ventes der på, at replikeringstråden bliver færdig og programmet afsluttes da. Ved replikering med GUI, returneres brugeren til applikationen, men kan se en grafisk fremstilling af, hvor langt replikeringsprocessen er. Replikeringstråden vil da køre i baggrunden. Tråden oprettes som vist nedenstående. Thread ReplicateThread = new Thread(new ThreadStart(startReplication)); Side 43 af 72

44 ReplicateThread.IsBackground = true; ReplicateThread.Start(); if (runningwithoutgui) ReplicateThread.Join(); Når den nye tråd er oprettet og kører, oprettes der en ny instans af LDAP forbindelsen til AD og det valgte ADAM. Derved sørges for, at forbindelserne er oprettet og klar til brug ved replikeringen. XML filen, der blev sendt til applikationen som argument, kontrolleres og prøves læst. Hvis der returneres en liste, der indeholder objekter fra klassen, der håndterer XML, kontrolleres listen for hvilke objekter, der er indeholdt i den. Hvis der findes hele OrganizationalUnits, der skal replikeres, startes en søgning efter underobjekter til disse OU er. Dette håndteres af funktionen getousubitems(). Denne funktion benytter LDAP.Search klassen til at finde alle elementer af typen Users. Hver af disse typer returneres som en dictionary indeholdende objektets objektsid (unik objekt Key) og distinguishedname. Når alle brugerne er fundet, og dermed udgør en liste af objekter uden at nogle OU er indgår, benyttes funktionen LDAP.buildOUStructure() på alle elementerne. Denne funktion opbygger den OU struktur, som det endelige objekt skal tilhøre. Dette gøres ved at opdele distinguishedname attributten i OU er og efterfølgende loope igennem ADAM for at kontrollere og oprette de OU er, der ikke findes. Efter dette startes den egentlige replikering af de fundne objekter. Dette håndteres af funktionen replicate(). Denne funktion looper igennem alle de tidligere fundne objekter. Der tilsluttes til ADAM og søges efter det aktuelle objekts objectsid. Hvis det findes, skal objektet opdateres, ellers skal der oprettes et nyt objekt med de aktuelle attributter, der skal overføres fra AD et. Alle attributter fra et objekt overføres ved brug af klassen LDAP.replication. Ved replikering af et objekt tilsluttes der først til objektet i AD et. Herefter tilsluttes til objektet (eller til den nye OU parent, hvis det er et nyt objekt) i ADAM. Der loopes derefter igennem alle objekt attributter i AD et og kontrolleres, hvorvidt den aktuelle attribut er sat til at replikere i Settings. Hvis den er sat til at replikere, gemmes AD attributten i ADAM attributten for objektet. Når alle attributter for objektet er overført, benyttes nedenstående SDS funktion til at overføre alle ændringer til directoriet. // Send the Changes to ADAM DirectoryEntryObject.CommitChanges(); Ovenstående fortsættes indtil alle objekter er opdateret i ADAM. Herefter afsluttes den ekstra oprettede tråd, og applikationen afsluttes. Når der replikeres uden GUI, er det ikke muligt at vise eventuelle fejlmeddelelser til brugerne, og i stedet benyttes log filen til håndtering af dette. Alle meddelelser af værdi bliver skrevet til log filen. Dette inkluderer alle fejlmeddelelser, men også almindelige beskeder som: Replication started by DE-PROD\lasfr: replicate file.xml -> test Baseret på log filen er det altid muligt at se, hvad der er foregået på den enkelte maskine. Side 44 af 72

45 6.7 Søgning Den implementerede søgefunktion kan startes via GUI.FormMain s top-menu Functions -> Search. Denne funktion muliggør søgninger i det forbundne directory. Der søges i alle de almindelige tekst attributter. Der er implementeret en speciel formular til brug ved søgninger, GUI.FormSearch. Denne formular kan ses på figur Det er muligt at søge efter objekttyperne Users, Groups og Organizational Units. Objekttyperne vælges i den implementerede drop-down -liste med ovenstående foruddefinerede værdier. Søgningen starter, når eventet bsearch_click() optræder. Denne event startes ved tryk på knappen Search. Der kontrolleres først, hvorvidt der er indtastet en søgetekst i tekstfeltet. Efterfølgende er der implementeret en switch-case, der baserer søgningen på tidligere omtalte objekttyper. Søgningen instantierer herefter LDAP.Search klassen, der udfører selve søgningen i directoriet. Funktionen, der kaldes i LDAP.Search klassen, er navngivet findobjectallattributes(). Funktionen benytter LDAP-søgefunktionen Figur GUI til søgning DirectorySearcher til at starte en søgning i directoriet. Der søges efter den indtastede tekststreng i attributter som bl.a. displayname, mail, description og telephonenumber. Hvis den indtastede tekststreng er indeholdt i nogle af de attributter, der gennemsøges, tilføjes objektets distinguishedname samt attributten cn (comonname) til en dictionary. Alle fundne elementer sendes via dictionary en tilbage til formularen, når søgningen er afsluttet. Dictionary en loopes herefter igennem for resultaterne og tilføjes det visuelle listview-element på formularen. Muligheden for at dobbeltklikke på et element i listen for at se egenskaber for elementet er også implementeret. Side 45 af 72

46 7 Test For at kunne udføre testen, har det været nødvendigt at få adgang til et Active Directory og en ADAM instans. Grundet den sideløbende implementering af PPW er der i dette tilfælde oprettet en ADAM instans der kan benyttes til formålet. Al implementering i DONG Energy foregår i lukkede test-miljøer, så det sikres at produktionsmiljøet ikke berøres af eventuelle fejl. Under udførslen af nedenstående test har undertegnede fået lov til at virtualisere en domain controller (DC) der indeholder et komplet AD. Ved at virtualisere DC en, kan denne flyttes til test miljøet og derved sikres det, at der ikke skabes fejl eller mangler hvis der opstår problemer. DC en der er blevet virtualiseret er fra det tidligere selskab Energi E2 (benytter domænet ka.local). Det er af største vigtighed, at systemet fungerer efter hensigten, og at der på ingen måde kan mistes data grundet fejl i applikationen. Dette er grundet, at det i produktionsmiljøet hos DONG Energy er hoved-brugerdatabasen programmet skal ind og kopiere, og kritiske data herfra må ikke mistes eller blive fejlbehæftede. Der benyttes to forskellige slags test ved undersøgelse af applikationen: Whitebox-test Denne slags test kan benyttes til at teste dele applikationen uafhængigt af hele programsammenhængen. Denne test kan hjælpe med at afsløre små problemer der hurtigt bliver store i den samlede sammenhæng. Det er vigtigt, at der testes på en så bred måde som muligt, og af den grund afprøves både valide og invalide inputs. Denne form for test er også kendt under navnet unittest. Blackbox-test Denne test benyttes til at kontrollere at kravene fra de tidligere oprettede use cases opfyldes. Det skal sikres, at kravene der er stillet til systemet er opfyldt, og der følges det flow der er beskrevet i de oprettede use cases. Denne test tager ikke højde for hvordan data bliver behandlet under programkørslen, så længe output er korrekt. Alle tests er kun vedlagt i nyeste version. Der har igennem hele projektforløbet være udført tests af de forskellige klasser, og de fejl der har vist sig undervejs er blevet rettet. Efter rettelserne af tidligere fejl, er samme tests er blevet udført igen på de pågældende klasser. Der benyttes nedenstående skema til alle tests, da dette giver læseren en ensformig indgangsvinkel til testene. Hvis der findes fejl eller mangler bliver dette dokumenteret i feltet konklusion for den pågældende test. Overskrift: Test nummer: Udført af: Testformål: Testtype: Funktionalitet testet: Forventet handling: Faktisk handling: Konklusion: Side 46 af 72

47 7.1 Whitebox Test Overskrift: Forbindelse til directory Test nummer: #001 Testtype: Whitebox test Udført af: Lasse Frederiksen Testformål: At påvise, at klassen Application_code.connection fungerer i henhold til design. Funktionalitet testet: Forventet resultat: Faktisk resultat: Modtagelse af destinationen, Forbindelsesdestinationen til Som forventet. directory, fra indstillingerne ved brug af connection klassen. øverste lag i directoriet modtages. Modtagelse af destination, ved forbindelse til specifik destination i directoriet. Modtagelse af korrekt brugernavn ved brug af connection klassen. Modtagelse af korrekt kodeord, ved brug af connection klassen. Modtagelse af forbindelsessikkerhed, ved brug af connection klassen. Konklusion: Forbindelsesdestinationen til det specifikke objekt i directoriet modtages. Brugernavnet til det specifikke directory modtages. Kodeordet til det specifikke directory modtages i læsbar tekst. Forbindelsessikkerheden vælges korrekt ud fra indstillingerne. Alle ovenstående tests er udført og fundet godkendt. Klassen Application_Code.connection fungerer i henhold til designet. Som forventet. Som forventet. Som forventet. Som forventet. Overskrift: Browse objekter Test nummer: #002 Testtype: Whitebox test Udført af: Lasse Frederiksen Testformål: At påvise, at klasserne LDAP.TreeView og LDAP.ListView fungerer i henhold til design. Funktionalitet testet: Forventet resultat: Faktisk resultat: Læsning af underobjekter (OUs) Alle OU er, der findes i det Som forventet til en specifik OU. underliggende niveau, læses fra directoriet. - Godkendt Læsning af underobjekter (not OUs) til en specifik OU. Konklusion: godkendt. Alle objekter, der ikke er OUs, hentes fra den valgte OU i directoriet. Som forventet - Godkendt De ovenstående to klasser, der håndterer opdateringen af de visuelle elementer, er Overskrift: Oprette, slette, flytte og omdøbe objekter Test nummer: #003 Testtype: Whitebox test Udført af: Lasse Frederiksen Testformål: At påvise, at klassen LDAP.ObjectChanges fungerer i henhold til design. Funktionalitet testet: Forventet resultat: Faktisk resultat: Oprettelse af et objekt ud fra Objektet oprettes som den valgte Som forventet. Side 47 af 72

48 angivet navn, placering og type, på den angivne placering, objekttype. med det angivne navn. Oprettelse af et objekt med navn, En fejlmeddelelse sendes til den Som forventet. objekttype og ugyldig placering. bagvedliggende GUI. Oprettelse af et objekt med En fejlmeddelelse sendes til den Som forventet. placering, objekttype og ugyldigt bagvedliggende GUI. navn. Sletning af et objekt ud fra Objektet slettes fra directoriet. Som forventet. objektets distinguishedname attribut. Sletning af et objekt hvor En fejlmeddelelse sendes til den Som forventet. distinguishedname er angivet bagvedliggende GUI. forkert. Flytning af et objekt, hvor Objektet flyttes til den nye Som forventet. objektet er angivet ved placering i directoriet. distinguishedname og den nye placering (distinguishedname). Flytning af et objekt, hvor En fejlmeddelelse sendes til den Som forventet. objektet er angivet ved bagvedliggende GUI. distinguishedname og den nye placering (distinguishedname) er ugyldig. Flytning af et objekt, hvor En fejlmeddelelse sendes til den Som forventet. objektet er angivet ved et bagvedliggende GUI. ugyldigt distinguishedname og den nye placering (distinguishedname). Objekt omdøbes, hvor objektet er Objektet omdøbes til det nye Som forventet. angivet ved distinguishedname navn. og det nye navn. Objektet omdøbes, hvor objektet En fejlmeddelelse sendes til den Som forventet. er angivet ved et ugyldigt bagvedliggende GUI. distinguishedname og det nye navn. Objektet omdøbes, hvor objektet En fejlmeddelelse sendes til den Som forventet. er angivet ved distinguishedname bagvedliggende GUI. og et ugyldigt nyt navn. Konklusion: Denne klasse er godkendt. Alle fejlmeddelelser håndteres korrekt, og sendes tilbage til den kaldende funktion/klasse. Overskrift: Replikering af objekter Test nummer: #004 Testtype: Whitebox test Udført af: Lasse Frederiksen Testformål: At påvise, at klassen LDAP.Replication fungerer i henhold til design. Funktionalitet testet: Forventet resultat: Faktisk resultat: Replikering af et bruger-objekt af Objektet oprettes i directoriet. Som forventet. typen User. Dog bliver objectsid attributten automatisk sat af directoriet. Replikering af et bruger-objekt af typen userproxyfull. Objektet oprettes i directoriet. Attributten objectsid bliver sat Som forventet. Side 48 af 72

49 Replikering af et bruger-objekt af typen userproxyfull, når ADAM ikke direkte kan kontakte AD. Oprettelse af en OU-struktur, givet ved en ArrayListe. Replikering af et gruppe-objekt med tilhørende medlemmer. igennem applikationen. En fejlmeddelelse sendes til den kaldende instans. Strukturen oprettes korrekt. Gruppen oprettes og alle eksisterende brugere, der bør tilknyttes gruppen, bliver det automatisk. Som forventet. Dog er fejlmeddelelsen Serveren vil ikke udføre anmodningen. ikke hensigtsmæssig i denne sammenhæng. Som forventet. Denne funktion er ikke implementeret endnu. - Afvist. Konklusion: Denne klasse er overordnet set godkendt. Der er dog endnu ikke implementeret muligheden for at replikere gruppeobjekter, da LDAP-skemaet ikke understøtter, at objectsid attributten sættes manuelt. Der skal derfor oprettes et nyt objekt i LDAP-skemaet, for at der kan replikeres gruppeobjekter. Der er i implementeringen allerede gjort klar til denne udvidelse, som overføres til næste version. Løsningen skal ikke replikere grupper hos DONG Energy. 7.2 Blackbox Test Overskrift: Forbindelse til directory Test nummer: #001 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At undersøge hvorvidt det er muligt at forbinde til et directory, og se hvilke fejl der opstår, hvis forkerte indstillinger er angivet. Funktionalitet testet: Forventet resultat: Faktisk resultat: Forbinde til directory med alle GUI bliver opdateret med en Som forventet. indstillinger korrekt. topnode i træstrukturen, og statusteksten i bunden af applikationen ændres til: Connectet to AD / ADAM. Forbinde til directory, hvor stien ikke er angivet. Forbinde til directory, hvor stien er angivet forkert. Forbinde til directory, hvor brugernavn ikke findes i directoriet. Forbinde til directory, hvor kodeordet er angivet forkert. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med følgende tekst vises: Enten findes det angivne domæne ikke, eller også kunne der ikke oprettes forbindelse til det. En fejlmeddelelse med følgende tekst vises: Enten findes det angivne domæne ikke, eller også kunne der ikke oprettes forbindelse til det. En fejlmeddelelse med følgende tekst vises: Logonfejl: Ukendt brugernavn eller adgangskode. En fejlmeddelelse med følgende tekst vises: Logonfejl: Ukendt brugernavn eller adgangskode. Forbinde til directory, hvor En fejlmeddelelse med En fejlmeddelelse med følgende Side 49 af 72

50 kodeordet er prøvet ændret direkte i brugerens indstillings fil, og den krypterede streng ikke længere opfylder kravene til AES. brugervenlig information vises. tekst vises: Udfyldningen er ugyldig og kan ikke fjernes. - Godkendt Konklusion: Den overordnede test er generelt godkendt, dog bør fejlmeddelelsen for den sidste deltest ændres til noget mere sigende end den nuværende fejlmeddelelse. Dette bør tilrettes i næste udgave af løsningen. Overskrift: Browse objekter Test nummer: #002 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At undersøge om den endelige løsning lever op til den opstillede use case Browse objekter. Funktionalitet testet: Forventet resultat: Faktisk resultat: Udvidelse af alle noder i Alle undernoder til den valgte Som forventet træstrukturen. node vises, i et nyt niveau. - Godkendt Lukning af alle noder i Alle undernoder til den valgte Som forventet træstrukturen. node forsvinder fra - Godkendt træstrukturen. Museklik på alle noder i Alle objekter med placering i den Som forventet. træstrukturen. node (OU) der klikkes på, vises. - Godkendt Konklusion: Denne test er godkendt på alle punkter. Overskrift: Repliker bruger(e) Test nummer: #003 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: Formålet med denne test er, at påvise hvorvidt replikeringen af objekter fra AD til ADAM fungerer. I denne test replikeres der ved brug af løsningens GUI. Funktionalitet testet: Forventet resultat: Faktisk resultat: Replikering af brugerobjekt, hvor Brugerobjektet bliver replikeret Som forventet. alle indstillinger er korrekte. til den valgte ADAM instans (Test/Produktion). Replikering af brugerobjekt, hvor XML-filen ikke er angivet. Replikering af brugerobjekt, hvor XML-filen indeholder fejl (Der er ændret på input manuelt i filen). En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. Allerede ved start af applikationen vises en fejlmeddelelse om, at stien til XML-filen skal angives i indstillingerne. Denne fejl skrives også til log filen. Hvis der alligevel prøves at replikere vises fejlmeddelelsen Der må ikke bruges tomme stinavne.. Der er to mulige udfald af denne test. Filstrukturen er beskadiget, og Side 50 af 72

51 Replikering af brugerobjekt, hvor objektet ikke eksisterer i AD et. Replikering af brugerobjekt, hvor import-folderen ikke er sat. Replikering af brugerobjekt, hvor import-folderen er forkert sat. Replikering af brugerobjekt, hvor XML-attribut filen ikke er sat. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. der findes ingen eller kun nogle objekter til replikering. Der vises ingen fejl. - Afvist. Objektet, der er ændret, findes ikke ved replikeringen, og replikeringsformularen hænger. Formularen venter på, at objektet bliver kopieret fra AD til ADAM, men objektet kan ikke findes i AD. Fejlmeddelelsen Replication completed with errors. vises - Godkendt Som forventet. Fejlmeddelelsen Replication completed with errors. vises Som forventet. Fejlmeddelelsen No import folder has been set. vises. Som forventet. Fejlmeddelelsen Objektet findes ikke på serveren. vises. Som forventet. Fejlmeddelelsen The XML-attributes file path has not been set. vises. Konklusion: Mange af fejlmeddelelserne viser teksten An error occurred, please consult the log file for information. Dette er grundet den ekstra tråd der udfører selve replikeringsprocessen. Hvis de specifikke fejlmeddelelser skulle sendes tilbage til den første tråd, skulle implementeringen håndteres lidt anderledes. Der vises ikke en fejlmeddelelse, hvis der er manuelt ændret i attribut filen, eller hvis filen er korrupt og ikke kan læses. Dog må dette ses som en mindre fejl, der kan vente med at blive rettet til næste version. Testen er overordnet set godkendt. Overskrift: Søg Test nummer: #004 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At undersøge hvorvidt søgefunktionen fungerer i henhold til design. Funktionalitet testet: Forventet resultat: Faktisk resultat: Udføre en søgning efter et userobjekt Det aktuelle objekt findes og Som forventet. der findes i directoriet. vises i listen. Udføre en søgning efter et Det aktuelle objekt findes og Som forventet. gruppe-objekt der findes i vises i listen. directoriet. Udføre en søgning efter et OUobjekt Det aktuelle objekt findes og Som forventet. der findes i directoriet. vises i listen. Udføre en søgning ved brug af Alle objekter, der har attributter Som forventet. Side 51 af 72

52 delelementer fra et kendt objekt. der indeholder matchende tekst, vises i listen. Udføre en søgning ved brug af Ingen objekter findes, og der tilfældige tegn. gives besked til brugeren, når søgningen er afsluttet. Udføre en søgning, når der ikke er forbundet til et directory. Udføre en søgning, og under søgningen trække netstikket ud. Derved går forbindelsen til directoriet tabt. Konklusion: fungerer efter hensigten. En fejlmeddelelse med brugervenlig information vises. En fejlmeddelelse med brugervenlig information vises. Som forventet. Som forventet. Fejlmeddelelsen There is no active connection to a directory. vises. Som forventet. Fejlmeddelelsen Der opstod en lokal fejl. vises. Alle punkter i denne test er godkendt, og det kan derfor konstateres, at søgefunktionen Overskrift: Opret nyt objekt Test nummer: #005 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At bekræfte muligheden for at oprette nye objekter ved brug af løsningen. Funktionalitet testet: Forventet resultat: Faktisk resultat: Oprettelse af OU. Et normalt Den nye OU vises i træstrukturen. Som forventet. navn angives. Oprettelse af OU med tomt navn angivet. En fejlmeddelelse med brugervenlig information vises. Fejlmeddelelsen The new OU needs a name. vises. Oprettelse af OU med diverse tegn, tal og bogstaver i navnet. Hvis navnet overholder tegn der kan indgå i directoriets navne, bliver objektet oprettet og vist i træstrukturen. Som forventet. Oprettelse af Group. Et normalt navn angives. Oprettelse af Group med tomt navn. Oprettelse af Group med diverse tegn, tal og bogstaver i navnet. Hvis navnet indeholder tegn der ikke må indgå i directoriets navne skal der vises en fejlmeddelelse med brugervenlig information. Den nye Group vises i listen over objekter i den pågældende OU. En fejlmeddelelse med brugervenlig information vises. Hvis navnet overholder tegn der kan indgå i directoriets navne, bliver objektet oprettet og vist i listen for den valgte OU. Hvis navnet indeholder tegn der ikke må indgå i directoriets navne, skal der vises en fejlmeddelelse med brugervenlig information. Fejlmeddelelsen Der blev angivet et ugyldigt stinavn til kataloget. vises. Som forventet. Fejlmeddelelsen The new Group needs a name. vises. Som forventet. Fejlmeddelelsen Der blev angivet et ugyldigt stinavn til kataloget. vises. Side 52 af 72

53 Konklusion: Det kan konkluderes, at det er muligt at oprette både OrganizationalUnits såvel som Grupper. Der gøres brug af korrekt fejlhåndtering, der giver brugervenlige beskeder, såfremt de opstår. Denne test er godkendt. Overskrift: Slet objekter Test nummer: #006 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At teste muligheden for at slette objekter i det tilsluttede directory. Funktionalitet testet: Forventet resultat: Faktisk resultat: Sletning af et brugerobjekt. Brugerobjektet slettes fra Som forventet. directoriet og alle tilhørsforhold fjernes fra grupper osv. Sletning af en gruppe. Sletning af en OU med tilhørende underobjekter Gruppeobjektet slettes fra directoriet og alle tilhørsforholdene til objektet fjernes. Det valgte OU objekt slettes sammen med alle underliggende objekter. Som forventet. Som forventet. Konklusion: Ovenstående test er godkendt. Alle tilhørsforhold håndteres automatisk af directoriet ved sletning af objekter, så det skal der ikke tages højde for i koden. Overskrift: Flyt objekter Test nummer: #007 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At bekræfte muligheden for at flytte objekter internt i et directory. Funktionalitet testet: Forventet resultat: Faktisk resultat: Flytning af et enkelt objekt (ikke Der vælges ny placering fra et Som forventet. OU). popup vindue med en vist træstruktur. Objektet flyttes til den valgte placering, og GUI opdateres. Flytning af flere objekter (ikke OU). Flytning af en enkelt OU. Flytning af flere OUs Der vælges ny placering fra et popup vindue med en vist træstruktur. Objekterne flyttes til den valgte placering, og GUI opdateres. Der vælges ny placering fra et popup vindue med en vist træstruktur. Objektet flyttes til den valgte placering, og er stadigt indeholdende eventuelle underobjekter. Da det ikke er muligt at markere mere end én OU af gangen, er det kun den OU der klikkes på der flyttes. Som forventet. Som forventet. Som forventet. Side 53 af 72

54 Flytning af en OU til samme eller underliggende placering. Konklusion: En fejlmeddelelse med brugervenlig information vises. Denne test er godkendt på alle punkter. Fejlmeddelelsen Serveren vil ikke udføre anmodningen. vises. Overskrift: Omdøb objekt Test nummer: #008 Testtype: Blackbox test Udført af: Lasse Frederiksen Testformål: At bekræfte muligheden for at omdøbe objekter i et directory. Funktionalitet testet: Forventet resultat: Faktisk resultat: Omdøb et objekt (ikke OU). Objektet omdøbes til det nye Som forventet navn, og GUI opdateres. Omdøb et objekt til et eksisterende navn (ikke OU). En fejlmeddelelse med brugervenlig information vises. Fejlmeddelelsen Objektet findes allerede. vises. Omdøb flere objekter (ikke OU). Omdøb en OU. Muligheden om at omdøbe objekterne fremgår ikke længere af menuen. Det er kun muligt at omdøbe et objekt af gangen. Objektet omdøbes til det nye navn, og GUI opdateres. En fejlmeddelelse med brugervenlig information vises. Som forventet. Som forventet. Fejlmeddelelsen Objektet findes allerede. vises. En fejlmeddelelse med Fejlmeddelelsen Der blev brugervenlig information vises. angivet et ugyldigt stinavn til kataloget. vises. Funktionaliteten, ud fra den tilhørende use case, er godkendt. Omdøb en OU til et eksisterende navn. Omdøb et objekt til et navn med tegn der ikke understøttes i navngivningen i directoriet. Konklusion: Side 54 af 72

55 8 Konklusion Det er lykkedes at få implementeret en løsning, der lever op til - og overholder - alle krav stillet i kravspecifikationen. Kunden (DONG Energy) er yderst tilfreds med løsningen og måden, denne er implementeret på. Problemstillingen omkring replikering af brugerobjekter fra et Microsoft Active Directory til et Microsoft Active Directory Application Mode må derfor betegnes som værende løst, idet applikationen EVA, der er udviklet og implementeret til formålet, benytter sig af LDAP-protokollen til læsning og skrivning af directory objekter, både for AD- og ADAM. Ved replikering af brugerobjekter fra AD til ADAM benyttes LDAP-skemaets brugerobjekt userproxyfull. I dette objekt kan - i modsætning til objektet user - alle attributter sættes manuelt, og attributten objectsid kan dermed oprettes med samme værdi som i AD et. Dermed kan attributten objectsid benyttes som nøgle for hvert objekt i replikeringen, når objekterne skal overføres/opdateres. Under de tests, der er udført, er der fundet nogle uhensigtsmæssigheder, der bør rettes ved næste version af løsningen. Dette inkluderer blandt andet et par fejlbeskrivelser, der kunne være mere sigende for brugerne. Løsningen er blevet testet grundigt i test-miljøet hos DONG Energy, og er på nuværende tidspunkt klar til at blive flyttet til produktionsmiljøet. Projektet omkring oprettelse af PPW er stadig ikke afsluttet, og derfor har DONG Energy endnu ikke fået det fulde udbytte af implementeringen af EVA applikationen. 8.1 Udviklingsmuligheder Internt i DONG Energy har der vist sig stor interesse for løsningen omkring replikering af brugerobjekter fra AD til ADAM, som også kunne udnyttes til andre projekter end kun til brug i PPW. Der bør derfor implementeres nogle forbedringer i næste version af løsningen. Af udviklingsmuligheder er der tænkt på følgende: Replikering af OU-egenskaber for at dette kan fungere, skal der vælges, hvilken attribut der skal benyttes som nøgle i LDAP-skemaet. En OU benytter ikke attributten objectsid. Replikering af Gruppe-egenskaber og medlemmer samme problemstilling som ved replikering af OUegenskaber. En SG benytter ikke nødvendigvis attributten objectsid, selvom denne er tilgængelig for objektet. Replikering direkte til en specifik OU-struktur afhængigt af en angivet attribut. Dette kunne f.eks. være replikering direkte til afdelings-ou en. Ved denne udvidelse vil løsningen dog blive specialiseret til lige netop én applikation, og det er ikke tiltænkt i denne implementering. I stedet for at hver installation af EVA benytter sin egen lokale log fil, kunne der oprettes en central log fil, hvortil alle instanserne af løsningen skriver. Ved at oprette en central log fil vil der kunne overvåges og fejlsøges mere præcist. Side 55 af 72

56 Oprettelse af nye brugere, der ikke skal replikeres fra AD et. Der kan muligvis opstå en situation, hvor det skal være muligt at kunne oprette nye brugere, f.eks. hvis ADAM ikke står på et lokalnetværk med et AD tilgængeligt. (Da vil objektet userproxyfull ikke kunne benyttes til brugere; her skal i stedet benyttes objektet user) Søgning efter f.eks. objectsid. Søgefunktionen kunne udvides til at omfatte søgninger efter attributter, der ikke er omfattet af typen klar-tekst. TODO Tests på 1GB net har vist sig at give fejl. Dette kan være grundet de mange forespørgsler der oprettes efter hinanden. AD har muligvis en begrænsning på antal forspørgsler fra samme adresse pr. tidsinterval. TODO Slet settings i implementeringskode! TODO Fjern IV kryptering fra koden inden den brændes på CD! TODO Opret installer til EVA Side 56 af 72

57 9 Bilag 9.1 Use Case Diagram (EVA) Side 57 af 72

58 9.1.1 Use Case Opret nyt objekt (ADAM) Use Case Navn Opret nyt objekt (ADAM) Mål At kunne oprette nye objekter i ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at skrive i ADAM. Brugeren er logget ind i EVA Succes postkondition Objektet eksisterer i ADAM Fejl postkondition Objektet bliver ikke oprettet i ADAM Primær aktør Systemadministrator for ADAM Trigger Et nyt objekt ønskes oprettet i ADAM Normalforløb Trin Aktivitet 1 Der tilsluttes til ADAM 2 Der browses til placeringen hvor objektet ønskes placeret 3 Det angives at et nyt objekt ønskes 4 Der indtastes navn og attributter på det nye objekt 5 Objektet fremkommer på den valgte liste Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 4.a Der opstår en fejl under oprettelsen. En fejl vises til brugeren Prioritet Mellem Performance Max 2 sekunder pr. oprettelse Frekvens Flere gange dagligt System Sekvens Diagram Opret nyt objekt (ADAM) Side 58 af 72

59 9.1.2 Use Case Slet objekt (ADAM) Use Case Navn Slet objekt (ADAM) Mål At kunne slette objekter i ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at skrive i ADAM. Brugeren er logget ind i EVA Succes postkondition Objektet, og alle tilknytninger til dette, slettes i ADAM Fejl postkondition Objektet bliver ikke slettet i ADAM Primær aktør Systemadministrator for ADAM Trigger Et objekt ønskes fjernet i ADAM Normalforløb Trin Aktivitet 1 Der tilsluttes til ADAM 2 Der browses til placeringen hvor objektet findes 3 Objektet markeres og der trykkes slet 4 Objektet fjernes fra den valgte liste Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 3.a Der opstår en fejl under sletningen. En fejl vises til brugeren Prioritet Mellem Performance Max 2 sekunder pr. sletning Frekvens Flere gange dagligt System Sekvens Diagram Slet objekt (ADAM) Side 59 af 72

60 9.1.3 Use Case Disable/Enable brugerobjekt (ADAM) Use Case Navn Disable/Enable brugerobjekt (ADAM) Mål At kunne disable/enable brugerobjekter i ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at skrive i ADAM. Brugeren er logget ind i EVA Succes postkondition Brugerobjektet bliver disablet eller enabled i ADAM Fejl postkondition Objektet ændrer sig ikke i ADAM Primær aktør Systemadministrator for ADAM Trigger Et brugerobjekt ønskes disabled eller enabled i ADAM Normalforløb Trin Aktivitet 1 Der tilsluttes til ADAM 2 Der browses til placeringen hvor objektet findes 3 Objektet markeres og der trykkes disable/enable 4 Objektet vises med aktivt eller inaktivt ikon på listen Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 3.a Der opstår en fejl ved ændringen. En fejl vises til brugeren Prioritet Mellem Performance Max 1 sekunder pr. disable/enable Frekvens Flere gange dagligt System Sekvens Diagram Disable/Enable brugerobjekt (ADAM) Side 60 af 72

61 9.1.4 Use Case Omdøb objekt (ADAM) Use Case Navn Omdøb objekt (ADAM) Mål At kunne omdøbe objekter i ADAM Scope System Niveau Primær Prækonditioner Servicekonto til replikering har adgang til at skrive i ADAM. Brugeren er logget ind i EVA Succes postkondition Objektet omdøbes i ADAM Fejl postkondition Objektet omdøbes ikke Primær aktør Systemadministrator for ADAM Trigger Et objekt ønskes omdøbt i ADAM Normalforløb Trin Aktivitet 1 Der tilsluttes til ADAM 2 Der browses til placeringen hvor objektet findes 3 Objektet markeres og der trykkes omdøb 4 Et nyt vindue vises, hvor det nye navn skal angives 5 Tryk OK Alternative forløb 1.a Fejl ved tilslutning. En fejlbesked vises til brugeren 5.a Der opstår en fejl omdøbningen. En fejl vises til brugeren Prioritet Lav Performance Max 1 sekunder pr. omdøb Frekvens Flere gange dagligt System Sekvens Diagram Omdøb objekt EVA System System Administrator Opret forbindelse til ADAM Browse til placering Hent objekter Returner liste af objekter Hent objekter Omdøb objekt Indtast nyt navn Omdøb objekt Returner liste af objekter Hent objekter Vis fejlbesked Fejl Side 61 af 72

62 9.2 Sekvens diagrammer Side 62 af 72

63 Side 63 af 72

64 9.3 Litteraturliste The.NET Developer s Guide to Directory Services Programming. Forlag: Pearson Education, Limited (Maj 2006). Forfattere: Ryan Dunn og Joe Kaplan. Applying UML and Patterns An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3th edition. Forlag: Pearson Education, Limited (November 2004). Forfattere: Craig Larman. AES Kryptering: Kursus-materiale fra kursus Kryptologi 1. Forfatter: Lars R. Knudsen, udleveret via CampusNet på DTU. - Implementering af AES sikkerhed i C#. Side 64 af 72

65 9.4 Brugervejledning Connect to Active Directory (AD) Make sure EVA is configured correctly (See configuring EVA). Connect to the Active Directory from the top-menu. Connect AD (1.). The connection is made, and the structure of AD can be browsed in the leftmost window (2.). In the rightmost window the sub-objects of the selected OU is shown (3.) Connect to Active Directory Application Mode (ADAM) Make sure EVA is configured correctly (See configuring EVA). There are two options to connect to ADAM. Production and Test. Make sure the correct connection is selected. Connect to ADAM, from the top-menu. Connect ADAM (Prod) / ADAM (Test) (1.). The connection is made and the structure of ADAM can be browsed in the leftmost window (2.). In the rightmost window the sub-objects of the selected OU is shown (3.) Viewing object-attributes An objects attributes can be shown by right-clicking the object Properties (1.). It is possible to view attributes for the following objects: Users Computers Groups Side 65 af 72

66 OrganizationalUnits (OU) Setting an OU as Import Folder. Before a replication can be done, it is necessary to mark an OrganizationalUnit as the Import Folder. All items that does not exists in the directory, will be replicated to this specific destination. Items that already exists in the directory will have their attributes updated, but will not be moved to the Import Folder. right-click the OU Set as Import-OU (1.). This setting will be saved between sessions Selecting objects for replication To add one or more objects to the replication-list (the bottom-window), select the object(s) and right-click the object(s) Replicate Item. (1.) All selected objects will now be added to the replication-list. The objects will now appear in the list, in the bottomwindow (2.) Replication To do a replication, with GUI, select the top-menu Functions Start replication (1.). A new window will show (2.), where it is possible to select the destination of the replication (ADAM Production or ADAM Test). Select the destination. Then click OK (3.). The replication will now start, and all attributes selected to replicate will be transferred to the selected destination. Side 66 af 72

67 Side 67 af 72

68 9.4.7 Creating new objects Connect to the directory where the new object needs creation. It is possible to create new OrganizationalUnits and Groups. Browse to the Parent OU in the directory, where the new object will be placed. right-click the OU (1.) New (2.) Select the objecttype of the new object (3.). Enter the name of the new object in the popup box (4.) Moving objects Connect to the directory where the object is placed. Browse to the object. right-click the object Move (1.). Select the new parent for the object in the new window (2.). Accept the change by pressing OK (3.) Deleting objects Connect to the directory where the change needs to be made. Browse to the object(s). right-click the object(s) Delete (1.). Confirm the deletion by pressing OK (2.). Side 68 af 72

69 Searching It is possible to search the connected directory. The objects: Users, Groups and OrganizationalUnits can be found. From the top-menu select: Functions Search (1.). The search-window appears. Select object type for the search (2.). Enter the search-string (3.). Press the Search - button (4.). The results will be displayed in the window below the search-string (5.) Configuring EVA The first time the program starts, the user is asked to configure the settings. This is needed to make the correct connections to the directories. From the top-menu select: Edit Settings (1.). The settings-window appears. Make sure settings on all tabs are entered correctly (2.). The settings for each tab are shown as (3.). For the tab Replication, the attributes for replication is shown (1.). All attributes are read from the XML file specified in (2.). Additional attributes can be added to this file manually. The files for replication and log are also specified at (2.). Accept the changes by pressing OK (3.). Side 69 af 72