Rapportsystem för Active Directory-information

(1)

Örebro universitet Örebro University

Institutionen för teknik Department of Technology

701 82 Örebro SE-701 82 Örebro, Sweden

Datateknik C, Examensarbete, 15 högskolepoäng

RAPPORTSYSTEM FÖR ACTIVE

DIRECTORY-INFORMATION

Fredrik Sjödahl Dataingenjörsprogrammet 180 hp Örebro vårterminen 2010 Examinator: Thomas Padron‐McCarthy REPORTSYSTEM FOR ACTIVE DIRECTORY INFORMATION

(2)

Sammanfattning

När det gäller fakturering av ett företags tjänster har det visat sig att den manuella hanteringen ofta är tidskrävande och att det lätt blir fel. Därför har det tagits fram många faktureringssystem för olika datorsystem. Detta examensarbete går ut på att ta fram en prototyp av ett automatiskt rapportsystem baserat på utvald användarinformation i Active Directory, informationen ska sedan användas som faktureringsunderlag. Informationen sammanställs i en databas där användaren på ett lätt sätt ska kunna ta fram en sammanställning av kundernas användning av diverse tjänster för en specifik domän.

Abstract

When it comes to invoicing a company’s services it has become evident that the manual handling very often is time‐consuming and easily becomes wrong. Therefore many developers have developed different invoicingsystems for different computersystems. This diploma work is about developing a prototype of a fully automatic reportsystem based on Active Directory‐information. This information will later on be used as basic data for the invoice. The information will be put together in a database where the user easily can retrieve a compilation about a customer’s usage of different services.

(3)

Förord

Under perioden 29:e mars till 28:e maj 2010 genomförde jag mitt examensarbete hos IT Mästaren Mitt AB i Örebro. Ett stort tack till personalen på IT Mästaren för all hjälp och gott samarbete som jag upplevt innan examensarbetet började samt under hela perioden . Jag vill rikta ett stort tack till ett antal personer som varit inblandade och gjort detta examensarbete möjligt, här följer deras namn samt på vilket sätt dem har varit inblandade. Anders Jansson och Anders Persson som var mina handledare på IT Mästaren. Mattias Ward och Anders Bergqvist som arbetade med ett annat examensarbete hos IT Mästaren och fanns till hands vid behov. Jack Pencz som fungerade som handledare på universitetet samt Rikard Westlund som gav mig möjligheten att utföra mitt examensarbete på IT Mästaren. Örebro den 10:e maj 2010 Fredrik Sjödahl

(4)

Innehållsförteckning

1. Inledning ... 5 1.1 Bakgrund ... 5 1.2 Uppdrag ... 5 2. Metoder och verktyg ... 7 2.1 Utvecklingsmiljö ... 7 2.2 Labbmiljö ... 7 2.3 Utvecklingsmetodik ... 8 2.4 Testmetodik ... 9 2.5 Protokoll och API ... 10 3. Genomförande ... 11 3.1 Informationssökning ... 11 3.1.1 Första delmomentet ... 11 3.1.2 Andra delmomentet ... 11 3.1.3 Tredje delmomentet ... 11 3.1.4 Fjärde delmomentet ... 11 3.2 Utveckling av delmoment ... 12 3.2.1 Första delmomentet ... 12 3.2.2 Andra delmomentet ... 14 3.2.3 Tredje delmomentet ... 15 3.2.4 Fjärde delmomentet ... 18 4. Resultat ... 20 5. Diskussion ... 21 Referenslista ... 22 Tryckta källor ... 22 Källor online ... 22 Active Directory ... 22 Databashantering ... 23 Kommunikation ... 23

(5)

Bilagor ... 25 Klassdiagram klient ... 25 Klassdiagram webbserver... 26 Databasstruktur ... 27 Tabeller ... 27 Lagrade Procedurer ... 27

(6)

1. Inledning

1.1 Bakgrund

Företaget som prototypen har utvecklats åt heter IT Mästaren Mitt AB i Örebro. Dem har en kundkrets av mindre och medelstora företag och erbjuder outsourcing av IT‐drifttjänster, dem har alltså ett antal IT‐drifttjänster som dem hyr ut via den befintliga internetanslutningen. Verksamheten innefattar då IT‐drift, datorkommunikation och konsulttjänster. Kunden hyr in en eller flera tjänster åt de anställda och används enbart internt hos kunden, tjänst kan hyras in för alla anställda eller enbart för några av dem. Kunden faktureras sedan utifrån vilka tjänster som hyrts in samt hur många av de anställda som använder tjänsten. I nuläget tas allt faktureringsunderlag fram manuellt genom att jämföra enskilda excel‐dokument för att kontrollera nytillkommen personal hos varje kund samt datumet för att veta hur fakturan ska se ut. Nu har alltså idén kommit upp om ett rapportsystem som automatiskt tar fram faktureringsunderlaget med Active Directory som källa. Till att börja med bör då Active Directory förklaras lite mer ingående. Active Directory är en katalogtjänst från Microsoft som innehåller information om de olika resurserna i domänen, de olika resurserna kan t.ex. vara datorer, skrivare eller användare. Det finns även möjlighet att sätta rättigheter för dessa resurser samt organisera resurserna i olika grupper. Det som är intressant för detta projekt är användarna samt möjligheten att organisera användarna i grupper. En användare motsvarar då en specifik person bland kundens anställda och en grupp kommer motsvara en specifik tjänst.[1,2]

