Inloggegevensprocessen in Windows-authenticatie

Windows-verificatie is een hoeksteen van veilige toegang in bedrijfsomgevingen, waardoor gebruikers en services kunnen communiceren met systemen terwijl gevoelige informatie wordt beveiligd. Dit artikel biedt IT-professionals een uitgebreid overzicht van hoe Windows referenties verwerkt tijdens verificatie. Het omvat belangrijke onderdelen, mechanismen en architecturen die betrokken zijn bij referentiebeheer, validatie en opslag, en zorgt voor een duidelijk begrip van het verificatieproces in verschillende Windows-besturingssystemen.

Deze onderdelen worden met name behandeld:

• Overzicht van verificatie van Windows-referenties

• referentie-invoer voor gebruikersaanmelding

• referentie-invoer voor aanmelding bij toepassingen en services

• lokale beveiligingsautoriteit

• In cache opgeslagen referenties en validatie

• opslag en validatie van inloggegevens

• Security Accounts Manager-database

• lokale domeinen en vertrouwde domeinen

• Certificaten in Windows-Verificatie

Overzicht van verificatie van Windows-referenties

Het beheer van Windows-referenties is het proces waarmee het besturingssysteem de referenties van de service of gebruiker ontvangt en die informatie voor toekomstige presentatie beveiligt voor het verifiërende doel. Als een computer lid is van een domein, is het verificatiedoel de domeincontroller. De referenties die in verificatie worden gebruikt, zijn digitale documenten die de identiteit van de gebruiker koppelen aan een vorm van echtheidsbewijs, zoals een certificaat, een wachtwoord of een pincode.

Standaard worden Windows-referenties gevalideerd op basis van de SAM-database (Security Accounts Manager) op de lokale computer of met Active Directory op een computer die lid is van een domein, via de Winlogon-service. Referenties worden verzameld via gebruikersinvoer op het aanmeldscherm of programmatisch via de API (Application Programming Interface) om te worden gepresenteerd aan het systeem dat de verificatie uitvoert.

Lokale beveiligingsgegevens worden opgeslagen in het register onder HKEY_LOCAL_MACHINE\SECURITY. Opgeslagen informatie bevat beleidsinstellingen, standaardbeveiligingswaarden en accountgegevens, zoals aanmeldingsreferenties in de cache. Een kopie van de SAM-database wordt hier ook opgeslagen, hoewel deze tegen schrijven beveiligd is.

In het volgende diagram ziet u de onderdelen die vereist zijn en de paden die authenticatiegegevens door het systeem nemen om de gebruiker of het proces te authenticeren voor een geslaagde aanmelding.

In de volgende tabel wordt elk onderdeel beschreven dat inloggegevens beheert in het verificatieproces tijdens het aanmelden voor alle systemen.

Referentie-invoer voor gebruikersaanmelding

De architectuur van de referentieprovider, die is geïntroduceerd in Windows Server 2008, is het primaire mechanisme voor het verzamelen van gebruikersreferenties tijdens het aanmelden. Het biedt een flexibele en uitbreidbare manier om referenties van gebruikers te verzamelen, zoals wachtwoorden, smartcards of biometrie. De architectuur van de referentieprovider vervangt de oudere GINA-architectuur (Graphical Identification and Authentication) die in eerdere versies van Windows wordt gebruikt.

Architectuur van referentieprovider

De architectuur van de referentieprovider maakt gebruik van een uitbreidbaar ontwerp met behulp van referentieproviders. Verschillende aanmeldingstegels vertegenwoordigen deze providers op het beveiligde bureaublad die een willekeurig aantal aanmeldingsscenario's toestaan, waaronder verschillende accounts voor dezelfde gebruiker en verschillende verificatiemethoden, zoals wachtwoord, smartcard en biometrische gegevens.

In het volgende diagram ziet u het referentieproces voor de architectuur van de referentieprovider:

Winlogon start het aanmeldingsproces Logon UI altijd nadat het een Secure Attention Sequence (SAS) gebeurtenis heeft ontvangen. De aanmeldingsinterface stelt aan elke referentieprovider de vraag hoeveel verschillende referentietypen de provider is ingesteld om te tellen. Aanbieders van inloggegevens kunnen een van deze tegels als standaard instellen. Nadat alle providers hun tegels hebben opgesomd, worden ze in de aanmeldingsinterface aan de gebruiker weergegeven. De gebruiker communiceert met een tegel om hun referenties op te geven. Het aanmeldscherm verzendt deze referentiegegevens ter verificatie van gebruikers.

