Nils Byström, Avd f IT och inköp. Projekt AD-design Uppsala universitet DiarieNr: UFV 2009/413. Revision 1.0 Filnamn AD skyddade personuppgifter.

Transkript

1 Bilaga 2 Benämning Utredning Ansvarig Nils Byström, Avd f IT och inköp Skapat :56 Skyddade personuppgifter Pelle Lindé, IT-strategiska avd Senast sparat :37 Projekt AD-design Uppsala universitet DiarieNr: UFV 2009/413 Revision 1.0 Filnamn AD skyddade personuppgifter.doc Active Directory Skyddade personuppgifter

2 Innehållsförteckning 1.1. Bakgrund Metoder Skyddat OU Skyddade användarkonton Slutsats Fördelar med skyddat OU Nackdelar med skyddat OU Fördelar med skyddade användarkonton Nackdelar med skyddade användarkonton Rekommendation 6

3 1.1. BAKGRUND Uppsala universitets nya Active Directory ska laddas med användaruppgifter ifrån den centrala katalogtjänsten AKKA. Uppgifter som Active Directory användarobjekt ska skapas med är t ex. användarnamn, lösenord, för-, mellan- och efternamn. För att vissa tjänster ska kunna fungera korrekt läses även andra uppgifter in som t.ex. e-postadressen. Fler fält kommer förmodligen att användas längre fram, men dessa kommer att utredas vid behov. Eftersom alla användarobjekten är läsbara för autentiserade användare som standard så måste de användare som har skyddade personuppgifter kunna få sin identitet dold i AD, men systemen måste fortfarande kunna autentisera dem så att de kan komma åt de resurser som de ska ha tillgång till, samt i de fall som t.ex. Exchange, eller sharepoint behöver tillgång till e-postadressen så måste även det fungera. I AKKA har de användare som har skyddade personuppgifter en flagga som markerar detta, och den kan nyttjas när objekten läses in i AD, dock finns det inget idag självklart sätt att skydda dessa personers identitet i AD, utan Uppsala universitet får ta fram sitt egna sätt att skydda dessa användare. Kravet är att en normal användare som loggar in mot AD inte ska kunna se de användare som har skyddade personuppgifter, men alla system som har behovet av att kunna nyttja skyddade konton ska kunna det. Det ska även finnas en eller flera speciella grupper av användare som ska kunna se de skyddade personernas konton och modifiera dessa, och placera dem i olika grupper. Dessutom ska inte de konton som är skyddade markeras ( hängas ut ) på något sätt i systemet METODER Det finns i huvudsak två sätt att skydda dessa personer som har skyddad identitet. Antingen kan man välja att sätta upp ett separat OU för de användare som har skyddade personuppgifter, och vid inläsningen från AKKA till ADt låta de skyddade användarna automatiskt hamna i det OUt. De användare som inte har skyddade personuppgifter låter man hamna i vanliga användar-oun. Alternativt läser man in alla användarkonton från AKKA till vanliga användar-oun, och de användare som har skyddade identitet sätter man andra rättigheter på som gör att användare med normala behörigheter/rättigheter inte har tillgång att se dessa konton SKYDDAT OU För att skapa ett skyddat OU gör man på följande sätt: Starta Active Directory Users and Computers. Markera Advanced Features under View-menyn. Skapa ett OU Tänk på att själva OU-namnet kommer vara synligt för alla användare. OUt kommer inte vara synligt som ett OU för de användare som inte har rättigheter att se de användare som har skyddade personuppgifter, utan kommer att se ut som ett CO som de inte har rättigheter att läsa. Gå in på egenskaper för objektet, klicka på säkerhetsfliken och sedan avancerat. Avmarkera Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicit defined here. för det OUt. Välj copy permissions när det efterfrågas. Kontrollera att Administrators, Domain Admin's, Enterprise Admin's, Enterpride Domain Controllers och System fortfarande har kvar sina rättigheter. Om dessa konton inte har kvar sina rättigheter på OUt kommer inte systemet kunna autentisera användaren. 3

