Category Archives

6 Articles

Certificate Services/tips&triks

Backup av Active Directory Certificate Services

Posted by ragnar harper on

Det er utbredt forståelse at backup av Active Directory Certificate Services installasjoner oppnås med backup av System state.

Dette er ikke riktig – en System state backup mangler sertifikatserverens private nøkkel!

Denne er du avhengig av, og du må sørge for backup av denne gjennom certutil –backup

Nøkkelen ligger lagret under "%systemdrive\ProgramData\Microsoft\Crypto\Keys" og om du kjører en system state restore vil denne mappa være tom!
Om du vil kjøre System state backup og være istand til å restore Active Directory Certificate Services – kjør certutil –backup også.

Certificate Services/Powershell

Hvordan liste ut sertifikater som utløper snart?

Posted by ragnar harper on

Etter å ha bistått i flere PKI implentasjoner på Microsoft plattform er det ett spørsmål som går igjen:

Hvordan liste ut sertifikater som utløper i nærmeste fremtid?

Dette kan man gjøre med certutil.exe kommandoen, men i disse Powershell tider har jeg laget et Powershell script som benytter certutil – men som formaterer sertifikatetene som objekter. Dette gjør at det er mye enklere å jobbe videre med sertifikatene. Merk at scriptet må kjøres på CA serveren.

Eksempel:

Get-ExpiringCertificates.ps1
Standard lister ut alle sertifikater som utløper iløpet av 180 dager

Get-ExpiringCertificates.ps1 -InNumberOfDays 30
Dette vil liste ut de sertifikatene som utløper i løpet av 30 dager

Get-ExpiringCertificates.ps1 -InNumberOfDays 30 -ExcludeAutoEnroll
Dette vil liste ut de sertifikatene som utløper i løpet av 30 dager, untatt de som er satt til  åfornye seg automatisk.

Du kan laste ned scriptet herfra http://blog.crayon.no/files/folders/scripts/entry13037.aspx

Source:

# ==============================================================================================
#
# NAME: Get-ExpiringCertificates.ps1
#
# AUTHOR: Ragnar Harper
# DATE  : 18.04.2009
#
# COMMENT: List out expiring certificates. Needs to be run on the Certificate Authority.
#            Takes two parameters:
#            InNumberOfdays
#                           If not given, defaults to 180 days from today. This is the number
#                           of days to check for expiring certificates
#             ExcludeAutoEnroll
#                           Excludes certificates that autoenroll from the list
#
# USAGE:
#    .\Get-ExpiringCertificates.ps1
#    .\Get-ExpiringCertificates.ps1 -InNumberOfDays 30
#    .\Get-ExpiringCertificates.ps1 -InNumberOfDays 30 -ExcludeAutoEnroll
# ==============================================================================================
param(
[int]$InNumberOfDays=180,
[switch]$ExcludeAutoEnroll)
function WriteCertInfo($cert)
{
#just a lot of code to get the fields into an object
$certObj = "" | Select RequesterName,RequestType,ExpirationDate,CommonName,EnrollmentFlags
$RequesterName=$cert -match "Requester Name:.*Request Type:"
$startLength="Requester Name:".Length
$lineLength=$matches[0].Length -("Request Type:".Length + $startLength)
$OutRequesterName=$matches[0].SubString($startLength,$lineLength)
$certObj.RequesterName=$OutRequesterName
$RequestType=$cert -match "Request Type:.*Certificate Expiration Date:"
$startLength="Request Type:".Length
$lineLength=$matches[0].Length - ("Certificate Expiration Date:".Length + $startLength)
$OutRequestType=$matches[0].SubString($startLength,$lineLength)
$certObj.RequestType=$OutRequestType
$ExpirationDate = $cert -match "Certificate Expiration Date:.*Issued Common Name:"
$startLength="Certificate Expiration Date:".Length
$lineLength=$matches[0].Length - ("Issued Common Name:".Length + $startLength)
$OutExpirationDate=$matches[0].SubString($startLength,$lineLength)
$certObj.ExpirationDate=$OutExpirationDate
$IssuedCommonName= $cert -match "Issued Common Name:.*Template Enrollment Flags:"
$startLength="Issued Common Name:".Length
$lineLength=$matches[0].Length - ("Template Enrollment Flags:".Length + $startLength)
$OutCommonName=$matches[0].SubString($startLength,$lineLength)
$certObj.CommonName=$OutCommonName
$EnrollmentFlags= $cert -match "Template Enrollment Flags:.*"
$startLength="Template Enrollment Flags:".Length
$lineLength=$matches[0].Length - ($startLength)
$OutEnrollmentFlags=$matches[0].SubString($startLength,$lineLength)
$certObj.EnrollmentFlags=$OutEnrollmentFlags
if($ExcludeAutoEnroll)
{
if(($OutEnrollmentFlags -match "CT_FLAG_AUTO_ENROLLMENT") -eq $false)
{
$script:CertToList+=$certObj
}
}
else
{
$script:CertToList+=$certObj
}
}
$CertToList=@()
$today=Get-Date
$endperiod=$today.AddDays($InNumberOfDays)
#List certificates that expire within 180 days from now
$tester=certutil -view -restrict "NotAfter>=$today,NotAfter<=$endperiod" -out "RequestID,RequesterName,RequestType,NotAfter,CommonName,EnrollmentFlags"
$arr=$tester -match "Row \d*:"
$numberOfCerts=$arr.length
$line=[string]::join(" ",$tester)
for($certNo=0;$certNo -lt $numberOfCerts;$certNo=$certNo+1)
{
$r1=$arr[$certNo]
if($certNo -ne ($numberOfCerts-1))
{
$r2=$arr[$certNo+1]
}
else
{
$r2="Maximum Row Index"
}
$isFound=$line -match "$r1 .* $r2"
$NumberOfChars=$matches[0].Length - $r2.Length
$thisCert=$matches[0].SubString(0,$NumberOfChars)
WriteCertInfo($thisCert)
}
$CertToList
Certificate Services/Windows Server 2008