Referentieproviders zijn geen afdwingingsmechanismen; ze worden gebruikt om referenties te verzamelen en te serialiseren. De lokale beveiligingsinstantie en verificatiepakketten dwingen beveiliging af.

Referentieproviders zijn geregistreerd op de computer en zijn verantwoordelijk voor de volgende taken:

• Beschrijving van de referentiegegevens die vereist zijn voor verificatie.

• Communicatie en logica verwerken met externe verificatie-instanties.

• Referenties verpakken voor interactieve aanmelding en netwerkaanmelding.

Het verpakken van referenties voor interactieve aanmelding en netwerkaanmelding omvat het serialisatieproces. Door referenties te serialiseren, kunnen meerdere aanmeldingstegels worden weergegeven aan een gebruiker. Daarom kan uw organisatie de aanmeldingsweergave beheren, zoals gebruikers, doelsystemen voor aanmelding, pre-aanmeldingstoegang tot het beleid voor netwerk- en werkstationvergrendeling/-ontgrendeling, met behulp van aangepaste referentieproviders. Meerdere referentieproviders kunnen coëxisteren op dezelfde computer. Providers voor eenmalige aanmelding (SSO) kunnen worden ontwikkeld als een standaardreferentieprovider of als een pre-aanmeldingstoegangsprovider (PLAP).

Elke versie van Windows bevat één standaardreferentieprovider en één standaardaanmeldingstoegangsprovider, ook wel bekend als de SSO-provider. Met de SSO-provider kunnen gebruikers verbinding maken met een netwerk voordat ze zich aanmelden bij de lokale computer. Wanneer deze provider is geïmplementeerd, worden tegels in de aanmeldingsinterface niet opgesomd door de provider.

Een SSO-provider is bedoeld voor gebruik in de volgende scenario's:

• Netwerkverificatie en computerlogin worden verwerkt door verschillende aanmeldingsproviders, waaronder de volgende variaties in dit scenario:

  • Een gebruiker heeft de mogelijkheid om verbinding te maken met een netwerk, zoals verbinding maken met een virtueel particulier netwerk (VPN), voordat hij zich aanmeldt bij de computer, maar deze verbinding niet hoeft te maken.

  • Netwerkverificatie is vereist om informatie op te halen die wordt gebruikt tijdens interactieve verificatie op de lokale computer.

  • Meerdere netwerkverificaties worden gevolgd door een van de andere scenario's. Een gebruiker wordt bijvoorbeeld geverifieerd bij een internetprovider (ISP), wordt geverifieerd bij een VPN en gebruikt vervolgens de referenties van het gebruikersaccount om zich lokaal aan te melden.

  • Referenties in de cache zijn uitgeschakeld en er is een VERBINDING met Remote Access Services via VPN vereist voordat lokale aanmelding voor verificatie van de gebruiker vereist is.

  • Een domeingebruiker heeft geen lokaal account ingesteld op een computer die lid is van een domein en moet een REMOTE Access Services-verbinding tot stand brengen via een VPN-verbinding voordat een interactieve aanmelding wordt voltooid.

• Netwerkverificatie en computeraanmelding worden verwerkt door dezelfde referentieprovider, waarbij de gebruiker verbinding moet maken met het netwerk voordat deze zich aanmeldt bij de computer.

Opsomming van aanmeldingstegel

De referentieprovider somt aanmeldingstegels op in de volgende gevallen:

• Voor inloggen op een werkstation. De referentieprovider serialiseert doorgaans referenties voor verificatie bij de lokale beveiligingsinstantie. In dit proces worden tegels weergegeven die specifiek zijn voor elke gebruiker en specifiek voor de doelsystemen van elke gebruiker.

• Met de aanmeldings- en verificatiearchitectuur kan een gebruiker tegels gebruiken die door de referentieprovider zijn geïnventariseerd om een werkstation te ontgrendelen. Normaal gesproken is de momenteel aangemelde gebruiker de standaardtegel, maar als meer dan één gebruiker is aangemeld, worden er talloze tegels weergegeven.

