02/11/2011 Jean de Klerk

Elke Windows-beheerder heeft uiteraard meer dan eens te maken gehad met de twee belangrijkste authenticatieprotocollen in de Windows-omgeving: Kerberos en NTLM. In dit artikel wordt beschreven hoe Kerberos en NTLM worden ondersteund op Windows 7 en Windows Server 2008 R2. Maar eerst wil ik de belangrijkste verschillen tussen deze protocollen benadrukken.

Microsoft-ontwikkelaars implementeerden het Kerberos-protocol voor het eerst in Windows 2000. Het NTLM-protocol werd veel eerder in gebruik genomen, in de tijd van Windows NT. Kerberos is een authenticatieprotocol gebaseerd op het concept van een vertrouwde derde partij (TTP), terwijl het NTLM-protocol gebaseerd is op een challenge/response-mechanisme. De verschillen tussen de twee protocollen worden in de tabel gedetailleerder beschreven.

Tijdens NTLM-verificatiecommunicatie genereert een serverbron (zoals een bestandsserver) een verzoek dat naar de client wordt verzonden. De client genereert een NTLM-antwoord dat een hash van het wachtwoord van de gebruiker bevat, en de server verifieert dat het antwoord correct is. Als de client een lokaal account gebruikt, verifieert de server het antwoord van de gebruiker met behulp van een hash van het wachtwoord van de gebruiker, die is opgeslagen in de lokale Security Account Manager (SAM)-database. Als de client een domeinaccount gebruikt, stuurt de server ter verificatie een antwoord naar de domeincontroller, omdat alleen domeincontrollers kopieën van gebruikerswachtwoord-hashes opslaan in hun Active Directory-databases (AD).

In Windows Kerberos is een vertrouwde derde partij een domeincontroller uit Windows 2000 of hoger die als host fungeert voor de Kerberos Key Distribution Center-service (KDC). De KDC vergemakkelijkt de authenticatie tussen een Kerberos-compatibele client en server. De KDC-service wordt automatisch geïnstalleerd als onderdeel van het AD-systeem en bestaat uit twee subsystemen: de Authentication Service (AS) en de Ticket-Granting Service (TGS).

Wanneer een gebruiker zich aanmeldt bij een Windows-domein met behulp van het Kerberos-protocol, verifieert de Windows-client de gebruiker eerst bij de domeincontroller met behulp van het wachtwoord van de gebruiker. Tegelijkertijd vraagt ​​de klant een Ticket Grant Ticket (TGT) aan bij de authenticatiedienst. De TGT kan worden gezien als een tijdelijk wachtwoord (de standaardlevensduur is 8 uur) dat het wachtwoord van de gebruiker zal vervangen bij volgende authenticatieverzoeken. Wanneer een gebruiker toegang moet krijgen tot een serverbron, zal de client een TGT indienen om een ​​TGT uit te geven om zich bij de serverbron te authenticeren. Houd er rekening mee dat, in tegenstelling tot NTLM, het Kerberos-protocol niet wordt gebruikt voor lokale authenticatie in Windows Security Accounts Manager; de reikwijdte ervan is beperkt tot domeinverificatie op een domeincontroller.

Kerberos is het standaardverificatieprotocol in Windows 2000 en nieuwere versies van Microsoft. In deze besturingssystemen wordt het authenticatieprotocol gedefinieerd met behulp van een onderhandelingsmechanisme. Als het standaard Kerberos-protocol niet geschikt is of niet wordt ondersteund door een van de client- of servercomponenten die deelnemen aan de authenticatie, schakelt Windows over op het gebruik van NTLM.

Waarom Kerberos?

Kerberos is om verschillende redenen efficiënter dan NTLM. Bij gebruik van het Kerberos-protocol wordt de wachtwoord-hash van de gebruiker veel minder vaak zichtbaar dan bij gebruik van NTLM. De wachtwoord-hash wordt alleen zichtbaar wanneer de gebruiker de TGT opvraagt, in principe eens in de acht uur. Aan de andere kant wordt bij NTLM de wachtwoord-hash zichtbaar wanneer een client NTLM gebruikt om zich bij de server te authenticeren. Dit is een belangrijk voordeel van het Kerberos-protocol ten opzichte van het NTLM-protocol; feit is dat er speciale tools zijn die het netwerkverkeer controleren op de aanwezigheid van wachtwoord-hashes. Deze tools vangen gedetecteerde hashes op en gebruiken brute kracht om gebruikerswachtwoorden te herstellen.

Een ander voordeel van Kerberos is dat het tijdstempels gebruikt ter bescherming tegen replay-aanvallen. Daarom is het zo belangrijk om een ​​tijdsynchronisatieservice te hebben die feilloos functioneert in een op Kerberos gerichte Windows-omgeving. In Windows 2000 en nieuwere versies van het systeem werken tijdservices standaard. Als de computerklokken op verschillende computers niet gesynchroniseerd zijn, kan dit leiden tot extra verkeer tijdens het Kerberos-authenticatieproces of, in het ergste geval, tot een fout in het authenticatieproces.

Naast het bovenstaande implementeert het Kerberos-protocol geavanceerde authenticatiefuncties zoals wederzijdse authenticatie en authenticatiedelegatie. Wederzijdse authenticatie betekent dat de gebruiker en de dienst elkaar authenticeren, terwijl de mogelijkheden van NTLM beperkt zijn tot gebruikersauthenticatie. Zonder deze functie kunnen zich situaties voordoen waarin gebruikers hun inloggegevens aan een valse server doorgeven.

De service heeft namens de gebruiker toegang tot externe bronnen met behulp van het mechanisme voor authenticatiedelegatie. Met andere woorden: de gebruiker kan het intermediaire systeem het recht verlenen om zichzelf (de gebruiker) namens hem te authenticeren bij de applicatieserver. Als resultaat hiervan kan de applicatieserver autorisatiebeslissingen nemen die niet gebaseerd zijn op de identiteit van het intermediaire systeem, maar op basis van de identiteit van de gebruiker. De functie voor het delegeren van authenticatie is erg handig bij toepassingen met meerdere lagen, zoals toegang tot databases met behulp van een webgebaseerde frontend.

Tenslotte moet worden gezegd dat hoewel Microsoft veel werk heeft verricht om het NTLM-protocol te moderniseren, namelijk het creëren van de NTLMv2-versie, die wordt ondersteund in de NT4 SP4-omgeving en nieuwere versies, het Microsoft Kerberos-product een groter aantal moderne encryptie-oplossingen implementeert algoritmen. Ik zal hier dieper op ingaan in het gedeelte over Kerberos-protocolversleuteling.

Beperkingen van het NTLM-protocol

De voordelen van authenticatie met behulp van het Kerberos-protocol staan ​​buiten kijf. Maar zelfs in een AD Server 2008-omgeving gebruikt Windows vaak het NTLM-protocol, bijvoorbeeld wanneer u verbinding maakt met een Windows-systeem van vóór Windows 2000 of wanneer u verbinding maakt met een gedeelde bron met behulp van de opdracht net use en een IP-adres (in plaats van een NetBIOS-naam). Bovendien blijven toepassingen waarvoor de Service Principal Names (SPN's) niet correct zijn geconfigureerd, het NTLM-protocol gebruiken.

Om erachter te komen welk protocol (NTLM of Kerberos) u momenteel gebruikt, kunt u NTLM-verkeer visualiseren met behulp van het netmon-hulpprogramma of een andere netwerktracer; Een alternatieve optie is om de inhoud van de Kerberos-ticketcache te controleren met behulp van de klist-tool (meegeleverd met Windows 7 en Server 2008). In Windows 7 en Server 2008 heeft Microsoft nieuw groepsbeleid geïntroduceerd waarmee u het gebruik van het NTLM-protocol door uw gebruikers en toepassingen kunt controleren en blokkeren. Er zijn drie van dergelijke beleidsregels: één voor inkomend NTLM-verkeer (voor monitoring en blokkering op serverniveau), één voor uitgaand NTLM-verkeer (voor monitoring en blokkering op clientniveau) en een derde voor domeinverkeer (voor monitoring en blokkering op clientniveau). het domeincontrollerniveau). Ze bevinden zich in de container Security Options Group Policy Object (CPO), die toegankelijk is door achtereenvolgens Computerconfiguratie, Windows-instellingen, Beveiligingsinstellingen en Lokaal beleid te selecteren (zie afbeelding 1). Ze beginnen allemaal met het element Netwerkbeveiliging: NTLM beperken:.

