Inloggning och autentisering i Windows

Sammanfattning

Om användaren har ett användarnamn (domäninloggningsnamn) angivet i HSA när certifikatet eller kortet beställs inkluderas det i certifikatet som ett “User Principal Name”. Certifikatet får då också övriga egenskaper som behövs för att det ska gå att använda vid interaktiv inloggning till Windows istället för angivande av användarnamn och lösenord.

Vid denna typ av interaktiv inloggning kommer även inloggning till övriga applikationer som hanterar autentisering med hjälp av samma samma AD-miljö att kunna hanteras via PIN-SSO/Pin-cache. För mer information se rubriken Autentiseringslösningar för SITHS på denna sida.

Förutsättningar

Något av följande krävs för att ge stöd för interaktiv inloggning till Windows tillsammans med SITHS eID på kort:

Lokalt i er organisation

1. Att ni installerar nedan mjukvara på klientdatorerna i er organisation. Information om och nedladdning av mjukvaror för SITHS finns här Programvaror och tillbehör för SITHS

   • Installera SITHS eID-app med tillägget MD (minidriver) på aktuella Windows-datorer

2. Att ni konfigurerar er lokala AD-installation och aktuella AD-konton enligt instruktioner från Microsoft för hur man implementerar stöd för inloggning till Microsoft AD med certifikat från en tredjepartsutfärdare (SITHS)

   1. Se Guidlines for enabling smart card logon with third-party certification authorities

   2. Samt from. 2022Instruktion - Förändring vid inloggning till Windows med SITHS-certifikat

Detaljer

Interaktiv inloggning till en dator (“lokal datorinloggning”) med Windows styrs enligt Windows-arkitekturen av s k autentiseringsmoduler (authentication providers) i operativsystemet. Microsoft rekommenderar inte att byta ut de inbyggda autentiseringsmodulerna till tredje-parts-programvara. Det gör att de autentiseringsmöjligheter som finns är begränsade till det som tillhandahålls i Windows. En sådan möjlighet är att använda smarta kort som följer Microsofts Minidriver-specifikation.

I miljöer där säker åtkomst till applikationerna är det primära och klientdatorerna ses som delade arbetsplatser, kan det vara lämpligast att endast kräva SITHS-kort vid applikationsåtkomst och inte för inloggning till klientdatorn.

Om man vill använda SITHS-kortet för den interaktiva inloggningen till Windows-datorer, kan SITHS eID-appen för Windows installationspaket med tillägget MD användas. I dessa paketeringar ingår

• en minidriver (SAC minidriver) med stöd för SITHS-korten.

• en funktion för att låsa upp ett låst SITHS-kort vid Windows inloggningsskärm med hjälp av upplåsningskod (puk).

Interaktiv inloggning till Windows med SAC minidriver

1. Välj ditt användarnamn

2. Välj Inloggningsalternativ

3. Välj smartkortssymbolen

   1. Det kan finnas flera om flera kortläsare och kort är anslutna till datorn

4. Ange din pin-kod

Open

Notera att inloggningen med SITHS-kortet sker lokalt mot Windows/AD med hjälp av det inbyggda stödet för smarta kort i Windows. I Windows/AD-miljön ställs s.k. Kerberos-biljetter ut för att användaren ska få åtkomst till olika Windows-resurser. Denna teknik är dock inte kopplad till den IdP-baserade inloggning som beskrevs ovan, vilket medför att kortinloggning i Windows/AD i sig inte ger SSO-funktionalitet mot tjänster som är kopplade till IdP.

SITHS eID för Windows i MD-paketnering (med SAC minidriver) i standardutförande en funktion som för SSO mot det smarta kortet som också behöver beaktas utöver eventuell IdP-baserad SSO. Läs mer om PIN-cache/PIN-SSO på denna sida: Autentiseringslösningar för SITHS | Pin cache och Pin SSO.

SITHS eID för Windows i MD-paketering (med SAC minidriver) funktion är att agera drivrutin mot SITHS-kortet och importera certifikaten till Windows-datorns “MyStore” och därigenom göras dem valbara för användaren vid Windows inloggningsskärm förutsatt att AD-miljön har konfigurerats korrekt.