1.2 Uppdrag

Uppdraget går alltså ut på att ta fram en prototyp av det här rapportsystemet som ska ta fram faktureringsunderlag ur Active Directory(AD). För att se en grafisk visualisering av systemets struktur se figur 1. I visualiseringen finns ett antal AD‐servrar som står bakom varsin brandvägg med och en internetanslutning, det finns en sådan server hos varje kund och det är en server med tillhörande Active Directory. I ett AD finns en användare per anställd samt tre olika grupper där varje grupp motsvara en tjänst. För varje tjänst en anställd använder sätts den anställdes användare som medlem i den grupp som motsvarar tjänsten. På det viset kan man via utläsningen ur AD:t få fram önskat faktureringsunderlag. I figuren finns även en webbserver som även den står bakom en brandvägg med en internetanslutning, den här servern står hos IT Mästaren i deras egen domän. Servern innehåller en SQL Server‐databas där informationen från alla AD‐servrar ska sammanställas, det körs även en serverprogramvara som tar emot och hanterar inkommande data. All information sparas alltså i

(7)

Det finns även en administratör som motsvarar den person på ekonomiavdelningen som sköter faktureringen. Databasen nås via internet men är endast öppen för datorer inom IT Mästaren egen domän, informationen hämtas då från databasen och presenteras i ett grafiskt gränssnitt. Informationen om användarna skickas alltså från varje AD‐server till webbservern och detta sker via envägskommunikation vilket framgår av figuren. Applikationen på varje AD‐server schemaläggs och tar på det viset initiativet till kommunikationen. AD‐servern skickar ett HTTPS‐anrop tillsammans med informationen till webbservern som enbart väntar på inkommande information och hanterar detta vid ankomst. Figur 1: System för att hämta AD‐information

(8)

2. Metoder och verktyg

2.1 Utvecklingsmiljö

Som utvecklingsmiljö används Microsoft Visual Studio 2008 och applikationen utvecklas med programmeringsspråket C#. C# har inbyggt stöd för hantering av Active Directory, kommunikationsmöjligheter via HTTPS samt hantering av Microsoft SQL Server vilket utgör en stor del av applikationen. Med detta i åtanke är C# att rekommendera för denna applikation. För backup används ingen CVS‐mjukvara. Istället används en katalogstruktur där dagens arbete sparas utan att spara över tidigare dagars arbete, kan ses som ett manuellt CVS‐system. Hela katalogstrukturen finns även på ytterligare två lagringsenheter om någon skulle sluta fungera.

2.2 Labbmiljö

Under projektets gång används en labbmiljö som ska likna den miljö som systemet sedan ska köras i. Detta ställer krav på att det finns en servermaskin med Active Directory tillgänglig. Applikationen på den här servermaskinen läser alltså ut vald information ur Active Directory och skickar detta via en HTTPS‐begäran till webbservern. På servermaskinen används Microsoft Windows 2003 och är skyddad av brandväggar som tillåter trafik ut från servern. Det ställs även krav på en annan servermaskin med tillhörande IIS som agerar webbserver. IIS är en serverprogramvara från Microsoft som hanterar Internetbaserade tjänster. Det krävs även att Microsoft SQL Server‐databas är installerat på servermaskinen som i det här fallet administreras via Microsoft SQL Server Management Studio. Serverprogramvaran tar emot en inkommande HTTPS‐ begäran och vid lyckad inloggning läser den av medskickad information och sparar detta i databasen. Därmed behövs även ett SSL‐certifikat för kommunikation via HTTPS.

(9)

2.3 Utvecklingsmetodik

När det gäller utveckling finns det ett stort antal utvecklingsmetodiker, t.ex. vattenfallsmetoden. Däremot för det här projektet var en mer modulbaserad metod mest lämplig där utvecklingen baseras på fyra delmomenten som finns beskrivet nedan. Projektet delas då upp i moduler där varje delmoment ses som en modul och utvecklas var för sig innan modulerna sätts samman till ett system. Detta innebär att utvecklingen fokuserar på ett delmoment åt gången och delmomentet färdigställs innan nästa påbörjas. Utvecklingen sker enligt följande ordning: 1. Delmoment 1: utläsning ur Active Directory som sker via en applikation lokalt på AD‐servern. 2. Delmomentet 3: inkommande information sparas i databasen. 3. Delmoment 2: informationen skickas från AD‐server till webbserver. 4. Delmoment 4: informationen i databasen presenteras i det grafiska gränssnittet. Att delmoment tre utvecklas före delmoment två beror på att testningen av skickad information blir mycket lättare om resultatet redan från början kan sparas ner någonstans.