Konfigurering av Online Responder

Posted by ragnar harper on

Vi har tidligere sett på installasjon av Online Responder tjenesten og konfigurering av CA relatert til online responder. Denne gangen skal vi se på hvilke konfigureringsalternativer vi har på Online Responder. Blant annet vil vi se på proxy, logging og sikkerhetsinnstillinger.

Konfigurering av Online Responder gjøres fra Online Responder Management konsollet. Du trenger rettigheter som lokal administrator.

Når du har starter Online Responder Management finner du din(e) online responder til venstre. Høyreklikk på den du ønsker å konfigurere, og trykk Properties. Du får nå opp et bilde med tre arkfaner; Web Proxy, Audit og Security.

Web Proxy

Under arkfanen web proxy kan du sette “Web Proxy Threads” og “Cached Entries”.
Web Proxy Threads  brukes til å spesifisere antallet tråder som er allokert for Online Responder. Med andre ord hvor mange klient forespørsler Online Responder kan håndtere samtidig. Å øke denne verdien betyr at man kan håndtere flere samtidige forespørsler, men også bruke mer minne.

Cached Entries spesifiserer antallet oppslag som kan caches i minnet.Anbefalt størrelse er mellom 1000 og 10 000.En høyere verdi vil bruke mer minne, men også frigjøre andre ressurser da det blir mindre oppslag og signering. Hvert oppslag som caches vil sånn ca ta 2KB (antatt ut fra en nøkkelstørrelse på 1024 bits på signeringssertifikatet.)

Audit

Her bestemmer du hvilke hendelser som skal logges til event loggen. Du kan velge mellom følgende hendelser:

  • Start/stop the online responder service
  • Changes to the online responder configuration
  • Changes to the online responder security settings
  • Requests submitted to the online responder
Security

Under Security kan du bestemme hvem som skal ha Read, Proxy Requests og Manage Online Responder rettigheter.

  • Read; lov til å lese konfigurasjonen på Online Responder
  • Manage Online Responder; lov til å administrere Online Responder
  • Proxy Requests;Lov til å proxye forespørsler til Online Responder gjennom grensesnittet IOCSP-RequestD.