Elke beleidsinstelling heeft controle- en blokkeringsparameters. Wanneer u de NTLM-auditfunctie inschakelt, maakt het programma gebeurtenislogboekvermeldingen met NTLM-brongegevens en nummers 8001, 8002, 8003 en 8004. De logboekvermeldingen worden opgeslagen in de operationele container met het toegangspad Gebeurtenisviewer (lokaal), Toepassingen en Serviceslogboeken, Microsoft, Windows, NTLM. Ik raad aan om te beginnen met een NTLM-audit in een testomgeving en ervoor te zorgen dat al je applicaties daar goed vertegenwoordigd zijn. Als u willekeurig het gebruik van het protocol blokkeert, zullen sommige applicaties hoogstwaarschijnlijk niet werken. Om verlies van gebeurtenissen te voorkomen, moet u een oplossing voor het verzamelen van auditgebeurtenissen installeren voordat u begint met het testen van NTLM-audittools; U kunt de ingebouwde Windows Event Collector-service, Event Subscriptions of een oplossing van derden gebruiken. Bovendien raad ik aan eerst NTLM-monitoring op uw servers te starten. U kunt clients verbinden om gedetailleerde analyses uit te voeren nadat duidelijk wordt dat de server het NTLM-protocol gebruikt. Zodra u begrijpt welke toepassingen NTLM gebruiken, kunt u een strategie ontwikkelen om NTLM te blokkeren. Deze strategie kan een uitzonderingsstrategie omvatten voor oudere applicaties die niet kunnen worden herschreven of gemigreerd en die altijd NTLM vereisen.

Helaas kunnen de genoemde NTLM-instellingen niet worden gebruikt op oudere Windows-systemen. Deze systemen maken echter versiebeheer van het NTLM-protocol mogelijk. U kunt bijvoorbeeld het LM-gedeelte van het NTLM-authenticatieprotocol uitschakelen (aangezien dit gedeelte inherent zwak is) of het gebruik van het NTLMv2-protocol afdwingen. Om dit te doen, gebruikt u de GPO-instelling Netwerkbeveiliging: LAN Manager Authentication Level, die zich bevindt in de GPO-container Computerconfiguratie\Windows-instellingen\Beveiligingsinstellingen\Lokaal beleid\Beveiligingsopties (zie Afbeelding 2).

Kerberos-coderingstools

Cryptografische protocollen die worden gebruikt door authenticatieprotocollen spelen een belangrijke rol bij het waarborgen van de veiligheid hiervan. Zoals ik al heb opgemerkt, presteert Kerberos op dit gebied beter dan NTLM. Het RC4-coderingsalgoritme werd voor het eerst geïmplementeerd in het Windows Kerberos-protocol in Windows 2000 en wordt nog steeds ondersteund in Server 2008-systemen, evenals in Windows 7 (meer precies, de versie RC4_HMAC_MD5 wordt ondersteund). In Server 2008, Windows Vista en nieuwere versies heeft Microsoft ondersteuning toegevoegd voor Advanced Encryption Standard (AES)-codering, en Windows 7 en Server 2008 R2 ondersteunen standaard Kerberos AES-coderingstypen (AES128_HMAC_SHA1 en AES256_HMAC_SHA1). AES is een nieuwer en krachtiger versleutelingsalgoritme dan DES. De Kerberos-logica op domeincontrollers wordt overgezet naar de AES-coderingsstandaard wanneer u uw AD-domein upgradet naar Windows 2008 Domain Functional Level (DFL).

Op Windows 7- en Server 2008 R2-systemen zijn DES-coderingstypen voor het Kerberos-verificatieprotocol standaard uitgeschakeld. Dit kan compatibiliteitsproblemen veroorzaken als een van de oudere applicaties hardgecodeerd is om uitsluitend DES-codering te gebruiken, of als het Windows-account waarop een bepaalde service wordt uitgevoerd (dat serviceaccount) is geconfigureerd om alleen DES-codering te gebruiken. Deze services of applicaties zullen mislukken tenzij u de service of applicatie opnieuw kunt configureren om een ​​ander coderingstype (RC4 of AES) te ondersteunen of DES-ondersteuning kunt herstellen.

Om te bepalen of u toepassingen of services hebt die uitsluitend met DES-codering zijn gecodeerd, kunt u aan het begin van de toepassing of service een netwerktracer uitvoeren en de inhoud van de Etype-velden in de Kerberos-authenticatieheaders controleren. Om te bepalen of een AD-gebruiker of computeraccount of een computeraccount is geconfigureerd om alleen DES-coderingstypen te gebruiken, moet u controleren of de optie Kerberos DES-coderingstypen gebruiken voor dit account is geselecteerd op het tabblad Account van de objecteigenschappen. Deze eigenschappen zijn toegankelijk via de module AD-gebruikers en computers in de MMC.

Als u de bovengenoemde controles uitvoert en constateert dat u dit probleem ondervindt, kunt u DES-codering voor Kerberos-verificatie inschakelen op computers met Windows 7 of Server 2008 R2 met behulp van het GPO Netwerkbeveiligingsinstellingen: Coderingstypen configureren die compatibel zijn met Kerberos standaard; Deze instellingen bevinden zich in de GPO-container Computerconfiguratie, Windows-instellingen, Beveiligingsinstellingen, Lokaal beleid, Beveiligingsopties.

Van de twee Windows-authenticatieprotocollen is Kerberos dus het voorkeursprotocol. Beheerders moeten er altijd op aandringen dat gebruikers en applicaties Kerberos gebruiken in plaats van NTLM. De nieuwe NTLM-beperkingen die in Windows 7 en Server 2008 R2 zijn geïntroduceerd, bieden een uitstekende gelegenheid om dit doel te bereiken.

Jean de Klerk ( [e-mailadres beveiligd]) is een medewerker van het Security Office van HP. Gespecialiseerd in identiteits- en beveiligingsbeheer in Microsoft-producten

Verificatie op Windows Server 2008 R2 en Windows 7

Het Windows 7-besturingssysteem introduceert een nieuwe generatie beveiligingstechnologieën voor de desktop, en een daarvan is authenticatie en autorisatie. Sommige technologieën zijn gericht op het versterken van de algehele Windows-infrastructuur, en de rest is gericht op het helpen beheren van de systeem- en gebruikersgegevens.

Voordat u effectieve beveiligingsmaatregelen in Windows 7 installeert, zoals voor het delen van bestanden en mappen, is het belangrijk dat u begrijpt welke typen gebruikersaccounts worden gebruikt tijdens het instellen van de beveiliging, en hoe het netwerkprotocol gebruikersaanmeldingen verifieert en autoriseert.

Authenticatie is een proces dat wordt gebruikt om de identiteit van een gebruiker te bevestigen bij toegang tot een computersysteem of aanvullende systeembronnen. In particuliere en openbare computernetwerken (waaronder internet) omvat authenticatie meestal het controleren van de inloggegevens van de gebruiker; dat wil zeggen gebruikersnaam en wachtwoord. Voor soorten kritieke transacties, zoals betalingsverwerking, is authenticatie van gebruikersnaam en wachtwoord echter niet voldoende, omdat wachtwoorden kunnen worden gestolen of gecompromitteerd. Om deze reden gebruiken de meeste online bedrijven, evenals vele andere transacties, nu digitale certificaten, die worden uitgegeven en geverifieerd door een certificeringsinstantie.

Authenticatie gaat logischerwijs vooraf aan autorisatie. Met autorisatie kan het systeem bepalen of een geautoriseerde gebruiker toegang heeft tot beveiligde systeembronnen en deze kan bijwerken. Met autorisatie kunt u directe toegang tot mappen en bestanden, toegangsuren, de hoeveelheid toegestane opslagruimte, enzovoort instellen.

• Wijzigingen in systeembronnen worden in eerste instantie toegestaan ​​door de systeembeheerder.
• Wanneer een gebruiker probeert toegang te krijgen tot een systeembron of deze bij te werken, wordt de toestemming voor de actie geëvalueerd door het systeem of de applicatie.

Met deze laatste optie kan de gebruiker toegang krijgen zonder authenticatie of autorisatie. Het wordt gebruikt wanneer u toegang wilt verlenen aan anonieme, niet-geverifieerde gebruikers. Dergelijke toegang is doorgaans zeer beperkt.

Autorisatie- en authenticatieproces.

Om toegang te krijgen tot bestanden op het netwerk, moeten gebruikers worden geverifieerd om hun identiteit te verifiëren. Dit gebeurt tijdens het netwerkaanmeldingsproces. Het Windows 7-besturingssysteem kent de volgende authenticatiemethoden voor inloggen op het netwerk:

• Kerberos-protocol versie 5: de primaire authenticatiemethode voor clients en servers met Microsoft Windows-besturingssystemen. Het wordt gebruikt om gebruikersaccounts en computeraccounts te authenticeren.
• Windows NT LAN Manager (NTLM): Wordt gebruikt voor achterwaartse compatibiliteit met besturingssystemen ouder dan Windows 2000 en sommige toepassingen. Het is minder flexibel, efficiënt en veilig dan Kerberos versie 5.
• Certificaattoewijzing: Meestal gebruikt voor login-authenticatie in combinatie met een smartcard. Het certificaat dat op de smartcard is opgeslagen, is gekoppeld aan het gebruikersaccount. Een smartcardlezer wordt gebruikt om smartcards te lezen en de gebruiker te authenticeren.

Nieuwe authenticatiefuncties in Windows 7.

Er zijn een aantal verbeteringen met betrekking tot gebruikersaanmeldings- en authenticatieprocessen toegevoegd in Windows Vista®. Deze verbeteringen vergroten de kern van de authenticatiefuncties en zorgen voor een betere beveiliging en beheerbaarheid. In Windows 7 zet Microsoft de verbeteringen voort die in Windows Vista zijn gestart door de volgende nieuwe authenticatiefuncties te bieden:

• Slimme kaarten
• Biometrie
• Integratie van persoonlijkheid op internet.

Slimme kaarten.

Het gebruik van smartcards is de meest gebruikelijke authenticatiemethode. Om organisaties en gebruikers aan te moedigen smartcards te gebruiken, biedt Windows 7 nieuwe functies om smartcards eenvoudiger te gebruiken en te implementeren. Met deze nieuwe mogelijkheden kunt u smartcards gebruiken om allerlei taken uit te voeren, waaronder:

• Plug-and-play smartcards
• Persoonlijke identificatieverificatie (PIV), standaard van het National Institute of Standards and Technology (NIST).
• Ondersteuning voor inloggen met Kerberos-smartcard.
• BitLocker-stationsversleuteling
• Documenten en e-mail
• Gebruik met zakelijke toepassingen.

Biometrie.

Biometrie is een steeds populairder wordende technologie die gemakkelijke toegang biedt tot systemen, diensten en bronnen. Biometrie maakt gebruik van het meten van zijn onveranderlijke fysieke kenmerken om een ​​persoon op unieke wijze te identificeren. Een van de meest gebruikte biometrische kenmerken zijn vingerafdrukken.

Tot nu toe had Windows geen standaardondersteuning voor biometrische apparaten. Om dit probleem op te lossen introduceert Windows 7 het Windows Biometric Framework (WBF). WBF biedt een nieuwe reeks componenten die vingerafdrukken met behulp van biometrische apparaten ondersteunen. Deze componenten verhogen de veiligheid van de gebruiker.

Met het Windows Biometric Framework kunnen gebruikers en beheerders eenvoudig biometrische apparaten instellen en beheren op een lokale computer of in een domein.

Integratie van persoonlijkheid op internet.

Accountbeheer is een beveiligingsstrategie. Gebruik Groepsbeleid om verificatie toe te staan ​​of te weigeren voor specifieke computers of voor alle computers die u online beheert.

Online identiteitsintegratie kan worden beheerd door groepsbeleid. Een beleid dat is geconfigureerd als: “Netwerkbeveiliging: sta toe dat deze computer een online-ID gebruikt wanneer om PKU2U-authenticatie wordt gevraagd” bepaalt de mogelijkheid van een online-ID om deze computer te verifiëren met behulp van het PKU2U-protocol. Deze beleidsinstelling heeft geen invloed op de mogelijkheid van domeinaccounts of lokale gebruikersaccounts om zich aan te melden bij deze computer.

Windows NT vraag/antwoord. Met geïntegreerde Windows-authenticatie verifieert de clientbrowser zichzelf tegen de server via cryptografische communicatie.

Windows Integrated Authentication ondersteunt zowel het Kerberos v5-protocol als het NTLM-protocol (NT LAN Manager) voor authenticatie via het Negotiate-pakket. Als Active Directory beschikbaar is en de juiste browserondersteuning (IE 5 of hoger op het Windows 2000-platform) wordt het Kerberos-protocol gebruikt, anders wordt het NTLM-protocol gebruikt. Zowel Kerberos als NTLM hebben enkele beperkingen. Een interessant feit is dat de voordelen van de een overeenkomen met de zwakheden van de ander. Kerberos werkt doorgaans met proxyservers, maar is niet zo effectief met firewalls. NTLM werkt meestal via firewalls, maar heeft een tamelijk middelmatige interactie met proxyservers.

Een paar woorden over Microsoft Negotiate

Microsoft Negotiate is een pakket dat dient als interface tussen verschillende leveranciers van beveiligingsondersteuning. Het kan kiezen tussen verschillende authenticatiepakketten. IIS gebruikt het Negotiate-pakket voor authenticatie, waarbij de keuze Kerberos of NTLM is. Dit pakket voegt ook ondersteuning voor de toekomst toe authenticatie pakketten, wat het voordeel is van onderhandelen. Standaard selecteert Negotiate Kerberos als het veiligste protocol. Als het Kerberos-protocol om de een of andere reden niet beschikbaar is, valt Negotiate terug op het gebruik van NTLM.

NTLM-authenticatie

NTLM is een verbeterde versie van het oude LM-authenticatieprotocol (LAN Manager). NTLM werkt via vraag/antwoord tussen de server en de client zonder dat het wachtwoord van de gebruiker in gewone tekst over het netwerk wordt verzonden. De client moet bevestigen dat hij het wachtwoord van de gebruiker kent door een gecodeerde hash te verzenden.

NTLM werkt als volgt.

1. De gebruiker geeft een gebruikersnaam, wachtwoord en domeinnaam op wanneer hij zich aanmeldt op de clientcomputer.
2. De client maakt een hash van het opgegeven wachtwoord en verwijdert het origineel.
3. De client stuurt de gebruikersnaam in duidelijke tekst naar de server.
4. De server stuurt een 16-bits stukje willekeurige gegevens naar de client.
5. De client codeert dit fragment, evenals een hash van het wachtwoord van de gebruiker, en verzendt deze naar de server.
6. De server geeft de gebruikersnaam, een willekeurig stukje gegevens en het antwoord van de client door aan de domeincontroller.
7. De domeincontroller codeert een stukje willekeurige gegevens samen met zijn eigen hash van het wachtwoord van de gebruiker, en vergelijkt deze vervolgens met de elementen die door de server zijn verzonden.
8. Als de waarden overeenkomen, laat de domeincontroller de server weten dat de authenticatie succesvol was.
9. Als de waarden of gebruikersnaam niet overeenkomen, waarschuwt de domeincontroller de server, die een bijbehorend bericht naar de client stuurt. De clientbrowser vraagt ​​de gebruiker vervolgens authenticatiegegevens.

Kerberos-authenticatie

In de oude Griekse mythologie is Kerberos een fantastische driekoppige hond die de onderwereld tegen mensen bewaakte. Momenteel verwijst de term Kerberos naar een veilig authenticatieprotocol voor toegang tot bronnen. Kerberos is gebaseerd op private key-authenticatie, waarbij de client en server dezelfde sleutel gebruiken voor encryptie en decryptie. De client bewijst kennis van de sleutel door het bericht te coderen, en de server bewijst kennis van de sleutel door het bericht te decoderen. De server neemt vervolgens een deel van het bericht, codeert het en stuurt het naar de client. Als de integriteit van het bericht behouden blijft, zal het authenticatieresultaat positief zijn.

Kerberos vertrouwt op een centrale server genaamd het Key Distribution Center (KDC) ( Sleutel distributiecentrum), dat alle benodigde sleutels biedt. Het KDC geeft zogenaamde TGT's (Ticket-Granting Tickets) uit en stelt deze ter beschikking aan klanten die toegang vragen tot een bron op de server.

Hieronder ziet u hoe een klant een eerste TGT-ticket ontvangt.

1. De gebruiker logt in op de clientcomputer met een gebruikersnaam en wachtwoord.
2. De client codeert het wachtwoord en slaat het op.
3. De client stuurt een bericht naar de KDC met het verzoek om authenticatiegegevens voor de TGT-service, evenals het gecodeerde wachtwoord van de gebruiker.
4. Het KDC vergelijkt het gecodeerde wachtwoord met de hoofdkopie om hun identiteit te verifiëren. De tijdstempel die de klant bij de aanvraag heeft gevoegd, wordt ook gecontroleerd om er zeker van te zijn dat de tijdstempel binnen vijf minuten na de eigen tijd van het KDC ligt.
5. Als er een volledige match is, maakt het KDC de gevraagde aan authenticatiegegevens voor TGT-service door te genereren sessie sleutel log in en versleutel het met een gebruikerssleutel.
6. KDC maakt nog een fragment authenticatiegegevens via encryptie sessie sleutel login en TGT-gebruiker met een eigen hoofdsleutel.
7. KDC verzendt beide fragmenten authenticatiegegevens naar de cliënt.
8. De client decodeert de inlogsessiesleutel uit het eerste segment authenticatiegegevens gebruikt een gecodeerd wachtwoord en slaat deze inlogsleutel voor de sessie op in de ticketcache.
9. De client slaat de TGT ook op in zijn ticketcache.

