Active Directory
Microsoft tillhandahåller två olika katalogtjänster. Dels finns Microsoft Account som ofta används för privata ändamål, dels Azure AD som är till för att hantera konton för företagstjänster.

I dag är det allt vanligare att företag går över till Office 365 istället för att fortsätta underhålla en egen lokal lösning för produkterna Exchange, Lync och Sharepoint. Ett av skälen till att många vill gå över är att man vill ha tillgång till de senaste versionerna av produkterna utan att själv behöva lägga tid och pengar på underhåll och uppgraderingar.

I flera avseenden är tjänsterna färdiga och det är inte så mycket att konfigurera, men det finns ett område där det ofta uppstår debatter och tyckanden: kontohanteringen. Här finns flera olika alternativ, och vi ska titta på dem en efter en.

Först ska vi dock reda ut en viktig punkt som förvirrar många. Det har sedan många år tillbaka funnits en separat katalogtjänst för privata konton för olika Microsoft-tjänster, till exempel Xbox och Hotmail. De kontona har haft många olika namn genom åren – Passport, Live ID och nu senast kort och gott Microsoft Account.

När Microsoft började skapa professionella molntjänster som Office 365 uppstod behovet av en separat katalogtjänst där företag kunde samla sina användarkonton, separat från de privata konton som folk redan använde. Denna nya skapelse kallas Azure AD.

Azure AD
Även om vi ser användarna i O ce 365- portalen är de egentligen placerade i Azure AD, och vi kan se samma användare i Azure. I portalen kan vi också bland annat genomföra ytterligare konfi - guration kring användarna och ta ut rapporter.

Det finns däremot inget som hindrar att man har samma användarnamn på sitt Microsoft Account och sitt konto i Azure AD, och man får då en fråga vid inloggning vilken katalogtjänst man vill logga in mot. Det här är viktigt att förstå, men under resten av den här artikeln kommer vi att hålla oss uteslutande till Azure AD.

Denna nya katalogtjänst används för att hålla konton för Office 365, Intune och andra professionella tjänster från Microsoft. Idag är det Exchange, Lync och SharePoint som utnyttjar tjänsten i Office 365, men inget hindrar Microsoft från att i framtiden knyta allt fler tjänster till konton i Azure AD. Vilka olika möjligheter har vi då att hantera konton i molnet?

Det är tre huvudsakliga modeller som gäller, var och en med sina för- och nackdelar:

1. Konton enbart i molnet

Den allra enklaste modellen att använda sig av är att enbart ha sina användarkonton placerade i molnet, helt separat från en eventuell lokal katalogtjänst.

Du lägger upp, förändrar och tar bort konton direkt i molnet antingen via webbportalen i Office 365 eller via Powershell. Lösenord byter användarna själva i portalen, och du kan också aktivera multifaktorinloggning för ökad säkerhet.

Den här lösningen används ofta i mindre och medelstora företag där målet med en övergång till molnet ofta är att minska lokal infrastruktur och minimera administrativa insatser och konsulthjälp.

Nackdelen med den här modellen är att användarna måste minnas ett separat lösenord för molnkontot och administratören manuellt måste justera förändringar på attribut i både lokalt AD och i molnet, till exempel vid byte av adress eller efternamn.

Det är också den enda modellen du kan använda om du helt vill ta bort din gamla Exchange-server. Anledningen till det är att du i de andra två modellerna vi ska nämna här måste ha kvar den gamla servern för att hantera e-postattribut. Det här blir alltså en vanlig modell för företag som vill minska sin lokala it-administration. Det kanske skulle smaka?

2. Synkronisering med AADSync

Ett annat alternativ är att man synkroniserar sitt lokala AD med Azure AD med AADSync, Azure Active Directory Synchronization. Användaren kommer fortfarande att ha två olika konton, men attributen på de lokala kontona kommer var tredje timme att replikeras ut till molnet. Om man vill kan också lösenordet överföras ut till molnet så att användaren får en upplevelse av att det är samma konto som finns på båda ställena.

Byter användaren lösenord i lokalt AD replikeras det nya lösenordet inom två minuter ut till Azure AD. Därefter kan användaren logga in med samma lösenord i molnet som i den lokala miljön.

Det här är förstås mycket praktiskt och minskar administrationen kring användarkonton, men du betalar ett pris för denna fördel. Den främsta nackdelen är att du behöver fortsätta ha en lokal Exchange-server kvar i din lokala miljö – det är ju det påbjudna Microsoft-sättet att hantera e-postrelaterade attribut i lokalt AD, som sedan replikeras ut till Azure AD och används där av Exchange Online i Office 365.

Många företag går över till en molnlösning för att slippa hantera lokal infrastruktur, och det sig är en tillräcklig anledning för att välja en lösning med enbart konton i molnet.

