Implementera sömlös enkel inloggning
Contosos IT-team vill ha ett sätt att göra det möjligt för användare att använda enkel inloggning för att få åtkomst till både lokala resurser och resurser i Azure. Sömlös enkel inloggning i Microsoft Entra är en teknik som fungerar med synkronisering av lösenordshash eller direktautentisering.
När sömlös enkel inloggning är aktiverat behöver användarna dessutom sällan skriva in sina användarnamn och aldrig sina lösenord för att logga in på Microsoft Entra-ID. Den här funktionen ger Contosos användare enkel åtkomst till sina molnbaserade program utan att kräva några ytterligare lokala komponenter.
Scenarier som stöds för direktautentisering
Microsoft Entra-direktautentisering hjälper till att säkerställa att tjänster som förlitar sig på Microsoft Entra-ID alltid validerar lösenord mot en lokal AD DS-instans.
Du kan konfigurera Microsoft Entra-direktautentisering med hjälp av Microsoft Entra Connect, som använder en lokal agent som lyssnar efter externa begäranden om lösenordsverifiering. Du kan distribuera den här agenten till en eller flera servrar för att tillhandahålla hög tillgänglighet. Det är inte nödvändigt att distribuera den här servern till ett perimeternätverk eftersom all kommunikation endast är utgående.
Du bör ansluta en server som kör direktautentiseringsagenten till AD DS-domänen där användarna finns. Innan du distribuerar Microsoft Entra-direktautentisering bör du veta vilka autentiseringsscenarier som stöds och vilka som inte stöds.
Du kan använda direktautentisering för följande autentiseringsscenarier:
- Användarinloggningar till alla webbläsarbaserade program som stöds av Microsoft Entra-ID.
- Användarinloggningar till Office-appen som stöder modern autentisering.
- Användarinloggningar till Microsoft Outlook-klienter med hjälp av äldre protokoll, till exempel Exchange ActiveSync, SMTP (Simple Mail Transfer Protocol), Post Office Protocol (POP) och Internet Message Access Protocol (IMAP).
- Användarinloggningar till Skype för företag program som stöder modern autentisering, inklusive online- och hybridtopologier.
- Microsoft Entra-domänanslutningar för Windows 10-enheter.
- Applösenord för multifaktorautentisering.
Scenarier som inte stöds för direktautentisering
Även om direktautentisering stöder de vanligaste autentiseringsscenarierna finns det fortfarande vissa scenarier där du inte kan använda den här metoden. Några vanliga scenarier:
Användarinloggningar till äldre Office-klientprogram, exklusive Outlook.
Kommentar
Dessa äldre klientappar omfattar Office 2010 och Office 2013 utan modern autentisering.
Åtkomst till kalenderdelning och ledig/upptagen-information endast i Exchange-hybridmiljöer på Office 2010.
Användarinloggningar till Skype för företag klientprogram utan modern autentisering.
Användarinloggningar till Windows PowerShell version 1.0.
Identifiering av användare med läckta autentiseringsuppgifter.
Scenarier som kräver Microsoft Entra Domain Services. Microsoft Entra Domain Services kräver att klientorganisationer har aktiverat synkronisering av lösenordshash, så klientorganisationer som endast använder direktautentisering fungerar inte i dessa scenarier.
Scenarier som kräver Microsoft Entra Connect Health. Direktautentisering är inte integrerat med Microsoft Entra Connect Health.
Om du använder Apple Device Enrollment Program (Apple DEP) som använder installationsassistenten för iOS kan du inte använda modern autentisering eftersom den inte stöds. Det går inte att registrera Apple DEP-enheter i Intune för hanterade domäner som använder direktautentisering. Överväg att använda Intune-företagsportal-appen som ett alternativ.
Så här fungerar direktautentisering
Innan du distribuerar direktautentisering bör du förstå hur det fungerar och hur den här autentiseringsmetoden skiljer sig från AD FS. Direktautentisering är inte bara en enklare form av AD FS-autentisering. Båda metoderna använder den lokala infrastrukturen för att autentisera användare vid åtkomst till resurser som Microsoft 365, men inte på samma sätt.
Direktautentisering använder en komponent som kallas autentiseringsagent för att autentisera användare. Microsoft Entra Connect installerar autentiseringsagenten under konfigurationen.
Efter installationen registrerar sig autentiseringsagenten i Microsoft 365-klientorganisationens Microsoft Entra-ID. Under registreringen tilldelar Microsoft Entra-ID autentiseringsagenten ett unikt certifikat för digital identitet. Det här certifikatet (med ett nyckelpar) möjliggör säker kommunikation med Microsoft Entra-ID. Registreringsproceduren binder även autentiseringsagenten till din Microsoft Entra-klientorganisation.
Kommentar
Autentiseringsbegäranden skickas inte till autentiseringsagenten. Under initieringen ansluter autentiseringsagenten i stället till Microsoft Entra-ID via port 443, en HTTPS-kanal som skyddas med hjälp av ömsesidig autentisering. När anslutningen har upprättats ger Microsoft Entra-ID autentiseringsagenten åtkomst till Azure Service Bus-kön. Från den här kön hämtar och hanterar autentiseringsagenten begäranden om lösenordsverifiering. Därför finns det ingen inkommande trafik, så det är inte nödvändigt att installera autentiseringsagenten i perimeternätverket.
Exempel
När Contosos IT-personal aktiverar direktautentisering i sin Microsoft 365-klientorganisation och en användare försöker autentisera i Outlook Web App utförs följande steg:
Om användaren inte redan är inloggad omdirigeras den till Microsoft Entra-användarens inloggningssida . På den här sidan loggar användaren in med ett användarnamn och lösenord. Microsoft Entra ID tar emot begäran om att logga in och placerar användarnamnet och lösenordet i en kö. En Microsoft Entra-säkerhetstokentjänst (STS) använder den offentliga autentiseringsagentens offentliga nyckel för att kryptera dessa autentiseringsuppgifter. STS-tjänsten hämtar den här offentliga nyckeln från certifikatet som autentiseringsagenten tar emot under registreringsprocessen.
Kommentar
Även om Microsoft Entra-ID tillfälligt placerar användarautentiseringsuppgifter i Azure Service Bus-kön lagras de aldrig i molnet.
Autentiseringsagenten, som är beständigt ansluten till Azure Service Bus-kön, märker ändringen i kön och hämtar de krypterade autentiseringsuppgifterna från kön. Eftersom autentiseringsuppgifterna krypteras med den offentliga nyckeln för autentiseringsagenten använder agenten sin privata nyckel för att dekryptera data.
Autentiseringsagenten verifierar användarnamnet och lösenordet mot den lokala AD DS med hjälp av standard-Windows-API:er. I det här läget liknar den här mekanismen vad AD FS använder. Ett användarnamn kan vara antingen det lokala standardanvändarnamnet, vanligtvis
userPrincipalName, eller ett annat attribut som konfigurerats i Microsoft Entra Connect, som kallas alternativt ID.Den lokala AD DS utvärderar begäran och returnerar lämpligt svar till autentiseringsagenten: lyckades, misslyckades, lösenordet har upphört att gälla eller användaren är utelåst.
När den har fått svaret från AD DS returnerar autentiseringsagenten det här svaret till Microsoft Entra-ID.
Microsoft Entra-ID utvärderar svaret och svarar användaren efter behov. Till exempel loggar Microsoft Entra-ID antingen in användaren omedelbart eller begär multifaktorautentisering. Om användaren har loggat in kan användaren komma åt programmet.
Kommentar
Du kan överväga att distribuera sömlös enkel inloggning i Microsoft Entra tillsammans med direktautentisering för att göra användarupplevelsen ännu bättre vid åtkomst till molnbaserade resurser från domänanslutna datorer. När du distribuerar den här funktionen kan användarna komma åt molnresurser utan att logga in om de redan är inloggade på sina företagsdomänanslutna datorer med sina domänautentiseringsuppgifter.
Mer att läsa
Läs mer i följande dokument.