Logga in med Microsoft
Logga in eller skapa ett konto.
Hej,
Välj ett annat konto.
Du har flera konton
Välj det konto som du vill logga in med.

Sammanfattning

Säkerhetsinställningar och tilldelningar av användarrättigheter kan ändras i lokala principer och grupprinciper för att öka säkerheten på domänkontrollanter och medlemsdatorer. Nackdelen med ökad säkerhet är dock införandet av inkompatibilitet med klienter, tjänster och program.

I den här artikeln beskrivs kompatibilitet som kan uppstå på klientdatorer som kör Windows XP, eller en tidigare version av Windows, när du ändrar specifika säkerhetsinställningar och tilldelningar av användarrättigheter i en Windows Server 2003-domän eller en tidigare Windows Server-domän.

Mer information om grupprincip för Windows 7, Windows Server 2008 R2 och Windows Server 2008 finns i följande artiklar:

Obs! Det återstående innehållet i den här artikeln är specifikt för Windows XP, Windows Server 2003 och tidigare versioner av Windows.

Windows XP

Om du vill öka medvetenheten om felkonfigurerade säkerhetsinställningar använder du verktyget grupprincip Objektredigeraren för att ändra säkerhetsinställningarna. När du använder grupprincip Objektredigeraren förbättras tilldelningar av användarrättigheter på följande operativsystem:

  • Windows XP Professional Service Pack 2 (SP2)

  • Windows Server 2003 Service Pack 1 (SP1)

Den förbättrade funktionen är en dialogruta som innehåller en länk till den här artikeln. Dialogrutan visas när du ändrar en säkerhetsinställning eller en tilldelning av användarrättigheter till en inställning som ger mindre kompatibilitet och är mer restriktiv. Om du direkt ändrar samma säkerhetsinställning eller tilldelning av användarrättigheter med hjälp av registret eller med hjälp av säkerhetsmallar, är det samma sak som att ändra inställningen i grupprincip Objektredigeraren. Men dialogrutan som innehåller länken till den här artikeln visas inte.

Den här artikeln innehåller exempel på klienter, program och åtgärder som påverkas av specifika säkerhetsinställningar eller tilldelningar av användarrättigheter. Exemplen är dock inte auktoritativa för alla Microsoft-operativsystem, för alla operativsystem från tredje part eller för alla programversioner som påverkas. Alla säkerhetsinställningar och tilldelningar av användarrättigheter ingår inte i den här artikeln.

Vi rekommenderar att du verifierar kompatibiliteten för alla säkerhetsrelaterade konfigurationsändringar i en testskog innan du introducerar dem i en produktionsmiljö. Provskogen måste spegla produktionsskogen på följande sätt:

  • Klient- och serveroperativsystemversioner, klient- och serverprogram, Service Pack-versioner, snabbkorrigeringar, schemaändringar, säkerhetsgrupper, gruppmedlemskap, behörigheter för objekt i filsystemet, delade mappar, registret, Active Directory-katalogtjänsten, lokala och grupprincip inställningar samt typ och plats för objektantal

  • Administrativa uppgifter som utförs, administrativa verktyg som används och operativsystem som används för att utföra administrativa uppgifter

  • Åtgärder som utförs, till exempel följande:

    • Dator- och användarinloggningsautentisering

    • Lösenord återställs av användare, efter datorer och av administratörer

    • Webbsökning

    • Ange behörigheter för filsystemet, för delade mappar, för registret och för Active Directory-resurser genom att använda ACL Editor i alla klientoperativsystem i alla konto- eller resursdomäner från alla klientoperativsystem från alla konto- eller resursdomäner

    • Skriva ut från administrativa och icke-administrativa konton

Windows Server 2003 SP1

Varningar i Gpedit.msc

För att göra kunderna medvetna om att de redigerar en användares rätt eller säkerhetsalternativ som kan ha påverkat deras nätverk negativt, har två varningsmetoder lagts till i gpedit.msc. När administratörer redigerar en användarrätt som kan påverka hela företaget negativt visas en ny ikon som liknar ett avkastningstecken. De får också ett varningsmeddelande som innehåller en länk till Microsoft Knowledge Base-artikeln 823659. Texten i det här meddelandet är följande:

Om du ändrar den här inställningen kan kompatibiliteten med klienter, tjänster och program påverkas. Mer information finns i <användares höger- eller säkerhetsalternativ som ändras> (Q823659) Om du hänvisas till den här Knowledge Base-artikeln från en länk i Gpedit.msc ska du se till att du läser och förstår förklaringen och den möjliga effekten av att ändra den här inställningen. Nedan visas Användarrättigheter som innehåller varningstexten:

  • Komma åt den här datorn från nätverket

  • Logga in lokalt

  • Hoppa över blädderingskontroll

  • Aktivera datorer och användare för betrodd delegering

Nedan visas säkerhetsalternativ med varningen och ett popup-meddelande:

  • Domänmedlem: Kryptera eller signera data för säker kanal digitalt (alltid)

  • Domänmedlem: Kräv stark sessionsnyckel (Windows 2000 eller en senare version)

  • Domänkontrollant: LDAP-serversigneringskrav

  • Microsoft-nätverksserver: Signera kommunikation digitalt (alltid)

  • Nätverksåtkomst: Tillåter anonym sid-/namnöversättning

  • Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och -resurser

  • Nätverkssäkerhet: Autentiseringsnivå för LAN-hanterare

  • Granskning: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar

  • Nätverksåtkomst: LDAP-klientsigneringskrav

Mer information

I följande avsnitt beskrivs inkompatibilitet som kan uppstå när du ändrar specifika inställningar i Windows NT 4.0-domäner, Windows 2000-domäner och Windows Server 2003-domäner.

Användarrättigheter

