Log på med Microsoft
Log på, eller opret en konto.
Hej
Markér en anden konto.
Du har flere konti
Vælg den konto, du vil logge på med.

Sammendrag

Sikkerhedsindstillinger og brugerrettigheder kan ændres i lokale politikker og gruppepolitikker for at stramme sikkerheden på domænecontrollere og medlemscomputere. Ulempen ved øget sikkerhed er dog indførelsen af kompatibilitet med klienter, tjenester og programmer.

I denne artikel beskrives kompatibilitetsproblemer, der kan opstå på klientcomputere, der kører Windows XP eller en tidligere version af Windows, når du ændrer bestemte sikkerhedsindstillinger og brugerrettigheder i et Windows Server 2003-domæne eller et tidligere Windows Server-domæne.

Du kan få oplysninger om Gruppepolitik til Windows 7, Windows Server 2008 R2 og Windows Server 2008 i følgende artikler:

Bemærk! Det resterende indhold i denne artikel er specifikt for Windows XP, Windows Server 2003 og tidligere versioner af Windows.

Windows XP

Hvis du vil gøre opmærksom på forkert konfigurerede sikkerhedsindstillinger, skal du bruge værktøjet Gruppepolitik Objekteditor til at ændre sikkerhedsindstillinger. Når du bruger Gruppepolitik Objekteditor, forbedres brugerrettigheder på følgende operativsystemer:

  • Windows XP Professional Service Pack 2 (SP2)

  • Windows Server 2003 Service Pack 1 (SP1)

Den forbedrede funktion er en dialogboks, der indeholder et link til denne artikel. Dialogboksen vises, når du ændrer en sikkerhedsindstilling eller en tildeling af brugerrettigheder til en indstilling, der giver mindre kompatibilitet og er mere restriktiv. Hvis du direkte ændrer den samme sikkerhedsindstilling eller brugerrettigheder ved hjælp af registreringsdatabasen eller ved hjælp af sikkerhedsskabeloner, er effekten det samme som at ændre indstillingen i Gruppepolitik Objekteditor. Men den dialogboks, der indeholder linket til denne artikel, vises ikke.

Denne artikel indeholder eksempler på klienter, programmer og handlinger, der påvirkes af bestemte sikkerhedsindstillinger eller brugerrettigheder. Eksemplerne er dog ikke autoritative for alle Microsoft-operativsystemer, for alle tredjepartsoperativsystemer eller for alle programversioner, der påvirkes. Ikke alle sikkerhedsindstillinger og brugerrettigheder er inkluderet i denne artikel.

Vi anbefaler, at du validerer kompatibiliteten af alle sikkerhedsrelaterede konfigurationsændringer i en testskov, før du introducerer dem i et produktionsmiljø. Testskoven skal afspejle produktionsskoven på følgende måder:

  • Klient- og serveroperativsystemversioner, klient- og serverprogrammer, servicepakkeversioner, hotfixes, skemaændringer, sikkerhedsgrupper, gruppemedlemskaber, tilladelser til objekter i filsystemet, delte mapper, registreringsdatabasen, Active Directory-katalogtjeneste, lokale og Gruppepolitik indstillinger samt objektantaltype og -placering

  • Administrative opgaver, der udføres, anvendte administrative værktøjer og operativsystemer, der bruges til at udføre administrative opgaver

  • Handlinger, der udføres, f.eks. følgende:

    • Godkendelse af computer- og brugerlogon

    • Adgangskode nulstilles af brugere, af computere og af administratorer

    • Browsing

    • Angive tilladelser for filsystemet, delte mapper, registreringsdatabasen og Active Directory-ressourcer ved hjælp af ACL Editor i alle klientoperativsystemer på alle konto- eller ressourcedomæner fra alle klientoperativsystemer fra alle konto- eller ressourcedomæner

    • Udskrivning fra administrative og ikke-administrative konti

Windows Server 2003 SP1

Advarsler i Gpedit.msc

For at gøre kunderne opmærksomme på, at de redigerer en brugerrettighed eller sikkerhedsindstilling, der kan have en negativ effekt på deres netværk, blev der føjet to advarselsmekanismer til gpedit.msc. Når administratorer redigerer en brugerrettighed, der kan påvirke hele virksomheden negativt, får de vist et nyt ikon, der ligner et afkasttegn. De modtager også en advarselsmeddelelse, der indeholder et link til Microsoft Knowledge Base-artiklen 823659. Teksten i denne meddelelse er som følger:

Hvis du ændrer denne indstilling, kan det påvirke kompatibiliteten med klienter, tjenester og programmer. Du kan få mere at vide under <brugerrettighed eller sikkerhedsindstilling, der ændres> (Q823659) Hvis du blev dirigeret til denne Knowledge Base-artikel fra et link i Gpedit.msc, skal du sørge for at læse og forstå den angivne forklaring og den mulige effekt af at ændre denne indstilling. Følgende viser brugerrettigheder, der indeholder advarselsteksten:

  • Få adgang til denne computer fra netværket

  • Log på lokalt

  • Spring krydskontrol over

  • Aktivere computere og brugere for delegering, der er tillid til

Følgende viser sikkerhedsindstillinger, der indeholder advarslen og en pop op-meddelelse:

  • Domænemedlem: Kryptér eller signer data til sikre kanaler digitalt (altid)

  • Domænemedlem: Kræver en stærk sessionsnøgle (Windows 2000 eller en nyere version)

  • Domænecontroller: Krav til LDAP-serversignering

  • Microsoft-netværksserver: Signer kommunikation digitalt (altid)

  • Netværksadgang: Tillader oversættelse af anonymt sid/navn

  • Netværksadgang: Tillad ikke anonym optælling af SAM-konti og -shares

  • Netværkssikkerhed: LAN Manager-godkendelsesniveau

  • Overvågning: Luk systemet med det samme, hvis sikkerhedsovervågninger ikke kan logføres

  • Netværksadgang: Krav til LDAP-klientsignering

Flere oplysninger

I de følgende afsnit beskrives kompatibiliteter, der kan opstå, når du ændrer bestemte indstillinger i Windows NT 4.0-domæner, Windows 2000-domæner og Windows Server 2003-domæner.

Brugerrettigheder