Upplåsning av blockerat kort med PUK vid Windows inloggningsskärm med SAC minidriver

Steg 1	Steg 2	Steg 3	Steg 4	Felhantering

Steg 1	Steg 2	Steg 3	Steg 4	Felhantering
Open Välj Lås upp PIN

Referenser

• Programvaror och tillbehör för SITHS

• Ladda ner SITHS eID Windowsklient

SITHS eID på kort respektive mobil enhet tillsammans med autentiseringslösngar baserade på out-of-band teknik går att integrera som primära alternativt kompletterande autentiseringsmetoder i en lokal Windows-miljö. Detta möjliggör autentisering mot kopplade applikationsresurser i Windows-miljön, t.ex. Office365, Google Apps eller dylikt.

För att åstadkomma detta behöver organisationens AD-installation (Azure AD eller ADFS) anslutas för att konsumera autentiseringsmetoderna som tillhandahålls av Inera Autentiseringstjänst.

Det är även möjligt att integrera en lokal “on-prem” AD-installation med Azure AD och på så sätt skapa en hybrid-lösning där användare som är kopplade till den lokala AD-installationen kan autentiseras via Azure AD, som i sin tur är kopplad till autentiseringsmetoderna för SITHS eID.

Generella förutsättningar

• Lokalt i er organisation

  • Azure AD alternativt ADFS används i rollen som lokal IdP (Legitimeringstjänst). Anslutning för autentiseringsmetoderna görs enligt något av nedanstående anslutningsmönster.

  • Klientprogramvaran SITHS eID-app för Windows-datorer installeras

    • Vid behov laddas SITHS eID-app för mobila enheter ner och användarna hämtar Mobilt SITHS

  • AD-installationen konfigureras med vilka applikationsresurser som ska kräva/använda vilken autentiseringsmetod.

  • Vid behov hanteras eventuell hybridlösning med on-prem AD-installation i kombination med Azure AD.

Anslutningsmönster IdP-proxy

I detta alternativ ansluts AD-installationen till Ineras IdP enligt anslutningsmönstret “IdP-proxy”. Endast Azure AD stöds av Microsoft i detta anslutningsmönster.

Förutsättningar

• Lokalt i er organisation

  • Azure AD används i rollen som lokal IdP. Denna behöver anslutas till Inera IdP för konsumtion av autentiseringsmetoderna SITHS eID på kort respektive mobil enhet.

    • Följ anvisningar för anslutning hos Inera Säkerhetstjänster enligt referens nedan. Se även MS dokumentation för anslutning av en SAML 2.0 Identity Provider (IdP).

• Inera IdP tillhandahåller autentisering med SITHS eID och out-of-band-teknik med hjälp av Inera Autentiseringstjänst.

Anslutningsmönster: Anslutning till Inera Autentiseringstjänst

I detta alternativ ansluts lokal AD FS eller en Azure AD-installation till Inera Autentiseringstjänst.

I denna konfiguration stödjer Microsoft officiellt s.k. multifaktorautentisering (MFA) i Windows-miiljön, vilket innebär att autentisering med SITHS eID kan användas som komplement till en primär autentiseringsmetod. Exempelvis om den primära metoden är användarnamn+lösenord, kan man även kräva autentisering med SITHS eID i ett extra användarsteg.

Förutsättningar

• Lokalt i er organisation

  • AD FS alternativt Azure AD ansluts till Inera Autentiseringstjänst för konsumtion av autentiseringsmetoderna SITHS eID på kort respektive mobil enhet. Följ anvisningar för anslutning hos Inera Säkerhetstjänster.

• Inera Autentiseringstjänst tillhandahåller autentisering med SITHS eID och out-of-band-teknik.

Referenser

• Anslutning till Ineras IdP och legitimering med SITHS eID

• Use a SAML 2.0 Identity Provider (IdP) for Single Sign On

• Hybrid-lösning med AD och Azure AD

  • Integrate on-premises AD with Azure

  • Integrate on-premises AD domains with Azure AD

  • Plan your hybrid Azure Active Directory join implementation

• Inera Referensarkitektur för Identitet och åtkomst

• Configure Additional Authentication Methods for AD FS

• How it works: Azure AD Multi-Factor Authentication