• De referentieprovider inventariseert tegels als reactie op een gebruikersaanvraag om hun wachtwoord of andere persoonlijke gegevens te wijzigen, zoals een pincode. Normaal gesproken is de momenteel aangemelde gebruiker de standaardtegel, maar als meer dan één gebruiker is aangemeld, worden er talloze tegels weergegeven.

• De referentieprovider inventariseert tegels op basis van de geserialiseerde referenties die moeten worden gebruikt voor verificatie op externe computers. De Credential UI gebruikt niet hetzelfde exemplaar van de provider als de aanmeldings-UI, het ontgrendelen van een werkstation, of bij het wijzigen van een wachtwoord. Daarom kan statusinformatie niet worden onderhouden in de provider tussen exemplaren van de inloggegevensinterface. Deze structuur resulteert in één tegel voor elke externe computerinlog, ervan uitgaande dat de referenties correct geserialiseerd zijn. Dit scenario wordt ook gebruikt in UAC (User Account Control), waarmee onbevoegde wijzigingen in een computer kunnen worden voorkomen door de gebruiker om toestemming of een beheerderswachtwoord te vragen voordat acties worden toegestaan die mogelijk van invloed kunnen zijn op de bewerking van de computer of die instellingen kunnen wijzigen die van invloed zijn op andere gebruikers van de computer.

Referentie-invoer voor aanmelding bij toepassingen en services

Windows-verificatie is ontworpen voor het beheren van referenties voor toepassingen of services waarvoor geen gebruikersinteractie is vereist. Toepassingen in de gebruikersmodus zijn beperkt in termen van de systeembronnen waartoe ze toegang hebben, terwijl services onbeperkte toegang kunnen hebben tot het systeemgeheugen en externe apparaten.

Systeemservices en toepassingen op transportniveau hebben toegang tot een SSP (Security Support Provider Provider) via de SSPI (Security Support Provider Interface) in Windows, die functies biedt voor het inventariseren van de beveiligingspakketten die beschikbaar zijn op een systeem, het selecteren van een pakket en het gebruik van dat pakket om een geverifieerde verbinding te verkrijgen.

Wanneer een client-/serververbinding wordt geverifieerd:

• De toepassing aan de clientzijde van de verbinding verzendt referenties naar de server met behulp van de SSPI-functie InitializeSecurityContext (General).

• De toepassing aan de serverzijde van de verbinding reageert met de SSPI-functie AcceptSecurityContext (General).

• De SSPI-functies InitializeSecurityContext (General) en AcceptSecurityContext (General) worden herhaald totdat alle benodigde verificatieberichten worden uitgewisseld om verificatie te voltooien of te mislukken.

• Nadat de verbinding is geverifieerd, gebruikt de LSA op de server informatie van de client om de beveiligingscontext te bouwen, die een toegangstoken bevat.

• De server kan vervolgens de SSPI-functie aanroepen ImpersonateSecurityContext om het toegangstoken te koppelen aan een imitatiethread voor de service.

Toepassingen en gebruikersmodus

De gebruikersmodus in Windows bestaat uit twee systemen die I/O-aanvragen kunnen doorgeven aan de juiste kernelmodusstuurprogramma's: het omgevingssysteem, dat toepassingen uitvoert die zijn geschreven voor veel verschillende typen besturingssystemen en het integrale systeem, dat systeemspecifieke functies uitvoert namens het omgevingssysteem.

Het integrale systeem beheert besturingssysteemspecifieke functies namens het omgevingssysteem en bestaat uit een beveiligingssysteemproces (de LSA), een werkstationservice en een serverservice. Het beveiligingssysteem verwerkt beveiligingstokens, verleent of weigert machtigingen voor toegang tot gebruikersaccounts op basis van resourcemachtigingen, verwerkt aanmeldingsaanvragen en initieert aanmeldingsverificatie en bepaalt welke systeembronnen het besturingssysteem moet controleren.

Toepassingen kunnen worden uitgevoerd in de gebruikersmodus, waarbij de toepassing kan worden uitgevoerd met elke hoofdgebruiker, inclusief in de beveiligingscontext van Local System (SYSTEM). Toepassingen kunnen ook worden uitgevoerd in de kernelmodus waar de toepassing kan worden uitgevoerd in de beveiligingscontext van Local System (SYSTEM).