Følgende liste beskriver en brugerrettighed, identificerer konfigurationsindstillinger, der kan forårsage problemer, beskriver, hvorfor du skal anvende brugerrettigheden, og hvorfor du måske vil fjerne brugerrettigheden, og indeholder eksempler på kompatibilitetsproblemer, der kan opstå, når brugerrettigheden er konfigureret.

  1. Få adgang til denne computer fra netværket

    1. Baggrund

      Muligheden for at interagere med Eksterne Windows-baserede computere kræver Access til denne computer fra brugerens ret til netværk. Eksempler på sådanne netværkshandlinger omfatter følgende:

      • Replikering af Active Directory mellem domænecontrollere i et fælles domæne eller en fælles skov

      • Godkendelsesanmodninger til domænecontrollere fra brugere og fra computere

      • Adgang til delte mapper, printere og andre systemtjenester, der er placeret på fjerncomputere på netværket



      Brugere, computere og tjenestekonti får eller mister adgang til denne computer fra netværksbrugerretten ved eksplicit eller implicit at blive tilføjet eller fjernet fra en sikkerhedsgruppe, der har fået tildelt denne brugerrettighed. En brugerkonto eller en computerkonto kan f.eks. eksplicit føjes til en brugerdefineret sikkerhedsgruppe eller en indbygget sikkerhedsgruppe af en administrator, eller den kan implicit føjes af operativsystemet til en beregnet sikkerhedsgruppe, f.eks. Domænebrugere, Godkendte brugere eller Enterprise-domænecontrollere.

      Som standard tildeles brugerkonti og computerkonti adgang til denne computer fra netværkets brugerret, når beregnede grupper som f.eks. Alle eller helst Godkendte brugere og, for domænecontrollere, gruppen Virksomhedsdomænecontrollere, er defineret i standarddomænecontrollere Gruppepolitik objekt (GPO).

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Fjernelse af sikkerhedsgruppen Virksomhedsdomænecontrollere fra denne brugerrettighed

      • Fjernelse af gruppen Godkendte brugere eller en eksplicit gruppe, der gør det muligt for brugere, computere og tjenestekonti at oprette forbindelse til computere via netværket

      • Fjernelse af alle brugere og computere fra denne brugerrettighed

    3. Grunde til at tildele denne bruger rettighed

      • Tildeling af Adgang til denne computer fra netværksbrugerretten til gruppen Virksomhedsdomænecontrollere opfylder godkendelseskrav, som Active Directory-replikering skal have, for at replikering kan forekomme mellem domænecontrollere i samme skov.

      • Denne brugerrettighed giver brugere og computere adgang til delte filer, printere og systemtjenester, herunder Active Directory.

      • Denne brugerrettighed er påkrævet, for at brugerne kan få adgang til mail ved hjælp af tidligere versioner af Microsoft Outlook Web Access (OWA).

    4. Årsager til at fjerne denne brugerrettighed

      • Brugere, der kan oprette forbindelse mellem deres computere og netværket, kan få adgang til ressourcer på fjerncomputere, de har tilladelser til. Denne brugerrettighed er f.eks. påkrævet, for at en bruger kan oprette forbindelse til delte printere og mapper. Hvis denne brugerrettighed tildeles gruppen Alle, og hvis nogle delte mapper har konfigureret tilladelserne for både delings- og NTFS-filsystemet, så den samme gruppe har læseadgang, kan alle få vist filer i disse delte mapper. Dette er dog en usandsynlig situation for nye installationer af Windows Server 2003, fordi standardsharet og NTFS-tilladelserne i Windows Server 2003 ikke omfatter gruppen Alle. For systemer, der opgraderes fra Microsoft Windows NT 4.0 eller Windows 2000, kan denne sikkerhedsrisiko have et højere risikoniveau, fordi standardsharen og filsystemtilladelserne for disse operativsystemer ikke er så restriktive som standardtilladelserne i Windows Server 2003.

      • Der er ingen gyldig grund til at fjerne gruppen Enterprise-domænecontrollere fra denne brugerrettighed.

      • Gruppen Alle fjernes generelt til fordel for gruppen Godkendte brugere. Hvis gruppen Alle fjernes, skal gruppen Godkendte brugere tildeles denne brugerrettighed.

      • Windows NT 4.0-domæner, der opgraderes til Windows 2000, giver ikke eksplicit Adgang til denne computer fra netværksbrugeren til gruppen Alle, gruppen Godkendte brugere eller gruppen Enterprise-domænecontrollere. Når du fjerner gruppen Alle fra Windows NT 4.0-domænepolitikken, mislykkes Active Directory-replikering med fejlmeddelelsen "Adgang nægtet", når du har opgraderet til Windows 2000. Winnt32.exe i Windows Server 2003 undgår denne fejlkonfiguration ved at tildele gruppen Enterprise-domænecontrollere denne brugerret, når du opgraderer primære Windows NT 4.0-domænecontrollere (PDCs). Tildel gruppen Enterprise-domænecontrollere denne brugerrettighed, hvis den ikke findes i Gruppepolitik Objekteditor.

    5. Eksempler på kompatibilitetsproblemer

      • Windows 2000 og Windows Server 2003: Replikering af følgende partitioner mislykkes med "Adgang nægtet"-fejl, som rapporteres af overvågningsværktøjer som f.eks. REPLMON- og REPADMIN- eller replikeringshændelser i hændelsesloggen.

        • Active Directory-skemapartition

        • Konfigurationspartition

        • Domænepartition

        • Global katalogpartition

        • Programpartition

      • Alle Microsoft-netværksoperativsystemer: Godkendelse af brugerkonti fra fjernnetværksklientcomputere mislykkes, medmindre brugeren eller en sikkerhedsgruppe, som brugeren er medlem af, har fået tildelt denne brugerrettighed.

      • Alle Microsoft-netværksoperativsystemer: Kontogodkendelse fra fjernnetværksklienter mislykkes, medmindre kontoen eller en sikkerhedsgruppe, som kontoen er medlem af, har fået tildelt denne brugerrettighed. Dette scenarie gælder for brugerkonti, computerkonti og tjenestekonti.

      • Alle Microsoft-netværksoperativsystemer: Hvis du fjerner alle konti fra denne brugerrettighed, forhindres enhver konto i at logge på domænet eller få adgang til netværksressourcer. Hvis beregnede grupper som f.eks. Virksomhedsdomænecontrollere, Alle eller Godkendte brugere fjernes, skal du udtrykkeligt give denne brugerret til konti eller til sikkerhedsgrupper, som kontoen er medlem af, for at få adgang til fjerncomputere via netværket. Dette scenarie gælder for alle brugerkonti, for alle computerkonti og for alle tjenestekonti.

      • Alle Microsoft-netværksoperativsystemer: Den lokale administratorkonto bruger en "tom" adgangskode. Netværksforbindelse med tomme adgangskoder er ikke tilladt for administratorkonti i et domænemiljø. Med denne konfiguration kan du forvente at modtage fejlmeddelelsen "Adgang nægtet".

  2. Tillad, at der logges på lokalt

    1. Baggrund

      Brugere, der forsøger at logge på på konsollen på en Windows-baseret computer (ved hjælp af tastaturgenvejen CTRL+ALT+DELETE), og konti, der forsøger at starte en tjeneste, skal have lokale logonrettigheder på værtscomputeren. Eksempler på lokale logonhandlinger omfatter administratorer, der logger på konsollerne på medlemscomputere eller domænecontrollere i hele virksomheden og domænebrugere, der logger på medlemscomputere for at få adgang til deres skriveborde ved hjælp af konti, der ikke har administratortilladelser. Brugere, der bruger en forbindelse til Fjernskrivebord eller Terminal Services, skal have brugerrettigheden Tillad, at der logges på lokalt på destinationscomputere, der kører Windows 2000 eller Windows XP, da disse logontilstande betragtes som lokale for værtscomputeren. Brugere, der logger på en server, der har Terminal Server aktiveret, og som ikke har denne brugerrettighed, kan stadig starte en ekstern interaktiv session i Windows Server 2003-domæner, hvis de har brugerrettigheden Tillad logon via Terminal Services.

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Fjernelse af administrative sikkerhedsgrupper, herunder kontooperatører, sikkerhedskopioperatorer, udskriftsoperatører eller serveroperatører og den indbyggede administratorgruppe fra standarddomænecontrollerens politik.

      • Fjernelse af tjenestekonti, der bruges af komponenter og programmer på medlemscomputere og på domænecontrollere på domænet, fra standarddomænecontrollerens politik.

      • Fjernelse af brugere eller sikkerhedsgrupper, der logger på konsollen på medlemscomputere i domænet.

      • Fjernelse af tjenestekonti, der er defineret i den lokale SAM-database (Security Accounts Manager) på medlemscomputere eller arbejdsgruppecomputere.

      • Fjernelse af ikke-indbyggede administrative konti, der godkender via Terminal Services, der kører på en domænecontroller.

      • Tilføjelse af alle brugerkonti i domænet eksplicit eller implicit via gruppen Alle til afvis logon lokalt logon til højre. Denne konfiguration forhindrer brugere i at logge på en medlemscomputer eller en domænecontroller i domænet.

    3. Grunde til at tildele denne bruger rettighed

      • Brugere skal have brugerrettigheden Tillad logon lokalt for at få adgang til konsollen eller skrivebordet på en arbejdsgruppecomputer, en medlemscomputer eller en domænecontroller.

      • Brugere skal have denne brugerret til at logge på via en Terminal Services-session, der kører på en Windows 2000-baseret medlemscomputer eller domænecontroller.

    4. Årsager til at fjerne denne brugerrettighed

      • Hvis konsoladgangen ikke begrænses til legitime brugerkonti, kan det medføre, at uautoriserede brugere henter og eksekverer skadelig kode for at ændre deres brugerrettigheder.

      • Fjernelse af brugerrettigheden Tillad logon lokalt forhindrer uautoriserede logon på konsoller på computere, f.eks. domænecontrollere eller programservere.

      • Fjernelse af denne logon-rettighed forhindrer konti, der ikke er domænekonti, i at logge på konsollen på medlemscomputere i domænet.

    5. Eksempler på kompatibilitetsproblemer

      • Windows 2000-terminalservere: Brugerrettigheden Tillad logon lokalt kræves, for at brugerne kan logge på Windows 2000-terminalservere.

      • Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003: Brugerkonti skal tildeles denne brugerret til at logge på på konsollen på computere, der kører Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003.

      • Windows NT 4.0 og nyere: Hvis du tilføjer brugerrettigheden Tillad logon lokalt på computere, der kører Windows NT 4.0 og nyere, men du implicit eller eksplicit også tildeler retten Afvis logon lokalt, kan kontiene ikke logge på konsollen for domænecontrollerne.

  3. Spring krydskontrol over

    1. Baggrund

      Brugerrettigheden Spring krydskontrol over giver brugeren mulighed for at gennemse mapper i NTFS-filsystemet eller i registreringsdatabasen uden at kontrollere, om der er særlig adgangstilladelse til Traverse-mappen. Brugerrettigheden Spring krydskontrol over tillader ikke brugeren at få vist indholdet af en mappe. Det giver brugeren mulighed for kun at gennemgå sine mapper.

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Fjernelse af ikke-administrative konti, der logger på Windows 2000-baserede Terminal Services-computere eller Windows Server 2003-baserede Terminal Services-computere, der ikke har tilladelse til at få adgang til filer og mapper i filsystemet.

      • Fjernelse af gruppen Alle fra listen over sikkerhedsprincipaler, der som standard har denne brugerret. Windows-operativsystemer og også mange programmer er designet med en forventning om, at alle, der har legitim adgang til computeren, har brugerrettigheden Spring krydstjek over. Derfor kan fjernelse af gruppen Alle fra listen over sikkerhedsprincipaler, der har denne brugerret som standard, medføre ustabilitet i operativsystemet eller programfejl. Det er bedre, at du lader denne indstilling være som standard.

    3. Grunde til at tildele denne bruger rettighed

      Standardindstillingen for brugerrettigheden Spring krydstjek over er at tillade, at alle tilsidesætter krydstjekket. For erfarne Windows-systemadministratorer er dette den forventede funktionsmåde, og de konfigurerer SACLs (File System Access Control Lists) i overensstemmelse hermed. Det eneste scenarie, hvor standardkonfigurationen kan føre til et uheld, er, hvis den administrator, der konfigurerer tilladelser, ikke forstår funktionsmåden og forventer, at brugere, der ikke kan få adgang til en overordnet mappe, ikke vil kunne få adgang til indholdet af underordnede mapper.

    4. Årsager til at fjerne denne brugerrettighed

      For at forsøge at forhindre adgang til filerne eller mapperne i filsystemet kan organisationer, der er meget bekymrede over sikkerhed, fristes til at fjerne gruppen Alle, eller endda gruppen Brugere, fra listen over grupper, der har brugerrettigheden Spring krydstjek over.

    5. Eksempler på kompatibilitetsproblemer

      • Windows 2000, Windows Server 2003: Hvis brugerrettigheden Spring krydstjek over fjernes eller er konfigureret forkert på computere, der kører Windows 2000 eller Windows Server 2003, replikeres Gruppepolitik indstillinger i mappen SYVOL ikke mellem domænecontrollere i domænet.

      • Windows 2000, Windows XP Professional, Windows Server 2003: Computere, der kører Windows 2000, Windows XP Professional eller Windows Server 2003, vil logføre hændelserne 1000 og 1202 og vil ikke kunne anvende computerpolitik og brugerpolitik, når de nødvendige tilladelser til filsystemet fjernes fra sysvol-træet, hvis brugerrettigheden Spring krydskontrol over fjernes eller er konfigureret forkert.

         

      • Windows 2000, Windows Server 2003: På computere, der kører Windows 2000 eller Windows Server 2003, forsvinder fanen Kvote i Windows Stifinder, når du får vist egenskaber på en diskenhed.

      • Windows 2000: Ikke-administratorer, der logger på en Windows 2000-terminalserver, modtager muligvis følgende fejlmeddelelse:

        Userinit.exe programfejl. Programmet kunne ikke initialiseres korrekt 0xc0000142 klik på OK for at afslutte appen.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Brugere, hvis computere kører Windows NT 4.0, Windows 2000, Windows XP eller Windows Server 2003, kan muligvis ikke få adgang til delte mapper eller filer på delte mapper, og de kan modtage fejlmeddelelserne "Adgang nægtet", hvis de ikke får tildelt brugerrettigheden Spring krydskontrol over.


         

      • Windows NT 4.0: På Windows NT 4.0-baserede computere vil fjernelse af brugerrettigheden Spring krydstjek over medføre, at en filkopi slipper filstrømme. Hvis du fjerner denne brugerrettighed, når en fil kopieres fra en Windows-klient eller fra en Macintosh-klient til en Windows NT 4.0-domænecontroller, der kører Services til Macintosh, går destinationsfilstreamet tabt, og filen vises som en fil, der kun indeholder tekst.

      • Microsoft Windows 95, Microsoft Windows 98: På en klientcomputer, der kører Windows 95 eller Windows 98, mislykkes kommandoen net use * /home med fejlmeddelelsen "Adgang nægtet", hvis gruppen Godkendte brugere ikke får tildelt brugerrettigheden Spring krydstjek over.

      • Outlook Web Access: Ikke-administratorer vil ikke kunne logge på Microsoft Outlook Web Access, og de får vist fejlmeddelelsen "Adgang nægtet", hvis de ikke får tildelt brugerrettigheden Spring krydstjek over.

Sikkerhedsindstillinger

