NTLM-gebruikersverificatie

In dit artikel vindt u informatie over NTLM-gebruikersverificatie.

Oorspronkelijk KB-nummer: 102716

Samenvatting

In dit artikel worden de volgende aspecten van NTLM-gebruikersverificatie in Windows besproken:

• Wachtwoordopslag in de accountdatabase
• Gebruikersverificatie met behulp van het MSV1_0-verificatiepakket
• Pass-through-verificatie

Meer informatie

Wachtwoordopslag in de accountdatabase

Gebruikersrecords worden opgeslagen in de SAM-database (Security Accounts Manager) of in de Active Directory-database. Elk gebruikersaccount is gekoppeld aan twee wachtwoorden: het met LAN Manager compatibele wachtwoord en het Windows-wachtwoord. Elk wachtwoord wordt versleuteld en opgeslagen in de SAM-database of in de Active Directory-database.

Het wachtwoord dat compatibel is met LAN Manager is compatibel met het wachtwoord dat wordt gebruikt door LAN Manager. Dit wachtwoord is gebaseerd op de originele OEM-tekenset (Equipment Manufacturer). Dit wachtwoord is niet hoofdlettergevoelig en mag maximaal 14 tekens lang zijn. De OWF-versie van dit wachtwoord wordt ook wel de LAN Manager OWF- of ESTD-versie genoemd. Dit wachtwoord wordt berekend met behulp van DES-versleuteling om een constante te versleutelen met het wachtwoord voor duidelijke tekst. Het LAN Manager OWF-wachtwoord is 16 bytes lang. De eerste 7 bytes van het wachtwoord voor duidelijke tekst worden gebruikt om de eerste 8 bytes van het LAN Manager OWF-wachtwoord te berekenen. De tweede 7 bytes van het wachtwoord voor duidelijke tekst worden gebruikt voor het computeren van de tweede 8 bytes van het LAN Manager OWF-wachtwoord.

Het Windows-wachtwoord is gebaseerd op de Unicode-tekenset. Dit wachtwoord is hoofdlettergevoelig en kan maximaal 128 tekens lang zijn. De OWF-versie van dit wachtwoord wordt ook wel het Windows OWF-wachtwoord genoemd. Dit wachtwoord wordt berekend met behulp van de RSA MD4-hashfunctie. Met deze functie wordt een samenvatting van 16 bytes berekend van een tekenreeks met een variabele lengte van wachtwoordbytes.

Elk gebruikersaccount kan het LAN Manager-wachtwoord of het Windows-wachtwoord niet hebben. Elke poging wordt echter gedaan om beide versies van het wachtwoord te onderhouden.

Als het gebruikersaccount bijvoorbeeld wordt overgezet vanuit een LAN Manager UAS-database met behulp van PortUas, of als het wachtwoord wordt gewijzigd van een LAN Manager-client of van een Windows for Workgroups-client, bestaat alleen de LAN Manager-versie van het wachtwoord. Als het wachtwoord is ingesteld of gewijzigd op een Windows-client en het wachtwoord geen LAN Manager-weergave heeft, bestaat alleen de Windows-versie van het wachtwoord. (Het wachtwoord heeft mogelijk geen LAN Manager-weergave omdat het wachtwoord langer is dan 14 tekens of omdat de tekens niet kunnen worden weergegeven in de OEM-tekenset.)

Gebruikersinterfacelimieten in Windows laten Windows-wachtwoorden niet langer zijn dan 14 tekens. De gevolgen van deze beperking worden verderop in dit artikel besproken.

In Windows 2000 Service Pack 2 en in latere versies van Windows is een instelling beschikbaar waarmee u kunt voorkomen dat Windows een LAN Manager-hash van uw wachtwoord opslaat. Raadpleeg het volgende artikelnummer voor meer informatie om het artikel in de Microsoft Knowledge Base weer te geven:

299656 Voorkomen dat Windows een LAN-manager-hash van uw wachtwoord opslaat in Active Directory en lokale SAM-databases

Notitie

Microsoft biedt geen ondersteuning voor het handmatig of programmatisch wijzigen van de SAM-database.