(10)

2.4 Testmetodik

Testningen utförs i flera steg under hela utvecklingsprocessen och utgörs av experimentell testning på varje delmoment. Nästa delmoment påbörjas först när testningen av nuvarande delmoment ger önskat resultat. Testningen av delmoment ett utförs lokalt eftersom applikationen för utläsning kommer utföras lokalt i fortsättningen också. Testningen av delmoment tre utförs även det lokalt, informationen som läses ut ur Active Directory sparas då direkt i en lokal databas. Detta är lämpligt eftersom databashanteringen kommer utföras lokalt på webbservern även i drift. Genom att jämföra informationen i Active Directory och informationen som läses ut framgår det om första delmomentet fungerar. Om sen samma information finns med i databasen framgår det om andra delmomentet fungerar. Testning av kommunikationen, när informationen skickas till webbservern, testas i två steg. Det första steget är att köra webbservern via Visual Studios och den lokala SQL Server‐databasen. När det fungerar testas kommunikationen när webbservern körs i den skarpa miljön, alltså på den servermaskin där serverprogramvaran ska köras i fortsättningen. Genom att jämföra informationen som skickas med i anropet med informationen i databasen framgår det om kommunikationen fungerar för dessa två steg. När tidigare delmoment fungerar testas utläsningen ur databasen. Genom att jämföra informationen som presenteras i det grafiska gränssnittet med informationen i databasen framgår det om utläsningen fungerar. Så här långt har utläsningen endast gjorts från labbmiljöns Active Directory och webbserverns skarpa miljö. När tidigare tester ger önskat resultat kommer det slutgiltiga testat, där applikationen för utläsning testas i sin skarpa miljö. Testet körs på Active Directory‐servern hos tre olika kunder ett antal gånger för att säkerställa att systemet fungerar och är stabilt.

(11)

2.5 Protokoll och API

Här följer en kort beskrivning av de huvudsakliga protokoll, API:er samt namnrymder som krävs för att applikationen ska kunna fungera. DirectoryService: namnrymden i .NET som ger åtkomst till Actice Directory’s domäntjänster. I namnrymden finns ett antal olika klasser som kan användas för att hantera objekt i form av användare, datorer etc. och deras tillhörande information.[8] LDAP (Lightweight Directory Access Protocol): protokoll för katalogtjänster som körs via TCP/IP‐ stacken och är baserad på en klient/server‐modell. Protokollet ger tillgång till olika katalogtjänster samt funktioner för att ansluta till tjänsten, söka i katalogen eller modifiera innehållet.[9] Net: namnrymd i .NET som innehåller stöd för ett stort antal protokoll som används i dagens nätverkshantering. Innehåller även klasser för nätverkshantering relaterade till de inkluderade protokollen, klasser som gör det möjligt att utveckla olika nätverksapplikationer och nätverkstjänster.[20] Cryptography: namnrymd som ger olika krypteringsmöjligheter. Namnrymden innehåller bland annat funktioner för kodning och avkodning av data, hashfunktioner och autentisering.[25] SqlClient: namnrymd som är framtagen för hantering av ett antal olika versioner av SQL Server. SqlClient innehåller olika databas‐specifika protokoll med tillhörande klasser. Klasserna ger användaren möjlighet att ansluta till databasen, begära information från databasen, lägga till ny information samt uppdatera informationen.[13]

(12)

3. Genomförande

3.1 Informationssökning

Förberedande informationssökning är en stor del av projektet och informationen tas fram inför respektive delmoment utifrån de frågeställningar som berör varje delmoment. För alla delmoment används både tryckt litteratur samt källor online som informationskälla. För en del av källorna finns referenser med i texten men den kompletta referenslistan återfinns i slutet av rapporten. 3.1.1 Första delmomentet Det första delmomentet handlar om att kunna läsa ut vald information ur Active Directory. Frågeställningarna är följande: • Hur skapas en koppling med given sökväg och tillräcklig behörighet mellan applikationen och Active Directory? • Hur fungerar en sökning i Active Directory? • Hur fungerar utläsning ur Active Directory? 3.1.2 Andra delmomentet Det andra delmomentet berör kommunikationen mellan varje Active Directory Server och web‐ servern. Frågeställningarna är följande: • Hur skapas en HTTPS‐begäran? • Vilken algoritm för kryptering kan användas och hur implementeras vald algoritm? • Hur skickas vald data med? • Hur skapas en server som tar emot HTTPS‐begäran och kräver inloggning? • Hur nås data som är medskickad? 3.1.3 Tredje delmomentet Det tredje delmomentet handlar om databashanteringen. Här finns följande frågeställningar: • Hur skapas en databaskoppling med sökväg och inloggning mellan applikation och databas? • Hur skapas och används lagrade procedurer för sökning i databasen samt uppdatering och insättning? 3.1.4 Fjärde delmomentet Det fjärde delmomentet som innefattar presentation av informationen i databasen har följande frågeställning: • Hur skapas ett enkelt grafiskt gränssnitt med grundläggande grafiska komponenter?