Følgende liste identificerer en sikkerhedsindstilling, og den indlejrede liste indeholder en beskrivelse af sikkerhedsindstillingen, identificerer konfigurationsindstillinger, der kan forårsage problemer, beskriver, hvorfor du skal anvende sikkerhedsindstillingen, og beskriver derefter årsager til, hvorfor du måske vil fjerne sikkerhedsindstillingen. Den indlejrede liste giver derefter et symbolsk navn til sikkerhedsindstillingen og stien til registreringsdatabasen for sikkerhedsindstillingen. Endelig gives der eksempler på kompatibilitetsproblemer, der kan opstå, når sikkerhedsindstillingen er konfigureret.

  1. Overvågning: Luk systemet med det samme, hvis sikkerhedsovervågninger ikke kan logføres

    1. Baggrund

      • Indstillingen Overvågning: Luk systemet med det samme, hvis sikkerhedsovervågninger ikke kan logføres, bestemmer, om systemet lukkes, hvis du ikke kan logge sikkerhedshændelser. Denne indstilling er påkrævet for TCSEC-programmets C2-evaluering (Trusted Computer Security Evaluation Criteria) og for de fælles kriterier for it-sikkerhedsevaluering for at forhindre hændelser, der kan overvåges, hvis overvågningssystemet ikke kan logføre disse hændelser. Hvis overvågningssystemet mislykkes, lukkes systemet, og der vises en stopfejlmeddelelse.

      • Hvis computeren ikke kan registrere hændelser i sikkerhedsloggen, er vigtige beviser eller vigtige fejlfindingsoplysninger muligvis ikke tilgængelige til gennemsyn efter en sikkerhedshændelse.

    2. Risikabel konfiguration

      Følgende er en skadelig konfigurationsindstilling: Indstillingen Overvåg: Luk systemet med det samme, hvis indstillingen Sikkerhedsovervågning ikke kan logføres er slået til, og størrelsen af sikkerhedshændelsesloggen begrænses af indstillingen Overskriv ikke hændelser (ryd log manuelt), indstillingen Overskriv hændelser efter behov eller overskriv hændelser, der er ældre end antal dage i Logbog. Se afsnittet "Eksempler på kompatibilitetsproblemer" for at få oplysninger om specifikke risici for computere, der kører den oprindelige version af Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 eller Windows 2000 SP3.

    3. Årsager til at aktivere denne indstilling

      Hvis computeren ikke kan registrere hændelser i sikkerhedsloggen, er vigtige beviser eller vigtige fejlfindingsoplysninger muligvis ikke tilgængelige til gennemsyn efter en sikkerhedshændelse.

    4. Årsager til at deaktivere denne indstilling

      • Aktivering af indstillingen Overvågning: Luk systemet med det samme, hvis sikkerhedsovervågninger ikke kan logføres, stopper systemet, hvis der af en eller anden grund ikke kan logføres en sikkerhedsovervågning. En hændelse kan typisk ikke logføres, når sikkerhedsovervågningsloggen er fuld, og når den angivne opbevaringsmetode enten er indstillingen Overskriv ikke hændelser (ryd log manuelt) eller indstillingen Overskriv hændelser, der er ældre end antal dage.

      • Den administrative byrde ved aktivering af overvågning: Indstillingen Luk systemet straks, hvis sikkerhedsovervågninger ikke kan logføres, kan være meget stor, især hvis du også aktiverer indstillingen Overskriv ikke hændelser (ryd log manuelt) for sikkerhedsloggen. Denne indstilling giver mulighed for individuel ansvarlighed for operatørhandlinger. En administrator kan f.eks. nulstille tilladelser for alle brugere, computere og grupper i en organisationsenhed, hvor overvågning blev aktiveret ved hjælp af den indbyggede administratorkonto eller en anden delt konto og derefter afvise, at de nulstiller sådanne tilladelser. Aktivering af indstillingen reducerer dog systemets robusthed, fordi en server kan blive tvunget til at lukke ned af overvældende med logonhændelser og med andre sikkerhedshændelser, der skrives til sikkerhedsloggen. Desuden kan det medføre uoprettelige skader på operativsystemet, programmer eller data, fordi lukningen ikke er effektiv. Mens NTFS garanterer, at filsystemets integritet bevares under en lukning af systemet, der ikke kan spores, kan det ikke garantere, at alle datafiler for hvert program stadig vil være i brugbar form, når systemet genstartes.

    5. Symbolsk navn:

      CrashOnAuditFail

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      • Windows 2000: På grund af en fejl kan computere, der kører den oprindelige version af Windows 2000, Windows 2000 SP1, Windows 2000 SP2 eller Windows Server SP3, stoppe logføring af hændelser, før den størrelse, der er angivet i indstillingen Maksimal logstørrelse for sikkerhedshændelsesloggen er nået. Denne fejl er rettet i Windows 2000 Service Pack 4 (SP4). Sørg for, at dine Windows 2000-domænecontrollere har Windows 2000 Service Pack 4 installeret, før du overvejer at aktivere denne indstilling.

         

      • Windows 2000, Windows Server 2003: Computere, der kører Windows 2000 eller Windows Server 2003, kan holde op med at svare og genstarter derefter spontant, hvis indstillingen Overvågning: Luk systemet med det samme, hvis indstillingen Til logføring af sikkerhedsovervågning ikke er slået til, sikkerhedsloggen er fuld, og en eksisterende hændelseslogpost kan ikke overskrives. Når computeren genstarter, vises følgende Stop-fejlmeddelelse:

        STOP: C0000244 {Audit Failed}
        Et forsøg på at generere en sikkerhedsovervågning mislykkedes.

        For at genoprette skal en administrator logge på, arkivere sikkerhedsloggen (valgfrit), rydde sikkerhedsloggen og derefter nulstille denne indstilling (valgfri og efter behov).

      • Microsoft Network Client for MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Ikke-administratorer, der forsøger at logge på et domæne, modtager følgende fejlmeddelelse:

        Din konto er konfigureret til at forhindre dig i at bruge denne computer. Prøv en anden computer.

      • Windows 2000: På Windows 2000-baserede computere kan ikke-administratorer ikke logge på fjernadgangsservere, og de modtager en fejlmeddelelse, der ligner følgende:

        Ukendt bruger eller forkert adgangskode

      • Windows 2000: På Windows 2000-domænecontrollere stopper tjenesten Intersite Messaging (Ismserv.exe) og kan ikke genstartes. DCDIAG rapporterer fejlen som "mislykkede testtjenester ISMserv", og hændelses-id 1083 registreres i hændelsesloggen.

      • Windows 2000: På Windows 2000-domænecontrollere mislykkes Active Directory-replikering, og meddelelsen "Adgang nægtet" vises, hvis sikkerhedshændelsesloggen er fuld.

      • Microsoft Exchange 2000: Servere, der kører Exchange 2000, kan ikke oprette databasen til lagring af oplysninger, og hændelse 2102 registreres i hændelsesloggen.

      • Outlook, Outlook Web Access: Ikke-administratorer vil ikke kunne få adgang til deres mail via Microsoft Outlook eller via Microsoft Outlook Web Access, og de får en 503-fejl.

  2. Domænecontroller: Krav til signering af LDAP-server

    1. Baggrund

      Domænecontrolleren: Sikkerhedsindstillingen LDAP-serversigneringskrav bestemmer, om LDAP-serveren (Lightweight Directory Access Protocol) kræver LDAP-klienter for at forhandle om datasignering. De mulige værdier for denne politikindstilling er følgende:

      • Ingen: Datasignering er ikke påkrævet for at binde med serveren. Hvis klienten anmoder om datasignering, understøtter serveren den.

      • Kræv signering: Indstillingen til LDAP-datasignering skal forhandles, medmindre TLS/SSL (Transport Layer Security/Secure Socket Layer) bruges.

      • ikke defineret: Denne indstilling er ikke aktiveret eller deaktiveret.

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Aktivering Afkræv signering i miljøer, hvor klienter ikke understøtter LDAP-signering, eller hvor LDAP-signering på klientsiden ikke er aktiveret på klienten

      • Anvendelse af sikkerhedsskabelonen Windows 2000 eller Windows Server 2003 Hisecdc.inf i miljøer, hvor klienterne ikke understøtter LDAP-signering, eller hvor LDAP-signering på klientsiden ikke er aktiveret

      • Anvendelse af sikkerhedsskabelonen Windows 2000 eller Windows Server 2003 Hisecws.inf i miljøer, hvor klienterne ikke understøtter LDAP-signering, eller hvor LDAP-signering på klientsiden ikke er aktiveret

    3. Årsager til at aktivere denne indstilling

      Usigneret netværkstrafik er modtagelig for man-in-the-middle-angreb, hvor en ubuden gæst registrerer pakker mellem klienten og serveren, ændrer pakkerne og videresender dem derefter til serveren. Når denne funktionsmåde opstår på en LDAP-server, kan en hacker få en server til at træffe beslutninger, der er baseret på falske forespørgsler fra LDAP-klienten. Du kan reducere denne risiko i et virksomhedsnetværk ved at implementere stærke fysiske sikkerhedsforanstaltninger for at beskytte netværksinfrastrukturen. IpSec-godkendelsesheadertilstand (Internet Protocol Security) kan være med til at forhindre mand-i-midt-angreb. Godkendelsesheadertilstand udfører gensidig godkendelse og pakkeintegritet for IP-trafik.

    4. Årsager til at deaktivere denne indstilling

      • Klienter, der ikke understøtter LDAP-signering, kan ikke udføre LDAP-forespørgsler mod domænecontrollere og mod globale kataloger, hvis der forhandles om NTLM-godkendelse, og hvis de korrekte servicepakker ikke er installeret på Windows 2000-domænecontrollere.

      • Netværkssporinger af LDAP-trafik mellem klienter og servere krypteres. Det gør det svært at undersøge LDAP-samtaler.

      • Windows 2000-baserede servere skal have Windows 2000 Service Pack 3 (SP3) installeret, når de administreres med programmer, der understøtter LDAP-signering, der køres fra klientcomputere, der kører Windows 2000 SP4, Windows XP eller Windows Server 2003.  

    5. Symbolsk navn:

      LDAPServerIntegrity

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      • Simple bindinger mislykkes, og du modtager følgende fejlmeddelelse:

        Ldap_simple_bind_s() mislykkedes: Stærk godkendelse påkrævet.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter, der kører Windows 2000 SP4, Windows XP eller Windows Server 2003, fungerer nogle Active Directory-administrationsværktøjer ikke korrekt mod domænecontrollere, der kører versioner af Windows 2000, som er tidligere end SP3, når der forhandles om NTLM-godkendelse.

         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter, der kører Windows 2000 SP4, Windows XP eller Windows Server 2003, vil nogle Active Directory-administrationsværktøjer, der er målrettet mod domænecontrollere, der kører versioner af Windows 2000, som er tidligere end SP3, ikke fungere korrekt, hvis de bruger IP-adresser (f.eks. "dsa.msc /server=x.x.x.x", hvor
        x.x.x.x er en IP-adresse).


         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: På klienter, der kører Windows 2000 SP4, Windows XP eller Windows Server 2003, vil nogle Active Directory-administrationsværktøjer, der er målrettet mod domænecontrollere, der kører versioner af Windows 2000, som er tidligere end SP3, ikke fungere korrekt.

         

  3. Domænemedlem: Kræver en stærk sessionsnøgle (Windows 2000 eller nyere)

    1. Baggrund

      • Domænemedlemmet: Kræv stærk (Windows 2000 eller nyere) sessionsnøgleindstilling bestemmer, om en sikker kanal kan oprettes med en domænecontroller, der ikke kan kryptere sikker kanaltrafik med en stærk 128-bit sessionsnøgle. Aktivering af denne indstilling forhindrer oprettelse af en sikker kanal med en domænecontroller, der ikke kan kryptere data for sikre kanaler med en stærk nøgle. Hvis du deaktiverer denne indstilling, kan du bruge 64-bit sessionsnøgler.

      • Før du kan aktivere denne indstilling på en medlemsarbejdsstation eller på en server, skal alle domænecontrollere på det domæne, som medlemmet tilhører, kunne kryptere data til sikre kanaler med en stærk 128-bit nøgle. Det betyder, at alle sådanne domænecontrollere skal køre Windows 2000 eller nyere.

    2. Risikabel konfiguration

      Aktivering af indstillingen Domænemedlem: Kræv stærk sessionsnøgle (Windows 2000 eller nyere) er en skadelig konfigurationsindstilling.

    3. Årsager til at aktivere denne indstilling

      • Sessionsnøgler, der bruges til at etablere sikker kanalkommunikation mellem medlemscomputere og domænecontrollere, er meget stærkere i Windows 2000 end i tidligere versioner af Microsoft-operativsystemer.

      • Når det er muligt, er det en god ide at drage fordel af disse stærkere sessionsnøgler for at beskytte sikker kanalkommunikation mod aflytning og mod session kapring af netværksangreb. Aflytning er en form for ondsindet angreb, hvor netværksdata læses eller ændres under transport. Dataene kan ændres for at skjule eller ændre afsenderen eller for at omdirigere dem.

      Vigtigt! En computer, der kører Windows Server 2008 R2 eller Windows 7, understøtter kun stærke taster, når der bruges sikre kanaler. Denne begrænsning forhindrer et tillidsforhold mellem et Windows NT 4.0-baseret domæne og et Windows Server 2008 R2-baseret domæne. Desuden blokerer denne begrænsning det Windows NT 4.0-baserede domænemedlemskab på computere, der kører Windows 7 eller Windows Server 2008 R2 og omvendt.

    4. Årsager til at deaktivere denne indstilling

      Domænet indeholder medlemscomputere, der kører andre operativsystemer end Windows 2000, Windows XP eller Windows Server 2003.

    5. Symbolsk navn:

      StrongKey

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      Windows NT 4.0: Nulstilling af sikre kanaler for tillidsforhold mellem Windows NT 4.0- og Windows 2000-domæner med NLTEST mislykkes på Windows NT 4.0-baserede computere. Fejlmeddelelsen "Adgang nægtet" vises:

      Tillidsforholdet mellem det primære domæne og det domæne, der er tillid til, mislykkedes.

      Windows 7 og Server 2008 R2: Til Windows 7 og nyere versioner og Windows Server 2008 R2 og nyere versioner er denne indstilling ikke længere accepteret, og den stærke nøgle bruges altid. Derfor fungerer tillidsforhold til Windows NT 4.0-domæner ikke længere.

  4. Domænemedlem: Kryptér eller signer data til sikre kanaler digitalt (altid)

    1. Baggrund

      • Aktivering af domænemedlem: Kryptér eller signer data til sikker kanal (altid) digitalt forhindrer oprettelse af en sikker kanal med en domænecontroller, der ikke kan signere eller kryptere alle data til sikre kanaler. For at beskytte godkendelsestrafik mod man-in-the-middle-angreb, genafspilning af angreb og andre typer netværksangreb opretter Windows-baserede computere en kommunikationskanal, der er kendt som en sikker kanal via tjenesten Netlogon for at godkende computerkonti. Sikre kanaler bruges også, når en bruger på ét domæne opretter forbindelse til en netværksressource i et fjerndomæne. Denne multidomænegodkendelse eller pass-through-godkendelse giver en Windows-baseret computer, der har tilsluttet sig et domæne, mulighed for at få adgang til brugerkontodatabasen på dets domæne og i alle domæner, der er tillid til.

      • For at aktivere domænemedlemmet: Kryptér eller signer data til sikre kanaler (altid) digitalt på en medlemscomputer, skal alle domænecontrollere på det domæne, som medlemmet tilhører, kunne signere eller kryptere alle data for sikre kanaler. Det betyder, at alle sådanne domænecontrollere skal køre Windows NT 4.0 med Service Pack 6a (SP6a) eller nyere.

      • Aktivering af indstillingen Domænemedlem: Kryptér eller signer data til sikre kanaler (altid) digitalt, aktiverer automatisk indstillingen Domænemedlem: Kryptér eller signer data til sikre kanaler digitalt (når det er muligt).

    2. Risikabel konfiguration

      Aktivering af indstillingen Domænemedlem: Kryptér eller signer data til sikre kanaler (altid) digitalt på domæner, hvor ikke alle domænecontrollere kan signere eller kryptere data for sikre kanaler, er en skadelig konfigurationsindstilling.

    3. Årsager til at aktivere denne indstilling

      Usigneret netværkstrafik er modtagelig for man-in-the-middle-angreb, hvor en ubuden gæst registrerer pakker mellem serveren og klienten og derefter ændrer dem, før de videresendes til klienten. Når denne funktionsmåde opstår på en LDAP-server (Lightweight Directory Access Protocol), kan den ubudne gæst få en klient til at træffe beslutninger, der er baseret på falske poster fra LDAP-mappen. Du kan reducere risikoen for et sådant angreb på et virksomhedsnetværk ved at implementere stærke fysiske sikkerhedsforanstaltninger for at beskytte netværksinfrastrukturen. Desuden kan implementering af IPSec-godkendelsesheadertilstand (Internet Protocol Security) være med til at forhindre angreb mellem mand og mellem. Denne tilstand udfører gensidig godkendelse og pakkeintegritet for IP-trafik.

    4. Årsager til at deaktivere denne indstilling

      • Computere på lokale eller eksterne domæner understøtter krypterede sikre kanaler.

      • Ikke alle domænecontrollere på domænet har de rette revisionsniveauer for servicepakker til at understøtte krypterede sikre kanaler.

    5. Symbolsk navn:

      StrongKey

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      • Windows NT 4.0: Windows 2000-baserede medlemscomputere kan ikke deltage i Windows NT 4.0-domæner og modtager følgende fejlmeddelelse:

        Kontoen er ikke autoriseret til at logge på fra denne station.

        Du kan få mere at vide ved at klikke på nedenstående artikelnummer for at få vist artiklen i Microsoft Knowledge Base:

        281648 Fejlmeddelelse: Kontoen er ikke godkendt til at logge på fra denne station
         

      • Windows NT 4.0: Windows NT 4.0-domæner kan ikke oprette et tillidsforhold til et Windows 2000-domæne og modtager følgende fejlmeddelelse:

        Kontoen er ikke autoriseret til at logge på fra denne station.

        Eksisterende tillidsforhold på nedniveau kan muligvis heller ikke godkende brugere fra det domæne, der er tillid til. Nogle brugere kan have problemer med at logge på domænet, og de modtager muligvis en fejlmeddelelse om, at klienten ikke kan finde domænet.

      • Windows XP: Windows XP-klienter, der er tilsluttet Windows NT 4.0-domæner, vil ikke kunne godkende logonforsøg og kan modtage følgende fejlmeddelelse, eller følgende hændelser kan registreres i hændelsesloggen:

        Windows kan ikke oprette forbindelse til domænet, enten fordi domænecontrolleren er nede eller på anden måde ikke er tilgængelig, eller fordi din computerkonto ikke blev fundet

      • Microsoft Network: Microsoft Network-klienter modtager en af følgende fejlmeddelelser:

        Logonfejl: Ukendt brugernavn eller forkert adgangskode.

        Der er ingen brugersessionsnøgle for den angivne logonsession.

  5. Microsoft-netværksklient: Signer kommunikation digitalt (altid)

    1. Baggrund

      SMB (Server Message Block) er den ressourcedelingsprotokol, der understøttes af mange Microsoft-operativsystemer. Det er grundlaget for netværkets grundlæggende input/output-system (NetBIOS) og mange andre protokoller. SMB-signering godkender både brugeren og den server, der hoster dataene. Hvis en af siderne mislykkes godkendelsesprocessen, sker der ikke dataoverførsel.

      Aktivering af SMB-signering starter under SMB-protokolforhandling. SMB-signeringspolitikkerne afgør, om computeren altid signerer klientkommunikation digitalt.

      Windows 2000 SMB-godkendelsesprotokollen understøtter gensidig godkendelse. Gensidig godkendelse lukker et "man-in-the-middle"-angreb. Windows 2000 SMB-godkendelsesprotokollen understøtter også meddelelsesgodkendelse. Meddelelsesgodkendelse hjælper med at forhindre aktive meddelelsesangreb. For at give dig denne godkendelse indsætter SMB-signering en digital signatur i hver SMB. Klienten og serveren bekræfter hver især den digitale signatur.

      Hvis du vil bruge SMB-signering, skal du aktivere SMB-signering eller kræve SMB-signering på både SMB-klienten og SMB-serveren. Hvis SMB-signering er aktiveret på en server, bruger klienter, der også er aktiveret til SMB-signering, pakkesigneringsprotokollen under alle efterfølgende sessioner. Hvis SMB-signering er påkrævet på en server, kan en klient ikke oprette en session, medmindre klienten er aktiveret eller påkrævet til SMB-signering.


      Aktivering af digital signering i netværk med høj sikkerhed er med til at forhindre repræsentation af klienter og servere. Denne form for repræsentation er kendt som session kapring. En hacker, der har adgang til det samme netværk som klienten eller serveren, bruger session kapringsværktøjer til at afbryde, afslutte eller stjæle en igangværende session. En hacker kan opfange og ændre usignerede SMB-pakker, ændre trafikken og derefter videresende den, så serveren kan udføre uønskede handlinger. Eller hackeren kan udgøre sig som serveren eller som klienten efter en legitim godkendelse og derefter få uautoriseret adgang til data.

      Den SMB-protokol, der bruges til fildeling og udskriftsdeling på computere, der kører Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003, understøtter gensidig godkendelse. Gensidig godkendelse lukker session kapringsangreb og understøtter meddelelsesgodkendelse. Derfor forhindrer det man-in-the-middle angreb. SMB-signering giver denne godkendelse ved at placere en digital signatur i hver SMB. Klienten og serveren bekræfter derefter signaturen.

      Noter

      • Som en alternativ modforanstaltning kan du aktivere digitale signaturer med IPSec for at beskytte al netværkstrafik. Der er hardwarebaserede acceleratorer til IPSec-kryptering og -signering, som du kan bruge til at minimere påvirkningen af ydeevnen fra serverens CPU. Der er ingen sådanne acceleratorer, der er tilgængelige til SMB-signering.

        Du kan få mere at vide i afsnittet Digitally sign server communications på webstedet Microsoft MSDN.

        Konfigurer SMB-signering via Gruppepolitik Objekteditor, fordi en ændring af en lokal registreringsdatabaseværdi ikke har nogen effekt, hvis der er en tilsidesættende domænepolitik.

      • I Windows 95, Windows 98 og Windows 98 Second Edition bruger Directory Services-klienten SMB-signering, når den godkendes med Windows Server 2003-servere ved hjælp af NTLM-godkendelse. Disse klienter bruger dog ikke SMB-signering, når de godkendes med disse servere ved hjælp af NTLMv2-godkendelse. Desuden reagerer Windows 2000-servere ikke på SMB-signeringsanmodninger fra disse klienter. Du kan få mere at vide under punkt 10: "Netværkssikkerhed: Lan Manager-godkendelsesniveau.".

    2. Risikabel konfiguration

      Følgende er en skadelig konfigurationsindstilling: Lader både Microsoft-netværksklienten: Indstillingen Signer kommunikation digitalt (altid) og Microsoft-netværksklienten: Signer kommunikation digitalt (hvis serveren accepterer det) indstillet til "Ikke defineret" eller deaktiveret. Disse indstillinger gør det muligt for omdirigeringen at sende adgangskoder til almindelig tekst til SMB-servere, der ikke understøtter kryptering af adgangskoder under godkendelse.

    3. Årsager til at aktivere denne indstilling

      Aktivering af Microsoft-netværksklient: Signer kommunikation digitalt (altid) kræver, at klienter signerer SMB-trafik, når der kontaktes servere, der ikke kræver SMB-signering. Dette gør klienter mindre sårbare over for session kapring angreb.

    4. Årsager til at deaktivere denne indstilling

      • Aktivering af Microsoft-netværksklient: Signer kommunikation digitalt (altid) forhindrer klienter i at kommunikere med destinationsservere, der ikke understøtter SMB-signering.

      • Konfiguration af computere til at ignorere al usigneret SMB-kommunikation forhindrer tidligere programmer og operativsystemer i at oprette forbindelse.

    5. Symbolsk navn:

      RequireSMBSignRdr

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      • Windows NT 4.0: Du kan ikke nulstille den sikre kanal for et tillidsforhold mellem et Windows Server 2003-domæne og et Windows NT 4.0-domæne ved hjælp af NLTEST eller NETDOM, og du får vist fejlmeddelelsen "Adgang nægtet".

      • Windows XP: Kopiering af filer fra Windows XP-klienter til Windows 2000-baserede servere og til Windows Server 2003-baserede servere kan tage længere tid.

      • Du kan ikke tilknytte et netværksdrev fra en klient med denne indstilling aktiveret, og du får vist følgende fejlmeddelelse:

        Kontoen er ikke autoriseret til at logge på fra denne station.

    8. Krav til

      genstart Genstart computeren, eller genstart tjenesten Workstation. Det gør du ved at skrive følgende kommandoer ved en kommandoprompt. Tryk på Enter, når du har skrevet hver kommando.

      net stop workstation
      net start workstation

  6. Microsoft-netværksserver: Signer kommunikation digitalt (altid)

    1. Baggrund

      • Server Messenger Block (SMB) er den ressourcedelingsprotokol, der understøttes af mange Microsoft-operativsystemer. Det er grundlaget for netværkets grundlæggende input/output-system (NetBIOS) og mange andre protokoller. SMB-signering godkender både brugeren og den server, der hoster dataene. Hvis en af siderne mislykkes godkendelsesprocessen, sker der ikke dataoverførsel.

        Aktivering af SMB-signering starter under SMB-protokolforhandling. SMB-signeringspolitikkerne afgør, om computeren altid signerer klientkommunikation digitalt.

        Windows 2000 SMB-godkendelsesprotokollen understøtter gensidig godkendelse. Gensidig godkendelse lukker et "man-in-the-middle"-angreb. Windows 2000 SMB-godkendelsesprotokollen understøtter også meddelelsesgodkendelse. Meddelelsesgodkendelse hjælper med at forhindre aktive meddelelsesangreb. For at give dig denne godkendelse indsætter SMB-signering en digital signatur i hver SMB. Klienten og serveren bekræfter hver især den digitale signatur.

        Hvis du vil bruge SMB-signering, skal du aktivere SMB-signering eller kræve SMB-signering på både SMB-klienten og SMB-serveren. Hvis SMB-signering er aktiveret på en server, bruger klienter, der også er aktiveret til SMB-signering, pakkesigneringsprotokollen under alle efterfølgende sessioner. Hvis SMB-signering er påkrævet på en server, kan en klient ikke oprette en session, medmindre klienten er aktiveret eller påkrævet til SMB-signering.


        Aktivering af digital signering i netværk med høj sikkerhed er med til at forhindre repræsentation af klienter og servere. Denne form for repræsentation er kendt som session kapring. En hacker, der har adgang til det samme netværk som klienten eller serveren, bruger session kapringsværktøjer til at afbryde, afslutte eller stjæle en igangværende session. En hacker kan opfange og ændre usignerede SBM-pakker (Subnet Bandwidth Manager), ændre trafikken og derefter videresende den, så serveren kan udføre uønskede handlinger. Eller hackeren kan udgøre sig som serveren eller som klienten efter en legitim godkendelse og derefter få uautoriseret adgang til data.

        Den SMB-protokol, der bruges til fildeling og udskriftsdeling på computere, der kører Windows 2000 Server, Windows 2000 Professional, Windows XP Professional eller Windows Server 2003, understøtter gensidig godkendelse. Gensidig godkendelse lukker session kapringsangreb og understøtter meddelelsesgodkendelse. Derfor forhindrer det man-in-the-middle angreb. SMB-signering giver denne godkendelse ved at placere en digital signatur i hver SMB. Klienten og serveren bekræfter derefter signaturen.

      • Som en alternativ modforanstaltning kan du aktivere digitale signaturer med IPSec for at beskytte al netværkstrafik. Der er hardwarebaserede acceleratorer til IPSec-kryptering og -signering, som du kan bruge til at minimere påvirkningen af ydeevnen fra serverens CPU. Der er ingen sådanne acceleratorer, der er tilgængelige til SMB-signering.

      • I Windows 95, Windows 98 og Windows 98 Second Edition bruger Directory Services-klienten SMB-signering, når den godkendes med Windows Server 2003-servere ved hjælp af NTLM-godkendelse. Disse klienter bruger dog ikke SMB-signering, når de godkendes med disse servere ved hjælp af NTLMv2-godkendelse. Desuden reagerer Windows 2000-servere ikke på SMB-signeringsanmodninger fra disse klienter. Du kan få mere at vide under punkt 10: "Netværkssikkerhed: Lan Manager-godkendelsesniveau.".

    2. Risikabel konfiguration

      Følgende er en skadelig konfigurationsindstilling: Aktivering af Microsoft-netværksserveren: Indstillingen Signer kommunikation digitalt (altid) på servere og på domænecontrollere, der tilgås af inkompatible Windows-baserede computere og tredjepartsoperativsystemerbaserede klientcomputere på lokale eller eksterne domæner.

    3. Årsager til at aktivere denne indstilling

      • Alle klientcomputere, der aktiverer denne indstilling direkte via registreringsdatabasen eller via indstillingen Gruppepolitik, understøtter SMB-signering. Med andre ord kører alle klientcomputere, der har denne indstilling aktiveret, enten Windows 95 med DS-klienten installeret, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional eller Windows Server 2003.

      • Hvis Microsoft-netværksserver: Signer kommunikation digitalt (altid) er deaktiveret, er SMB-signering helt deaktiveret. Fuldstændig deaktivering af al SMB-signering gør computere mere sårbare over for session kapringsangreb.

    4. Årsager til at deaktivere denne indstilling

      • Aktivering af denne indstilling kan medføre langsommere filkopiering og netværksydeevne på klientcomputere.

      • Aktivering af denne indstilling forhindrer klienter, der ikke kan forhandle SMB-signering, i at kommunikere med servere og med domænecontrollere. Dette medfører, at handlinger som domænetilslutninger, bruger- og computergodkendelse eller netværksadgang fra programmer mislykkes.

    5. Symbolsk navn:

      RequireSMBSignServer

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

      • Windows 95: Windows 95-klienter, der ikke har DS-klienten (Directory Services) installeret, vil mislykkes med logongodkendelse og modtager følgende fejlmeddelelse:

        Den angivne domæneadgangskode er ikke korrekt, eller adgang til logonserveren er blevet nægtet.

      • Windows NT 4.0: Klientcomputere, der kører versioner af Windows NT 4.0, som er ældre end Service Pack 3 (SP3), kan ikke logge på og modtager følgende fejlmeddelelse:

        Systemet kunne ikke logge dig på. Sørg for, at dit brugernavn og dit domæne er korrekt, og skriv derefter din adgangskode igen.

        Nogle SMB-servere, der ikke er fra Microsoft, understøtter kun ikke-krypterede adgangskodeudvekslinger under godkendelse. (Disse udvekslinger kaldes også "almindelige tekstudvekslinger"). I Windows NT 4.0 SP3 og nyere versioner sender SMB-omdirigering ikke en ukrypteret adgangskode under godkendelse til en SMB-server, medmindre du tilføjer en bestemt post i registreringsdatabasen.
        Hvis du vil aktivere ikke-krypterede adgangskoder for SMB-klienten på Windows NT 4.0 SP 3 og nyere systemer, skal du ændre registreringsdatabasen på følgende måde: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

        Værdinavn: EnablePlainTextPassword

        Datatype: REG_DWORD

        Data: 1

         

      • Windows Server 2003: Som standard er sikkerhedsindstillinger på domænecontrollere, der kører Windows Server 2003, konfigureret til at forhindre domænecontrollerkommunikation i at blive opsnappet eller ændret af ondsindede brugere. For at brugerne kan kommunikere med en domænecontroller, der kører Windows Server 2003, skal klientcomputere bruge både SMB-signering og kryptering eller signering af sikker kanaltrafik. Som standard har klienter, der kører Windows NT 4.0 med Service Pack 2 (SP2) eller tidligere installeret, og klienter, der kører Windows 95, ikke SMB-pakkesignering aktiveret. Derfor kan disse klienter muligvis ikke godkende til en Windows Server 2003-baseret domænecontroller.

      • Politikindstillinger for Windows 2000 og Windows Server 2003: Afhængigt af dine specifikke installationsbehov og konfiguration anbefaler vi, at du angiver følgende politikindstillinger til det laveste omfang af det nødvendige omfang i snap-in-hierarkiet i Microsoft Management Console Gruppepolitik Editor:

        • Computerkonfiguration\Windows Sikkerhed Indstillinger\Sikkerhedsindstillinger

        • Send ikke-krypteret adgangskode for at oprette forbindelse til tredjeparts SMB-servere (denne indstilling er til Windows 2000)

        • Microsoft-netværksklient: Send ikke-krypteret adgangskode til tredjeparts SMB-servere (denne indstilling er til Windows Server 2003)


        Bemærk! På nogle cifs-servere fra tredjepart, f.eks. ældre Samba-versioner, kan du ikke bruge krypterede adgangskoder.

      • Følgende klienter er ikke kompatible med Microsoft-netværksserveren: Indstillingen Signer kommunikation digitalt (altid):

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

        • Microsoft MS-DOS-netværksklienter (f.eks. Microsoft LAN Manager)

        • Microsoft Windows for Workgroups-klienter

        • Microsoft Windows 95-klienter, uden at DS-klienten er installeret

        • Microsoft Windows NT 4.0-baserede computere uden SP3 eller nyere installeret

        • Novell Netware 6 CIFS-klienter

        • SAMBA SMB-klienter, der ikke understøtter SMB-signering

    8. Krav til

      genstart Genstart computeren, eller genstart servertjenesten. Det gør du ved at skrive følgende kommandoer ved en kommandoprompt. Tryk på Enter, når du har skrevet hver kommando.

      net stop server
      net start server

  7. Netværksadgang: Tillad anonym oversættelse af SID/navn

    1. Baggrund

      Netværksadgang: Sikkerhedsindstillingen Tillad anonym SID/navneoversættelse bestemmer, om en anonym bruger kan anmode om SID-attributter (Security Identification Number) for en anden bruger.

    2. Risikabel konfiguration

      Aktivering af netværksadgang: Indstillingen Tillad anonym oversættelse af SID/navn er en skadelig konfigurationsindstilling.

    3. Årsager til at aktivere denne indstilling

      Hvis indstillingen Netværksadgang: Tillad anonym oversættelse af SID/navn er deaktiveret, kan tidligere operativsystemer eller programmer muligvis ikke kommunikere med Windows Server 2003-domæner. Følgende operativsystemer, tjenester eller programmer fungerer f.eks. muligvis ikke:

      • Windows NT 4.0-baserede Remote Access Service-servere

      • Microsoft SQL Server, der kører på Windows NT 3.x-baserede computere eller Windows NT 4.0-baserede computere

      • Remote Access Service, der kører på Windows 2000-baserede computere, der er placeret i Windows NT 3.x-domæner eller Windows NT 4.0-domæner

      • SQL Server, der kører på Windows 2000-baserede computere, der er placeret i Windows NT 3.x-domæner eller i Windows NT 4.0-domæner

      • Brugere i Windows NT 4.0-ressourcedomænet, der vil give tilladelse til at få adgang til filer, delte mapper og objekter i registreringsdatabasen til brugerkonti fra kontodomæner, der indeholder Windows Server 2003-domænecontrollere

    4. Årsager til at deaktivere denne indstilling

      Hvis denne indstilling er aktiveret, kan en ondsindet bruger bruge det velkendte administrator-SID til at få det rigtige navn på den indbyggede administratorkonto, også selvom kontoen er blevet omdøbt. Personen kan derefter bruge kontonavnet til at starte et angreb, der gætter på adgangskoder.

    5. Symbolsk navn: I/T

    6. Sti til registreringsdatabasen: Ingen. Stien er angivet i brugergrænsefladens kode.

    7. Eksempler på kompatibilitetsproblemer

      Windows NT 4.0: Computere i Windows NT 4.0-ressourcedomæner viser fejlmeddelelsen "Konto ukendt" i ACL Editor, hvis ressourcer, herunder delte mapper, delte filer og registreringsdatabaseobjekter, er sikret med sikkerhedsprincipaler, der findes på kontodomæner, der indeholder Windows Server 2003-domænecontrollere.

  8. Netværksadgang: Tillad ikke anonym optælling af SAM-konti

    1. Baggrund

      • Indstillingen Netværksadgang: Tillad ikke anonym optælling af SAM-konti bestemmer, hvilke yderligere tilladelser der tildeles til anonyme forbindelser til computeren. Windows giver anonyme brugere mulighed for at udføre visse aktiviteter, f.eks. optælling af navnene på arbejdsstations- og serverkonti til Sikkerhedskontostyring (SAM) og på netværksshares. En administrator kan f.eks. bruge dette til at give adgang til brugere på et domæne, der er tillid til, og som ikke har et gensidigt tillidsforhold. Når en session er oprettet, kan en anonym bruger have den samme adgang, der gives til gruppen Alle, baseret på indstillingen i Netværksadgang: Lad alle-tilladelser gælde for anonyme brugere, indstilling eller DACL (Discretionary Access Control List) for objektet.

        Typisk anmodes der om anonyme forbindelser i tidligere versioner af klienter (klienter på nedniveau) under konfiguration af SMB-sessionen. I disse tilfælde viser en netværkssporing, at SMB-proces-id'et (PID) er klientomdirigeringsenheden, f.eks. 0xFEFF i Windows 2000 eller 0xCAFE i Windows NT. RPC kan også forsøge at oprette anonyme forbindelser.

      • Vigtigt! Denne indstilling har ingen indflydelse på domænecontrollere. På domænecontrollere styres denne funktionsmåde af tilstedeværelsen af "NT AUTHORITY\ANONYMOUS LOGON" i "Pre-Windows 2000 compatible Access".

      • I Windows 2000 administrerer en lignende indstilling kaldet Yderligere begrænsninger for anonyme forbindelser registreringsdatabaseværdien RestrictAnonymous . Placeringen af denne værdi er som følger

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

    2. Risikable konfigurationer

      Aktivering af indstillingen Netværksadgang: Tillad ikke anonym optælling af SAM-konti er en skadelig konfigurationsindstilling fra et kompatibilitetsperspektiv. Deaktivering af den er en skadelig konfigurationsindstilling fra et sikkerhedsperspektiv.

    3. Årsager til at aktivere denne indstilling

      En uautoriseret bruger kan anonymt angive kontonavne og derefter bruge oplysningerne til at prøve at gætte adgangskoder eller udføre social engineering-angreb. Social engineering er jargon, der betyder at narre folk til at afsløre deres adgangskoder eller en form for sikkerhedsoplysninger.

    4. Årsager til at deaktivere denne indstilling

      Hvis denne indstilling er aktiveret, er det umuligt at oprette tillidsforhold til Windows NT 4.0-domæner. Denne indstilling medfører også problemer med nedgraderede klienter (f.eks. Windows NT 3.51-klienter og Windows 95-klienter), der forsøger at bruge ressourcer på serveren.

    5. Symbolsk navn:


      RestrictAnonymousSAM

    6. Sti til registreringsdatabasen:

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

    7. Eksempler på kompatibilitetsproblemer

    • SMS Network Discovery kan ikke hente oplysninger om operativsystemet og skriver "Ukendt" i egenskaben OperatingSystemNameandVersion.

    • Windows 95, Windows 98: Windows 95-klienter og Windows 98-klienter kan ikke ændre deres adgangskoder.

    • Windows NT 4.0: Windows NT 4.0-baserede medlemscomputere kan ikke godkendes.

    • Windows 95, Windows 98: Windows 95-baserede og Windows 98-baserede computere kan ikke godkendes af Microsoft-domænecontrollere.

    • Windows 95, Windows 98: Brugere på Windows 95-baserede og Windows 98-baserede computere kan ikke ændre adgangskoderne for deres brugerkonti.

  9. Netværksadgang: Tillad ikke anonym optælling af SAM-konti og -shares

    1. Baggrund

      • Indstillingen Netværksadgang: Tillad ikke anonym optælling af SAM-konti og -shares (også kaldet RestrictAnonymous) bestemmer, om anonym optælling af SAM-konti og -shares (Security Accounts Manager) er tilladt. Windows giver anonyme brugere mulighed for at udføre visse aktiviteter, f.eks. optælling af navnene på domænekonti (brugere, computere og grupper) og på netværksshares. Dette er f.eks. praktisk, når en administrator vil give adgang til brugere på et domæne, der er tillid til, og som ikke har et gensidigt tillidsforhold. Hvis du ikke vil tillade anonym optælling af SAM-konti og -shares, skal du aktivere denne indstilling.

      • I Windows 2000 administrerer en lignende indstilling kaldet Yderligere begrænsninger for anonyme forbindelser registreringsdatabaseværdien RestrictAnonymous . Placeringen af denne værdi er som følger:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

    2. Risikabel konfiguration

      Aktivering af netværksadgang: Tillad ikke anonym optælling af SAM-konti og -shares er en skadelig konfigurationsindstilling.

    3. Årsager til at aktivere denne indstilling

      • Aktivering af indstillingen Netværksadgang: Tillad ikke anonym optælling af SAM-konti og -shares forhindrer optælling af SAM-konti og -shares for brugere og computere, der bruger anonyme konti.

    4. Årsager til at deaktivere denne indstilling

      • Hvis denne indstilling er aktiveret, kan en uautoriseret bruger anonymt angive kontonavne og derefter bruge oplysningerne til at prøve at gætte adgangskoder eller udføre social engineering-angreb. Social engineering er jargon, der betyder at narre folk til at afsløre deres adgangskode eller en form for sikkerhedsoplysninger.

      • Hvis denne indstilling er aktiveret, vil det være umuligt at oprette tillidsforhold til Windows NT 4.0-domæner. Denne indstilling vil også medføre problemer med klienter på nedgraderede niveauer, f.eks. Windows NT 3.51- og Windows 95-klienter, der forsøger at bruge ressourcer på serveren.

      • Det vil være umuligt at give adgang til brugere af ressourcedomæner, fordi administratorer på domænet, der er tillid til, ikke vil kunne optælle lister over konti i det andet domæne. Brugere, der får adgang til fil- og udskriftsservere anonymt, vil ikke kunne få vist de delte netværksressourcer på disse servere. Brugerne skal godkendes, før de kan få vist listerne over delte mapper og printere.

    5. Symbolsk navn:

      RestrictAnonymous

    6. Sti til registreringsdatabasen:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

    7. Eksempler på kompatibilitetsproblemer

      • Windows NT 4.0: Brugere kan ikke ændre deres adgangskoder fra Windows NT 4.0-arbejdsstationer, når RestrictAnonymous er aktiveret på domænecontrollere i brugernes domæne.

      • Windows NT 4.0: Tilføjelse af brugere eller globale grupper fra pålidelige Windows 2000-domæner til lokale Windows NT 4.0-grupper i Brugerstyring mislykkes, og følgende fejlmeddelelse vises:

        Der er i øjeblikket ingen logonservere tilgængelige til at udføre logonanmodningen.

      • Windows NT 4.0: Windows NT 4.0-baserede computere kan ikke forbinde domæner under installationen eller ved hjælp af brugergrænsefladen til domænetilslutning.

      • Windows NT 4.0: Oprettelse af et tillidsforhold til Windows NT 4.0-ressourcedomæner mislykkes. Følgende fejlmeddelelse vises, når RestrictAnonymous er aktiveret på det domæne, der er tillid til:

        Domænecontrolleren for dette domæne blev ikke fundet.

      • Windows NT 4.0: Brugere, der logger på Windows NT 4.0-baserede Terminal Server-computere, tilknyttes standardstartmappen i stedet for den hjemmemappe, der er defineret i Brugeradministrator for domæner.

      • Windows NT 4.0: Windows NT 4.0-sikkerhedskopierede domænecontrollere (BDCs) vil ikke kunne starte tjenesten Net Logon, få en liste over sikkerhedskopierede browsere eller synkronisere SAM-databasen fra Windows 2000 eller fra Windows Server 2003-domænecontrollere i det samme domæne.

      • Windows 2000: Windows 2000-baserede medlemscomputere i Windows NT 4.0-domæner kan ikke få vist printere på eksterne domæner, hvis indstillingen Ingen adgang uden eksplicit anonyme tilladelser er aktiveret i klientcomputerens lokale sikkerhedspolitik.

      • Windows 2000: Windows 2000-domænebrugere kan ikke tilføje netværksprintere fra Active Directory. De vil dog kunne tilføje printere, når de har valgt dem fra trævisningen.

      • Windows 2000: På Windows 2000-baserede computere kan ACL Editor ikke tilføje brugere eller globale grupper fra Windows NT 4.0-domæner, der er tillid til.

      • ADMT version 2: Overførsel af adgangskode for brugerkonti, der overføres mellem skove med ADMT (Active Directory Migration Tool) version 2, mislykkes.

        Du kan få mere at vide ved at klikke på nedenstående artikelnummer for at få vist artiklen i Microsoft Knowledge Base:

        322981 Sådan foretager du fejlfinding af overførsel af adgangskode mellem skoven med ADMTv2

      • Outlook-klienter: Den globale adresseliste vises tom for Microsoft Exchange Outlook-klienter.

      • SMS: Microsoft Sms (Systems Management Server) Network Discovery kan ikke hente oplysninger om operativsystemet. Der skrives derfor "Ukendt" i egenskaben OperatingSystemNameandVersion for egenskaben SMS DDR for registreringsdataposten (DDR).

      • SMS: Når du bruger guiden Sms-administratorbruger til at søge efter brugere og grupper, vises ingen brugere eller grupper. Desuden kan avancerede klienter ikke kommunikere med Administrationspunkt. Anonym adgang er påkrævet på administrationspunktet.

      • SMS: Når du bruger funktionen Network Discovery i SMS 2.0 og i Fjernklientinstallation med indstillingen Netværksregistrering i topologi, klient og klientoperativsystemer slået til, kan computere blive fundet, men installeres muligvis ikke.

  10. Netværkssikkerhed: Lan Manager-godkendelsesniveau

    1. Baggrund

      LAN Manager-godkendelse (LM) er den protokol, der bruges til at godkende Windows-klienter til netværkshandlinger, herunder domænetilslutninger, adgang til netværksressourcer og bruger- eller computergodkendelse. LM-godkendelsesniveauet bestemmer, hvilken challenge/response-godkendelsesprotokol der forhandles mellem klienten og servercomputerne. Specifikt bestemmer LM-godkendelsesniveauet, hvilke godkendelsesprotokoller klienten vil forsøge at forhandle, eller som serveren accepterer. Den værdi, der er angivet for LmCompatibilityLevel, bestemmer, hvilken challenge/response-godkendelsesprotokol der bruges til netværkslogon. Denne værdi påvirker det godkendelsesniveau, som klienter bruger, det niveau af sessionssikkerhed, der forhandles om, og det godkendelsesniveau, der accepteres af servere.

      Mulige indstillinger omfatter følgende.

      Værdi

      Indstilling

      Beskrivelse

      0

      Send LM-& NTLM-svar

      Klienter bruger LM- og NTLM-godkendelse og bruger aldrig NTLMv2-sessionssikkerhed. Domænecontrollere accepterer LM-, NTLM- og NTLMv2-godkendelse.

      1

      Send LM & NTLM – brug NTLMv2-sessionssikkerhed, hvis der forhandles

      Klienter bruger LM- og NTLM-godkendelse og bruger NTLMv2-sessionssikkerhed, hvis serveren understøtter det. Domænecontrollere accepterer LM-, NTLM- og NTLMv2-godkendelse.

      2

      Send kun NTLM-svar

      Klienter bruger kun NTLM-godkendelse og bruger NTLMv2-sessionssikkerhed, hvis serveren understøtter det. Domænecontrollere accepterer LM-, NTLM- og NTLMv2-godkendelse.

      3

      Send kun NTLMv2-svar

      Klienter bruger kun NTLMv2-godkendelse og bruger NTLMv2-sessionssikkerhed, hvis serveren understøtter det. Domænecontrollere accepterer LM-, NTLM- og NTLMv2-godkendelse.

      4

      Send kun NTLMv2-svar/afvis LM

      Klienter bruger kun NTLMv2-godkendelse og bruger NTLMv2-sessionssikkerhed, hvis serveren understøtter det. Domænecontrollere afviser LM og accepterer kun NTLM- og NTLMv2-godkendelse.

      5

      Send kun NTLMv2-svar/afvis LM-& NTLM

      Klienter bruger kun NTLMv2-godkendelse og bruger NTLMv2-sessionssikkerhed, hvis serveren understøtter det. Domænecontrollere afviser LM og NTLM og accepterer kun NTLMv2-godkendelse.

      Bemærk! I Windows 95, Windows 98 og Windows 98 Second Edition bruger Directory Services-klienten SMB-signering, når den godkendes med Windows Server 2003-servere ved hjælp af NTLM-godkendelse. Disse klienter bruger dog ikke SMB-signering, når de godkendes med disse servere ved hjælp af NTLMv2-godkendelse. Desuden reagerer Windows 2000-servere ikke på SMB-signeringsanmodninger fra disse klienter.

      Kontrollér LM-godkendelsesniveauet: Du skal ændre politikken på serveren for at tillade NTLM, eller du skal konfigurere klientcomputeren til at understøtte NTLMv2.

      Hvis politikken er indstillet til (5) Send kun NTLMv2-svar\afviser LM-& NTLM på den destinationscomputer, du vil oprette forbindelse til, skal du enten sænke indstillingen på den pågældende computer eller indstille sikkerheden til den samme indstilling, som findes på den kildecomputer, du opretter forbindelse fra.

      Find den korrekte placering, hvor du kan ændre LAN Manager-godkendelsesniveauet for at indstille klienten og serveren til det samme niveau. Når du har fundet den politik, der angiver LAN Manager-godkendelsesniveauet, og hvis du vil oprette forbindelse til og fra computere, der kører tidligere versioner af Windows, skal du sænke værdien til mindst (1) Send LM-& NTLM – brug NTLM version 2-sessionssikkerhed, hvis der forhandles om det. En effekt af inkompatible indstillinger er, at hvis serveren kræver NTLMv2 (værdi 5), men klienten er konfigureret til kun at bruge LM og NTLMv1 (værdi 0), oplever den bruger, der forsøger godkendelse, en logonfejl, der har en dårlig adgangskode, og som øger antallet af forkerte adgangskoder. Hvis kontolåsning er konfigureret, kan brugeren med tiden blive låst ude.

      Det kan f.eks. være, at du skal kigge på domænecontrolleren, eller du skal muligvis undersøge politikkerne for domænecontrolleren.

      Kig på domænecontrolleren

      Bemærk! Du skal muligvis gentage følgende procedure på alle domænecontrollerne.

      1. Klik på Start, peg på Programmer, og klik derefter på Administration.

      2. Under Lokale sikkerhedsindstillinger skal du udvide Lokale politikker.

      3. Klik på Sikkerhedsindstillinger.

      4. Dobbeltklik på Netværkssikkerhed: LAN Manager-godkendelsesniveau, og klik derefter på en værdi på listen.


      Hvis den effektive indstilling og den lokale indstilling er ens, er politikken blevet ændret på dette niveau. Hvis indstillingerne er forskellige, skal du kontrollere domænecontrollerens politik for at afgøre, om indstillingen Netværkssikkerhed: LAN Manager-godkendelsesniveau er defineret der. Hvis den ikke er defineret der, skal du undersøge politikkerne for domænecontrolleren.

      Undersøg politikkerne for domænecontrolleren

      1. Klik på Start, peg på Programmer, og klik derefter på Administration.

      2. I sikkerhedspolitik for domænecontroller skal du udvide Sikkerhedsindstillinger og derefter udvide Lokale politikker.

      3. Klik på Sikkerhedsindstillinger.

      4. Dobbeltklik på Netværkssikkerhed: LAN Manager-godkendelsesniveau, og klik derefter på en værdi på listen.


      Bemærk

      • Du skal muligvis også kontrollere politikker, der er sammenkædet på webstedsniveau, domæneniveau eller organisationsenhedsniveau for at bestemme, hvor du skal konfigurere LAN Manager-godkendelsesniveauet.

      • Hvis du implementerer en Gruppepolitik indstilling som standarddomænepolitik, anvendes politikken på alle computere i domænet.

      • Hvis du implementerer en Gruppepolitik indstilling som standarddomænecontrollerens politik, gælder politikken kun for serverne i domænecontrollerens OU.

      • Det er en god ide at angive LAN Manager-godkendelsesniveauet i den laveste enhed af det nødvendige omfang i politikprogramhierarkiet.

      Windows Server 2003 har en ny standardindstilling til kun at bruge NTLMv2. Windows Server 2003 og Windows 2000 Server SP3-baserede domænecontrollere har som standard aktiveret politikken "Microsoft-netværksserver: Signer kommunikation digitalt (altid)". Denne indstilling kræver, at SMB-serveren udfører SMB-pakkesignering. Ændringer i Windows Server 2003 blev foretaget, fordi domænecontrollere, filservere, netværksinfrastrukturservere og webservere i en hvilken som helst organisation kræver forskellige indstillinger for at maksimere deres sikkerhed.

      Hvis du vil implementere NTLMv2-godkendelse i dit netværk, skal du sikre dig, at alle computerne på domænet er indstillet til at bruge dette godkendelsesniveau. Hvis du anvender Active Directory-klientudvidelser til Windows 95 eller Windows 98 og Windows NT 4.0, bruger klientudvidelserne de forbedrede godkendelsesfunktioner, der er tilgængelige i NTLMv2. Da klientcomputere, der kører et af følgende operativsystem, ikke påvirkes af Windows 2000 Gruppepolitik Objekter, skal du muligvis konfigurere disse klienter manuelt:

      • Microsoft Windows NT 4.0

      • Microsoft Windows Millennium Edition

      • Microsoft Windows 98

      • Microsoft Windows 95

      Bemærk! Hvis du aktiverer Netværkssikkerhed: Gem ikke LAN Manager-hash-værdien ved næste ændring af adgangskode , eller angiv noLMHash-registreringsdatabasenøglen , Windows 95-baserede og Windows 98-baserede klienter, der ikke har installeret Directory Services-klienten, kan ikke logge på domænet efter en ændring af adgangskoden.

      Mange CIFS-servere fra tredjepart, f.eks. Novell Netware 6, er ikke opmærksomme på NTLMv2 og bruger kun NTLM. Derfor tillader niveauer over 2 ikke forbindelse. Der er også SMB-tredjepartsklienter, der ikke bruger udvidet sessionssikkerhed. I disse tilfælde tages der ikke hensyn til LmCompatiblityLevel for ressourceserveren. Serveren pakker derefter denne ældre anmodning og sender den til brugerdomænecontrolleren. Indstillingerne på domænecontrolleren afgør derefter, hvilke hashes der bruges til at bekræfte anmodningen, og om disse opfylder domænecontrollerens sikkerhedskrav.

       

      299656 Sådan forhindrer du Windows i at gemme en LAN Manager-hash af din adgangskode i Active Directory og lokale SAM-databaser
       

      2701704Overvågningshændelsen viser godkendelsespakken som NTLMv1 i stedet for NTLMv2 Du kan få mere at vide om LM-godkendelsesniveauer ved at klikke på nedenstående artikelnummer for at få vist artiklen i Microsoft Knowledge Base:

      239869 Sådan aktiveres NTLM 2-godkendelse
       

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Ikke-begrænsende indstillinger, der sender adgangskoder i klartekst, og som afviser NTLMv2-forhandling

      • Restriktive indstillinger, der forhindrer inkompatible klienter eller domænecontrollere i at forhandle en fælles godkendelsesprotokol

      • Krav om NTLMv2-godkendelse på medlemscomputere og domænecontrollere, der kører versioner af Windows NT 4.0, der er tidligere end Service Pack 4 (SP4)

      • Kræver NTLMv2-godkendelse på Windows 95-klienter eller på Windows 98-klienter, hvor Windows Directory Services-klienten ikke er installeret.

      • Hvis du klikker for at markere afkrydsningsfeltet Kræv NTLMv2-sessionssikkerhed i Snap-in-programmet Microsoft Management Console Gruppepolitik Editor på en Windows Server 2003- eller Windows 2000 Service Pack 3-baseret computer, og du sænker LAN Manager-godkendelsesniveauet til 0, er de to indstillinger i konflikt, og du får muligvis vist følgende fejlmeddelelse i filen Secpol.msc eller gpEdit.msc-filen:

        Windows kan ikke åbne databasen for den lokale politik. Der opstod en ukendt fejl under forsøg på at åbne databasen.

        Du kan finde flere oplysninger om Security Configuration and Analysis Tool i Hjælp-filerne til Windows 2000 eller Windows Server 2003.

    3. Grunde til at ændre denne indstilling

      • Du vil øge den laveste fælles godkendelsesprotokol, der understøttes af klienter og domænecontrollere i organisationen.

      • Hvor sikker godkendelse er et forretningskrav, vil du ikke give adgang til forhandling af LM- og NTLM-protokollerne.

    4. Årsager til at deaktivere denne indstilling

      Krav til klient- eller servergodkendelse eller begge dele er blevet øget til det punkt, hvor godkendelse over en fælles protokol ikke kan forekomme.

    5. Symbolsk navn:

      Lmcompatibilitylevel

    6. Sti til registreringsdatabasen:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Eksempler på kompatibilitetsproblemer

      • Windows Server 2003: Indstillingen For Send NTLM-svar i Windows Server 2003 NTLMv2 er som standard aktiveret. Derfor modtager Windows Server 2003 fejlmeddelelsen "Adgang nægtet" efter den første installation, når du forsøger at oprette forbindelse til en Windows NT 4.0-baseret klynge eller til LanManager V2.1-baserede servere, f.eks. OS/2 Lanserver. Dette problem opstår også, hvis du forsøger at oprette forbindelse fra en tidligere version af klienten til en Windows Server 2003-baseret server.

      • Du installerer Windows 2000 Security Rollup Package 1 (SRP1). SRP1 gennemtvinger NTLM version 2 (NTLMv2). Denne opdateringspakke blev udgivet efter udgivelsen af Windows 2000 Service Pack 2 (SP2).
         

      • Windows 7 og Windows Server 2008 R2: Mange cifs-servere fra tredjeparter, f.eks Novell Netware 6 eller Linux-baserede Samba-servere, er ikke opmærksomme på NTLMv2 og bruger kun NTLM. Derfor tillader niveauer, der er større end "2", ikke forbindelse. I denne version af operativsystemet blev standarden for LmCompatibilityLevel ændret til "3". Så når du opgraderer Windows, kan disse filer fra tredjepart holde op med at fungere.

      • Microsoft Outlook-klienter kan blive bedt om at angive legitimationsoplysninger, selvom de allerede er logget på domænet. Når brugerne angiver deres legitimationsoplysninger, modtager de følgende fejlmeddelelse: Windows 7 og Windows Server 2008 R2

        De angivne logonoplysninger var forkerte. Sørg for, at dit brugernavn og domæne er korrekt, og skriv derefter din adgangskode igen.

        Når du starter Outlook, bliver du muligvis bedt om at angive dine legitimationsoplysninger, selvom indstillingen Logonnetværkssikkerhed er indstillet til Passthrough eller adgangskodegodkendelse. Når du har skrevet de korrekte legitimationsoplysninger, får du muligvis vist følgende fejlmeddelelse:

        De angivne logonoplysninger var forkerte.

        En netværksovervågningssporing kan vise, at det globale katalog har udstedt en RPC-fejl (Remote Procedure Call) med statussen 0x5. En status for 0x5 betyder "Adgang nægtet".

      • Windows 2000: Et netværksovervågningsklip kan vise følgende fejl i NetBIOS over TCP/IP(NetBT)-servermeddelelsesbloksessionen (SMB):

        SMB R-søgemappe Dos-fejl, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ugyldigt bruger-id

      • Windows 2000: Hvis et Windows 2000-domæne med NTLMv2 niveau 2 eller nyere er tillid til et Windows NT 4.0-domæne, kan Windows 2000-baserede medlemscomputere i ressourcedomænet opleve godkendelsesfejl.

      • Windows 2000 og Windows XP: Windows 2000 og Windows XP indstiller som standard indstillingen lokal sikkerhedspolitik på lan manager-godkendelsesniveau til 0. En indstilling på 0 betyder "Send LM- og NTLM-svar".

        Bemærk! Windows NT 4.0-baserede klynger skal bruge LM til administration.

      • Windows 2000: Windows 2000-klynger godkender ikke en joinnode, hvis begge noder er en del af et Windows NT 4.0 Service Pack 6a(SP6a)-domæne.

      • IIS Lockdown Tool (HiSecWeb) indstiller værdien LMCompatibilityLevel til 5 og Værdien RestrictAnonymous til 2.

      • Tjenester til Macintosh

        User Authentication Module (UAM): Microsoft UAM (User Authentication Module) indeholder en metode til at kryptere de adgangskoder, du bruger til at logge på Windows AFP-servere (AppleTalk Filing Protocol). Apple User Authentication Module (UAM) giver kun minimal eller ingen kryptering. Derfor kan din adgangskode nemt opsnappes på LAN eller på internettet. Selvom UAM ikke er påkrævet, giver den krypteret godkendelse til Windows 2000-servere, der kører Tjenester til Macintosh. Denne version indeholder understøttelse af NTLMv2 128-bit krypteret godkendelse og en MacOS X 10.1-kompatibel version.

        Som standard tillader Windows Server 2003 Services til Macintosh-serveren kun Microsoft-godkendelse.
         

      • Windows Server 2008, Windows Server 2003, Windows XP og Windows 2000: Hvis du konfigurerer værdien LMCompatibilityLevel til at være 0 eller 1 og derefter konfigurerer NoLMHash-værdien til at være 1, kan programmer og komponenter blive nægtet adgang via NTLM. Dette problem opstår, fordi computeren er konfigureret til at aktivere LM, men ikke til at bruge adgangskoder, der er gemt i LM.

        Hvis du konfigurerer NoLMHash-værdien til 1, skal du konfigurere værdien LMCompatibilityLevel til at være 2 eller højere.

  11. Netværkssikkerhed: Krav til signering af LDAP-klient

    1. Baggrund

      Indstillingen Netværkssikkerhed: LDAP-klientsigneringskrav bestemmer niveauet af den datasignering, der anmodes om på vegne af klienter, der udsteder LDAP BIND-anmodninger (Lightweight Directory Access Protocol) på følgende måde:

      • Ingen: LDAP BIND-anmodningen udstedes med de indstillinger, der er angivet af den person, der ringer op.

      • Forhandle signering: Hvis SSL/TLS (Secure Sockets Layer/Transport Layer Security) ikke er blevet startet, startes LDAP BIND-anmodningen med LDAP-datasigneringsindstillingen, der er angivet ud over de opkalderspecifikke indstillinger. Hvis SSL/TLS er blevet startet, startes LDAP BIND-anmodningen med de opkalderspecifikke indstillinger.

      • Kræv signering: Dette er det samme som Forhandl signering. Men hvis LDAP-serverens mellemliggende saslBindInProgress-svar ikke angiver, at LDAP-trafiksignering er påkrævet, får den opkaldende besked om, at LDAP BIND-kommandoanmodningen mislykkedes.

    2. Risikabel konfiguration

      Aktivering af indstillingen Netværkssikkerhed: Krav til LDAP-klientsignering er en skadelig konfigurationsindstilling. Hvis du indstiller serveren til at kræve LDAP-signaturer, skal du også konfigurere LDAP-signering på klienten. Hvis klienten ikke konfigureres til at bruge LDAP-signaturer, forhindres kommunikation med serveren. Dette medfører, at brugergodkendelse, Gruppepolitik indstillinger, logonscripts og andre funktioner mislykkes.

    3. Grunde til at ændre denne indstilling

      Usigneret netværkstrafik er modtagelig for man-in-the-middle-angreb, hvor en ubuden gæst registrerer pakker mellem klienten og serverne, ændrer dem og videresender dem derefter til serveren. Når dette sker på en LDAP-server, kan en hacker få en server til at svare baseret på falske forespørgsler fra LDAP-klienten. Du kan reducere denne risiko i et virksomhedsnetværk ved at implementere stærke fysiske sikkerhedsforanstaltninger for at beskytte netværksinfrastrukturen. Desuden kan du være med til at forhindre alle typer angreb mellem mand og mellem ved at kræve digitale signaturer på alle netværkspakker ved hjælp af IPSec-godkendelsesheadere.

    4. Symbolsk navn:

      LDAPClientIntegrity

    5. Sti til registreringsdatabasen:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

  12. Hændelseslog: Maksimal størrelse på sikkerhedsloggen

    1. Baggrund

      Hændelsesloggen: Den maksimale sikkerhedslogstørrelse angiver den maksimale størrelse af sikkerhedshændelsesloggen. Denne log har en maksimumstørrelse på 4 GB. Du kan finde denne indstilling ved at udvide
      Windows-indstillinger og derefter udvide Sikkerhedsindstillinger.

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Begrænsning af størrelsen på sikkerhedsloggen og opbevaringsmetoden for sikkerhedsloggen, når indstillingen Overvågning: Luk systemet med det samme, hvis indstillingen sikkerhedsovervågning ikke kan logføres er aktiveret. Se afsnittet "Overvågning: Luk systemet med det samme, hvis det ikke er muligt at logføre sikkerhedsovervågninger" i denne artikel for at få flere oplysninger.

      • Begrænsning af størrelsen på sikkerhedsloggen, så interessante sikkerhedshændelser overskrives.

    3. Årsager til at øge denne indstilling

      Forretnings- og sikkerhedskrav kan diktere, at du øger størrelsen på sikkerhedsloggen for at håndtere yderligere oplysninger om sikkerhedsloggen eller for at bevare sikkerhedslogfiler i længere tid.

    4. Årsager til at mindske denne indstilling

      Logbog logfiler er hukommelsestilknyttet filer. Den maksimale størrelse for en hændelseslog er begrænset af mængden af fysisk hukommelse på den lokale computer og af den virtuelle hukommelse, der er tilgængelig for hændelseslogprocessen. Hvis du øger logstørrelsen ud over mængden af virtuel hukommelse, der er tilgængelig for Logbog, øges antallet af logposter, der bevares.

    5. Eksempler på kompatibilitetsproblemer

      Windows 2000: Computere, der kører versioner af Windows 2000, som er tidligere end Service Pack 4 (SP4), kan stoppe logføring af hændelser i hændelsesloggen, før den når den størrelse, der er angivet i indstillingen Maksimal logstørrelse i Logbog, hvis indstillingen Overskriv ikke hændelser (ryd log manuelt) er slået til.


       

  13. Hændelseslog: Bevar sikkerhedsloggen

    1. Baggrund

      Hændelsesloggen: Sikkerhedsindstillingen Bevar sikkerhedsloggen bestemmer "ombrydningsmetoden" for sikkerhedsloggen. Du kan finde denne indstilling ved at udvide Windows-indstillinger og derefter udvide Sikkerhedsindstillinger.

    2. Risikable konfigurationer

      Følgende er skadelige konfigurationsindstillinger:

      • Hvis alle logførte sikkerhedshændelser ikke bevares, før de overskrives

      • Konfiguration af indstillingen Maksimal størrelse på sikkerhedslogfil for lille, så sikkerhedshændelser overskrives

      • Begrænsning af størrelse og opbevaringsmetode for sikkerhedsloggen under Overvågning: Luk systemet med det samme, hvis sikkerhedsindstillingen Sikkerhedsovervågning ikke kan logføres er aktiveret

    3. Årsager til at aktivere denne indstilling

      Aktivér kun denne indstilling, hvis du vælger opbevaringsmetoden Overskriv begivenheder efter dage . Hvis du bruger et hændelseskorrelationssystem, der forespørger om hændelser, skal du kontrollere, at antallet af dage er mindst tre gange afstemningsfrekvensen. Gør dette for at tillade mislykkede afstemningscyklusser.

  14. Netværksadgang: Lad alle-tilladelser gælde for anonyme brugere

    1. Baggrund

      Som standard er indstillingen Netværksadgang: Lad alle-tilladelser gælde for anonyme brugere indstillet til Ikke defineret på Windows Server 2003. Windows Server 2003 inkluderer som standard ikke tokenet Anonym adgang i gruppen Alle.

    2. Eksempel på kompatibilitetsproblemer

      Følgende værdi af

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 bryder tillidsoprettelsen mellem Windows Server 2003 og Windows NT 4.0, når Windows Server 2003-domænet er kontodomænet, og Windows NT 4.0-domænet er ressourcedomænet. Det betyder, at der er tillid til kontodomænet på Windows NT 4.0, og at ressourcedomænet har tillid til på Windows Server 2003-siden. Dette problem opstår, fordi processen til at starte tillidsforholdet, når den indledende anonyme forbindelse er ACL'd med alle-tokenet, der omfatter anonymt SID i Windows NT 4.0.

    3. Grunde til at ændre denne indstilling

      Værdien skal indstilles til 0x1 eller indstilles ved hjælp af et gruppepolitikobjekt på domænecontrollerens OU for at være: Netværksadgang: Lad alle-tilladelser gælde for anonyme brugere – Aktiveret for at gøre det muligt at oprette tillid.

      Bemærk! De fleste andre sikkerhedsindstillinger går op i værdi i stedet for ned til 0x0 i deres mest sikrede tilstand. En mere sikker fremgangsmåde ville være at ændre registreringsdatabasen på den primære domænecontrolleremulator i stedet for på alle domænecontrollere. Hvis emulatorrollen for den primære domænecontroller flyttes af en eller anden grund, skal registreringsdatabasen opdateres på den nye server.

      Der kræves en genstart, når denne værdi er angivet.

    4. Sti til registreringsdatabase

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

  15. NTLMv2-godkendelse

    1. Sessionssikkerhed

      Sessionssikkerhed bestemmer minimumsstandarderne for klient- og serversessioner. Det er en god ide at kontrollere følgende indstillinger for sikkerhedspolitik i snap-in'en Microsoft Management Console Gruppepolitik Editor:

      • Computerindstillinger\Windows-indstillinger\Sikkerhedsindstillinger\Lokale politikker\Sikkerhedsindstillinger

      • Netværkssikkerhed: Minimum sessionssikkerhed for NTLM SSP-baserede (herunder sikre RPC)-servere

      • Netværkssikkerhed: Minimum sessionssikkerhed for NTLM SSP-baserede (herunder sikre RPC)-klienter

      Indstillingerne for disse indstillinger er som følger:

      • Kræv meddelelsesintegritet

      • Kræv meddelelseshemmelighed

      • Kræv NTLM version 2-sessionssikkerhed

      • Kræv 128-bit kryptering

      Standardindstillingen før Windows 7 er Ingen krav. Fra og med Windows 7 er standarden ændret til Kræv 128-bit kryptering for at opnå forbedret sikkerhed. Med denne standard kan ældre enheder, der ikke understøtter 128-bit kryptering, ikke oprette forbindelse.

      Disse politikker bestemmer minimumsstandarderne for sikkerhed for en program til program-kommunikationssession på en server for en klient.

      Bemærk, at selvom de beskrives som gyldige indstillinger, bruges flagene til at kræve meddelelsesintegritet og fortrolighed ikke, når NTLM-sessionssikkerheden bestemmes.

      Historisk set har Windows NT understøttet følgende to varianter af challenge/response-godkendelse for netværkslogon:

      • LM-udfordring/svar

      • NTLM version 1 challenge/response

      LM giver mulighed for interoperabilitet med den installerede base af klienter og servere. NTLM giver forbedret sikkerhed for forbindelser mellem klienter og servere.

      De tilsvarende registreringsdatabasenøgler er følgende:

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

    2. Risikable konfigurationer

      Denne indstilling styrer, hvordan netværkssessioner, der er sikret ved hjælp af NTLM, håndteres. Dette påvirker f.eks. RPC-baserede sessioner, der er godkendt med NTLM. Der er følgende risici:

      • Hvis du bruger ældre godkendelsesmetoder end NTLMv2, bliver kommunikationen nemmere at angribe på grund af de enklere anvendte hashingmetoder.

      • Hvis du bruger krypteringsnøgler, der er lavere end 128-bit, kan hackere bryde kommunikationen ved hjælp af angreb med brute-force.