Om du ändå väljer den här lösningen så tänk på att du behöver säkerställa några extra saker vid migreringen till Office 365. Till exempel måste du om du använder cut overmigrering se till att e-postadresser och UPN-loginnamn i lokalt AD stämmer överens med de konton som skapades i molnet vid migreringen. Annars kommer soft match-funktionen av loginnamn mot e-postadress inte att få trä på rätt konton när du startar katalog-synkroniseringen. Du måste nämligen först slutföra e-postmigreringen för att sedan bums sätta fart på AADSync för att överföra lösenorden från din lokala katalogtjänst. Konfiguration av AADSync blir ofta en tidskänslig åtgärd där mycket ska stämma för att det ska bli rätt.

Med den här lösningen kan du inte skapa nya brevlådor direkt i molnet, utan du skapar ett konto i lokalt AD med e-postattribut som sedan replikeras till Office 365. Sedan tilldelar du en licens till den synkroniserade lådan några timmar senare. Du kan också använda Powershell-kommandot New-Remotemailbox för att genomföra allt i ett steg.

Vi hoppas att Microsoft ger bättre möjligheter att använda AADSync i framtiden och inför dubbelriktad replikering, för idag är lösningen inte alldeles enkel och effektiv att upprätthålla.

Men om man testar det här alternativet och ångrar sig är det enkelt att slå av AADSync i portalen, och från och med då enbart använda molnkonton. AADSync kan också på det sättet användas enbart för att populera Azure AD med konton.

3. ADFS

Den här modellen baseras på tjänsten ADFS, Active Directory Federation Services, i Windows Server 2012 R2. Lösningen kräver en ganska omfattande lokal infrastruktur som kanske till och med överstiger den du hade tidigare – modellen används främst hos de större och mest komplexa företagen som har väldigt specifika krav.

En komplett lösning består av minst fem servrar som fördelas så här: 2 stycken ADFS-servrar, 2 stycken WAP-servrar (Web Application Proxy) och 1 AADSync-server. Man har två av varje roll för att få bättre feltolerans.

ADFS ger samma för- och nackdelar som AADSync medför eftersom AADSync används tillsammans med ADFS, men tillför också fördelar i sig.

När en användare befinner sig på en extern enhet, till exempel en hemmadator, och försöker logga in i Office 365 via webbportalen styrs han eller hon automatiskt om till de företagsinterna WAP-servrarna och erbjuds där ett formulär för inloggning.

Användaren verifieras sedan via ADFS-servrarna mot lokalt AD, och om uppgifterna stämmer släpps användaren in i Office 365.

Om användaren sitter på interna nätverket inloggad med ett domänkonto får han eller hon en äkta ssoupplevelse (single sign-on) och släpps rakt in i Office 365 utan att behöva ange användarnamn eller lösenord.

Det här fungerar för Lync och Sharepoint, men Outlook kan idag inte använda ADFS för sso, utan där tvingas man logga in manuellt oavsett vilken av de tre olika modellerna man väljer. Givetvis kan lösenordet sparas så att det blir enkelt att använda, men äkta sso uppnås inte med Outlook. Microsoft uppger dock att en ändring på detta kommer att ske inom kort.

Nackdelarna med ADFS är främst den utökade lokala infrastruktur som behövs, och den expertis som krävs för att konfigurera och underhålla.

Att senare försöka lämna en lösning baserad på ADFS kan vara komplicerat. Det är inte svårt att med Powershell slå av själva funktionen, men vid de tester vi gjort fick detta svåra konsekvenser för användarna och vi fick skapa om lokala e-postprofiler för att få fart på e-posten igen.

Sammanfattning - de 3 alternativen:

molnkonto
Enbart molnkonton

Konton enbart i molnet: I den lösningen har du separata användarkonton i molnet och ingen integration med lokalt AD. Enkelt att använda, men ger separat administration av alla konton i molnet.

+Enkel administration. Du slipper helt lokal infrastruktur. Allt kan göras via portal i molnet för både admins och användare.
-Separat katalogtjänst att underhålla. Dubbla lösenord är sällan populärt hos användarna.

AADSync

AADSync

Synkronisering med AADSync: I den här modellen synkroniseras konto-attribut och lösenord från lokalt AD till molnet. Det kan minska konto-administrationen, men kräver lokal infrastruktur och en lokal Exchange-server

+Samma lösenord lokalt som i molnet. Alla attribut synkroniseras automatiskt till molnet. Man slipper underhålla två katalogtjänster. Samma komplexitetskrav i molnet som i lokalt AD.
-Lokal Exchange-server kostar pengar. Molnet får ett beroende av lokal miljö. Användare kan inte byta lösenord i molnet. Ger inte sso, bara samma lösenord. Administration av användare kan inte ske i portalen eller med Powershell i molnet. Svårare migrering med softmatch.

ADFS

ADFS

Användaren loggar in mot Azure AD (1), men blir omstyrd till en lokal ADFS-server (2). Autentiseringen sker mot lokalt AD och användaren blir sedan insläppt i Office 365 (3). Modellen kräver omfattande lokal infrastruktur och kunskap, men ger sso för Lync och webbläsare (för till exempel Sharepoint).