I följande lista beskrivs en användarrätt, konfigurationsinställningar som kan orsaka problem identifieras, varför du bör tillämpa användarrätten och varför du kanske vill ta bort användarrätten och innehåller exempel på kompatibilitetsproblem som kan uppstå när användarrätten är konfigurerad.

  1. Komma åt den här datorn från nätverket

    1. Bakgrund

      Möjligheten att interagera med windows-baserade fjärrdatorer kräver åtkomst till den här datorn från nätverksanvändarens höger. Exempel på sådana nätverksåtgärder är:

      • Replikering av Active Directory mellan domänkontrollanter i en gemensam domän eller skog

      • Autentiseringsbegäranden till domänkontrollanter från användare och från datorer

      • Åtkomst till delade mappar, skrivare och andra systemtjänster som finns på fjärrdatorer i nätverket



      Användare, datorer och tjänstkonton får eller förlorar åtkomsten till den här datorn från nätverksanvändare genom att uttryckligen eller implicit läggas till eller tas bort från en säkerhetsgrupp som har beviljats den här användarrätten. Ett användarkonto eller ett datorkonto kan till exempel uttryckligen läggas till i en anpassad säkerhetsgrupp eller en inbyggd säkerhetsgrupp av en administratör, eller så kan operativsystemet implicit läggas till i en beräknad säkerhetsgrupp som Domänanvändare, Autentiserade användare eller Domänkontrollanter för företag.

      Som standard beviljas användarkonton och datorkonton åtkomst till den här datorn från nätverksanvändare direkt när grupper som Alla eller, helst autentiserade användare, och för domänkontrollanter, gruppen Enterprise Domain Controllers, definieras i standarddomänkontrollanterna grupprincip Object (GPO).

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Ta bort säkerhetsgruppen Enterprise Domain Controllers från den här användarens höger

      • Ta bort gruppen Autentiserade användare eller en explicit grupp som gör det möjligt för användare, datorer och tjänstkonton att ansluta till datorer över nätverket

      • Ta bort alla användare och datorer från den här användarens rättighet

    3. Anledningar till att bevilja användaren rätt

      • Att bevilja åtkomst till den här datorn från nätverksanvändares rätt till gruppen Enterprise Domain Controllers uppfyller autentiseringskrav som Active Directory-replikering måste ha för att replikering ska ske mellan domänkontrollanter i samma skog.

      • Med den här användarrätten kan användare och datorer komma åt delade filer, skrivare och systemtjänster, inklusive Active Directory.

      • Den här användarrätten krävs för att användare ska kunna komma åt e-post med hjälp av tidiga versioner av Microsoft Outlook Web Access (OWA).

    4. Anledningar till att ta bort den här användarens rätt

      • Användare som kan ansluta sina datorer till nätverket kan komma åt resurser på fjärrdatorer som de har behörighet för. Den här användarrätten krävs till exempel för att en användare ska kunna ansluta till delade skrivare och mappar. Om den här användarrätten beviljas gruppen Alla, och om vissa delade mappar har både filsystembehörigheter för delning och NTFS konfigurerade så att samma grupp har läsbehörighet, kan vem som helst visa filer i de delade mapparna. Det här är dock osannolikt för nya installationer av Windows Server 2003 eftersom standardresursen och NTFS-behörigheterna i Windows Server 2003 inte innehåller gruppen Alla. För system som uppgraderas från Microsoft Windows NT 4.0 eller Windows 2000 kan den här säkerhetsrisken ha en högre risknivå eftersom standardresursen och filsystembehörigheterna för dessa operativsystem inte är lika restriktiva som standardbehörigheterna i Windows Server 2003.

      • Det finns ingen giltig anledning att ta bort gruppen Enterprise Domain Controllers från den här användarrätten.

      • Gruppen Alla tas vanligtvis bort till förmån för gruppen Autentiserade användare. Om gruppen Alla tas bort måste gruppen Autentiserade användare beviljas den här användarrätten.

      • Windows NT 4.0-domäner som uppgraderas till Windows 2000 beviljar inte uttryckligen åtkomst till den här datorn från nätverksanvändares rätt till gruppen Alla, gruppen Autentiserade användare eller gruppen Enterprise Domain Controllers. När du tar bort gruppen Alla från windows NT 4.0-domänprincipen misslyckas därför Active Directory-replikering med felmeddelandet "Åtkomst nekad" efter att du uppgraderat till Windows 2000. Winnt32.exe i Windows Server 2003 undviker den här felaktiga konfigurationen genom att bevilja enterprise domain controllers-gruppen den här användaren direkt när du uppgraderar Windows NT 4.0-primära domänkontrollanter (PDC). Bevilja enterprise domain controllers group this user right if it is not present in the grupprincip Object Editor.

    5. Exempel på kompatibilitetsproblem

      • Windows 2000 och Windows Server 2003: Replikering av följande partitioner misslyckas med "Åtkomst nekad"-fel som rapporterats av övervakningsverktyg som REPLMON och REPADMIN eller replikeringshändelser i händelseloggen.

        • Active Directory-schemapartition

        • Konfigurationspartition

        • Domänpartition

        • Global katalogpartition

        • Programpartition

      • Alla Microsoft-nätverksoperativsystem: Användarkontoautentisering från fjärrnätverksklientdatorer misslyckas om inte användaren eller en säkerhetsgrupp som användaren är medlem i har beviljats denna användarrätt.

      • Alla Microsoft-nätverksoperativsystem: Kontoautentisering från fjärrnätverksklienterna misslyckas om inte kontot eller en säkerhetsgrupp som kontot är medlem i har beviljats den här användarbehörigheten. Det här scenariot gäller för användarkonton, datorkonton och tjänstkonton.

      • Alla Operativsystem för Microsoft-nätverk: Om du tar bort alla konton från den här användarrätten hindras alla konton från att logga in på domänen eller komma åt nätverksresurser. Om beräknade grupper som Enterprise Domain Controllers, Everyone eller Authenticated Users tas bort, måste du uttryckligen bevilja användaren rätt till konton eller säkerhetsgrupper att kontot är medlem i för att få åtkomst till fjärrdatorer via nätverket. Det här scenariot gäller för alla användarkonton, alla datorkonton och alla tjänstkonton.

      • Alla Operativsystem för Microsoft-nätverk: Det lokala administratörskontot använder ett "tomt" lösenord. Nätverksanslutningar med tomma lösenord tillåts inte för administratörskonton i en domänmiljö. Med den här konfigurationen kan du förvänta dig att få felmeddelandet "Åtkomst nekad".

  2. Tillåt inloggning lokalt

    1. Bakgrund

      Användare som försöker logga in på konsolen på en Windows-baserad dator (med kortkommandot CTRL+ALT+DELETE) och konton som försöker starta en tjänst måste ha lokala inloggningsbehörigheter på värddatorn. Exempel på lokala inloggningsåtgärder är administratörer som loggar in på konsoler på medlemsdatorer eller domänkontrollanter i hela företaget och domänanvändare som loggar in på medlemsdatorer för att komma åt sina skrivbord med hjälp av konton som inte är privilegierade. Användare som använder en anslutning till fjärrskrivbord eller Terminal Services måste ha behörigheten Tillåt inloggning lokalt på måldatorer som kör Windows 2000 eller Windows XP eftersom dessa inloggningslägen anses vara lokala för värddatorn. Användare som loggar in på en server som har Terminal Server aktiverat och som inte har den här användarrätten kan fortfarande starta en interaktiv fjärrsession i Windows Server 2003-domäner om de har användarrätten Tillåt inloggning via Terminal Services.

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Ta bort administrativa säkerhetsgrupper, inklusive kontooperatörer, säkerhetskopieringsoperatorer, utskriftsoperatörer eller serveroperatörer, och den inbyggda administratörsgruppen från standardprincipen för domänkontrollanten.

      • Ta bort tjänstkonton som används av komponenter och program på medlemsdatorer och i domänkontrollanter i domänen från standardprincipen för domänkontrollanten.

      • Ta bort användare eller säkerhetsgrupper som loggar in på konsolen på medlemsdatorerna i domänen.

      • Ta bort tjänstkonton som har definierats i den lokala SAM-databasen (Security Accounts Manager) för medlemsdatorer eller arbetsgruppsdatorer.

      • Ta bort icke-inbyggda administrativa konton som autentiseras över Terminal Services som körs på en domänkontrollant.

      • Lägga till alla användarkonton i domänen explicit eller implicit via gruppen Alla till höger om neka inloggning lokalt. Den här konfigurationen hindrar användare från att logga in på alla medlemsdatorer eller domänkontrollanter i domänen.

    3. Anledningar till att bevilja användaren rätt

      • Användarna måste ha behörigheten Tillåt inloggning lokalt för att få åtkomst till konsolen eller skrivbordet på en dator i en arbetsgrupp, en medlemsdator eller en domänkontrollant.

      • Användarna måste ha rätt att logga in över en Terminal Services-session som körs på en Windows 2000-baserad medlemsdator eller domänkontrollant.

    4. Anledningar till att ta bort den här användarens rätt

      • Om det inte går att begränsa konsolåtkomsten till legitima användarkonton kan det leda till att obehöriga användare laddar ned och kör skadlig kod för att ändra sina användarrättigheter.

      • Borttagning av tillåt inloggning lokalt användarrätt förhindrar obehörig inloggning på konsoler på datorer, till exempel domänkontrollanter eller programservrar.

      • Borttagning av den här inloggningsrätten förhindrar att konton som inte är domänkonton loggar in på konsolen för medlemsdatorer i domänen.

    5. Exempel på kompatibilitetsproblem

      • Windows 2000-terminalservrar: Behörigheten Tillåt inloggning lokalt krävs för att användare ska kunna logga in på Windows 2000-terminalservrar.

      • Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003: Användarkonton måste beviljas användaren rätt att logga in på konsolen med datorer som kör Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003.

      • Windows NT 4.0 och senare: På datorer med Windows NT 4.0 och senare kan kontona inte logga in på domänkontrollanternas konsol på datorer med Windows NT 4.0 och senare, men du implicit eller uttryckligen också beviljar inloggningsrätten Neka inloggning lokalt.

  3. Hoppa över blädderingskontroll

    1. Bakgrund

      Med förbikopplingskontrollen kan användaren bläddra igenom mappar i NTFS-filsystemet eller i registret utan att söka efter den särskilda behörigheten Traverse-mapp. Förbikopplingskontrollen av användarrätten tillåter inte att användaren visar innehållet i en mapp. Det gör att användaren bara kan gå igenom sina mappar.

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Tar bort icke-administrativa konton som loggar in på Windows 2000-baserade Terminal Services-datorer eller Windows Server 2003-baserade Terminal Services-datorer som inte har behörighet att komma åt filer och mappar i filsystemet.

      • Tar bort gruppen Alla från listan med säkerhetsobjekt som har den här användaren som standard. Windows-operativsystem, och även många program, är utformade med förväntning om att alla som har laglig åtkomst till datorn kommer att ha förbikopplingskontroll av användaren rätt. Därför kan det leda till instabilitet i operativsystemet eller programfel om gruppen Alla tas bort från listan över säkerhetsobjekt som har den här användaren rätt som standard. Det är bättre att du lämnar den här inställningen som standard.

    3. Anledningar till att bevilja användaren rätt

      Standardinställningen för förbikopplingskontrollens användarrätt är att tillåta vem som helst att hoppa över genomkorsningskontrollen. För erfarna Systemadministratörer i Windows är detta det förväntade beteendet och de konfigurerar SACL:er (File System Access Control Lists) i enlighet med detta. Det enda scenario där standardkonfigurationen kan leda till ett missöde är om administratören som konfigurerar behörigheter inte förstår beteendet och förväntar sig att användare som inte kan komma åt en överordnad mapp inte kommer att kunna komma åt innehållet i några underordnade mappar.

    4. Anledningar till att ta bort den här användarens rätt

      För att förhindra åtkomst till filerna eller mapparna i filsystemet kan organisationer som är mycket oroliga för säkerheten frestas att ta bort gruppen Alla, eller till och med gruppen Användare, från listan över grupper som har användarbehörigheten Förbikopplingskontroll.

    5. Exempel på kompatibilitetsproblem

      • Windows 2000, Windows Server 2003: Om användarrätten förbikopplingskontroll tas bort eller är felkonfigurerad på datorer med Windows 2000 eller Windows Server 2003 replikeras inte grupprincip-inställningarna i SYVOL-mappen mellan domänkontrollanter i domänen.

      • Windows 2000, Windows XP Professional, Windows Server 2003: Datorer med Windows 2000, Windows XP Professional eller Windows Server 2003 loggar händelser 1000 och 1202 och kommer inte att kunna tillämpa datorprincip och användarprincip när de nödvändiga filsystembehörigheterna tas bort från SYSVOL-trädet om förbikopplingskontrollen av användarrätten tas bort eller är felkonfigurerad.

         

      • Windows 2000, Windows Server 2003: På datorer med Windows 2000 eller Windows Server 2003 försvinner fliken Kvot i Utforskaren när du visar egenskaper på en volym.

      • Windows 2000: Icke-administratörer som loggar in på en Windows 2000-terminalserver kan få följande felmeddelande:

        Userinit.exe programfel. Programmet kunde inte initieras korrekt 0xc0000142 klicka på OK för att avsluta appen.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Användare vars datorer kör Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003 kanske inte kan komma åt delade mappar eller filer i delade mappar, och de kan få felmeddelanden om nekad åtkomst om de inte beviljas behörigheten Förbikopplingskontroll av användare.


         

      • Windows NT 4.0: På Windows NT 4.0-baserade datorer leder borttagningen av förbikopplingskontrollen till användarens högerkant att en filkopia släpper filströmmar. Om du tar bort den här användarens rättighet går målfilströmmen förlorad när en fil kopieras från en Windows-klient eller från en Macintosh-klient till en Windows NT 4.0-domänkontrollant som kör Services for Macintosh och filen visas som en fil med endast text.

      • Microsoft Windows 95, Microsoft Windows 98: På en klientdator som kör Windows 95 eller Windows 98 misslyckas kommandot net use * /home med felmeddelandet "Åtkomst nekad" om gruppen Autentiserade användare inte beviljas användarbehörigheten Förbikopplingskontroll.

      • Outlook Web Access: Icke-administratörer kommer inte att kunna logga in på Microsoft Outlook Web Access, och de får felmeddelandet "Åtkomst nekad" om de inte beviljas användarbehörigheten Förbikopplingskontroll.

Säkerhetsinställningar