Revocation konfigurering

En såkalt “revocation configuration” må finnes for hver CA som refererer en online responder. For å opprette en revocation konfigurering gjør du følgende:

  1. Start Online Responder Managemen med en bruker som har Manage Online Responder rettigheter
  2. Åpne navnet på Online Responder du ønsker å konfiguere (du vil se DNS navnet på denne i lista til venstre)
  3. Trykk på “Revocation Configuration”
  4. Høyreklikk på “Revocation Configuration” og velg “Add Revocation Configuration”
  5. Trykk “Next” på Getting Started … bildet
  6. På neste side (Name the Revocation Configuraton") skriver du inn et beskrivende navn for konfigurasjonen, og trykker “Next”
  7. Neste side (Select CA Certificate Location) gir deg tre valg:
    1. Select a certificate for an existing enterprise ca Dette valget brukes hvis du skal være online responder for en enterprise CA i samme forest. Sertifikatet hentes da fra Active Directory Domain Services
    2. Select a certificate from the local certificate store Bruk dette valget hvis sertifikatet finnes lokalt på online responder maskinen
    3. Import a certificate from a file Sertifikatet importeres fra fil
  8. Siden du kommer til å (Choose CA Certificate) avhenger av valget på punkt 7.
    1. Valgte du 7.1 får du velge hvilken CA i forest du skal bruke
    2. Valgte du 7.2 kan du velge CA sertifikat fra lokal sertifikat store
    3. Valgte du 7.3 velger du sertifikat fra filsystemet
  9. Nå skal du velge sertifikat å signere svarene med (Select Signing Certificate). Her kan du velge mellom manuell eller automatisk innrullering av OCSP signeringsertifikat. Trykk deretter “Next” og tilslutt “Finish”.
    MERK: Sertifikatet blir lagt inn i online responderens tjenestebrukerens certificate store. Du må altså peke certificate snapin mot service brukeren for online responder for å se dette sertifikatet
Certificate Services/Windows Server 2008

Implementering av Online Responder i Windows Server 2008

Posted by ragnar harper on

I denne artikkelen vil jeg se på hva Online Responder i Windows Server 2008 er, og hvordan du kan implementere den.
Selv om det er mulig å installere Online Responder ved å følge en oppskrift som dette, anbefaler jeg deg å planlegge PKI installasjonen på forhånd. Det er ikke nødvendigvis enkelt å gjøre endringer i en PKI installasjon på et senere tidspunkt, da en del informasjon knyttes til sertifikatene som utstedes.

Nok advarsler, la oss se på Online Responder.

Hva er Online Responder?

En Online Responder er basert på protokollen OCSP (Online Certificate Status Protocol) og er en effektiv måte å sjekke ett bestemt sertifikats status. Istedet for at klienten laster ned en CRL (Certificate Revocation List)  som inneholder alle ugyldige sertifikater, sender klienten en forespørsel til en online responder om statusen til ett bestemt sertifikat. Online responder returnerer status kun for det forespurte sertifikatet. Det er kun Vista og Windows Server 2008 som støtter Online Responders “out-of-the-box”, men på tidligere versjoner av Windows kan man bruke tredjepartsleverandører som for eksempel Tumbleweed.

Installasjon av Online Responder

Online Responer kan implementeres etter at Active Directory Certificate Services er installert, men før sertifikater utstedes. Her er prosessen du kan følge for å implementere Online Responder:

Om du ikke allerede har installert Online Responder tjenesten må du gjøre dette.

  1. Installer rollen Active Directory Certificate Services
  2. På siden for “Select Role Services” velger du Online Responder
  3. Ta med alle påkrevde tjenester (du får isåfall varsell om dette)
  4. Fullfør veiviseren
Konfigurere CA til å benytte Online Responder

Deretter må du konfigurere CA til å utstede sertifikater med URL til Online Responder

  1. Logg på CA med en bruker som har “Manage CA” rettigheter
  2. Start Certificate Authority konsollet
  3. På venstre side i konsollet finner du CA Serverens navn, høyreklikk på dette
  4. I dialogboksen som kommer frem (Properties), åpner du arkfanen “Extensions” (figur 1)
  5. Velg Authority Information Access (AIA) fra Select Extension , og klikk ADD
  6. I dialogboksen som nå kommer frem skriver du URL til Online Responer i Location ( figur 2 ) – klikk deretter OK
    1. Standardplassering til en online responder er /ocsp (http://ocsp.firma.no/ocsp)
  7. Tilbake i “Extensions”,velger du Online Responer URL´en du nettopp la til fra listen over URL´er, og klikker på “Include in the AIA extension of issued certificates”
  8. Klikk OK, og svar JA på å restarte Certificate Services

Dette kunne også være gjort fra kommandolinja med følgende bruk av certutil:

certutil –setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://pki.firma.no/CertData/%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n34:http://ocsp.firma.no/ocsp”

image
image

Figur 1

Figur 2

Konfigurere OCSP Response Signing Certificate Template

En Online Responder må signere sine OCSP svar. For å utføre denne signeringen trenger den ett sertifikat å signere med. Windows Server 2008 kommer med en template (eller mal om du vil) som støtter dette. Denne template´n er av type Windows Server 2008 (version 3) og er prekonfigurert med støtte for alle extentions og attributter.

Template´n har følgende egenskaper:

  • Gyldig for to uker, og fornyes to dager før utløp
  • Template gir leserettighet for Network Service kontoen, slik at denne kan lese sertifikatets private nøkkel.
  • Inneholder ingen AIA eller CDP extensions
  • Inneholder OCSP No Revocation Checking extension (1.3.6.1.5.5.7.48.1.5) ; dette betyr at OCSP signeringssertifikatet ikke blir testet for gyldighet på CRL listen

Den eneste endringen du trenger å gjøre på denne malen er å gi Read og Enroll rettigheter til hver Online Responder maskinkonto.

NB! Ikke gi AutoEnroll rettigheter til Online Responder maskinene. En Online Responder vil etterspørre flere OCSP Response Signing sertifikater (en per revocation provider) og autoenrollment vil kun fornye en av sertifikatene.

Nå må du aktivere denne template´n på en Windows Server 2008 Enterprise CA gjennom følgende prosedyre:

  1. Logg på CA med en bruker som har “Manage CA” rettigheter
  2. Start Certificate Authority konsollet
  3. Høyreklikk på Certificate Templates noden, og velg New – > Certificate Template To Issue
  4. I listen med tilgjenglige templates velger du OCSP Response Signing (som du nettopp modifiserte) og klikk deretter OK

    image
    Selve Online Responder tjenesten kjører som Network Service. Vi må derfor hake av for “Add Read Permission to Network Service on the private key(enable for machine templates only)” under “Request Handling” på OCSP Response Signing template´n. Dette er vist i figur 3.
    Merk at dette gjelder en Windows Server 2008 CA. På Windows Server 2003. På en Windows Server 2003 CA må du manuellt gi Network Service leserettigheter til sertifikates private nøkkel. Oppsummert gjøres dette på sertifikatet etter at det er utstedt. (Høyreklikk på sertifikatet og velg All Tasks –>Manage Private Keys. Gi Network Service Read rettigheter)

    Figur 3

    Nå har vi installert Online Responder, og konfigurert CA til å utstede sertifikater som er knyttet opp mot Online Responder. Hvis det er interesse for det kan jeg senere også lage en artikkel på konfigurering av Online Responder.

    Certificate Services/Sikkerhet/Windows Server 2008

    Kort om Windows Server 2008 Certificate Services

    Posted by ragnar harper on
    Hva er PKI?

    Public key infrastructure (PKI) er et system bestående av digitale sertifikater, sertifikat utstedere (Certification Authority,CA), samt registreringsautoriteter som verifiserer og autentiserer gyldigheten av hver entitet som er involvert i en elektronisk transaksjon gjennom bruk av kryptering med offentlige nøkler(public key cryptography). Standardisering av PKIs er fortsatt under rivende utvikling, selv om PKI er bredt implementert som et nødvendig element for ehandel.

    Microsoft PKI støtter en hierakisktisk CA modell som er skalerbar og tilbyr sameksistens med andre CA produkter.

    I sin enkleste form består et slikt hieraki av en enkelt Certification Authority (CA). I praksis er det vanlig å benytte flere CA for å klart definere et hieraki. I et hieraki vil underliggende noder (barn) være sertifisert av nivået over, og på denne måten binde identiteten sammen. På toppen av hierakiet sitter Root CA, og de CA som ligger under benevnes subordinate CA.

    I Windows er det slik at hvis du har etablert tillit til root CA (ved at root sertifikatet til root CA ligger i Trusted Root Certification Authorities) , så har du også tillit til alle gyldige subordinate CA.

    Det kan være flere årsaker til at man ønsker å benytte subordinate CA, for eksempel:

    • Bruk. Sertifikater kan utstedes for ulike formål, slik som for eksempel sikker epost og nettverksautentisering. Regelverk for utstedelse av disse sertifikatene kan være ulikt, og separering tilbyr ulik administrasjon av dette.
    • Organisasjonens oppbygning. Det kan være ulikt regelverk for administrasjon og utstedelse av sertifikat , avhengig av rollen i organisasjonen. Med subordinate CA kan du skille ut dette.
    • Geografisk oppbygning. Organisasjonen kan være spredt over et store geografisk område. Avhengig av nettverkstilkoblingen mellom disse kan det være vi krever dedikerte subordinate CA for noen eller alle av lokasjonene.
    • Last balansering. Hvis din PKI skal benyttes til et stort antall sertifikater, kan det å kun ha en CA resultere i en betydelig nettverksbelastning for denne. Bruk av flere subordinate CA til å utstede sertifikatene deler belastningen mellom disse CA.
    • Backup og feiltoleranse. Flere CAer øker sannsynligheten for at ditt nettverk alltid vil ha en CA tilgjenglig for å svare på henvendelser.

    Et hieraki med flere CA kan også tilby administrative fordeler, slik som :

    • Fleksibelt CA sikkerhetsmiljø for å skreddersy balansen mellom sikkerhet og brukervennlighet. For eksempel kan du benytte en maskinvarebasert kryptering på root CA, plassere CA fysisk adskilt og sikret, eller ha root CA offline.
    • Mulighet for å “slå av” en spesifikk del av CA hierakiet uten at det påvirker etablerte relasjoner. For eksempel kan du enkelt stenge ned en CA certificate som er assosisert med en spesifikk avdeling uten at det påvirker andre deler av organisasjonen.
    Ulike typer Certification Authorities (CA)

    En CA mottar en forespørsel om å utstede et sertifikat, verifiserer forespørselen basert på policy som er satt, og deretter bruker CA sin private nøkkel til å signere sertifikatet som blir utstedt. CA utsteder deretter sertifikatet til subjektet på sertifikatet som nå kan benytte sertifikatet som en identifisering i PKI. En CA er også ansvarlig for å trekke tilbake sertifikater og publisere en liste over sertifikater som er trukket tilbake(certificate revocation list (CRL)).

    En CA kan være en ekstern aktør, slik som VeriSign, eller en CA kan opprettes internt gjennom installasjon av Active Directory Certificate Services. Hver CA kan ha ulike krav til identifisering for utstedelse av sertifikat. Identifisering av forespørselen kan for eksempel gjøres mot domenekonto, ansatt id kort, førerkort eller lignende.

    En Windows Enterprise CA kan bruke en persons brukerkonto som bevis på identitet. Med andre ord, hvis du er pålogget en konto i domene, og ber om et sertifikat fra en enterprise CA, kan sertifikatet utstedes med bakgrunn i domenekontoen du er logget på med.

    Alle CA har et eget sertifikat som bekrefter identiteten til CA´en som er utstedt av en annen CA i hierakiet. Root CA derimot, utsteder sertifikatet til seg selv. Husk at alle kan opprette en CA, det er altså viktig at vi har retningslinjer for hvordan vi angjør om vi skal ha tillit til en CA eller ikke.

    Root og subordinate CA

    En root CA er den enheten med størst tillit i en organisasjons PKI. Hvis en root CA blir kompromitert eller utsteder sertifikater til uautoriserte entiteter vil enhver sertifikatbasert sikkerhet i din organisasjon bli sårbar. Derfor er vanligvis både fysisk sikkerhet og utstedelseeespolicyen på root CA sterkere enn for subordinate CA´er. Selv om det er mulig å benytte root CA til å utstede sertifikater til sluttbrukere, er det mer vanlig at dette utføres av subordinate CA´er istedet.

    En subordinate CA er en CA som har fått sitt eget sertifikat signert av en annen CA. Typisk bruk av en subordinate CA er for spesifikk bruk, slik som sikker epost, webautentisering eller smartkort autentisering. En subordinate CA kan igjen også utstede sertifikater til andre CA´er under seg selv. Gjennom en slik lenke med CA´er fra root CA og ned gjennom subordinate CA´er får vi et hieraki.

    Enterprise og stand-alone CA

    Windows Server 2008 støtter to typer CA, enterprise og stand-alone.

    Enterprise CA

    Enterprise certification authorities (CA) kan for eksempel utstede sertifikater for digital signatur, sikker epost (S/MIME), web autentisering (SSL og TLS) og pålogging til domene gjennom bruk av smartkort.

    Egenskaper til en enterprise CA:

    • Krever adgang til Active Directory Domain Services (AD DS).
    • Benytter Group Policy for å legge sitt eget sertifikat i Trusted Root Certification Authorities for alle brukere og maskiner i domene.
    • Publiserer bruker sertifikater og certificate revocation lists (CRL) til AD DS. For å kunne publisere sertifikater til AD DS, må CA serveren være medlem av gruppa Certificate Publishers. Dette skjer automatisk for det domenet serveren er medlem, men serveren må bli delegert nødvendige rettigheter for å kunne publisere sertifikater I andre domener.

    Merk! Du må være medlem av Domain Admins for å installere en enterprise root CA.

    En enterprise CA utsteder sertifikater basert på maler. Følgende funksjonalitet er mulig gjennom bruk av maler:

    · Enterprise CA utfører identifisering av brukeren ved utstedelse av sertifikat. Alle maler har rettighetsstyring som angir om den som forespør sertifikatet er autorisert til å få et sertifikat av typen den ber om.

    • Subjektets navn i sertifikatet kan genereres automatisk fra Active Directory Directory Services eller bli angitt eksplisitt av den som forespør. (Subjektets navn er navnet som sertifikatet blir utstedt på)
    • Malene har ett sett med forhåndsdefinerte utvidelser som legges inn i sertifikatet. Dette reduserer behovet for å angi informasjon ved forespørselen.
    • Sertifikater kan rulles ut automatisk med autoenrollment.
    Standalone CA

    Stand-alone certification authorities (CA) kan utstede sertifikat for oppgaver som digitale signaturer,sikker epost (S/MIME) og autentisering av servere (SSL, TLS).

    En stand-alone CA har følgende egenskaper:

    • Krever ikke Active Directory Domain Services (AD DS) (slik en enterprise CA gjør) Selv om du benytter AD DS kan en stand-alone CA bli brukt som en offline trusted root CA i ditt CA hieraki eller brukes til å utstede sertifikater til klienter over et extranett eller Internet.
    • Brukeren må legge ved identifiserende informasjon og spesiefisere hvilken type sertifikat som ønskes utstedt. (dette gjøres ikke når vi sender en forespørsel til en enterprise CA da denne henter
      identiteten fra AD DS og sertifikattypen basert på malen som er valgt). Autentiseringsinformasjon om forespørselen hentes fra maskinen lokale SAM database.
    • Som standard vil alle forespørsler måtte vente på en godkjennelse. En administrator kan godkjenne forespøreselen.
    • Maler kan ikke benyttes.
    • Stand-alone root sertifikat må manuellt installers i trusted root.
    • Hvis det benyttes en krypografisk provider med støtte for elliptic curve cryptography (ECC), en stand-alone CA will honor every key usage for the ECC key. For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

    Merk : Ved å kombinere stand-alone CA med AD DS,har CA følgende egenskaper:

    • Hvis en medlem av Domain Admins gruppa installerer en stand-alone root CA,vil den bli automatisk lagt til i Trusted Root Certification Authoritiesfor alle brukere og maskiner i domenet. På grunn av dette anbefales det ikke at du endrer standardhåndteringen av forespørsler i slike tilfeller. Ellers risikierer du å ha tillit til en CA som utsteder sertifikater uten noen form for sjekk om gyldigheten av identiteten.
    • Hvis en stand-alone CA installers av en bruker some r medlem i Domain Admins I domenet, så vil stand-alone CA publisere sitt CA sertifikat og certificate revocation list (CRL) til AD DS.
    Windows Server 2008 PKI funksjonalitet

    Sertifikathåndtering og PKI håndteres i Windows av Certificate Services. I Windows Server 2008 heter denne Active Directory Certificate Services (AD CS). Tidligere versjoner av Windows Server, slik som Windows Server 2003 og Windows 2000 Server støtter og sertifikattjenester. Funksjonaliteten er derimot forskjellige mellom disse versjoner, slik at det er viktig at man har oversikt over hvilke krav man har, slik at man velger riktig versjon. Implementeringen kan gjøres fra helt enkle enserver installasjoner til flere servere. Ved bruk av flere servere har man som oftest root, policy og issuing CA servere, samt andre som er Online Responders.

    Merk! AD CS kan ikke installeres på Server Coreeller Itanium baserte Windows Server 2008 systemer. Kun et begrenset utvalg av server roller er tilgjenglig for disse versjonene.

    Oversikt over AD CS komponenter på ulike Windows Server 2008 versjoner:

    Komponent

    Web Edition

    Standard Edition

    Enterprise

    Datacenter

    Certification Authority

    Nei

    Ja

    Ja

    Ja

    Network Device Enrollment

    Nei

    Nei

    Ja

    Ja

    Online Reponder

    Nei

    Nei

    Ja

    Ja

    Web enrollment

    Nei

    Ja

    Ja

    Ja

    Oversikt over hvilke Certification Authority (CA) komponenter som støttes på Windows Server 2008:

    CA egenskap

    Web Edition

    Standard

    Enterprise

    Datacenter

    Tilpassbare version 2 og version 3 certificate templates

    Nei

    Nei

    Ja

    Ja

    Arkivering av nøkkel (key archival)

    Nei

    Nei

    Ja

    Ja

    Rolle separering

    Nei

    Nei

    Ja

    Ja

    Certificate manager restrictions

    Nei

    Nei

    Ja

    Ja

    Delegated enrollment agent restrictions

    Nei

    Nei

    Ja

    Ja

    Administrasjon av Windows Server 2008 PKI

    Følgende Microsoft Management Console snapins benyttes til konfigurasjon av AD CS:

    • Certification Authority. Verktøyet for å administrere CA,tilbakekalle sertifikat, og utstede sertifikat.
    • Certificate Templates. Benyttes til å duplisere og konfigurere sertifikat maler som skal publiseres i Active Directory Domain Services (AD DS) og benyttes av enterprise CA.
    • Online Responder. Konfigurering og administrering av Online Certificate Status Protocol (OCSP) responders.
    • Enterprise PKI. Overvåking av flere CA´er, certificate revocation lists (CRLs), og lokasjoner hvor informasjon lagres, slik som authority information. Administrerer også AD CS objekter som er publisert til AD DS.

    · Certificates. Benyttes for å se og administrere sertifikater for en maskin, bruker eller tjeneste.

    Alle disse snapin´ene kan hentes opp i mmc.exe, og når komponenten er installert på en server, vil du også finne snarveier til verktøyene under Administrative Tools.