Tidssynkronisering

Tidssynkronisering mislykkedes. Tiden er slukket med mere end 30 minutter på en berørt computer. Sørg for, at klientcomputerens ur er synkroniseret med domænecontrollerens ur.

Løsning til SMB-signering

Vi anbefaler, at du installerer Service Pack 6a (SP6a) på Windows NT 4.0-klienter, der fungerer sammen i et Windows Server 2003-baseret domæne. Windows 98 Second Edition-baserede klienter, Windows 98-baserede klienter og Windows 95-baserede klienter skal køre Directory Services-klienten for at udføre NTLMv2. Hvis Windows NT 4.0-baserede klienter ikke har Windows NT 4.0 SP6 installeret, eller hvis Windows 95-baserede klienter, Windows 98-baserede klienter og Windows 98SE-baserede klienter ikke har directory services-klienten installeret, skal du deaktivere SMB-signering i standarddomænecontrollerens politikindstilling på domænecontrollerens OU og derefter sammenkæde denne politik med alle OU'er, der hoster domænecontrollere.

Directory Services-klienten til Windows 98 Second Edition, Windows 98 og Windows 95 udfører SMB-signering med Windows 2003-servere under NTLM-godkendelse, men ikke under NTLMv2-godkendelse. Desuden reagerer Windows 2000-servere ikke på SMB-signeringsanmodninger fra disse klienter.

