Kolla MS patchar powershell.

Script för att kolla
https://gallery.technet.microsoft.com/scriptcenter/PowerShell-script-to-list-0955fe87

Get-MSHotfix|Where-Object {$_.Installedon -gt ((Get-Date).Adddays(-2))}|Select-Object -Property Computername, KBArticle,InstalledOn, HotFixID, InstalledBy|Format-Table

Get-MSHotfix|Where-Object {$_.HotfixID -match "KB2953522"}

Get-MSHotfix|Where-Object {$_.HotfixID -match "KB2953522"}|ForEach-Object {[System.Diagnostics.Process]::Start($_.KBArticle)}

Advertisements

Schedule task error 2147746321 EventID 202

När man lägger upp ett schedule task för att skicka mail så kan man få Event ID 202 med error 2147746321. Detta beror oftast på 2 saker:
E-postadressen för kontot som kör jobbet stämmer inte överens med den e-postadress som är satt som send adress.
Servern som tar emot mailet kräver inte autentisering.

Lägga till Crl till publishing CA

Om man får nedanstående i loggen på en CA server så kan det bero på att Crl listan för Root CA saknas eller inte är uppdaterad. Tjänsten kommer inte heller att starta.

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          2011-01-17 13:05:44
Event ID:      100
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      nisse
Description:
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate.  XXX issuing CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).
För att lösa problemet kan man använda Certutil och läsa in Crl listan till local root.

  1. Skapa en katalog på den icke fungerande CA:n och kopiera ner Crl och eventuella delta Crl listor till den mappen.
  2. Skapa en batfil med nedanstående kommando:
    for %% in C*.crl) do certutil -addstore -f Root “%%c”
  3. Kör batfilen.
  4. Efter det så kan du starta Certifikattjänsten.

Observera att efter du startat tjänsten så bör du reda ut varför dom vanliga publiseringsvägarna för Crl inte fungerar och eventuellt konfigurera om din CA så att den publiserar rätt sökvägar.

DNS Sec i Windows 2008 R2 och Windows 7

I Windows 2008 R2 finns stöd för DNS sec. Stödet är dock begränsat till enbart statiska zoner. Det finns inte heller något stöd för att signera zoner via grafiskt gränssnitt utan det sker via Dnscmd. Om du gör en ändring i zonen så måste du signera om zonen och ladda om den. Vid signering av zoner kan man välja att använda flera nycklar för att underlätta key rollover.

Vad som inte är supporterat

Nedanstående är inte supporterat

  • Signering av GlobalNames zone och Wins forwarding.
  • NSEC3 signerade zoner.
  • Dynamiska uppdateringar.

Generera nycklar

KSK

  1. Öppna ett cmdfönster.
  2. För att skapa en 2048 bitars nyckel för zonen test.lab som är giltig till 20110107 skriv:

    dnscmd /offlinesign /genkey /alg rsasha1 /flags KSK /length 2048 /zone test.lab /Sscert /friendlyname KSK-test.lab /validto 20110107000000″
  3. Du kan verifiera att nyckeln skapats genom att titta i certifikathanteraren under MS-DNSSEC.

 

ZSK

  1. Öppna ett cmdfönster.
  2. För att skapa en 1024 bitars nyckel för zonen test.lab som är giltig till 20110106 skriv:
    “dnscmd /offlinesign /genkey /alg rsasha1 /length 1024 /zone test.lab /sscert /friendlyname zsk_1-test.lab /validto 20110106000000”
  3. Även här kan du verifiera att nyckeln skapats genom att använda certifikathanteraren enligt ovan.

Tänk på

Enbart RSA/SHA-1 är supporterat i dagsläget. Om inte validto anges så är nyckeln giltig i 5 år. Efter att nyckelparen är skapade så bör man ta backup på dom privata nycklarna. Detta görs på samma sätt som när man tar backup på ett vanligt certifikat. Nycklarna bör sedan förvaras på ett säkert ställe.

Enligt Microsoft så kan en DNS server behöva tre till fem gånger så mycket minne för att ladda en signerad zon jämfört med att ladda en osignerad zon.