De klant heeft nu de TGT en kan deze gebruiken om tickets te verkrijgen voor toegang tot bronnen. Hier is hoe het gebeurt.

1. De client vraagt ​​een ticket aan bij de KDC om toegang te krijgen tot bronnen op de server. De client verstrekt zijn TGT aan de KDC, samen met de gewenste bronnaam en een authenticatiebericht dat is gecodeerd met de inlogsessiesleutel.

Authenticatie is een onmisbare procedure voor elke gebruiker, computer en serviceaccount in Windows, maar het mechanisme ervan is niet grondig bestudeerd door systeembeheerders. Iedereen weet dat je om je op een computer te registreren het juiste wachtwoord moet opgeven, maar hoeveel mensen weten wat er daarna gebeurt? Windows-verificatie en de bijbehorende protocollen worden ingeschakeld wanneer een gebruiker, computer of service zich lokaal of met een domeincontroller (DC) registreert. In dit artikel worden eerst de basisprincipes van Windows-authenticatie besproken en vervolgens de bijbehorende protocollen. Tot slot worden er korte aanbevelingen gegeven om de betrouwbaarheid van de authenticatieprocedure op een Windows-netwerk te verbeteren.

Authenticatie: algemene principes

Authenticatie is een van de componenten van elk computertoegangscontrolesysteem. Zoals Figuur 1 laat zien, zorgen toegangscontrolesystemen voor identificatie, authenticatie, autorisatie en rapportage.

Identificatie. Het authenticatieproces maakt gebruik van een set informatie die een beveiligingsobject op unieke wijze identificeert (bijvoorbeeld gebruiker, groep, computer, serviceaccount) in een gedeelde directoryservice. Met een directoryservice zoals Active Directory (AD) kunnen objecten uniek worden geïdentificeerd, net zoals DNS ervoor zorgt dat geen twee mensen hetzelfde e-mailadres kunnen hebben. Windows-internals gebruiken SID's, Globally Unique Identifiers (GUID's) en andere unieke tags. In de meeste gevallen is het simpelweg invoeren van een unieke accountnaam, zoals Rgrimes, voldoende om u te identificeren. In een groot AD-forest moet u bijvoorbeeld volledig gekwalificeerde UPN (User Principal Names) gebruiken [e-mailadres beveiligd]. Bij gebruik van smartcards kan de beveiligingspersoon zijn digitale certificaat of sleutel presenteren.

Authenticatie of authenticatie. Nadat de beveiligingspersoon heeft ingetoetst of anderszins identificatie-informatie heeft verstrekt (bijvoorbeeld gebruikersnaam, beveiligingstoken), moet de persoon de privé-authenticatiegegevens intoetsen of op andere wijze verstrekken (bijvoorbeeld wachtwoord en pincode). In Windows voert de beveiligingsprincipal deze informatie in op het aanmeldingsscherm met behulp van de programma's Microsoft Graphical Identification and Authentication DLL (msgina.dll) en Winlogon.exe. Het authenticatieprotocol en de engine van het systeem coderen de ingediende informatie op de desktopcomputer en verzenden het authenticatieverzoek. De Windows Authentication Service kan een SAM- of AD-database zijn. De SAM-database ondersteunt lokale registratieprocedures en registratie op Windows NT 4.0-domeincontrollers. AD verifieert aanvragen tegen Windows 2000 of latere Windows 2000-domeinen. Een authenticatieprotocol (bijv. LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) wordt gebruikt om authenticatieverzoeken en daaropvolgende transacties tussen het inlogscherm en de authenticatieservice te transporteren. Hieronder wordt elk authenticatieprotocol afzonderlijk besproken.

Autorisatie. Als de authenticatiedienst de combinatie van de identificator en de "geheime" authenticatiegegevens authenticeert, wordt de identiteit van de beveiligingspersoon als succesvol geverifieerd. Het systeem verzamelt vervolgens informatie over de groepslidmaatschappen van het beveiligingssubject (dat wil zeggen de gebruiker). Het is niet ongebruikelijk dat een gebruiker tot verschillende goed gedefinieerde groepen behoort (lokaal, domeinlokaal, globaal en universeel) als resultaat van de normale procedures voor lidmaatschapstoewijzing. Het systeem vergelijkt lokale groepen met de lokale SAM-database en verifieert lokale en globale groepen op DC's in het thuisdomein van de gebruiker, evenals universele groepen op de DC die de Globale Catalogus bevat. Het systeem verzamelt direct of indirect alle groepslidmaatschapsgegevens om informatie over beveiligingsmachtigingen te verkrijgen.

Onmiddellijk na de authenticatie verzamelt het systeem account-SID's en groepslidmaatschapsinformatie in een object dat een toegangstoken wordt genoemd. Mogelijk moet de gebruiker zich afmelden en opnieuw aanmelden voordat de nieuwe beveiligingsmachtigingen van kracht worden. Als een gebruiker toegang moet krijgen tot een object (bijvoorbeeld een bestand, map, printer, registersleutel) dat wordt beschermd door NTFS-machtigingen, dan levert een proces (bijvoorbeeld Windows Verkenner) dat namens de gebruiker handelt het toegangstoken. Elk NTFS-object heeft een lijst met toegangscontrole-items (ACE's), die in wezen bekende NTFS-machtigingen zijn (bijvoorbeeld Lezen toestaan, Schrijven toestaan). De set ACE's die aan gebruikers en groepen is toegewezen, vormt de toegangscontrolelijst (ACL) voor een bepaald object. De ACL van een object wordt met name weergegeven door beveiligingsmachtigingen, die kunnen worden bekeken in Windows Verkenner.

Het toegangstoken, dat de account en groepen bevat waaraan de gebruiker is gekoppeld, bepaalt de effectieve machtigingen van de gebruiker. Het autorisatieproces omvat het toestaan ​​of weigeren van toegang tot een specifiek object op basis van een vergelijking van het toegangstoken met de ACL van het object. Autorisatie wordt verleend door de Windows Security Reference Monitor (scherm 1). In het voorbeeld dat Figuur 1 laat zien, heeft de gebruiker de machtigingen Lezen, Schrijven en Wijzigen. De groep Iedereen waartoe de gebruiker behoort, beschikt echter niet over de machtiging Wijzigen. Leden van andere groepen hebben de machtigingen Lezen en Wijzigen, maar de machtiging Weigeren van de groep Iedereen overschrijft de machtiging Wijzigen. Het object heeft ook ACL's die de machtiging Volledig beheer weigeren aan de HR-groep, maar de gebruiker behoort niet tot die groep. De effectieve machtigingen van de gebruiker voor een object zijn dus scherm 2- Lezen en schrijven.

Boekhouding. Als de auditmodus in Windows is ingeschakeld, slaat het systeem de authenticatiegebeurtenis op in het beveiligingslogboek, en dit is het laatste onderdeel van het toegangscontrolesysteem: rapportage. De meeste complexe initiële registratie- en daaropvolgende autorisatiegebeurtenissen vinden binnen enkele seconden plaats en zijn voor de gebruiker verborgen. Alle complexe handelingen worden toevertrouwd aan het authenticatieprotocol.

Protocoldoelstellingen

Een authenticatieprotocol moet minstens twee dingen doen. Ten eerste moet het op veilige wijze transacties van de aanvrager naar de authenticatiedatabase en naar elke andere computer die de overeenkomstige bron host, verzenden. Ten tweede moet het wachtwoord of token veilig worden opgeslagen. Dit laatste is van bijzonder belang voor wachtwoordkrakers. Het authenticatieprotocol moet door de gebruiker aangeleverde informatie beschermen wanneer deze wordt doorgestuurd naar de authenticatiedatabase (dat wil zeggen SAM of AD). Om dit te doen, ondertekent, verbergt of codeert het protocol de transactie. Het is ook voorzien van een tijdstempel om te voorkomen dat een aanvaller de inloggegevens in de toekomst kan gebruiken. Om te voorkomen dat het wachtwoord van de gebruiker onmiddellijk uit de database wordt opgehaald, moet het protocol ervoor zorgen dat wachtwoorden geheim worden opgeslagen in de authenticatiedatabase.

