|
Klicka nedan för att läsa mer om inloggning till Windows-dator med SITHS eID på kort.
Support kring interaktiv inloggning till Windows-datorer med SITHS eID på kort hanteras dock inte via Inera. Hjälp med att aktivera detta och support vid problem måste säkras via egna supportavtal om din organisation inte känner sig säker på att kunna hantera detta med egna resurser. |
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ättningarNå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
DetaljerInteraktiv 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
Interaktiv inloggning till Windows med SAC minidriver
![]() 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: https://inera.atlassian.net/wiki/spaces/IAM/pages/2895216838/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
Referenser |
Detta scenario stödjer inte inloggning vid Windows-datorer via inloggningsskärmen. Utan endast inloggning till applikationer efter att användaren loggat in på Windows-datorn. För information om inloggning till Windows se avsnittet Interaktiv inloggning till Windows-dator med SITHS-kort ovan. |
Klicka nedan för att läsa mer om inloggning till applikationer efter att du loggat in till Windows-datorn då även användning av SITHS eID-appen och Mobilt SITHS stöds.
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
Anslutningsmönster IdP-proxyI 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
![]() Anslutningsmönster: Anslutning till Inera AutentiseringstjänstI 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
![]() Referenser
|