4 Ta bort accessen för Domain users, Authenticated users, och Everyone. Genom att ta bort dessa kan vi reglera exakt vilka användare som ska ha access på objektet. Ta bort eller behåll övriga defaultanvändares rättigheter efter tycke och smak (Account operators, Print operators, Pre-Windows 2000 Compatbile Access). Rekommenderat är att ta bort dessa användare också och sedan lägga till rättigheter för de användare som behöver access på objektet. Om en tjänst installeras på en server som behöver ha access till de användare som har skyddade personuppgifter så måste de användarkontot som tjänsten körs under få läsrättigheter på OUt. Om tjänsten installeras om local system så måste datorobjektet få läsrättigheter på OUt. Observera dock att alla tjänster som körs som local system på den datorn kommer att få tillgång til de skyddade personuppgifterna. Ett sätt att hantera detta på är att skapa en grupp i det skyddade OUt som har läsrättigheter på det skyddade OUt och i den gruppen placera de användare och datorer som behöver läsrättigheter på det skyddade OUt, På det viset så kan ingen se vilken grupp det är som har de skyddade SKYDDADE ANVÄNDARKONTON Starta Active Directory Users and Computers. Markera Advanced Features under View-menyn. Skapa en användare Tänk på att "Display Name" kommer vara synligt för alla användare Användarobjektet kommer inte vara synligt som ett användarobjekt för de användare som inte har rättigheter att se de användare som har skyddade personuppgifter, utan kommer att se ut som ett CO som de inte har rättigheter att läsa. Gå in på egenskaper för objektet, klicka på säkerhetsfliken och sedan avancerat. Avmarkera Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicit defined here. för det användarobjektet. Välj copy permissions när det efterfrågas. Kontrollera att Administrators, Domain Admin's, Enterprise Admin's, Enterprise Domain Controllers och System fortfarande har kvar sina rättigheter. Om dessa konton inte har kvar sina rättigheter på användarkontot kommer inte systemet kunna autentisera användaren. Ta bort accessen för Domain users, Authenticated users, och Everyone. Genom att ta bort dessa kan vi reglera exakt vilka användare som ska ha access på objektet. Ta bort eller behåll övriga defaultanvändares rättigheter efter tycke och smak (Account operators, Print operators, Pre-Windows 2000 Compatbile Access). Rekommenderat är att ta bort dessa användare också och sedan lägga till rättigheter för de användare som behöver access på objektet. Om en tjänst installeras på en server som behöver ha access till de användare som har skyddade personuppgifter så måste de användarkontot som tjänsten körs under få läsrättigheter på användarobjektet. Om tjänsten installeras som local system så måste datorobjektet få läsrättigheter på användarobjektet. Observera dock att alla tjänster som körs som local system på den datorn kommer att få tillgång till de skyddade personuppgifterna. Ett sätt att hantera detta på är att skapa en grupp som har samma rättigheter som 4

5 användarkontona och som har läsrättigheter på det skyddade användarkontona och i den gruppen placera de användare och datorer som behöver läsrättigheter på det skyddade användarkonto, På det viset så kan ingen se vilken grupp det är som har de skyddade, samt att man behöver bara lägga till de nya kontona som ska ha läsrättigheter i den gruppen, istället för att uppdatera alla konton SLUTSATS De båda metoderna som beskrivs har båda för och nackdelar. Tyvärr verkar det inte finnas i dagens läge något riktigt bra sätt att hantera skyddade personuppgifter i Active Directory så vi har fått att anpassa oss till de metoder som finns beskrivna ovan. Om man skyddar ett objekt med metoden ovan så kommer de att få Typen Okänd, och ikonen kommer att indikera att objektet inte är läsbart för användaren. Om en ny tjänst sätts upp som behöver komma åt användarobjekten ifrån Active Directory krävs det att rättigheterna på dessa attribut uppdateras med korrekta rättigheter för att den nya tjänstens ska kunna hämta uppgifterna. Om den nya tjänsten sätts upp som local system på en server så måste det datorkontot få access till de kontona med skyddade personuppgifter. 5

6 1.6. FÖRDELAR MED SKYDDAT OU Fördelen med att placera alla användare som har skyddade personuppgifter i ett OU är att om en ny tjänst installeras som behöver rättigheter på dessa objekt, räcker det med att uppdatera rättigheterna på OUt. Det blir ett objekt i AD-strukturen som blir skyddat, så det går inte att säga hur många användare som är skyddade för användare som inte har rättigheter på det OUt NACKDELAR MED SKYDDAT OU Alla användare som har skyddade personuppgifter grupperas i ett OU, vilket medför att om man har rättigheter att läsa det OUt kan man snabbt och enkelt filtrerar ut vilka användare som har skyddade personuppgifter. Om en person som först läggs in i ADet som inte har skyddade uppgifter och sedan får skyddade personuppgifter, kommer då att flytas från huvud Out till det skyddade OUt. Detta kan medföra problem för system som slår mot AD ldap och har en specifik sökväg till objektet FÖRDELAR MED SKYDDADE ANVÄNDARKONTON Det går att placera användarkontot vart som helst i OU-strukturen, och det är i alla fall skyddat. De skyddade kontona är inte grupperade, vilket gör att de inte hängs ut i ett specifikt OU. Om en person som först inte har haft skyddade personuppgifter sedan får det, kommer inte att flytas från sitt befintliga OU utan kommer ligga kvar på samma plats, vilket gör att system som använder sig av AD ldap inte behöver uppdateras i de fallen NACKDELAR MED SKYDDADE ANVÄNDARKONTON Konton med skyddade personuppgifter hängs ut genom att dessa har andra rättigheter. Användaren som söker fram dessa konton kan inte gå in och titta på detaljer på användarkontot, men eftersom de inte har rättigheter att gör det så får de en deny på de objekt som är skyddade. Display name är alltid synligt. Dock går det att sätta ett annat displayname på objektet REKOMMENDATION Då det största skyddet erhålls genom att spränga in de användare som har skyddade personuppgifter i AD-strukturen så borde det vara den bästa metoden att använda sig av. Om man är en administratör som har läsrättigheter på AD-objekten som är skyddade så ser det ut för den admin-användaren som vilket AD-konto som helst, detta medför att de konton som har skyddade personuppgifter måste få en notering om att dessa konton är skyddade så att inte uppgifter lämnas ut av misstag. 6