Al meer dan tien jaar lang bieden authenticatieprotocollen voornamelijk veiligheid door wachtwoorden in verborgen vorm (meestal gehasht) op te slaan in de authenticatiedatabase en de overdracht van wachtwoorden tussen de aanvrager en de authenticatiedatabase in platte tekst (zelfs in verborgen vorm) volledig te verbieden. Het verzoek-antwoordproces ziet er als volgt uit:

1. De computer ontvangt identificatie- en authenticatie-informatie van de gebruiker en vraagt ​​authenticatie aan bij de juiste server.
2. De authenticatieserver genereert een willekeurige willekeurige waarde (een zogenaamde challenge) en stuurt deze naar de aanvrager.
3. De aanvrager ontvangt het verzoek en voert er wiskundige bewerkingen op uit, evenals de verborgen vorm van het wachtwoord, en verzendt vervolgens het resultaat (het antwoord genoemd) naar de authenticatieserver.
4. De authenticatieserver voert ook wiskundige manipulaties uit op het verzoek met behulp van een methode die identiek is aan die welke op het werkstation wordt gebruikt, en vergelijkt het resultaat met het ontvangen antwoord. Als de resultaten overeenkomen, wordt de aanvrager als succesvol geverifieerd beschouwd.

Authenticatieprotocollen maken gebruik van een challenge-response-proces, zodat het wachtwoord nooit via het netwerk wordt verzonden.

Lokale en domeinregistratie

Bij het registreren van een gebruiker is een van de eerste taken van Windows het bepalen of de procedure alleen van toepassing is op de lokale machine of op een domeinaccount. Gebruikers die zich aanmelden als een lokaal account hebben alleen toegang tot bronnen op hun computer en alleen als de gebruikersaccountinformatie in de lokale SAM-database staat. Als gebruikers zonder domeinverificatie toegang moeten krijgen tot bronnen op een externe computer, moeten hun accounts worden gedupliceerd in de lokale SAM-database van elke toegankelijke computer. Accounts op elke deelnemende computer moeten worden gesynchroniseerd (dezelfde inlognamen, wachtwoorden en vervaldatums van inloggegevens op alle machines). Anders wordt de situatie veel gecompliceerder. Het is moeilijk om middelgrote peer-to-peer (P2P)-netwerken te onderhouden die alleen lokale registratieprocedures gebruiken.

DC is niet onderworpen aan de vereiste om meerdere gebruikersaccounts op verschillende computers te synchroniseren. Met domeinauthenticatie lokaliseren domeingeregistreerde computers DC's om de accountreferenties van domeingebruikers te presenteren wanneer authenticatieverzoeken worden gedaan. Als een externe gebruiker dus toegang probeert te krijgen tot een lokale bron op een machine, vraagt ​​die machine de DC om de identiteit van de aanvragende gebruiker te verifiëren. Domeingebruikersaccounts bevinden zich alleen op de domeincontroller en worden slechts één keer aangemaakt. Elke lidcomputer die een account in het domein moet verifiëren, kan op elk moment contact opnemen met de DC's. Er zijn geen problemen met het synchroniseren van logins, wachtwoorden en hun vervaldata, omdat inloggegevens en accountbeheer slechts op één plek worden uitgevoerd: op de DC. Ongeacht het aanmeldingstype (lokaal of domein) moet Windows het verzoek van de gebruiker verifiëren.

Windows-verificatieprotocollen

Zoals hierboven vermeld, gebruikt Windows vier hoofdverificatieprotocollen: LAN Manager, NTLM, NTLMv2 en Kerberos. LAN Manager dateert uit de tijd van DOS en werd nog steeds gebruikt met vroege versies van Windows. NTLM werd samen met NT uitgebracht. Nieuw in NT Server 4.0 Service Pack 4 (SP4) was NTLMv2, en Windows 2000 introduceerde Kerberos. Standaard zijn alle computers met Windows 2000 en nieuwere besturingssystemen compatibel met alle vier de verificatieprotocollen. Door de juiste opdrachten naar deze systemen te sturen, kunnen andere werkstations en servers een protocol selecteren om het authenticatieverzoek te verwerken. Windows 9x en latere systemen met volledige softwarepatches zijn compatibel met LM, NTLM en NTLMv2. Op het Microsoft-platform kan Kerberos alleen worden gebruikt door Windows 2000-clients (of hoger) bij toegang tot Windows 2000-domeinen (en hoger). Een computer met Windows 2000 of een nieuwer besturingssysteem moet beschikken over Kerberos en ten minste één ander authenticatieprotocol.

Uit beveiligingsonderzoek is gebleken dat oudere protocollen (LM en NTLM) kwetsbaar zijn voor afluister- en wachtwoordraadaanvallen.

LAN-beheerder

IBM ontwikkelde het LAN Manager-protocol en gebruikte het in vroege versies van Windows en Windows-netwerken. Zoals alle Microsoft-authenticatieprotocollen genereert LAN Manager een wachtwoord-hash (LM-hash) die wordt opgeslagen en gebruikt door de afzender en ontvanger tijdens het authenticatieproces. LAN Manager genereert LM-hashes door alle letters van het wachtwoord in hoofdletters te veranderen, het wachtwoord in twee helften van 7 tekens te splitsen en vervolgens te coderen. De LM-hash wordt vervolgens gebruikt in verschillende opeenvolgende bewerkingen, vergelijkbaar met het hierboven beschreven verzoek-antwoordproces.

Hoewel LAN Manager vroeger heel acceptabel was, wordt het nu als zeer onbetrouwbaar beschouwd. Met behulp van speciale tools kunnen wachtwoorden die zijn gecodeerd met de LAN Manager-hashing-methode in slechts enkele seconden worden omgezet in platte tekst. LM-hashes hebben fundamentele nadelen en kennen ook een aantal kwetsbaarheden:

• wachtwoorden kunnen bestaan ​​uit een beperkte reeks van 128 ASCII-tekens;
• De wachtwoordlengte is niet langer dan 14 tekens;
• als het wachtwoord minder dan 14 tekens bevat, worden de ontbrekende tekens vervangen door een gemakkelijk te raden gehashte vorm, waarmee u de lengte van het wachtwoord nauwkeurig kunt bepalen;
• LAN Manager converteert alle alfabetische tekens in het wachtwoord naar hoofdletters voordat het in de cache wordt opgeslagen.

Waarom is LAN Manager nog steeds niet buiten gebruik? Voor achterwaartse compatibiliteit is het standaard ingeschakeld op alle Windows-computers, inclusief Windows Server 2003. In de nieuwste Windows-authenticatiedatabases wordt de zwakke LM-hash naast de sterkere opgeslagen, voor het geval er een LAN Manager-transactie moet worden uitgevoerd. Als uw onderneming geen andere toepassingen gebruikt waarvoor LAN Manager-authenticatie vereist is, kunt (en moet) u LAN Manager uitschakelen.

NTLM

Met de komst van NT heeft Microsoft een veiliger authenticatieprotocol ontworpen en geïmplementeerd, NTLM. NTLM maakt gebruik van een efficiënter authenticatiealgoritme dat een sterkere wachtwoord-hash creëert (NTLM-hash). Het NTLM-wachtwoord kan maximaal 128 tekens lang zijn. In tegenstelling tot LAN Manager-hashing, die beperkt is tot het gebruik van alleen ASCII-tekens, is NTLM compatibel met de volledige Unicode-tekenset, waardoor de complexiteit van wachtwoorden toeneemt. De NTLM-hash wordt afgebroken bij het 128e teken, omgezet naar een 16-bits Unicode-waarde, verwerkt door de MD4-distributiefunctie en opgeslagen in een hexadecimale reeks van 32 tekens. Door een NTLM-hash te gebruiken bij challenge-response-bewerkingen is de NTLM-authenticatiereeks veel complexer dan de LAN Manager-procedure.

NTLMv2

Als gevolg hiervan bleek dat NTLM ook kwetsbaar was en hebben Microsoft-specialisten NTLMv2 voorbereid, wat nog steeds als redelijk betrouwbaar wordt beschouwd, hoewel Kerberos nu het voorkeursprotocol is. NTLMv2 wordt nog steeds veel gebruikt voor lokale logboekregistratie en andere toepassingen. NTLMv2 is vergelijkbaar met NTLM, maar de NTLMv2-wachtwoord-hash maakt gebruik van HMAC-MD5-berichtauthenticatie en geeft een tijdstempel aan de challenge-response-reeks om aanvallen te voorkomen waarbij een aanvaller inloggegevens registreert en deze later gebruikt.