(13)

3.2 Utveckling av delmoment

Utvecklingen av applikationen delas upp i olika delmoment enligt avsnitt 2.3. 3.2.1 Första delmomentet Den första fasen där applikationen hämtar information ur Active Directory kan modelleras enligt följande[1,3]: Figur 2: Aplikation för att söka information i AD För att få tillgång till informationen krävs att en koppling mellan applikation och Active Directory (AD). För att etablera kopplingen används LDAP‐protokollet och för att etablera kopplingen krävs tre parametrar. Den första är sökvägen till aktuellt AD med domännamn och var det befinner sig[10]: LDAP://DC=domainname,DC=local De andra parametrarna som krävs är användarnamn och lösenord för inloggning till AD:t. Det krävs även att en typ autentisering anges. När kopplingen etableras skapas ett objekt som heter DirectoryEntry som pekar på en specifik nod i AD:t och kopplingen etableras på följande sätt[10]: DirectoryEntry directoryEntry = new DirectoryEntry(LDAPPath(), LDAPUser(), LDAPPassword(), AuthenticationTypes.Secure);

För att sedan läsa ut information krävs ett antal olika sökningar i AD:t. Man använder då ett objekt som kallas DirectorySearcher som ställer frågor mot AD:t för att läsa ut informationen. Vid skapandet av detta objekt skickar man med en DirectoryEntry som sökrot samt definierar ett filter som fungerar som sökkriterium. Resultatet sparas sedan i ett resultatobjekt. För det här fallet då applikationen ska läsa ut information om alla användare i en given grupp, ser sökningen ut som följer[10,11]:

DirectorySearcher directorySearch = new DirectorySearcher(searchRoot()); directorySearch.Filter="(&(objectClass=group)(SAMAccountName="+groupName+"))";

(14)

Varje objekt i AD:t har en egen sökväg och för att byta objekt krävs att en ny DirectoryEntry skapas. Så när gruppen är funnen krävs alltså en DirectoryEntry som pekar på den funna gruppen. Till skillnad från tidigare använder man nu sökvägen till sökningen resultat som sökväg för den nya

DirectoryEntry. Det ser ut som följer[10]:

DirectoryEntry groupDir = new DirectoryEntry(results.Path, LDAPUser(), LDAPPassword());

För att kunna läsa ut informationen för varje användare i gruppen krävs ett objekt som kallas PropertyCollection som är en samling egenskaper för ett antal objekt, ett antal användare i det här fallet[10].

PropertyCollection propCollection = groupDir.Properties;

För att läsa ut informationen för varje användare används en loop som definieras med hjälp av antal medlemmar i samlingen av egenskaper. Eftersom varje användare är ett eget objekt och har en egen sökväg krävs en ny DirectoryEntry för varje användare. Sökvägen blir då en sammansättning av gruppens namn och varje användares samling av egenskaper[10].

string resultpath = result.Path;

string[] pathnavigate = resultpath.Split("CN".ToCharArray()); resultpath = pathnavigate[0];

string objectpath = propCollection["member"][i].ToString();

string path = resultpath + objectpath;

DirectoryEntry userDir = new DirectoryEntry(path, LDAPUser(), LDAPPassword()); För varje samling av egenskaper skapas sedan en instans av ett egendefinierat objekt som representerar en användare och som används framöver i applikationen.

(15)

3.2.2 Andra delmomentet Den andra fasen där applikationen skickar informationen till web‐servern kan modelleras enligt följande: Figur 3: Applikation för att skicka AD‐information Informationen ska alltså sändas till webbservern via en HTTPS‐anslutning. För att etablera en sådan anslutning används klassen WebClient som finns med i namnrymden Net och innehåller metoder för att etablera anslutningar via HTTP och HTTPS. Som parametrar tar metoderna i regel två parametrar, destination och medskickad information, men i det här fallet krävs enbart en parameter som är adressen till webbservern. Adressen blir nämligen en sammansatt textsträng med både webbserverns adress samt all information om en användare som utgörs av ett antal textsträngar[22,23,24]. För varje användare som lästs ut ur Active Directory används det egendefinierade objektet för att sätta samman användarinformationen med webbserverns adress. Den skapade instansen av WebClient‐klassen skickas sedan med hela textsträngen som adress. Lägg märke till att lösenordet som skickas med för inloggning är krypterat. Det ser ut som följer:

userNameStr = "?uname=" + TargetWebServerUsername();

passwordStr = "&pword=" + EncodePassword(TargetWebServerPassword()); containerNameStr = "&cn=" + user.getContainerName;

lastNameStr = "&lname=" + user.getLastName; firstNameStr = "&fname=" + user.getFirstName;

lastLogOnStr = "&llon=" + user.getLastLogOn.ToString(); logOnNameStr = "&loname=" + user.getLogOnName;

domainStr = "&domain=" + user.getDomainName; emailStr = "&email=" + user.getEMail;

mobileNrStr = "&mnr=" + user.getMobileNr;

homePhoneNrStr = "&hpnr=" + user.getHomePhoneNr;

citrixMemberStr = "&citrixMem=" + user.getCitrixMember; emailMemberStr = "&emailMem=" + user.getEmailMember;

smsCodeMemberStr = "&smscodeMem=" + user.getSmsCodeMember;

String userInfo = userNameStr + passwordStr + containerNameStr +

lastNameStr + firstNameStr + lastLogOffStr + lastLogOnStr + logOnNameStr + domainStr + emailStr + mobileNrStr + homePhoneNrStr + citrixMemberStr + emailMemberStr + smsCodeMemberStr;

(16)

3.2.3 Tredje delmomentet Den tredje fasen där webbservern hämtar den medskickade informationen och lägger in det i databasen kan modelleras enligt följande: Figur 4: Applikation för att lagra överförd AD‐information i databasen Enligt uppdragsbeskrivningen nås webbservern via en webbsida som hanterar all data. Servern är utformad så att den kräver användarnamn och lösenord för att den ska hantera den inkommande begäran. All hantering av inkommande data hanteras med SQL‐frågor som lagras i databasen som lagrade procedurer. Som konstaterats ovan skickas all AD‐information tillsammans med adressen. Detta innebär att webbservern måste läsa textsträngen och i den urskilja AD‐informationen. Strängen är formaterad med följande struktur för att webbservern ska kunna läsa av den korrekt[20]: "?var1=value&var2=value&var3=value…" Den kompletta strängens struktur med alla dess variabler framgår av exempelkoden under avsnitt 3.2.2. Som exempel skulle början av informationssträngen, den delen av strängen som satts samman med adressen till servern, kunna se ut som följer:

"?unamn=testUN&pword=testP&cn= testuser1 test1…"

När informationen kommer in utförs ett antal tester för att servern ska vara säker på att den får in rätt information och att informationen kan hanteras. Det första testet är att testa om loginnamn (loname) eller domännamn (domain) saknar värde, vilket sker på följande sätt[20]:

Request.QueryString["loname"] != "" && Request.QueryString["domain"] != "" Eftersom loginnamn och domännamn tillsammans utgör primärnyckel i databasen och identifierar en unik användare måste båda variablerna ha ett värde. Om variablerna saknas i strängen eller om dem saknar värde avbryts processen, annars går den vidare. Om processen går vidare etableras en databaskoppling som kommer sköta mycket av hanteringen. Den etableras som följer[14]:

(17)

För att skydda databasen och dess innehåll används som nästa steg en inloggningskontroll. Servern läser användarnamn och det krypterade lösenordet från textsträngen samtidigt som den läser av originallösenordet för användaren från databasen och krypterar detta med samma algoritm. Om lösenorden är lika kommer inloggningen att lyckas och allt går vidare, annars avbryts hanteringen. Läsningen av databasen sker via en lagrad procedur och hanteras enligt följande[15,18,28]:

cmd = new SqlCommand("sp_SelectPassword", conn); cmd.CommandType = CommandType.StoredProcedure;

cmd.Parameters.Add("@userName", SqlDbType.VarChar).Value = Request.QueryString["uname"];

SqlDataReader sqlDataReader = cmd.ExecuteReader(); String password = null;

while (sqlDataReader.Read()) { password = sqlDataReader["Password"].ToString(); } sqlDataReader.Close(); Om inloggningen lyckas går processen vidare för att avgöra om användaren som kommer in redan finns i databasen eller inte. Om användaren finns ska användaren uppdateras, annars ska användaren läggas till i databasen. Genom att anropa den lagrade proceduren sp_SelectRecord som söker efter en unik användare med hjälp av loginnamn och domännamn returneras all information om användaren om den finns i databasen. Om det framgår att användaren redan finns i databasen, uppdateras informationen som returnerats som sedan skickas med som parametrar till den lagrade proceduren sp_UpdateReportTable. Proceduren uppdaterar informationen om den funna användaren, samt sätter senast uppdaterade datum för varje grupp användaren är med i till dagens datum. Skulle användaren påträffas i en ny grupp sätts både datumet för när posten skapades och senast uppdaterade datum till dagens datum för den nya gruppen. Loginnamn och domännamn uppdateras inte eftersom de tillsammans bildar primärnyckeln (för krypteringen) och aldrig ändras. Om det framgår att användaren inte finns, anropas den lagrade proceduren sp_InsertReportTable som tar samma parametrar som för uppdatering och lägger till en ny post i databasen med informationen. Det som skiljer är att i det här fallet sätts båda datumfälten för respektive grupp som användaren är med i till dagens datum. Det sista som sker i den här fasen är att uppdatera informationen om vilka grupper i Active Directory som varje användare tillhör, detta betecknas med sant eller falskt i databasen. Genom att ta hänsyn

