Overzicht
Beveiligingsinstellingen en toewijzingen van gebruikersrechten kunnen worden gewijzigd in lokaal beleid en groepsbeleid om de beveiliging op domeincontrollers en lidcomputers te verbeteren. Het nadeel van verhoogde beveiliging is echter de introductie van incompatibiliteiten met clients, services en programma's.
In dit artikel worden compatibiliteiten beschreven die kunnen optreden op clientcomputers waarop Windows XP of een eerdere versie van Windows wordt uitgevoerd wanneer u bepaalde beveiligingsinstellingen en toewijzingen van gebruikersrechten in een Windows Server 2003-domein of een ouder Windows Server-domein wijzigt.
Zie de volgende artikelen voor informatie over groepsbeleid voor Windows 7, Windows Server 2008 R2 en Windows Server 2008:
- Zie groepsbeleid beheer voor IT-professionals voor Windows 7
- Zie Nieuw in het groepsbeleid voor Windows 7 en Windows Server 2008 R2
Opmerking: De resterende inhoud in dit artikel is specifiek voor Windows XP, Windows Server 2003 en eerdere versies van Windows.
Windows XP
U kunt onjuist geconfigureerde beveiligingsinstellingen beter bekend maken door de beveiligingsinstellingen te wijzigen met het hulpprogramma Objecteditor voor groepsbeleid. Wanneer u Objecteditor voor groepsbeleid gebruikt, worden de toewijzingen van gebruikersrechten uitgebreid uitgevoerd op de volgende besturingssystemen:
- Windows XP Professional Service Pack 2 (SP2)
- Windows Server 2003 Service Pack 1 (SP1)
De uitgebreide functie is een dialoogvenster met een koppeling naar dit artikel. Het dialoogvenster wordt weergegeven wanneer u een beveiligingsinstelling of de toewijzing van gebruikersrechten wijzigt in een instelling die minder compatibel en meer beperkend is. Als u dezelfde beveiligingsinstelling of toewijzing van gebruikersrechten rechtstreeks wijzigt via het register of met behulp van beveiligingssjablonen, heeft het hetzelfde effect als het wijzigen van de instelling in Objecteditor voor groepsbeleid. Het dialoogvenster met de koppeling naar dit artikel wordt echter niet weergegeven.
Dit artikel bevat voorbeelden van clients, programma's en bewerkingen die worden beïnvloed door specifieke beveiligingsinstellingen of toewijzingen van gebruikersrechten. De voorbeelden zijn echter niet bindend voor alle Microsoft-besturingssystemen, voor alle besturingssystemen van derden of voor alle programmaversies waarin dit probleem zich voordoet. Niet alle beveiligingsinstellingen en toewijzingen van gebruikersrechten zijn in dit artikel opgenomen.
We raden u aan de compatibiliteit van alle beveiligingsgerelateerde configuratiewijzigingen in een testforest te valideren voordat u ze in een productieomgeving introduceert. Het testforest moet op de volgende manieren een afspiegeling zijn van het productieforest:
Versies van het besturingssysteem voor clients en servers, client- en serverprogramma's, servicepackversies, hotfixes, schemawijzigingen, beveiligingsgroepen, groepslidmaatschappen, machtigingen voor objecten in het bestandssysteem, gedeelde mappen, het register, Active Directory-adreslijstservice, lokale en groepsbeleid-instellingen, en type en locatie van aantal objecten
Beheertaken die worden uitgevoerd, beheerhulpprogramma's die worden gebruikt en besturingssystemen die worden gebruikt om beheertaken uit te voeren
Bewerkingen die worden uitgevoerd, zoals:
- Aanmeldingsverificatie van computers en gebruikers
- Wachtwoorden opnieuw instellen door gebruikers, computers en beheerders
- Bladeren
- Machtigingen instellen voor het bestandssysteem, voor gedeelde mappen, voor het register en voor Active Directory-bronnen door ACL-editor te gebruiken in alle clientbesturingssystemen in alle account- of brondomeinen van alle clientbesturingssystemen van alle accounts of brondomeinen
- Afdrukken vanuit administratieve en niet-administratieve rekeningen
Windows Server 2003 SP1
Waarschuwingen in gpedit.msc
Om klanten ervan bewust te maken dat ze een gebruikersrecht of beveiligingsoptie bewerken die een negatieve invloed op hun netwerk kan hebben, zijn er twee waarschuwingsmechanismen toegevoegd aan gpedit.msc. Wanneer beheerders een gebruikersrecht bewerken dat nadelige gevolgen kan hebben voor de hele onderneming, zien ze een nieuw pictogram dat lijkt op een rendementsteken. De gebruiker ontvangt ook een waarschuwing met een koppeling naar een Microsoft Knowledge Base-artikel 823659. De tekst van dit bericht is als volgt:
Als u deze instelling wijzigt, kan dit van invloed zijn op de compatibiliteit met clients, services en toepassingen. Zie <Gebruikersrechten of beveiligingsoptie wordt gewijzigd> (Q823659) voor meer informatie. Als u naar dit Knowledge Base-artikel bent doorverwezen via een koppeling in Gpedit.msc, zorg er dan voor dat u de gegeven uitleg en het mogelijke effect van het wijzigen van deze instelling leest en begrijpt. Hieronder vindt u een lijst met gebruikersrechten die de waarschuwingstekst bevatten:
- Access this computer from network
- Lokaal aanmelden
- Controle op traverse omzeilen
- Computers en gebruikers inschakelen voor vertrouwde overdracht
Hier volgen de beveiligingsopties met een waarschuwing en een pop-upbericht:
- Domeinlid: gegevens in Secure Channel digitaal versleutelen of ondertekenen (altijd)
- Domeinlid: Sterke sessietoets (Windows 2000 of een latere versie) vereisen
- Domeincontroller: ondertekeningsvereisten voor LDAP-server
- Microsoft-netwerkserver: communicatie digitaal ondertekenen (altijd)
- Netwerktoegang: Anonieme sid / naamvertaling toestaan
- Netwerktoegang: anonieme opsomming van SAM-accounts en -shares niet toestaan
- Netwerkbeveiliging: LAN Manager-verificatieniveau
- Controle: Sluit het systeem onmiddellijk af als beveiligingsaudits niet kunnen worden geregistreerd
- Netwerktoegang: Ondertekeningsvereisten voor LDAP-client
Meer informatie
In de volgende secties worden compatibiliteiten beschreven die kunnen optreden wanneer u bepaalde instellingen in Windows NT 4.0-domeinen, Windows 2000-domeinen en Windows Server 2003-domeinen wijzigt.
Gebruikersrechten
In de volgende lijst wordt een gebruikersrecht beschreven, worden configuratie-instellingen geïdentificeerd die problemen kunnen veroorzaken, wordt beschreven waarom u het gebruikersrecht moet toepassen en waarom u het gebruikersrecht kunt verwijderen, en worden voorbeelden gegeven van compatibiliteitsproblemen die kunnen optreden wanneer het gebruikersrecht wordt geconfigureerd.
Access this computer from network
Achtergrond
Voor de mogelijkheid om te kunnen communiceren met externe Windows-computers is het gebruikersrecht Toegang tot deze computer vanaf netwerk vereist. Voorbeelden van dergelijke netwerkbewerkingen zijn:
- Replicatie van Active Directory tussen domeincontrollers in een gemeenschappelijk domein of forest
- Verificatieaanvragen van gebruikers en computers voor domeincontrollers
- Toegang tot gedeelde mappen, printers en andere systeemservices die zich op externe computers op het netwerk bevinden
Gebruikers, computers en serviceaccounts verkrijgen of verliezen het gebruikersrecht Toegang tot deze computer van netwerk door expliciet of impliciet te worden toegevoegd aan of verwijderd uit een beveiligingsgroep waaraan dit gebruikersrecht is verleend. Een gebruikersaccount of een computeraccount kan bijvoorbeeld expliciet worden toegevoegd aan een aangepaste beveiligingsgroep of een ingebouwde beveiligingsgroep door een beheerder, of kan impliciet door het besturingssysteem worden toegevoegd aan een berekende beveiligingsgroep zoals Domeingebruikers, Geverifieerde gebruikers of Bedrijfsdomeincontrollers.
Gebruikersaccounts en computeraccounts krijgen standaard het recht Toegang tot deze computer van netwerkgebruiker wanneer berekende groepen zoals Iedereen of, bij voorkeur, Geverifieerde gebruikers en, voor domeincontrollers, de groep Ondernemingsdomeincontrollers zijn gedefinieerd in de standaarddomeincontrollers groepsbeleid Object (GPO).
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- De beveiligingsgroep Enterprise-domeincontrollers verwijderen uit dit gebruikersrecht
- Het verwijderen van de groep Geverifieerde gebruikers of een expliciete groep die gebruikers, computers en serviceaccounts het gebruikersrecht geeft om via het netwerk verbinding te maken met computers
- Alle gebruikers en computers van dit gebruikersrecht verwijderen
Redenen om dit gebruikersrecht te verlenen
- Het verlenen van het recht Toegang tot deze computer van netwerkgebruiker aan de groep Bedrijfsdomeincontrollers voldoet aan de verificatievereisten waaraan Active Directory-replicatie moet voldoen om replicatie tussen domeincontrollers in hetzelfde forest te laten plaatsvinden.
- Met dit gebruikersrecht hebben gebruikers en computers toegang tot gedeelde bestanden, printers en systeemservices, waaronder Active Directory.
- Dit gebruikersrecht is vereist voor gebruikers om e-mail te openen met behulp van vroege versies van Microsoft Outlook Web Access (OWA).
Redenen voor het verwijderen van dit gebruikersrecht
- Gebruikers die hun computers kunnen verbinden met het netwerk, hebben toegang tot bronnen op externe computers waarvoor ze machtigingen hebben. Dit gebruikersrecht is bijvoorbeeld vereist om een gebruiker toegang te geven tot gedeelde printers en mappen. Als dit gebruikersrecht is verleend aan de groep Iedereen en als voor sommige gedeelde mappen zowel share- als NTFS-bestandssysteemmachtigingen zijn geconfigureerd zodat dezelfde groep leestoegang heeft, kan iedereen bestanden in die gedeelde mappen bekijken. Dit is echter een onwaarschijnlijke situatie voor nieuwe installaties van Windows Server 2003, omdat de groep Iedereen niet is opgenomen in de standaardshare en NTFS-machtigingen in Windows Server 2003. Voor systemen die zijn bijgewerkt vanaf Microsoft Windows NT 4.0 of Windows 2000 bestaat er mogelijk een hoger risico voor dit beveiligingslek omdat de standaardshare-machtigingen en de machtigingen van het bestandssysteem voor deze besturingssystemen niet zo beperkend zijn als de standaardmachtigingen in Windows Server 2003.
- Er is geen geldige reden om de groep Enterprise-domeincontrollers uit dit gebruikersrecht te verwijderen.
- De groep Iedereen wordt over het algemeen verwijderd ten gunste van de groep Geverifieerde gebruikers. Als de groep Iedereen wordt verwijderd, moet aan de groep Geverifieerde gebruikers dit gebruikersrecht worden verleend.
- Windows NT 4.0-domeinen die zijn bijgewerkt naar Windows 2000 verlenen het recht Toegang tot deze computer vanaf netwerkgebruiker niet expliciet aan de groep Iedereen, de groep Geverifieerde gebruikers of de groep Ondernemingsdomeincontrollers. Wanneer u daarom de groep Iedereen uit het Windows NT 4.0-domeinbeleid verwijdert, mislukt Active Directory-replicatie met het foutbericht 'Toegang geweigerd' nadat u een upgrade naar Windows 2000 hebt uitgevoerd. Winnt32.exe in Windows Server 2003 voorkomt deze onjuiste configuratie door deze gebruiker het recht te verlenen aan de groep Enterprise Domain Controllers wanneer u een upgrade uitvoert van primaire domeincontrollers (PDC's) voor Windows NT 4.0. Geef dit gebruikersrecht aan de groep Ondernemingsdomeincontrollers als dit niet aanwezig is in de objecteditor voor groepsbeleid.
Voorbeelden van compatibiliteitsproblemen
Windows 2000 en Windows Server 2003: Replicatie van de volgende partities mislukt met fouten 'Toegang geweigerd' zoals gerapporteerd door bewakingsprogramma's zoals REPLMON en REPADMIN of replicatiegebeurtenissen in het gebeurtenislogboek.
- Partitie Active Directory-schema
- Configuration partition
- Domain partition
- Verdeling van globale catalogus
- Partitie van toepassing
Alle Microsoft-netwerkbesturingssystemen: verificatie van gebruikersaccounts vanaf externe netwerkclientcomputers mislukt tenzij dit gebruikersrecht is verleend aan de gebruiker of een beveiligingsgroep waarvan de gebruiker lid is.
Alle Microsoft-netwerkbesturingssystemen: accountverificatie vanaf externe netwerkclients mislukt tenzij het account of een beveiligingsgroep waarvan het account lid is, dit gebruikersrecht heeft gekregen. Dit scenario is van toepassing op gebruikers-, computer- en serviceaccounts.
Alle Microsoft-netwerkbesturingssystemen: als u alle accounts van dit gebruikersrecht verwijdert, kan geen enkel account zich aanmelden bij het domein of toegang krijgen tot netwerkbronnen. Als berekende groepen, zoals Ondernemingsdomeincontrollers, Iedereen of Geverifieerde gebruikers worden verwijderd, moet u deze gebruikers expliciet rechten verlenen aan accounts of beveiligingsgroepen waarvan het account lid is, om toegang te krijgen tot externe computers via het netwerk. Dit scenario is van toepassing op alle gebruikersaccounts, alle computeraccounts en alle serviceaccounts.
Alle Microsoft-netwerkbesturingssystemen: het lokale beheerdersaccount gebruikt een 'leeg' wachtwoord. Netwerkconnectiviteit met lege wachtwoorden is niet toegestaan voor beheerdersaccounts in een domeinomgeving. Met deze configuratie kunt u het foutbericht 'Toegang geweigerd' verwachten.
Lokaal aanmelden toestaan
Achtergrond
Gebruikers die zich proberen aan te melden op de console van een Windows-computer (met de sneltoets CTRL+ALT+DELETE) en accounts die een service proberen te starten, moeten lokale aanmeldingsbevoegdheden hebben op de hostcomputer. Voorbeelden van lokale aanmeldingsbewerkingen zijn beheerders die zich aanmelden op de consoles van lidcomputers of domeincontrollers in de hele onderneming en domeingebruikers die zich aanmelden bij lidcomputers om toegang tot hun bureaublad te krijgen met niet-bevoegde accounts. Gebruikers die gebruikmaken van een Verbinding met extern bureaublad of Terminal Services, moeten het recht Lokaal gebruiker toestaan hebben op doelcomputers met Windows 2000 of Windows XP, omdat deze aanmeldingswijzen als lokaal op de hostcomputer worden beschouwd. Gebruikers die zich aanmelden bij een server waarvoor Terminal Server is ingeschakeld en die niet over dit gebruikersrecht beschikken, kunnen nog altijd een externe interactieve sessie starten in domeinen met Windows Server 2003 als ze het gebruikersrecht Aanmelden via Terminal Services toestaan hebben.
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- Beheerdersbeveiligingsgroepen, waaronder accountoperators, back-upoperators, afdrukoperators of serveroperators, en de ingebouwde groep Administrators, verwijderen uit het standaardbeleid van de domeincontroller.
- Serviceaccounts die worden gebruikt door onderdelen en door programma's op lidcomputers en op domeincontrollers in het domein, te verwijderen uit het standaardbeleid van de domeincontroller.
- Gebruikers of beveiligingsgroepen verwijderen die zich aanmelden bij de console van lidcomputers in het domein.
- Serviceaccounts verwijderen die zijn gedefinieerd in de lokale SAM-database (Security Accounts Manager) van lidcomputers of werkgroepcomputers.
- Het verwijderen van niet-ingebouwde beheerdersaccounts die worden geverifieerd via Terminal Services die draaien op een domeincontroller.
- Alle gebruikersaccounts in het domein expliciet of impliciet via de groep Iedereen toevoegen aan het lokale aanmeldingsrecht Aanmelding weigeren. Deze configuratie voorkomt dat gebruikers zich kunnen aanmelden bij een lidcomputer of een domeincontroller in het domein.
Redenen om dit gebruikersrecht te verlenen
- Gebruikers moeten het recht hebben om lokaal aanmelden toe te staan om toegang te krijgen tot de console of het bureaublad van een werkgroepcomputer, een lidcomputer of een domeincontroller.
- Gebruikers moeten dit gebruikersrecht hebben om zich aan te melden via een Terminal Services-sessie die wordt uitgevoerd op een op Windows 2000 gebaseerde lidcomputer of domeincontroller.
Redenen voor het verwijderen van dit gebruikersrecht
- Als je de consoletoegang tot legitieme gebruikersaccounts niet beperkt, kan dit ertoe leiden dat onbevoegde gebruikers schadelijke code downloaden en uitvoeren om hun gebruikersrechten te wijzigen.
- Door het verwijderen van het gebruikersrecht Lokaal aanmelden toestaan wordt voorkomen dat onbevoegden zich kunnen aanmelden op de consoles van computers, zoals domeincontrollers of toepassingsservers.
- Door verwijdering van dit aanmeldingsrecht voorkomt u dat niet-domeinaccounts zich kunnen aanmelden op de console van lidcomputers in het domein.
Voorbeelden van compatibiliteitsproblemen
- Windows 2000-terminalservers: het lokale gebruikersrecht Aanmelden toestaan is vereist om gebruikers zich te laten aanmelden bij Windows 2000-terminalservers.
- Windows NT 4.0, Windows 2000, Windows XP of Windows Server 2003: Gebruikersaccounts moeten dit gebruikersrecht krijgen om zich aan te melden op de console van computers die Windows NT 4.0, Windows 2000, Windows XP of Windows Server 2003 draaien.
- Windows NT 4.0 en hoger: Als u op computers met Windows NT 4.0 en hoger het lokaal gebruikersrecht Aanmelden toestaan toevoegt, maar u impliciet of expliciet ook het lokale aanmeldingsrecht voor aanmelding weigeren verleent, kunnen de accounts zich niet aanmelden bij de console van de domeincontrollers.
Controle op traverse omzeilen
Achtergrond
Met het gebruikersrecht Controle van de regel Omzeilen kan de gebruiker door mappen in het NTFS-bestandssysteem of in het register bladeren zonder te controleren of de speciale toegangsmachtiging voor de Traverse-map is toegestaan. Het gebruikersrecht Controle overslaan staat de gebruiker niet toe de inhoud van een map weer te geven. Hiermee kan de gebruiker alleen door de mappen bladeren.
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- Het verwijderen van niet-beheerdersaccounts die zich aanmelden bij op Windows 2000 gebaseerde Terminal Services-computers of op Windows Server 2003 gebaseerde Terminal Services-computers die geen toegang hebben tot bestanden en mappen in het bestandssysteem.
- De groep Iedereen verwijderen uit de lijst met beveiligingsprincipals die standaard over dit gebruikersrecht beschikken. Windows-besturingssystemen, en ook veel programma's, zijn ontworpen met de verwachting dat iedereen die legitiem toegang heeft tot de computer, het gebruikersrecht heeft om de Bypass traverse te controleren. Het verwijderen van de groep Iedereen uit de lijst met beveiligingsprincipals die standaard over dit gebruikersrecht beschikken, kan daarom leiden tot instabiliteit van het besturingssysteem of tot programmafouten. Het is beter dat u deze instelling op de standaardinstelling laat staan.
Redenen om dit gebruikersrecht te verlenen
De standaardinstelling voor het gebruikersrecht Controle op overslaan is om iedereen toe te staan de controle op traverse te omzeilen. Voor ervaren Windows-systeembeheerders is dit het verwachte gedrag en zij configureren SACL's (File System Access Control Lists) dienovereenkomstig. Het enige scenario waarin de standaardconfiguratie tot een ongeluk kan leiden, is als de beheerder die machtigingen configureert het gedrag niet begrijpt en verwacht dat gebruikers die geen toegang hebben tot een bovenliggende map, geen toegang hebben tot de inhoud van onderliggende mappen.
Redenen voor het verwijderen van dit gebruikersrecht
Organisaties die zich grote zorgen maken over de beveiliging kunnen de toegang tot de bestanden of mappen in het bestandssysteem verhinderen om de groep Iedereen of zelfs de groep Gebruikers te verwijderen uit de lijst met groepen waarvoor het gebruikersrecht Controle door negeren is toegestaan.
Voorbeelden van compatibiliteitsproblemen
Windows 2000, Windows Server 2003: Als het gebruikersrecht Controle omzeilen wordt verwijderd of onjuist is geconfigureerd op computers met Windows 2000 of Windows Server 2003, worden de instellingen van het groepsbeleid in de map SYVOL niet gerepliceerd tussen domeincontrollers in het domein.
Windows 2000, Windows XP Professional, Windows Server 2003: Computers met Windows 2000, Windows XP Professional of Windows Server 2003 registreren gebeurtenissen 1000 en 1202 en kunnen geen computerbeleid en gebruikersbeleid toepassen wanneer de vereiste bestandssysteemmachtigingen uit de SYSVOL-structuur worden verwijderd als het gebruikersrecht voor het controleren van de bypass-controle is verwijderd of verkeerd is geconfigureerd.
Windows 2000, Windows Server 2003: Op computers met Windows 2000 of Windows Server 2003 verdwijnt het tabblad Quotum in Windows Verkenner wanneer u eigenschappen op een volume bekijkt.
Windows 2000: Niet-beheerders die zich aanmelden bij een Windows 2000-terminalserver kunnen het volgende foutbericht ontvangen:
Opmerking
Userinit.exe toepassingsfout. De toepassing kon niet goed worden geïnitialiseerd 0xc0000142 klik op OK om de app te beëindigen.
Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Gebruikers met computers met Windows NT 4.0, Windows 2000, Windows XP of Windows Server 2003 hebben mogelijk geen toegang tot gedeelde mappen of bestanden in gedeelde mappen en krijgen mogelijk de foutmelding 'Toegang geweigerd' als aan hen het gebruikersrecht Controle van overslaan niet is verleend.
Windows NT 4.0: Op computers met Windows NT 4.0 zorgt het verwijderen van het gebruikersrecht voor het controleren van de bypass-traverse ervoor dat een bestandskopie bestandsstromen verliest. Als u dit gebruikersrecht verwijdert en een bestand vanuit een Windows-client of Macintosh-client wordt gekopieerd naar een Windows NT 4.0-domeincontroller waarop Services for Macintosh wordt uitgevoerd, gaat de doelbestandsstroom verloren en wordt het bestand alleen als tekstbestand weergegeven.
Microsoft Windows 95, Microsoft Windows 98: Op een clientcomputer met Windows 95 of Windows 98 mislukt de opdracht net use * /home met het foutbericht 'Toegang geweigerd' als aan de groep Geverifieerde gebruikers niet het gebruikersrecht Bypass traverse checking wordt verleend.
Outlook Web Access: niet-beheerders kunnen zich niet aanmelden bij Microsoft Outlook Web Access en ontvangen het foutbericht 'Toegang geweigerd' als aan hen het gebruikersrecht Controle van overslaan niet is verleend.
Beveiligingsinstellingen
In de volgende lijst wordt een beveiligingsinstelling geïdentificeerd en de geneste lijst bevat een beschrijving van de beveiligingsinstelling, configuratie-instellingen die problemen kunnen veroorzaken, een beschrijving van waarom u de beveiligingsinstelling moet toepassen en een beschrijving van de redenen waarom u de beveiligingsinstelling mogelijk wilt verwijderen. De geneste lijst geeft vervolgens een symbolische naam voor de beveiligingsinstelling en het registerpad van de beveiligingsinstelling. Ten slotte worden er voorbeelden gegeven van compatibiliteitsproblemen die kunnen optreden wanneer de beveiligingsinstelling is geconfigureerd.
Controle: Sluit het systeem onmiddellijk af als beveiligingsaudits niet kunnen worden geregistreerd
Achtergrond
- De instelling Controle: systeem onmiddellijk afsluiten als beveiligingsaudits niet kunnen worden geregistreerd, bepaalt of het systeem wordt afgesloten als u beveiligingsgebeurtenissen niet kunt registreren. Deze instelling is vereist voor de C2-evaluatie van het TCSEC-programma (Trusted Computer Security Evaluation Criteria) en voor de Common Criteria for Information Technology Security Evaluation om controlebare gebeurtenissen te voorkomen als het controlesysteem deze gebeurtenissen niet kan vastleggen. Als het controlesysteem uitvalt, wordt het systeem afgesloten en wordt een stopfoutbericht weergegeven.
- Als de computer geen gebeurtenissen in het beveiligingslogboek kan vastleggen, is het mogelijk dat kritieke gegevens of belangrijke informatie voor probleemoplossing niet beschikbaar zijn voor beoordeling na een beveiligingsincident.
Riskante configuratie
Het volgende is een schadelijke configuratie-instelling: De instelling Controle: systeem onmiddellijk afsluiten als het logboek voor beveiligingsaudits niet kan worden geregistreerd, is ingeschakeld en de grootte van het gebeurtenislogboek wordt beperkt door de optie Gebeurtenissen niet overschrijven (logboek handmatig wissen), de optie Gebeurtenissen overschrijven indien nodig of de optie Overschrijven van gebeurtenissen ouder dan het aantal dagen in Logboeken. Zie de sectie 'Voorbeelden van compatibiliteitsproblemen' voor informatie over specifieke risico's voor computers met de oorspronkelijke uitgebrachte versie van Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 of Windows 2000 SP3.
Redenen om deze instelling in te schakelen
Als de computer geen gebeurtenissen in het beveiligingslogboek kan vastleggen, is het mogelijk dat kritieke gegevens of belangrijke informatie voor probleemoplossing niet beschikbaar zijn voor beoordeling na een beveiligingsincident.
Redenen om deze instelling uit te schakelen
- De audit inschakelen: Sluit het systeem onmiddellijk af als de instelling voor beveiligingsaudits niet kan worden geregistreerd, stopt het systeem als een beveiligingsaudit om welke reden dan ook niet kan worden geregistreerd. Een gebeurtenis kan meestal niet worden geregistreerd wanneer het beveiligingsauditlogboek vol is en wanneer de opgegeven bewaarmethode de optie Gebeurtenissen niet overschrijven (logboek handmatig wissen) of de optie Overschrijven gebeurtenissen ouder dan het aantal dagen is.
- De administratieve last van het inschakelen van de audit: sluit het systeem onmiddellijk af als de instelling voor beveiligingsaudits niet kan worden geregistreerd, kan erg hoog zijn, vooral als u ook de optie Gebeurtenissen niet overschrijven (logboek handmatig wissen) inschakelt voor het beveiligingslogboek. Deze instelling voorziet in individuele verantwoordelijkheid voor acties van operators. Een beheerder kan bijvoorbeeld machtigingen opnieuw instellen voor alle gebruikers, computers en groepen in een organisatie-eenheid (OU) waarvoor controle is ingeschakeld met behulp van het ingebouwde Administrator-account of een ander gedeeld account, en vervolgens weigeren dat ze dergelijke machtigingen opnieuw instellen. Het inschakelen van deze instelling vermindert echter de robuustheid van het systeem omdat een server mogelijk wordt afgesloten door deze te overspoelen met aanmeldingsgebeurtenissen en andere beveiligingsgebeurtenissen die naar het beveiligingslogboek worden geschreven. Omdat het afsluiten niet probleemloos verloopt, kan dit bovendien leiden tot onherstelbare schade aan het besturingssysteem, programma's of gegevens. Hoewel NTFS garandeert dat de integriteit van het bestandssysteem behouden blijft wanneer het systeem zonder problemen wordt afgesloten, kan niet worden gegarandeerd dat elk gegevensbestand voor elk programma nog steeds bruikbaar is wanneer het systeem opnieuw wordt opgestart.
Symbolische naam:
CrashOnAuditFail
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)Voorbeelden van compatibiliteitsproblemen
Windows 2000: Door een fout stoppen computers met de oorspronkelijke uitgebrachte versie van Windows 2000, Windows 2000 SP1, Windows 2000 SP2 of Windows Server SP3 met het registreren van gebeurtenissen voordat de grootte is bereikt die is opgegeven in de optie Maximale logboekgrootte voor het logboek voor beveiligingsgebeurtenissen. Deze fout is opgelost in Windows 2000 Service Pack 4 (SP4). Controleer of Windows 2000 Service Pack 4 is geïnstalleerd op uw Windows 2000-domeincontrollers voordat u deze instelling inschakelt.
Windows 2000, Windows Server 2003: Computers met Windows 2000 of Windows Server 2003 reageren mogelijk niet meer en starten vervolgens spontaan opnieuw op als de controle: Sluit het systeem onmiddellijk af als de instelling voor het logboek van de logboekregistratie niet kan worden ingeschakeld, het beveiligingslogboek vol is en een bestaande logboekvermelding niet kan worden overschreven. Wanneer de computer opnieuw wordt opgestart, wordt de volgende stopfout weergegeven:
Opmerking
STOP: C0000244 {Audit Failed}
Een poging om een beveiligingscontrole te genereren is mislukt.Om het bestand te herstellen moet een beheerder zich aanmelden, het beveiligingslogboek archiveren (optioneel), het beveiligingslogboek wissen en deze optie vervolgens opnieuw instellen (optioneel en indien nodig).
Microsoft-netwerkclient voor MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Niet-beheerders die zich bij een domein proberen aan te melden, krijgen de volgende foutmelding:
Opmerking
Uw account is zo geconfigureerd dat u deze computer niet kunt gebruiken. Probeer een andere computer.
Windows 2000: Op computers met Windows 2000 kunnen niet-beheerders zich niet aanmelden bij RAS-servers en wordt een foutbericht van de volgende strekking weergegeven:
Opmerking
Onbekende gebruiker of onjuist wachtwoord
Windows 2000: Op Windows 2000-domeincontrollers wordt de Intersite Messaging-service (Ismserv.exe) gestopt en kan deze niet opnieuw worden gestart. DCDIAG rapporteert de fout als 'mislukte testservices ISMserv' en gebeurtenis-id 1083 wordt geregistreerd in het gebeurtenislogboek.
Windows 2000: Op Windows 2000-domeincontrollers mislukt Active Directory-replicatie en verschijnt het bericht 'Toegang geweigerd' als het gebeurtenislogboek voor beveiliging vol is.
Microsoft Exchange 2000: Servers met Exchange 2000 kunnen de database voor het informatiearchief niet koppelen en gebeurtenis 2102 wordt geregistreerd in het gebeurtenislogboek.
Outlook, Outlook Web Access: niet-beheerders hebben geen toegang tot hun e-mail via Microsoft Outlook of Microsoft Outlook Web Access en krijgen een foutcode 503.
Domeincontroller: ondertekeningsvereisten voor LDAP-server
Achtergrond
De beveiligingsinstelling Domeincontroller: Vereisten voor LDAP-serverondertekening bepaalt of de LDAP-server (Lightweight Directory Access Protocol) vereist dat LDAP-clients onderhandelen over gegevensondertekening. De mogelijke waarden voor deze beleidsinstelling zijn:
- Geen: gegevensondertekening is niet vereist voor binding met de server. Als de client om ondertekening van gegevens vraagt, dan ondersteunt de server dit.
- Ondertekening vereisen: Over de optie voor LDAP-gegevensondertekening moet worden onderhandeld, tenzij Transport Layer Security/Secure Socket Layer (TLS/SSL) wordt gebruikt.
- niet gedefinieerd: deze instelling is niet in- of uitgeschakeld.
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- Ondertekening vereisen inschakelen in omgevingen waar clients geen ondersteuning bieden voor LDAP-ondertekening of waar LDAP-ondertekening aan clientzijde niet is ingeschakeld op de client
- De beveiligingssjabloon Hisecdc.inf voor Windows 2000 of Windows Server 2003 toepassen in omgevingen waar de clients geen ondersteuning bieden voor LDAP-ondertekening of waar LDAP-ondertekening aan clientzijde niet is ingeschakeld
- De beveiligingssjabloon Hisecws.inf voor Windows 2000 of Windows Server 2003 toepassen in omgevingen waar de clients geen ondersteuning bieden voor LDAP-ondertekening of waar LDAP-ondertekening aan clientzijde niet is ingeschakeld
Redenen om deze instelling in te schakelen
Niet-ondertekend netwerkverkeer is vatbaar voor man-in-the-middle-aanvallen waarbij een indringer pakketten vastlegt tussen de client en de server, de pakketten wijzigt en vervolgens doorstuurt naar de server. Wanneer dit gedrag optreedt op een LDAP-server, kan een aanvaller een server ertoe brengen beslissingen te nemen die zijn gebaseerd op onjuiste query's van de LDAP-client. U kunt dit risico in een bedrijfsnetwerk verlagen door krachtige fysieke beveiligingsmaatregelen te implementeren om de netwerkinfrastructuur te helpen beschermen. De headermodus van IPSec-authenticatie (Internet Protocol Security) kan man-in-the-middle-aanvallen helpen voorkomen. Verificatieheadermodus voert wederzijdse authenticatie en pakketintegriteit uit voor IP-verkeer.
Redenen om deze instelling uit te schakelen
- Clients die LDAP-ondertekening niet ondersteunen, kunnen geen LDAP-query's uitvoeren tegen domeincontrollers en globale catalogi als NTLM-verificatie is overeengekomen en als de juiste servicepacks niet zijn geïnstalleerd op Windows 2000-domeincontrollers.
- Netwerktraces van LDAP-verkeer tussen clients en servers worden versleuteld. Daardoor zijn LDAP-gesprekken moeilijk te onderzoeken.
- Op Windows 2000-servers moeten Windows 2000 Service Pack 3 (SP3) bevatten of geïnstalleerd zijn als ze worden beheerd in combinatie met programma's die LDAP-ondertekening ondersteunen en die worden uitgevoerd op clientcomputers met Windows 2000 SP4, Windows XP of Windows Server 2003.
Symbolische naam:
LDAPServerIntegrity
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)Voorbeelden van compatibiliteitsproblemen
Eenvoudig binden mislukt en u ontvangt het volgende foutbericht:
Opmerking
Ldap_simple_bind_s() mislukt: sterke verificatie vereist.
Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Op clients met Windows 2000 SP4, Windows XP of Windows Server 2003 werken sommige Active Directory-beheerprogramma's niet correct bij domeincontrollers met versies van Windows 2000 die ouder zijn dan SP3 wanneer NTLM-verificatie wordt onderhandeld.
Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Op clients met Windows 2000 SP4, Windows XP of Windows Server 2003 werken sommige Active Directory-beheerprogramma's die gericht zijn op domeincontrollers met versies van Windows 2000 die lager zijn dan SP3, niet correct als ze IP-adressen gebruiken (bijvoorbeeld "dsa.msc /server=x.x.x.x" waarbij
x.x.x.x is een IP-adres).Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Op clients met Windows 2000 SP4, Windows XP of Windows Server 2003 werken sommige Active Directory-beheerprogramma's die zijn gericht op domeincontrollers met versies van Windows 2000 ouder dan SP3 niet goed.
Domeinlid: Sterke sessiesleutel (Windows 2000 of hoger) vereisen
Achtergrond
- De instelling Sessiesleutel vereist voor domeinlid: vereist (Windows 2000 of hoger) bepaalt of een beveiligd kanaal tot stand kan worden gebracht met een domeincontroller die geen beveiligd kanaalverkeer kan versleutelen met een sterke 128-bits sessiesleutel. Door deze instelling in te schakelen, wordt voorkomen dat er een beveiligd kanaal tot stand wordt gebracht met een domeincontroller die beveiligde kanaalgegevens niet kan versleutelen met een sterke sleutel. Als u deze instelling uitschakelt, zijn 64-bits sessiesleutels toegestaan.
- Voordat u deze instelling kunt inschakelen op een werkstation voor een lid of op een server, moeten alle domeincontrollers in het domein waartoe het lid behoort, beveiligde kanaalgegevens kunnen versleutelen met een sterke 128-bits sleutel. Dit betekent dat op al deze domeincontrollers Windows 2000 of hoger moet worden uitgevoerd.
Riskante configuratie
Het domeinlid inschakelen: De instelling Sterke sessiesleutel vereisen (Windows 2000 of hoger) is een schadelijke configuratie-instelling.
Redenen om deze instelling in te schakelen
- Sessiesleutels die worden gebruikt om beveiligde communicatie tot stand te brengen tussen lidcomputers en domeincontrollers zijn veel sterker in Windows 2000 dan in eerdere versies van Microsoft-besturingssystemen.
- Indien mogelijk is het een goed idee om gebruik te maken van deze sterkere sessiesleutels om beveiligde kanaalcommunicatie te beschermen tegen afluisteren en sessiekaping, netwerkaanvallen. Afluisteren is een vorm van kwaadaardige aanval waarbij netwerkgegevens worden gelezen of tijdens het transport worden gewijzigd. De gegevens kunnen worden gewijzigd om de afzender te verbergen, te wijzigen of om ze om te leiden.
Belangrijk: een computer met Windows Server 2008 R2 of Windows 7 ondersteunt alleen sterke sleutels wanneer beveiligde kanalen worden gebruikt. Deze beperking voorkomt een vertrouwensrelatie tussen een op Windows NT 4.0 gebaseerd domein en een op Windows Server 2008 R2 gebaseerd domein. Bovendien blokkeert deze beperking het op Windows NT 4.0 gebaseerde domeinlidmaatschap van computers met Windows 7 of Windows Server 2008 R2, en omgekeerd.
Redenen om deze instelling uit te schakelen
Het domein bevat lidcomputers met een ander besturingssysteem dan Windows 2000, Windows XP of Windows Server 2003.
Symbolische naam:
StrongKey
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)Voorbeelden van compatibiliteitsproblemen
Windows NT 4.0: Op Windows NT 4.0-computers mislukt het resetten van beveiligde kanalen van vertrouwensrelaties tussen Windows NT 4.0- en Windows 2000-domeinen met NLTEST. Het foutbericht 'Toegang geweigerd' wordt weergegeven:
De vertrouwensrelatie tussen het primaire domein en het vertrouwde domein is mislukt.Windows 7 en Server 2008 R2: Voor Windows 7 en latere versies en Windows Server 2008 R2 en latere versies wordt deze instelling niet langer gebruikt en wordt de sterke toets altijd gebruikt. Hierdoor werken vertrouwensrelaties met Windows NT 4.0 domeinen niet meer.
Domeinlid: gegevens in Secure Channel digitaal versleutelen of ondertekenen (altijd)
Achtergrond
- Domeinlid inschakelen: Beveiligde kanaalgegevens digitaal versleutelen of ondertekenen (altijd) voorkomt dat er een beveiligd kanaal tot stand wordt gebracht met een domeincontroller die niet alle beveiligde kanaalgegevens kan ondertekenen of versleutelen. Ter bescherming van verificatieverkeer tegen man-in-the-middle-aanvallen, replay-aanvallen en andere soorten netwerkaanvallen, maken Windows-computers een communicatiekanaal dat bekend staat als een beveiligd kanaal via de Net Logon-service om computeraccounts te verifiëren. Beveiligde kanalen worden ook gebruikt wanneer een gebruiker in een domein verbinding maakt met een netwerkbron in een extern domein. Met deze multidomeinverificatie, of pass-through-verificatie, heeft een Windows-computer die lid is geworden van een domein, toegang tot de gebruikersaccountdatabase in het domein van het domein en in alle vertrouwde domeinen.
- Om de instelling Domeinlid in te schakelen: De instelling Beveiligde kanaalgegevens digitaal versleutelen of ondertekenen (altijd) Op de computer van een lid moeten alle domeincontrollers in het domein waartoe het lid behoort, alle gegevens in het beveiligde kanaal kunnen ondertekenen of versleutelen. Dit betekent dat op al deze domeincontrollers Windows NT 4.0 met Service Pack 6a (SP6a) of hoger moet worden uitgevoerd.
- Het domeinlid inschakelen: Gegevens digitaal versleutelen of ondertekenen (altijd) met de instelling Domeinlid: Gegevens in Secure Channel digitaal versleutelen of ondertekenen (indien mogelijk).
Riskante configuratie
Het domeinlid inschakelen: Beveiligd kanaalgegevens digitaal versleutelen of ondertekenen (altijd) instelling in domeinen waar niet alle domeincontrollers beveiligde kanaalgegevens kunnen ondertekenen of versleutelen, is een schadelijke configuratie-instelling.
Redenen om deze instelling in te schakelen
Niet-ondertekend netwerkverkeer is vatbaar voor man-in-the-middle-aanvallen, waarbij een indringer pakketten vastlegt tussen de server en de client en deze vervolgens wijzigt voordat deze worden doorgestuurd naar de client. Wanneer dit gedrag optreedt op een LDAP-server (Lightweight Directory Access Protocol), kan de indringer een client ertoe brengen beslissingen te nemen die zijn gebaseerd op onjuiste records uit de LDAP-adreslijst. U kunt het risico van een dergelijke aanval op een bedrijfsnetwerk verlagen door krachtige fysieke beveiligingsmaatregelen te implementeren om de netwerkinfrastructuur te helpen beschermen. Daarnaast kan de implementatie van de headermodus voor IPSec-authenticatie (Internet Protocol Security) man-in-the-middle-aanvallen helpen voorkomen. In deze modus wordt wederzijdse verificatie en pakketintegriteit uitgevoerd voor IP-verkeer.
Redenen om deze instelling uit te schakelen
- Computers in lokale of externe domeinen ondersteunen versleutelde beveiligde kanalen.
- Niet alle domeincontrollers in het domein hebben de juiste revisieniveaus voor servicepacks ter ondersteuning van versleutelde, beveiligde kanalen.
Symbolische naam:
StrongKey
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)Voorbeelden van compatibiliteitsproblemen
Windows NT 4.0: Op Windows 2000 gebaseerde lidcomputers kunnen geen Windows NT 4.0-domeinen koppelen en het volgende foutbericht wordt weergegeven:
Opmerking
Het account is niet geautoriseerd om in te loggen vanaf dit station.
Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie:
281648 Foutbericht: Het account is niet geautoriseerd om in te loggen vanaf dit station
Windows NT 4.0: Windows NT 4.0-domeinen kunnen geen vertrouwensrelatie op een lager niveau tot stand brengen met een Windows 2000-domein en ontvangen het volgende foutbericht:
Opmerking
Het account is niet geautoriseerd om in te loggen vanaf dit station.
Bestaande vertrouwensrelaties op een lager niveau verifiëren mogelijk ook geen gebruikers van het vertrouwde domein. Sommige gebruikers ondervinden mogelijk problemen bij het aanmelden bij het domein en krijgen mogelijk een foutbericht waarin staat dat de client het domein niet kan vinden.
Windows XP: Windows XP-clients die zijn toegevoegd aan Windows NT 4.0-domeinen kunnen geen aanmeldingspogingen verifiëren en ontvangen mogelijk het volgende foutbericht, of de volgende gebeurtenissen kunnen worden geregistreerd in het gebeurtenislogboek:
Opmerking
Windows kan geen verbinding maken met het domein omdat de domeincontroller niet beschikbaar is of anderszins niet beschikbaar is, of omdat uw computeraccount niet is gevonden
Microsoft-netwerk: voor Microsoft-netwerkclients wordt een van de volgende foutberichten weergegeven:
Opmerking
Aanmeldingsfout: onbekende gebruikersnaam of onjuist wachtwoord.
Opmerking
Er is geen gebruikerssessiesleutel voor de opgegeven aanmeldingssessie.
Microsoft-netwerkclient: Communicatie digitaal ondertekenen (altijd)
Achtergrond
Server Message Block (SMB) is het protocol voor het delen van bronnen dat door veel Microsoft-besturingssystemen wordt ondersteund. Het is de basis van het netwerk basic input/output system (NetBIOS) en van vele andere protocollen. SMB-ondertekening authenticeert zowel de gebruiker als de server die de gegevens host. Als een van beide partijen niet door het verificatieproces komt, vindt er geen gegevensoverdracht plaats.
Het inschakelen van SMB-ondertekening begint tijdens de SMB-protocolonderhandelingen. Het ondertekeningsbeleid voor SMB bepaalt of clientcommunicatie op de computer altijd digitaal wordt ondertekend.
Het SMB-verificatieprotocol Windows 2000 ondersteunt wederzijdse verificatie. Wederzijdse authenticatie sluit een "man-in-the-middle"-aanval af. Het Windows 2000 SMB-verificatieprotocol ondersteunt ook berichtverificatie. Berichtverificatie helpt aanvallen met actieve berichten te voorkomen. Om u deze verificatie te geven, plaatst SMB-ondertekening een digitale handtekening in elke SMB. De client en de server controleren elk de digitale handtekening.
Als u SMB-ondertekening wilt gebruiken, moet u SMB-ondertekening inschakelen of SMB-ondertekening vereisen op zowel de SMB-client als de SMB-server. Als SMB-ondertekening is ingeschakeld op een server, gebruiken clients die ook SMB-ondertekening gebruiken het protocol voor pakketondertekening tijdens alle volgende sessies. Als SMB-ondertekening is vereist op een server, kan een client alleen een sessie tot stand brengen als de client is ingeschakeld of vereist voor SMB-ondertekening.
Door digitale ondertekening in streng beveiligde netwerken in te schakelen, wordt de imitatie van clients en servers voorkomen. Dit soort imitatie staat bekend als sessiekaping. Een aanvaller die toegang heeft tot hetzelfde netwerk als de client of de server, gebruikt hulpprogramma's voor sessiekaping om een actieve sessie te onderbreken, te beëindigen of te stelen. Een aanvaller kan niet-ondertekende SMB-pakketten onderscheppen en wijzigen, het verkeer wijzigen en vervolgens doorsturen zodat de server mogelijk ongewenste acties uitvoert. Of de aanvaller kan zich voordoen als de server of als de client na een legitieme verificatie en vervolgens ongeoorloofde toegang krijgen tot de gegevens.
Het SMB-protocol dat wordt gebruikt voor het delen van bestanden en voor het delen van printers op computers met Windows 2000 Server, Windows 2000 Professional, Windows XP Professional of Windows Server 2003 ondersteunt wederzijdse verificatie. Wederzijdse authenticatie sluit sessiekapingsaanvallen en ondersteunt berichtauthenticatie. Daarom voorkomt het man-in-the-middle-aanvallen. SMB-ondertekening biedt deze authenticatie door een digitale handtekening in elk SMB te plaatsen. De client en de server controleren vervolgens de handtekening.
Notities
Als alternatieve tegenmaatregel kunt u digitale handtekeningen met IPSec inschakelen om al het netwerkverkeer te helpen beschermen. Er zijn hardwareversnellers voor IPSec-versleuteling en -ondertekening die u kunt gebruiken om de invloed van de CPU op de prestaties te minimaliseren. Er zijn geen dergelijke accelerators die beschikbaar zijn voor SMB-ondertekening.
Zie voor meer informatie het hoofdstuk Communicatie met servers digitaal ondertekenen op de Microsoft MSDN-website.
SMB-ondertekening configureren via de objecteditor voor groepsbeleid omdat een wijziging in een lokale registerwaarde geen effect heeft als er een doorslaggevend domeinbeleid is.
In Windows 95, Windows 98 en Windows 98 Tweede editie gebruikt de Directory Services Client SMB-ondertekening wanneer deze wordt geverifieerd met Windows Server 2003-servers door middel van NTLM-verificatie. Deze clients gebruiken echter geen SMB-ondertekening wanneer ze met deze servers worden geverifieerd met behulp van NTLMv2-verificatie. Bovendien reageren Windows 2000-servers niet op SMB-ondertekeningsaanvragen van deze clients. Zie voor meer informatie item 10: "Netwerkbeveiliging: Lan Manager-verificatieniveau."
Riskante configuratie
Het volgende is een schadelijke configuratie-instelling: Bij het verlaten van zowel de Microsoft-netwerkclient: De instelling Communicatie digitaal ondertekenen (altijd) en de Microsoft-netwerkclient: De instelling Communicatie digitaal ondertekenen (als de server daarmee akkoord gaat) ingesteld op Niet gedefinieerd of uitgeschakeld. Met deze instellingen kan de redirector wachtwoorden in tekst zonder opmaak verzenden naar niet-Microsoft SMB-servers die geen ondersteuning bieden voor wachtwoordversleuteling tijdens verificatie.
Redenen om deze instelling in te schakelen
Microsoft-netwerkclient inschakelen: Digitaal ondertekenen van communicatie (altijd) vereist dat clients SMB-verkeer ondertekenen wanneer contact wordt gemaakt met servers waarvoor geen SMB-ondertekening is vereist. Dit maakt clients minder kwetsbaar voor sessiekapingsaanvallen.
Redenen om deze instelling uit te schakelen
- Microsoft-netwerkclient inschakelen: Communicatie digitaal ondertekenen voorkomt (altijd) dat clients communiceren met doelservers die SMB-ondertekening niet ondersteunen.
- Door computers zo te configureren dat alle niet-ondertekende SMB-communicatie wordt genegeerd, voorkomt u dat oudere programma's en besturingssystemen verbinding kunnen maken.
Symbolische naam:
RequireSMBSignRdr
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignatureVoorbeelden van compatibiliteitsproblemen
Windows NT 4.0: U kunt het beveiligde kanaal van een vertrouwensrelatie tussen een Windows Server 2003-domein en een Windows NT 4.0-domein niet opnieuw instellen door NLTEST of NETDOM te gebruiken, en u ontvangt een foutmelding "Toegang geweigerd".
Windows XP: Het kopiëren van bestanden van Windows XP-clients naar Windows 2000- en Windows Server 2003-servers kan langer duren.
U kunt geen netwerkstation toewijzen vanaf een client met deze instelling ingeschakeld en u ontvangt het volgende foutbericht:
Opmerking
Het account is niet geautoriseerd om in te loggen vanaf dit station.
Vereisten voor opnieuw opstarten
Start de computer opnieuw op of start de Workstation-service opnieuw. Typ hiervoor de volgende opdrachten in een opdrachtprompt. Druk na elke opdracht op Enter.
net stop werkstation
net start werkstation
Microsoft-netwerkserver: communicatie digitaal ondertekenen (altijd)
Achtergrond
Server Messenger Block (SMB) is het protocol voor het delen van bronnen dat door veel Microsoft-besturingssystemen wordt ondersteund. Het is de basis van het netwerk basic input/output system (NetBIOS) en van vele andere protocollen. SMB-ondertekening authenticeert zowel de gebruiker als de server die de gegevens host. Als een van beide partijen niet door het verificatieproces komt, vindt er geen gegevensoverdracht plaats.
Het inschakelen van SMB-ondertekening begint tijdens de SMB-protocolonderhandelingen. Het ondertekeningsbeleid voor SMB bepaalt of clientcommunicatie op de computer altijd digitaal wordt ondertekend.
Het SMB-verificatieprotocol Windows 2000 ondersteunt wederzijdse verificatie. Wederzijdse authenticatie sluit een "man-in-the-middle"-aanval af. Het Windows 2000 SMB-verificatieprotocol ondersteunt ook berichtverificatie. Berichtverificatie helpt aanvallen met actieve berichten te voorkomen. Om u deze verificatie te geven, plaatst SMB-ondertekening een digitale handtekening in elke SMB. De client en de server controleren elk de digitale handtekening.
Als u SMB-ondertekening wilt gebruiken, moet u SMB-ondertekening inschakelen of SMB-ondertekening vereisen op zowel de SMB-client als de SMB-server. Als SMB-ondertekening is ingeschakeld op een server, gebruiken clients die ook SMB-ondertekening gebruiken het protocol voor pakketondertekening tijdens alle volgende sessies. Als SMB-ondertekening is vereist op een server, kan een client alleen een sessie tot stand brengen als de client is ingeschakeld of vereist voor SMB-ondertekening.
Door digitale ondertekening in streng beveiligde netwerken in te schakelen, wordt de imitatie van clients en servers voorkomen. Dit soort imitatie staat bekend als sessiekaping. Een aanvaller die toegang heeft tot hetzelfde netwerk als de client of de server, gebruikt hulpprogramma's voor sessiekaping om een actieve sessie te onderbreken, te beëindigen of te stelen. Een aanvaller kan niet-ondertekende SBM-pakketten (Subnet Bandwidth Manager) onderscheppen en wijzigen, het verkeer wijzigen en vervolgens doorsturen zodat de server mogelijk ongewenste acties uitvoert. Of de aanvaller kan zich voordoen als de server of als de client na een legitieme verificatie en vervolgens ongeoorloofde toegang krijgen tot de gegevens.
Het SMB-protocol dat wordt gebruikt voor het delen van bestanden en voor het delen van printers op computers met Windows 2000 Server, Windows 2000 Professional, Windows XP Professional of Windows Server 2003 ondersteunt wederzijdse verificatie. Wederzijdse authenticatie sluit sessiekapingsaanvallen en ondersteunt berichtauthenticatie. Daarom voorkomt het man-in-the-middle-aanvallen. SMB-ondertekening biedt deze authenticatie door een digitale handtekening in elk SMB te plaatsen. De client en de server controleren vervolgens de handtekening.
Als alternatieve tegenmaatregel kunt u digitale handtekeningen met IPSec inschakelen om al het netwerkverkeer te helpen beschermen. Er zijn hardwareversnellers voor IPSec-versleuteling en -ondertekening die u kunt gebruiken om de invloed van de CPU op de prestaties te minimaliseren. Er zijn geen dergelijke accelerators die beschikbaar zijn voor SMB-ondertekening.
In Windows 95, Windows 98 en Windows 98 Tweede editie gebruikt de Directory Services Client SMB-ondertekening wanneer deze wordt geverifieerd met Windows Server 2003-servers door middel van NTLM-verificatie. Deze clients gebruiken echter geen SMB-ondertekening wanneer ze met deze servers worden geverifieerd met behulp van NTLMv2-verificatie. Bovendien reageren Windows 2000-servers niet op SMB-ondertekeningsaanvragen van deze clients. Zie voor meer informatie item 10: "Netwerkbeveiliging: Lan Manager-verificatieniveau."
Riskante configuratie
Het volgende is een schadelijke configuratie-instelling: De Microsoft-netwerkserver inschakelen: De instelling Communicatie digitaal ondertekenen (altijd) op servers en domeincontrollers die toegankelijk zijn voor incompatibele Windows-computers en op het besturingssysteem van derden gebaseerde clientcomputers in lokale of externe domeinen.
Redenen om deze instelling in te schakelen
- Alle clientcomputers waarop deze instelling rechtstreeks via het register of de instelling voor het groepsbeleid wordt ingeschakeld, ondersteunen SMB-ondertekening. Met andere woorden: alle clientcomputers waarop deze instelling is ingeschakeld, draaien ofwel Windows 95 met de DS-client geïnstalleerd, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional of Windows Server 2003.
- Als Microsoft-netwerkserver: Communicatie digitaal ondertekenen (altijd) is uitgeschakeld, is SMB-ondertekening volledig uitgeschakeld. Door alle SMB-ondertekening volledig uit te schakelen, zijn computers kwetsbaarder voor aanvallen met sessiekapingen.
Redenen om deze instelling uit te schakelen
- Als u deze instelling inschakelt, kan dit leiden tot tragere bestandskopieën en netwerkprestaties op clientcomputers.
- Door deze instelling in te schakelen wordt voorkomen dat clients die niet kunnen onderhandelen over SMB-ondertekening communiceren met servers en domeincontrollers. Hierdoor mislukken bewerkingen zoals domeinjoins, gebruikers- en computerverificatie of netwerktoegang door programma's.
Symbolische naam:
RequireSMBSignServer
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)Voorbeelden van compatibiliteitsproblemen
Windows 95: Voor Windows 95-clients waarop de DS-client (Directory Services) niet is geïnstalleerd, mislukt de aanmeldingsverificatie en wordt het volgende foutbericht weergegeven:
Opmerking
Het opgegeven domeinwachtwoord is onjuist of toegang tot de aanmeldingsserver is geweigerd.
Windows NT 4.0: Op clientcomputers met versies van Windows NT 4.0 die lager zijn dan Service Pack 3 (SP3) wordt de aanmeldingsverificatie mislukt en wordt het volgende foutbericht weergegeven:
Opmerking
U kunt zich niet aanmelden via het systeem. Controleer of uw gebruikersnaam en domein juist zijn en typ vervolgens uw wachtwoord opnieuw.
Sommige niet-Microsoft-SMB-servers ondersteunen alleen niet-versleutelde wachtwoorduitwisseling tijdens verificatie. (Deze uitwisselingen worden ook wel "platte tekst"-uitwisselingen genoemd.) Voor Windows NT 4.0 SP3 en latere versies stuurt de SMB-redirector geen niet-versleuteld wachtwoord tijdens verificatie naar een SMB-server, tenzij u een specifieke registervermelding toevoegt.
Als u niet-versleutelde wachtwoorden wilt inschakelen voor de SMB-client op systemen met Windows NT 4.0 SP 3 en nieuwere systemen, wijzigt u het register als volgt: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\ParametersWaardenaam: EnablePlainTextPassword
Gegevenstype: REG_DWORD
Gegevens: 1
Windows Server 2003: Beveiligingsinstellingen op domeincontrollers met Windows Server 2003 zijn standaard zo geconfigureerd dat wordt voorkomen dat communicatie van domeincontrollers wordt onderschept of gemanipuleerd door kwaadwillende gebruikers. Om succesvol te kunnen communiceren met een domeincontroller waarop Windows Server 2003 wordt uitgevoerd, moeten clientcomputers zowel SMB-ondertekening als versleuteling gebruiken of verkeersondertekening via Secure Channel. Clients waarop Windows NT 4.0 met Service Pack 2 (SP2) of eerder is geïnstalleerd en clients waarop Windows 95 wordt uitgevoerd, hebben standaard geen SMB-pakketondertekening ingeschakeld. Daarom kunnen deze clients mogelijk niet worden geverifieerd bij een domeincontroller op basis van Windows Server 2003.
Beleidsinstellingen voor Windows 2000 en Windows Server 2003: Afhankelijk van uw specifieke installatiebehoeften en configuratie, raden we u aan de volgende beleidsinstellingen in te stellen op de laagste entiteit van het vereiste bereik in de module-hiërarchie van de groepsbeleid-editor voor Microsoft Management Console:
- Computer Configuration\Windows-beveiliging Settings\Security Options
- Verzend een niet-versleuteld wachtwoord om verbinding te maken met SMB-servers van derden (deze instelling is bedoeld voor Windows 2000)
- Microsoft-netwerkclient: stuur een niet-versleuteld wachtwoord naar SMB-servers van derden (deze instelling is bedoeld voor Windows Server 2003)
Opmerking In sommige CIFS-servers van derden, zoals oudere Samba-versies, kunt u geen versleutelde wachtwoorden gebruiken.
De volgende clients zijn niet compatibel met de Microsoft-netwerkserver: Instelling voor digitaal ondertekenen van communicatie (altijd):
- Apple Computer, Inc., Mac OS X-clients
- Microsoft MS-DOS-netwerkclients (bijvoorbeeld Microsoft LAN Manager)
- Microsoft Windows voor werkgroepen-clients
- Microsoft Windows 95-clients zonder de DS-client geïnstalleerd
- Microsoft Windows NT 4.0-computers zonder SP3 of hoger geïnstalleerd
- Novell Netware 6 CIFS-clients
- SAMBA MKB-clients die geen ondersteuning hebben voor SMB-ondertekening
Vereisten voor opnieuw opstarten
Start de computer opnieuw op of start de Server-service opnieuw. Typ hiervoor de volgende opdrachten in een opdrachtprompt. Druk na elke opdracht op Enter.
net stop server
net start server
Netwerktoegang: anonieme SID-/naamomzetting toestaan
Achtergrond
De beveiligingsinstelling Netwerktoegang: anonieme SID-/naamvertaling toestaan bepaalt of een anonieme gebruiker SID-kenmerken (Security Identification Number) kan aanvragen voor een andere gebruiker.
Riskante configuratie
De netwerktoegang inschakelen: anonieme SID-/naamomzettingsinstelling toestaan is een schadelijke configuratie-instelling.
Redenen om deze instelling in te schakelen
Als de instelling Netwerktoegang: Anonieme SID-/naamvertaling toestaan is uitgeschakeld, kunnen oudere besturingssystemen of toepassingen mogelijk niet communiceren met domeinen van Windows Server 2003. De volgende besturingssystemen, services of toepassingen werken bijvoorbeeld mogelijk niet:
- Op Windows NT 4.0 gebaseerde Remote Access Service-servers
- Microsoft SQL Server die draaien op Windows NT 3.x- of Windows NT 4.0-computers
- RAS-service die draait op Windows 2000-computers die zich bevinden in Windows NT 3.x- of Windows NT 4.0-domeinen
- SQL Server die wordt uitgevoerd op Windows 2000-computers die zich bevinden in Windows NT 3.x-domeinen of in Windows NT 4.0-domeinen
- Gebruikers in het Windows NT 4.0-brondomein die machtigingen voor toegang tot bestanden, gedeelde mappen en registerobjecten willen verlenen aan gebruikersaccounts van accountdomeinen met domeincontrollers met Windows Server 2003
Redenen om deze instelling uit te schakelen
Als deze instelling is ingeschakeld, kan een kwaadwillende gebruiker de bekende Administrators-SID gebruiken om de echte naam van het ingebouwde Administrator-account te verkrijgen, zelfs als de naam van het account is gewijzigd. Die persoon zou vervolgens de accountnaam kunnen gebruiken om een wachtwoord-raadaanval te starten.
Symbolische naam: N.v.t.
Registerpad: Geen. Het pad wordt opgegeven in UI-code.
Voorbeelden van compatibiliteitsproblemen
Windows NT 4.0: Computers in Windows NT 4.0-brondomeinen geven het foutbericht 'Account onbekend' weer in ACL-editor als resources, waaronder gedeelde mappen, gedeelde bestanden en registerobjecten, zijn beveiligd met beveiligingsprincipals die zich bevinden in accountdomeinen die Windows Server 2003-domeincontrollers bevatten.
Netwerktoegang: anonieme inventarisatie van SAM-accounts niet toestaan
Achtergrond
Met de instelling Netwerktoegang: anonieme inventarisatie van SAM-accounts niet toestaan wordt bepaald welke extra machtigingen worden verleend voor anonieme verbindingen met de computer. In Windows kunnen anonieme gebruikers bepaalde activiteiten uitvoeren, zoals het opsommen van de namen van SAM-accounts (Security Accounts Manager) van werkstations en servers. Een beheerder kan dit bijvoorbeeld gebruiken om toegang te verlenen aan gebruikers in een vertrouwd domein dat geen wederzijds vertrouwen onderhoudt. Zodra een sessie is gemaakt, kan een anonieme gebruiker dezelfde toegang krijgen die wordt verleend aan de groep Iedereen op basis van de instelling in de instelling Netwerktoegang: Laat iedereen-machtigingen van toepassing zijn op anonieme gebruikers of de discretionaire toegangsbeheerlijst (DACL) van het object.
Anonieme verbindingen worden meestal gevraagd door eerdere versies van clients (clients met een lager niveau) tijdens het instellen van SMB-sessies. In deze gevallen laat een netwerktracering zien dat de SMB-proces-id (PID) de client-redirector is, zoals 0xFEFF in Windows 2000 of 0xCAFE in Windows NT. RPC probeert mogelijk ook anonieme verbindingen tot stand te brengen.
Belangrijk: Deze instelling heeft geen invloed op domeincontrollers. Op domeincontrollers wordt dit gedrag bepaald door de aanwezigheid van 'NT AUTHORITY\ANONYMOUS LOGON' in 'Toegang compatibel met vóór Windows 2000'.
In Windows 2000 wordt de registerwaarde RestrictAnonymous beheerd door een vergelijkbare instelling met de naam Aanvullende beperkingen voor anonieme verbindingen. De locatie van deze waarde is als volgt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Riskante configuraties
De netwerktoegang inschakelen: anonieme inventarisatie van SAM-accounts niet toestaan De instelling is een configuratie-instelling die schadelijk is vanuit het oogpunt van compatibiliteit. Het uitschakelen ervan is een schadelijke configuratie-instelling vanuit een beveiligingsperspectief.
Redenen om deze instelling in te schakelen
Een niet-geautoriseerde gebruiker kan anoniem accountnamen weergeven en de informatie vervolgens gebruiken om wachtwoorden te raden of social engineering-aanvallen uit te voeren. Social engineering is jargon, wat betekent dat mensen worden misleid om hun wachtwoorden of een of andere vorm van beveiligingsinformatie te onthullen.
Redenen om deze instelling uit te schakelen
Als deze instelling is ingeschakeld, is het onmogelijk om vertrouwensrelaties tot stand te brengen met Windows NT 4.0-domeinen. Deze instelling veroorzaakt ook problemen met clients van een lager niveau (zoals Windows NT 3.51-clients en Windows 95-clients) die bronnen op de server proberen te gebruiken.
Symbolische naam:
RestrictAnonymousSAM
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)Voorbeelden van compatibiliteitsproblemen
- SMS Network Discovery kan geen informatie over het besturingssysteem verkrijgen en schrijft 'Unknown' in de eigenschap OperatingSystemNameandVersion.
- Windows 95, Windows 98: Windows 95-clients en Windows 98-clients kunnen hun wachtwoorden niet wijzigen.
- Windows NT 4.0: Op Windows NT 4.0 gebaseerde lidcomputers kunnen niet worden geverifieerd.
- Windows 95, Windows 98: Windows 95- en Windows 98-computers kunnen niet worden geverifieerd door Microsoft-domeincontrollers.
- Windows 95, Windows 98: Gebruikers van Windows 95- en Windows 98-computers kunnen de wachtwoorden voor hun gebruikersaccounts niet wijzigen.
Netwerktoegang: anonieme inventarisatie van SAM-accounts en -shares niet toestaan
Achtergrond
- Met de instelling Netwerktoegang: anonieme inventarisatie van SAM-accounts en -shares niet toestaan (ook wel RestrictAnonymous genoemd) wordt bepaald of anonieme inventarisatie van SAM-accounts (Security Accounts Manager) is toegestaan. In Windows kunnen anonieme gebruikers bepaalde activiteiten uitvoeren, zoals het opsommen van de namen van domeinaccounts (gebruikers, computers en groepen) en van netwerkshares. Dit is bijvoorbeeld handig als een beheerder toegang wil verlenen aan gebruikers in een vertrouwd domein dat geen wederzijds vertrouwen onderhoudt. Schakel deze instelling in als u anonieme inventarisatie van SAM-accounts en shares niet wilt toestaan.
- In Windows 2000 wordt de registerwaarde RestrictAnonymous beheerd door een vergelijkbare instelling met de naam Aanvullende beperkingen voor anonieme verbindingen. De locatie van deze waarde is als volgt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
Riskante configuratie
De netwerktoegang inschakelen: anonieme inventarisatie van SAM-accounts en -delen niet toestaan De instelling is een schadelijke configuratie-instelling.
Redenen om deze instelling in te schakelen
- Netwerktoegang inschakelen: anonieme inventarisatie van SAM-accounts en -shares niet toestaan Instelling voorkomt dat gebruikers en computers die anonieme accounts gebruiken, worden geïnventariseerd.
Redenen om deze instelling uit te schakelen
- Als deze instelling is ingeschakeld, kan een niet-geautoriseerde gebruiker anoniem accountnamen weergeven en de informatie vervolgens gebruiken om wachtwoorden te raden of social engineering-aanvallen uit te voeren. Social engineering is jargon, wat betekent dat mensen worden misleid om hun wachtwoord of een of andere vorm van beveiligingsinformatie te onthullen.
- Als deze instelling is ingeschakeld, is het onmogelijk om vertrouwensrelaties tot stand te brengen met Windows NT 4.0-domeinen. Deze instelling veroorzaakt ook problemen met clients van een lager niveau zoals Windows NT 3.51- en Windows 95-clients die bronnen op de server proberen te gebruiken.
- Het is dan onmogelijk om toegang te verlenen aan gebruikers van brondomeinen, omdat beheerders in het vertrouwende domein geen lijsten met accounts in het andere domein kunnen opsommen. Gebruikers die anoniem toegang hebben tot bestands- en afdrukservers, kunnen de gedeelde netwerkbronnen op die servers niet weergeven. Gebruikers moeten worden geverifieerd voordat ze de lijsten met gedeelde mappen en printers kunnen weergeven.
Symbolische naam:
RestrictAnonymous
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousVoorbeelden van compatibiliteitsproblemen
Windows NT 4.0: Gebruikers kunnen hun wachtwoorden van Windows NT 4.0-werkstations niet wijzigen wanneer RestrictAnonymous is ingeschakeld op domeincontrollers in het domein van de gebruiker.
Windows NT 4.0: Gebruikers of globale groepen van vertrouwde Windows 2000-domeinen toevoegen aan lokale Windows NT 4.0-groepen in Gebruikersbeheer mislukt en het volgende foutbericht verschijnt:
Opmerking
Er zijn momenteel geen aanmeldingsservers beschikbaar om de aanmeldingsaanvraag te verwerken.
Windows NT 4.0: Op Windows NT 4.0-computers kunnen geen domeinen koppelen tijdens de installatie of met behulp van de gebruikersinterface voor domeindeelname.
Windows NT 4.0: Het instellen van een vertrouwensrelatie op een lager niveau met Windows NT 4.0-brondomeinen mislukt. Het volgende foutbericht wordt weergegeven wanneer RestrictAnonymous is ingeschakeld voor het vertrouwde domein:
Opmerking
Kan domeincontroller voor dit domein niet vinden.
Windows NT 4.0: Gebruikers die zich aanmelden bij Terminal Server-computers met Windows NT 4.0 worden toegewezen aan de standaard basismap in plaats van aan de basismap die is gedefinieerd in Gebruikersbeheer voor domeinen.
Windows NT 4.0: Windows NT 4.0-back-updomeincontrollers (BDC's) kunnen de Net Logon-service niet starten, geen lijst met back-upbrowsers ophalen of de SAM-database synchroniseren van Windows 2000 of van Windows Server 2003-domeincontrollers in hetzelfde domein.
Windows 2000: Op Windows 2000-lidcomputers in Windows NT 4.0-domeinen kunnen geen printers in externe domeinen weergeven als de instelling Geen toegang zonder expliciet anonieme machtigingen is ingeschakeld in het lokale beveiligingsbeleid van de clientcomputer.
Windows 2000: Windows 2000-domeingebruikers kunnen geen netwerkprinters toevoegen vanuit Active Directory. Ze kunnen echter wel printers toevoegen nadat ze die in de structuurweergave hebben geselecteerd.
Windows 2000: Op computers met Windows 2000 kan ACL Editor geen gebruikers of globale groepen uit vertrouwde Windows NT 4.0-domeinen toevoegen.
ADMT versie 2: Wachtwoordmigratie voor gebruikersaccounts die worden gemigreerd tussen forests met Active Directory Migration Tool (ADMT) versie 2 mislukt.
Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie:
322981 Problemen oplossen met wachtwoordmigratie tussen forests met ADMTv2Outlook-clients: de algemene adreslijst wordt leeg weergegeven voor Microsoft Exchange Outlook-clients.
SMS: Microsoft Systems Management Server (SMS) Network Discovery kan de informatie over het besturingssysteem niet verkrijgen. Daarom wordt 'Unknown' geschreven in de eigenschap OperatingSystemNameandVersion van de SMS DDR-eigenschap van de Discovery Data Record (DDR).
SMS: Wanneer u de gebruikerswizard Sms-beheer gebruikt om naar gebruikers en groepen te zoeken, worden er geen gebruikers of groepen weergegeven. Bovendien kunnen Advanced-clients niet communiceren met het Management Point. Anonieme toegang is vereist op het Management Point.
SMS: wanneer u de functie Netwerkdetectie gebruikt in SMS 2.0 en in Installatie op afstand van clients met de netwerkdetectieoptie Topologie, client en besturingssystemen van de client ingeschakeld, kunnen computers worden gevonden, maar niet worden geïnstalleerd.
Netwerkbeveiliging: Lan Manager-authenticatieniveau
Achtergrond
LAN Manager-verificatie (LM) is het protocol dat wordt gebruikt voor de verificatie van Windows-clients voor netwerkbewerkingen, waaronder domeinjoins, toegang tot netwerkbronnen en gebruikers- of computerverificatie. Het LM-verificatieniveau bepaalt over welk challenge/response-verificatieprotocol wordt onderhandeld tussen de client en de servercomputers. Het LM-verificatieniveau bepaalt met name welke verificatieprotocollen de client probeert te onderhandelen of die de server accepteert. De waarde die is ingesteld voor LmCompatibilityLevel bepaalt welk protocol voor challenge/response-verificatie wordt gebruikt voor netwerkaanmeldingen. Deze waarde beïnvloedt het niveau van het verificatieprotocol dat clients gebruiken, het niveau van sessiebeveiliging waarover is onderhandeld en het verificatieniveau dat door servers wordt geaccepteerd.
Instellingen zijn mogelijk:
Value Instelling Beschrijving 0 LM & NTLM-antwoorden verzenden Clients gebruiken LM- en NTLM-authenticatie en gebruiken nooit NTLMv2-sessiebeveiliging. Domeincontrollers accepteren LM-, NTLM- en NTLMv2-verificatie. 1 Stuur LM & NTLM - gebruik NTLMv2-sessiebeveiliging als hierover is onderhandeld Clients gebruiken LM- en NTLM-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt. Domeincontrollers accepteren LM-, NTLM- en NTLMv2-verificatie. 2 Alleen NTLM-antwoord verzenden Clients gebruiken alleen NTLM-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt. Domeincontrollers accepteren LM-, NTLM- en NTLMv2-verificatie. 3 Alleen NTLMv2-antwoord verzenden Clients gebruiken alleen NTLMv2-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt. Domeincontrollers accepteren LM-, NTLM- en NTLMv2-verificatie. 4 Alleen NTLMv2-antwoord verzenden/LM weigeren Clients gebruiken alleen NTLMv2-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt. Domeincontrollers weigeren LM en accepteren alleen NTLM- en NTLMv2-verificatie. 5 Alleen NTLMv2-antwoord verzenden/LM weigeren & NTLM Clients gebruiken alleen NTLMv2-verificatie en gebruiken NTLMv2-sessiebeveiliging als de server dit ondersteunt. Domeincontrollers weigeren LM en NTLM en accepteren alleen NTLMv2-verificatie. Opmerking In Windows 95, Windows 98 en Windows 98 Tweede editie gebruikt de Directory Services Client SMB-ondertekening wanneer deze wordt geverifieerd met Windows Server 2003-servers door middel van NTLM-verificatie. Deze clients gebruiken echter geen SMB-ondertekening wanneer ze met deze servers worden geverifieerd met behulp van NTLMv2-verificatie. Bovendien reageren Windows 2000-servers niet op SMB-ondertekeningsaanvragen van deze clients.
Controleer het LM-verificatieniveau: u moet het beleid op de server wijzigen om NTLM toe te staan, of u moet de clientcomputer configureren om NTLMv2 te ondersteunen.
Als het beleid is ingesteld op (5) Alleen NTLMv2-antwoord verzenden\weigeren LM & NTLM op de doelcomputer waarmee u verbinding wilt maken, moet u de instelling op die computer verlagen of de beveiliging instellen op dezelfde instelling als op de broncomputer vanwaar u verbinding maakt.
Zoek de juiste locatie waar u het verificatieniveau van LAN-beheer kunt wijzigen om de client en de server op hetzelfde niveau in te stellen. Nadat u het beleid hebt gevonden waarmee het verificatieniveau van LAN-beheer wordt ingesteld, verlaagt u de waarde tot ten minste (1) LM verzenden & NTLM - gebruik NTLM versie 2-sessiebeveiliging indien onderhandeld. Een effect van incompatibele instellingen is dat als NTLMv2 (waarde 5) vereist is voor de server, maar de client is geconfigureerd voor alleen LM en NTLMv1 (waarde 0), de gebruiker die verificatie probeert uit te voeren, een aanmeldingsfout ondervindt met een onjuist wachtwoord en waardoor het aantal onjuiste wachtwoorden toeneemt. Als accountvergrendeling is geconfigureerd, kan de gebruiker uiteindelijk worden vergrendeld.
Het is bijvoorbeeld mogelijk dat u de domeincontroller moet doorzoeken of de beleidsregels van de domeincontroller moet doornemen.
Zoek op de domeincontroller
Opmerking: Mogelijk moet u de volgende procedure herhalen voor alle domeincontrollers.
- Klik op Start, wijs Programma's aan en klik op Systeembeheer.
- Vouw onder Lokale beveiligingsinstellingen de optie Lokaal beleid uit.
- Klik op Beveiligingsopties.
- Dubbelklik op Netwerkbeveiliging: LAN Manager-verificatieniveau en klik vervolgens op een waarde in de lijst.
Als de effectieve instelling en de lokale instelling identiek zijn, is het beleid op dit niveau gewijzigd. Als de instellingen verschillen, controleert u het beleid van de domeincontroller om te bepalen of de instelling Netwerkbeveiliging: verificatieniveau LAN-manager hier is gedefinieerd. Als die daar niet is gedefinieerd, bekijk dan het beleid van de domeincontroller.
Onderzoek het beleid van de domeincontroller
- Klik op Start, wijs Programma's aan en klik op Systeembeheer.
- vouw in het beveiligingsbeleid van domeincontroller de beveiligingsinstellingen uit en vouw vervolgens lokaal beleid uit.
- Klik op Beveiligingsopties.
- Dubbelklik op Netwerkbeveiliging: LAN Manager-verificatieniveau en klik vervolgens op een waarde in de lijst.
Opmerking
- U moet mogelijk ook beleidsregels controleren die zijn gekoppeld op site-, domein- of organisatie-eenheidniveau om te bepalen waar u het verificatieniveau van LAN-beheer moet configureren.
- Als u een instelling voor groepsbeleid implementeert als het standaarddomeinbeleid, wordt het beleid toegepast op alle computers in het domein.
- Als u een instelling voor groepsbeleid implementeert als het standaardbeleid van de domeincontroller, is het beleid alleen van toepassing op de servers in de OU van de domeincontroller.
- Het is een goed idee om het verificatieniveau van LAN-beheer in te stellen in de laagste entiteit van het vereiste bereik in de hiërarchie van de beleidstoepassingen.
In Windows Server 2003 is een nieuwe standaardinstelling opgenomen voor het gebruik van alleen NTLMv2. Standaard is voor domeincontrollers met basis van Windows Server 2003 en Windows 2000 Server SP3 het beleid 'Microsoft-netwerkserver: Communicatie digitaal ondertekenen (altijd)' ingeschakeld. Voor deze instelling moet de SMB-server SMB-pakketondertekening uitvoeren. Wijzigingen in Windows Server 2003 werden aangebracht omdat domeincontrollers, bestandsservers, netwerkinfrastructuurservers en webservers in elke organisatie verschillende instellingen nodig hebben om hun beveiliging te maximaliseren.
Als u NTLMv2-verificatie in uw netwerk wilt implementeren, moet u ervoor zorgen dat alle computers in het domein zijn ingesteld op het gebruik van dit verificatieniveau. Als u Active Directory-clientextensies voor Windows 95 of Windows 98 en Windows NT 4.0 toepast, gebruiken de clientextensies de verbeterde verificatiefuncties die beschikbaar zijn in NTLMv2. Omdat clientcomputers met een van de volgende besturingssystemen niet worden beïnvloed door Windows 2000-groepsbeleid-objecten, moet u deze clients mogelijk handmatig configureren:
- Microsoft Windows NT 4.0
- Microsoft Windows Millennium Edition
- Microsoft Windows 98
- Microsoft Windows 95
Opmerking Als u de netwerkbeveiliging inschakelt : Sla de hashwaarde van LAN Manager niet op bij het volgende beleid voor wachtwoordwijziging en stel de registersleutel NoLMHash niet in. Windows 95- en Windows 98-clients waarop de Directory Services-client niet is geïnstalleerd, kunnen zich niet aanmelden bij het domein nadat het wachtwoord is gewijzigd.
Veel CIFS-servers van derden, zoals Novell Netware 6, zijn niet op de hoogte van NTLMv2 en gebruiken alleen NTLM. Daarom staan niveaus groter dan 2 geen connectiviteit toe. Er zijn ook SMB-clients van derden die geen gebruikmaken van uitgebreide sessiebeveiliging. In deze gevallen wordt het LmCompatiblityLevel van de bronserver buiten beschouwing gelaten. De server pakt vervolgens deze verouderde aanvraag in en verzendt deze naar de User Domain Controller. De instellingen op de domeincontroller bepalen vervolgens welke hashes worden gebruikt om de aanvraag te verifiëren en of deze voldoen aan de beveiligingsvereisten van de domeincontroller.
299656 Voorkomen dat Windows een LAN Manager-hash van uw wachtwoord opslaat in Active Directory en lokale SAM-databases
2701704 controlegebeurtenis wordt het verificatiepakket weergegeven als NTLMv1 in plaats van NTLMv2 Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie over LM-verificatieniveaus:
239869 NTLM 2-verificatie inschakelen
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
Niet-beperkende instellingen die wachtwoorden verzenden in niet-versleutelde tekst en die NTLMv2-onderhandeling weigeren
Beperkende instellingen die verhinderen dat incompatibele clients of domeincontrollers een gemeenschappelijk verificatieprotocol gebruiken
NTLMv2-verificatie vereisen op lidcomputers en domeincontrollers waarop versies van Windows NT 4.0 worden uitgevoerd die lager zijn dan Service Pack 4 (SP4)
NTLMv2-verificatie vereisen op Windows 95-clients of op Windows 98-clients waarop de Windows Directory Services-client niet is geïnstalleerd.
Als u op een computer met Windows Server 2003 of Windows 2000 Service Pack 3 het selectievakje NTLMv2-sessiebeveiliging vereisen inschakelt in de Microsoft Management Console-module groepsbeleid Editor en u het verificatieniveau LAN Manager verlaagt tot 0, conflicteren de twee instellingen en wordt mogelijk het volgende foutbericht weergegeven in het bestand Secpol.msc of GPEdit.msc:
Opmerking
Windows kan de database met lokaal beleid niet openen. Er is een onbekende fout opgetreden bij het openen van de database.
Zie de Help-bestanden voor Windows 2000 of Windows Server 2003 voor meer informatie over het hulpprogramma voor beveiligingsconfiguratie en -analyse.
Redenen om deze instelling te wijzigen
- U wilt het laagste algemene verificatieprotocol dat wordt ondersteund door clients en domeincontrollers in uw organisatie uitbreiden.
- Als beveiligde verificatie een zakelijke vereiste is, wilt u onderhandelen over de LM- en NTLM-protocollen niet toestaan.
Redenen om deze instelling uit te schakelen
De vereisten voor client- en/of serverauthenticatie zijn zodanig verhoogd dat authenticatie via een gemeenschappelijk protocol niet mogelijk is.
Symbolische naam:
LmCompatibilityLevel
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevelVoorbeelden van compatibiliteitsproblemen
Windows Server 2003: Standaard is de instelling NTLMv2-antwoorden verzenden in Windows Server 2003 NTLMv2 ingeschakeld. Daarom ontvangt Windows Server 2003 na de eerste installatie het foutbericht "Toegang geweigerd" wanneer u probeert verbinding te maken met een Windows NT 4.0-cluster of met LanManager V2.1-servers, zoals OS/2 Lanserver. Dit probleem treedt ook op als u probeert verbinding te maken vanaf een client van een eerdere versie met een server op basis van Windows Server 2003.
U installeert Windows 2000-beveiligingsupdatepakket 1 (SRP1). SRP1 dwingt NTLM versie 2 (NTLMv2) af. Dit updatepakket is uitgebracht na de release van Windows 2000 Service Pack 2 (SP2).
Windows 7 en Windows Server 2008 R2: Veel CIFS-servers van derden, zoals Novell Netware 6 of op Linux gebaseerde Samba-servers, zijn niet op de hoogte van NTLMv2 en gebruiken alleen NTLM. Daarom staan niveaus groter dan "2" geen connectiviteit toe. In deze versie van het besturingssysteem is de standaardinstelling voor LmCompatibilityLevel gewijzigd in "3". Dus wanneer u Windows bijwerkt, werken deze externe filers mogelijk niet meer.
Microsoft Outlook-clients kunnen worden gevraagd om referenties, zelfs als ze al zijn aangemeld bij het domein. Wanneer gebruikers hun referenties opgeven, wordt het volgende foutbericht weergegeven: Windows 7 en Windows Server 2008 R2
Opmerking
De opgegeven aanmeldingsreferenties waren onjuist. Controleer of uw gebruikersnaam en domein juist zijn en typ vervolgens uw wachtwoord opnieuw.
Wanneer u Outlook start, wordt u mogelijk om uw referenties gevraagd, zelfs als uw instelling voor Beveiliging van aanmeldnetwerk is ingesteld op Passthrough of op Wachtwoordverificatie. Nadat u de juiste referenties hebt ingevoerd, wordt het volgende foutbericht weergegeven:
Opmerking
De opgegeven aanmeldingsreferenties waren onjuist.
In een netwerktracering kan worden weergegeven dat de globale catalogus een RPC-fout (Remote Procedure Call) heeft afgegeven met de status 0x5. De status 0x5 betekent 'Toegang geweigerd'.
Windows 2000: Bij een opname van een netwerkmonitor kunnen de volgende fouten worden weergegeven in de NetBIOS over TCP/IP (NetBT) server message block (SMB)-sessie:
Opmerking
SMB R Search Directory Dos-fout, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ongeldige gebruikers-id
Windows 2000: Als een Windows 2000-domein met NTLMv2 niveau 2 of hoger wordt vertrouwd door een Windows NT 4.0-domein, kunnen op Windows 2000 gebaseerde lidcomputers in het brondomein verificatiefouten optreden.
Windows 2000 en Windows XP: In Windows 2000 en Windows XP is de optie Lokaal beveiligingsbeleid op het niveau van het lokale beveiligingsbeleid van LAN Manager standaard ingesteld op 0. De instelling 0 betekent 'LM- en NTLM-antwoorden verzenden'.
Opmerking Windows NT 4.0-clusters moeten LM gebruiken voor beheer.
Windows 2000: Windows 2000-clustering authenticeert een deelnemend knooppunt niet als beide knooppunten deel uitmaken van een Windows NT 4.0 Service Pack 6a (SP6a)-domein.
Het IIS-hulpprogramma Vergrendelen (HiSecWeb) stelt de LMCompatibilityLevel-waarde in op 5 en de RestrictAnonymous-waarde op 2.
Services for Macintosh
User Authentication Module (UAM): De Microsoft UAM (User Authentication Module) biedt een methode voor het versleutelen van de wachtwoorden waarmee u zich aanmeldt bij Windows AFP-servers (AppleTalk Filing Protocol). De Apple User Authentication Module (UAM) biedt slechts minimale of geen versleuteling. Daarom kan uw wachtwoord gemakkelijk worden onderschept op het LAN of op internet. Hoewel het UAM niet vereist is, biedt het wel versleutelde verificatie voor Windows 2000-servers waarop Services For Macintosh wordt uitgevoerd. Deze versie bevat ondersteuning voor NTLMv2 128-bits versleutelde authenticatie en een MacOS X 10.1-compatibele release.
Standaard staat op de server Windows Server 2003 Services for Macintosh alleen verificatie van Microsoft toe.
Windows Server 2008, Windows Server 2003, Windows XP en Windows 2000: Als u de LMCompatibilityLevel-waarde configureert op 0 of 1 en vervolgens de NoLMHash-waarde op 1, kan de toegang van toepassingen en onderdelen via NTLM worden geweigerd. Dit probleem treedt op omdat de computer is geconfigureerd om LM in te schakelen, maar niet om door LM opgeslagen wachtwoorden te gebruiken.
Als u de NoLMHash-waarde configureert op 1, moet u de LMCompatibilityLevel-waarde configureren op 2 of hoger.
Netwerkbeveiliging: ondertekeningsvereisten voor LDAP-client
Achtergrond
De instelling Netwerkbeveiliging: vereisten voor LDAP-clientondertekening bepaalt het niveau van gegevensondertekening dat wordt aangevraagd namens clients die LDAP BIND-aanvragen (Lightweight Directory Access Protocol) uitgeven, als volgt:
- Geen: De LDAP BIND-aanvraag wordt uitgegeven met de door de aanroeper opgegeven opties.
- Onderhandelen over ondertekening: Als de Secure Sockets Layer/Transport Layer Security (SSL/TLS) niet is gestart, wordt het LDAP BIND-verzoek geïnitieerd met de LDAP-optie voor gegevensondertekening ingesteld naast de door de aanroeper opgegeven opties. Als SSL/TLS is gestart, wordt de LDAP BIND-aanvraag geïnitieerd met de door de aanroeper opgegeven opties.
- Ondertekening vereisen: Dit is hetzelfde als onderhandelen ondertekening. Als de tussenliggende saslBindInProgress-reactie van de LDAP-server echter niet aangeeft dat LDAP-verkeersondertekening is vereist, krijgt de beller te horen dat de opdracht LDAP BIND is mislukt.
Riskante configuratie
De netwerkbeveiliging inschakelen: De instelling Vereisten voor LDAP-clientondertekening is een schadelijke configuratie-instelling. Als u de server instelt op het vereisen van LDAP-handtekeningen, moet u LDAP-ondertekening ook configureren op de client. Als u de client niet configureert voor het gebruik van LDAP-handtekeningen, wordt er geen communicatie met de server uitgevoerd. Dit zorgt ervoor dat gebruikersverificatie, instellingen voor groepsbeleid, aanmeldingsscripts en andere functies mislukken.
Redenen om deze instelling te wijzigen
Niet-ondertekend netwerkverkeer is vatbaar voor man-in-the-middle-aanvallen waarbij een indringer pakketten tussen de client en de servers vastlegt, wijzigt en vervolgens doorstuurt naar de server. Wanneer dit gebeurt op een LDAP-server, kan een aanvaller een server laten reageren op basis van valse query's van de LDAP-client. U kunt dit risico in een bedrijfsnetwerk verlagen door krachtige fysieke beveiligingsmaatregelen te implementeren om de netwerkinfrastructuur te helpen beschermen. Daarnaast kunt u allerlei soorten man-in-the-middle-aanvallen helpen voorkomen door digitale handtekeningen te vereisen op alle netwerkpakketten door middel van IPSec-verificatieheaders.
Symbolische naam:
LDAPClientIntegrity
Registerpad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
Gebeurtenislogboek: Maximale grootte van het beveiligingslogboek
Achtergrond
Het gebeurtenislogboek: Maximale grootte van het beveiligingslogboek De beveiligingsinstelling geeft de maximale grootte van het gebeurtenislogboek voor beveiliging aan. Dit logboek heeft een maximale grootte van 4 GB. Als u deze instelling wilt vinden, vouwt u
Windows-instellingen en vouwt u vervolgens Beveiligingsinstellingen uit.Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- Beperking van de grootte van het beveiligingslogboek en het bewaren van het beveiligingslogboek tijdens de instelling Controle: systeem onmiddellijk afsluiten als het niet mogelijk is om beveiligingsaudits te registreren is ingeschakeld. Zie de sectie 'Audit: sluit het systeem onmiddellijk af als u geen beveiligingsaudits kunt loggen' van dit artikel voor meer informatie.
- De grootte van het beveiligingslogboek beperken, zodat belangrijke beveiligingsgebeurtenissen worden overschreven.
Redenen om deze instelling te verhogen
Zakelijke en beveiligingsvereisten kunnen vereisen dat u de grootte van het beveiligingslogboek vergroot om extra beveiligingslogboekgegevens te verwerken of om beveiligingslogboeken voor een langere periode te bewaren.
Redenen om deze instelling te verlagen
Logboeken zijn in het geheugen toegewezen bestanden. De maximale grootte van een gebeurtenislogboek wordt beperkt door de hoeveelheid fysiek geheugen in de lokale computer en door het virtuele geheugen dat beschikbaar is voor het gebeurtenislogboekproces. Het vergroten van de logboekgrootte boven de hoeveelheid virtueel geheugen die beschikbaar is voor Logboeken verhoogt niet het aantal logboekvermeldingen dat wordt bijgehouden.
Voorbeelden van compatibiliteitsproblemen
Windows 2000: Computers met versies van Windows 2000 die ouder zijn dan Service Pack 4 (SP4), stoppen mogelijk met het registreren van gebeurtenissen in het gebeurtenislogboek voordat ze de grootte hebben bereikt die is opgegeven in de instelling Maximale logboekgrootte in Logboeken als de optie Geen gebeurtenissen overschrijven (logboek handmatig wissen) is ingeschakeld.
Gebeurtenislogboek: Beveiligingslogboek behouden
Achtergrond
Het gebeurtenislogboek: Beveiligingslogboek behouden De beveiligingsinstelling bepaalt de 'wrapping'-methode voor het beveiligingslogboek. Als u deze instelling wilt vinden, vouwt u Windows-instellingen uit en vouwt u vervolgens Beveiligingsinstellingen uit.
Riskante configuraties
De volgende zijn schadelijke configuratie-instellingen:
- Het niet behouden van alle geregistreerde beveiligingsgebeurtenissen voordat ze worden overschreven
- De instelling Maximale grootte van het beveiligingslogboek te klein maken, zodat beveiligingsgebeurtenissen worden overschreven
- De grootte van het beveiligingslogboek en de bewaarmethode beperken tijdens de controle: het systeem onmiddellijk afsluiten als het niet mogelijk is om beveiligingsaudits te registreren beveiligingsinstelling is ingeschakeld
Redenen om deze instelling in te schakelen
Schakel deze instelling alleen in als u de bewaarmethode Gebeurtenissen overschrijven per dag selecteert. Als u een gebeurteniscorrelatiesysteem gebruikt waarmee naar gebeurtenissen wordt gepeild, moet u ervoor zorgen dat het aantal dagen ten minste drie keer zo groot is als de frequentie van de peiling. Doe dit om mislukte peilingscycli toe te staan.
Netwerktoegang: de machtigingen Iedereen toestaan zijn van toepassing op anonieme gebruikers
Achtergrond
Standaard is de instelling Netwerktoegang: Laat iedereen machtigingen toepassen op anonieme gebruikers ingesteld op Niet gedefinieerd op Windows Server 2003. Standaard bevat Windows Server 2003 het token voor anonieme toegang niet in de groep Iedereen.
Voorbeeld van compatibiliteitsproblemen
De volgende waarde van
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 verbreekt het maken van vertrouwensrelaties tussen Windows Server 2003 en Windows NT 4.0, wanneer het Windows Server 2003-domein het accountdomein is en het Windows NT 4.0-domein het brondomein. Dit betekent dat het accountdomein Vertrouwd is in Windows NT 4.0 en het brondomein Vertrouwd is aan de kant van Windows Server 2003. Dit gedrag treedt op omdat het proces voor het starten van de vertrouwensrelatie na de eerste anonieme verbinding ACL is met het Everyone-token waarin de anonieme SID op Windows NT 4.0 is opgenomen.Redenen om deze instelling te wijzigen
De waarde moet worden ingesteld op 0x1 of worden ingesteld met behulp van een groepsbeleidsobject op de organisatie-eenheid van de domeincontroller: Netwerktoegang: de machtigingen Iedereen mogen worden gebruikt voor anonieme gebruikers: deze machtiging is ingeschakeld om het maken van vertrouwensrelaties mogelijk te maken.
Opmerking: De meeste andere beveiligingsinstellingen stijgen in waarde in plaats van omlaag naar 0x0 in hun meest beveiligde status. Het is veiliger om het register op de primaire domeincontroller-emulator te wijzigen in plaats van op alle domeincontrollers. Als de rol van de primaire domeincontroller-emulator om welke reden dan ook wordt verplaatst, moet het register op de nieuwe server worden bijgewerkt.
Opnieuw opstarten is vereist nadat deze waarde is ingesteld.
Registerpad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
NTLMv2-verificatie
Sessiebeveiliging
Sessiebeveiliging bepaalt de minimale beveiligingsnormen voor client- en serversessies. Het is een goed idee om de volgende instellingen voor het beveiligingsbeleid te controleren in de module Editor voor groepsbeleid van Microsoft Management Console:
- Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options
- Netwerkbeveiliging: Minimale sessiebeveiliging voor NTLM SSP-gebaseerde (inclusief beveiligde RPC)-servers
- Netwerkbeveiliging: minimale sessiebeveiliging voor NTLM SSP-clients (inclusief beveiligde RPC-clients)
De opties voor deze instellingen zijn als volgt:
- Integriteit van berichten vereisen
- Vertrouwelijkheid van berichten vereisen
- NTLM versie 2-sessiebeveiliging vereisen
- 128-bits versleuteling vereisen
De standaardinstelling vóór Windows 7 is Geen vereisten. Vanaf Windows 7 is de standaardinstelling gewijzigd in 128-bits versleuteling vereisen voor betere beveiliging. Met deze standaard kunnen oudere apparaten die geen ondersteuning bieden voor 128-bits versleuteling geen verbinding maken.
Op basis van deze beleidsregels worden de minimale beveiligingsnormen vastgesteld voor een communicatiesessie tussen toepassingen op een server voor een client.
Hoewel beschreven als geldige instellingen, worden de vlaggen voor het vereisen van de integriteit en vertrouwelijkheid van berichten niet gebruikt bij het bepalen van de beveiliging van de NTLM-sessie.
Windows NT heeft historisch gezien de volgende twee varianten van challenge/response-verificatie voor netwerkaanmeldingen ondersteund:
- LM uitdaging/reactie
- NTLM versie 1 uitdaging/antwoord
LM maakt interoperabiliteit met de geïnstalleerde basis van clients en servers mogelijk. NTLM biedt verbeterde beveiliging voor verbindingen tussen clients en servers.
De bijbehorende registersleutels zijn als volgt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"Riskante configuraties
Deze instelling bepaalt hoe netwerksessies die zijn beveiligd met NTLM worden afgehandeld. Dit geldt bijvoorbeeld voor RPC-sessies die zijn geverifieerd met NTLM. Er zijn de volgende risico's:
- Het gebruik van oudere authenticatiemethoden dan NTLMv2 maakt de communicatie gemakkelijker aan te vallen vanwege de eenvoudigere hashing-methoden die worden gebruikt.
- Met behulp van versleutelingssleutels die lager zijn dan 128-bits kunnen aanvallers de communicatie verbreken met brute-force-aanvallen.
Tijdsynchronisatie
Tijdsynchronisatie is mislukt. De tijd op een getroffen computer meer dan 30 minuten afwijkt. Zorg ervoor dat de klok van de clientcomputer is gesynchroniseerd met die van de domeincontroller.
Tijdelijke oplossing voor ondertekening door het MKB
Het is raadzaam Service Pack 6a (SP6a) te installeren op Windows NT 4.0-clients die samenwerken in een domein gebaseerd op Windows Server 2003. Clients met Windows 98 Second Edition, Windows 98-clients en Windows 95-clients moeten de Directory Services-client uitvoeren om NTLMv2 te kunnen uitvoeren. Als Windows NT 4.0-clients niet voorzien zijn van Windows NT 4.0 SP6 of als op Windows 95, Windows 98 gebaseerde clients en Windows 98SE-clients niet beschikken over de Directory Services Client, schakelt u SMB-ondertekening uit in de beleidsinstelling van de standaarddomeincontroller in de organisatie-eenheid van de domeincontroller en koppelt u dit beleid vervolgens aan alle organisatie-eenheden die als host fungeren voor domeincontrollers.
De Directory Services Client voor Windows 98 Tweede editie, Windows 98 en Windows 95 voert SMB-ondertekening uit met Windows 2003-servers onder NTLM-authenticatie, maar niet onder NTLMv2-authenticatie. Bovendien reageren Windows 2000-servers niet op SMB-ondertekeningsaanvragen van deze clients.
Hoewel dit niet wordt aangeraden, kunt u voorkomen dat SMB-ondertekening vereist is op alle domeincontrollers die Windows Server 2003 in een domein draaien. Ga als volgt te werk om deze beveiligingsinstelling te configureren:
- Open het beleid van de standaarddomeincontroller.
- Open de map Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options (Computerconfiguratie\Windows-instellingen\Beveiligingsinstellingen\Local Policies\Beveiligingsopties).
- Zoek de Microsoft-netwerkserver en klik erop: Beleidsinstelling Communicatie digitaal ondertekenen (altijd) en klik vervolgens op Uitgeschakeld.
Belangrijk Deze sectie, methode of taak bevat stappen voor het bewerken van het register. Er kunnen echter ernstige problemen optreden als u het register verkeerd wijzigt. Zorg er daarom voor dat u deze stappen zorgvuldig uitvoert. Zorg er als extra beveiligingsmaatregel voor dat u een back-up van het register maakt voordat u hierin wijzigingen aanbrengt. Vervolgens kunt u het register herstellen als er een probleem optreedt. Als u meer informatie wilt over het maken van een back-up van het register en het herstellen van het register, klikt u op het volgende artikelnummer in de Microsoft Knowledge Base:
322756 Een back-up van het register maken en het register herstellen in Windows U kunt ook SMB-ondertekening op de server uitschakelen door het register te wijzigen. Ga hiervoor als volgt te werk:
- Klik op Start, klik op Uitvoeren, typ regedit en klik vervolgens op OK.
- Zoek de volgende subsleutel en klik erop:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters - Klik op de vermelding enablesecuritysignature .
- Klik in het menu Bewerken op Aanpassen.
- Typ 0 in het vak Waardegegevens en klik op OK.
- Sluit de Register-editor af.
- Start de computer opnieuw op of stop en start de Server-service opnieuw. Typ hiervoor de volgende opdrachten in een opdrachtprompt en druk na elke opdracht op Enter:
net stop server
net start server
Opmerking De bijbehorende sleutel op de clientcomputer bevindt zich in de volgende registersubsleutel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters In de volgende tabel worden de eerder genoemde foutcodenummers weergegeven die zijn omgezet in statuscodes en letterlijke foutberichten:
Opmerking
fout 5
ERROR_ACCESS_DENIED
Toegang is geweigerd.
Opmerking
fout 1326
ERROR_LOGON_FAILURE
Aanmeldingsfout: onbekende gebruikersnaam of onjuist wachtwoord.
Opmerking
fout 1788
ERROR_TRUSTED_DOMAIN_FAILURE
De vertrouwensrelatie tussen het primaire domein en het vertrouwde domein is mislukt.
Opmerking
fout 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
De vertrouwensrelatie tussen dit werkstation en het primaire domein is mislukt.
Klik op de volgende artikelnummers in de Microsoft Knowledge Base voor meer informatie:
324802 Groepsbeleid configureren om beveiliging voor systeemservices in te stellen in Windows Server 2003
816585 Vooraf gedefinieerde beveiligingssjablonen toepassen in Windows Server 2003