Over het algemeen is NTLMv2 beter bestand tegen brute force-aanvallen dan NTLM, omdat het protocol een 128-bits coderingssleutel gebruikt. Er zijn slechts twee bekende programma's voor het kraken van wachtwoorden (een daarvan is LC5 van Symantec) die NTLMv2-wachtwoordhashes konden openen.

Kerberos

Microsoft heeft Kerberos aangenomen als het stvoor Windows 2000 en latere AD-domeinen. Kerberos is een open standaard die geschikt is voor samenwerking met buitenlandse domeinen (in UNIX en Linux realms genoemd). Elke DC in AD-domeinen speelt de rol van een distributieserver (Kerberos Distribution Server, KDC) en kan deelnemen aan de authenticatieprocedure. De beveiliging wordt verbeterd door de volgende Kerberos-kenmerken:

• wederzijdse authenticatie tussen client en server;
• betrouwbare wachtwoordbeveiliging, omdat Windows het wachtwoord alleen verzendt tijdens het eerste verzoek en niet bij elke authenticatiegebeurtenis, en alle communicatiesessies gecodeerd zijn;
• een tijdstempel van uitdaging-antwoordreeks voorkomt dat een aanvaller het onderschepte wachtwoord gebruikt nadat een bepaalde tijd is verstreken;
• het serverproces kan namens de gebruiker toegang krijgen tot een externe bron;
• interoperabiliteit.

Een korte beschrijving van hoe Kerberos werkt:

1. Na succesvolle basisauthenticatie vraagt ​​de computer van de gebruiker een beveiligingsticket aan bij de Kerberos-server (DC) voor toekomstige authenticatieverzoeken.
2. De Kerberos-server geeft een ticket uit aan de aanvrager om deel te nemen aan toekomstige authenticatie- en autorisatiegebeurtenissen zonder de originele authenticatiegegevens opnieuw te hoeven overleggen.
3. Wanneer een aanvrager toegang moet krijgen tot een bron op een lidserver, ontvangt hij een ander toegangsticket van de Kerberos-server en presenteert dit ter verificatie aan de bronserver.
4. De initiële authenticatiegegevens worden bij volgende authenticatiesessies niet via netwerklinks verzonden (totdat het ticket dat in stap 2 is uitgegeven, verloopt).

Houd er rekening mee dat hoewel Kerberos op een manier werkt die vergelijkbaar is met een openbare-sleutelinfrastructuur (PKI), alle informatie wordt beschermd met behulp van symmetrische sleutels (in tegenstelling tot de asymmetrische sleutels die in de meeste authenticatiediensten worden gebruikt).

Slimme kaarten

De kracht van wachtwoorden en andere authenticatiemethoden met één identificatie neemt snel af. E-commerce dringt door in het dagelijks leven en zowel het aantal methoden voor identiteitsdiefstal (spam, URL-fraude) als de kans op misbruik van wachtwoorden neemt toe. Veel deskundigen zijn van mening dat tweerichtingsauthenticatie – in de vorm van smartcards, USB-apparaten of andere cryptografische apparaten – in de toekomst gemeengoed zal worden voor internettransacties. Microsoft-ontwikkelaars integreren functies voor het werken met digitale certificaten en smartcards in hun oplossingen. Als u smartcards wilt gebruiken, moet u Certificate Services installeren en smartcardcertificaten distribueren. Natuurlijk hebt u ook fysieke smartcards, lezers en leverancierssoftware nodig. Gebruikers kunnen vervolgens hun smartcards in lokale lezers plaatsen als dat nodig is om toegang te krijgen tot een Windows-computer. Bij correct gebruik kunnen smartcards de betrouwbaarheid van de authenticatie aanzienlijk verbeteren.

Beveiliging van authenticatieprotocol

Sommige artikelen beweren ten onrechte dat het hacken van het authenticatiemechanisme van Microsoft nog steeds eenvoudig is. Van de twintig bestaande tools voor het kraken van wachtwoorden werken er slechts twee met NTLMv2 en slechts één met Kerberos. Maar door een paar eenvoudige stappen te nemen, kunt u deze dreiging afwenden. Om pogingen om uw wachtwoord te raden en opnieuw in te stellen te voorkomen, moet u de volgende stappen ondernemen (de meeste instellingen kunnen lokaal of via Groepsbeleid worden geconfigureerd).