(18)

dagens datum samt ett domännamn. Proceduren jämför dagens datum med senast uppdaterade för varje grupp och en specifik domän. Om inget av senaste uppdaterade datumen för en användare stämmer överens med dagens datum tolkas det som att användaren är borttagen, i databasen visas detta genom att variablerna som talar om att användaren är med i gruppen sätts till falskt.

(19)

3.2.4 Fjärde delmomentet Den fjärde fasen där det grafiska gränssnittet hämtar och presenterar informationen för användaren kan modelleras enligt följande: Figur 5: Applikation för det grafiska gränssnittet Enligt uppdragsbeskrivningen ska alltså ett grafiskt gränssnitt tas fram för att presentera informationen som i tidigare fas sparades i databasen. Gränssnittet består av en dropdownlist och ett antal olika gridviews. Via en dropdownlist markeras en av de domäner som finns representerade i databasen. För den valda domänen fylls en gridview för varje grupp som lästs ut ur Active Directory samt en gridview för alla användare i domänen som funnits med i någon grupp men tagits bort och inte ingår i någon grupp för tillfället. Eftersom en grupp motsvarar en av företagets tjänster redovisar varje gridview vilka användare som använder tjänsten samt hur aktivt tjänsten används. Eftersom gränssnittet nås via en webbsida som är öppen för allmänheten bör någon form av behörighet kontrolleras. I det här fallet används klientens publika IP‐adress för att verifiera att klienten tillhör företagets eget nätverk. Alla godkända IP‐adresser finns sparade som en lista i en konfigurationsfil och varje gång sidan laddas jämförs klientens IP‐adress med listan. Om IP‐adressen inte är godkänd vidarebefordras klienten till en tom sida, annars laddas resterande komponenter på webbsidan.

String clientIP = Request.UserHostAddress; String[] IPtoCompare = GrantedIP();

if (!IPtoCompare.Contains(clientIP)) {

Response.Redirect("http://adinfo.itmastaren.se/IPTestFailed.aspx"); }

(20)

Om IP‐adressen är godkänd laddas alltså resterande delar av sidan, däribland skapas en

databaskoppling som kommer användas för utläsning av information. Via databaskopplingen anropas sedan den lagrade proceduren sp_SelectDomainNames som fyller den ovan nämnda dropdownlist med alla unika domännamn som förekommer i databasen[15,18,28].

SqlCommand cmd = new SqlCommand("sp_SelectDomainNames", conn); cmd.CommandType = CommandType.StoredProcedure;

SqlDataReader sqlDataReader = cmd.ExecuteReader();

while (sqlDataReader.Read()) {

String str = (String)sqlDataReader["DomainName"]; ddlDomains.Items.Add(str); } sqlDataReader.Close(); När domänen är vald skickas domännamnet med som parameter till ett antal lagrade procedurer, en procedur för varje grupp samt en procedur för alla borttagna användare. Resultatet från varje procedur läggs sedan in i respektive gridview[15,18,28].

cmd = new SqlCommand("sp_SelectCitrixInfo", conn); cmd.CommandType = CommandType.StoredProcedure;

cmd.Parameters.Add("@domainName", SqlDbType.VarChar).Value = choosenDomain; sqlDataReader = cmd.ExecuteReader(); gwShowCitrixGroup.DataSource = sqlDataReader; gwShowCitrixGroup.DataBind(); gwShowCitrixGroup.CellPadding = 5; sqlDataReader.Close();

(21)

4. Resultat

Rapportsystemet tillhandahåller en prototyp av en Windows‐tjänst för rapportering av Active Directory‐information rörande företagets kunder och deras användning av företagets tjänster. Informationen sammanställs sedan i en databas och informationen ska i sin tur ligga till grund för företagets fakturering. Tjänsten syftar alltså till att automatisera en stor del av faktureringsprocessen samtidigt som tjänsten ska underlätta den resterande manuella hanteringen av faktureringen. Den helt automatiska delen av rapportsystemet utförs en gång per dygn med en utläsning av vald information från Active Directory. Informationen organiseras och skickas sedan till en webbserver där informationen hanteras och en lokal databas uppdateras med den inkommande informationen. Den manuella hanteringen utförs via det grafiska gränssnittet på samma webbserver. Här väljer man vilken domän som faktureringen gäller. För den valda domänen listas sedan alla användare för varje tjänstegrupp som representeras av en grupp i Active Directory. För den valda domänen listas även alla användare som varit med i gruppen men har blivit borttagna. Med hjälp av de datum som finns för varje användare kan man utläsa när användaren började använda tjänster. Närmare bestämt används datum för användarens inträde i gruppen respektive tjänstegrupp.