SSPI is beschikbaar via de secur32.dll module, een API die wordt gebruikt voor het verkrijgen van geïntegreerde beveiligingsservices voor verificatie, berichtintegriteit en berichtprivacy. Het biedt een abstractielaag tussen protocollen op toepassingsniveau en beveiligingsprotocollen. Omdat voor verschillende toepassingen verschillende manieren nodig zijn om gebruikers te identificeren of verifiëren en verschillende manieren om gegevens te versleutelen tijdens het reizen in een netwerk, biedt SSPI een manier om toegang te krijgen tot dynamic-linkbibliotheken (DLL's) die verschillende verificatie- en cryptografische functies bevatten. Deze DLL's worden SSP's (Security Support Providers) genoemd.

Beheerde serviceaccounts en virtuele accounts werden geïntroduceerd in Windows Server 2008 R2 en Windows 7 om cruciale toepassingen zoals Microsoft SQL Server en Internet Information Services (IIS) te voorzien van de isolatie van hun eigen domeinaccounts, terwijl de noodzaak voor een beheerder om de serviceprincipalnaam (SPN) en referenties voor deze accounts handmatig te beheren werd geëlimineerd. Zie Documentatie voor Beheerde Serviceaccounts voor Windows 7 en Windows Server 2008 R2 en Overzicht van Beheerde Serviceaccounts voor Groepenvoor meer informatie over deze functies en hun rol bij de authenticatie.

Services en kernelmodus

Hoewel de meeste Windows-toepassingen worden uitgevoerd in de beveiligingscontext van de gebruiker die ze start, geldt dit niet voor services. De servicecontroller bestuurt veel Windows-services, zoals netwerk- en afdrukservices, wanneer de gebruiker de computer start. Deze services kunnen worden uitgevoerd als lokale service of lokaal systeem en kunnen blijven worden uitgevoerd nadat de laatste menselijke gebruiker zich afmeldt.

Voordat u een service start, meldt de servicecontroller zich aan met het account dat is aangewezen voor de service en geeft de servicereferenties weer voor verificatie door de LSA. De Windows-service implementeert een programmatische interface die de servicecontrollerbeheer kan gebruiken om de service te beheren. Een Windows-service kan automatisch worden gestart wanneer het systeem wordt gestart of handmatig met een servicebeheerprogramma. Wanneer een Windows-clientcomputer bijvoorbeeld lid wordt van een domein, maakt de messenger-service op de computer verbinding met een domeincontroller en opent een beveiligd kanaal. Om een geverifieerde verbinding tot stand te brengen, moet de service referenties hebben die de lokale beveiligingsautoriteit (LSA) van de externe computer betrouwbaar acht. Bij de communicatie met andere computers in het netwerk gebruikt LSA de referenties voor het domeinaccount van de lokale computer, net zoals alle andere services die worden uitgevoerd in de beveiligingscontext van het Lokaal Systeem en de Netwerkservice. Services op de lokale computer worden uitgevoerd als SYSTEM, zodat referenties niet hoeven te worden gepresenteerd aan de LSA.

Het bestand ksecdd.sys beheert en versleutelt deze referenties en gebruikt een lokale procedureaanroep naar de LSA. Het bestandstype is DRV (stuurprogramma) en staat bekend als de kernelmodus Security Support Provider (SSP) en voldoet aan FIPS 140-2 Level 1 , vanaf Windows Server 2008.

De kernelmodus heeft volledige toegang tot de hardware- en systeembronnen van de computer. De kernelmodus voorkomt dat services in de gebruikersmodus en toepassingen toegang hebben tot kritieke gebieden van het besturingssysteem waartoe ze geen toegang mogen hebben.

Lokale beveiligingsautoriteit

De Local Security Authority (LSA) is een beveiligd systeemproces dat gebruikers verifieert en aanmeldt bij de lokale computer. Daarnaast onderhoudt LSA informatie over alle aspecten van lokale beveiliging op een computer (deze aspecten worden gezamenlijk het lokale beveiligingsbeleid genoemd) en biedt het verschillende services voor vertaling tussen namen en beveiligings-id's (SID's). Het beveiligingssysteemproces, LSASS (Local Security Authority Server Service), houdt het beveiligingsbeleid en de accounts bij die van kracht zijn op een computersysteem.

De LSA valideert de identiteit van een gebruiker op basis van welke van de volgende twee entiteiten het account van de gebruiker heeft uitgegeven:

• Lokale beveiligingsinstantie: de LSA kan gebruikersgegevens valideren door de SAM-database (Security Accounts Manager) op dezelfde computer te controleren. Elke werkstation of lidserver kan lokale gebruikersaccounts en informatie over lokale groepen opslaan. Deze accounts kunnen echter alleen worden gebruikt voor toegang tot dat werkstation of computer.

• Beveiligingsinstantie voor het lokale domein of voor een vertrouwd domein: de LSA neemt contact op met de entiteit die het account heeft uitgegeven en vraagt om verificatie dat het account geldig is en dat de aanvraag afkomstig is van de accounthouder.

LSASS (Local Security Authority Subsystem Service) slaat referenties op in het geheugen namens gebruikers met actieve Windows-sessies. Met de opgeslagen referenties hebben gebruikers naadloos toegang tot netwerkbronnen, zoals bestandsshares, Exchange Server-postvakken en SharePoint-sites, zonder dat ze hun referenties opnieuw hoeven in te voeren voor elke externe service.

LSASS kan referenties opslaan in meerdere formulieren, waaronder:

• Omkeerbaar versleutelde platte tekst.

• Kerberos tickets (ticket-toekenning tickets (TGTs), service tickets).

• NT-hash.

• LAN Manager (LM)-hash.

Als de gebruiker zich aanmeldt bij Windows met behulp van een smartcard, slaat LSASS geen wachtwoord voor tekst zonder opmaak op, maar de bijbehorende NT-hashwaarde voor het account en de pincode voor tekst zonder opmaak voor de smartcard. Als het accountkenmerk is ingeschakeld voor een smartcard die vereist is voor interactieve aanmelding, wordt automatisch een willekeurige NT-hashwaarde gegenereerd voor het account in plaats van de oorspronkelijke wachtwoordhash. De wachtwoord-hash die automatisch wordt gegenereerd wanneer het kenmerk is ingesteld, wordt niet gewijzigd.

Als een gebruiker zich aanmeldt bij een Windows-computer met een wachtwoord dat compatibel is met LM-hashes (LAN Manager), is deze verificator aanwezig in het geheugen. De opslag van platte tekst referenties in het geheugen kan niet worden uitgeschakeld, zelfs niet als de referentieproviders die ze vereisen zijn uitgeschakeld.

De opgeslagen referenties zijn rechtstreeks gekoppeld aan de aanmeldingssessies van de Local Security Authority Subsystem Service (LSASS) die na de laatste herstart zijn gestart en die niet zijn gesloten. LSA-sessies met opgeslagen LSA-referenties worden bijvoorbeeld gemaakt wanneer een gebruiker een van de volgende acties uitvoert:

• Meldt u aan bij een lokale sessie of RDP-sessie (Remote Desktop Protocol) op de computer.

• Hiermee wordt een taak uitgevoerd met behulp van de optie Uitvoeren als .

• Voert een actieve Windows-service uit op de computer.

• Voert een geplande taak of batchtaak uit.

• Voert een taak uit op de lokale computer met behulp van een extern beheerprogramma.

In sommige gevallen worden de LSA-geheimen, die geheime gegevens zijn die alleen toegankelijk zijn voor SYSTEM-accountprocessen, opgeslagen op de harde schijf. Sommige van deze geheimen zijn referenties die behouden moeten blijven na het opnieuw opstarten en worden opgeslagen in versleutelde vorm op de harde schijf. Referenties die zijn opgeslagen als LSA-geheimen, kunnen het volgende omvatten:

• Accountwachtwoord voor het AD DS-account (Active Directory Domain Services) van de computer.

• Accountwachtwoorden voor Windows-services die op de computer zijn geconfigureerd.

• Accountwachtwoorden voor geconfigureerde geplande taken.

• Accountwachtwoorden voor IIS-toepassingsgroepen en websites.

• Wachtwoorden voor Microsoft-accounts.

Het Windows-clientbesturingssysteem biedt extra beveiliging voor de LSA om het lezen van geheugen en code-injectie door niet-beveiligde processen te voorkomen, die zijn geïntroduceerd in Windows 8.1. Deze bescherming verhoogt de beveiliging voor de referenties die de LSA opslaat en beheert.

Zie Aanvullende LSA-beveiliging configureren voor meer informatie over deze extra beveiligingen.