Gebruikersverificatie met behulp van het MSV1_0-verificatiepakket

Windows maakt gebruik van de LsaLogonUser-API voor allerlei soorten gebruikersverificaties. De LsaLogonUser-API verifieert gebruikers door een verificatiepakket aan te roepen. LsaLogonUser roept standaard het MSV1_0-verificatiepakket (MSV) aan. Dit pakket is opgenomen in Windows NT. In het MSV-verificatiepakket worden gebruikersrecords opgeslagen in de SAM-database. Dit pakket ondersteunt passthrough-verificatie van gebruikers in andere domeinen met behulp van de Netlogon-service.

Intern is het MSV-verificatiepakket onderverdeeld in twee delen. Het eerste deel van het MSV-verificatiepakket wordt uitgevoerd op de computer waarmee verbinding wordt gemaakt. Het tweede deel wordt uitgevoerd op de computer die het gebruikersaccount bevat. Wanneer beide onderdelen op dezelfde computer worden uitgevoerd, roept het eerste deel van het MSV-verificatiepakket het tweede deel aan zonder de Netlogon-service te betrekken. Het eerste deel van het MSV-verificatiepakket herkent dat passthrough-verificatie is vereist omdat de doorgegeven domeinnaam niet zijn eigen domeinnaam is. Wanneer passthrough-verificatie is vereist, geeft MSV de aanvraag door aan de Netlogon-service. De Netlogon-service stuurt de aanvraag vervolgens naar de Netlogon-service op de doelcomputer. Op zijn beurt geeft de Netlogon-service de aanvraag door aan het andere deel van het MSV-verificatiepakket op die computer.

LsaLogonUser ondersteunt interactieve aanmeldingen, serviceaanmeldingen en netwerkaanmeldingen. In het MSV-verificatiepakket geven alle vormen van aanmelding de naam van het gebruikersaccount, de naam van het domein met het gebruikersaccount en een functie van het wachtwoord van de gebruiker door. De verschillende soorten aanmelding vertegenwoordigen het wachtwoord anders wanneer ze het doorgeven aan LsaLogonUser.

Voor interactieve aanmeldingen, batchaanmeldingen en serviceaanmeldingen bevindt de aanmeldingsclient zich op de computer waarop het eerste deel van het MSV-verificatiepakket wordt uitgevoerd. In dit geval wordt het wachtwoord zonder tekst doorgegeven aan LsaLogonUser en aan het eerste deel van het MSV-verificatiepakket. Voor serviceaanmeldingen en batchaanmeldingen bieden servicebeheer en taakplanner een veiligere manier om de referenties van het account op te slaan.

Het eerste deel van het MSV-verificatiepakket converteert het wachtwoord zonder tekst zowel naar een LAN Manager OWF-wachtwoord als naar een Windows NT OWF-wachtwoord. Vervolgens geeft het eerste deel van het pakket het wachtwoord voor duidelijke tekst door aan de NetLogon-service of aan het tweede deel van het pakket. Het tweede deel voert vervolgens een query uit op de SAM-database voor de OWF-wachtwoorden en zorgt ervoor dat ze identiek zijn.

Voor netwerkaanmeldingen kreeg de client die verbinding maakt met de computer eerder een uitdaging van 16 bytes of 'nonce'. Als de client een LAN Manager-client is, heeft de client een antwoord van 24 bytes berekend door de 16-byte-uitdaging te versleutelen met het 16-byte LAN Manager OWF-wachtwoord. De LAN Manager-client geeft vervolgens dit "LAN Manager Challenge Response" door aan de server. Als de client een Windows-client is, wordt een 'Windows NT-vraagantwoord' berekend met behulp van hetzelfde algoritme. De Windows-client gebruikt echter de Windows 16-byte Windows OWF-gegevens in plaats van de LAN Manager OWF-gegevens. De Windows-client geeft vervolgens zowel het LAN Manager-vraagantwoord als het Antwoord van de Windows NT-vraag door aan de server. In beide gevallen verifieert de server de gebruiker door het volgende door te geven aan de LsaLogonUser-API:

• De domeinnaam
• De gebruikersnaam
• De oorspronkelijke uitdaging
• Antwoord van de LAN Manager-uitdaging
• Het optionele antwoord van de Windows NT-vraag

In het eerste deel van het MSV-verificatiepakket wordt deze informatie ongewijzigd doorgegeven aan het tweede deel. Eerst voert het tweede deel een query uit op de OWF-wachtwoorden uit de SAM-database of uit de Active Directory-database. Vervolgens berekent het tweede deel het antwoord van de uitdaging met behulp van het OWF-wachtwoord uit de database en de uitdaging die is doorgegeven. Het tweede deel vergelijkt vervolgens het berekende antwoord op de uitdaging met het antwoord van de geslaagde uitdaging.

Notitie

Met NTLMv2 kan de client ook een uitdaging verzenden, samen met het gebruik van sessiesleutels die helpen het risico op veelvoorkomende aanvallen te verminderen.

Zoals eerder vermeld, ontbreekt de versie van het wachtwoord mogelijk in de SAM-database of in de Active Directory-database. Beide versies van het wachtwoord ontbreken mogelijk ook in de aanroep van LsaLogonUser. Als zowel de Windows-versie van het wachtwoord uit de SAM-database als de Windows-versie van het wachtwoord van LsaLogonUser beschikbaar is, worden beide gebruikt. Anders wordt de LAN Manager-versie van het wachtwoord gebruikt ter vergelijking. Met deze regel kunt u hoofdlettergevoeligheid afdwingen wanneer netwerkaanmeldingen plaatsvinden van Windows naar Windows. Met deze regel is ook compatibiliteit met eerdere versies mogelijk.

Pass-through-verificatie

De NetLogon-service implementeert passthrough-verificatie. De volgende functies worden uitgevoerd:

• Selecteert het domein waaraan de verificatieaanvraag moet worden doorgegeven.
• Hiermee selecteert u de server in het domein.
• Geeft de verificatieaanvraag door aan de geselecteerde server.

Het selecteren van het domein is eenvoudig. De domeinnaam wordt doorgegeven aan LsaLogonUser. De domeinnaam wordt als volgt verwerkt:

• Als de domeinnaam overeenkomt met de naam van de SAM-database, wordt de verificatie op die computer verwerkt. Op een Windows-werkstation dat lid is van een domein, wordt de naam van de SAM-database beschouwd als de naam van de computer. Op een Active Directory-domeincontroller is de naam van de accountdatabase de naam van het domein. Op een computer die geen lid is van een domein, verwerken alle aanmeldingen aanvragen lokaal.
• Als de opgegeven domeinnaam wordt vertrouwd door dit domein, wordt de verificatieaanvraag doorgegeven aan het vertrouwde domein. Op Active Directory-domeincontrollers is de lijst met vertrouwde domeinen eenvoudig beschikbaar. Bij een lid van een Windows-domein wordt de aanvraag altijd doorgegeven aan het primaire domein van het werkstation, zodat het primaire domein kan bepalen of het opgegeven domein wordt vertrouwd.
• Als de opgegeven domeinnaam niet wordt vertrouwd door het domein, wordt de verificatieaanvraag verwerkt op de computer die wordt verbonden alsof de opgegeven domeinnaam die domeinnaam was. NetLogon maakt geen onderscheid tussen een niet-bestaand domein, een niet-vertrouwd domein en een onjuist getypte domeinnaam.

NetLogon selecteert een server in het domein door een proces dat detectie wordt genoemd. Een Windows-werkstation detecteert de naam van een van de Windows Active Directory-domeincontrollers in het primaire domein. Een Active Directory-domeincontroller detecteert de naam van een Active Directory-domeincontroller in elk vertrouwd domein. Het onderdeel dat de detectie uitvoert, is de DC-locator die wordt uitgevoerd in de Netlogon-service. De DC-locator gebruikt NETBIOS- of DNS-naamomzetting om de benodigde servers te vinden, afhankelijk van het type domein en de vertrouwensrelatie die is geconfigureerd.