Kommandolinje

Liste ut filer basert på eier– FSUtil

Posted by ragnar harper on

Hvis du bruker quota på et NTFS volume kan du liste ut filer etter eier med FSUtil kommandoen:

FSUTIL file findbysid <brukernavn> <katalog>
FSUTIL file findbysid Ragnar c:\users

Jeg tenker å organisere kommandoer under wiki´en på harper.no etter hvert som jeg får tid. Har du noen spesielle ønsker så hører jeg fra deg 🙂

Hyper-V/Windows Server 2008

Backup av virtuelle maskiner på Hyper-V med Windows Backup

Posted by ragnar harper on

Det er mulig å benytte VSS for å ta backup av virtuelle maskiner som kjører på Windows Server 2008. For å gjøre dette må du legge inn følgende registry nøkler for å registrere Hyper-V VSS Wirter med Windows Server Backup.

Du kan forøvrig liste dette ut med:

vssadmin list writers – {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}

Endring i registry:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}

Name: Application Identifier
Type: REG_SZ
Value: Hyper-V

Exchange/Powershell

Script som starter Exchange 2007 services som er stoppet

Posted by ragnar harper on

I forbindelse med Exchange kursene trenger vi en del ganger å starte servicer som vi har stoppet, eller kommer opp i status stopped ved oppstart.
Jeg skrev dette enkle scriptet som skal være ganske enkelt å forstå 🙂 Det kjøres på hver Exchange server, analyserer hvilke tjenester den trenger som ikke kjører, og starter disse.

# Scriptname start-StoppedExchangeService.ps1
#Script start
$groups=test-servicehealth | select ServicesNotRunning
foreach($group in $groups)
{
  foreach($service in $group.ServicesNotRunning)
  {
    $testService=Get-Service $service
    if($testService.Status -eq "Stopped")
    {
        start-service $service
    }
  }
}

#Script end

Kommandolinje

Bruk av VSSAdmin.exe

Posted by ragnar harper on

Vista, Windows Server 2008,Windows XP, Windows Server 2003)

VssAdmin brukes til å håndtere volume shadow copy tjenesten.

Liste ut informasjon om volume shadow (plassering og plassbruk)
vssadmin list shadowstorage

Endre plassbegrensninger eller plassering:
vssadmin resize shadowstorage /for=C: /On=D: /Maxsize=500MB

Eksemplet over endrer shadow kopiene for C: til å ligge på D:, i tillegg kan volume shadow kopiene maks benytte 500 mb. Hvis ikke maxsize angis er det ingen grense på hvor mye plass den kan benytte. Kravet er at MaxSize er 300MB eller høyere, og kan angis med KB,MB,GB,TB,PB og EB. Hvis du ikke angir suffiks, så beregnes størrelsen i bytes.

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.

Kommandolinje/Windows Server 2008

Bruk av dfsrmig.exe

Posted by ragnar harper on

DFSRmig.exe

(Windows Server 2008)

Kommandoen dfsrmig.exe lar deg migrere fra NTFRS replikering til DFSR replikering av SYSVOL.
Dette kan gjøres når domain functional level er satt til Windows Server 2008

Prosessen er og verktøyet gir:

  • enkel og krever minimalt med input
  • er designet med tanke på å gjøre operasjonen med lav risiko og minimalt med nedetid
  • gir oversikt og mulighet til å "commite" replikeringen over til DFSR når alt er oppe og fungerer
  • er reverserbar – kan gå tilbake (rolled back) til NTFRS
  • beskrives som robust, feiltolerant og håndterer forsinkelser – kan altså brukes på migrering av domenekontrolellere i fjerne lokasjoner også