Klient-, tjänst- och programinkompatibilitet vid ändring av säkerhetsinställningar och tilldelning av användarrättigheter

Artikelöversättning Artikelöversättning
Artikel-id: 823659 - Visa produkter som artikeln gäller.
Visa alla | Dölj alla

På den här sidan

Sammanfattning

I den här artikeln beskrivs inkompatibiliteter som kan uppstå på klientdatorer med Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT 4.0, Microsoft Windows 2000, Microsoft Windows XP Professional eller Microsoft Windows Server 2003 vid ändring av vissa säkerhetsinställningar och tilldelningar av användarrättigheter i Windows NT 4.0-, Windows 2000- eller Windows Server 2003-domäner.

Genom att konfigurera de här inställningarna och tilldelningarna i lokala principer och grupprinciper kan du öka säkerheten på domänkontrollanter och datorer som är medlemmar av domänen. Den ökade säkerheten ger emellertid även upphov till inkompatibiliteter med klienter, tjänster och program.

För att öka medvetenheten om felkonfigurerade säkerhetsinställningar kan du ändra säkerhetsinställningarna med Redigeraren för grupprincipobjekt. När du använder detta verktyg utökas tilldelningen av användarrättigheter i följande operativsystem:
  • Microsoft Windows XP Professional Service Pack 2 (SP2)
  • Microsoft Windows Server 2003 Service Pack 1 (SP1)
Bland annat tillkommer en dialogruta med en länk till den här artikeln som visas när en säkerhetsinställning eller en tilldelning av användarrättigheter ändras till en mindre kompatibel och mer begränsad inställning. Om du direkt ändrar samma säkerhetsinställning eller tilldelning av användarrättigheter med hjälp av registret eller säkerhetsmallar blir resultatet detsamma som om inställningen ändras i Redigeraren för grupprincipobjekt. Dialogrutan med länken till den här artikeln visas emellertid inte.

Den här artikeln innehåller exempel på klienter, program och åtgärder som påverkas av vissa säkerhetsinställningar eller tilldelningar av användarrättigheter. Exemplen gäller emellertid inte alla Microsoft-operativsystem, alla operativsystem från andra tillverkare eller alla programversioner som påverkas. Alla säkerhetsinställningar och tilldelningar av användarrättigheter ingår inte i den här artikeln.

Microsoft rekommenderar att du kontrollerar kompatibiliteten för alla säkerhetsrelaterade konfigurationsändringar i en testskog innan du inför dem i en produktionsmiljö. Testskogen måste avspegla produktionsskogen i följande avseenden:
  • Versioner av klient- och serveroperativsystem, 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 inställningar och grupprincipinställningar samt objektens antal, typ och placering.
  • Administrativa åtgärder, administrativa verktyg och operativsystem som används för att utföra administrativa åtgärder
  • Åtgärder som utförs, inklusive inloggningsautentisering för dator och användare; lösenordsåterställning av användare, datorer och administratörer; bläddring; inställning av behörigheter för filsystemet, för delade mappar, för registret och för Active Directory-resurser med hjälp av ACL Editor i alla klientoperativsystem i alla konto- eller resursdomäner från alla klientoperativsystem från alla konto- eller resursdomäner; utskrift från administratörskonton och icke-administratörskonton

Windows Server 2003 SP1

Varningar i Gpedit.msc

För att kunderna ska vara medvetna om att de redigerar en användarrättighet eller ett säkerhetsalternativ som kan ha negativa effekter på nätverket har två varningsmekanismer lagts till i gpedit.msc. När administratörer redigerar en användarrättighet som kan påverka hela företaget negativt visas en ny ikon som liknar en lämna företräde-skylt. Dessutom visas en varning med en länk till artikel 823659 i Microsoft Knowledge Base. Meddelandet innehåller följande text:
Om du ändrar den här inställningen kan du påverka kompatibilitet med klienter, tjänster och program. Mer information finns i <användarrättighet eller säkerhetsalternativ som ändras> (Q823659)
Om du har kommit till den här artikeln via en länk i GPEDIT.MSC bör du läsa och förstå förklaringen och vad som kan hända om du ändrar inställningen. Följande användarrättigheter innehåller den nya varningstexten:
  • Åtkomst till den här datorn från nätverket
  • Lokal inloggning
  • Kringgå bläddringskontroll
  • Aktivera datorer och användare för betrodd delegering
Följande säkerhetsalternativ har varningen och ett popup-fönster:
  • Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid)
  • Domänmedlem: Kräv stark (Windows 2000 eller senare) sessionsnyckel
  • Domänkontrollant: Signeringskrav för LDAP-server
  • Microsoft-nätverksserver: Signera kommunikation digitalt (alltid)
  • Nätverksåtkomst: Tillåt översättning av SID/namn anonymt
  • Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och resurser
  • Nätverkssäkerhet: Autentiseringsnivå för LAN Manager
  • Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning
  • Nätverksåtkomst: Signeringskrav för LDAP-klient

Mer Information

I följande avsnitt beskrivs inkompatibiliteter som kan uppstå vid ändring av vissa inställningar i Windows NT 4.0-, Windows 2000- och Windows Server 2003-domäner.