• Schakel het opslaan van LM-hashes uit zoals beschreven in het Microsoft-artikel "Hoe u kunt voorkomen dat Windows een LAN-manager-hash van uw wachtwoord opslaat in Active Directory en lokale SAM-databases" ( http://support.microsoft.com/default.aspx?scid=kb;en-us;299656). Dit wordt gedaan om te voorkomen dat aanvallers het originele wachtwoord onthullen.
• Schakel alle authenticatieprotocollen uit, behalve NTLMv2 en Kerberos (na uitgebreide tests). De procedure wordt beschreven in het Microsoft TechNet-artikel "Netwerkbeveiliging: LAN Manager-verificatieniveau" ().
• Schakel het opstarten vanaf verwisselbare media uit om te voorkomen dat tools voor het kraken van wachtwoorden in het besturingssysteem actief zijn. Als u het opstarten vanaf alle schijven behalve de standaardstations uitschakelt, voorkomt u dat offline programma's voor het kraken van wachtwoorden toegang krijgen tot de authenticatiedatabase waar wachtwoord-hashes worden opgeslagen.
• Gebruikers moeten complexe wachtwoorden van minimaal 8 tekens lang toewijzen.
• Gebruikers moeten hun wachtwoord minstens elk kwartaal wijzigen.
• Activeer de accountvergrendeling gedurende minimaal één minuut met automatische reset. Dit voorkomt dat wachtwoorden online worden geraden.

Verantwoordelijkheden van gebruikers

Met NTLMv2, Kerberos en smartcards beschikt Windows over sterke authenticatiemechanismen die bestand zijn tegen afluisteren en brute-force-aanvallen. Maar best practices en sterke authenticatieprotocollen zullen niet helpen als gebruikers zwakke wachtwoorden toewijzen. Het is noodzakelijk om gebruikers voor te lichten over het correct kiezen van wachtwoorden en om ervoor te zorgen dat wachtwoorden complex en sterk zijn.

Roger Grimes- Windows IT Pro-editor en beveiligingsconsulent. Hij beschikt over CPA-, CISSP-, CEH-, CHFI-, TICSA-, MCT-, MCSE: Security- en Security+-certificaten.

Werkend in de Windows-omgeving komt iedere systeembeheerder op de een of andere manier in aanraking met authenticatiesystemen. Maar voor velen is dit mechanisme een black box, waarbij de essentie van de lopende processen onduidelijk blijft. Tegelijkertijd hangt de veiligheid van het netwerk rechtstreeks af van de juiste authenticatie-instellingen, dus het is niet alleen belangrijk om de methoden en protocollen te kennen, maar ook om hun werk te begrijpen, althans op algemeen niveau.

In het kader van dit materiaal zullen we een opzettelijk vereenvoudigde presentatie van authenticatieprocedures overwegen, voldoende om vervolgens het basisprincipe van de werking te begrijpen. Deze kennis kan worden verdiept door gespecialiseerde literatuur te bestuderen;

Laten we eerst de voorwaarden verduidelijken. Veel mensen verwarren de concepten authenticatie en autorisatie, ook al zijn dit verschillende procedures.

• Authenticatie- komt van het Engelse woord authenticatie, wat vertaald kan worden als identificatie of authenticatie. Dit weerspiegelt volledig de essentie van het proces: gebruikersauthenticatie, d.w.z. we moeten ervoor zorgen dat de gebruiker die toegang probeert te krijgen tot het systeem is wie hij zegt dat hij is.
• Autorisatie- woordvertaling autorisatie middelen toestemming, d.w.z. toegangsrechten tot een object controleren. Het autorisatieproces kan alleen worden toegepast op een geauthenticeerde gebruiker, omdat we, voordat we de toegangsrechten controleren, de identiteit moeten achterhalen van het object waaraan we rechten gaan verlenen.

Laten we, om het gemakkelijker te maken om dit proces voor te stellen, een eenvoudige analogie maken. U bent in het buitenland en een politieagent houdt u tegen, u toont uw paspoort. De politieagent controleert de informatie in het paspoort en vergelijkt de foto - dit is een authenticatieproces. Nadat hij zich ervan heeft vergewist dat u het bent, vraagt ​​de politieagent om uw visum te tonen - dit is een autorisatieproces, d.w.z. jouw recht om hier te zijn.

Op dezelfde manier vraagt ​​een politieagent, nadat hij een migrerende werknemer heeft aangehouden en zijn paspoort heeft gecontroleerd, om een ​​werkvergunning; de buitenlandse gast is dan wel geslaagd voor de authenticatie, maar niet voor de autorisatie; Als de authenticatie mislukt, zal de autorisatie niet doorgaan.

Voor authenticatie in computersystemen wordt traditioneel een combinatie van een gebruikersnaam en een bepaalde geheime zin (wachtwoord) gebruikt om vast te stellen dat de gebruiker precies is wie hij beweert te zijn. Er zijn ook andere authenticatiemethoden, bijvoorbeeld met behulp van een smartcard, maar daar gaan we in dit artikel niet op in.

Lokale authenticatie

Laten we eerst beginnen met lokale authenticatie, waarbij de gebruiker direct wil inloggen op een werkstation dat geen deel uitmaakt van een domein. Wat gebeurt er nadat de gebruiker zijn gebruikersnaam en wachtwoord heeft ingevoerd? Onmiddellijk daarna worden de ingevoerde gegevens verzonden naar het lokale beveiligingssubsysteem (LSA), dat het wachtwoord onmiddellijk omzet in een hash; dit is een cryptografische transformatie in één richting die het onmogelijk maakt om de oorspronkelijke reeks te herstellen. In leesbare tekst wordt het wachtwoord nergens in het systeem opgeslagen of weergegeven; de gebruiker is de enige die het kent.

De LSA neemt vervolgens contact op met de Security Account Manager (SAM) en geeft deze de gebruikersnaam door. De coördinator heeft toegang tot de SAM-database en haalt de wachtwoord-hash van de opgegeven gebruiker op, die is gegenereerd toen het account werd aangemaakt (of tijdens het wachtwoordwijzigingsproces).

De LSA vergelijkt vervolgens de hash van het ingevoerde wachtwoord met de hash uit de SAM-database. Als deze overeenkomen, wordt de authenticatie als succesvol beschouwd en wordt de hash van het ingevoerde wachtwoord in de LSA-serviceopslag geplaatst en blijft daar tot het einde van de sessie. gebruikerssessie.

Als een gebruiker inlogt op een domein, worden andere mechanismen gebruikt voor authenticatie, voornamelijk het Kerberos-protocol. Als een van de partijen dit echter niet kan gebruiken, kunnen NTLM en zelfs oudere LM-protocollen in overleg worden gebruikt. Hieronder zullen we de werking van deze protocollen bespreken.

LAN-manager (LM)

Het LAN Manager-protocol ontstond in de begindagen van op Windows gebaseerde lokale netwerken en werd voor het eerst geïntroduceerd in Windows 3.11 voor werkgroepen, vanwaar hij naar de familie migreerde Windows 9.x. We zullen dit protocol niet overwegen, omdat het al lange tijd niet meer in de natuurlijke omgeving is aangetroffen, maar de ondersteuning ervan, voor compatibiliteitsdoeleinden, is nog steeds aanwezig. En als een modern systeem een ​​verzoek om authenticatie ontvangt met behulp van het LM-protocol, wordt dit, als de juiste machtigingen beschikbaar zijn, verwerkt.

Wat is daar mis mee? Laten we proberen het uit te zoeken. Laten we eerst eens kijken hoe een wachtwoord-hash wordt gemaakt voor het werken met het LM-protocol, zonder in details te treden. Laten we uw aandacht vestigen op de belangrijkste beperkingen:

• Het wachtwoord is hoofdlettergevoelig en wordt omgezet in hoofdletters.
• De wachtwoordlengte is 14 tekens; kortere wachtwoorden worden opgevuld met nullen bij het maken van de hash.
• Het wachtwoord wordt in tweeën gedeeld en voor elk onderdeel wordt een hash gemaakt met behulp van het DES-algoritme.

Op basis van moderne beveiligingseisen kunnen we zeggen dat de LM-hash vrijwel onbeschermd is en, indien onderschept, zeer snel wordt gedecodeerd. Laten we meteen een voorbehoud maken dat direct hash-herstel onmogelijk is, maar vanwege de eenvoud van het coderingsalgoritme is het mogelijk om in extreem korte tijd een combinatie te selecteren die overeenkomt met het wachtwoord.

En nu het meest interessante: de LM-hash wordt voor compatibiliteitsdoeleinden aangemaakt wanneer u een wachtwoord invoert en wordt opgeslagen in systemen tot en met Windows XP. Dit maakt het mogelijk om aan te vallen wanneer het systeem doelbewust een LM-verzoek ontvangt en dit verwerkt. U kunt voorkomen dat er een LM-hash wordt aangemaakt door uw beveiligingsbeleid te wijzigen of wachtwoorden te gebruiken die langer zijn dan 14 tekens. Op systemen die beginnen met Windows Vista en Server 2008 wordt standaard geen LM-hash gemaakt.

NT LAN-manager (NTLM)

Het nieuwe authenticatieprotocol verscheen in Windows NT en is, met enkele wijzigingen, tot op de dag van vandaag bewaard gebleven. En vóór de komst van Kerberos in Windows 2000 was dit het enige authenticatieprotocol in het NT-domein.

Tegenwoordig wordt het NTLM-protocol, of liever de modernere versie NTLMv2, gebruikt om werkgroepcomputers te authenticeren in Active Directory-domeinnetwerken; Kerberos wordt standaard gebruikt, maar als een van de partijen dit protocol niet kan gebruiken, dan wordt in overleg NTLMv2, NTLM gebruikt. en zelfs L.M.

Het werkingsprincipe van NTLM heeft veel gemeen met LM en deze protocollen zijn achterwaarts compatibel, maar er zijn ook aanzienlijke verschillen. De NT-hash wordt gevormd op basis van een wachtwoord van maximaal 128 tekens lang met behulp van het MD4-algoritme. Het wachtwoord is hoofdlettergevoelig en kan niet alleen ACSII-tekens bevatten, maar ook Unicode, wat de sterkte ervan aanzienlijk vergroot in vergelijking met LM.

Hoe werkt het NTLM-protocol? Beschouw het volgende diagram:

Laten we zeggen dat een lokale computer toegang wil krijgen tot een bestandsbron op een andere pc, die we als een server zullen beschouwen, en het is helemaal niet nodig dat deze pc een noordelijk besturingssysteem of serverrollen heeft. Vanuit het oogpunt van het NTLM-protocol is de client degene die toegang krijgt, en de server degene die wordt aangesproken.

Om toegang te krijgen tot een bron, stuurt de client een verzoek naar de server met de gebruikersnaam. Als reactie hierop stuurt de server hem een ​​willekeurig nummer serververzoek. De client codeert dit verzoek op zijn beurt met behulp van het DES-algoritme, waarbij de NT-hash van het wachtwoord als sleutel wordt gebruikt. Ondanks het feit dat de NT-hash 128 bits is, vanwege technische beperkingen, een 40 of 56 bits sleutel wordt gebruikt (de hash is verdeeld in drie delen en elk deel codeert het serververzoek afzonderlijk).

Er wordt een serververzoek aangeroepen dat is gecodeerd met een wachtwoord-hash NTLM-reactie en wordt teruggestuurd naar de server, haalt de server de wachtwoordhash op van de gebruiker wiens naam eraan is doorgegeven uit de SAM-opslag en voert soortgelijke acties uit met het serververzoek, en vergelijkt vervolgens het resulterende resultaat met het NTLM-antwoord. Als de resultaten overeenkomen, is de clientgebruiker wie hij zegt dat hij is en wordt de authenticatie als succesvol beschouwd.

Bij domeinauthenticatie verloopt het proces enigszins anders. In tegenstelling tot lokale gebruikers, wier wachtwoord-hashes worden opgeslagen in lokale SAM-databases, worden wachtwoord-hashes van domeingebruikers opgeslagen op domeincontrollers. Bij het inloggen stuurt de LSA een verzoek naar de beschikbare domeincontroller met de gebruikersnaam en domeinnaam en het verdere proces vindt plaats zoals hierboven weergegeven.

Bij het verkrijgen van toegang tot derde middelen verandert de regeling ook enigszins:

Na een verzoek van de client te hebben ontvangen, zal de server hem ook een serververzoek sturen, maar nadat hij een NTLM-antwoord heeft ontvangen, kan hij de waarde voor verificatie aan zijn kant niet berekenen, omdat hij niet over de wachtwoordhash van de domeingebruiker beschikt , dus het stuurt het NTLM-antwoord om naar de domeincontroller en stuurt het zijn eigen serververzoek. Na ontvangst van deze gegevens haalt de domeincontroller de hash van de opgegeven gebruiker op en berekent op basis van het serververzoek een verificatiecombinatie, die hij vergelijkt met het ontvangen NTLM-antwoord. Als er een match is, wordt er een bericht naar de server gestuurd dat de authenticatie is gelukt.

Zoals u kunt zien, wordt de wachtwoord-hash onder geen enkele omstandigheid via het netwerk verzonden. De hash van het ingevoerde wachtwoord wordt opgeslagen door de LSA-service. Gebruikerswachtwoord-hashes worden opgeslagen in lokale SAM-archieven of in domeincontroller-archieven.

Maar desondanks kan het NTLM-protocol tegenwoordig niet als veilig worden beschouwd. Zwakke codering maakt het mogelijk om de wachtwoord-hash snel te herstellen, en als er niet alleen NTLM, maar ook een LM-reactie is gebruikt, herstel dan het wachtwoord.

Maar de onderschepte hash kan voldoende zijn, aangezien het NTLM-antwoord wordt gegenereerd op basis van het wachtwoord van de gebruiker en de authenticiteit van de client op geen enkele manier door de server wordt geverifieerd. Het is mogelijk om de onderschepte gegevens te gebruiken voor ongeautoriseerde toegang tot netwerkbronnen. Het gebrek aan wederzijdse authenticatie maakt ook man-in-the-middle-aanvallen mogelijk, waarbij de aanvaller zich voordoet als de server van de client en omgekeerd, waarbij hij twee kanalen tot stand brengt en de verzonden gegevens onderschept.

NTLMv2

Microsoft realiseerde zich dat het NTLM-protocol niet voldeed aan de moderne beveiligingsvereisten en introduceerde met de release van Windows 2000 de tweede versie van het NTLMv2-protocol, die aanzienlijk was verbeterd in termen van het verbeteren van de cryptografische sterkte en het tegengaan van veelvoorkomende soorten aanvallen. Vanaf Windows 7/Server 2008 R2 is het gebruik van de NTLM- en LM-protocollen standaard uitgeschakeld.

Laten we meteen het schema met een domeincontroller bekijken; als deze afwezig is, verandert het interactieschema niet, alleen de berekeningen die door de domeincontroller worden uitgevoerd, worden rechtstreeks op de server uitgevoerd.

Net als bij NTLM vertelt een client, wanneer hij contact opneemt met de server, de gebruikersnaam en de domeinnaam, en als reactie stuurt de server hem een ​​willekeurig nummer - serververzoek. Als reactie hierop genereert de client ook een willekeurig getal, waaraan onder meer een tijdstempel wordt toegevoegd, genaamd verzoek van de klant. Door de aanwezigheid van een tijdstempel kunt u een situatie vermijden waarin een aanvaller in eerste instantie onderschepte gegevens verzamelt en deze vervolgens gebruikt om een ​​aanval uit te voeren.

Het serververzoek wordt gecombineerd met het clientverzoek en op basis van deze reeks wordt de HMAC-MD5-hash berekend. Vervolgens wordt uit deze hash nog een HMAC-MD5-hash gehaald, waarbij de sleutel de NT-hash van het wachtwoord van de gebruiker is. Het resulterende resultaat wordt een NTLMv2-antwoord genoemd en wordt samen met het clientverzoek naar de server verzonden.

De cryptografische kracht van dit algoritme is relevant en momenteel zijn er slechts twee gevallen bekend waarin deze hash is gehackt, waarvan er één door Symantec is geproduceerd voor onderzoeksdoeleinden. Het is veilig om te zeggen dat er op dit moment geen wijdverbreide tools zijn voor aanvallen op NTLMv2, in tegenstelling tot NTLM, dat kan worden gehackt door elk schoolkind dat de instructies aandachtig heeft gelezen.

De server, die het NTLMv2-antwoord en het clientverzoek heeft ontvangen, combineert dit laatste met het serververzoek en berekent ook de HMAC-MD5-hash en verzendt deze vervolgens samen met het antwoord naar de domeincontroller. Het haalt de opgeslagen hash van het wachtwoord van de gebruiker op uit de opslag en voert berekeningen uit op de HMAC-MD5-hash van de server- en clientverzoeken, waarbij het resulterende resultaat wordt vergeleken met het NTLMv2-antwoord dat ernaar wordt verzonden. Als er een overeenkomst is, wordt een antwoord dat een succesvolle authenticatie aangeeft, teruggestuurd naar de server.

Tegelijkertijd voert NTLMv2, zoals u misschien hebt gemerkt,, net als zijn voorganger, geen wederzijdse authenticatie uit, hoewel sommige materialen op internet dit aangeven.

Beveiligingsinstellingen

Nu je een idee hebt van hoe authenticatieprotocollen werken, is het tijd om over beveiligingsinstellingen te praten. NTLMv2 is een volledig veilig protocol, maar als het systeem niet correct is geconfigureerd, kan een aanvaller een NTLM- of LM-verzoek verzenden en een overeenkomstig antwoord ontvangen, wat een succesvolle aanval mogelijk maakt.

De keuze van het authenticatieprotocol is de verantwoordelijkheid van lokaal of groepsbeleid. Laten we de beleidseditor openen en naar Computerconfiguratie - Windows-configuratie - Beveiligingsbeleid - Lokaal beleid - Beveiligingsinstellingen gaan. In deze sectie vinden we het beleid Netwerkbeveiliging: LAN Manager-verificatieniveau.

In dezelfde sectie is er een beleid Netwerkbeveiliging: sla geen LAN Manager-hashes op de volgende keer dat u uw wachtwoord wijzigt, dat het maken van een LM-hash uitschakelt, is standaard actief vanaf Vista/Server 2008.

In ons beleid zien we een ruime keuze aan waarden; het is duidelijk dat het huidige beleid vanaf en onder in de lijst als veilig kan worden beschouwd.

Dezelfde waarden kunnen worden ingesteld via het register, wat handig is in netwerken op werkgroepniveau, hiervoor in de sectie HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa u moet een parameter maken DWORD met naam LmCompatibiliteitsniveau, die waarden van 0 tot 5 kan aannemen. Laten we ze in meer detail bekijken:

Naam instellen	Clientcomputer	Domeincontroller	Lm-compatibiliteitsniveau
Verzend LM- en NTLM-antwoorden	Clientcomputers gebruiken LM- en NTLM-verificatie en gebruiken nooit NTLMv2-sessiebeveiliging.		0
Verzend LM en NTLM - gebruik NTLMv2-sessiebeveiliging	Clientcomputers gebruiken LM- en NTLM-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt.	Domeincontrollers maken LM-, NTLM- en NTLMv2-authenticatie mogelijk.	1
Alleen NTLM-antwoord verzenden	Clientcomputers gebruiken NTLMv1-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt.	Domeincontrollers maken LM-, NTLM- en NTLMv2-authenticatie mogelijk.	2
Alleen NTLMv2-antwoord verzenden		Domeincontrollers maken LM-, NTLM- en NTLMv2-authenticatie mogelijk.	3
Alleen NTLMv2-antwoord verzenden. Weigeren LM.	Clientcomputers gebruiken NTLMv2-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt.	Domeincontrollers weigeren LM-authenticatie te accepteren en accepteren alleen NTLM en NTLMv2.	4
Alleen NTLMv2-antwoord verzenden. Weiger LM en NTLM.	Clientcomputers gebruiken NTLMv2-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt.	Domeincontrollers weigeren LM- en NTLM-authenticatie te accepteren, en accepteert alleen NTLMv2.	5

Een oplettende lezer die deze tabel bestudeert, zal er zeker op letten NTLMv2-sessiebeveiliging. Deze functie is, net als alle interacties via NTLMv2 in het algemeen, nogal slecht gedocumenteerd, waardoor veel mensen de betekenis van deze functie verkeerd begrijpen. Maar eigenlijk is alles vrij eenvoudig.

Nadat de client de authenticatie heeft doorstaan, wordt een sessiesleutel gegenereerd, die wordt gebruikt om de authenticiteit tijdens verdere interactie te bevestigen. De NTLM-sessiesleutel is alleen gebaseerd op de NT-hash en blijft hetzelfde totdat de client het wachtwoord van de gebruiker wijzigt. Het lijkt ons dat het niet nodig is om uit te leggen welke veiligheidsrisico's dit met zich meebrengt. NTLMv2-sessiebeveiliging omvat het berekenen van de sessiesleutel met behulp van niet alleen de NT-hash, maar ook server- en clientverzoeken, waardoor de sleutel uniek is en veel beter bestand tegen mogelijke aanvallen. Bovendien kan deze functie worden gebruikt in combinatie met NTLM- of LM-authenticatie.

We hopen dat dit materiaal u zal helpen een dieper inzicht te krijgen in de authenticatieprocessen in Windows-systemen. In dit artikel gaan we uitgebreid in op het ontwerp en de werking van het Kerberos-protocol.