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.
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
Att ni installerar EN av nedan mjukvaror på klientdatorerna i er organisation:
Alt 1 - Installera paket för SITHS eID-app på aktuella Windows-datorer
ELLER Alt 2 - . OBS! from den 31 december 2022 tillhandahåller inte längre Inera licenser för denna mjukvara
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)
Se Guidlines for enabling smart card logon with third-party certification authorities
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 installationspaket för Windows-datorer användas. I en av paketeringarna ingår en Minidriver med stöd för SITHS-korten. I paketeringen ingår även en funktion för att låsa upp ett låst SITHS-kort vid Windows inloggningsskärm med hjälp av upplåsningskod (puk).
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 ut s.k. Kerberos-biljetter 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. Dock har Minidrivern stöd för cachning av pin på datorn vilket i vissa.
Minidrivern eller Net iDs 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.
Referenser