Inloggegevens en validatie in cache

Validatiemechanismen zijn afhankelijk van de presentatie van referenties op het moment van aanmelden. Wanneer de computer echter niet is verbonden met een domeincontroller en de gebruiker domeinreferenties presenteert, gebruikt Windows het proces van referenties in de cache in het validatiemechanisme.

Telkens wanneer een gebruiker zich aanmeldt bij een domein, worden de opgegeven referenties in de cache geplaatst en in de beveiligingssubsectie in het register van het besturingssysteem bewaard. Met referenties in de cache kan de gebruiker zich aanmelden bij een domeinlid zonder verbinding te maken met een domeincontroller binnen dat domein.

Opslag en validatie van referentiegegevens

Het is niet altijd wenselijk om één set referenties te gebruiken voor toegang tot verschillende resources. Een beheerder kan bijvoorbeeld beheerdersreferenties gebruiken in plaats van gebruikersreferenties bij het openen van een externe server. Als een gebruiker toegang heeft tot externe resources, zoals een bankrekening, kunnen ze alleen referenties gebruiken die afwijken van hun domeinreferenties.

Externe aanmeldingsgegevensprocessen

Het Remote Desktop Protocol (RDP) beheert de inloggegevens van de gebruiker die verbinding maakt met een externe computer via de Remote Desktop-client, die in Windows 8 is geïntroduceerd. De referenties in platte tekst worden naar de doelhost verzonden, waar de host probeert het verificatieproces uit te voeren en, indien succesvol, de gebruiker met toegestane bronnen verbindt. RdP slaat de referenties niet op de client op, maar de domeinreferenties van de gebruiker worden opgeslagen in de LSASS.

De modus Beperkte beheerder biedt extra beveiliging voor externe aanmeldingsscenario's, die zijn geïntroduceerd in Windows Server 2012 R2 en Windows 8.1. Deze modus van Extern bureaublad zorgt ervoor dat de clienttoepassing een challenge-response voor netwerkaanmelding uitvoert met de NT-eenrichtingsfunctie (NTOWF) of een Kerberos-serviceticket gebruikt bij authenticatie van de externe host. Nadat de beheerder is geverifieerd, beschikt de beheerder niet over de respectieve accountreferenties in LSASS, omdat deze niet aan de externe host zijn opgegeven. In plaats daarvan heeft de beheerder de referenties van het computeraccount voor de sessie. Beheerdersgegevens worden niet aan de externe host verstrekt, waardoor acties worden uitgevoerd als het computeraccount. Resources zijn ook beperkt tot het computeraccount en de beheerder heeft geen toegang tot resources met hun eigen account.

Aanmeldingsgegevensproces voor automatisch herstarten

Wanneer een gebruiker zich aanmeldt, slaat LSA de gebruikersreferenties op in versleuteld geheugen dat alleen toegankelijk is door LSASS.exe, die is geïntroduceerd in Windows 8.1. Wanneer Windows Update een automatische herstart start zonder aanwezigheid van de gebruiker, worden deze referenties gebruikt om Autologon voor de gebruiker te configureren.

Bij opnieuw opstarten wordt de gebruiker automatisch aangemeld via het Autologon-mechanisme en wordt de computer bovendien vergrendeld om de sessie van de gebruiker te beveiligen. De vergrendeling wordt gestart via Winlogon, terwijl het referentiebeheer wordt uitgevoerd door LSA. Door zich automatisch aan te melden en de sessie van de gebruiker op de console te vergrendelen, worden de toepassingen voor het vergrendelingsscherm van de gebruiker opnieuw opgestart en beschikbaar.

Voor meer informatie over ARSO, zie Winlogon Automatic Restart Sign-On (ARSO).

Windows Vault en Referentiebeheer

Referentiebeheer is een Configuratiescherm-functie voor het opslaan en beheren van gebruikersnamen en wachtwoorden, die is geïntroduceerd in Windows Server 2008 R2 en Windows 7. Met Referentiebeheer kunnen gebruikers referenties opslaan die relevant zijn voor andere systemen en websites in de beveiligde Windows-kluis.