Användarrättigheter

  1. Åtkomst till den här datorn från nätverket
    1. Bakgrund

      För att det ska vara möjligt att interagera med fjärr-Windows-datorer krävs användarrättigheten Åtkomst till den här datorn från nätverket. 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 datorer samt åtkomst till delade mappar, till skrivare och till andra systemtjänster på fjärrdatorer i nätverket.

      Användare, datorer och tjänstkonton får eller förlorar användarrättigheten Åtkomst till den här datorn från nätverket genom att uttryckligen eller underförstått läggas till i eller tas bort från en säkerhetsgrupp som har tilldelats den här användarrättigheten. Ett användar- eller datorkonto kan exempelvis uttryckligen läggas till i en anpassad eller inbyggd säkerhetsgrupp av en administratör eller underförstått läggas till av operativsystemet i en beräknad säkerhetsgrupp som Domänanvändare, Autentiserade användare eller Företagets domänkontrollanter.

      Som standard tilldelas användar- och datorkonton användarrättigheten Åtkomst till den här datorn från nätverket när beräknade grupper som Alla eller (helst) Autentiserade användare och , för domänkontrollanter, gruppen Företagets domänkontrollanter, har definierats i standardgrupprincipobjektet för domänkontrollanter.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Borttagning av säkerhetsgruppen Företagets domänkontrollanter från den här användarrättigheten
      • Borttagning av gruppen Autentiserade användare eller en uttrycklig grupp som ger användare, datorer och tjänstkonton rätt att ansluta till datorer via nätverket
      • Borttagning av alla användare och datorer från den här användarrättigheten
    3. Skäl att tilldela den här användarrättigheten
      • Om gruppen Företagets domänkontrollanter ges användarrättigheten Åtkomst till den här datorn från nätverket tillfredsställs autentiseringskrav som Active Directory-replikering ställer för att replikering ska ske mellan domänkontrollanter i samma skog.
      • Den här användarrättigheten ger användare och datorer tillgång till delade filer, skrivare och systemtjänster, däribland Active Directory.
      • Användarrättigheten krävs för att användare ska komma åt e-post med hjälp av tidiga versioner av Microsoft Outlook Web Access (OWA).
    4. Skäl att ta bort den här användarrättigheten
      • 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ättigheten krävs till exempel för att en användare ska kunna ansluta till delade skrivare och mappar. Om användarrättigheten ges till gruppen Alla, och vissa delade filer har både resurs- och NTFS-filsystembehörigheter konfigurerade så att samma grupp har läsbehörighet, kan alla visa filer i de delade mapparna. Detta är emellertid osannolikt vid nya installationer av Windows Server 2003, eftersom standardresurs- och NTFS-behörigheterna i Windows Server 2003 inte innefattar gruppen Alla. För datorer som uppgraderas från Microsoft Windows NT 4.0 eller Windows 2000 kan det här säkerhetsproblemet innebära en högre risk, eftersom standardbehörigheterna för resurser och filsystem i dessa operativsystem inte är så begränsade som standardbehörigheterna i Windows Server 2003.
      • Det finns inget rimligt skäl till att ta bort Företagets domänkontrollanter från den här användarrättigheten.
      • Gruppen Alla tas i allmänhet bort till förmån för gruppen Autentiserade användare. Om gruppen Alla tas bort måste gruppen Autentiserade användare ges den här användarrättigheten.
      • Windows NT 4.0-domäner som uppgraderas till Windows 2000 ger inte uttryckligen grupperna Alla, Autentiserade användare eller Företagets domänkontrollanter användarrättigheten Åtkomst till den här datorn från nätverket. När gruppen Alla tas bort från Windows NT 4.0-domänprincipen misslyckas därför Active Directory-replikering med felmeddelandet "Åtkomst nekad" efter uppgradering till Windows 2000. Winnt32.exe i Windows Server 2003 undanröjer felkonfigurationen genom att gruppen Företagets domänkontrollanter ges den här användarrättigheten vid uppgradering av primära Windows NT 4.0-domänkontrollanter. Ge gruppen Företagets domänkontrollanter användarrättigheten om den inte finns i Redigeraren för grupprincipobjekt.
    5. Exempel på kompatibilitetsproblem
      • Windows 2000 och Windows Server 2003: Replikering av ett Active Directory-schema, en konfiguration, en domän, en global katalog eller programpartitioner misslyckas med felmeddelandet "Åtkomst nekad", vilket framgår av övervakningsverktyg som REPLMON och REPADMIN eller replikeringshändelser i händelseloggen.
      • Alla Microsoft-nätverksoperativsystem: Autentisering av ett användarkonto från klientdatorer i ett fjärrnätverk misslyckas om inte användaren eller en säkerhetsgrupp som användaren är medlem av har tilldelats den här användarrättigheten.
      • Alla Microsoft-nätverksoperativsystem: Autentisering av ett konto från fjärrnätverksklienter misslyckas om inte kontot eller en säkerhetsgrupp som kontot är medlem av har tilldelats den här användarrättigheten. Det här scenariot gäller användar-, dator- och tjänstkonton.
      • Alla Microsoft-nätverksoperativsystem: Om alla konton tas bort från den här användarrättigheten hindras alla konton från att logga in på domänen eller komma åt nätverksresurser. Om beräknade grupper som Företagets domänkontrollanter, Alla eller Autentiserade användare tas bort, måste du uttryckligen ge den här användarrättigheten till konton eller säkerhetsgrupper som kontot är medlem av för att det ska vara möjligt att komma åt fjärrdatorer via nätverket. Det här scenariot gäller alla användar-, dator- och tjänstkonton.
      • Alla Microsoft-nätverksoperativsystem: Ett "tomt" lösenord används för det lokala administratörskontot. 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 ett felmeddelande med "Åtkomst nekad".
  2. Tillåt lokal inloggning
    1. Bakgrund

      Användare som försöker logga in vid konsolen på en dator med Microsoft Windows (med hjälp av inloggningstangentsekvensen CTRL+ALT+DELETE) och konton som försöker starta en tjänst måste ha lokala inloggningsprivilegier på värddatorn. Lokal inloggning kan gälla administratörer som loggar in på medlemsdatorernas konsoler. Det kan också röra sig om domänkontrollanter i hela företaget eller domänanvändare som loggar in på medlemsdatorer för att komma åt sina skrivbord med hjälp av konton utan privilegier. Användare som använder en fjärrskrivbordsanslutning eller Terminal Services måste ha användarrättigheten Tillåt lokal inloggning på måldatorer med Windows 2000 eller Windows XP, eftersom dessa inloggningslägen betraktas som lokala för värddatorn. Användare som loggar in på en server där Terminal Server är aktiverat och som saknar den här användarrättigheten kan ändå starta en interaktiv fjärrsession i Windows Server 2003-domäner om de har användarrättigheten Tillåt inloggning genom Terminal Services.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Borttagning av administrativa säkerhetsgrupper, inklusive kontoansvariga, ansvariga för säkerhetskopiering, skrivaransvariga eller serveransvariga, och den inbyggda gruppen Administratörer från standardprincipen för domänkontrollanter.
      • Borttagning av tjänstkonton som används av komponenter och program på medlemsdatorer och domänkontrollanter i domänen från standardprincipen för domänkontrollanter.
      • Borttagning av användare eller säkerhetsgrupper som loggar in på konsolen för medlemsdatorer i domänen.
      • Borttagning av tjänstkonton som definieras i den lokala SAM-databasen (Security Accounts Manager) med medlems- eller arbetsgruppsdatorer.
      • Borttagning av icke-inbyggda administratörskonton som autentiserar genom Terminal Services som körs på en domänkontrollant.
      • Tillägg av alla användarkonton i domänen uttryckligen eller underförstått genom gruppen Alla till inloggningsrättigheten Neka lokal inloggning. Den här konfigurationen hindrar användare från att logga in på någon medlemsdator eller på en domänkontrollant i domänen.
    3. Skäl att tilldela den här användarrättigheten
      • Användare måste ha användarrättigheten Tillåt lokal inloggning för att komma åt konsolen eller skrivbordet på en arbetsgruppsdator, medlemsdator eller domänkontrollant.
      • Användare måste ha den här användarrättigheten för att kunna logga in genom en Terminal Services-session som körs på en medlemsdator eller domänkontrollant med Windows 2000.
    4. Skäl att ta bort den här användarrättigheten
      • Om konsolåtkomst inte begränsas till legitima användarkonton kan det medföra att obehöriga användare överför och kör skadlig kod för ändring av sina användarrättigheter.
      • Borttagning av användarrättigheten Tillåt lokal inloggning förhindrar obehöriga inloggningar på konsoler för datorer, till exempel domänkontrollanter eller programservrar.
      • Borttagning av den här inloggningsrättigheten förhindrar inloggning från icke-domänkonton på konsoler för medlemsdatorer i domänen.
    5. Exempel på kompatibilitetsproblem
      • Terminalservrar med Windows 2000: Användarrättigheten Tillåt lokal inloggning krävs för att användare ska kunna logga in på terminalservrar med Windows 2000.
      • Windows NT 4.0, Windows 2000, Windows XP och Windows Server 2003: Användarkonton måste ges den här användarrättigheten för att kunna logga in på konsolen för datorer där Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003 körs.
      • Windows NT 4.0 och senare: Om du lägger till användarrättigheten Tillåt lokal inloggning på datorer med Windows NT 4.0 eller senare, men även uttryckligen eller underförstått ger inloggningsrättigheten Neka lokal inloggning, kan kontona inte logga in på domänkontrollanternas konsol.
  3. Kringgå bläddringskontroll
    1. Bakgrund

      Användarrättigheten Kringgå bläddringskontroll ger användaren möjlighet att bläddra bland mappar i NTFS-filsystemet eller registret utan att kontrollera den särskilda åtkomstbehörigheten Bläddra mapp. Användarrättigheten Kringgå bläddringskontroll ger inte användaren rätt att visa innehållet i en mapp, bara rätt att bläddra i mapparna.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Borttagning av icke-administratörskonton som loggar in på Terminal Services-datorer med Windows 2000 eller Windows Server 2003 som saknar behörighet för att komma åt filer och mappar i filsystemet.
      • Borttagning av gruppen Alla från listan över säkerhetsobjekt som i standardfallet har den här användarrättigheten. Windows-operativsystem och många program har skapats med förutsättningen att alla som har legitim åtkomst till datorn även har användarrättigheten Kringgå bläddringskontroll. Borttagning av gruppen Alla från listan över säkerhetsobjekt som i standardfallet har den här användarrättigheten kan leda till att operativsystemet blir instabilt eller att programmet upphör att fungera. Det är därför bättre att låta inställningen ha kvar standardvärdet.
    3. Skäl att tilldela den här användarrättigheten

      Standardinställningen för användarrättigheten Kringgå bläddringskontroll är att alla tillåts kringgå bläddringskontroll. Erfarna Windows-systemadministratörer förväntar sig att det ska fungera så och konfigurerar listor för systembehörighet (SACL) i enlighet med detta. Det enda fallet där standardkonfigurationen kan ge upphov till problem är om administratören som konfigurerar behörigheter inte förstår funktionen och förväntar sig att användare som inte kan komma åt en överordnad mapp inte ska komma åt innehållet i underordnade mappar.
    4. Skäl att ta bort den här användarrättigheten

      Organisationer som är extremt säkerhetsmedvetna kan frestas att ta bort gruppen Alla, eller till och med gruppen Användare, från listan över grupper med användarrättigheten Kringgå bläddringskontroll för att förhindra åtkomst till filer eller mappar i filsystemet.
    5. Exempel på kompatibilitetsproblem
      • Windows 2000, Windows Server 2003: Om användarrättigheten Kringgå bläddringskontroll tas bort eller konfigureras felaktigt på en dator med Windows 2000 eller Windows Server 2003, replikeras inte grupprincipinställningar i SYVOL-mappen mellan domänkontrollanter i domänen.
      • Windows 2000, Windows XP Professional, Windows Server 2003: På datorer med Windows 2000, Windows XP Professional eller Windows Server 2003 loggas händelserna 1000 och 1202, och dator- och användarprinciper kan inte användas när de nödvändiga filsystembehörigheterna tas bort från SYSVOL-trädet, om användarrättigheten Kringgå bläddringskontroll tas bort eller konfigureras felaktigt.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        290647 Händelse-ID 1000, 1001 loggas var femte minut i loggboken Program (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000, Windows Server 2003: På datorer med Windows 2000 eller Windows Server 2003 försvinner fliken Kvot i Utforskaren när egenskaper för en volym visas.
      • Windows 2000: När användare utan administratörsbehörighet försöker logga in på en Windows 2000-terminalserver visas kanske följande felmeddelande:
        Userinit.exe programfel. Det gick inte att initiera programmet korrekt 0xc0000142 Klicka på OK för att avsluta programmet.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        272142 Användare loggas automatiskt ut vid försök att logga in i Terminal Services (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Användare med Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003 kan kanske inte komma åt delade mappar eller filer i delade mappar, och felmeddelandet "Åtkomst nekad" visas kanske om de inte ges användarrättigheten Kringgå bläddringskontroll.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        277644 Felmeddelandet "Åtkomst nekad" visas vid försök att komma åt delade mappar (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: På datorer med Windows NT 4.0 medför borttagning av användarrättigheten Kringgå bläddringskontroll att filströmmar försvinner från en filkopia. Om den här användarrättigheten tas bort och filen kopieras från en Windows- eller Macintosh-klient till en Windows NT 4.0-domänkontrollant där Macintosh-tjänster används, går målfilströmmen förlorad, och filen visas med endast text.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        172930 Borttagning av "Kringgå bläddringskontroll" medför att strömmar försvinner från filkopia (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Microsoft Windows 95, Microsoft Windows 98: På en klientdator med Windows 95 eller Windows 98 misslyckas kommandot net use * /home med felmeddelandet "Åtkomst nekad", om gruppen Autentiserade användare inte ges användarrättigheten Kringgå bläddringskontroll.
      • Outlook Web Access: Icke-administratörer kan inte logga in i Microsoft Outlook Web Access, och felmeddelandet "Åtkomst nekad" visas om de inte ges användarrättigheten Kringgå bläddringskontroll.
Säkerhetsinställningar
  1. Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning
    1. Bakgrund
      • Inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning avgör om systemet ska stängas av när det inte går att logga säkerhetshändelser. Den här inställningen krävs för TCSEC-programmets (Trusted Computer Security Evaluation Criteria) C2-utvärdering och för att Common Criteria for Information Technology Security Evaluation ska kunna förhindra granskningsbara händelser om händelserna inte kan loggas i granskningssystemet. Om granskningssystemet inte fungerar stängs datorn av, och ett Stop-felmeddelande visas.
      • Om det inte går att registrera händelser i säkerhetsloggen är kritiska bevis eller viktig information för felsökning kanske inte tillgängliga för granskning efter en säkerhetsincident.
    2. Riskabel konfiguration

      Följande konfiguration är skadlig: Inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning är aktiv, och säkerhetshändelsloggens storlek begränsas av alternativet Skriv aldrig över händelser (rensa loggen manuellt), Skriv över händelser om det behövs eller Skriv över händelser äldre än antal dagar i Loggboken. I "Exempel på kompatibilitetsproblem" finns information om risker för datorer med de ursprungliga utgivna versionerna av Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 eller Windows 2000 SP3.
    3. Skäl att aktivera den här inställningen

      Om det inte går att registrera händelser i säkerhetsloggen är kritiska bevis eller viktig information för felsökning kanske inte tillgängliga för granskning efter en säkerhetsincident.
    4. Skäl att inaktivera den här inställningen
      • Om du aktiverar inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning stängs datorn av när det inte går att logga säkerhetshändelser. Normalt kan en händelse inte loggas när säkerhetsgranskningsloggen är full och den angivna loggmetoden är Skriv aldrig över händelser (rensa loggen manuellt) eller Skriv över händelser äldre än antal dagar.
      • Aktivering av inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning kan innebära mycket administrativt arbete, i synnerhet om även alternativet Skriv aldrig över händelser (rensa loggen manuellt) väljs för säkerhetsloggen. Den här inställningen gör det möjligt att ställa enskilda till ansvar för olika åtgärder. En administratör kan till exempel återställa behörigheter för alla användare, datorer och grupper i en organisationsenhet där granskning har aktiverats med hjälp av det inbyggda administratörskontot eller ett annat delat konto, och sedan förneka åtgärden. Aktivering av den här inställningen minskar emellertid datorns stabilitet, eftersom en server kan stängas av genom ett stort antal inloggningshändelser och andra säkerhetshändelser som skrivs till säkerhetsloggen. Eftersom avstängningen inte sker på ett städat sätt kan det dessutom uppstå irreparabla skador på operativsystemet, program eller data. Även om NTFS säkerställer att filsystemet inte skadas vid en avstängning som inte sker på ett städat sätt, finns det inga garantier för att alla datafiler för varje program kan användas när datorn startar 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 programfel kan det hända att loggning av händelser på datorer med Windows 2000, Windows 2000 SP1, Windows 2000 SP2 eller Windows Server SP3 upphör innan storleken som anges i alternativet Maximal loggstorlek för säkerhetshändelseloggen uppnås. Programfelet har åtgärdats i Windows 2000 Service Pack 4 (SP4). Se till att alla Windows 2000-domänkontrollanter har Windows 2000 Service Pack 4 innan du överväger att aktivera den här inställningen.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        312571 Loggning av händelser i händelseloggen upphör innan den maximala loggstorleken har uppnåtts (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000, Windows Server 2003: Datorer med Windows 2000 eller Windows Server 2003 kan sluta svara och sedan spontant starta om, om inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning har aktiverats, säkerhetsloggen är full och en befintlig händelseloggpost inte kan skrivas över. När datorn startar om visas följande Stop-felmeddelande:
        STOP: C0000244 {Granskning misslyckades}
        Det gick inte att generera en säkerhetsgranskning.
        För att återställa datorn 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: När användare utan administratörsbehörighet försöker logga in i en domän visas följande felmeddelande:
        Ditt konto är konfigurerat så att du inte ska kunna använda denna dator. Försök med en annan.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        160783 Felmeddelande: Användare kan inte logga in på en arbetsstation (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000: På datorer med Windows 2000 kan icke-administratörer inte logga in på fjärråtkomstservrar, och ett felmeddelande av följande slag visas:
        Okänd användare eller felaktigt lösenord
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        285665 Felmeddelande: Ditt konto är konfigurerat så att du inte ska kunna använda denna dator (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000: På Windows 2000-domänkontrollanter stoppas tjänsten Intersite Messaging (Ismserv.exe) och kan inte startas om. I DCDIAG rapporteras felet som "failed test services ISMserv", och händelse-ID 1083 registreras i händelseloggen.
      • Windows 2000: På Windows 2000-domänkontrollanter misslyckas Active Directory-replikering, och felmeddelandet "Åtkomst nekad" visas om säkerhetshändelseloggen är full.
      • Microsoft Exchange 2000: På servrar med Exchange 2000 är det inte möjligt att montera databasen för informationsarkivet, och händelse 2102 registreras i händelseloggen.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        314294 Felmeddelanden i Exchange 2000 på grund av problem med SeSecurityPrivilege Right och Policytest (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Outlook, Outlook Web Access: Icke-administratörer kommer inte åt sin e-post med hjälp av Microsoft Outlook eller Microsoft Outlook Web Access, och ett 503-felmeddelande visas.
  2. Domänkontrollant: Signeringskrav för LDAP-server
    1. Bakgrund

      Säkerhetsinställningen Domänkontrollant: Signeringskrav för LDAP-server avgör om LDAP-servern (Lightweight Directory Access Protocol) kräver att LDAP-klienter förhandlar datasignering. Principinställningen kan ha följande värden:
      • Inga: Datasignering krävs inte för bindning med servern. Om klienten begär datasignering stöds det av servern.
      • Kräv signering: LDAP-datasigneringsalternativet måste förhandlas om inte TLS/SSL (Transport Layer Security/Secure Socket Layer) används.
      • inte definierad: Inställningen har inte aktiverats eller inaktiverats.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Aktivering av Kräv signering i miljöer där klienter inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte aktiveras på klienten
      • Användning av säkerhetsmallen Hisecdc.inf för Windows 2000 eller Windows Server 2003 i miljöer där klienterna inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte har aktiverats
      • Användning av säkerhetsmallen Hisecws.inf för Windows 2000 eller Windows Server 2003 i miljöer där klienterna inte stöder LDAP-signering eller där LDAP-signering på klientsidan inte har aktiverats
    3. Skäl att aktivera den här inställningen

      Vid osignerad nätverkstrafik kan en angripare fånga upp paket mellan klienten och servern, ändra dem och sedan vidarebefordra dem till servern. När detta inträffar på en LDAP-server kan angreppet medföra att beslut fattas utifrån falska förfrågningar från LDAP-klienten. I ett företagsnätverk kan risken för detta minskas med hjälp av starka fysiska säkerhetsåtgärder som bidrar till att skydda nätverkets infrastruktur. IPSec (Internet Protocol security) Authentication Header-läget kan försvåra angrepp av det här slaget mycket. I detta läge genomförs ömsesidig autentisering av IP-trafik och kontrolleras att paketen inte har ändrats.
    4. Skäl att inaktivera den här inställningen
      • Klienter som inte stöder LDAP-signering kan inte genomföra LDAP-frågor mot domänkontrollanter och globala kataloger om NTML-autentisering förhandlas och om rätt Service Pack-versioner inte installeras på Windows 2000-domänkontrollanter.
      • Nätverksspår av LDAP-trafik mellan klienter och servrar krypteras, vilket gör det svårt att granska LDAP-samtal.
      • Servrar med Windows 2000 måste ha Windows 2000 Service Pack 3 (SP3) eller senare när de administreras med program som stöder LDAP-signering och körs från klientdatorer med Windows 2000 SP4, Windows XP eller Windows Server 2003. Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        325465 Windows 2000-domänkontrollanter kräver Service Pack 3 eller senare vid användning av Windows Server 2003-administrationsverktyg (Länken kan leda till en webbplats som är helt eller delvis på engelska)
    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 följande felmeddelande visas:
        Ldap_simple_bind_s() misslyckades: Stark autentisering krävs.
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter med Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg på rätt sätt mot domänkontrollanter med tidigare versioner av Windows 2000 än SP3 när NTLM-autentisering förhandlas.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        325465 Windows 2000-domänkontrollanter kräver Service Pack 3 eller senare vid användning av Windows Server 2003-administrationsverktyg (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter med Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg för domänkontrollanter med tidigare Windows 2000-versioner än SP3 på rätt sätt om IP-adresser används (till exempel "dsa.msc /server=x.x.x.x" där x.x.x.x är en IP-adress).

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        325465 Windows 2000-domänkontrollanter kräver Service Pack 3 eller senare vid användning av Windows Server 2003-administrationsverktyg (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter med Windows 2000 SP4, Windows XP eller Windows Server 2003 fungerar inte vissa Active Directory-administrationsverktyg för domänkontrollanter med tidigare Windows 2000-versioner än SP3 på rätt sätt.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        325465 Windows 2000-domänkontrollanter kräver Service Pack 3 eller senare vid användning av Windows Server 2003-administrationsverktyg (Länken kan leda till en webbplats som är helt eller delvis på engelska)
  3. Domänmedlem: Kräv stark (Windows 2000 eller senare) sessionsnyckel
    1. Bakgrund
      • Inställningen Domänmedlem: Kräv stark (Windows 2000 eller senare) sessionsnyckel avgör en om säker kanal kan upprättas med en domänkontrollant som inte kan kryptera trafik via en säker kanal med en stark, 128-bitars sessionsnyckel. Om den här inställningen aktiveras upprättas en säker kanal med domänkontrollanter som inte kan kryptera data via en säker kanal med en stark nyckel. Om inställningen inaktiveras tillåts 64-bitars sessionsnycklar.
      • Innan du kan aktivera den här inställningen på en medlemsarbetsstation eller server måste alla domänkontrollanter i domänen som medlemmen tillhör kunna kryptera data via en säker kanal med en stark, 128-bitars nyckel. Detta innebär att Windows 2000 eller senare måste köras på alla sådana domänkontrollanter.
    2. Riskabel konfiguration

      Aktivering av Domänmedlem: Kräv stark (Windows 2000 eller senare) sessionsnyckel är en skadlig konfiguration.
    3. Skäl att aktivera den här inställningen
      • Sessionsnycklar som används för att upprätta kommunikation via en säker kanal mellan medlemsdatorer och domänkontrollanter är mycket starkare i Windows 2000 än i tidigare versioner av Microsoft-operativsystem.
      • Närhelst det är möjligt bör dessa starkare sessionsnycklar användas för att skydda kommunikation via en säker kanal från att avlyssnas och från nätverksangrepp med sessionskapning. Vid avlyssning kan nätverksdata läsas eller ändras vid överföringen. Data kan ändras för att dölja eller ändra avsändaren eller dirigeras om.
      Viktigt! En dator som kör Windows Server 2008 R2 eller Windows 7 har bara stöd för starka nycklar när säkerhetskanaler används. Begränsningen förhindrar ett förtroende mellan en Windows NT 4.0-baserad domän och en Windows Server 2008 R2-baserad domän. Dessutom blockerar begränsningen den Windows NT 4.0-baserade domänens medlemskap i datorer som kör Windows 7 eller Windows Server 2008 R2 och vice versa.
    4. Skäl att inaktivera den här inställningen

      Domänen innehåller datorer med andra operativsystem än Windows 2000, Windows XP och 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å datorer med Windows NT 4.0 misslyckas återställning av säkra kanaler med förtroenderelationer mellan Windows NT 4.0- och Windows 2000-domäner med NLTEST, och "Åtkomst nekad"-felmeddelandet visas:
      Det gick inte att upprätta förtroende mellan den primära domänen och den betrodda domänen.
  4. Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid)
    1. Bakgrund
      • Om Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid) aktiveras förhindras att en säker kanal upprättas med en domänkontrollant som inte kan signera eller kryptera alla data för säkra kanaler. För att autentiseringstrafik ska skyddas mot angrepp där paket fångas upp, replay-angrepp och andra typer av nätverksangrepp skapas en kommunikationskanal som kallas säker kanal på Windows-datorer med hjälp av Net Logon-tjänsten för autentisering av datorkonton. Säkra konton kan även användas när en användare i en domän ansluter till en nätverksresurs i en fjärrdomän. Den här flerdomänsautentiseringen, eller vidarebefordring av autentisering, gör att en Windows-dator som har anslutit till en domän kan få tillgång till användarkontodatabasen i sin domän och i alla betrodda domäner.
      • För att inställningen Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid) ska kunna aktiveras på en medlemsarbetsstation måste alla domänkontrollanter i domänen som medlemmen tillhör kunna signera eller kryptera alla data för säkra kanaler. Detta innebär att Windows NT 4.0 med Service Pack 6a (SP6a) eller senare måste köras på alla sådana domänkontrollanter.
      • När Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid) aktiveras medför det också att Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (om möjligt) aktiveras automatiskt.
    2. Riskabel konfiguration

      När Domänmedlem: Kryptera eller signera data för säkra kanaler digitalt (alltid) aktiveras i domäner där inte alla domänkontrollanter kan signera eller kryptera data för säkra kanaler, är det en skadlig konfiguration.
    3. Skäl att aktivera den här inställningen

      Vid osignerad nätverkstrafik kan en angripare fånga upp paket mellan servern och klienten, ändra dem och sedan vidarebefordra dem till klienten. När detta inträffar på en LDAP-server (Lightweight Directory Access Protocol) kan angreppet medföra att beslut fattas på en klient utifrån falska poster från LDAP-katalogen. I ett företagsnätverk kan risken för detta minskas med hjälp av starka fysiska säkerhetsåtgärder som bidrar till att skydda nätverkets infrastruktur. IPSec (Internet Protocol security) Authentication Header-läget kan dessutom försvåra angrepp av det här slaget mycket. I detta läge genomförs ömsesidig autentisering av IP-trafik och kontrolleras att paketen inte har ändrats.
    4. Skäl att inaktivera den här inställningen
      • Datorer i lokala eller externa domäner stöder inte krypterade säkra kanaler
      • Alla domänkontrollanter i domänen har inte lämpliga Service Pack-nivåer för stöd av 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: Medlemsdatorer med Windows 2000 kan inte ansluta till Windows NT 4.0, och följande felmeddelande visas:
        Kontot kan inte användas för inloggning från denna dator.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        281648 Felmeddelande: Kontot kan inte användas för inloggning från denna dator (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Windows NT 4.0-domäner kan inte upprätta ett förtroende med en Windows 2000-domän, och följande felmeddelande visas:
        Kontot kan inte användas för inloggning från denna dator.
        Befintliga förtroenden kan kanske inte heller användas för att autentisera användare från den betrodda domänen. Vissa användare kan ha problem med att logga in i domänen, och ett felmeddelande kan ange att domänen inte kan hittas.
      • Windows XP: Windows XP-klienter som ansluts till Windows NT 4.0-domäner kan inte autentisera inloggningsförsök, och följande felmeddelande kan visas, eller så kan följande händelser registreras i händelseloggen:
        Det går inte att ansluta till domänen. Detta kan bero på att domänkontrollanten är otillgänglig eller på att ditt datorkonto inte kunde hittas.

        Händelse 5723: Sessionen från datorn Datornamn kunde inte utföra verifiering. Namnet på kontot som refereras i säkerhetsdatabasen är Datornamn. Följande fel uppstod: Åtkomst nekad.

        Händelse 3227: Sessionen till Windows NT eller Windows 2000-domänkontrollanten Servernamn i domänen Domännamn misslyckades pga Servernamn inte stöder att Netlogon-sessionen signeras eller sluts. Uppgradera domänkontrollanten, eller ange värdet 0 till registerposten RequireSignOrSeal på den här datorn.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        318266 En Windows XP-klient kan inte logga in i en Windows NT 4.0-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Microsoft-nätverk: På Microsoft-nätverksklienter visas något av följande felmeddelanden:
        Inloggningsfel: okänt användarnamn eller felaktigt lösenord.
        Det finns ingen användarsessionsnyckel för angiven inloggningssession.
  5. Klient för Microsoft-nätverk: signera kommunikation digitalt (alltid)
    1. Bakgrund

      SMB (Server Message Block) är ett resursdelningsprotokoll som stöds av många Microsoft-operativsystem och ligger till grund för NetBIOS (network basic input/output system) och många andra protokoll. Vid SMB-signering autentiseras både användaren och servern som är värd för data. Om autentiseringsprocessen misslyckas på någon sida sker ingen dataöverföring.

      Aktivering av SMB-signering startar under SMB-protokollförhandling. SMB-signeringsprinciperna avgör om klientkommunikation alltid signeras digitalt på datorn.

      SMB-autentiseringsprotokollet i Windows 2000 stöder ömsesidig autentisering, vilket förhindrar angrepp som bygger på att paket fångas upp på vägen. SMB-autentiseringsprotokollet i Windows 2000 stöder även ömsesidig meddelandeautentisering, vilket bidrar till att förhindra aktiva meddelandeangrepp. Autentiseringen möjliggörs av att SMB-signeringen placerar en digital signatur i varje SMB som sedan verifieras av klienten och servern.

      För att kunna använda SMB-signering måste du aktivera SMB-signering eller kräva SMB-signering både på SMB-klienten och på SMB-servern. Om SMB-signering aktiveras på en server används paketsigneringsprotokollet under alla följande sessioner på klienter som även är aktiverade för SMB-signering. Om SMB-signering krävs på en server kan en klient inte upprätta en session om klienten inte aktiveras eller krävs för SMB-signering.

      Aktivering av digital signering i nätverk med hög säkerhet bidrar till att förhindra personifiering av klienter och servrar. Denna typ av personifiering kallas sessionskapning. En angripare som har tillgång till samma nätverk som klienten eller servern använder sessionskapningsverktyg för att avbryta, avsluta eller stjäla en pågående session. En angripare kan fånga upp och ändra osignerade SMB-paket, ändra trafiken och sedan vidarebefordra den så att servern kanske utför oönskade åtgärder. Angriparen kan även utge sig för att vara servern eller klienten efter en legitim autentisering och få obehörigt tillträde till data.

      SMB-protokollet som används för fil- och skrivardelning på datorer med Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003 stöder ömsesidig autentisering. Ömsesidig autentisering stänger sessionskapningsangrepp och stöder meddelandeautentisering, vilket förhindrar angrepp som bygger på att paket fångas upp på vägen. SMB-signering ger denna autentisering genom att en digital signatur placeras i varje SMB och sedan verifieras av både klienten och servern.

      Obs!
      • En alternativ motåtgärd som kan bidra till att skydda all nätverkstrafik är att aktivera digitala signaturer med IPSec. Det finns maskinvarubaserade acceleratorer för IPSec-kryptering och IPSec-signering som kan användas för att minimera prestandapåverkan från serverns processor. Inga sådana acceleratorer är tillgängliga för SMB-signering.

        Mer information finns i kapitlet "Digitally sign server communications" på följande Microsoft MSDN-webbplats:
        http://msdn.microsoft.com/sv-se/library/ms814149.aspx
        Konfigurera SMB-signering med hjälp av Redigeraren för grupprincipobjekt, eftersom en ändring av ett lokalt registervärde inte har någon inverkan om det finns en övergripande domänprincip.
      • I Windows 95, Windows 98 och Windows 98, andra utgåvan, används SMB-signering på katalogtjänstklienten när denna autentiserar med Windows Server 2003-servrar med hjälp av NTLM-autentisering. SMB-signering används emellertid inte på klienterna när de autentiserar med servrarna med hjälp av NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsbegäranden från dessa klienter. Se punkt 10: "Nätverkssäkerhet: Autentiseringsnivå för Lan Manager."
    2. Riskabel konfiguration

      Följande konfiguration är skadlig: Både inställningen Klient för Microsoft-nätverk: Signera kommunikation digitalt (alltid) och inställningen Klient för Microsoft-nätverk: Signera kommunikation digitalt (om servern tillåter) lämnas som "Inte definierad" eller inaktiverad. De här inställningarna gör att omdirigeraren kan skicka lösenord med oformaterad text till SMB-servrar som inte kommer från Microsoft och som inte stöder lösenordskryptering under autentisering.
    3. Skäl att aktivera den här inställningen

      Om Klient för Microsoft-nätverk: Signera kommunikation digitalt (alltid) aktiveras måste klienter signera SMB-trafik när de kontaktar servrar som inte kräver SMB-signering, vilket gör klienterna mindre sårbara för sessionskapning.
    4. Skäl att inaktivera den här inställningen
      • Om Klient för Microsoft-nätverk: Signera kommunikation digitalt (alltid) aktiveras hindras klienterna från att kommunicera med målservrar som inte stöder SMB-signering.
      • Om datorerna konfigureras för att ignorera all osignerad SMB-kommunikation kan tidigare program och operativsystem inte ansluta.
    5. Symboliskt namn:

      RequireSMBSignRdr
    6. Registersökväg:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature
    7. Exempel på kompatibilitetsproblem
      • Windows NT 4.0: Det går inte att å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 ett felmeddelande med "Åtkomst nekad" visas.
      • Windows XP: Kopiering av filer från Windows XP klienter till servrar med Windows 2000 eller Windows Server 2003 kan ta längre tid.
      • Det går inte att mappa en nätverksenhet från en klient om den här inställningen är aktiverad, och följande felmeddelande visas:
        Kontot kan inte användas för inloggning från denna dator.
    8. Krav på omstart

      Starta om datorn eller tjänsten Workstation genom att skriva följande kommandon vid en kommandotolk. Tryck på RETUR efter varje kommando.
      net stop workstation
      net start workstation
  6. Microsoft-nätverksserver: signera kommunikation digitalt (alltid)
    1. Bakgrund
      • SMB (Server Messenger Block) är ett resursdelningsprotokoll som stöds av många Microsoft-operativsystem och ligger till grund för NetBIOS (network basic input/output system) och många andra protokoll. Vid SMB-signering autentiseras både användaren och servern som är värd för data. Om autentiseringsprocessen misslyckas på någon sida sker ingen dataöverföring.

        Aktivering av SMB-signering startar under SMB-protokollförhandling. SMB-signeringsprinciperna avgör om klientkommunikation alltid signeras digitalt på datorn.

        SMB-autentiseringsprotokollet i Windows 2000 stöder ömsesidig autentisering, vilket förhindrar angrepp som bygger på att paket fångas upp på vägen. SMB-autentiseringsprotokollet i Windows 2000 stöder även ömsesidig meddelandeautentisering, vilket bidrar till att förhindra aktiva meddelandeangrepp. Autentiseringen möjliggörs av att SMB-signeringen placerar en digital signatur i varje SMB som sedan verifieras av klienten och servern.

        För att kunna använda SMB-signering måste du aktivera SMB-signering eller kräva SMB-signering både på SMB-klienten och på SMB-servern. Om SMB-signering aktiveras på en server används paketsigneringsprotokollet under alla följande sessioner på klienter som även är aktiverade för SMB-signering. Om SMB-signering krävs på en server kan en klient inte upprätta en session om klienten inte aktiveras eller krävs för SMB-signering.

        Aktivering av digital signering i nätverk med hög säkerhet bidrar till att förhindra personifiering av klienter och servrar. Denna typ av personifiering kallas sessionskapning. En angripare som har tillgång till samma nätverk som klienten eller servern använder sessionskapningsverktyg för att avbryta, avsluta eller stjäla en pågående session. En angripare kan fånga upp och ändra osignerade SMB-paket (Subnet Bandwidth Manager), ändra trafiken och sedan vidarebefordra den så att servern kanske utför oönskade åtgärder. Angriparen kan även utge sig för att vara servern eller klienten efter en legitim autentisering och få obehörigt tillträde till data.

        SMB-protokollet som används för fil- och skrivardelning på datorer med Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003 stöder ömsesidig autentisering. Ömsesidig autentisering förhindrar sessionskapningsangrepp och stöder meddelandeautentisering, vilket förhindrar angrepp som bygger på att paket fångas upp på vägen. SMB-signering ger denna autentisering genom att en digital signatur placeras i varje SMB och sedan verifieras av både klienten och servern.
      • En alternativ motåtgärd som kan bidra till att skydda all nätverkstrafik är att aktivera digitala signaturer med IPSec. Det finns maskinvarubaserade acceleratorer för IPSec-kryptering och IPSec-signering som kan användas för att minimera prestandapåverkan från serverns processor. Inga sådana acceleratorer är tillgängliga för SMB-signering.
      • I Windows 95, Windows 98 och Windows 98, andra utgåvan, används SMB-signering på katalogtjänstklienten när den autentiserar med Windows Server 2003-servrar med hjälp av NTLM-autentisering. SMB-signering används emellertid inte på klienterna när de autentiserar med servrarna med hjälp av NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsbegäranden från dessa klienter. Se punkt 10: "Nätverkssäkerhet: Autentiseringsnivå för Lan Manager."
    2. Riskabel konfiguration

      Följande konfiguration är skadlig: Aktivering av inställningen Microsoft-nätverksserver: Signera kommunikation digitalt (alltid) på servrar och domänkontrollanter med åtkomst från inkompatibla klientdatorer med Windows-operativsystem och operativsystem från andra tillverkare i lokala eller externa domäner.
    3. Skäl att aktivera den här inställningen
      • SMB-signering stöds på alla klientdatorer där den här inställningen aktiveras direkt genom registret eller genom grupprincipinställningen. Med andra ord har alla klientdatorer där inställningen är aktiverad Windows 95 med katalogtjänstklienten, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional eller Windows Server 2003.
      • Om Microsoft-nätverksserver: Signera kommunikation digitalt (alltid) inaktiveras så inaktiveras SMB-signering fullständigt. Om SMB-signering inaktiveras fullständigt blir datorerna mer sårbara för sessionskapning.
    4. Skäl att inaktivera den här inställningen
      • Om inställningen aktiveras kan det medföra långsammare filkopiering och sämre nätverksprestanda på klientdatorer.
      • Om inställningen aktiveras kan klienter som inte kan förhandla SMB-signering inte kommunicera med servrar och domänkontrollanter. Detta medför att åtgärder som domänanslutningar, användar- och datorautentisering samt nätverksåtkomst inte fungerar.
    5. Symboliskt namn:

      RequireSMBSignServer
    6. Registersökväg:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)
    7. Exempel på kompatibilitetsproblem
      • Windows 95: Inloggningsautentisering misslyckas på Windows 95-klienter utan klienten för katalogtjänster, och följande felmeddelande visas:
        Det angivna domänlösenordet är inte korrekt, eller så har åtkomst till inloggningsservern nekats.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        811497 Felmeddelande vid inloggning av Windows 95- eller Windows NT 4.0-klient i en Windows Server 2003-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: På klientdatorer med tidigare Windows NT 4.0-versioner än Service Pack 3 (SP3) misslyckas inloggningsautentiseringen, och följande felmeddelande visas:
        Du loggades inte in. Kontrollera att användarnamnet och domänen är korrekta, skriv sedan ditt lösenord igen.
        Vissa SMB-servrar som inte kommer från Microsoft stöder endast okrypterade lösenordsutbyten under autentisering. (Dessa utbyten kallas även utbyten med "oformaterad text".) Från och med Windows NT 4.0 SP3 skickar inte SMB-omdirigeraren ett okrypterat lösenord under autentisering till en SMB-server om du inte lägger till en särskild registerpost.
        Om du vill aktivera okrypterade lösenord för SMB-klienten i Windows NT 4.0 SP 3 och senare ändrar du registret så här: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters
        Värdenamn: EnablePlainTextPassword
        Datatyp: REG_DWORD
        Data: 1

        Om du vill veta mer om närliggande ämnen klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
        224287 Felmeddelande: Följande systemfel har inträffat: 1240. Kontot kan inte användas för inloggning från denna dator. (Länken kan leda till en webbplats som är helt eller delvis på engelska)
        166730 Okrypterade lösenord kan förhindra anslutning med Service Pack 3 till SMB-servrar (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows Server 2003:Säkerhetsinställningar på domänkontrollanter med Windows Server 2003 är som standard konfigurerade så att de bidrar till att förhindra att kommunikation med domänkontrollanter fångas upp eller ändras av angripare. För att användare ska kunna kommunicera med en domänkontrollant som har Windows Server 2003 måste både SMB-signering och kryptering eller signering av trafik via en säker kanal användas på klientdatorerna. SMB-paketsignering är som standard inte aktiverad på klienter som har Windows NT 4.0 med Service Pack 2 (SP2) eller tidigare och på klienter med Windows 95. Därför kan dessa klienter kanske inte autentisera till en domänkontrollant med Windows Server 2003.
      • Principinställningar för Windows 2000 och Windows Server 2003:Beroende på dina installationsbehov och din konfiguration rekommenderar vi att du ställer in följande principinställningar på den lägsta nödvändiga omfattningen i snapin-hierarkin i Principeditorn i Microsoft Management Console:
        • Computer Configuration\Windows Security Settings\Security Options
        • Skicka okrypterade lösenord vid anslutning till SMB-servrar från tredjepartsleverantörer (Den här inställningen gäller Windows 2000.)
        • Klient för Microsoft-nätverk: Skicka okrypterade lösenord till SMB-servrar från tredjepartsleverantörer (Den här inställningen gäller Windows Server 2003.)

        Obs! I vissa tredjeparts-CIFS-servrar, till exempel äldre Samba-versioner, går det inte att använda krypterade lösenord.
      • Följande klienter är inkompatibla med inställningen Microsoft-nätverksservern: Signera kommunikation digitalt (alltid):
        • Apple Computer, Inc., Mac OS X-klienter
        • Microsoft MS-DOS-nätverksklienter (till exempel Microsoft LAN Manager)
        • Microsoft Windows for Workgroups-klienter
        • Microsoft Windows 95-klienter utan klienten Katalogtjänster
        • Microsoft Windows NT 4.0-datorer utan SP3 eller senare
        • Novell Netware 6 CIFS-klienter
        • SAMBA SMB-klienter som saknar stöd för SMB-signering
    8. Krav på omstart

      Starta om datorn eller tjänsten Server genom att skriva följande kommandon vid en kommandotolk. Tryck på RETUR efter varje kommando.
      net stop server
      net start server
  7. Nätverksåtkomst: Tillåt översättning av SID/namn anonymt
    1. Bakgrund

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

      Aktivering av inställningen Nätverksåtkomst: Tillåt översättning av SID/namn anonymt är en skadlig konfiguration.
    3. Skäl att aktivera den här inställningen

      Om inställningen Nätverksåtkomst: Tillåt översättning av SID/namn anonymt inaktiveras kan tidigare operativsystem eller program kanske inte kommunicera med Windows Server 2003-domäner. Följande operativsystem, tjänster eller program fungerar till exempel kanske inte:
      • Remote Access Service-servrar med Windows NT 4.0
      • Microsoft SQL Server som körs på datorer med Windows NT 3.x eller Windows NT 4.0
      • Remote Access Service som körs på datorer med Windows 2000 som finns i Windows NT 3.x- eller Windows NT 4.0-domäner
      • SQL Server som körs på datorer med Windows 2000 som finns i Windows NT 3.x- eller Windows NT 4.0-domäner
      • Användare i en Windows NT 4.0-resursdomän som vill ge behörighet för åtkomst till filer, delade mappar och registerobjekt till användarkonton från kontodomäner med Windows Server 2003-domänkontrollanter
    4. Skäl att inaktivera den här inställningen

      Om den här inställningen är aktiverad kan en angripare utnyttja det välkända administratörs-SID:et för att få tillgång till det verkliga namnet på det inbyggda administratörskontot, även om kontot har fått ett nytt namn. Angriparen kan sedan använda kontonamnet för att inleda ett angrepp för att gissa lösenord.
    5. Symboliskt namn: Inget
    6. Registersökväg: Ingen. Sökvägen anges i UI-kod.
    7. Exempel på kompatibilitetsproblem

      Windows NT 4.0: På datorer i Windows NT 4.0-resursdomäner visas felmeddelandet "Okänt konto" i ACL Editor om resurser, inklusive delade mappar, delade filer och registerobjekt, säkras 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
      • Inställningen Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton avgör vilka ytterligare behörigheter som ska ges för anonyma anslutningar till datorn. I Windows kan anonyma användare utföra vissa aktiviteter som att räkna upp namnen på arbetsstations- och server-SAM-konton (Security Accounts Manager) och nätverksresurser. En administratör kan exempelvis använda det här för att bevilja åtkomst till användare i en betrodd domän som inte har något ömsesidigt förtroende. När en session har gjorts har en anonym användare samma åtkomst som beviljats gruppen Alla, baserat på inställningen för Nätverksåtkomst: Låt behörigheter för Alla gälla även för anonyma användare eller objektets DACL (discretionary access control list).

        Normalt begärs anonyma anslutningar av tidigare klienter (klienter på lägre nivå) under konfigurationen av SMB-sessionen. I dessa fall visar ett nätverksspår att SMB-PID (Process ID) är klientomdirigeraren, som 0xFEFF i Windows 2000 och 0xCAFE i Windows NT. Försök till anonyma anslutningar kan även göras från RPC.
      • Viktigt!Den här inställningen har ingen inverkan på domänkontrollanter. På domänkontrollanter styrs det här funktionssättet av förekomsten av "NT AUTHORITY\ANONYMOUS LOGON" i "Åtkomst till äldre operativsystem (före Windows 2000)".
      • I Windows 2000 hanteras registervärdet
        RestrictAnonymous
        med en liknande inställning, Ytterligare begränsningar för anonyma anslutningar. Värdet finns här:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
        . Om du vill veta mer om registervärdet RestrictAnonymous klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
        246261 Använda registervärdet RestrictAnonymous i Windows 2000 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
        143474 Begränsa information som är tillgänglig för användare med anonym inloggning (Länken kan leda till en webbplats som är helt eller delvis på engelska)
    2. Riskabla konfigurationer:

      Aktivering av inställningen Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton ger en skadlig konfiguration ur ett kompatibilitetsperspektiv. Om den inaktiveras ger det en skadlig konfiguration ur ett säkerhetsperspektiv.
    3. Skäl att aktivera den här inställningen

      En obehörig användare kan ange kontonamn anonymt och sedan använda informationen för att försöka gissa lösenord eller lura användare att avslöja sina lösenord eller annan säkerhetsinformation.
    4. Skäl att inaktivera den här inställningen

      Om den här inställningen är aktiverad går det inte att upprätta förtroenden med Windows NT 4.0-domäner. Inställningen medför även problem med tidigare klienter som 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 får ingen information om operativsystem och skriver "Unknown" i egenskapen OperatingSystemNameandVersion.
    • Windows 95, Windows 98: Windows 95- och Windows 98-klienter kan inte ändra lösenord.
    • Windows NT 4.0: Medlemsdatorer med Windows NT 4.0 kan inte autentiseras.
    • Windows 95, Windows 98: Datorer med Windows 95 eller Windows 98 kan inte autentiseras av Microsoft-domänkontrollanter.
    • Windows 95, Windows 98: Användare vid datorer med Windows 95 eller Windows 98 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
      • Inställningen Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och resurser (även kallad RestrictAnonymous) avgör om anonym uppräkning av SAM-konton (Security Accounts Manager) och resurser tillåts. I Windows kan anonyma användare utföra vissa aktiviteter som att räkna upp namnen på domänkonton (användare, datorer och grupper) och nätverksresurser. Detta är praktiskt, till exempel när en administratör vill ge å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 hanteras registervärdet
        RestrictAnonymous
        med en liknande inställning, Ytterligare begränsningar för anonyma anslutningar. Värdet finns här:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
    2. Riskabel konfiguration

      Aktivering av inställningen Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och resurser är en skadlig konfiguration.
    3. Skäl att aktivera den här inställningen
      • Aktivering av inställningen Nätverksåtkomst: Tillåt inte anonym uppräkning av SAM-konton och resurser förhindrar att användare och datorer med anonyma konton räknar upp SAM-konton och resurser.
    4. Skäl att inaktivera den här inställningen
      • Om inställningen är aktiverad kan en obehörig användare ange kontonamn anonymt och sedan använda informationen för att försöka gissa lösenord eller lura användare att avslöja sina lösenord eller annan 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. Inställningen medför även problem med tidigare klienter som Windows NT 3.51-klienter och Windows 95-klienter som försöker använda resurser på servern.
      • Det blir omöjligt att ge åtkomst till användare av resursdomäner, eftersom administratörer i domänen med förtroende inte kan räkna upp listor med konton i den andra domänen. Användare som kommer åt fil- och skrivarservrar anonymt kan inte visa en lista över delade nätverksresurser på servrarna. Användarna måste autentisera innan de kan visa listor över 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ändare 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. Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        198941 Användare kan inte byta lösenord vid inloggning (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Tillägg av användare eller globala grupper från betrodda Windows 2000-domäner till lokala Windows NT 4.0-grupper i Kontohanteraren misslyckas, och följande felmeddelande visas:
        Det finns för tillfället inte några inloggningsservrar tillgängliga som kan hantera inloggningsförfrågan.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        296405 Registervärdet "RestrictAnonymous" kan bryta förtroendet till en Windows 2000-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Datorer med Windows NT 4.0 kan inte ansluta till domäner under installationen eller utnyttja användargränssnittet för att ansluta till en domän.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        184538 Felmeddelande: det gick inte att hitta en kontrollant för den här domänen (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Windows NT 4.0: Ett försök att upprätta ett förtroende med Windows NT 4.0-resursdomäner misslyckas med följande felmeddelande när RestrictAnonymous är aktiverat i den betrodda domänen:
        Det går inte att hitta domänkontrollanten för denna domän.
        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        178640 Det gick inte att hitta domänkontrollanten vid upprättande av ett förtroende (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Användare som loggar in på Terminal Server-datorer med Windows NT 4.0 mappar till standardhemkatalogen i stället för till hemkatalogen som anges i Kontohanteraren för domäner.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        236185 Användarprofiler och arbetsmappar för Terminal Server ignoreras efter installation av SP4 eller senare (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows NT 4.0: Windows NT 4.0-reservdomänkontrollanter kan inte starta Net Logon-tjänsten, för att hämta en lista över backup browsers eller för att synkronisera SAM-databasen från Windows 2000 eller från Windows Server 2003-domänkontrollanter i samma domän.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        293127 Net Logon-tjänsten på en Windows NT 4.0-reservdomänkontrollant fungerar inte i en Windows 2000-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000: Datorer med Windows 2000 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 aktiveras i klientdatorns lokala säkerhetsprincip.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        280329 Användare kan inte hantera eller visa skrivaregenskaper (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000: Windows 2000-domänanvändare kan inte lägga till nätverksskrivare från Active Directory, men kan lägga till skrivare efter att ha valt dem från trädvyn.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        318866 Outlook-klienter kan inte visa global adresslista efter installation av Samlat säkerhetspaket 1 (SRP1) på global katalogserver (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000: På datorer med Windows 2000 kan inte ALC Editor lägga till användare eller globala grupper från betrodda Windows NT 4.0-domäner.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        296403 Värdet RestrictAnonymous bryter förtroendet i en miljö med blandade domäner (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • ADMT version 2: Lösenordsmigrering för användarkonton som migreras mellan skogar med Active Directory Migration Tool (ADMT) version 2 fungerar inte.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        322981 Felsökning av lösenordsmigrering mellan skogar med ADMTv2 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Outlook-klienter: Den globala adresslistan visas tom för Microsoft Exchange Outlook-klienter.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        318866 Outlook-klienter kan inte visa global adresslista efter installation av Samlat säkerhetspaket 1 (SR) på global katalogserver (Länken kan leda till en webbplats som är helt eller delvis på engelska)
        321169 Dåliga SMB-prestanda vid kopiering av filer från Windows XP till en Windows 2000-domänkontrollant (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • SMS: Microsoft Systems Management Server (SMS) Network Discovery får inte information om operativsystem. Därför skrivs "Unknown" i egenskapen OperatingSystemNameandVersion i SMS DDR-egenskapen i DDR (Discovery Data Record).

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        229769 Så avgörs om en klientkonfigurationsbegäran ska genereras i Discovery Data Manager (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • SMS: När SMS Administrator User Wizard används för att bläddra efter användare och grupper visas inga. Dessutom kan avancerade klienter inte kommunicera med hanteringspunkten. Anonym åtkomst krävs på hanteringspunkten.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        302413 Inga användare eller grupper visas i Administrator User Wizard (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • SMS: När du använder Network Discovery-funktionen i SMS 2.0 och i Remote Client Installation med alternativet Topology, client, and client operating systems aktiverat kan det hända att datorer upptäcks men inte installeras.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        311257 Resurser upptäcks inte om anonyma anslutningar stängs av (Länken kan leda till en webbplats som är helt eller delvis på engelska)
  10. Nätverkssäkerhet: Autentiseringsnivå för LAN Manager
    1. Bakgrund

      LM-autentisering (LAN Manager) är protokollet som används för att autentisera Windows-klienter för nätverksåtgärder, inklusive domänanslutningar, åtkomst till nätverksresurser samt användar- eller datorautentisering. LM-autentiseringsnivån avgör vilket autentiseringsprotokoll för anrop/svar som förhandlas mellan klienten och serverdatorerna. Närmare bestämt avgör LM-autentiseringsnivån vilka autentiseringsprotokoll som förhandlas från klienten eller som accepteras från servern. Det inställda värdet för LmCompatibilityLevel avgör vilket autentiseringsprotokoll för anrop/svar som används för nätverksinloggningar. Värdet påverkar autentiseringsprotokollnivån som används av klienter, vilken nivå av sessionssäkerhet som förhandlas samt autentiseringsnivån som accepteras av servrar, enligt följande tabell.

      Möjliga inställningar är:
      Dölj tabellenVisa tabellen
      VärdeInställningBeskrivning
      0 Skicka LM & NTLM-svarPå klienter används LM- och NTLM-autentisering och aldrig NTLMv2-sessionssäkerhet; på domänkontrollanter accepteras LM-, NTLM- och NTLMv2-autentisering.
      1Skicka LM & NTLM - använd NTLMv2-sessionssäkerhet om sådan förhandlatsPå klienter används LM- och NTLM-autentisering, samt NTLMv2-sessionssäkerhet om servern stöder det; på domänkontrollanter accepteras LM-, NTLM- och NTLMv2-autentisering.
      2Skicka endast NTLM-svarPå klienter används endast NTLM-autentisering, samt NTLMv2-sessionssäkerhet om servern stöder det; på domänkontrollanter accepteras LM-, NTLM- och NTLMv2-autentisering.
      3Skicka endast NTLMv2-svarPå klienter används endast NTLMv2-autentisering, samt NTLMv2-sessionssäkerhet om servern stöder det; på domänkontrollanter accepteras LM-, NTLM- och NTLMv2-autentisering.
      4Skicka endast NTLMv2-svar/neka LMPå klienter används endast NTLMv2-autentisering, samt NTLMv2-sessionssäkerhet om servern stöder det. Domänkontrollanter nekar LM och accepterar endast NTLM- och NTLMv2-autentisering.)
      5Skicka endast NTLMv2-svar/neka LM & NTLMPå klienter används endast NTLMv2-autentisering, samt NTLMv2-sessionssäkerhet om servern stöder det; på domänkontrollanter nekas LM och NTLM, och endast NTLMv2-autentisering accepteras.
      Obs! I Windows 95, Windows 98 och Windows 98, andra utgåvan, används SMB-signering på katalogtjänstklienten när den autentiserar med Windows Server 2003-servrar med hjälp av NTLM-autentisering. SMB-signering används emellertid inte på klienterna när de autentiserar med servrarna med hjälp av NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsbegäranden från dessa klienter.

      Kontrollera LM-autentiseringsnivån Du måste ändra principen på servern så att NTLM tillåts, eller så måste du konfigurera klientdatorn så att NTLMv2 stöds.

      Om principen har värdet (5) Skicka endast NTLMv2-svar/neka LM & NTLM på måldatorn som du vill ansluta till, måste du antingen sänka inställningen på den datorn eller använda samma säkerhetsinställning som på källdatorn du ansluter från.

      Hitta rätt plats där du kan ändra autentiseringsnivån för LAN Manager så att klienten och servern har samma nivå. När du har hittat principen som anger LAN Manager-autentiseringsnivån, och du vill ansluta till och från datorer med tidigare versioner av Windows, sänker du värdet till minst (1) Skicka LM & NTLM - använd NTLM version 2-sessionssäkerhet om sådan förhandlats. Ett resultat av inkompatibla inställningar är följande: om servern kräver NTLMv2 (värde 5), men klienten endast är konfigurerad för LM och NTLMv1 (värde 0), drabbas användaren som försöker autentisera av ett inloggningsfel på grund av felaktigt lösenord, och antalet felaktiga lösenord ökar. Om kontoutelåsning har konfigurerats, låses användaren kanske slutligen ut.

      Du måste kanske till exempel se på domänkontrollanten eller på domänkontrollantens principer.

      Undersöka domänkontrollanten
      Obs! Du måste kanske upprepa följande åtgärder på alla domänkontrollanter.
      1. Klicka på Start, peka på Program och klicka sedan på Administrationsverktyg.
      2. Expandera Lokala principer under Lokala säkerhetsinställningar.
      3. Klicka på Säkerhetsalternativ.
      4. Dubbelklicka på Nätverkssäkerhet: Autentiseringsnivå för LAN manager, och klicka sedan på lämpligt värde i listan.
      Om Faktisk inställning och Lokal inställning är samma har principen ändrats på denna nivå. Om inställningarna skiljer sig åt måste du kontrollera domänkontrollantens princip för att se om inställningen Nätverkssäkerhet: Autentiseringsnivå för LAN manager definieras där. Om inställningen inte är definierad där granskar du domänkontrollantens principer.

      Undersöka domänkontrollantens principer
      1. Klicka på Start, peka på Program och klicka sedan på Administrationsverktyg.
      2. I Säkerhetsprincip för domänkontrollant expanderar du Säkerhetsinställningar och sedan Lokala principer.
      3. Klicka på Säkerhetsalternativ.
      4. Dubbelklicka på Nätverkssäkerhet: Autentiseringsnivå för LAN manager, och klicka sedan på lämpligt värde i listan.
      Obs!
      • Du måste kanske även kontrollera principer som är länkade på plats-, domän- eller organisationsenhetsnivå för att fastställa var du måste konfigurera autentiseringsnivån för LAN manager.
      • Om du implementerar en grupprincipinställning som standarddomänprincip används denna på alla datorer i domänen.
      • Om du implementerar en grupprincipinställning som standarddomänkontrollantprincip gäller denna endast servrar i domänkontrollantens organisationsenhet.
      • Det är lämpligt att ställa in autentiseringsnivån för LAN manager på det lägsta värdet för nödvändig omfattning i principtillämpningshierarkin.
      Uppdatera principen efter ändringar. (Om ändringen görs på nivån för lokala säkerhetsinställningar genomförs den omedelbart. Du måste emellertid starta om klienterna innan du provar.)

      Som standard uppdateras grupprincipinställningar på domänkontrollanter var femte minut. Om du vill framtvinga omedelbar uppdatering av principinställningar i Windows 2000 eller senare använder du kommandot gpupdate.

      Genom kommandot gpupdate /force uppdateras lokala grupprincipinställningar och grupprincipinställningar som baseras på Active Directory-katalogtjänsten, inklusive säkerhetsinställningar. Detta kommando ersätter det nu föråldrade alternativet /refreshpolicy för kommandot secedit.

      I kommandot gpupdate används följande syntax:
      gpupdate [/target:{dator|användare}] [/force] [/wait:värde] [/logoff] [/boot]

      Aktivera det nya grupprincipobjektet genom att använda kommandot gpupdate för att manuellt aktivera alla principinställningar igen. Gör detta genom att skriva följande vid kommandotolken och sedan trycka på RETUR:
      GPUpdate /Force
      Kontrollera i programmets händelselogg att principinställningen har tillämpats utan problem.

      I Windows XP och Windows Server 2003 kan du använda snapin-modulen Gällande principuppsättning för att se vilken inställning som gäller. Klicka på Start, Kör, skriv rsop.msc och klicka på OK.

      Om problemet kvarstår efter att du har ändrat principen startar du om Windows-servern och kontrollerar sedan att problemet är borta.

      Obs! Om du har flera domänkontrollanter med Windows 2000 eller Windows Server 2003, eller båda, måste du kanske replikera Active Directory för att säkerställa att dessa domänkontrollanter får de uppdaterade ändringarna omedelbart.

      Inställningen kan verka ha det lägsta värdet i den lokala säkerhetsprincipen. Om du kan tvinga fram inställningen med hjälp av en säkerhetsdatabas kan du även ange autentiseringsnivån för LAN Manager i registret genom att redigera posten LmCompatibilityLevel i följande registerundernyckel:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
      Windows Server 2003 har en ny standardinställning för användning av endast NTLMv2. Som standard har domänkontrollanter med Windows Server 2003 och Windows 2000 Server SP3 aktiverat principen "Microsoft-nätverksserver: Signera kommunikation digitalt (alltid)". Den här inställningen kräver att SMB-paketsignering sker på SMB-servern. Ändringar av Windows Server 2003 gjordes därför att domänkontrollanter, filservrar, nätverksinfrastrukturservrar och webbservrar i alla organisationer kräver olika inställningar för maximal säkerhet.

      Om du vill implementera NTLMv2-autentisering i nätverket måste du se till att alla datorer i domänen är inställda för användning av denna autentiseringsnivå. Om du installerar Active Directory-klienttillägg för Windows 95 eller Windows 98 och Windows NT 4.0 används samma förbättrade säkerhetsfunktioner som i NTLMv2. Eftersom klientdatorer med följande operativsystem inte påverkas av Windows 2000-grupprincipobjekt måste du kanske konfigurera dessa klienter manuellt:
      • Microsoft Windows NT 4.0
      • Microsoft Windows Millennium Edition
      • Microsoft Windows 98
      • Microsoft Windows 95
      Obs! Om du aktiverar principen Nätverkssäkerhet: Lagra inte Lan Manager-hashvärden vid nästa lösenordsändring eller ger registernyckeln NoLMHash ett värde, kan klienter med Windows 95 eller Windows 98 men utan katalogtjänstklienten inte logga in i domänen efter en lösenordsändring.

      Många CIFS-servrar från andra tillverkare, till exempel Novell Netware 6, kan inte identifiera NTLMv2 och använder endast NTLM. Därför tillåter högre nivåer än 2 inte anslutningar.

      Om du vill veta mer om hur du konfigurerar autentiseringsnivån för LAN manager klickar du på artikelnumren nedan och läser artiklarna i Microsoft Knowledge Base:
      147706 Inaktivera LM-autentisering i Windows NT (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      175641 LMCompatibilityLevel och dess effekter (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      299656 Förhindra att ett LAN manager-hashvärde av lösenordet lagras i Active Directory och på lokala SAM-databaser (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      312630 Inloggningsinformation efterfrågas upprepade gånger i Outlook (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      Om du vill veta mer om LM-autentiseringsnivåer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
      239869 Aktivera NTLM 2-autentisering (Länken kan leda till en webbplats som är helt eller delvis på engelska)
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Icke-restriktiva inställningar som skickar lösenord i klartext och nekar NTLMv2-förhandling
      • Restriktiva inställningar som förhindrar att inkompatibla klienter eller domänkontrollanter förhandlar fram ett gemensamt autentiseringsprotokoll
      • Kräva NTLMv2-autentisering på datorer och domänkontrollanter med tidigare Windows NT 4.0-versioner än Service Pack 4 (SP4)
      • Kräva NTLMv2-autentisering på Windows 95- eller Windows 98-klienter utan Windows-katalogtjänstklienten.
      • Om du markerar kryssrutan Kräv NTLMv2-sessionssäkerhet i snapin-modulen Principeditorn i Microsoft Management Console på en dator med Windows Server 2003 eller Windows 2000 Service Pack 3 och sänker LAN manager-autentiseringsnivån till 0, uppstår det en konflikt mellan de båda inställningarna, och följande felmeddelande visas i filen Secpol.msc eller GPEdit.msc:
        Det går inte att öppna den lokala principdatabasen. Ett okänt fel uppstod när databasen skulle öppnas.
        Mer information om verktyget Säkerhetskonfiguration och -analys finns i hjälpfilerna för Windows 2000 eller Windows Server 2003.

        Om du vill veta mer om hur du analyserar säkerhetsnivåer i Windows 2000 och Windows Server 2003 klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
        313203 Analysera systemsäkerhet i Windows 2000 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
        816580 Analysera systemsäkerhet i Windows Server 2003 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
    3. Skäl att inaktivera den här inställningen
      • Du vill höja det lägsta gemensamma autentiseringsprotokollet som stöds av klienter och domänkontrollanter i organisationen.
      • Om säker autentisering är ett krav för verksamheten vill du förhindra förhandling av LM- och NTLM-protokoll.
    4. Skäl att inaktivera den här inställningen

      Kraven på klient- eller serverautentisering, eller bådadera, har ökat till den punkt där autentisering via ett gemensamt protokoll inte kan genomföras.
    5. Symboliskt namn:

      LmCompatibilityLevel
    6. Registersökväg:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
    7. Exempel på kompatibilitetsproblem
      • Windows Server 2003: NTLMv2-svarsinställningen i Windows Server 2003 Skicka NTML-svar är aktiverad som standard. Därför visas felmeddelandet "Åtkomst nekad" i Windows Server 2003 efter den första installationen vid försök att ansluta till ett Windows NT 4.0-kluster eller till servrar med LanManager V2.1, till exempel OS/2 Lanserver. Problemet uppstår även vid försök att ansluta från en klient med en tidigare version till en server med Windows Server 2003.
      • Samlat säkerhetspaket 1 för Windows 2000 (SRP1) installeras. SRP1 framtvingar NTLM version 2 (NTLMv2). Paketet släpptes efter Windows 2000 Service Pack 2 (SP2). Om du vill veta mer om SRP1 klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:

        311401 Windows 2000 säkerhetsuppsamlingspaket 1, januari 2002 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Microsoft Outlook-klienter kan uppmanas att ange identifieringsinformation trots att de redan är inloggade i domänen. När informationen ges visas följande felmeddelande:
        Inloggningsinformationen var felaktig. Kontrollera användarnamn och domän och ange lösenordet igen.
        När du startar Outlook kan du bli ombedd att ange din inloggningsinformation trots att inställningen för Inloggningssäkerhet för nätverk är Direkt eller Lösenordsautentisering. När du har skrivit in rätt inloggningsinformation visas följande felmeddelande:
        Inloggningsinformationen var felaktig.
        Ett Network Monitor-spår kan visa att den globala katalogen har utfärdat ett RPC-fel (Remote Procedure Call) med status 0x5, som innebär "Åtkomst nekad".
      • Windows 2000: Network Monitor kan visa följande fel i NetBT-SMB-sessionen (NetBIOS över TCP/IP, Server Message Block):
        SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Invalid user identifier
      • 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 det uppstå autentiseringsfel på Windows 2000-datorer i resursdomänen.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        305379 Autentiseringsproblem i Windows 2000 med NTLM 2-nivåer över 2 i en Windows NT 4.0-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows 2000 och Windows XP: Alternativet Lokal säkerhetsprincip för autentiseringsnivå i LAN Manager är som standard 0 i Windows 2000 och Windows XP, vilket innebär "Skicka LM- och NTLM-svar".

        Obs! I kluster med Windows NT 4.0 måste LM användas för administration.
      • Windows 2000: Windows 2000-klustring autentiserar inte en anslutande nod om båda noderna ingår i en Windows NT 4.0 Service Pack 6a (SP6a)-domän.

        Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
        305379 Autentiseringsproblem i Windows 2000 med NTLM 2-nivåer över 2 i en Windows NT 4.0-domän (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • IIS Lockdown-verktyget (HiSecWeb) ger LMCompatibilityLevel värdet 5 och RestrictAnonymous värdet 2.
      • Tjänster för Macintosh

        UAM (User Authentication Module): Microsoft UAM (User Authentication Module) ger möjlighet att kryptera lösenord som används för inloggning på Windows AFP-servrar (AppleTalk Filing Protocol). Apples UAM (User Authentication Module) ger endast minimal kryptering eller ingen alls. Därför kan lösenordet lätt fångas upp i det lokala nätverket eller på Internet. Även om UAM inte är obligatorisk ger den krypterad autentisering på Windows 2000-servrar där Macintosh-tjänster används. I den här versionen ingår stöd för NTLMv2 128-bitars krypterad autentisering och en MacOS X 10.1-kompatibel utgåva.

        Servern för Macintosh-tjänster i Windows Server 2003 tillåter som standard bara Microsoft-autentisering.

        Om du vill veta mer klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
        834498 Macintosh-klient kan inte ansluta till Macintosh-tjänster i Windows Server 2003 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
        838331 Användare av Mac OS X kan inte öppna delade Macintosh-mappar på en server med Windows Server 2003 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
      • Windows Server 2008, Windows Server 2003, Windows XP och Windows 2000: Om du konfigurerar LMCompatibilityLevel-värdet till 0 eller 1 och sedan konfigurerar NoLMHash-värdet till 1, kan program och komponenter nekas åtkomst genom NTLM. Detta problem beror på att datorn är konfigurerad för aktivering av LM men inte för användning av LM-lagrade lösenord.

        Om du konfigurerar NoLMHash-värdet till 1 måste du konfigurera LMCompatibilityLevel-värdet till 2 eller mer.
  11. Nätverkssäkerhet: Signeringskrav för LDAP-klient
    1. Bakgrund

      Inställningen Nätverkssäkerhet: Signeringskrav för LDAP-klient avgör datasigneringsnivån som krävs för klienter som utfärdar LDAP BIND-begäranden (Lightweight Directory Access Protocol) enligt följande:
      • Inga: LDAP BIND-begärandet utfärdas med anroparspecifika alternativ.
      • Förhandla om signering: Om SSL/TLS (Secure Sockets Layer/Transport Layer Security) inte har startats initieras LDAP BIND-begäran med LDAP-datasigneringsalternativet inställt förutom anroparspecifika alternativ. Om SSL/TLS har startats initieras LDAP BIND-begäran med anroparspecifika alternativ.
      • Kräv signering: Detta är samma som Förhandla om signering. Om LDAP-serverns mellanliggande saslBindInProgress-svar inte anger att LDAP-trafiksignering krävs, meddelas emellertid anroparen att LDAP BIND-kommandobegäran har misslyckats.
    2. Riskabel konfiguration

      Aktivering av inställningen Nätverksåtkomst: Signeringskrav för LDAP-klient är en riskabel konfiguration. Om du ställer in servern så att LDAP-signaturer krävs måste du även konfigurera LDAP-signering på klienten. Om klienten inte konfigureras för användning av LDAP-signaturer förhindras kommunikation med servern, vilket innebär att användarautentisering, grupprincipinställningar, inloggningsskript och andra funktioner inte fungerar.
    3. Skäl att inaktivera den här inställningen

      Vid osignerad nätverkstrafik kan en angripare fånga upp paket mellan klienten och servern, ändra dem och sedan vidarebefordra dem till servern. När detta inträffar på en LDAP-server kan angreppet medföra att serverns svar baseras på falska förfrågningar från LDAP-klienten. I ett företagsnätverk kan risken för detta minskas med hjälp av starka fysiska säkerhetsåtgärder som bidrar till att skydda nätverkets infrastruktur. Dessutom kan sådana här angrepp försvåras mycket genom att digitala signaturer krävs för 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: Största loggstorlek för säkerhetsloggen
    1. Bakgrund

      Inställningen Händelselogg: Största loggstorlek för säkerhetsloggen anger säkerhetshändelseloggens maximala storlek. Loggens största storlek är 4 GB. Du hittar inställningen genom att expandera Windows-inställningar och sedan Säkerhetsinställningar.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Begränsning av säkerhetsloggens storlek och lagringsmetod när inställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning är aktiverad. Mer information finns i avsnittet "Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning" i den här artikeln.
      • Begränsning av säkerhetsloggens storlek så att säkerhetshändelser av intresse skrivs över.
    3. Skäl att öka den här inställningen

      Verksamhets- och säkerhetskrav kan medföra att säkerhetsloggen måste utökas för att kunna hantera ytterligare information eller för att säkerhetsloggar ska kunna sparas längre.
    4. Skäl att minska den här inställningen

      Loggar i Loggboken är minnesmappade filer. Den största storleken för 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 loggstorleken ökas mer än det virtuella minne som är tillgängligt för Loggboken ökas inte antalet loggposter.
    5. Exempel på kompatibilitetsproblem

      Windows 2000: På datorer med tidigare Windows 2000-versioner än Service Pack 4 (SP4) kan det hända att händelser inte längre loggas till händelseloggen innan storleken som anges i inställningen Största loggstorlek uppnås i Loggboken, om alternativet Skriv aldrig över händelser (rensa loggen manuellt) är aktiverat.

      Om du vill veta mer klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
      312571 Loggning av händelser i händelseloggen upphör innan den maximala loggstorleken har uppnåtts (Länken kan leda till en webbplats som är helt eller delvis på engelska)
  13. Händelselogg: Behåll säkerhetsloggen
    1. Bakgrund

      Inställningen Händelselogg: Behåll säkerhetsloggen anger loggperioden för säkerhetsloggen. Du hittar inställningen genom att expandera Windows-inställningar och sedan Säkerhetsinställningar.
    2. Riskabla konfigurationer

      Följande är skadliga konfigurationer:
      • Alla loggade säkerhetshändelser behålls inte innan de skrivs över.
      • Inställningen för Största loggstorlek för säkerhetsloggen är så låg att säkerhetshändelser skrivs över.
      • Säkerhetsloggens storlek och lagringsmetod begränsas när säkerhetsinställningen Granskning: Stäng ner systemet omedelbart om det inte går att logga säkerhetsgranskning är aktiverad.
    3. Skäl att aktivera den här inställningen

      Aktivera denna inställning endast om du markerar lagringsmetoden Skriv över händelser efter dagar. Om du använder ett system för händelsekorrelering med händelseavsökning, måste du se till att antalet dagar är minst tre gånger avsökningsfrekvensen. På så vis finns det en marginal för eventuella misslyckade avsökningscykler.
  14. Nätverksåtkomst: Låt behörigheter för Alla gälla även för anonyma användare
    1. Bakgrund

      Inställningen Nätverksåtkomst: Låt behörigheter för Alla gälla även för anonyma användare är som standard Inte definierad i Windows Server 2003. Anonym åtkomst-token ingår inte som standard i gruppen Alla i Windows Server 2003.
    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än. Detta innebär att kontodomänen är betrodd i Windows NT 4.0, och resursdomänen är en domän med förtroende i Windows Server 2003. Det här beror på att processen för att starta förtroendet efter den inledande anonyma anslutningen styrs av åtkomstkontrollistan med token Alla som innehåller anonym SID i Windows NT 4.0.
    3. Skäl att inaktivera den här inställningen

      Värdet måste anges till 0x1 eller anges med hjälp av ett grupprincipobjekt i domänkontrollantens organisationsenhet till Nätverksåtkomst: Låt behörigheter för Alla gälla även för anonyma användare - Aktiverad för att förtroendeskapande ska vara möjligt.

      Obs! De flesta andra säkerhetsinställningar får högre värde i stället för att gå ned till 0x0 i det säkraste tillståndet. En säkrare åtgärd vore att ändra registret på den primära domänkontrollantens emulator i stället för på alla domänkontrollanter. Om den primära domänkontrollantens emulatorroll av någon anledning flyttas, måste registret uppdateras på den nya servern.

      En omstart krävs efter inställningen av värdet.
    4. Registersökväg
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
  15. NTLMv2-autentisering

    Sessionssäkerhet

    Sessionssäkerheten avgör de lägsta säkerhetsnormerna för klient- och serversessioner. Det kan vara lämpligt att kontrollera följande säkerhetsprincipinställningar i snapin-modulen Principeditorn i Microsoft Management Console:
    • Computer Settings\Windows Settings\Security Settings\Local Policies\Security Options
    • Nätverkssäkerhet: Lägsta sessionssäkerhet för servrar som baseras på NTLM SSP (inklusive Secure RPC)
    • Nätverkssäkerhet: Lägsta sessionssäkerhet för klienter som baseras på NTLM SSP (inklusive Secure RPC)
    Alternativen för dessa inställningar är:
    • Kräv integritet för meddelanden
    • Kräv konfidentialitet för meddelanden
    • Kräv NTLM version 2-sessionssäkerhet
    • Kräv 128-bitars kryptering
    Standardinställningen är Inga krav.

    De här principerna avgör de lägsta säkerhetsnormerna för en kommunikationssession mellan program på en server för en klient.

    Tidigare har Windows NT stött följande två varianter av anrop-/svarautentisering för nätverksinloggning:
    • LM anrop/svar
    • NTLM version 1 anrop/svar
    LM tillåter samverkan med den installerade basen av klienter och servrar. NTLM ger förbättrad säkerhet för anslutningar mellan klienter och servrar.

    Motsvarande registernycklar är följande:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"

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

Tidssynkronisering

Tidssynkronisering misslyckades. Tiden skiljer sig med mer än 30 minuter på en dator. Se till 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-domän. Klienter med Windows 98, andra utgåvan, Windows 98 eller Windows 95 måste köra katalogtjänstklienten för att genomföra NTLMv2. Om klienter med Windows NT 4.0 saknar Windows NT 4.0 SP6, eller om klienter med Windows 95, Windows 98 eller Windows 98, andra utgåvan, saknar katalogtjänstklienten, inaktiverar du SMB-signering i standarddomänkontrollantens principinställning på domänkontrollantens organisationsenhet. Länka sedan denna princip till alla organisationsenheter som är värdar för domänkontrollanter.

Katalogtjänstklienten för Windows 98, andra utgåvan, Windows 98 och Windows 95 ger SMB-signering med Windows 2003-servrar vid NTLM-autentisering men inte vid NTLMv2-autentisering. Dessutom svarar inte Windows 2000-servrar på SMB-signeringsbegäranden från dessa klienter.

Även om Microsoft inte rekommenderar det kan du förhindra att SMB-signering krävs på alla domänkontrollanter där Windows Server 2003 körs i en domän. Så här konfigurerar du säkerhetsinställningen:
  1. Öppna standarddomänkontrollantens princip.
  2. Öppna mappen Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.
  3. Leta upp och klicka på principinställningen Microsoft-nätverksserver: Signera kommunikation digitalt (alltid) och klicka på Inaktiverad.
Viktigt! Den här artikeln innehåller information om hur du redigerar registret. Det kan uppstå allvarliga problem om du gör detta felaktigt. Följ därför instruktionerna noga, och säkerhetskopiera registret innan du gör några ändringar i det. Då kan du återställa registret om det uppstår problem. Om du vill veta mer om hur du säkerhetskopierar och återställer registret klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
322756 Säkerhetskopiera och återställa registret i Windows XP
Du kan även stänga av SMB-signering på servern genom en registerändring så här:
  1. Klicka på Start, Kör, skriv regedit och klicka på OK.
  2. Leta upp och klicka 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 Data, och klicka sedan på OK.
  6. Avsluta Registereditorn.
  7. Starta om datorn eller stoppa och starta sedan om tjänsten Server genom att skriva följande kommandon vid en kommandotolk och trycka på RETUR efter 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
Här anges felkodnumren översatta till statuskoder och till de felmeddelanden som återges ovan:
fel 5
ERROR_ACCESS_DENIED
Åtkomst nekad.
fel 1326
ERROR_LOGON_FAILURE
Inloggningsfel: okänt användarnamn eller felaktigt lösenord.
fel 1788
ERROR_TRUSTED_DOMAIN_FAILURE
Det gick inte att upprätta förtroende mellan den primära domänen och den betrodda domänen.
fel 1789
ERROR_TRUSTED_RELATIONSHIP_FAILURE
Det gick inte att upprätta en förtroenderelation mellan den här arbetsstationen och den primära domänen.
Om du vill veta mer klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
324802 Konfigurera grupprinciper för inställning av säkerhet för systemtjänster i Windows Server 2003 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
306771 Felmeddelandet "Åtkomst nekad" visas efter konfigurering av ett Windows Server 2003-kluster (Länken kan leda till en webbplats som är helt eller delvis på engelska)
101747 Installera Microsoft-autentisering på en Macintosh-dator (Länken kan leda till en webbplats som är helt eller delvis på engelska)
161372 Aktivera SMB-signering i Windows NT (Länken kan leda till en webbplats som är helt eller delvis på engelska)
236414 Det går inte att dela resurser med LMCompatibilityLevel inställd på endast NTLM 2-autentisering (Länken kan leda till en webbplats som är helt eller delvis på engelska)
241338 Windows NT LAN Manager version 3-klient med första inloggning förhindrar följande inloggningsaktivitet (Länken kan leda till en webbplats som är helt eller delvis på engelska)
262890 Det går inte att ansluta till arbetskatalogenheten i en blandad miljö (Länken kan leda till en webbplats som är helt eller delvis på engelska)
308580 Arbetskatalogmappningar till servrar med en lägre nivå fungerar inte under inloggning (Länken kan leda till en webbplats som är helt eller delvis på engelska)
285901 Fjärråtkomst-, VPN- och RIS-klienter kan inte upprätta sessioner med en server som är konfigurerad för att endast acceptera NTLM version 2-autentisering (Länken kan leda till en webbplats som är helt eller delvis på engelska)
816585 Använda fördefinierade säkerhetsmallar i Windows Server 2003 (Länken kan leda till en webbplats som är helt eller delvis på engelska)
820281 Windows-kontoreferenser måste lämnas vid anslutning till Exchange Server 2003 med hjälp av Outlook 2003-funktionen RPC över HTTP (Länken kan leda till en webbplats som är helt eller delvis på engelska)

Egenskaper

Artikel-id: 823659 - Senaste granskning: den 10 maj 2011 - Revision: 21.0
Informationen i denna artikel gäller:
  • Microsoft Windows Server 2003 Standard Edition
  • Microsoft Windows Server 2003 Datacenter Edition
  • Microsoft Windows Server 2003 Enterprise Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows XP Professional Edition
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows 95
Nyckelord: 
kbinfo KB823659

Ge feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com