Selvom vi ikke anbefaler det, kan du forhindre, at der kræves SMB-signering på alle domænecontrollere, der kører Windows Server 2003 på et domæne. Følg disse trin for at konfigurere denne sikkerhedsindstilling:

  1. Åbn standarddomænecontrollerens politik.

  2. Åbn mappen Computerkonfiguration\Windows-indstillinger\Sikkerhedsindstillinger\Lokale politikker\Sikkerhedsindstillinger.

  3. Find og klik derefter på politikindstillingen Microsoft-netværksserver: Signer kommunikation digitalt (altid), og klik derefter på Deaktiveret.

Vigtigt! Dette afsnit, metode eller opgave indeholder trin, der fortæller dig, hvordan du redigerer registreringsdatabasen. Der kan dog opstå alvorlige problemer, hvis du redigerer registreringsdatabasen forkert. Derfor skal du sørge for at følge disse trin omhyggeligt. Du kan få ekstra beskyttelse ved at sikkerhedskopiere registreringsdatabasen, før du redigerer den. Derefter kan du gendanne registreringsdatabasen, hvis der opstår et problem. Flere oplysninger om, hvordan du sikkerhedskopier og gendanner registreringsdatabasen, finder du ved at klikke på nedenstående artikelnummer for at få vist artiklen i Microsoft Knowledge Base:

322756 Sådan sikkerhedskopieres og gendannes registreringsdatabasen i Windows Du kan også slå SMB-signering fra på serveren ved at ændre registreringsdatabasen. Det kan du gøre, ved at følge disse trin:

  1. Klik på Start, klik på Kør, skriv regedit, og klik derefter på OK.

  2. Find og klik derefter på følgende undernøgle:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

  3. Klik på posten enablesecuritysignature .

  4. Klik på Rediger i menuen Rediger.

  5. Skriv 0 i feltet Værdidata , og klik derefter på OK.

  6. Afslut Registreringseditor.

  7. Genstart computeren, eller stop, og genstart derefter servertjenesten. Det gør du ved at skrive følgende kommandoer ved en kommandoprompt og derefter trykke på Enter, når du har skrevet hver kommando:
    net stop server
    net start server

Bemærk! Den tilsvarende nøgle på klientcomputeren findes i følgende undernøgle i registreringsdatabasen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Følgende viser de oversatte fejlkodenumre til statuskoder og til de direkte fejlmeddelelser, der er nævnt tidligere:

fejl 5


ERROR_ACCESS_DENIED Adgang nægtet.

fejl 1326



ERROR_LOGON_FAILURE Logonfejl: Ukendt brugernavn eller forkert adgangskode.