Följande lista identifierar en säkerhetsinställning och den kapslade listan innehåller en beskrivning av säkerhetsinställningen, identifierar konfigurationsinställningar som kan orsaka problem, beskriver varför du bör använda säkerhetsinställningen och beskriver sedan orsakerna till varför du kanske vill ta bort säkerhetsinställningen. Den kapslade listan ger sedan ett symboliskt namn för säkerhetsinställningen och registersökvägen för säkerhetsinställningen. Slutligen ges exempel på kompatibilitetsproblem som kan uppstå när säkerhetsinställningen konfigureras.

  1. Granskning: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar

    1. Bakgrund

      • Inställningen Granska: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningsinställningen avgör om systemet stängs av om du inte kan logga säkerhetshändelser. Den här inställningen krävs för TCSEC-programmets C2-utvärdering (Trusted Computer Security Evaluation Criteria) och för att de gemensamma kriterierna för säkerhetsutvärdering av informationsteknik ska förhindra granskningsbara händelser om granskningssystemet inte kan logga dessa händelser. Om granskningssystemet misslyckas stängs systemet av och ett stoppfel visas.

      • Om datorn inte kan registrera händelser i säkerhetsloggen är det möjligt att viktig information om kritisk bevisning eller viktig felsökning inte är tillgänglig för granskning efter en säkerhetsincident.

    2. Riskabla konfigurationer

      Följande är en skadlig konfigurationsinställning: Inställningen Granska: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar är aktiverad och storleken på säkerhetshändelseloggen begränsas av alternativet Skriv inte över händelser (rensa loggen manuellt), alternativet Skriv över händelser efter behov eller alternativet Skriv över händelser som är äldre än antal dagar i Loggboken. I avsnittet "Exempel på kompatibilitetsproblem" finns information om specifika risker för datorer som kör den ursprungliga versionen av Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 eller Windows 2000 SP3.

    3. Orsaker till att aktivera den här inställningen

      Om datorn inte kan registrera händelser i säkerhetsloggen är det möjligt att viktig information om kritisk bevisning eller viktig felsökning inte är tillgänglig för granskning efter en säkerhetsincident.

    4. Orsaker till att inaktivera den här inställningen

      • Aktivering av inställningen Granskning: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar stoppar systemet om en säkerhetsgranskning inte kan loggas av någon anledning. Vanligtvis går det inte att logga en händelse när säkerhetsgranskningsloggen är full och när dess angivna bevarandemetod antingen är alternativet Skriv inte över händelser (rensa loggen manuellt) eller alternativet Skriv över händelser som är äldre än antal dagar.

      • Den administrativa bördan med att aktivera granskning: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar kan vara mycket hög, särskilt om du också aktiverar alternativet Skriv inte över händelser (rensa loggen manuellt) för säkerhetsloggen. Den här inställningen ger individuell ansvarsskyldighet för operatoråtgärder. En administratör kan till exempel återställa behörigheter för alla användare, datorer och grupper i en organisationsenhet (OU) där granskning aktiverats med hjälp av det inbyggda administratörskontot eller ett annat delat konto och sedan neka att de återställer sådana behörigheter. Om du aktiverar inställningen minskas dock systemets robusthet eftersom en server kan tvingas stänga av den genom att överväldiga den med inloggningshändelser och med andra säkerhetshändelser som skrivs till säkerhetsloggen. Eftersom avstängningen inte är graciös kan det dessutom leda till irreparabel skada på operativsystemet, programmen eller data. Även om NTFS garanterar att filsystemets integritet upprätthålls under en avstängning av systemet, kan det inte garantera att alla datafiler för varje program fortfarande är i användbar form när systemet startas om.

    5. Symboliskt namn:

      CrashOnAuditFail

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

    7. Exempel på kompatibilitetsproblem

      • Windows 2000: På grund av ett fel kan datorer som kör den ursprungliga versionen av Windows 2000, Windows 2000 SP1, Windows 2000 SP2 eller Windows Server SP3 sluta logga händelser innan den storlek som anges i alternativet Maximal loggstorlek för säkerhetshändelseloggen har nåtts. Det här felet är åtgärdat i Windows 2000 Service Pack 4 (SP4). Kontrollera att windows 2000-domänkontrollanterna har Windows 2000 Service Pack 4 installerat innan du aktiverar den här inställningen.

         

      • Windows 2000, Windows Server 2003: Datorer som kör Windows 2000 eller Windows Server 2003 kan sluta svara och kan sedan spontant starta om om inställningen Granska: Stäng av systemet omedelbart om inställningen inte kan logga säkerhetsgranskningar är aktiverad, säkerhetsloggen är full och en befintlig händelseloggpost kan inte skrivas över. När datorn startas om visas följande stoppfelmeddelande:

        STOP: C0000244 {Audit Failed}
        Ett försök att generera en säkerhetsgranskning misslyckades.

        För att återställa måste en administratör logga in, arkivera säkerhetsloggen (valfritt), rensa säkerhetsloggen och sedan återställa det här alternativet (valfritt och vid behov).

      • Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Icke-administratörer som försöker logga in på en domän får följande felmeddelande:

        Ditt konto är konfigurerat för att hindra dig från att använda den här datorn. Försök med en annan dator.

      • Windows 2000: På Windows 2000-baserade datorer kan inte icke-administratörer logga in på fjärråtkomstservrar och de får ett felmeddelande som liknar följande:

        Okänd användare eller felaktigt lösenord

      • Windows 2000: På Windows 2000-domänkontrollanter stoppas tjänsten Intersite Messaging (Ismserv.exe) och kan inte startas om. DCDIAG rapporterar felet som "failed test services ISMserv" och händelse-ID 1083 registreras i händelseloggen.

      • Windows 2000: Active Directory-replikering misslyckas på Windows 2000-domänkontrollanter och meddelandet "Åtkomst nekad" visas om säkerhetshändelseloggen är full.

      • Microsoft Exchange 2000: Servrar som kör Exchange 2000 kan inte montera informationslagringsdatabasen och händelse 2102 registreras i händelseloggen.

      • Outlook, Outlook Web Access: Icke-administratörer kommer inte att kunna komma åt sin e-post via Microsoft Outlook eller via Microsoft Outlook Web Access, och de får ett 503-fel.

  2. Domänkontrollant: LDAP-serversigneringskrav

    1. Bakgrund

      Domänkontrollanten: Säkerhetsinställningen för LDAP-serversigneringskrav avgör om LDAP-servern (Lightweight Directory Access Protocol) kräver LDAP-klienter för att förhandla om datasignering. De möjliga värdena för den här principinställningen är följande:

      • Ingen: Datasignering krävs inte för att binda till servern. Om klienten begär datasignering har servern stöd för det.

      • Kräv signering: LDAP-datasigneringsalternativet måste förhandlas fram om inte TLS/SSL (Transport Layer Security/Secure Socket Layer) används.

      • inte definierad: Den här inställningen är inte aktiverad eller inaktiverad.

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Aktivera Kräv inloggning i miljöer där klienter inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte är aktiverat på klienten

      • Använda säkerhetsmallen Windows 2000 eller Windows Server 2003 Hisecdc.inf i miljöer där klienterna inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte är aktiverat

      • Använda säkerhetsmallen Windows 2000 eller Windows Server 2003 Hisecws.inf i miljöer där klienterna inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte är aktiverat

    3. Orsaker till att aktivera den här inställningen

      Osignerad nätverkstrafik är mottaglig för man-in-the-middle-attacker där en inkräktare fångar paket mellan klienten och servern, ändrar paketen och sedan vidarebefordrar dem till servern. När det här beteendet inträffar på en LDAP-server kan en angripare orsaka att en server fattar beslut som baseras på falska frågor från LDAP-klienten. Du kan minska den här risken i ett företagsnätverk genom att genomföra starka fysiska säkerhetsåtgärder för att skydda nätverksinfrastrukturen. IpSec-autentiseringshuvudläge (Internet Protocol Security) kan förhindra man-in-the-middle-attacker. Autentiseringshuvudläge utför ömsesidig autentisering och paketintegritet för IP-trafik.

    4. Orsaker till att inaktivera den här inställningen

      • Klienter som inte stöder LDAP-signering kan inte utföra LDAP-frågor mot domänkontrollanter och globala kataloger om NTLM-autentisering förhandlas fram och om rätt Service Pack inte installeras på Windows 2000-domänkontrollanter.

      • Nätverksspårningar av LDAP-trafik mellan klienter och servrar krypteras. Det gör det svårt att undersöka LDAP-konversationer.

      • Windows 2000-baserade servrar måste ha Windows 2000 Service Pack 3 (SP3) eller installeras när de administreras med program som stöder LDAP-signering som körs från klientdatorer som kör Windows 2000 SP4, Windows XP eller Windows Server 2003.  

    5. Symboliskt namn:

      LDAPServerIntegrity

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

    7. Exempel på kompatibilitetsproblem

      • Enkla bindningar misslyckas och du får följande felmeddelande:

        Ldap_simple_bind_s() misslyckades: Stark autentisering krävs.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter som kör Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg korrekt mot domänkontrollanter som kör versioner av Windows 2000 som är tidigare än SP3 när NTLM-autentisering förhandlas fram.

         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter som kör Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg som riktar sig till domänkontrollanter som kör tidigare versioner av Windows 2000 än SP3 om de använder IP-adresser (till exempel "dsa.msc /server=x.x.x.x" där
        x.x.x.x är en IP-adress).


         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter som kör Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg som riktar sig till domänkontrollanter som kör tidigare versioner av Windows 2000 än SP3.

         

  3. Domänmedlem: Kräv stark (Windows 2000 eller senare) sessionsnyckel

    1. Bakgrund

      • Domänmedlem: Kräver stark (Windows 2000 eller senare) sessionsnyckelinställning avgör om en säker kanal kan upprättas med en domänkontrollant som inte kan kryptera säker kanaltrafik med en stark 128-bitars sessionsnyckel. Om du aktiverar den här inställningen förhindras etablering av en säker kanal med domänkontrollanter som inte kan kryptera säkra kanaldata med en stark nyckel. Om du inaktiverar den här inställningen tillåts 64-bitars sessionstangenter.

      • Innan du kan aktivera den här inställningen på en medlemsarbetsstation eller på en server måste alla domänkontrollanter i den domän som medlemmen tillhör kunna kryptera säkra kanaldata med en stark 128-bitarsnyckel. Det innebär att alla sådana domänkontrollanter måste köra Windows 2000 eller senare.

    2. Riskabla konfigurationer

      Aktivera domänmedlemmen: Kräv stark (Windows 2000 eller senare) sessionsnyckelinställning är en skadlig konfigurationsinställning.

    3. Orsaker till att aktivera den här inställningen

      • Sessionsnycklar som används för att upprätta säker kanalkommunikation mellan medlemsdatorer och domänkontrollanter är mycket starkare i Windows 2000 än i tidigare versioner av Microsoft-operativsystem.

      • När det är möjligt är det en bra idé att dra nytta av dessa starkare sessionsnycklar för att skydda säker kanalkommunikation från avlyssning och från sessionskapning av nätverksattacker. Avlyssning är en form av skadlig attack där nätverksdata läses upp eller ändras under överföringen. Data kan ändras för att dölja eller ändra avsändaren eller för att omdirigera dem.

      Viktigt! En dator med Windows Server 2008 R2 eller Windows 7 stöder endast starka nycklar när säkra kanaler används. Den här begränsningen förhindrar ett förtroende mellan alla Windows NT 4.0-baserade domäner och alla Windows Server 2008 R2-baserade domäner. Den här begränsningen blockerar dessutom det Windows NT 4.0-baserade domänmedlemskapet för datorer som kör Windows 7 eller Windows Server 2008 R2, och vice versa.

    4. Orsaker till att inaktivera den här inställningen

      Domänen innehåller andra medlemsdatorer som kör andra operativsystem än Windows 2000, Windows XP eller Windows Server 2003.

    5. Symboliskt namn:

      StrongKey

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

    7. Exempel på kompatibilitetsproblem

      Windows NT 4.0: På Windows NT 4.0-baserade datorer går det inte att återställa säkra kanaler med förtroenderelationer mellan Windows NT 4.0- och Windows 2000-domäner med NLTEST. Felmeddelandet "Åtkomst nekad" visas:

      Förtroenderelationen mellan den primära domänen och den betrodda domänen misslyckades.

      Windows 7 och Server 2008 R2: För Windows 7 och senare versioner och Windows Server 2008 R2 och senare versioner används inte den här inställningen längre och den starka nyckeln används alltid. Därför fungerar inte förtroenden med Windows NT 4.0-domäner längre.

  4. Domänmedlem: Kryptera eller signera data om säker kanal digitalt (alltid)

    1. Bakgrund

      • Aktivera Domänmedlem: Kryptera eller signera data för säker kanal digitalt (alltid) förhindrar att en säker kanal upprättas med domänkontrollanter som inte kan signera eller kryptera alla säkra kanaldata. För att skydda autentiseringstrafik från man-in-the-middle-attacker, uppspelningsattacker och andra typer av nätverksattacker skapar Windows-baserade datorer en kommunikationskanal som kallas en säker kanal via tjänsten Net Logon för att autentisera datorkonton. Säkra kanaler används också när en användare i en domän ansluter till en nätverksresurs i en fjärrdomän. Med den här multidomänautentiseringen, eller direktautentiseringen, kan en Windows-baserad dator som har anslutit till en domän ha åtkomst till användarkontodatabasen i sin domän och i alla betrodda domäner.

      • Så här aktiverar du domänmedlemmen: Kryptera eller signera data om säker kanal (alltid) digitalt på en medlemsdator. Alla domänkontrollanter i den domän som medlemmen tillhör måste kunna signera eller kryptera alla säkra kanaldata. Det innebär att alla sådana domänkontrollanter måste köra Windows NT 4.0 med Service Pack 6a (SP6a) eller senare.

      • Aktivering av domänmedlemmen: Inställningen Kryptera eller signera data om säker kanal (alltid) digitalt aktiverar domänmedlemmen: Kryptera eller signera data om säker kanal (om möjligt).

    2. Riskabla konfigurationer

      Aktivera domänmedlemmen: Kryptera eller signera data om säker kanal digitalt (alltid) i domäner där inte alla domänkontrollanter kan signera eller kryptera säkra kanaldata är en skadlig konfigurationsinställning.

    3. Orsaker till att aktivera den här inställningen

      Osignerad nätverkstrafik är mottaglig för man-i-mitten-attacker, där en inkräktare fångar paket mellan servern och klienten och sedan ändrar dem innan de vidarebefordras till klienten. När det här beteendet inträffar på en LDAP-server (Lightweight Directory Access Protocol) kan inkräktaren orsaka att en klient fattar beslut som baseras på falska poster från LDAP-katalogen. Du kan minska risken för en sådan attack på ett företagsnätverk genom att genomföra starka fysiska säkerhetsåtgärder för att skydda nätverksinfrastrukturen. Om du implementerar IPSec-autentiseringshuvudläge (Internet Protocol Security) kan det dessutom förhindra man-i-mitten-attacker. Det här läget utför ömsesidig autentisering och paketintegritet för IP-trafik.

    4. Orsaker till att inaktivera den här inställningen

      • Datorer i lokala eller externa domäner stöder krypterade säkra kanaler.

      • Alla domänkontrollanter i domänen har inte rätt service pack-revisionsnivåer för att stödja krypterade säkra kanaler.

    5. Symboliskt namn:

      StrongKey

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

    7. Exempel på kompatibilitetsproblem

      • Windows NT 4.0: Windows 2000-baserade medlemsdatorer kan inte ansluta till Windows NT 4.0-domäner och får följande felmeddelande:

        Kontot har inte behörighet att logga in från den här stationen.

        Om du vill ha mer information klickar du på följande artikelnummer för att visa artikeln i Microsoft Knowledge Base:

        281648 Felmeddelande: Kontot har inte behörighet att logga in från den här stationen
         

      • Windows NT 4.0: Windows NT 4.0-domäner kan inte upprätta ett förtroende på nedåtnivå med en Windows 2000-domän och får följande felmeddelande:

        Kontot har inte behörighet att logga in från den här stationen.

        Befintliga förtroenden på låg nivå kanske inte heller autentiserar användare från den betrodda domänen. Vissa användare kan ha problem med att logga in på domänen och de kan få ett felmeddelande om att klienten inte kan hitta domänen.

      • Windows XP: Windows XP-klienter som är anslutna till Windows NT 4.0-domäner kan inte autentisera inloggningsförsök och kan få följande felmeddelande, eller så kan följande händelser registreras i händelseloggen:

        Windows kan inte ansluta till domänen antingen på grund av att domänkontrollanten är nere eller inte är tillgänglig på annat sätt eller på grund av att datorkontot inte hittades

      • Microsoft Network: Microsoft Network-klienter får något av följande felmeddelanden:

        Inloggningsfel: okänt användarnamn eller felaktigt lösenord.

        Det finns ingen användarsessionsnyckel för den angivna inloggningssessionen.

  5. Microsoft-nätverksklient: Signera kommunikation digitalt (alltid)

    1. Bakgrund

      Server Message Block (SMB) är det resursdelningsprotokoll som stöds av många Microsoft-operativsystem. Det är grunden för netBIOS (Network Basic Input/Output System) och många andra protokoll. SMB-signering autentiserar både användaren och servern som är värd för data. Om autentiseringsprocessen misslyckas på båda sidor sker ingen dataöverföring.

      Aktivering av SMB-signering startar under SMB-protokollförhandlingar. SMB-signeringsprinciperna avgör om datorn alltid signerar klientkommunikation digitalt.

      Windows 2000 SMB-autentiseringsprotokollet stöder ömsesidig autentisering. Ömsesidig autentisering stänger en "man-i-mitten"-attack. Autentiseringsprotokollet för Windows 2000 SMB har också stöd för meddelandeautentisering. Meddelandeautentisering hjälper till att förhindra aktiva meddelandeattacker. För att ge dig den här autentiseringen lägger SMB-signeringen till en digital signatur i varje SMB. Klienten och servern verifierar var och en den digitala signaturen.

      Om du vill använda SMB-signering måste du aktivera SMB-signering eller kräva SMB-signering på både SMB-klienten och SMB-servern. Om SMB-signering är aktiverat på en server använder klienter som också är aktiverade för SMB-signering protokollet för paketsignering under alla efterföljande sessioner. Om SMB-signering krävs på en server kan en klient inte upprätta en session om inte klienten är aktiverad eller krävs för SMB-signering.


      Genom att aktivera digital inloggning i högsäkerhetsnätverk kan du förhindra att klienter och servrar personifieras. Denna typ av imitation kallas session kapning. En angripare som har åtkomst till samma nätverk som klienten eller servern använder verktyg för sessionskapning för att avbryta, avsluta eller stjäla en pågående session. En angripare kan avlyssna och ändra osignerade SMB-paket, ändra trafiken och sedan vidarebefordra det så att servern kan utföra oönskade åtgärder. Eller så kan angriparen utgöra servern eller som klienten efter en legitim autentisering och sedan få obehörig åtkomst till data.

      SMB-protokollet som används för fildelning och för utskriftsdelning på datorer med Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003 har stöd för ömsesidig autentisering. Ömsesidig autentisering stänger sessionskapningsattacker och stöder meddelandeautentisering. Därför förhindrar det man-i-mitten-attacker. SMB-signering ger den här autentiseringen genom att placera en digital signatur i varje SMB. Klienten och servern verifierar signaturen.

      Anteckningar

      • Som en alternativ motåtgärd kan du aktivera digitala signaturer med IPSec för att skydda all nätverkstrafik. Det finns maskinvarubaserade acceleratorer för IPSec-kryptering och signering som du kan använda för att minimera prestandapåverkan från serverns PROCESSOR. Det finns inga sådana acceleratorer som är tillgängliga för SMB-signering.

        Mer information finns i kapitlet Signera serverkommunikation digitalt på Microsoft MSDN-webbplatsen.

        Konfigurera SMB-signering via grupprincip objektredigeraren eftersom en ändring av ett lokalt registervärde inte har någon effekt om det finns en åsidosättande domänprincip.

      • I Windows 95, Windows 98 och Windows 98 Second Edition använder Directory Services-klienten SMB-signering när den autentiseras med Windows Server 2003-servrar med NTLM-autentisering. Men dessa klienter använder inte SMB-signering när de autentiseras med dessa servrar med NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsförfrågningar från dessa klienter. Mer information finns i objekt 10: "Nätverkssäkerhet: Lan Manager-autentiseringsnivå."

    2. Riskabla konfigurationer

      Följande är en skadlig konfigurationsinställning: Lämnar både Microsoft-nätverksklienten: Signera kommunikation (alltid) digitalt och Microsoft-nätverksklienten: Inställningen Signera kommunikation (om servern godkänner) är inställd på "Ej definierad" eller inaktiverad. Med de här inställningarna kan omdirigeringen skicka oformaterade textlösenord till icke-Microsoft SMB-servrar som inte stöder lösenordskryptering under autentisering.

    3. Orsaker till att aktivera den här inställningen

      Aktivera Microsoft-nätverksklient: Signera kommunikation digitalt (alltid) kräver att klienter signerar SMB-trafik när de kontaktar servrar som inte kräver SMB-signering. Detta gör klienter mindre sårbara för sessionskapningsattacker.

    4. Orsaker till att inaktivera den här inställningen

      • Aktivera Microsoft-nätverksklient: Signera kommunikation digitalt (alltid) hindrar klienter från att kommunicera med målservrar som inte stöder SMB-signering.

      • Om du konfigurerar datorer för att ignorera all osignerad SMB-kommunikation förhindras tidigare program och operativsystem från att ansluta.

    5. Symboliskt namn:

      KrävSMBSignRdr

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

    7. Exempel på kompatibilitetsproblem

      • Windows NT 4.0: Du kan inte återställa den säkra kanalen för ett förtroende mellan en Windows Server 2003-domän och en Windows NT 4.0-domän med hjälp av NLTEST eller NETDOM, och du får felmeddelandet "Åtkomst nekad".

      • Windows XP: Det kan ta längre tid att kopiera filer från Windows XP-klienter till Windows 2000-baserade servrar och till Windows Server 2003-baserade servrar.

      • Du kommer inte att kunna mappa en nätverksenhet från en klient med den här inställningen aktiverad, och du får följande felmeddelande:

        Kontot har inte behörighet att logga in från den här stationen.



    8. Krav för omstart Starta om datorn eller starta om workstation-tjänsten. Det gör du genom att skriva följande kommandon i en kommandotolk. Tryck på Retur när du har skrivit varje kommando.

      net stop workstation
      net start workstation

  6. Microsoft-nätverksserver: Signera kommunikation digitalt (alltid)

    1. Bakgrund

      • Server Messenger Block (SMB) är det resursdelningsprotokoll som stöds av många Microsoft-operativsystem. Det är grunden för netBIOS (Network Basic Input/Output System) och många andra protokoll. SMB-signering autentiserar både användaren och servern som är värd för data. Om autentiseringsprocessen misslyckas på båda sidor sker ingen dataöverföring.

        Aktivering av SMB-signering startar under SMB-protokollförhandlingar. SMB-signeringsprinciperna avgör om datorn alltid signerar klientkommunikation digitalt.

        Windows 2000 SMB-autentiseringsprotokollet stöder ömsesidig autentisering. Ömsesidig autentisering stänger en "man-i-mitten"-attack. Autentiseringsprotokollet för Windows 2000 SMB har också stöd för meddelandeautentisering. Meddelandeautentisering hjälper till att förhindra aktiva meddelandeattacker. För att ge dig den här autentiseringen lägger SMB-signeringen till en digital signatur i varje SMB. Klienten och servern verifierar var och en den digitala signaturen.

        Om du vill använda SMB-signering måste du aktivera SMB-signering eller kräva SMB-signering på både SMB-klienten och SMB-servern. Om SMB-signering är aktiverat på en server använder klienter som också är aktiverade för SMB-signering protokollet för paketsignering under alla efterföljande sessioner. Om SMB-signering krävs på en server kan en klient inte upprätta en session om inte klienten är aktiverad eller krävs för SMB-signering.


        Genom att aktivera digital inloggning i högsäkerhetsnätverk kan du förhindra att klienter och servrar personifieras. Denna typ av imitation kallas session kapning. En angripare som har åtkomst till samma nätverk som klienten eller servern använder verktyg för sessionskapning för att avbryta, avsluta eller stjäla en pågående session. En angripare kan avlyssna och ändra Osignerade SBM-paket (Subnet Bandwidth Manager), ändra trafiken och sedan vidarebefordra den så att servern kan utföra oönskade åtgärder. Eller så kan angriparen utgöra servern eller som klienten efter en legitim autentisering och sedan få obehörig åtkomst till data.

        SMB-protokollet som används för fildelning och för utskriftsdelning på datorer med Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003 har stöd för ömsesidig autentisering. Ömsesidig autentisering stänger sessionskapningsattacker och stöder meddelandeautentisering. Därför förhindrar det man-i-mitten-attacker. SMB-signering ger den här autentiseringen genom att placera en digital signatur i varje SMB. Klienten och servern verifierar signaturen.

      • Som en alternativ motåtgärd kan du aktivera digitala signaturer med IPSec för att skydda all nätverkstrafik. Det finns maskinvarubaserade acceleratorer för IPSec-kryptering och signering som du kan använda för att minimera prestandapåverkan från serverns PROCESSOR. Det finns inga sådana acceleratorer som är tillgängliga för SMB-signering.

      • I Windows 95, Windows 98 och Windows 98 Second Edition använder Directory Services-klienten SMB-signering när den autentiseras med Windows Server 2003-servrar med NTLM-autentisering. Men dessa klienter använder inte SMB-signering när de autentiseras med dessa servrar med NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsförfrågningar från dessa klienter. Mer information finns i objekt 10: "Nätverkssäkerhet: Lan Manager-autentiseringsnivå."

    2. Riskabla konfigurationer

      Följande är en skadlig konfigurationsinställning: Aktivera Microsofts nätverksserver: Signera kommunikation (alltid) digitalt på servrar och domänkontrollanter som nås av inkompatibla Windows-baserade datorer och tredjepartsoperativsystembaserade klientdatorer i lokala eller externa domäner.

    3. Orsaker till att aktivera den här inställningen

      • Alla klientdatorer som aktiverar den här inställningen direkt via registret eller via grupprincip-inställningen har stöd för SMB-signering. Med andra ord kör alla klientdatorer som har den här inställningen aktiverad Antingen Windows 95 med DS-klienten installerad, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional eller Windows Server 2003.

      • Om Microsofts nätverksserver: Signera kommunikation digitalt (alltid) är inaktiverad, är SMB-signering helt inaktiverad. Att helt inaktivera all SMB-signering gör datorer mer sårbara för sessionskapningsattacker.

    4. Orsaker till att inaktivera den här inställningen

      • Om du aktiverar den här inställningen kan filkopiering och nätverksprestanda bli långsammare på klientdatorer.

      • Aktivering av den här inställningen förhindrar att klienter som inte kan förhandla om SMB-signering kommunicerar med servrar och med domänkontrollanter. Det gör att åtgärder som domänanslutningar, användar- och datorautentisering eller nätverksåtkomst för program misslyckas.

    5. Symboliskt namn:

      KrävSMBSignServer

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

    7. Exempel på kompatibilitetsproblem

      • Windows 95: Windows 95-klienter som inte har DS-klienten installerad misslyckas inloggningsautentiseringen och får följande felmeddelande:

        Domänlösenordet du angav är inte korrekt eller åtkomst till inloggningsservern har nekats.

      • Windows NT 4.0: Klientdatorer som kör versioner av Windows NT 4.0 som är tidigare än Service Pack 3 (SP3) misslyckas med inloggningsautentiseringen och får följande felmeddelande:

        Det gick inte att logga in dig. Kontrollera att användarnamnet och domänen är korrekta och skriv sedan lösenordet igen.

        Vissa SMB-servrar som inte kommer från Microsoft stöder endast okrypterade lösenordsutbyten under autentiseringen. (Dessa utbyten kallas även för "oformaterad text".) För Windows NT 4.0 SP3 och senare versioner skickar SMB-omdirigeringen inte ett okrypterat lösenord under autentiseringen till en SMB-server om du inte lägger till en specifik registerpost.
        Om du vill aktivera okrypterade lösenord för SMB-klienten i Windows NT 4.0 SP 3 och nyare system ändrar du registret på följande sätt: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

        Värdenamn: EnablePlainTextPassword

        Datatyp: REG_DWORD

        Data: 1

         

      • Windows Server 2003: Som standard är säkerhetsinställningarna för domänkontrollanter som kör Windows Server 2003 konfigurerade för att förhindra att kommunikation med domänkontrollanter avlyssnas eller manipuleras av skadliga användare. För att användare ska kunna kommunicera med en domänkontrollant som kör Windows Server 2003 måste klientdatorerna använda både SMB-signering och kryptering eller säker kanaltrafiksignering. Som standard har klienter som kör Windows NT 4.0 med Service Pack 2 (SP2) eller tidigare installerat och klienter som kör Windows 95 inte SMB-paketsignering aktiverat. Därför kanske dessa klienter inte kan autentiseras mot en Windows Server 2003-baserad domänkontrollant.

      • Principinställningar för Windows 2000 och Windows Server 2003: Beroende på dina specifika installationsbehov och konfiguration rekommenderar vi att du anger följande principinställningar på den lägsta enheten av nödvändig omfattning i snapin-modulhierarkin för Microsoft Management Console grupprincip Editor:

        • Datorkonfiguration\Windows-säkerhet Inställningar\Säkerhetsalternativ

        • Skicka okrypterat lösenord för att ansluta till SMB-servrar från tredje part (den här inställningen gäller för Windows 2000)

        • Microsoft-nätverksklient: Skicka okrypterat lösenord till SMB-servrar från tredje part (den här inställningen är för Windows Server 2003)


        Obs! På vissa CIFS-servrar från tredje part, till exempel äldre Samba-versioner, kan du inte använda krypterade lösenord.

      • Följande klienter är inkompatibla med Microsofts nätverksserver: Inställningen Signera kommunikation (alltid) digitalt:

        • Apple Computer, Inc., Mac OS X-klienter

        • Microsoft MS-DOS-nätverksklienter (till exempel Microsoft LAN Manager)

        • Microsoft Windows för arbetsgruppsklienter

        • Microsoft Windows 95-klienter utan DS-klienten installerad

        • Microsoft Windows NT 4.0-baserade datorer utan SP3 eller senare installerade

        • Novell Netware 6 CIFS-klienter

        • SAMBA SMB-klienter som inte har stöd för SMB-signering



    8. Krav för omstart Starta om datorn eller starta om servertjänsten. Det gör du genom att skriva följande kommandon i en kommandotolk. Tryck på Retur när du har skrivit varje kommando.

      net stop server
      net start server

  7. Nätverksåtkomst: Tillåt anonym SID/namnöversättning

    1. Bakgrund

      Nätverksåtkomst: Tillåt säkerhetsinställningen för anonym SID/namnöversättning avgör om en anonym användare kan begära SID-attribut (Security Identification Number) för en annan användare.

    2. Riskabla konfigurationer

      Aktivera nätverksåtkomst: Tillåt anonym SID/namnöversättning är en skadlig konfigurationsinställning.

    3. Orsaker till att aktivera den här inställningen

      Om inställningen Nätverksåtkomst: Tillåt anonym SID/Namn-översättning är inaktiverad kanske tidigare operativsystem eller program inte kan kommunicera med Windows Server 2003-domäner. Följande operativsystem, tjänster eller program kanske inte fungerar:

      • Windows NT 4.0-baserade fjärråtkomsttjänstservrar

      • Microsoft SQL Server som körs på Windows NT 3.x-baserade datorer eller Windows NT 4.0-baserade datorer

      • Fjärråtkomsttjänst som körs på Windows 2000-baserade datorer som finns i Windows NT 3.x-domäner eller Windows NT 4.0-domäner

      • SQL Server som körs på Windows 2000-baserade datorer som finns i Windows NT 3.x-domäner eller i Windows NT 4.0-domäner

      • Användare i Windows NT 4.0-resursdomän som vill ge behörighet till filer, delade mappar och registerobjekt till användarkonton från kontodomäner som innehåller Windows Server 2003-domänkontrollanter

    4. Orsaker till att inaktivera den här inställningen

      Om den här inställningen är aktiverad kan en illvillig användare använda det välkända SID-administratörssidan för att hämta det inbyggda administratörskontots riktiga namn, även om kontot har bytt namn. Den personen kan sedan använda kontonamnet för att initiera en attack med lösenords gissa.

    5. Symboliskt namn: SAKNAS

    6. Registersökväg: Ingen. Sökvägen anges i användargränssnittskoden.

    7. Exempel på kompatibilitetsproblem

      Windows NT 4.0: Datorer i Windows NT 4.0-resursdomäner visar felmeddelandet "Konto okänt" i ACL-redigeraren om resurser, inklusive delade mappar, delade filer och registerobjekt, skyddas med säkerhetsobjekt som finns i kontodomäner som innehåller Windows Server 2003-domänkontrollanter.

  8. Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton

    1. Bakgrund

      • Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton avgör vilka ytterligare behörigheter som ska beviljas för anonyma anslutningar till datorn. Med Windows kan anonyma användare utföra vissa aktiviteter, till exempel numrera namnen på arbetsstations- och server sam-konton (Security Accounts Manager) och nätverksresurser. En administratör kan till exempel använda detta för att ge åtkomst till användare i en betrodd domän som inte har ett ömsesidigt förtroende. När en session har gjorts kan en anonym användare ha samma åtkomst som tilldelas gruppen Alla baserat på inställningen i Nätverksåtkomst: Låt alla behörigheter gälla för inställningen för anonyma användare eller objektets godtyckliga åtkomstkontrollista (DACL).

        Vanligtvis begärs anonyma anslutningar av tidigare versioner av klienter (klienter på låg nivå) under konfigurationen av SMB-sessionen. I sådana fall visar en nätverksspårning att SMB-process-ID (PID) är klientomdirigeraren, till exempel 0xFEFF i Windows 2000 eller 0xCAFE i Windows NT. RPC kan också försöka göra anonyma anslutningar.

      • Viktigt Den här inställningen påverkar inte domänkontrollanterna. På domänkontrollanter styrs det här beteendet av förekomsten av "NT AUTHORITY\ANONYMOUS LOGON" i "Pre-Windows 2000 compatible Access".

      • I Windows 2000 hanterar en liknande inställning som kallas Ytterligare begränsningar för anonyma anslutningar registervärdet RestrictAnonymous . Placeringen av det här värdet är enligt följande:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

    2. Riskfyllda konfigurationer

      Aktivera nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton är en skadlig konfigurationsinställning ur ett kompatibilitetsperspektiv. Att inaktivera det är en skadlig konfigurationsinställning ur ett säkerhetsperspektiv.

    3. Orsaker till att aktivera den här inställningen

      En obehörig användare kan anonymt lista kontonamn och sedan använda informationen för att försöka gissa lösenord eller utföra social engineering-attacker. Social ingenjörskonst är jargong som innebär att lura människor att avslöja sina lösenord eller någon form av säkerhetsinformation.

    4. Orsaker till att inaktivera den här inställningen

      Om den här inställningen är aktiverad är det omöjligt att upprätta förtroenden med Windows NT 4.0-domäner. Den här inställningen orsakar också problem med klienter på låg nivå (till exempel Windows NT 3.51-klienter och Windows 95-klienter) som försöker använda resurser på servern.

    5. Symboliskt namn:


      RestrictAnonymousSAM

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

    7. Exempel på kompatibilitetsproblem

    • SMS Network Discovery kommer inte att kunna hämta information om operativsystemet och skriver "Unknown" i egenskapen OperatingSystemNameandVersion.

    • Windows 95, Windows 98: Windows 95-klienter och Windows 98-klienter kan inte ändra sina lösenord.

    • Windows NT 4.0: Windows NT 4.0-baserade medlemsdatorer kan inte autentiseras.

    • Windows 95, Windows 98: Windows 95-baserade och Windows 98-baserade datorer kan inte autentiseras av Microsofts domänkontrollanter.

    • Windows 95, Windows 98: Användare på Windows 95- och Windows 98-baserade datorer kan inte ändra lösenorden för sina användarkonton.

  9. Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och -resurser

    1. Bakgrund

      • Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och -resurser (kallas även RestrictAnonymous) avgör om anonym uppräkning av SAM-konton och -resurser (Security Accounts Manager) är tillåten. Med Windows kan anonyma användare utföra vissa aktiviteter, till exempel numrera namnen på domänkonton (användare, datorer och grupper) och nätverksresurser. Det här är till exempel praktiskt när en administratör vill bevilja åtkomst till användare i en betrodd domän som inte har ett ömsesidigt förtroende. Om du inte vill tillåta anonym uppräkning av SAM-konton och resurser aktiverar du den här inställningen.

      • I Windows 2000 hanterar en liknande inställning som kallas Ytterligare begränsningar för anonyma anslutningar registervärdet RestrictAnonymous . Placeringen av det här värdet är följande:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

    2. Riskabla konfigurationer

      Aktivera nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och delningsinställningar är en skadlig konfigurationsinställning.

    3. Orsaker till att aktivera den här inställningen

      • Aktivera nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och -resurser förhindrar uppräkning av SAM-konton och -resurser av användare och datorer som använder anonyma konton.

    4. Orsaker till att inaktivera den här inställningen

      • Om den här inställningen är aktiverad kan en obehörig användare anonymt lista kontonamn och sedan använda informationen för att försöka gissa lösenord eller utföra social engineering-attacker. Social ingenjörskonst är jargong som innebär att lura människor att avslöja sitt lösenord eller någon form av säkerhetsinformation.

      • Om den här inställningen är aktiverad går det inte att upprätta förtroenden med Windows NT 4.0-domäner. Den här inställningen orsakar också problem med klienter på låg nivå, till exempel Windows NT 3.51- och Windows 95-klienter som försöker använda resurser på servern.

      • Det blir omöjligt att bevilja åtkomst till användare av resursdomäner eftersom administratörer i den betrodda domänen inte kommer att kunna räkna upp listor med konton i den andra domänen. Användare som öppnar fil- och utskriftsservrar anonymt kommer inte att kunna lista delade nätverksresurser på dessa servrar. Användarna måste autentisera innan de kan visa listorna med delade mappar och skrivare.

    5. Symboliskt namn:

      Restrictanonymous

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

    7. Exempel på kompatibilitetsproblem

      • Windows NT 4.0: Användarna kan inte ändra sina lösenord från Windows NT 4.0-arbetsstationer när RestrictAnonymous är aktiverat på domänkontrollanter i användarnas domän.

      • Windows NT 4.0: Det går inte att lägga till användare eller globala grupper från betrodda Windows 2000-domäner i lokala Windows NT 4.0-grupper i Användarhanteraren och följande felmeddelande visas:

        Det finns för närvarande inga inloggningsservrar tillgängliga för service av inloggningsbegäran.

      • Windows NT 4.0: Windows NT 4.0-baserade datorer kan inte ansluta till domäner under installationen eller genom att använda användargränssnittet för domänanslutning.

      • Windows NT 4.0: Det går inte att upprätta ett förtroende på låg nivå med Windows NT 4.0-resursdomäner. Följande felmeddelande visas när RestrictAnonymous är aktiverat på den betrodda domänen:

        Det gick inte att hitta domänkontrollanten för den här domänen.

      • Windows NT 4.0: Användare som loggar in på Windows NT 4.0-baserade Terminal Server-datorer mappas till standardkatalogen i stället för den hemkatalog som definieras i Användarhanteraren för domäner.

      • Windows NT 4.0: Windows NT 4.0-domänkontrollanter (BDCs) kan inte starta tjänsten Net Logon, hämta en lista över säkerhetskopierade webbläsare eller synkronisera SAM-databasen från Windows 2000 eller från Windows Server 2003-domänkontrollanter i samma domän.

      • Windows 2000: Windows 2000-baserade medlemsdatorer i Windows NT 4.0-domäner kan inte visa skrivare i externa domäner om inställningen Ingen åtkomst utan explicit anonym behörighet är aktiverad i klientdatorns lokala säkerhetsprincip.

      • Windows 2000: Windows 2000-domänanvändare kan inte lägga till nätverksskrivare från Active Directory. Men de kan lägga till skrivare när de har valt dem i trädvyn.

      • Windows 2000: På Windows 2000-baserade datorer kan ACL-redigeraren inte lägga till användare eller globala grupper från betrodda Windows NT 4.0-domäner.

      • ADMT version 2: Lösenordsmigrering för användarkonton som migreras mellan skogar med Active Directory Migration Tool (ADMT) version 2 misslyckas.

        Om du vill ha mer information klickar du på följande artikelnummer för att visa artikeln i Microsoft Knowledge Base:

        322981 Felsöka lösenordsmigrering mellan skogar med ADMTv2

      • Outlook-klienter: Den globala adresslistan visas tom för Microsoft Exchange Outlook-klienter.

      • SMS: Microsoft Systems Management Server (SMS) Network Discovery kan inte hämta information om operativsystemet. Därför skrivs "Okänt" i egenskapen OperatingSystemNameandVersion för SMS DDR-egenskapen för dataposten (DDR).

      • SMS: När du använder användarguiden för SMS-administratör för att bläddra efter användare och grupper visas inga användare eller grupper. Dessutom kan avancerade klienter inte kommunicera med hanteringspunkten. Anonym åtkomst krävs på hanteringspunkten.

      • SMS: När du använder nätverksidentifieringsfunktionen i SMS 2.0 och i installation av fjärrklient med alternativet Topologi, klient och klientoperativsystem för nätverksidentifiering aktiverat, kan datorer upptäckas men kanske inte installeras.

  10. Nätverkssäkerhet: Lan Manager-autentiseringsnivå

    1. Bakgrund

      LAN Manager-autentisering (LM) är det protokoll som används för att autentisera Windows-klienter för nätverksåtgärder, inklusive domänanslutningar, åtkomst till nätverksresurser och användar- eller datorautentisering. LM-autentiseringsnivån avgör vilket protokoll för autentisering av utmaning/svar som förhandlas fram mellan klienten och serverdatorerna. Mer specifikt avgör LM-autentiseringsnivån vilka autentiseringsprotokoll som klienten ska försöka förhandla om eller som servern accepterar. Värdet som anges för LmCompatibilityLevel avgör vilket protokoll för autentisering av utmaning/svar som används för nätverksanloggningar. Det här värdet påverkar nivån på autentiseringsprotokollet som klienter använder, vilken nivå av sessionssäkerhet som förhandlats fram och vilken autentiseringsnivå som accepteras av servrar.

      Exempel på möjliga inställningar:

      Värde

      Inställning

      Beskrivning

      0

      Skicka LM & NTLM-svar

      Klienter använder LM- och NTLM-autentisering och använder aldrig NTLMv2-sessionssäkerhet. Domänkontrollanter accepterar LM-, NTLM- och NTLMv2-autentisering.

      1

      Skicka LM & NTLM – använd NTLMv2-sessionssäkerhet om det förhandlas fram

      Klienter använder LM- och NTLM-autentisering och använder NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter accepterar LM-, NTLM- och NTLMv2-autentisering.

      2

      Skicka endast NTLM-svar

      Klienter använder endast NTLM-autentisering och NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter accepterar LM-, NTLM- och NTLMv2-autentisering.

      3

      Skicka endast NTLMv2-svar

      Klienter använder endast NTLMv2-autentisering och NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter accepterar LM-, NTLM- och NTLMv2-autentisering.

      4

      Skicka endast NTLMv2-svar/vägra LM

      Klienter använder endast NTLMv2-autentisering och NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter avvisar LM och accepterar endast NTLM- och NTLMv2-autentisering.

      5

      Skicka endast NTLMv2-svar/vägra LM-& NTLM

      Klienter använder endast NTLMv2-autentisering och NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter avvisar LM och NTLM och accepterar endast NTLMv2-autentisering.

      Obs! I Windows 95, Windows 98 och Windows 98 Second Edition använder Directory Services-klienten SMB-signering när den autentiseras med Windows Server 2003-servrar med NTLM-autentisering. Men dessa klienter använder inte SMB-signering när de autentiseras med dessa servrar med NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsförfrågningar från dessa klienter.

      Kontrollera LM-autentiseringsnivån: Du måste ändra principen på servern för att tillåta NTLM, eller så måste du konfigurera klientdatorn så att den stöder NTLMv2.

      Om principen är inställd på (5) Skicka endast NTLMv2-svar\vägra LM-& NTLM på måldatorn som du vill ansluta till måste du antingen sänka inställningen på den datorn eller ställa in säkerheten på samma inställning som finns på källdatorn som du ansluter från.

      Hitta rätt plats där du kan ändra autentiseringsnivån för LAN-hanteraren för att ställa in klienten och servern på samma nivå. När du har hittat principen som anger autentiseringsnivån för LAN-hanteraren, om du vill ansluta till och från datorer som kör tidigare versioner av Windows, sänker du värdet till minst (1) Skicka LM-& NTLM – använd NTLM version 2-sessionssäkerhet om du förhandlar om det. En effekt av inkompatibla inställningar är att om servern kräver NTLMv2 (värde 5), men klienten är konfigurerad att endast använda LM och NTLMv1 (värde 0), upplever användaren som försöker autentisering ett inloggningsfel som har ett felaktigt lösenord och som ökar antalet felaktiga lösenord. Om kontolåsning har konfigurerats kan användaren så småningom bli utelåst.

      Du kan till exempel behöva titta på domänkontrollanten, eller så kan du behöva granska domänkontrollantens principer.

      Titta på domänkontrollanten

      Obs! Du kan behöva upprepa följande procedur för alla domänkontrollanter.

      1. Klicka på Start, peka på Program och klicka sedan på Administrationsverktyg.

      2. Under Lokala säkerhetsinställningar expanderar du Lokala principer.

      3. Klicka på Säkerhetsalternativ.

      4. Dubbelklicka på Nätverkssäkerhet: autentiseringsnivå för LAN-hanterare och klicka sedan på ett värde i listan.


      Om gällande inställning och lokal inställning är desamma har principen ändrats på den här nivån. Om inställningarna skiljer sig åt måste du kontrollera domänkontrollantens princip för att avgöra om inställningen för autentiseringsnivå för nätverkssäkerhet: LAN-hanterare har definierats där. Om den inte är definierad där kan du undersöka domänkontrollantens principer.

      Granska domänkontrollantens principer

      1. Klicka på Start, peka på Program och klicka sedan på Administrationsverktyg.

      2. I domänkontrollantens säkerhetsprincip expanderar du Säkerhetsinställningar och expanderar sedan Lokala principer.

      3. Klicka på Säkerhetsalternativ.

      4. Dubbelklicka på Nätverkssäkerhet: autentiseringsnivå för LAN-hanterare och klicka sedan på ett värde i listan.


      Observera

      • Du kan också behöva kontrollera principer som är länkade på webbplatsnivå, domännivå eller organisationsenhetsnivå för att avgöra var du måste konfigurera autentiseringsnivån för LAN-chefen.

      • Om du implementerar en grupprincip inställning som standarddomänprincip tillämpas principen på alla datorer i domänen.

      • Om du implementerar en grupprincip inställning som standardprincip för domänkontrollanten gäller principen endast servrarna i domänkontrollantens OU.

      • Det är en bra idé att ange autentiseringsnivån för LAN-hanteraren i den lägsta enheten med nödvändig omfattning i principprogramhierarkin.

      Windows Server 2003 har en ny standardinställning som endast använder NTLMv2. Som standard har Windows Server 2003- och Windows 2000 Server SP3-baserade domänkontrollanter aktiverat principen "Microsoft-nätverksserver: Signera kommunikation digitalt (alltid)". Den här inställningen kräver att SMB-servern utför SMB-paketsignering. Ändringar av Windows Server 2003 har gjorts eftersom domänkontrollanter, filservrar, nätverksinfrastrukturservrar och webbservrar i alla organisationer kräver olika inställningar för att maximera säkerheten.

      Om du vill implementera NTLMv2-autentisering i nätverket måste du se till att alla datorer i domänen är inställda på att använda den här autentiseringsnivån. Om du använder Active Directory-klienttillägg för Windows 95 eller Windows 98 och Windows NT 4.0 använder klienttilläggen de förbättrade autentiseringsfunktionerna som är tillgängliga i NTLMv2. Eftersom klientdatorer som kör något av följande operativsystem inte påverkas av Windows 2000 grupprincip Objects kan du behöva konfigurera dessa klienter manuellt:

      • Microsoft Windows NT 4.0

      • Microsoft Windows Millennium Edition

      • Microsoft Windows 98

      • Microsoft Windows 95

      Obs! Om du aktiverar nätverkssäkerhet: Lagra inte LAN-hanterarens hash-värde på nästa princip för lösenordsändring eller ange registernyckeln NoLMHash , Windows 95-baserade och Windows 98-baserade klienter som inte har Directory Services Client installerat kan inte logga in på domänen efter en lösenordsändring.

      Många CIFS-servrar från tredje part, till exempel Novell Netware 6, är inte medvetna om NTLMv2 och använder endast NTLM. Därför tillåter inte nivåer som är större än 2 anslutningar. Det finns också SMB-klienter från tredje part som inte använder utökad sessionssäkerhet. I dessa fall beaktas inte resursserverns LmCompatiblityLevel. Servern packar sedan upp den här äldre begäran och skickar den till användardomänkontrollanten. Inställningarna på domänkontrollanten bestämmer sedan vilka hash-funktioner som används för att verifiera begäran och om dessa uppfyller domänkontrollantens säkerhetskrav.

       

      299656 Så här förhindrar du att Windows lagrar en LAN-hanterares hash för ditt lösenord i Active Directory och lokala SAM-databaser
       

      2701704Granskningshändelsen visar autentiseringspaketet som NTLMv1 i stället för NTLMv2 Om du vill ha mer information om LM-autentiseringsnivåer klickar du på följande artikelnummer för att visa artikeln i Microsoft Knowledge Base:

      239869 Så här aktiverar du NTLM 2-autentisering
       

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Icke-begränsande inställningar som skickar lösenord i klartext och som nekar NTLMv2-förhandling

      • Restriktiva inställningar som hindrar inkompatibla klienter eller domänkontrollanter från att förhandla om ett gemensamt autentiseringsprotokoll

      • Kräver NTLMv2-autentisering på medlemsdatorer och domänkontrollanter som kör versioner av Windows NT 4.0 som är tidigare än Service Pack 4 (SP4)

      • Kräver NTLMv2-autentisering på Windows 95-klienter eller på Windows 98-klienter som inte har Windows Directory Services-klienten installerad.

      • Om du klickar för att markera kryssrutan Kräv NTLMv2-sessionssäkerhet i snapin-modulen Microsoft Management Console grupprincip Editor på en Windows Server 2003- eller Windows 2000 Service Pack 3-baserad dator, och du sänker autentiseringsnivån för LAN-hanteraren till 0, är de två inställningarna i konflikt, och du kan få följande felmeddelande i filen Secpol.msc eller GPEdit.msc:

        Windows kan inte öppna den lokala principdatabasen. Ett okänt fel uppstod vid försök att öppna databasen.

        Mer information om säkerhetskonfigurations- och analysverktyget finns i hjälpfilerna för Windows 2000 eller Windows Server 2003.

    3. Anledningar till att ändra den här inställningen

      • Du vill öka det lägsta gemensamma autentiseringsprotokollet som stöds av klienter och domänkontrollanter i organisationen.

      • Där säker autentisering är ett affärskrav vill du inte tillåta förhandling om LM- och NTLM-protokollen.

    4. Orsaker till att inaktivera den här inställningen

      Kraven på klient- eller serverautentisering, eller båda, har utökats till den grad att autentisering över ett gemensamt protokoll inte kan ske.

    5. Symboliskt namn:

      Lmcompatibilitylevel

    6. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Exempel på kompatibilitetsproblem

      • Windows Server 2003: Som standard är inställningen Skicka NTLM-svar i Windows Server 2003 NTLMv2 Aktiverad. Därför får Windows Server 2003 felmeddelandet "Åtkomst nekad" efter den första installationen när du försöker ansluta till ett Windows NT 4.0-baserat kluster eller till LanManager V2.1-baserade servrar, till exempel OS/2 Lanserver. Det här problemet uppstår också om du försöker ansluta från en tidigare version av klient till en Windows Server 2003-baserad server.

      • Du installerar Windows 2000 Security Rollup Package 1 (SRP1). SRP1 tvingar NTLM version 2 (NTLMv2). Det här samlade paketet släpptes efter lanseringen av Windows 2000 Service Pack 2 (SP2).
         

      • Windows 7 och Windows Server 2008 R2: Många CIFS-servrar från tredje part, till exempel Novell Netware 6 eller Linux-baserade Samba-servrar, känner inte till NTLMv2 och använder endast NTLM. Därför tillåter inte nivåer som är större än "2" anslutningar. I den här versionen av operativsystemet har standardinställningen för LmCompatibilityLevel ändrats till "3". Så när du uppgraderar Windows kan dessa filer från tredje part sluta fungera.

      • Microsoft Outlook-klienter kan uppmanas att ange autentiseringsuppgifter även om de redan är inloggade på domänen. När användarna anger sina autentiseringsuppgifter får de följande felmeddelande: Windows 7 och Windows Server 2008 R2

        Inloggningsuppgifterna som angavs var felaktiga. Kontrollera att användarnamnet och domänen är korrekta och skriv sedan lösenordet igen.

        När du startar Outlook kan du uppmanas att ange dina autentiseringsuppgifter även om inställningen Inloggningsnätverkssäkerhet är inställd på Genomstrykning eller lösenordsautentisering. När du har angett rätt autentiseringsuppgifter kan du få följande felmeddelande:

        Inloggningsuppgifterna som angavs var felaktiga.

        En nätverksövervakningsspårning kan visa att den globala katalogen utfärdade ett RPC-fel (Remote Procedure Call) med statusen 0x5. Statusen för 0x5 betyder "Åtkomst nekad".

      • Windows 2000: En nätverksövervakares inspelning kan visa följande fel i SMB-sessionen (NetBIOS over TCP/IP (NetBT):

        SMB R Search Directory Dos-fel, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ogiltig användaridentifierare

      • Windows 2000: Om en Windows 2000-domän med NTLMv2-nivå 2 eller senare är betrodd av en Windows NT 4.0-domän kan windows 2000-baserade medlemsdatorer i resursdomänen uppleva autentiseringsfel.

      • Windows 2000 och Windows XP: Som standard ställer Windows 2000 och Windows XP in alternativet Lokal säkerhetsprincip för LAN Manager-autentiseringsnivå till 0. Inställningen 0 betyder "Skicka LM- och NTLM-svar".

        Obs! Windows NT 4.0-baserade kluster måste använda LM för administration.

      • Windows 2000: Windows 2000-kluster autentiserar inte en sammanfogningsnod om båda noderna ingår i en Windows NT 4.0 Service Pack 6a-domän (SP6a).

      • IIS Lockdown Tool (HiSecWeb) anger värdet LMCompatibilityLevel till 5 och värdet RestrictAnonymous till 2.

      • Tjänster för Macintosh

        Användarautentiseringsmodul (UAM): Microsoft UAM (User Authentication Module) är en metod för att kryptera lösenorden som du använder för att logga in på Windows AFP-servrar (AppleTalk Filing Protocol). Apple User Authentication Module (UAM) ger endast minimal kryptering eller ingen kryptering. Därför kan ditt lösenord lätt fångas upp på LAN eller på Internet. Även om UAM inte krävs ger den krypterad autentisering till Windows 2000-servrar som kör Services For Macintosh. Den här versionen innehåller stöd för NTLMv2 128-bitars krypterad autentisering och en MacOS X 10.1-kompatibel version.

        Som standard tillåter Windows Server 2003 Services för Macintosh-servern endast Microsoft-autentisering.
         

      • Windows Server 2008, Windows Server 2003, Windows XP och Windows 2000: Om du konfigurerar värdet LMCompatibilityLevel till 0 eller 1 och sedan konfigurerar värdet NoLMHash till 1, kan program och komponenter nekas åtkomst via NTLM. Det här problemet uppstår eftersom datorn är konfigurerad för att aktivera LM men inte för att använda LM-lagrade lösenord.

        Om du konfigurerar Värdet för NoLMHash till 1 måste du konfigurera värdet LMCompatibilityLevel till 2 eller högre.

  11. Nätverkssäkerhet: LDAP-klientsigneringskrav

    1. Bakgrund

      Nätverkssäkerhet: Inställningen för LDAP-klientsigneringskrav bestämmer vilken nivå av datasignering som begärs för klienter som utfärdar LDAP-BIND-begäranden (Lightweight Directory Access Protocol) enligt följande:

      • Inget: LDAP BIND-begäran utfärdas med angivna alternativ för uppringaren.

      • Förhandla om signering: Om SSL/TLS (Secure Sockets Layer/Transport Layer Security) inte har startats initieras LDAP-BIND-begäran med LDAP-datasigneringsalternativet utöver alternativen som anges av uppringaren. Om SSL/TLS har startats initieras LDAP-BIND-begäran med alternativen som anges av uppringaren.

      • Kräv signering: Det här är samma som Förhandla om signering. Men om LDAP-serverns mellanliggande saslBindInProgress-svar inte anger att LDAP-trafiksignering krävs får uppringaren veta att kommandobegäran LDAP BIND misslyckades.

    2. Riskabla konfigurationer

      Aktivering av inställningen Nätverkssäkerhet: LDAP-klientsigneringskrav är en skadlig konfigurationsinställning. Om du anger att servern ska kräva LDAP-signaturer måste du också konfigurera LDAP-signering på klienten. Att inte konfigurera klienten till att använda LDAP-signaturer förhindrar kommunikation med servern. Detta gör att användarautentisering, grupprincip-inställningar, inloggningsskript och andra funktioner misslyckas.

    3. Anledningar till att ändra den här inställningen

      Osignerad nätverkstrafik är mottaglig för attacker mellan människor där en inkräktare fångar paket mellan klienten och servrarna, ändrar dem och sedan vidarebefordrar dem till servern. När detta inträffar på en LDAP-server kan en angripare orsaka att en server svarar baserat på falska frågor från LDAP-klienten. Du kan minska den här risken i ett företagsnätverk genom att genomföra starka fysiska säkerhetsåtgärder för att skydda nätverksinfrastrukturen. Dessutom kan du förhindra alla typer av man-in-the-middle-attacker genom att kräva digitala signaturer i alla nätverkspaket med hjälp av IPSec-autentiseringshuvuden.

    4. Symboliskt namn:

      LDAPClientIntegrity

    5. Registersökväg:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

  12. Händelselogg: Maximal säkerhetsloggstorlek

    1. Bakgrund

      Händelseloggen: Säkerhetsinställningen maximal säkerhetsloggstorlek anger den maximala storleken på säkerhetshändelseloggen. Den här loggen har en maximal storlek på 4 GB. Om du vill hitta den här inställningen expanderar du
      Windows-inställningar och expanderar sedan Säkerhetsinställningar.

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Begränsa säkerhetsloggens storlek och metoden för bevarande av säkerhetsloggar när inställningen Granska: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar är aktiverad. Mer information finns i avsnittet "Granskning: Stäng av systemet omedelbart om det inte går att logga säkerhetsgranskningar" i den här artikeln.

      • Begränsa storleken på säkerhetsloggen så att säkerhetshändelser av intresse skrivs över.

    3. Anledningar till att öka den här inställningen

      Företags- och säkerhetskraven kan diktera att du ökar säkerhetsloggstorleken för att hantera ytterligare säkerhetslogginformation eller behålla säkerhetsloggar under en längre tid.

    4. Orsaker till att minska den här inställningen

      Loggboken loggar är minnesmappade filer. Den maximala storleken på en händelselogg begränsas av mängden fysiskt minne på den lokala datorn och av det virtuella minne som är tillgängligt för händelseloggprocessen. Om du ökar loggstorleken utöver mängden virtuellt minne som är tillgängligt för Loggboken ökar inte antalet loggposter som underhålls.

    5. Exempel på kompatibilitetsproblem

      Windows 2000: Datorer som kör versioner av Windows 2000 som är tidigare än Service Pack 4 (SP4) kan sluta logga händelser i händelseloggen innan de når den storlek som anges i inställningen Maximal loggstorlek i Loggboken om alternativet Skriv inte över händelser (rensa logg manuellt) är aktiverat.


       

  13. Händelselogg: Behåll säkerhetsloggen

    1. Bakgrund

      Händelseloggen: Behåll säkerhetsloggsäkerhetsinställningen bestämmer "omslagsmetoden" för säkerhetsloggen. Om du vill hitta den här inställningen expanderar du Windows-inställningar och expanderar sedan Säkerhetsinställningar.

    2. Riskfyllda konfigurationer

      Följande är skadliga konfigurationsinställningar:

      • Det går inte att behålla alla loggade säkerhetshändelser innan de skrivs över

      • Konfigurera inställningen Maximal säkerhetsloggstorlek för liten så att säkerhetshändelser skrivs över

      • Begränsa säkerhetsloggens storlek och kvarhållningsmetod medan säkerhetsinställningen Granska: Stäng av systemet omedelbart om säkerhetsinställningen inte kan logga säkerhetsgranskningar är aktiverad

    3. Orsaker till att aktivera den här inställningen

      Aktivera endast den här inställningen om du väljer bevarandemetoden Skriv över händelser efter dagar . Om du använder ett system för händelsekorrelation som avrundar händelser kontrollerar du att antalet dagar är minst tre gånger så ofta som för omröstningar. Gör så här för att tillåta misslyckade omröstningscykler.

  14. Nätverksåtkomst: Låt alla behörigheter gälla för anonyma användare

    1. Bakgrund

      Som standard är nätverksåtkomsten: Inställningen Tillåt alla behörigheter för anonyma användare är inställd på Inte definierad i Windows Server 2003. Som standard innehåller Windows Server 2003 inte token för anonym åtkomst i gruppen Alla.

    2. Exempel på kompatibilitetsproblem

      Följande värde för

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 bryter skapande av förtroende mellan Windows Server 2003 och Windows NT 4.0, när Windows Server 2003-domänen är kontodomän och Windows NT 4.0-domänen är resursdomänen. Det innebär att kontodomänen är betrodd i Windows NT 4.0 och att resursdomänen är Betrodd på Windows Server 2003-sidan. Det här beteendet inträffar eftersom processen för att starta förtroendet efter den första anonyma anslutningen är ACL'd med token alla som innehåller Anonymt SID på Windows NT 4.0.

    3. Anledningar till att ändra den här inställningen

      Värdet måste anges till 0x1 eller anges med hjälp av ett GPO i domänkontrollantens OU: Nätverksåtkomst: Låt alla behörigheter gälla för anonyma användare – Aktiverad för att göra förtroendeskapanden möjliga.

      Obs! De flesta andra säkerhetsinställningar ökar i värde i stället för ned till 0x0 i deras mest skyddade tillstånd. En säkrare metod skulle vara att ändra registret i den primära domänkontrollantens emulator i stället för på alla domänkontrollanter. Om emulatorrollen för primär domänkontrollant flyttas av någon anledning måste registret uppdateras på den nya servern.

      En omstart krävs när det här värdet har angetts.

    4. Registersökväg

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

  15. NTLMv2-autentisering

    1. Sessionssäkerhet

      Sessionssäkerhet avgör de lägsta säkerhetsstandarderna för klient- och serversessioner. Det är en bra idé att kontrollera följande säkerhetsprincipinställningar i snapin-modulen Microsoft Management Console grupprincip Editor:

      • Datorinställningar\Windows-inställningar\Säkerhetsinställningar\Lokala principer\Säkerhetsalternativ

      • Nätverkssäkerhet: Lägsta sessionssäkerhet för NTLM SSP-baserade (inklusive säkra RPC)-servrar

      • Nätverkssäkerhet: Lägsta sessionssäkerhet för NTLM SSP-baserade klienter (inklusive säkra RPC-klienter)

      Alternativen för de här inställningarna är följande:

      • Kräv meddelandeintegritet

      • Kräv att meddelandet är konfidentiellt

      • Kräv säkerhet för NTLM version 2-session

      • Kräv 128-bitarskryptering

      Standardinställningen före Windows 7 är Inga krav. Från och med Windows 7 ändrades standardinställningen till Kräv 128-bitarskryptering för bättre säkerhet. Med den här standardinställningen kan äldre enheter som inte stöder 128-bitarskryptering inte ansluta.

      Dessa principer bestämmer de lägsta säkerhetsstandarderna för en kommunikationssession mellan program på en server för en klient.

      Observera att flaggor som kräver meddelandeintegritet och konfidentialitet inte används när NTLM-sessionssäkerheten fastställs, även om de beskrivs som giltiga inställningar.

      Tidigare har Windows NT stött följande två varianter av utmanings-/svarsautentisering för nätverksanloggningar:

      • LM-utmaning/respons

      • NTLM version 1 utmaning/svar

      LM möjliggör interoperabilitet med den installerade basen av klienter och servrar. NTLM ger förbättrad säkerhet för anslutningar mellan klienter och servrar.

      De motsvarande registernycklarna är följande:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    2. Riskfyllda konfigurationer

      Den här inställningen styr hur nätverkssessioner som skyddas med NTLM hanteras. Detta påverkar till exempel RPC-baserade sessioner autentiserade med NTLM. Det finns följande risker:

      • Med äldre autentiseringsmetoder än NTLMv2 blir kommunikationen enklare att attackera på grund av de enklare hash-metoderna som används.

      • Om du använder krypteringsnycklar som är lägre än 128-bitars kan angripare bryta kommunikationen med rå force-attacker.

Tidssynkronisering

Tidssynkroniseringen misslyckades. Tiden är avstängd i mer än 30 minuter på en berörd dator. Kontrollera att klientdatorns klocka är synkroniserad med domänkontrollantens klocka.

Lösning för SMB-signering

Vi rekommenderar att du installerar Service Pack 6a (SP6a) på Windows NT 4.0-klienter som samverkar i en Windows Server 2003-baserad domän. Windows 98 Second Edition-baserade klienter, Windows 98-baserade klienter och Windows 95-baserade klienter måste köra Directory Services-klienten för att utföra NTLMv2. Om Windows NT 4.0-baserade klienter inte har Windows NT 4.0 SP6 installerat eller om Windows 95-baserade klienter, Windows 98-baserade klienter och Windows 98SE-baserade klienter inte har Directory Services Client installerat, inaktiverar du SMB-inloggning i standarddomänkontrollantens principinställning på domänkontrollantens OU och länkar sedan den här principen till alla OUs som är värd för domänkontrollanter.

Katalogtjänstklienten för Windows 98 Second Edition, Windows 98 och Windows 95 utför SMB-signering med Windows 2003-servrar under NTLM-autentisering, men inte under NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsförfrågningar från dessa klienter.

Även om vi inte rekommenderar det kan du förhindra att SMB-signering krävs för alla domänkontrollanter som kör Windows Server 2003 i en domän. Så här konfigurerar du den här säkerhetsinställningen:

  1. Öppna standardprincipen för domänkontrollanten.

  2. Öppna mappen Datorkonfiguration\Windows-inställningar\Säkerhetsinställningar\Lokala principer\Säkerhetsalternativ.

  3. Leta reda på och klicka sedan på microsofts nätverksserver: Signera principinställningen för kommunikation (alltid) digitalt och klicka sedan på Inaktiverad.

Viktigt Det här avsnittet, metoden eller uppgiften innehåller steg som beskriver hur du ändrar registret. Allvarliga problem kan dock uppstå om du ändrar registret på fel sätt. Se därför till att du följer de här stegen noggrant. Om du vill ha ytterligare skydd bör du säkerhetskopiera registret innan du ändrar det. Sedan kan du återställa registret om ett problem uppstår. Om du vill ha mer information om hur du säkerhetskopierar och återställer registret klickar du på följande artikelnummer för att visa artikeln i Microsoft Knowledge Base:

322756 Säkerhetskopiera och återställa registret i Windows Du kan också inaktivera SMB-signering på servern genom att ändra registret. Gör så här:

  1. Klicka på Start, klicka på Kör, skriv regedit och klicka sedan på OK.

  2. Leta reda på och klicka sedan på följande undernyckel:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

  3. Klicka på posten enablesecuritysignature .

  4. Klicka på ÄndraRedigera-menyn.

  5. Skriv 0 i rutan Värdedata och klicka sedan på OK.

  6. Avsluta Registereditorn.

  7. Starta om datorn eller stoppa och starta sedan om servertjänsten. Det gör du genom att skriva följande kommandon i en kommandotolk och sedan trycka på Retur när du har skrivit varje kommando:
    net stop server
    net start server

Obs! Motsvarande nyckel på klientdatorn finns i följande registerundernyckel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Nedan visas de översatta felkodsnumren till statuskoder och till de ordagranta felmeddelanden som nämns tidigare:

fel 5


ERROR_ACCESS_DENIED Åtkomst nekas.

fel 1326



ERROR_LOGON_FAILURE Inloggningsfel: okänt användarnamn eller felaktigt lösenord.

fel 1788



ERROR_TRUSTED_DOMAIN_FAILURE Förtroenderelationen mellan den primära domänen och den betrodda domänen misslyckades.

fel 1789



ERROR_TRUSTED_RELATIONSHIP_FAILURE Förtroenderelationen mellan den här arbetsstationen och den primära domänen misslyckades.

Om du vill ha mer information klickar du på följande artikelnummer för att visa artiklarna i Microsoft Knowledge Base:

324802 Så här konfigurerar du grupprinciper för att ställa in säkerhet för systemtjänster i Windows Server 2003

816585 Så här använder du fördefinierade säkerhetsmallar i Windows Server 2003

Behöver du mer hjälp?

Vill du ha fler alternativ?

Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.

Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.

Hade du nytta av den här informationen?

Hur nöjd är du med språkkvaliteten?
Vad påverkade din upplevelse?
Genom att trycka på skicka, kommer din feedback att användas för att förbättra Microsofts produkter och tjänster. IT-administratören kan samla in denna data. Sekretesspolicy.

Tack för din feedback!

×