Gebruikers kunnen inloggegevens opslaan en bewaren vanuit ondersteunde browsers en Windows-toepassingen op de lokale computer om het gebruik gemakkelijker te maken wanneer ze zich moeten aanmelden bij deze resources. Referenties worden opgeslagen in speciale versleutelde mappen op de computer onder het profiel van de gebruiker. Toepassingen die deze functie ondersteunen (met behulp van de Credential Manager-API's), zoals webbrowsers en apps, kunnen de juiste referenties presenteren aan andere computers en websites tijdens het aanmeldingsproces.

Wanneer een website, een toepassing of een andere computer verificatie aanvraagt via NTLM of het Kerberos-protocol, wordt er een dialoogvenster weergegeven waarin u het selectievakje Standaardreferenties bijwerken of Wachtwoord opslaan inschakelt. Een toepassing die ondersteuning biedt voor de Credential Manager-API's genereert dit dialoogvenster waarmee een gebruiker referenties lokaal kan opslaan. Als de gebruiker het selectievakje Wachtwoord opslaan inschakelt, houdt Credential Manager de gebruikersnaam, het wachtwoord en de bijbehorende informatie bij voor de verificatieservice die wordt gebruikt.

De volgende keer dat de service wordt gebruikt, levert Credential Manager automatisch de in de Windows-kluis opgeslagen inloggegevens. Als dit niet wordt geaccepteerd, wordt de gebruiker gevraagd om de juiste toegangsgegevens. Als toegang wordt verleend met de nieuwe referenties, overschrijft Credential Manager de vorige referentie met de nieuwe en slaat de nieuwe referentie vervolgens op in de Windows-kluis.

Security Accounts Manager-database

Security Accounts Manager (SAM) is een database waarin lokale gebruikersaccounts en -groepen worden opgeslagen. Het is aanwezig in elk Windows-besturingssysteem; Wanneer een computer lid is van een domein, beheert Active Directory echter domeinaccounts in Active Directory-domeinen.

Clientcomputers met een Windows-besturingssysteem nemen bijvoorbeeld deel aan een netwerkdomein door te communiceren met een domeincontroller, zelfs als er geen menselijke gebruiker is aangemeld. Als u communicatie wilt initiëren, moet de computer een actief account in het domein hebben. Voordat de communicatie van de computer wordt geaccepteerd, verifieert de LSA op de domeincontroller de identiteit van de computer en bouwt de beveiligingscontext van de computer op dezelfde wijze als voor een menselijke beveiligingsprincipaal. Deze beveiligingscontext definieert de identiteit en mogelijkheden van een gebruiker of service op een bepaalde computer of een gebruiker, service of computer in een netwerk. Het toegangstoken in de beveiligingscontext definieert bijvoorbeeld de resources (zoals een bestandsshare of printer) die kunnen worden geopend en de acties (zoals Lezen, Schrijven of Wijzigen) die een principal (een gebruiker, computer of service) op die resource kan uitvoeren.

De beveiligingscontext van een gebruiker of computer kan variëren van de ene computer naar de andere, bijvoorbeeld wanneer een gebruiker zich aanmeldt bij een server of een ander werkstation dan het eigen primaire werkstation van de gebruiker. Het kan ook variëren van de ene sessie naar de andere, bijvoorbeeld wanneer een beheerder de rechten en machtigingen van de gebruiker wijzigt. Bovendien is de beveiligingscontext meestal anders wanneer een gebruiker of computer zelfstandig werkt, in een netwerk of als onderdeel van een Active Directory-domein.

Lokale domeinen en vertrouwde domeinen

Wanneer er een vertrouwensrelatie tussen twee domeinen bestaat, zijn de verificatiemechanismen voor elk domein afhankelijk van de geldigheid van de verificaties die afkomstig zijn van het andere domein. Vertrouwensrelaties helpen om beheerde toegang te bieden tot gedeelde resources in een resourcedomein (het vertrouwende domein) door te controleren of binnenkomende verificatieaanvragen afkomstig zijn van een vertrouwde instantie (het vertrouwde domein). Op deze manier fungeren vertrouwensrelaties als bruggen waarmee alleen gevalideerde verificatieaanvragen tussen domeinen kunnen worden verzonden.

Hoe een specifieke vertrouwensrelatie verificatieaanvragen doorgeeft, is afhankelijk van hoe deze is geconfigureerd. Vertrouwensrelaties kunnen in één richting zijn, door toegang te bieden van het vertrouwde domein naar resources in het vertrouwende domein, of in twee richtingen, door toegang van elk domein aan resources in het andere domein te bieden. Vertrouwensrelaties zijn ook niet-transitief, in welk geval een vertrouwensrelatie alleen bestaat tussen de twee vertrouwenspartnerdomeinen, of transitief, in welk geval een vertrouwensrelatie automatisch uitbreidt naar andere domeinen die een van de partners vertrouwt.

Zie Gedelegeerde verificatie- en vertrouwensrelatiesvoor meer informatie over domein- en forestvertrouwensrelaties met betrekking tot verificatie.

Certificaten voor Windows-authenticatie

Een PKI (Public Key Infrastructure) is de combinatie van software, versleutelingstechnologieën, processen en services waarmee een organisatie communicatie en zakelijke transacties kan beveiligen. De mogelijkheid van een PKI voor het beveiligen van communicatie en zakelijke transacties is gebaseerd op de uitwisseling van digitale certificaten tussen geverifieerde gebruikers en vertrouwde resources.

Een digitaal certificaat is een elektronisch document met informatie over de entiteit waartoe het behoort, de entiteit die het heeft uitgegeven, een uniek serienummer of een andere unieke identificatie, uitgifte- en vervaldatums en een digitale vingerafdruk.

Verificatie is het proces om te bepalen of een externe host kan worden vertrouwd. Om de betrouwbaarheid ervan vast te stellen, moet de externe host een acceptabel verificatiecertificaat bieden.

Externe hosts stellen hun betrouwbaarheid vast door een certificaat van een certificeringsinstantie (CA) te verkrijgen. De CA kan op zijn beurt certificering hebben van een hogere instantie, die een vertrouwensketen creëert. Om te bepalen of een certificaat betrouwbaar is, moet een toepassing de identiteit van de basis-CA bepalen en vervolgens bepalen of het betrouwbaar is.

Op dezelfde manier moet de externe host of lokale computer bepalen of het certificaat dat door de gebruiker of toepassing wordt gepresenteerd, authentiek is. Het certificaat dat door de gebruiker via de LSA en SSPI wordt gepresenteerd, wordt geëvalueerd op echtheid op de lokale computer voor lokale aanmelding, op het netwerk of op het domein via de certificaatarchieven in Active Directory.

Om een certificaat te produceren, worden verificatiegegevens doorgegeven via hash-algoritmen, zoals Secure Hash Algorithm (SHA), om een berichtsamenvatting te produceren. De samenvatting van het bericht wordt vervolgens digitaal ondertekend met behulp van de persoonlijke sleutel van de afzender om te bewijzen dat de afzender de berichtsamenvating heeft geproduceerd.

Smartcardauthenticatie

Smartcardtechnologie is een voorbeeld van verificatie op basis van certificaten. Aanmelden bij een netwerk met een smartcard biedt een sterke vorm van verificatie, omdat deze gebruikmaakt van cryptografische identificatie en bewijs van eigendom bij het verifiëren van een gebruiker bij een domein. Active Directory Certificate Services (AD CS) biedt de cryptografische identificatie via de uitgifte van een aanmeldingscertificaat voor elke smartcard.

Virtuele smartcardtechnologie is geïntroduceerd in Windows 8. Het certificaat van de smartcard wordt opgeslagen op de pc en vervolgens beschermd met behulp van de TPM-beveiligingschip (Trusted Platform Module) van het apparaat. Op deze manier wordt de pc eigenlijk de smartcard die de pincode van de gebruiker moet ontvangen om te worden geverifieerd.

Zie de technische documentatie voor Windows Smart Cardvoor meer informatie over smartcardverificatie.

Externe en draadloze verificatie

Externe en draadloze netwerkverificatie is een andere technologie die gebruikmaakt van certificaten voor verificatie. De IAS-servers (Internet Authentication Service) en virtuele particuliere netwerkservers maken gebruik van Extensible Authentication Protocol-Transport Level Security (EAP-TLS), Protected Extensible Authentication Protocol (PEAP) of Internet Protocol Security (IPsec) om verificatie op basis van certificaten uit te voeren voor veel soorten netwerktoegang, waaronder VPN (Virtual Private Network) en draadloze verbindingen.

Zie Netwerktoegangsverificatie en certificatenvoor informatie over verificatie op basis van certificaten in netwerken.

Verwante inhoud

• Windows-verificatieconcepten
• Technisch overzicht van Windows-verificatie