+Sso för webbläsare och Lync. Man kan styra finmaskigt när olika personer får logga in. Plus fördelarna med AADSync.
-Betyder kanske ännu mer lokal infrastruktur än man hade innan övergången till molnet. Komplext att underhålla. Ger i dag inte sso med Outlook. Användarna kommer inte åt e-post med mera om ADFS kraschar lokalt (kan lösas med manuell och tidsödande insats). Plus alla nackdelar med AADSync.

Kom ihåg: Molnet kan hjälpa dig

Om du väljer AADSync- eller ADFSmodellen kan en extern molntjänst hjälpa till att driva den infrastruktur som behövs om du inte vill ha den på egna servrar. Använder du Azure Virtual Machines kan du, efter att ha etablerat en sajt-till-sajt-vpn-förbindelse mellan molnet och ditt lokala nätverk, skapa en domänkontrollant (dc) i Azure och där också skapa dina AADSync och/eller ADFS-servrar.

På det sättet får du en rent molnbaserad lösning för identitets-hanteringen utan att behöva investera i lokal hårdvara eller licenser. Men det är givetvis en kostnad förknippad med en sådan molnlösning, vilket förstås bör vägas in vid beslutet om vilken design som ska användas.

TechWorlds slutsats

Vi har alltså två olika huvudsakliga katalogtjänster från Microsoft i molnet, MS-konton och Azure AD-baserade konton. Vidare finns tre olika modeller för kontohantering i Azure AD, alla med olika grad av beroende till den lokala miljön.

Det finns inget självklart svar på vilken av de tre modellerna just du ska använda – du måste själv fundera över vilka krav du har på lösningen och vad som är acceptabelt för användarna, väga detta mot konsekvenserna av varje lösning och sedan fatta ett beslut.

Experten:
”Det handlar om framtiden för it-avdelningen”

Vi tog kontakt med Jesper Ståhle, Microsoft MVP inom området Jesper StåhleOffice 365 på Avanade.

Hur bör företag resonera angående sitt lokala AD? Kommer AD att tappa sin roll på längre sikt?

– Till att börja med måste man inse vidden av den här frågan, och att det inte bara handlar om framtiden för Active Directory. Det handlar om framtiden för it-avdelningens roll – om att föregå eller föregås.

Molnet och mjukvara som tjänst handlar inte bara om ett annat sätt att köpa tjänster, det handlar om att nya verktyg blir tillgängliga direkt för olika delar av verksamheten.

Om it-avdelningen inte har en tydlig molnstrategi där man kan svara sin verksamhet på frågorna ”Vi behöver den här tjänsten för att utföra vårt uppdrag, hur tycker ni att vi ska göra med säkerhet och användarkonton? Kan ni ta hand om det åt oss?” kommer verksamheten att kringgå it-avdelningen, köpa de tjänsterna på sitt kreditkort och skapa identiteter i tjänsten på egen hand.

När det sker har man tappat all kontroll och säkerhet över de data som lagras i molntjänsterna – alltså ett klassiskt fall av skugg-it, eller rogue it som det kallas på engelska.

Om it-avdelningen istället författar en molnstrategi, med en plan för hur man ska hjälpa verksamheten med att implementera de molntjänster som de behöver, och vilka krav som ställs kring identiteter, har man plötsligt förvandlat it-avdelningen till verksamhetens samarbetspartner i de frågorna.

I praktiken kan det innebära att it-avdelningen hjälper verksamheten att implementera molntjänsten på ett kontrollerat sätt så att verksamheten inte behöver administrera användarkonton, och kanske även få mervärde i form av sso.

Så – Active Directory eller Azure AD?

– Alla företag med en molnstrategi bör helt klart investera i Azure AD i någon form. Frågan om man ska behålla och integrera med Active Directory bör avgöras av det mervärde Active Directory kan ge idag, som inte Azure AD kan ännu. Det kan vara till exempel ldap-integrationer, sso med Windows-inloggning eller klassisk Group Policy. Om det mervärdet inte kan motivera kostnaden för att behålla Active Directory är saken avgjord.

Men spelplanen förändras snabbt, till exempel kommer man kunna ansluta Windows 10 till Azure AD, vilket förändrar hela sso-aspekten. Så i sin molnstrategi bör det ingå att man omvärderar läget med jämna mellanrum.

En sak är säker – det har aldrig varit mer relevant att ha koll på sina identiteter och sitt Active Directory än idag.


Illustrationer: Jonas Englund


CITE Conference till Stockholm 21-22 april! 

Här samlas alla typer av IT-beslutsfattare för att prata om digitaliseringen som driver framtidens affärer.

Fokus ligger på mobilitet, säkerhet, molnet och big data.

http://cite.event.idg.se

Fakta

tinytw.se/installadfs – Technet har en utmärkt guide kring hur du sätter upp ADFS.

tinytw.se/365poster – En nyttig poster som du bör ha på väggen om du jobbar med Office 365 och identiteter.