(22)

5. Diskussion

Till att börja med bör en detalj angående kommunikationen påpekas. Tidigare har det framgått att kommunikationen helst ska gå via HTTPS‐anslutning. Som systemet ser ut i nuläget är det förberett för att HTTPS ska fungera men tyvärr fanns det inte tid att testa detta. För att kommunicera via HTTPS krävdes vissa förberedelser på webbservern som tyvärr inte hanns med. Det finns även anledning att kommentera säkerheten i systemet. Som det ser ut just nu finns det ett antal säkerhetsåtgärder som är vidtagna men självklart kan säkerheten byggas ut ytterligare. Eftersom tiden var begränsad fanns det helt enkelt inte tid att fokusera allt för mycket på säkerheten, det hade blivit alldeles för omfattande i det här fallet. I och med att alla SQL‐frågor körs som lagrade procedurer finns det i alla fall skydd mot SQL‐injektion men sen kvarstår andra problem, som t.ex. skydd mot spoofing. Det bör återigen nämnas att det här examensarbetet syftade enbart till att utveckla en prototyp och grundstruktur av faktureringssystemet. Det handlade om att hitta en lösning på hur man hämtar information ut Active Directory, hur informationen på ett tillförlitligt sätt kan skickas till en webbserver samt hur informationen kan sammanställas för att underlätta informationshanteringen. Detta innebär att den informationen som hämtas ur Active Directory i nuläget mycket väl kan förändras beroende på hur systemet kommer att komplettera företagets faktureringsprocess. I slutänden är i alla fall specifikationen för mitt examensarbete uppfylld och IT Mästaren är nöjda med prototypen, och som jag har förstått det kommer den tas i drift efter lite vidareutveckling som även den finns beskriven här. Eftersom systemet i nuläget bara utgör en prototyp finns det som sagt en hel del vidareutveckling att arbeta med. Under arbetets gång kom det fram några önskemål från företagets sida som det tyvärr inte fanns tid för under examensarbetet. Framför allt handlar det om ett mer användarvänligt och omfattande grafiskt gränssnitt. Dels vill företaget utöka möjligheten till utläsning ur databasen med fler och mer specifika SQL‐frågor för att enbart läsa ut den informationen som är intressant för tillfället. Det finns även behov av att kunna presentera informationen som läses ut i någon form av formulär, formulär som ska kunna användas som utskick till kund samt användas för intern hantering. För att underlätta installation och underhåll av tjänsten finns det ytterligare två önskemål som inte hanns med. Eftersom tjänsten ska köras en gång per dygn, finns behov av schemaläggning. För tillfället används Windows egen schemaläggare men det skulle underlätta med en inbyggd schemaläggare i tjänsten. Då skulle Windows schemaläggare inte behöva konfigureras. Det sista önskemålet handlar om implementation av en relativt omfattande loggfil. Eftersom större delen av tjänsten körs automatiskt är den svår att felsöka vid problem och för ändamålet skulle en loggfil komma väl till pass.

(23)

Referenslista

Tryckta källor

[1] William R. Stanek , Windows Server 2008 INSIDE OUT, Microsoft Press 2008, ISBN 978‐0‐7356‐2438‐2 [2] Jill Spealman m.fl. , Microsoft Windows Server 2003 Active Directory Infrastructure, Microsoft Press 2006 [3] Christian Nagel m.fl. , Professional C# 2005, Wiley Publishing Inc 2006, ISBN 978‐0‐7645‐7534‐1 [4] Jesse Liberty & Donald Xie , Programming C# 3.0, O’Reilly Media Inc 2008, ISBN 978‐0‐596‐52743‐3 [5] Joseph & Ben Albahari , C# 4.0 In a nutshell, O’Reilly Media Inc 2010, ISBN 978‐0‐596‐80095‐ 6 [6] Jesse Liberty m.fl. , Programming ASP.NET 3.5, O’Reilly Media Inc 2009, ISBN 978‐0‐596‐52956‐7 [7] Thomas Padron‐McCarthy & Tore Risch, Databasteknik, Studentlitteratur 2005, ISBN 91‐44‐04449‐6

Källor online