fejl 1788



ERROR_TRUSTED_DOMAIN_FAILURE Tillidsforholdet mellem det primære domæne og det domæne, der er tillid til, mislykkedes.

fejl 1789



ERROR_TRUSTED_RELATIONSHIP_FAILURE Tillidsforholdet mellem denne arbejdsstation og det primære domæne mislykkedes.

Du kan få mere at vide ved at klikke på nedenstående artikelnumre for at få vist artiklerne i Microsoft Knowledge Base:

324802 Sådan konfigureres gruppepolitikker til at angive sikkerhed for systemtjenester i Windows Server 2003

816585 Sådan anvendes foruddefinerede sikkerhedsskabeloner i Windows Server 2003

Har du brug for mere hjælp?

Vil du have flere indstillinger?

Udforsk abonnementsfordele, gennemse kurser, få mere at vide om, hvordan du sikrer din enhed og meget mere.

Communities hjælper dig med at stille og besvare spørgsmål, give feedback og høre fra eksperter med omfattende viden.

Var disse oplysninger nyttige?

Hvor tilfreds er du med kvaliteten af sproget?
Hvad påvirkede din oplevelse?
Når du trykker på Send, bliver din feedback brugt til at forbedre Microsoft-produkter og -tjenester. Din it-administrator kan indsamle disse data. Erklæring om beskyttelse af personlige oplysninger.

Tak for din feedback!

×