Du kan välja mellan tre huvudsakliga identitetsmodeller i Office 365 när du konfigurerar och hanterar användarkonton:
Hantera endast dina användarkonton i Office 365. Inga lokala servrar krävs för att hantera användare. Allt görs i molnet. |
Synkronisera lokala katalogobjekt med Office 365 och hantera dina användare lokalt. Du kan också synkronisera lösenord så att användarna har samma lösenord lokalt och i molnet, men de måste logga in igen för att kunna använda Office 365. |
Synkronisera lokala katalogobjekt med Office 365 och hantera dina användare lokalt. Användarna har samma lösenord lokalt och i molnet, och de behöver inte logga in igen för att använda Office 365. Det här kallas ofta för enkel inloggning. |
Det är viktigt att noga överväga vilken identitetsmodell som ska användas för att komma igång. Tänk på tid, befintlig komplexitet och kostnad. Dessa faktorer är olika för varje organisation; I det här avsnittet går vi igenom de här viktiga begreppen för varje identitetsmodell för att hjälpa dig att välja den identitet som du vill använda för distributionen.
Du kan också växla till en annan identitetsmodell om dina krav ändras.
I den här modellen skapar och hanterar du användare i Microsoft Office-portalen och lagrar kontona i Azure AD. Azure AD verifierar lösenorden. Azure AD är molnkatalogen som används av Office 365. Inga lokala servrar krävs – Microsoft hanterar allt det åt dig. När identitet och autentisering hanteras helt i molnet kan du hantera användarkonton och användarlicenser via Microsoft Online-portalen eller Windows PowerShell-cmdlets.
I följande bild sammanfattas hur du hanterar användare i molnidentitetsmodellen.
Administratören ansluter till Microsoft Online-portalen på Microsoft-molnplattformen för att skapa eller hantera användare.
Begäranden om att skapa eller hantera skickas vidare till Azure AD.
Om det är en ändringsbegäran görs ändringen och kopieras tillbaka till Microsoft Office-portalen
Nya användarkonton och ändringar av befintliga användarkonton kopieras tillbaka till Microsoft Office-portalen.
När ska du använda Cloud Identity? Molnidentitet är ett bra val om:
Om du har en befintlig katalogmiljö lokalt kan du integrera Office 365 med din katalog genom att använda antingen synkroniserad identitet eller enkel inloggning och samlad identitet för att skapa och hantera dina användare i Office 365.
I den här modellen hanterar du användaridentiteten på en lokal server och synkroniserar kontona och, om du vill, lösenorden till molnet. Användaren anger samma lösenord lokalt som han eller hon gör i molnet, och vid inloggningen verifieras lösenordet av Azure AD. Den här modellen använder ett katalogsynkroniseringsverktyg för att synkronisera den lokala identiteten till Office 365.
Om du vill konfigurera den synkroniserade identitetsmodellen måste du ha en lokal katalog att synkronisera från och du måste installera ett katalogsynkroniseringsverktyg. Du kör några konsekvenskontroller i den lokala katalogen innan du synkroniserar kontona.
När du ska använda synkroniserade eller federerade identiteter:
Den här modellen: |
Fungerar i följande situationer: |
Synkroniserade identiteter |
När du har en lokal katalog och du vill synkronisera användarkonton och eventuellt lösenord. Om du även synkroniserar lösenord använder användarna samma lösenord för att komma åt lokala resurser och Office 365. När du i slutändan vill ha federerade identiteter, men du kör en pilot av Office 365 eller av någon annan anledning, inte är redo att ägna tid åt att distribuera Active Directory Federation Services (AD FS)-servrarna (AD FS) ännu. |
Federerade identiteter |
När du behöver ett avancerat scenario, till exempel: befintliga federations-, princip- eller tekniska krav |
Följande diagram visar ett scenario med synkroniserad identitet med en lösenordssynkronisering. Synkroniseringsverktyget håller dina lokala och molnbaserade företagsanvändaridentiteter synkroniserade.
Du installerar en Microsoft Azure Active Directory Connect.
Du skapar nya användare i din lokala katalog.
Synkroniseringsverktyget kontrollerar regelbundet om det finns nya identiteter som du har skapat i den lokala katalogen. Sedan etablerar den dessa identiteter i Azure AD, länkar de lokala identiteterna och molnidentiteterna till varandra, synkroniserar lösenord och gör dem synliga för dig via Microsoft Office-portalen.
När du gör ändringar i användarna i den lokala katalogen synkroniseras dessa ändringar till Azure AD och görs tillgängliga för dig via Microsoft Office-portalen.
Den här modellen kräver en synkroniserad identitet, men med en ändring av modellen: användarlösenordet verifieras av den lokala identitetsprovidern. Det innebär att lösenordshashen inte behöver synkroniseras till Azure AD. Den här modellen använder Active Directory Federation Services (AD FS) (AD FS) eller en identitetsprovider från tredje part.
Orsakerna till att använda en federerad identitet är:
Befintlig infrastruktur
Tekniska krav
Policykrav
Följande diagram visar ett scenario med federerad identitet med en lokal hybrid- och molndistribution. Den lokala katalogen i det här exemplet är AD FS. Synkroniseringsverktyget håller dina lokala och molnbaserade företagsanvändaridentiteter synkroniserade.
Du installerar Azure Active Directory Connect Synkroniseringsverktyget hjälper till att hålla Azure AD uppdaterat med de senaste ändringarna du gör i din lokala katalog. Du måste använda en anpassad installation av Azure AD Connect för att konfigurera enkel inloggning.
Du skapar nya användare i din lokala Active Directory.
Synkroniseringsverktyget kontrollerar regelbundet din lokala Active Directory-server för eventuella nya identiteter som du har skapat. Sedan etablerar den dessa identiteter i Azure AD, länkar de lokala identiteterna och molnidentiteterna till varandra och gör dem synliga för dig via Microsoft Office-portalen.
När ändringar görs i identiteten i lokal Active Directory synkroniseras dessa ändringar till Azure AD.
Dessa ändringar görs tillgängliga för dig via Microsoft Office-portalen.
Dina federerade användare loggar in med din AD FS.
AD FS genererar en säkerhetstoken och denna token skickas till Azure AD. Token verifieras och verifieras och användarna auktoriseras sedan för Office 365.