Active Directory [8] MSDN, System.DirectoryServices Namespace, 29:e mars 2010 http://msdn.microsoft.com/en‐us/library/system.directoryservices.aspx [9] MSDN , Lightweight Directory Access Protocol, 29:e mars 2010 http://msdn.microsoft.com/en‐us/library/aa367008(VS.85).aspx [10] C# Corner , ALL Operations on Active Directory (AD) using c#, 29:e mars 2010 http://www.c‐ sharpcorner.com/UploadFile/dhananjaycoder/activedirectoryoperations11132009113015A M/activedirectoryoperations.aspx [11] The Internet Engineering Task Force (IETF) , The String Representation of LDAP Search Filters, 1:a april 2010 http://www.ietf.org/rfc/rfc2254.txt [12] DevelopmentNow , c# : How do I get "lastLogon" from ActiveDirectory, 11:e maj april 2010 http://www.developmentnow.com/g/36_2004_1_0_0_205194/How‐do‐I‐get‐lastLogon‐

(24)

Databashantering [13] MSDN, System.Data.SqlClient Namespace, 4:e april 2010‐06‐07 http://msdn.microsoft.com/en‐us/library/system.data.sqlclient.aspx [14] The Code Project , Beginners guide to accessing SQL Server through C#, 4:e april 2010 http://www.codeproject.com/KB/database/sql_in_csharp.aspx [15] Ideal Programmer , C# – Sql Parameters Source Code – Insert Statement, 4:e april 2010 http://idealprogrammer.com/code‐samples/sql‐parameters‐insert‐statement/ [16] MSDN , How to: Create a Stored Procedure (SQL Server Management Studio), 17:e april 2010 http://msdn.microsoft.com/en‐us/library/ms345415.aspx [17] C# Station , Lesson 07: Using Stored Procedures, 17:e april 2010 http://www.csharp‐station.com/Tutorials/AdoDotNet/Lesson07.aspx [18] About.com , SQL Server Stored Procedures, 17:e april 2010 http://databases.about.com/od/sqlserver/a/storedprocedure.htm [19] Exforsys Inc , SQL Server 2000: Creating Stored Procedure with Input and Output Parameters, 17:e april 2010 http://www.exforsys.com/tutorials/sql‐server/sql‐server‐creating‐stored‐procedure‐with‐ input‐and‐output‐parameters.html [20] Sitepoint , Handling Submitted Data with ASP, 17:e april 2010 http://articles.sitepoint.com/article/handling‐submitted‐data‐asp/3 Kommunikation [21] MSDN, System.Net Namespace, 9:e april 2010‐06‐07 http://msdn.microsoft.com/sv‐se/library/system.net.aspx [22] Heaton Research , Using HTTPS in C#, 29:e mars 2010 http://www.heatonresearch.com/articles/166/page2.html [23] MSDN , WebClient Class, 9:e april 2010 http://msdn.microsoft.com/en‐us/library/system.net.webclient(VS.80).aspx [24] C# 4.0 in a Nutshell ‐ Code Listings , Chapter 14: Networking, 9:e april 2010 http://www.albahari.com/nutshell/ch14.aspx [25] MSDN , System.Security.Cryptography Namespace, 27:e april 2010 http://msdn.microsoft.com/en‐us/library/system.security.cryptography.aspx [26] Stackoverflow , Password hashing in a C# Windows app, absent ASP.NET’s FormsAuthentication, 27:e april 2010 http://stackoverflow.com/questions/212763/password‐hashing‐in‐a‐c‐windows‐app‐absent‐

(25)

Grafiskt gränssnitt [27] DotNetSpark , How to Fill a Gridview using DataReader object, 26:e april 2010 http://www.dotnetspark.com/kb/797‐hoe‐to‐fill‐gridview‐using‐datareader‐object.aspx [28] MSDN , SqlDataReader Class, 26:e april 2010 http://msdn.microsoft.com/en‐us/library/system.data.sqlclient.sqldatareader.close.aspx Övrigt [29] AspAlliance , Working with Windows Service Using Visual Studio 2005, 6:e maj 2010 http://aspalliance.com/1316_Working_with_Windows_Service_Using_Visual_Studio_2005.2

(26)

Bilagor

Klassdiagram klient

Figur 1: Klassdiagram för klienten som körs på varje Active Directory‐server

(27)

Klassdiagram webbserver

Figur 2: Klassdiagram för web‐servern

(28)

Databasstruktur

Tabeller

Figur 3: Databasens tabellstruktur

Lagrade Procedurer

Figur 4: Returnerar lösenordet för den medskickade användaren Figur 5: Returnerar hela posten för den medskickade unika användaren

(29)

Figur 6: Uppdaterar hela posten för den medskickade unika användaren Figur 7: Sätter in den medskickade unika användaren i en ny post Figur 8: Uppdaterar grupptillhörigheten för varje användare i medskickad domän Figur 9: Returnerar alla unika domännamn i databasen Figur 10: Returnerar alla användare som är med i gruppen citrix i medskickad domän Figur 11: Returnerar alla användare som är med i gruppen email i medskickad domän