Signera en zon

  1. Ta backup på den osignerade zonen. Den finns under ..\system32\DNS. Om det är en AD integrerad zon måste man exportera den med dnscmd /zoneexport.
  2. Öppna ett eleverat cmdfönster. Bläddra till ..\system32\dns.
  3. För att signera zonfilen för test.lab med dom nycklar som skapats ovan skriv:
    dnscmd /offlinesign /signzone /input test.lab.dns /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110106235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_1-test.lab
  4. Observera att när kommandot körts så har det skapats 2 st filer med namnet keyset <zonenamn> och dsset<zonenamn> dessa filer innehåller TrustAnchors och DS record för zonen.

Reload zone

När zonerna är signerade så måste man ta bort den gamla zonfilen och ladda om zonen med den signerade zonfilen. Det gör du med följande kommandon:
dnscmd /zonedelete test.lab /f (tar bort befintlig osignerad zon)
dnscmd /zoneadd test.lab /primary /file test.lab.dns.signed1 /load
(laddar den signerade zonen)
Din dnsserver har nu laddat den signerade zonen för att verifiera detta kan du öppna DNS hanteraren.
Om du använder en AD integrerad zon anger du typ dsprimary istället.

Ej signerad zon.


Samma zon signerad.

Larm – Loggning

Om zonens giltighet börjar gå ut så loggas detta i loggboken för DNS servern (Event ID 1525) enligt nedan:

Om zonens giltighet har gått ut loggas detta i loggboken för DNS servern (Event ID 1524) enligt nedan:

Omsignering av zon.

Omsignering av zon behöver bl.a. göras när:

  • Data i zonen förändrats.
  • En subdomän har blivit signerad. Då måste DS record från subdomänen läggas till i huvudzonen.
  • Giltighetstiden gått ut.
  • Nyckeln blivit röjd, men då behöver även nya nycklar genereras.

Vid omsignering av zonen så kan input och output vara samma. Tänk på att om zonen signeras om beroende på att nyckeln har gått ut så behöver man uppdatera SOA record manuellt.

Test av records

För att testa så att records i zonen fungerar kan vi använda Check DNSSEC Signature från simple DNS Plus.

Test av fungerande record

Test av felaktigt ej signerat record.

Key rollover

Windows 2008 R2 stödjer 2 st metoder för Key rollover. Key Pre-publication rollover och Double signature rollover.

Pre-published rollover

Vid Key Pre-publication så används 2 st ZSK. En för att signera data, den andra publiceras även om den inte har används för att generera några signaturer. Exempel:

  1. Zonen har signerats med en KSK och en ZSK enligt ovan. Vi behöver nu generera en ny ZSK, detta görs med samma kommando som ovan. Lägg till den nya nyckeln till zonen med:

dnscmd /offlinesign /signzone /input test.lab.dns.signed1 /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110120235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_1-test.lab /addkey /cert /friendlyname zsk_2-test.lab

Det är den sista delen av kommandot som lägger till den nya nyckeln. Om man nu tittar i zonfilen så finns det 3 stycken nycklar angivna, en KSK (257)och två stycken ZSK (256). Dock så har bara den ursprungliga ZSK nyckeln används för att signering.

Bilden ovan visar att trots att det finns två st ZSK nycklar så har bara den ena (22008) används för signering.

  1. Vänta nu tills TTL värdet för zonen har passerats.
  2. Efter att TTL värdet har passerats så behöver zonen signeras om med den nya nyckeln. Den gamla nyckeln är kvar som DSKEY men utan att användas för signering. Enligt nedan:

dnscmd /offlinesign /signzone /input test.lab.dns.signed1 /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110130235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_2-test.lab /addkey /cert /friendlyname zsk_1-test.lab

Bilden visar zonen efter att den nya nyckeln används för signering. Observera att den gamla nyckeln fortfarande är kvar i zonen.

  1. Vänta tills TTL värdet för zonen har passerats igen.
  2. Du kan nu signera om zonen med enbart den nya nyckeln. Enligt nedan:

dnscmd /offlinesign /signzone /input test.lab.dns.signed1 /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110228235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_2-test.lab

Enbart den nya nyckeln används.

Double Signature Rollover

Vid Double Signature Rollover så används båda nycklarna till att signera zonen samtidigt. Detta gör att det går snabbare att genomföra nyckelbyte men det medför att zonen blir dubbelt så stor eftersom alla records signeras två gånger.

  1. Zonen har signerats med en KSK och en ZSK vi behöver nu generera en ny ZSK det görs med samma kommando som tidigare. När nyckeln är genererad så används den direkt för att signera zonen tillsammans med den gamla nyckeln:

dnscmd /offlinesign /signzone /input test.lab.dns.signed1 /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110228235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_2-test.lab /signkey /validto 20110310235900 /cert /friendlyname zsk_4-test.lab

Efter att zonen är signerad med båda nycklarna så har antalet records fördubblats.

  1. Vänta tills TTL värdet för zonen passerats.
  2. Signera om zonen med enbart KSK och den nya ZSK.

dnscmd /offlinesign /signzone /input test.lab.dns.signed1 /output test.lab.dns.signed1 /zone test.lab /signkey /validto 20110228235900 /cert /friendlyname ksk-test.lab /signkey /cert /friendlyname zsk_2-test.lab /signkey /validto 20110310235900 /cert /friendlyname zsk_4-test.lab

Nyckelbyte klart och bara den nya nyckeln används.

Konfigurering av Trust Anchors

Trust Anchors kan konfigureras antingen via det grafiska gränssnittet eller via Dnscmd. Om dnsservern är en domänkontrollant så sparas Trust Anchors i forest partitionen och replikeras till alla DC i foresten. På standalone DNS servrar så sparas informationen i filen TrustAnchors.dns i ..\system32\DNS.

I dagsläget så stöds bara RSA/SHA-1, exempelvis .SE. Zoner som är signerade med RSA/SHA-256 exempelvis root är inte supporterade.

För att se vilken algoritm som används så kan man använda DIG. Om vi frågar: “dig @193.0.14.129 . dnskey” så kan vi se att i början av recordet så står det “DNSKEY 256 3 8 AwEAAb5gV…”. Denna algoritm kan Windows för närvarande inte använda.
Om vi istället frågar en av namnservrarna för .SE med “dig @192.36.144.107 se. dnskey” så står det “DNSKEY 257 3 5 AwEAAeeGE5u…” Denna algoritm kan vi använda.

För att använda .se zonens publika nyckel som Trust Anchor så kan man ladda ner nyckel från http://www.iis.se/domaner/dnssec/publika-nycklar-for-dnssec. När man har laddat ner den så går man in i DNS hanteraren och högerklickar på DNS servern, väljer egenskaper, fliken Trust Anchors. Klicka på Add. Lägg sedan till den publika nyckeln. Kryssa i att det ska vara en Secure Entry Point. Protocol och Algoritm kan vi i dagsläget inte ändra.

Om vi nu tittar i filen TrustAnchors.dns så ser vi att se ligger med i den filen.

För att lägga upp ett TrustAnchor från en Windowssignerad zon så använder vi filen keyset-<domännamn> som ligger i dnskatalogen istället.

För att göra det via CMD så skriver man dnscmd /trustanchoradd se DNSKEY 257 3 5 “AwE….” istället.

Secure EnryPoint

Hur vet man om man ska kryssa i Secure EntryPoint eller inte? Det kan man se på siffrorna efter DNSKEY exempelvis 257 3 5.

257 Visar att det är en zone signing key och en secure entry point. Om det stått 256 istället så hade det bara varit en zone signing key. Siffran 3 visar att det är DNSSEC protokollet och 5 visar att krypteringen är RSA-SHA1 och NSEC.

DNS klient Windows 7 och Windows 2008 R2

I Windows 7 och Windows 2008 R2 så används Name Resolution Policy Table (NRPT) för att styra hur namnupplösning för olika zoner ska göras. Du kan jobba med NRTP antingen via grupppolicy eller direct via registret. För att jobba via grupppolicy gå till Windows Settings /Name Resolution Policy. För att lägga till SE så kryssar man i enligt nedan.

Efter det så måste man köra gpupdate /force och starta om dnsclienten kan göras med:

gpupdate /force & net stop dnscache & net start dnscache

För att kontrollera statusen så kan man använda: netsh namespace show alt. netsh nam sho eff.

DNSSEC inställningar för .se

Observera att man inte kan använda nslookup för att testa utan man kan testa med ping istället.

Ping hittar inte hosten iis.se eftersom DNSSEC krävs och Trust Anchor för SE inte är installerat på mellanliggande DNS server.


Med Trust Anchor installerat så hittar även ping hosten.

Felsökning

Förutom att kontrollera så att mellanliggande DNS servrar har Trust Anchor installerat för zonen som man kräver DNSSEC mot så kan det även vara problem med vissa DNS servrar, Routrar och Brandväggar. En artikel som beskriver hur man använder DIG för att testa detta finns här. I stället för att använda DIG kan man använda nslookup enligt nedan:

nslookup -type=txt rs.dns-oarc.net. 192.168.1.254

Där du ersätter “192.168.1.254” med ipadressen till din DNS server. Om det fungerar bör svaret vara ungefär:

Det viktiga här är att reply size är runt 4000 eller mer. Nedan visas ett exempel från en router\brandvägg som förmodligen filtrerar IP fragment.

Observera att reply size är betydligt mindre.

Powershell

Microsoft har gett ut 2 st Powershell script för att hantera DNSSEC SignZone.ps1 och TrustAnchor.ps1 dessa underlättar hanteringen av DNSSEC.

SignZone.ps1

SignZone.ps1 kan användas för att signera eller göra rollover för en zon. Rollovermetoder som stödjs är pre-published ZSK, double signature ZSK och double signature KSK.

Signera zon

För att signera en zon så skriver man signzone.ps1 –action sign –zone <zone>.

Scriptet sparar undan orginalfilen som signzone-<zon>-backup och skapar nya KSK och ZSK automatiskt. Livslängden på nycklarna är 5 år.

Omsignering av zon

För att signera om en zon så skriver man signzone.ps1 –action resign –zone <zone> -ksk <friendlyname KSK> -zsk <friendlyname ZSK>. Tänk på att du måste ta bort befintlig backupfil innan du signerar om zonen.

Pre-published ZSK rollover

För att genomföra pre-published ZSK rollover så skriver man signzone.ps1 –action prezsk –zone <zone> -ksk <friendlyname KSK> -zsk <friendlyname ZSK>.

Scriptet räknar ut hur lång tid det kommer att ta (baserat på aktuellt TTL värde) och genererar en ny ZSK och därefter genomförs rollover automatiskt.

Double signature ZSK rollover

Double signature ZSK fungerar på samma sätt men kommandot är signzone.ps1 –action doublezsk –zone <zone> -ksk <friendlyname KSK> -zsk <friendlyname ZSK>.

Double signature KSK

Signzone.ps1 stödjer även KSK rollover med Double signature. Kommandot för detta är signzone.ps1 –action doubleksk –zone <zone> -ksk <friendlyname KSK> -zsk <friendlyname ZSK> -ttl <ttl värde i ovanliggande ZON>. När man gör en KSK rollover så måste även byta ut DS record i ovanliggande zon. När man kör skriptet så informerar skriptet om detta.

Här måste man alltså se till att byta ut befintligt DS record mot det nya.

Klart.

TrustAnchor.ps1

TrustAnchor.ps1 kan användas för att lägga till, uppdatera och verifiera TrustAnchor.

För att lägga till skriver man trustanchor.ps1 –action add –zone <zone> -keyset <keysetfil>

För att uppdatera skriver man trustanchor.ps1 –action roll –zone <zone>

För att verifiera skriver man trustanchor.ps1 –action verify –zone <zone>

Sammanfattning

Microsoft har infört utökat stöd för DNSSEC i Windows 2008 R2, tidigare versioner kunde vara sekundära DNS servrar för zoner som använde DNSSEC. I Windows 2008 R2 så kan man DNS servern vara primär för en zon och man kan signera zoner. Det saknas dock fortfarande stöd för vissa algoritmer, dynamiska uppdateringar och ett grafiskt gränssnitt. Att införa DNSSEC på AD integrerade zoner kommer att medföra ett väsentligt merarbete eftersom man kommer att behöva uppdatera zonerna manuellt. Detta känns inte aktuellt.

För organisationer som har ett litet antal zoner som inte uppdateras så ofta och som idag kör Windows 2008 R2 för sina externa zoner kan detta vara ett alternativ. Då rekommenderas att använda de powershell script som finns som grund och kanske utveckla egna interna script för att underlätta bl.a backup. Innan man kör igång bör man tänka igenom hur hantering av nycklar ska ske, nycklarnas livslängd och vilken rollover mekanism man vill använda. Man bör även kontakta sin registrar för att säkerställa så att dom stödjer DNSSEC.

Länkar

Lista på vilka algoritmer som används: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.

.SE information om DNSSEC: http://www.iis.se/domaner/dnssec

Microsoft DNSSEC deployment guide och powershellscript: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=7a005a14-f740-4689-8c43-9952b5c3d36f

Sida som visar DNSSEC status för Sveriges kommuner: http://www.kommunermeddnssec.se/

Sida där man kan kontrollera DNSSEC status för en zon: http://dnsviz.net/