Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
srpen 31
Záznamy přednášek z konference MVP Open Days v Moskvě 2014

Všechny záznamy z přednášek z konference MVP Open Days v Moskvě z června 2014, jsou k dispozici zde. Je tam i jedna moje :-)

http://www.techdays.ru/series/MVP_DAY_2014

srpen 30
Zajímavé poměry na trhu

Dneska jsem se jenom tak pro zajímavost mrknul na poměry na trhu OS a prohlížečů:

Operační systémy s přehledem vedek Windows 7, Windows XP i nadále 25%

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

Prohlížeče na počítačích vede krutě IE, ale jsou zajímavé jeho verze, jak lidi moc neaktualizují:

http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

Zatímco na mobilech se IE skoro neumístilo :-)

http://www.netmarketshare.com/browser-market-share.aspx?qprid=0&qpcustomd=1

 

Bing opět propadl. Ta parta Indů, která při každém dotazu generuje ručně jeho výsledky, není moc úspěšná, jak se zdá. Asi by to chtělo zvolit jinou strategii :-)

http://www.netmarketshare.com/search-engine-market-share.aspx?qprid=4&qpcustomd=0

Teď mě ještě napadlo - porovnejte používanost Bingu s penetrací operačních systémů Windows a IE prohlížeče. I když je Bing výchozím vyhledávačem, stejně si ho lidi dokážou změnit, když opravdu chtějí.

srpen 23
Skenování IP a MAC adres pomocí PowerShellu

Dneska jenom taková blbůstka - mám virtuálku v Azůru, tak jsem si říkal, že se mrknu, jaké další virtuálky tam jsou. Tak jsem si udělal jednoduchý MAC/IP adresovový skenner v PowerShellu.

$net = '100.79.176' ; (1..254) | % { $ip = $_ ; ping "$net.$ip" -n 1 -w 1000 | out-null ; arp -a | ? { $_ -like "  $net.$ip * ??-??-??-??-??-?? *" } }

V podstatě stačí změnit rozsah IP adres v první proměnné.

Co by si z toho mohl někdo odnést za ponaučení je následující. Bez ohledu na, jestli máte zapnutý firewall (a můžete blokovat všechno), stejně váš počítač bude odpovídat na ARP dotazy. Samozřejmě jsou to broadcasty, takže dostupné jen na stejném segmentu sítě, ale to v případě těchto sdílených prostředí není moc omezující.

srpen 19
Hodnocení konference MVP Open Days v Moskvě z června 2014

V červnu jsem se zúčastnil konference MVP Open Days, která probíhala v Moskvě. Potom ještě následoval výlet do oblasti horní Volhy okolo města Rybinsk. A protože nedávno přišlo vyhodnocení obou těchto přednáškových bloků, nemůžu odolat a musím se tady pochválit. Toto smrdííí:

Session Name Speaker Name Content Score Speaker Score Avg. Score
C403 What would a real hacker do to your Active Directory Ondřej Ševeček 8,7 8,76 8,73
B403 Exchange Design Concepts and Best Practices Oleg Krylov 8,67 8,52 8,59
B306 Publishing Exchange – TMG\UAG Replacement Consideration Oleg Krylov 8,4 8,5 8,45
B401 Lync Server 2013 and Exchange Server 2013 Integration Ilya Rud 8,3 8,52 8,41
A206 SQL Server Analysis Services: Multidimensional vs Tabular Mode? Andrey Korshikov 8,33 8,44 8,39
A305 SQL Server 2014 In-Memory OLTP. Deep Dive for developers Sergey Olontsev 8,33 8,33 8,33
A302 NFC for Windows Phone Developers Catalin Gheorghiu 8,14 8,5 8,32
C206 Using Windows Server 2012 R2 Essentials & Windows Server 2012 R2 Essentials Experience. Scenarios overview Gennadij Chernikov 8,17 8,25 8,21
B102 SQL Server: some tips for the beginners Sergey Olontsev 8,17 8,22 8,2
C205 Front door with locker: Service Manager on IT-duty Anton Gritsenko, Artem Pronichkin 7,88 7,96 7,92
A301 C# 6 new language features Andrew Koryavchenko 7,83 7,61 7,72
C304 Operations Manager - what should you NOT do Alexey Zhuravlev, Artem Pronichkin 7,42 7,9 7,66
A304 Windows Embedded 8(.1) Handheld Catalin Gheorghiu 7,25 8 7,63
C201 What’s New in Hyper-V in Windows Server 2012 R2  Mikhail Komarov 7,74 7,45 7,59
C402 Hyper-V Networking Alexey Zhuravlev, Artem Pronichkin 7,72 7,45 7,59
B305 Windows Azure IaaS - configure, deploy and manage Luka Manojlovic 7,33 7,71 7,52
A203 SQL Injection - are you ready for defense? Andrey Korshikov 6,79 6,84 6,82

 

Session Name Speaker Name Content Score Speaker Score Avg. Score
Building virtual lab environment with PowerShell Ondřej Ševeček 8,75 8,75 8,75
Setting Up Business in the US Dmitry Sotnikov 8,63 8,81 8,72
How to Grow Your Blog Audience and Keep it Engaged Vadim Sterkin 8,52 8,8 8,66
Local Office interaction roundtable Artem Pronichkin, Yulia Belyanina 8,61 8,61 8,61
Demonstrate to Win! Andrey Beshkov 8,57 8,64 8,61
Metrics for SaaS Dmitry Sotnikov 8,33 8,66 8,5
Building up community Bernardin Katić 8,33 8,55 8,44
How to pitch investors Alexander Gornyi 8,4 8,4 8,4
Community technical content Ekaterina Lajintseva 8,18 8,51 8,35
Mysteries of Windows Phone Emulator Catalin Gheorghiu 7,87 8,37 8,12
The art of stage presence Andrey Beshkov 7,85 8,35 8,1
MS et al: SSO challenge on Enterprise landscape Ivan Padabed 8 8,16 8,08
Professional Technical Evangelism Dmitri Nesteruk 7,88 8,17 8,03
Migration of legacy systems to Microsoft Azure Mihail Mateev 7,5 8 7,75
srpen 18
Split DNS a veřejné záznamy uvnitř interního DNS serveru

Kamarád mě požádal, abych se trošku vyjádřil o parádní možnosti, kterou máte, když provozujete tzv. split DNS (někdy split-brain DNS). Tedy skoro každý provozuje split DNS prostředí. Pokud nevíte co to je, určitě to hned poznáte z následujícího obrázku:

Jednoduše - vaše vnitřní doména Active Directory má nějaké vnitřní jméno, běžně tam bývá přípona .local, nebo v jako v mém případě gopas.virtual. K tomu máte uvnitř také DNS server, který obsahuje záznamy pro tato jména ve formě DNS zóny (DNS zone). Vnitřní DNS server je autoritou pro tuto gopas.virtual doménu, která navíc není z internetu přeložitelná.

Někde venku v internetu máte jiný DNS server, který obsahuje zónu pro vaši veřejnou doménu, něco jako v mém příkladu gopas.cz.

Většina A záznamů ve vnitřní zóně gopas.virtual budou privátní IP adresy. Zatímco většina A záznamů ve veřejné zóně gopas.cz budou nejspíš veřejné IP adresy vedoucí na nějaké web servery apod.

Web servery máte buď hostované v internetu, to nás tady nezajímá. Nebo je máte u sebe, například v DMZ, nebo přímo v intranetu v LAN. V našem obrázku jsou tam dokonce dva SharePoint servery, čistě pro příklad.

Oba dva SharePoint mají ve skutečnosti privátní IP adresy a oba ty počítače jsou členem vnitřní gopas.virtual domény. Mají tedy samozřejmě automaticky zaregistrovaná jména (A record) ve vnitřní DNS zóně gopas.virtual. To by vás asi nemělo překvapit.

Problém s přístupem ze vnitř a z venku

Když mají uživatelé přistupovat na ten SharePoint jak z vnitřní sítě (nebo z VPN), tak i přímo z internetu? Lidé to řeší různě.

Šlo by to samozřejmě udělat tak, že SharePoint bude dostupný na více URL, například http://intranet.gopas.virtual (nebo jen krátce http://intranet) a https://intranet.gopas.cz. Tedy dvě různá URL, jedno je čisté HTTP na vnitřní .virtual doméně, zatímco druhé je veřejné a ještě HTTPS. Technicky to samozřejmě vyřešit lze, na to máte na SharePoint technologii Alternate Access Mapping (AAM).

Ale uživatelsky je to nepohodlné a vede to k chaosu jak v hlavách lidí, tak v lincích, které si lidi posílají mailem, nebo které mají uložené v oblíbených poližkách apod. Proč bych to tak dělal? Mám lepší řešení.

Jedno jméno vládne všem

Proč proboha neudělat ten SharePoint rovnou na jednom společném jméně, pěkně veřejném, ideálně tedy https://intranet.gopas.cz. Ze všech směrů to bude přístupné a pořeší se jen technické problémy, zatímco lidi budou fungovat hladce. Plus, až se rozhodně te, že to celé přesunete do Office365, tak si toho nikdo ani nevšimne.

Jenže ty technické problémy...

Ve vnějším DNS, které je autoritou pro veřejnou zónu gopas.cz samozřejmě ten záznam vytvoříte a dáte mu veřejnou IP adresu. Nastane problém s přístupem zevnitř. Vnitřní DNS server toto jméno nezná, bude tedy pouze rekurzivně nechávat překládat název intranet.gopas.cz venku v internetu. Výsledkem bude opět ona veřejná IP adresa.

Ale to se tam nejspíš zevnitř nedostanete, aniž by to váš firewall nějak podporoval (loopback publishing, DNS rewrite apod.). Protože se budete snažit zevnitř dostat přes ten firewall a jeho veřejnou IP adresu zase zpět dovnitř.

Nene, potřebujeme to zařídit tak, aby rovnou vnitřní DNS server znal ono veřejné jméno intranet.gopas.cz a překládal ho rovnou na privátní IP adresu.

Takže dáme do vnitřního DNS serveru celou veřejnou zónu gopas.cz? Uf. Buď tam dáte jen jeden záznam intranet.gopas.cz a všechno ostatní se tím stane automaticky nedostupné (protože vnitřní DNS server bude autoritou pro tuto celou zónu), nebo tam budete muset opsat všechny ostatní záznamy z veřejného DNS serveru.

Samostatná zóna pro jeden jediný záznam?

Právě toto! Ono se to moc neví, ale proč byste nemohli udělat do vnitřního DNS serveru zónu přímo pro jméno intranet.gopas.cz. Do ní už pak jenom vložíte A záznam (neuvedete jméno a bude se to zobrazovat s nápisem (same as parent folder)), který povede na privátní IP adresu SharePoint NLB a je to.

Takto si nezakryjete veřejnou zónu a přitom budete mít maximální flexibilitu.

Chápu, že se to člověkovi na první pohled nezdá, dělat "celou DNS zónu" pro "jeden jediný záznam", ale proč ne? Celá zóna je navíc jeden jediný objekt v Active Directory, A záznam je taky jeden objekt v AD. Takže spotřeba je minimální, výkon netrpí a bezpečnost? Stačí vypnout automatické aktualizace (dynamic update) a není co řešit. Naopak, máte to plně pod kontrolou, to je podle mě spíš výhoda. Ve větších prostředích uvidíte třeba i desítky takových "zóneček".

Nemusíte se starat o zástupce a linky pro víc URL, DNS překlad si řešíte sami na Windows DNS serverech a nemusíte se bavit se síťaři. Pohodička.

srpen 18
Naučte se používat uvozovky, apostrofy, složené závorky a herestring

Jéé, našel jsem článek, co jsem psal před půl rokem a neuveřejnil...

Pokaždé, když tohle ukazuju, setkávám se s poměrně překvapenými výrazy. Možná bude dobře dát tady do kupy, třeba si to někdo přečte.

Řetězce v PowerShellu

Existuje několik možností, jak zadat řetězec v PowerShellu. Můžete to udělat takto:

# pomoci apostrofu (jednoducha uvozovka) - single quote
$text = 'hellow world'

# pomoci normalnich uvozovek - double quotes
$text = "hellow world"

# slozene zavorky - double brackets
$text = { hellow world }

# jednoduche uvozovky (apostrof) a zavinac - at sign
$text = @'
    hello world
'@

# normalni dvojite uvozovky a zavinac - at sign (herestring)
$text = @"
    hello world
"@

Akorát ten výsledek není stejný. Jednoduché uvozovky, neboli apostrof, a normální dvojité úvozovky se nazývají jednoduše string. Pokud tam přidáte ještě zavináč (at sign), tak se to nazývá here string. Složené závorky jsou specialita nazvaná ScriptBlock.

Rozdíl mezi apostrofem a uvozovkami

Cokoliv napíšete do apostrofů (jednoduchých uvozovek) se chápe prostě jako znaky. Uvnitř apostrofů neexistují žádné speciální znaky, kromě jednoho. Co když chcete dovnitř napsat apostrof? Musíte ho jednoduše zdvojit:

$message = 'I would like to say ''hello world'' to the world'

Výsledkem jsou jenom jedny apostrofy. Pokud do apostrofového řetězce vložíte například dvojité úvozovky, nemusíte se ničeho obávat, prostě tam normálně budou:

$message = 'I would like to say "hello world" to the world'

Zato pokud použijete normální uvozovky, má to trošku více možností. Uvnitř dvojitých úvozovek se vyhodnocují escape sekvence a nahrazují se hodnoty proměnných a složitějších výrazů. Podívejte se na následující příklad.

$age = 35
$name = 'Ondrej'

$message = "My name is $name and I am `t`t $age years old"
# result: My name is Ondrej and I am         35 years old

Uvnitř uvozovkového řetězce se vyhodnotí $ (dolar) znak a proměnné $age a $name a nahradí se svou hodnotou. Dále jsem tam rovnou vložil dvakrát escape sekvenci pro speciální znak TAB. Escape sekvence se dělá pomocí znaku zpětného apostrofu (zpětná jednoduchá uvozovka - tick), to je znak co máte úplně nalevo vedle jedničky pod ESC. Jiné speciální escape znaky, které jsou běžně používané jsou `n a `r, tedy konec řádku.

Jak vložíte do uvozovek jiné uvozovky? Musíte to zvnovu escapenout:

$message = "Moje prezdivka je `"ondass`" a me se docela libi"

Jak je vidět, narozdíl od jednoduchých apostrofů, uvnitř nichž jste apostrof museli zdvojit, tady musíte uvozovky escapenout.

Nahrazování proměnných a výrazů uvnitř uvozovek

Jak jsme říkali, řetězce apostrofové samy proměnné nenahrazují. Hodí se to tedy obvykle více jako obecný znak pro ohraničování "čehokoliv". Zatímco uvozovkové řetězcové konstanty mají právě výhodu (někdy to právě není výhoda), že nahrazují proměnné, ale umí nahradit i složitější výrazy.

Samozřejmě pozor na to, že PowerShell musí být schopen poznat, co je jméno proměnné a co není:

$age = 35
$name = 'Ondrej'

$message = "My name is $name and I am $ageYears old"
# result: My name is Ondrej and I am old

Jak je vidět, tady jste neoddělili slovo Years od jména proměnné, takže si PowerShell myslel, že tam chcete vložit hodnotu proměnné $ageYears, která neexistuje.

To se dá vyřešit právě pomocí nahrazování celých výrazů:

$age = 35
$name = 'Ondrej'

$message = "My name is $name and after 20 years, I will be $($age + 20)years old"
# result: My name is Ondrej and after 20 years, I will be 55years old

Jasné? PowerShell vidí uvnitř znak dollaru. Za ním následuje závorka, takže všechno co je uvnitř se nejprve vyhodnotí. V tomto případě nejen jméno proměnné, ale rovnou výpočet. Můžete volat dokonce cmdlety, příkazy a cokoliv, co je prostě PowerShell výraz.

Já osobně nerad používám uvozovky, raději dovnitř vkládám hodnoty pomocí operátoru -f (tedy [String]::Format), protože je to podle mě přehlednější a méně náchylné k chybám, kdy si do uvozovkového řetězce z nepozornosti vložíte dolar jako součást nějakého textu. Typicky heslo Pa$$w0rd :-)

Abyste nemuseli přemýšlet o nahrazování, aneb herestring

Takže jak jsme viděli, v obou formách řetězců se něco nahrazuje. Uvnitř apostrofů sice jenom znak dvojitého apostrofu, ale i tak je to dost. Někdy chcete do řetězce vložit prostě cokoliv. Typickým příkladem je možnost přímo do PowerShellu vložit C# kód, který to umí samo zkompilovat a pustit (jako jsem třeba nedávno použil v případě porovnání na null). Jenže to by byla strašná dřina kontrolovat, co tam musíte opravit, aby to fungovalo správně.

Od toho jsou právě ony herestringy. Prostě dáte navíc zavináč a můžete si psát co chcete. Má to samozřejmě jedno omezení. Here string začíná @', ale tohle musí být poslední znak na řádku. A končí zase opačně apostrof-zavináč, tedy '@, ale tady to musí být vůbec první znak na řádku. Ani mezera před ním nemůže být.

Aby toho nebylo málo, here string můžete udělat i za použití uvozovek, tedy @" a "@. V takovém případě se uvnitř vyhodnocují escape sekvence a proměnné. Na co to tedy je? No na to, že uvnitř můžete používat volně uvozovky, které tím pádem nemusíte escapeovat.

Podivný řetězec typu ScriptBlock

Ono to vypadá divně, když tvrdím, že to je řetězec. Asi to každý chápe jako blok PowerShell kódu, že? Jenže on to je opravdu jen řetězec. Přijme to cokoliv, co tam napíšete. Není to kompilované. Jediné co to dělá, je že to musí mít korektní PowerShell syntaxi. Následující dva příklady jsou podivné, ale od toho je tento článek

# although this is a valid PowerShell script
# when you run it, it will probably fail because you do not have
# a hello program with world parameter available
$validPSstr = ' hello world '
$validPSsb = { hello world }
& $validPSstr
& $validPSsb

# this is an invalid PowerShell code, because if requires
# brackets for its condition
$invalidPDstr = ' if error then fail '
$invalidPD = { if error then fail }

V prvním případě jsem nadefinoval dvakrát ten stejný PowerShell kód, který následně spouštím pomocí operátoru ampersand &. Z pohledu syntaxe je to naprosto v pořádku PowerShell kód. Akorát se podívejte na tu chybu. PowerShell to pochopil tak, že chcete spustit program hello s parametrem world. Což nejspíš neexistuje.

Ve druhém případě vám projde to přiřazení do řetězce, protože tam se nekontroluje syntaxe. Ale právě v případě složených závorek (double bracket) to neprojde. Byť to možná vypadá podobně, klíčové slovo if musí být následováno závorkami, takže tohle není platný PowerShell kód.

Shrnutí

Existují tedy tyto typy řetězců:

  • jednoduché uvozovky (apostrof) - uvnitř se v podstatě nic nenahrazuje, kromě dvojitého apostrofu
  • normální uvozovky (dvojité uvozovky) - uvnitř se nahrazují escape sekvence pomocí znaku zpětného apostrofu (tick) a hodnoty proměnných a obecně výrazů začínajících znakem dollar $.
  • here string - nenahrazuje se nic v případě apostrofového, v případě uvozovkového se uvnitř dá použít bez problémů uvozovka.
  • ScriptBlock - taky je to vlastně jen text. Akorát se mu kontroluje PowerShell syntaxe. Neznamená to, že by příkazy musely existovat. Prostě až se bude spouštět, třeba to klapne :-)

Cvičení na závěr

A zkuste se zamyslet, co asi udělá toto (když to dělá chybu, je to tam tak schválně :-)):

$jmeno = 'Ondrej'
$vek = 35

'Moje jmeno je $jmeno a vek je $vek'

"Moje jmeno je $($jmeno) a vek je $vek"

"Vsechny procesy v retezci $(get-process). To je ale hruuuuza"

"Vsechny procesy v retezci $(get-process svc* | Out-String). Neni to aspon trosku lepsi?"

"Heslo je: Pa$$w0rd"

"Moje jmeno je ''$jmeno''"

'Moje jmeno je `'$jmeno`''

"Co treba ""tohle"""

"Co treba `"jinak`""

'Pujde sem vlozit TAB-`t`t-?'

"Pujde sem vlozit TAB-`t`t-?"

'Jmeno zarovnane doprava {0,20}.' -f $jmeno

"Co tohle jmeno {$jmeno}"

"Co tohle jmeno {$jmeno} a {0}" -f $vek

"Co tohle jmeno `{$jmeno`} a {0}" -f $vek

"Co tohle jmeno {{$jmeno}} a {0}" -f $vek

'Vsechny procesy v retezci {0}. Takto mi to pripadne neprehlednejsi.' -f (get-process svc* | Out-String)

 

srpen 17
Nová parádní vychytávka v PowerShell 3 kterou soudruzi neudělali kompatibilní s PowerShell 2

Dneska jsem narazil na pěknou věc. Obecná teorie tvrdí, že PowerShell 3.0 by měl být zpětně kompatibilní s PowerShell 2.0. Mělo by to znamenat, že co napíšete ve starší verzi, mělo by jet v pořádku v novější verzi. Jak jsem tu už psal, není tomu tak úplně vždycky (což se ostatně dalo čeka). Byť i například obsah proměnné $psVersionTable se snaží tvářit, že všechno by tak být mělo.

Dneska si můžete vyzkoušet příkaz switch a jeho problém při porovnávání konstantních hodnot typu [double], tedy desetinných čísel. Následující kód běží korektně v PowerShell 2.0, zatímco ve verzi 3.0 to vrací jiný výsledek. Zdá se, že PowerShell 3.0 konvertuje ty konstanty na řetězce a tím pádem to potom není schopen korektně porovnat.

PowerShell 2.0 se správným porovnáním:

$double = 5.3
$double.GetType()

switch ($double) {

  5.3 { echo 'prvni' }
  5.4 { echo 'druhy' }
  default { echo 'default' }

}

# result in PowerShell 2.0: prvni

PowerShell 3.0 s jiným výsledkem:

$double = 5.3
$double.GetType()

switch ($double) {

  5.3 { echo 'prvni' }
  5.4 { echo 'druhy' }
  default { echo 'default' }

}

# result in PowerShell 3.0: default

Existuje nějaká forma, která by to v obou verzích jazyka porovnala stejně a korektně? Například takto:

$double = 5.3
$double.GetType()

switch ($double) {

  { $_ -eq 5.3 } { echo 'prvni' ; break ; }
  { $_ -eq 5.4 } { echo 'druhy' ; break ; }
  default { echo 'default' }

}

# result in both PowerShell 2.0 and 3.0: prvni

Musíte si prostě to porovnávání udělat ručně sami pomocí [ScriptBlock], protože jak se zdá, trojka si to konvertuje špatně.

srpen 16
Jak ve skriptu poznáte jestli běžíte ve virtuálním počítači na Hyper-V

Občas něco skriptujete a potřebujete se rozhodovat, jestli běžíte na železe, nebo ve virtuálním počítači. Prozatím to u Hyper-V virtuálních strojů detekuju takto, pomocí WMI třídy Win32_BaseBoard:

$runningInHyperV = gwmi Win32_BaseBoard | % { if (($_.Manufacturer -eq 'Microsoft Corporation') -and ($_.Product -eq 'Virtual Machine')) { $true } else { $false } }

Co jsem googloval, tak se nikdo nedívá na tu hodnotu Product (nebo to stejné v tabulce Win32_ComputerSystem.Model), ale já bych to nepodceňoval. V dnešní době bych očekával, že pomalu začnou věci jako Surface a Nokia hlásit výrobce taky jako Microsoft.

Kdyby to náhodou někdo měl, mohl by sem přikomentovat, jakou má hodnotu v políčku Manufacturer a Product, když si pustí následující skript:

gwmi Win32_BaseBoard | select Manufacturer, Product

 

srpen 15
Snapshot, checkpoint a Hyper-V replikace - tohle není zálohování

Dnes na první pohled možná z trošku jiného soudku. Uvědomte si ale, že spolehlivost a dostupnost jsou základní bezpečnostní požadavky, takže se zase až tak moc od svého obvyklého směru neodchyluju.

Dnes na věčné téma - snapshot (dnes checkpoint) - a na dnes ještě aktuálnější téma Hyper-V replikace.

Bohužel, pořád si někdo myslí, že se jedná o zálohování. Tohle nemá nic společného se zálohováním. V případě Hyper-V replikace (Hyper-V replication) se GUI dokonce tváří, že vytváří tzv. "application consistent recovery point", což je značně matoucí a přitom to taky není zálohování. Špatně to chápat může být smrtící. Když takovou "zálohu" obnovíte, buď si něco nenávratně poškodíte, nebo budete následujících x let řešit opakující se problémky a latentní bugy.

Přehled technologií

Hyper-V nabízí následující technologie, které se nějakým způsobem dotýkají pojmu "zálohování", a které nějak řeší data uložená ve VHD a VHDX souborech.

  • snapshot, neboli checkpoint od Windows 2012 (pouze změna názvu, jinak se nic nemění) - prostě si uděláte v jednom okamžiku snímek virtuálního počítače. Tedy obsahu jeho VHD a VHDX disků a paměti RAM, pokud virtuálka zrovna běží. Mohli bychom to tedy nazývat offline a online snapshot, tedy buď děláte snapshot z vypnutého VM, nebo z běžícího.
  • storage migration - Windows 2012 umí přesunout VHD i VHDX soubory za jízdy virtuálního počítače na jiné úložiště. V případě VHDX souborů můžete přesouvat i na sdílený SMB adresář. Prostě virtuálka jede celou dobu z původního virtuálního hard disku, jakmile je dokopírováno, virtuálka se "pausne", dokopíruje se posledních pár bajtíků a přehodí se to na nové umístění.
  • live migration - virtuální disky zůstávají na stejném místě, jenom se přehodí RAM paměť mezi dvěma stroji, klidně za jízdy virtual machine.
  • Hyper-V replication - Windows 2012 umí kopírovat VHD a VHDX soubory a jejich změny plynule na pozadí na jiný Hyper-V hostitelský stroj. Kopírování neprobíhá úplně plynule, dělá se v balících jednou za 30 sekund, jednou za 5 minut, nebo jednou za 15 minut. Takže na cílovém stroji budete mít několik sekund, nebo minut starou verzi VHD a VHDX souborů. Na co je replikace dobrá se dozvíte na konci.
  • asynchronní mirroring na diskovém poli - relativně levnější hardware technologie, kdy se pole umí samo o sobě kopírovat na jiné diskové pole. Dělá to asynchronně, to znamená, že na druhém poli máte o něco starší stav disků.
  • syncronní mirroring na diskovém poli - ultra mega drahá hardware technologie, kdy se pole miroruje synchronně hned při zápisu každého bloku, takže na druhém poli je v každém okamžiku to stejné.

Storage migration a live migration náz nezajímá, protože v těchto dvou případech se nemůžete vrátit ke staršímu obsahu VHD/VHDX souborů. Zatímco v případě snapshotu/checkpointu a Hyper-V repliky si vrátit starší verzi disků můžete.

A to je ten kámen úrazu.

Obnovit starou verzi VHD nebo VHDX může být smrtící

Už se docela ví, že není zdravé obnovovat jen tak snapshot. Ale ono je to stejné v případě Hyper-V repliky!!! Ani tam to nedělejte. Detaily zde.

Máte řekněme server. Například databázový, nebo Active Directory, nebo Exchange, nebo SMB souborový, nebo cokoliv. Co se asi stane, když ten server vrátíte datově o pár sekund/minut/hodin/dnů zpátky? Mohlo by se zdát na první pohled, že nic podstatného. Prostě přijdete o ta data, která se uložila v té "obnovovací díře" - prostě tam nebudou nějaké soubory, nebo maily, nebo třeba několik uživatelů bude mít zase staré heslo, protože si ho mezitím změnili.

Tak to by až tak nevadilo. S tím se snad počítá, že když obnovuju zálohu, že tam budou jen starší data.

Jenže je jiný problém. Replikace. Všechny tyto technologie obvykle nabízí nějakou formu své vlastní aplikační replikace. V případě Exchange máte dokonce replikací stovky nebo i tisíce. On si totiž každý Outlook ve skutečnosti replikuje obsah svého mailboxu k sobě do offline složek (OST soubor). V případě SMB serveru je tam taky podobná klientská replikace nazvaná offline files.

Obecně bych řekl, že více počítačů nějak sdílí data.

Jak fungují replikace

Představte si, že Outlook replikuje z Exchange tisíce, nebo miliony jednotlivých mailů a schůzek. Asi těžko to bude dělat tak, že by při každém spuštění projel seznam všech mailů, které jsou v Exchange a porovnal to s tím, co má u sebe, a zbytek si dostáhl. Že? Samozřejmě stahuje jen "novinky".

Na druhou stranu musí být schopen zpět do Exchange uložit všechno, co se u něho vytvořilo v průběhu doby, co byl odpojen od sítě. Na to tam přece právě máte ten offline mode.

Příklad - jste offline, vytvoříte si v Outlooku nový kontakt, a nějaký jiný si upravíte. Za hodinu se připojíte a Outlook tyto dvě modifikace nahraje zpět do Exchange. Jakmile aktualizace na nějaké položce proběhne, už nikdy se nedělá znovu. Proč taky, že? Takže položky, které už byly synchronizovány, se znovu nesynchronizují.

Co je "nové" se pozná podle nějakého celosystémového čítače, obvykle. V případě Active Directory se to nazývá universal serial number (USN). Jak se to jmenuje v Outlooku nevím.

Co se stane, když vy jednu stranu replikace natvrdo vrátít v čase zpět? Řekněme, že vrátíte zpět Exchange databázi o jeden den. Vrátíte zpět snapshot/checkpoint, nebo Hyper-V replica. Exchange se vrátí zpět, aniž by to sám věděl. Nebude mít tedy nějaké kontatky a maily, které jsou v OST souborech na klientech. Jenže Exchange neví, že byl vrácen zpět. Neví to ani Outlooky.

Znamená to, že položky, které byly synchronizovány v té "obnovovací díře" se už nikdy nebudou synchronizovat z Outlooku zpět do Exchange. V Exchange mailboxu budou tedy chybět buď úplně, nebo tam budou ve své starší verzi. To je mejhem! Každý Outlook bude nějak poškozen.

Jaký by byl rozdíl, kdybyste provedli skutečnou obnovu Exchange databáze? Provedli byste to za plného vědomí Exchange. Exchange by sám věděl, že byl vrácen o nějaký čas zpět. Tohle by řekl všem klientům. A všechny Outlooky by provedly násilnou re-synchronizaci všech položek, které byly změněny v oné "obnovovací díře".

To je důvod, proč Exchange nepodporuje obnovu ze snapshot/checkpoint/image/replica. To je důvod, proč to nepodpruje skoro nikdo. Kromě Active Directory na Windows 2012, pokud virtualizační platforma nabízí GenerationID. Ale já tomu stejně nevěřím. Je jednoduché to poškodit.

Vemte si jiný příklad WSUS a aktualizací na stanicích. Jak probíhá detekce? Myslíte, že Windows Update client pokaždé projíždí celý seznam všech nabídek? Nebo si stanice pamatuje co už všechno chtěla/nechtěla a znovu to nedetekuje? Můžete tedy ze snapshot/replica vrátit WSUS server? To já nevím.

Co vím, je že nikdy nevíte, dokud vám výrobce konkrétní aplikace nepotvrdí, že to umí. Tak jako to potvrzuje v případě Active Directory. Jak se chová DNS? Jak se chová DHCP replika? Jak se chová certifikační autorita a certifikátoví klienti? Vy to víte? A garantujete?

V ostatních případech musíte bezpodmínečně provádět korektní podporovanou aplikační obnovu ze skutečné aplikační zálohy. Takže i pro WSUS atd.

Nikdy nevíte.

To je stejné, jako když máte nějaký hardware mirroring na diskovém poli. Na to, aby to fungovalo korektně, musíte mít synchronní mirroring. Tzn. na druhém poli máte data synchronně mirorovaná ještě předtím, než pole dá vědět OS, že se data zapsala. To je drahé jako peklo.

Na co je tedy snapshot/checkpoint

Samozřejmě na pokusy. Pro obnovu to můžete také použít, jako startovní bod. Nahodíte snapshot BEZ SÍŤOVÉHO PŘIPOJENÍ a až to naběhne, provedete uvnitř korektní aplikační obnovu. Teprve potom můžete připojit do zbytku prostředí.

Na co je Hyper-V replika

Hyper-V replica může sloužit zase jako startovací bod pro manuální aplikační obnovu, stejně jako checkpoint. Na co je ale výborná je plánovaný failover (planned failover). Tedy přenos virtuálního počítače plánovaně na totálně jiný Hyper-V hostitel. Tady nenastává problém s vracením se k minulému stavu, ale plynule přecházíte z jednoho hostitele na druhého.

A samozřejmě na pokusy. Na to tam je právě ten "application consitent recovery point".

Hyper-V replika a application consistent recovery point

Co to je? Když se dělá replika, je to trošku divné. Replikuje se totiž jen storage. Tedy VHD a VHDX. Za jízdy virtuálního stroje. Pokud obnovíte nějakou repliku (tzn. neděláte planned failover), tak obnovujete vlastně stroj, který jste vytrhli z napájení. Tedy po tvrdém restartu.

V takovém případě vám nemusí už databázový systém (speciálně Exchange) naběhnout. Prostě vytrhnout Exchange, AD, nebo DHCP a certifikační autoritu, nebo i jen registry z napájení může být smrtící. Hyper-V replica umí tedy vyžádat, před odkopírováním, volume shadow copy (VSS), kdy se aplikace dozví, že bude vyrvána ze zásuvky a korektně se na to připraví.

Je tedy Hyper-V replica backup? Ne!!!

Znamená to, že pokud obnovíte starší obyčejný recovery point, tak nemusí vám ta virtuálka naběhnout vůbec. Zatímco když obnovíte starší application consistent recovery point, virtuálka vám zaručeně sama o sobě naběhne v pořádku. Ale do sítě to stejně pustit nemůžete, protože jste obnovili ve skutečnosti snapshot/checkpoint. Tak bacha!

Co z toho plyne?

Virtualizace sama vám nikdy v životě nemůže nabízet službu spolehlivého zálohování a obnovy. Obnovu musíte vždy provádět podle návodu výrobce každé jednotlivé aplikace, kterou provozujete! Musíte obvykle zálohovat "uvnitř virtuálního počítače" pomocí nějakého agenta a obnovit to opět uvnitř jedoucího a vědoucího virtuálního počítače a jeho aplikace.

srpen 12
Upgrade VMWare je svině, jak já říkám pořád

Zákazník má hostované serverové prostředí v cloudu. Pánové z obláčku to provozují na VMWare. Údajně dělali nějaký upgrade VMWare i jeho "hardware" nebo co. Těmhle VMWare kravinám já nerozumím a ani rozumět nechci. Protože už jsem po několikáté zažil, že ty jejich síťovky jsou šmejdy.

Oni totiž při upgrade hardware musí změnit to zařízení síťovky. Tedy změní jeho identifikaci ve Windows (asi PNP ID) a tím pádem se ta původní síťovka ztratí a objeví se nová. Nový hardware. Takže se na síťovce samozřejmě vytratí i IP konfigurace. VMWare Tools k tomu přistupuje bojovně a prostě se snaží to nějak ohekovat a konfiguraci přenést.

Akorát, že to dělá blbě.

Tentokrát se mu nepodařilo přenést nastavení DNS serverů na novou síťovku. To by si ještě dokázal opravit každý skoro na první pohled. Dobrá.

Ale to druhé, co to udělalo je děs. Z registrů to odstranilo hodnotu NV Domain z klíče HKLM\System\CurrentControlSet\Services\TcpIp\Parameters. To jsou kreténi!

Tahle hodnota obsahuje primary DNS suffix serveru. Tohle byl dokonce řadič domény (domain controller). Proč na to vůbec sahají? Bože. Speciálně na DC. Co myslíte, že se asi pak stalo, po restartu. Už ta doména nejela.

Naštěstí jsem neuvěřitelně dokonalej AD mástr, takže jsem na to přišel vcelku rychle. Ale tohle dělat? Prostě jako u kreténů. Co jiného můžete čekat od víjemvývaru? Navrhuju přejít bleskově na Hyper-V. Microsoft aspoň ví, co má a co nemá dělat ve svých Windows.

červenec 06
Vytvoření bootovacího Windows instalačního flash disku

Omlouvám se všem, že tady píšu zrovna tuhle tisíc let starou záležitost, ale dneska jsem to zrovna potřeboval a - světe div se - nenašel jsem to u sebe na webu, i když jsem si byl 100% jistej, že jsem to sem dával.

Takže pardon. Prostě to berte tak, že to tu musím mít taky:

Jak se naformátuje USB flash disk tak, abych na něho mohl nakopírovat instalační médium operačního systému Windows Vista, Windows 7, Windows 8, Windows 8.1 nebo třeba i Windows 2012 a Windows 2008 serverů?

Je to jednoduché, jenom musíte překonat problém, že normální flash klíčenka se netváří jako regulérní harddisk - tzn. nemá master boot sektor. To co dostanete, když si koupíte USB flešku, je v podstatě disketový formát - má to jenom boot sector. Normální harddisk, byť jen s jedním oddílem musí mít ale i master boot sector.

Takže postup je ten, že musíte váš flash disk vyčistit a pomocí nástroje diskpart na něm vytvořit správnou harddiskovou strukturu:

diskpart
list disk
select disk <cisloVasehoFlashDisku>
clean
create partition primary
select partition 1
active
format fs=ntfs quick label=osinstall
assign

Na teď už do toho jenom nakopírujete obsah instalačního ISO, nebo DVD média.

červenec 02
Aktuální šou ohledně Perfect Forward Secrecy (PFS) a TLS/SSL

Toto je přesně věc, kterou probíráme na kurzu GOC173 - Enteprise PKI v GOPASu!

V poslední době sleduju na různých místech výskyt různých článků o PFS (perfect forward secrecy, nebo i jenom FS - forward secrecy) v TLS/SSL protokolu (nadále tomu budu říkat pouze TLS, protože SSL už dneska používáte jen nějakých nekompatibilních případech). Vzhledem k tomu, že to je plné různých fám, podívejme se na to i my.

Autentizační a přenosové klíče

PFS je obecný kryptografický termín, který znamená v podstatě následující - velmi zjednodušeně. Řekněme, že komunikujeme zašifrovaně. K tomu nejspíš potřebujete dva šifrovací klíče. Jeden klíč bude autentizační (authentication key) a druhý bude přenosový (session key).

Autentizačním klíčem (klíči) (authentication keys) si obě strany přenosu vzájemně prokazují identitu. Přenosovým klíčem (session key) šifrují přenášená data. Přenosové klíče se budou nejspíš generovat nějak náhodně, obvykle opakovaně i v průběhu přenosu (re-keying), například po několika minutách, nebo po nějakém objemu přenesených dat. Zatímco ty autentizační budou asi mnohem trvalejší, protože obě strany je musí buď sdílet - v případě symetrických algoritmů, nebo jim musí věřit - v přípravě kryptografie asymetrické.

Pro TLS se používá jako autentizační klíč běžný serverový (server authentication) certifikát s veřejným klíčem (public key) a jemu odpovídající soukromý klíč (private key). Přenosové klíče se generují náhodně.

Jak jste asi zažili, vygenerovat si, nebo koupit certifikát není moc jednoduché a budete ho tedy používat poměrně dlouhou dobu, obvykle rok až dva (tak jak si přeje standard NIST algorithm advisory). Takže ten autentizační klíč bude opravdu na dlouhou dobu.

Tyto dva klíče ovšem budou mít nějakou vazbu - abychom svázali přenosový klíč s ověřením identity, tedy abychom autentizovali přenos přenosového klíč. Prakticky jsou dvě možnosti - buď děláte key exchange, nebo key agreement:

  • key exchange - znamená, že klient dostane od serveru jeho autentizační veřejný klíč jako součást certifikátu. Klient si vygeneruje (náhodně) přenosový klíč a zašifruje ho veřejným klíčem serveru. A takto chráněný ho pošle zpět na server. Server si to dešifruje svým privátním klíčem a oba tak znají přenosový klíč, kterým dále šifrují. TLS k tomuhle používá RSA key exchange algoritmy. Klíč se musí přenést tajně.
  • key agreement - to jsou modifikace Diffie-Hellman key agreement algoritmu. Při D-H se kousky přenosového klíče přenáší totálně nezašifrovaně. To by ale bylo náchylné na MITM (man in the middle) útok. Takže ty kousky přenosového klíče jsou podepsány soukromým klíčem serveru a naopak veřejným klíčem serveru při cestě z klienta. Ano, veřejným klíčem se skutečně spíše "šifruje" než "podepisuje", ale schválně tu píšu "podepisuje", protože nejde o tajný přenos, jako spíš o podpis - nehledě na to, že tyto dvě operace jsou technicky stejné.

Poznámka - RSA key exchange tedy šifruje přenosový klíč, zatímco D-H key agreement ten klíč jen podepisuje. Z toho taky plyne použití, které musíte mít v certifikátu - Key Usage - buď Key encipherment pro RSA key exchange, nebo Digital signature pro DH key agreement.

PFS - perfect forward secrecy

Pokud máme PFS, znamená to, že bezpečnost klíče přenosového nezávisí na bezpečnosti klíče autentizačního. Tedy šifrovací klíč pro přenos se musí generovat nezávisle na privátním klíči autentizačního certifikátu.

RSA šifruje přenosový klíč privátním, takže RSA nemá PFS. Zatímco DH a ECDH přenosový klíč pouze podepisuje, takže D-H a EC-DH naopak PFS mají. Detaily dále:

Bezpečnost v obou případech, jak key exchange, tak i key agreement, stojí na ochraně autentizačního klíče. Pokud ho má jen server bezpečně uložený, tak je všechno v pořádku. Od toho se to také jmenuje soukromý klíč (private key). Ale teď rozdíl.

Certifikáty mají přece nějakou platnost (time validity). Platnost certifikátu vyjadřuje, po jakou dobu musí vlastník klíče (subject) dbát o bezpečnost soukromého klíče v případě podpisu (digital signature) nebo key agreement (viz. i něco o časových razítkách). Jakmile platnost certifikátu skončí, můžete ho "politicky" vyhodit na internet, nebo nechat povalovat na flešce, spolu s privátním klíčem a nikdo vám nemůže nic říct. (To je stejné jako v případě občanky, neplatná občanka se může povalovat kde chce, už si na ni nic nepůjčíte, ani děcka ze školky nevyzvednete :-))

Pokud se jedná o šifrovací certifikát (key encipherment, data encipherment), tak byste tohle udělat neměli. Možná jsou ještě nějaká data zašifrována vaším veřejným klíčem a privátní (soukromý) klíč by to všechno dešifroval. Příklad jsou S/MIME maily, nebo EFS soubory.

A to je ten kámen úrazu. TLS je jenom přenosové šifrování. Přenosové klíče se používají jen chvilku a potom "z drátů zmizí". Jenže. Co když ten přenos někdo nachytal. A schoval si ho na lepší časy. Dokud je váš privátní klíč pro key exchange v bezpečí, dešifrovat se to nedá. Ale co když se vám ten klíč ztratí někdy později. Nebo se na něho vykašlete po vypršení jeho platnosti - byť byste to udělat neměli.

Pro NSA a jiné hackery může být mnohdy zajímavé prostě chytat zašifrované TLS a jenom si to někde uložit. A počkat si, jestli časem nedostaneme ten certifikát. Identifikace půjde udělat krásně automaticky. Jak agenti po světě zasílají nalezené privátní klíče, tak se v historii otevírají nevídaná data.

Pokud děláte key encipherment (tedy třeba právě TLS RSA key exchange, nebo i PPTP VPN), tak jste náchylní na tento druh útoku - nazval bych to "opožděná krádež klíče".

Naopak, pokud používáte key agreement (tedy u TLS D/H key agreement, nebo jeho eliptická obdoba ECDH key agreement), tak tohle nenastane. Přenášené části klíče jsou z podstaty veřejné. Podepisujete je privátním klíčem, tahle signatura se dá kdykoliv v budoucnu stejně ověřit veřejným klíčem, ale hlavně její zlá pozdější modifikace už nemá smysl.

TLS suites ve Windows a v internetu a PFS

TLS se domlouvá na šifrovacích algoritmech v okamžiku, kdy se začíná spojení se serverem. Klient pošle na server seznam algoritmů (s pořadím preference) - přesněji řečeno skupin (suite) algoritmů - které umí, a server si z nich jeden vybere a tím se domluví. Takže to vždycky stojí na schopnostech klienta a serveru, ale také na pořadí, v jakém jsou ty sujty posílány na server. V jakém jsou pořadí na klientovi!

Například Windows XP a jejich TLS knihovna Schannel ovládají pouze protokol TLS 1.0 a umí jen následující sujty v tomto výchozím pořadí:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

Jak si můžete všimnout, není tam ani jeden AES, není tam ani jedna SHA256 (SHA2 obecně), není tam žádný ECDH. Je tam sice DH algoritmus, ale jen v případě, že na serveru je DSS (DSA) certifikát. Normální web serverové certifikáty jsou RSA, nikoliv DSA. Takže můžeme říci, že z Windows XP klienta žádné PFS v TLS nemáte.

Windows Server 2003 přidal podporu AES šifrování. To je ale pro PFS totálně nepodstatné. Takže zase smůla:

TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA 

Až na Windows 7 a Windows 2008 (ano, je to i na Vista ale kdo tohle dneska má, že :-)) přišlo i do TLS 1.0ECDH: - stejná situace je i na Windows 8, Windows 8.1 a Windows 2012 i Windows 2012 R2:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5

Jsou tam dvě suitey ECDH+RSA, což je provozovatelné s běžnými web serverovými certifikáty (narozdíl od ECDH+ECDSA, protože eliptické ECDSA certifikáty nikdo nemá). Ale všimněte si, že nejsou na prvních místech. Klient tedy preferuje spíše klasický RSA key exchange který nemá PFS. Místo aby preferoval ECDH, kde je PFS samosebou.

Jak to pořešit? Museli byste buď na klientovi, nebo na serveru, vypnout ty hornější suity. Buď se to udělá v registrech, nebo přes Group Policy (GPO). Jenže se vystavujete nekompatibilitě. Co když to nějaký server, nebo klient, nebude umět, že?

Poznamejme ještě bokem, že TLS 1.0 ani na Windows 8.1 neumí SHA256 (obecně SHA-2) - opět to nemá co do činění s PFS, proto jen poznámečka kvůli kompletnosti. Takové sujty jsou až pro TLS 1.1 a TLS 1.2, které se také musí explicitně zapnout, a to i na Windows 2012 R2:

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_NULL_SHA  

Kde zjistím, jak je na tom můj server?

Pokud se váš server dívá do internetu, tak si ho můžete nechat otestovat z pohodlí domova například na adrese www.ssllabs.com. Stačí zadat adresu vašeho serveru. Nebo se můžete podívat, jak jsou na tom cizí web servery, jako například gmail, nebo microsoft.

Tak to je pro dnešek všechno, milé děti. Tak do hajan :-)

červen 27
Video z Ruska

Přednášel jsem na Microsoft MVP & Community ​Day v Moskvě. Pokud se někdo chce podívat video z přednášky What would a real hacker do to your Active Directory, v mé kostrbaté angličtině samozřejmě, tak může tady:

http://events.techdays.ru/MVP-CommunityDay/2014-06/cee

červen 23
Proč je složité obnovovat RID manager

Mimochodem, všechno se dozvíte osobně na kurzu GOC171 - Active Directory Troubleshooting, který přednáším v GOPASu!

Byla tady otázka ohledně problémů s obnovou RID manager FSMO. O RID manageru jsem tu už psal tady a tady a tady a vlastně i tady. Ale nevysvětloval jsem tenhle problém, tak tu to je. To stejné bude nastávat, pokud byste nesprávně provedli operaci seize této role, nebo pokud obnovíte virtualizační snapshot (tedy pokud se to náhodou nepovede dobře pomocí GenerationId).

Obecně by se dali FSMO role rozdělit na dvě skupiny, podle toho, jestli jsou "stavové", nebo "nestavové". Pod pojmeme stavový myslím, že má nějaká data, která si sám výlučně spravuje. Tím myslím to, ře třeba schema master FSMO má stav, protože má data ve schema partition, kam může zapisovat jen on.

Stavové FSMO jsou:

  •  schema master - ten má svoji schema partition (CN=Schema,CN=Configuration), do které jen on může dělat změny. Když tam ty změny udělá, výsledek se už normálně doreplikuje do ostatních řadičů domény (DC), ale tu změnu (originating update) může udělat jen schema FSMO.
  • domain naming master - tenhle má svůj kontejner CN=Partitions,CN=Configuration, do kterého si opět jen on může výlučně zapisovat. Změny se opět v pohodě poreplikují.
  • RID master - tady je to trošinku složitější, protože tenhle kamarád má svůj vlastní objekt CN=RID Manager$,CN=System, do kterého si zapisuje volný rozsah RIDů, které ještě žádnému DC nedal (atribut rIDAvailablePool). To je jeho vlastní objekt. Jenže s tím souvisí ještě objekty CN=RID Set, které najdete pod každým objektem DC. Tady si každé DC samo zapisuje, z jakého RID rozsahu zrovna přiděluje RIDy - atributy rIDAllocationPool, rIDPreviousAllocationPool a rIDNextRID. Detaily dále.

Nestavové FSMO a zvláštnosti jsou:

  • PDC master - tohle jenom procesuje změny hesla a zamykání účtů a změny hesel na trustech, je to taky časová autorita (možná to tak nemáte nastaveno) a provádí AdminSDHolder apod. Ani jedno z toho nepotřeuje nikde nic ukládat. Prostě se jenom na základě nějakých ponoukání spouští a něco provádí. Takže si nic nepamatuje.
  • Infrastructure master - tenhle taky jenom periodicky něco provádí nad celým svým databázovým kontextem a taky si tedy nemusí nic pamatovat. Navíc, pokud máte na všech DC zapnuty GC (global catalogue), nebo pokud máte zapnut Recycle Bin, tak tuhle roli stejně už ani nemáte.
  • Intersite topology generator (ISTG) - no sice to není úplně přesně řečené FSMO, ale taky je to role, kterou má jen jedno DC. V tomto případě jedno DC v každé AD sajtě. Zase nemá žádnou konfiguraci. Tedy má ji ve formě inter-site connection objektů, ale pokud to bude jakkoliv divně, tak si to stejně ISTG sám přegeneruje podle aktuální potřeby.

Obnova a operace seize může mít vliv jen v případě stavových FSMO. Nestavové lze obnovovat a přehazovat v podstatě bez ztráty kytičky. To nejhorší co se může stát, že ta role bude současně na dvou (a více) kamarádech. Prostě ty jejich akce nebudou dočasně chodit tak hladce, jak by bylo žádoucí.

Obnova řadiče jakéhokoliv řadiče domény (DC)

Představte si, že děláte prostě obnovu databáze o nějakou dobu zpět. Takže po obnově v ní něco nebude. Ukažme si to nejprve na příkladu třeba naming FSMO.

Obnova domain naming FSMO master

Domain naming FSMO obhospodařuje kontejner CN=Partitions,CN=Configuration. Kdykoliv chcete přidat další doménu, nebo application partition, tak musí tuto změnu provést nejprve domain naming master a z něho se ta změna taky nejprve musí pořádne poreplikovat, než to bude celkově fungovat.

Další doménu přidáváte jak často? Aplikační oddíly jsou potřeba pro DNS. Takže pokud přidáváte do nové domény na DC první DNS server, zase to musí udělat naming FSMO. A dělá to navíc nějaký člen Enterprise Admins. Takže to je vlastně jen málo častá, téměř vždycky ručně řízená operace - což pro nás znamená, že jsme schopni to hned potom zazálohovat, mimochodem.

Dobře. Co se může stát, pokud se vám domain naming master zhroutí chvilinku po provedení té přidávací akce? Jsou přesně jen dvě možnosti, ne? AD modifikace i replikace jsou transakční:

  1. změny, které jste na naming FSMO právě provedli, se prozatím nikam nezkopírovaly (nezreplikovaly). Takže jste o tuto celou operaci komplet přišli. Řešení je na snadě - buď obnovíte starou zálohu vašeho naming FSMO a prostě to provedete znovu (tohle máte vždy pod kontrolou, je to ruční akce, ty instalace domén). Nebo se na něho úplně vykašlete a seizenete ho natvrdo někam jinam. A provedete to znovu.
  2. změny, které jste na naming FSMO právě provedli, se už potvory stihly poreplikovat alespoň na nějakého dalšího kamaráda DC. Pohoda ne? Obvnovíte starou databázi, nebo to někam prostě jenom seizenete, ne? Bacha!

Co musíte udělat, pokud se to stihlo poreplikovat (tedy vždycky)

Bacha, pokud se to stihlo někam repliknout, nemůžete jenom tak obnovit zastaralou databázi na naming FSMO. Nemůžete ani jen tak někam seizenout naming FSMO. Stará databáze ze zálohy neví, že ta doména už existuje a mohlo by se stát, že hned po obnově proběhne znovu ta stejná operace a vznikne neřešitelná kolize.

Stejná situace je pokud byste jen tak někam seizeovali naming FSMO. Pokud ten nový master nemá ještě komplet repliku od všech! kamarádů, tak nemáte jistotu, že ví o všech existujících oddílech. A mohl by zase náhodou schválit nové přidání, i když by bylo kolizní.

Takže co musíte udělat když tam zrovna žádného daného FSMO nemáte? Před obnovou, nebo před operací seize všech masterů musíte poreplikovat celý obor - tzn. forest, případně doménu, pokud se jedná o RID managera. Výsledek před-replikace zjistíte jednoduše pomocí REPADMIN /REPLSUMMARY. Musíte tam prostě mít jen malinké časové rozdíly na všech DC.

Jenže pro RID master jen ta replikace nestačí

Tady je to horší. Máte například DC1, DC2, DC3 a DC4. Řekněme, že DC1 je RID master. Řekněme, že DC2 je vypnuté. Na DC3 se nějaký admin snaží vytvořit skupinu, nebo třeba uživatele, nebo připojit počítač do domény. Takže velmi častá operace, špatně kontrolovatelná a prováděná mnohdy totálně distribuovaně.

A DC3 nemá volný SID. Co se bude dít?

DC3 řekne DC1 RID o nový rozsah RIDů a dostane ho. RID master na DC1 si to zapíše do svého objektu RID Manager$. Příjemce rozsahu, DC3, si uloží do svého objektu (tedy do jiného objektu) RID Set hodnotu tohoto svého nového rozsahu. A za třetí, DC3 vytvoří nový bezpečnostní objekt s novým SID z tohoto rozsahu.

Ani jednou jsem neřekl slovo replikace. Protože k tomuhle žádná replikace není zapotřebí. Prostě jedna věc se stane na DC1, zatímco DC3 pracuje na jiných dvou objektech.

A teď vám spadne RID manager, tedy DC1. A vy ho chcete obnovit nebo seizenout.

I kdybyste replikovali jak zběsilí, tak jediné co poreplikujete je objekt RID Set z DC3, ve kterém je ten nejnovější rozsah, to ano. Taky zreplikujete ten nový bezpečnostní objekt s jeho novým SID. Jenže tohle RID managera vůbec nezajímá. RID manager se zajímá pouze a výhradně a exkluzivně o svůj objekt RID Manager$.

Problém je, že když ho vrátíte zpět, nebo provedete seize kamkoliv jinam, nemáte zaručeno, že tam bude aktuální RID Manager$ objekt. A to je ono.

Správné řešení obnovy a operace seize všech FSMO kromě RID manager

Prostě nejprve poreplikujte celý forest a potom to teprve obnovte, nebo proveďte seize.

Správné řešení obnovy a operace seize pro RID manager

Ano, samozřejmě proveď nejprve replikaci všeho, ideálně v celém forestu, a zkontrolujte to pomocí repadmin /replsummary.

A potom se zařiďte, aby nemohly vznikat žádné nové bezpečnostní objekty!!! Takže všem zakažte, aby cokoliv dělali, nebo si nechte běžet jenom jedno DC z dané domény a odpojte ho od sítě.

A podívejte se do všech objektů (opakuju pro všechna DC) RID Set a najděte tam ten největší rozsah (rIDAllocationPool). A potom opravte hodnotu v RID Manager$ (rIDAvailablePool, to je jiný atribut) tak, aby tam bylo cokoliv většího, než jste zjistili, ze všech těch DC objektů a jejich RID Setů.

MS lišácky doporučuje, abyste tam dali hodnotu o 100 000 vyšší. To je blbost. Tohle nic, ale vůbec nic nezaručuje. V krajním případě se těch 100 000 dá přečerpat pomocí sedmi DC, kterým zrovna náhodou došly RIDy.

Musíte udělat audit a dát tam hodnotu vyšší, než cokoliv v provozu.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
1.9.2014 18:09

Ubytování v Ostravě za 1400,- na 4 noci s kabelovým internetem 6 MB, vlastní pokoj velmi nově opravený a zařízený, s kuchyňkou a sociálkou. Panebože!!! To je skoro lepší se sem úplně přestěhovat!

 

22.8.2014 4:40
Dekuji vsem za prizpevky a komentare!
20.8.2014 12:37
Zda se, ze instalace DC 2012+ dela kontrolu ostatnich DC pomoci WMI
18.8.2014 20:13
Dneska alza reklama - dum a auto si zamykate, tak proc si nechranite pocitac antivirem?

Na to meje odpoved - protoze tam mam antivirus od MS, ktery funguje stejne jako zamek doma a od auta - neznici vam motor, nezpomalǔi vam auto trikrat a chaoticky neblika levym a pravym blinkrem a nebrzdi ve stopadesatce znicehoz nic
12.8.2014 10:09
dneska jedna zajímavost - tu u zákazníka zmizel na DC po výpadku proudu primární DNS suffix. Prostě to bylo najednou bez suffixu. Co se stalo ve skutečnosti je, že zmizel klíč z registrů - HKLM\System\CurrentControlSet\Services\TcpIp\Parameters, hodnota "NV Domain". Tak jsem to nastavil znovu ručně a už to funguje. Divnost nad divnost.

11.8.2014 12:01
je škoda, že nejde zvýšit karmu víckrát, než jenom jednou:
http://vetvicka.blog.idnes.cz/c/421436/Zastavte-Putina-dokud-je-cas.html
15.7.2014 20:07
Tak to jsem se musel fakt smat - http://www.dfens-cz.com/view.php?cisloclanku=2014071501 - "britove a francouzi take maji letadlovou lod" :-D
9.7.2014 16:19
Jak poznáte, že máte nainstalován Windows 2012 R2 "Update"? Spustíte MSINFO32 a v položce Hardware Abstraction Layer musí být hodnota alespoň 6.3.9600.17031.

8.7.2014 11:41
Aaa, tak jenom jsem se trošku unáhlil - na to, aby Network Monitor zobrazoval i pakety, které přicházejí do Destination virtuálního počítače ze Source počítače - je potřeba pro tu danou sledující síťovku zapnout P-Mode. To uděláte v Network Monitoru například v Capture Settings, nebo rovnou na Start Page je dole čudlík - pozor, pro každou síťovku zvlášť. Takže port mirroring v Hyper-V už není žádný problém ani s Network Monitor.
8.7.2014 11:35
tak zdá se, že Network Monitor od Microsoftu neumí zobrazovat pakety, které přijdou přes port mirroring v Hyper-V do Destination virtuálního počítače. Když jsem si nainstaloval Wireshark a WinPCap, tak úplně v pohodě. Jdu to prozkoumat ještě o trošku více, třeba se to dá někde v Network Monitoru zapnout.
6.7.2014 15:42
Tývolé, co to jéé: Internet Explorer has modified this page to help prevent cross-site scripting
5.7.2014 16:23
Hodni slovensti policiste mi naparili pouze 20Eur pokuty. Kluk a holka zrejme nemeli radar, pac jinak bych uz nejspis nejezdil :-)
5.7.2014 16:23
Cukrarna Dino ve Zline opet nezklamala svou uuuuuzasnou zmrzlinou!
24.6.2014 8:52
pokračování úspěšné série o dírách v SuperMicro - aneb dorazilo mailem:

vami uvedeny problem byl resen a vyresen jiz v lonskem roce novou verzi IPMI firmwaru. Viz. odkaz nize.
http://www.supermicro.com/support/faqs/faq.cfm?faq=16536

Upgradujte si prosim IPMI na posledni moznou verzi nejlepe na vsech vasich serverech.
23.6.2014 19:16
dorazilo poštou. přikládám v nepozměněné formě:

V Supermicro pracujou odborníci :)

Bezpečnostní tým CARI.net, zjistil, že IPMI/BMC - Supermicro základních desek obsahuje binární soubor, který ukládá přihlašovací hesla ve formátu prostého textu a je k dispozici ke stažení soubor pouhým připojením ke konkrétnímu portu 49152. Pokud je management dostupný z internetu, je možno tento soubor snadno získat "GET /PSBlock". Team provedl skenování a získal tak hesla k 32 tisícům serverů. Je dost zarážející, že je management u tolika serverů dostupný z internetu. A ještě víc zarážející je, kolik hesel bylo defaultních.
http://www.root.cz/clanky/postrehy-z-bezpecnosti-karty-supermikro-umoznuji-stahnout-hesla/

A já potvrzuju, že to fakt funguje, na heslo se prostě člověk podívá na adrese http://ip_adresa_IPMI:49152/PSBlock

23.6.2014 15:42
No musim teda rict, ze oproti vsem moskevskejm nadrazim, na kterejch sem byl a metro stanicim, tady v Brne na hlavnaku je me na zvraceni. A napriklad takova Beloruskaja je uplne atmosfericka.
23.6.2014 14:50
Čéééeeeeeééééeeeeéeeéééeskóóóóóóóó!
23.6.2014 11:46
Prave sme dosedli ve Vidni. Po ceste se krasne menila krajina - v Rusku sirokodaleko nic, v obcasne vesnicce hnedy silnice (no asfalt baby), stokilometrovy pruseky lesu neznamejch ucelu, obcas pouzity na draty. V Belorusku zmena pustiny na pustinu bazinatou. V nekolika mistech regulovany baziny. Vesnicky stejne jako v rusku z vrchu vypadaji jako smetaky. Na hranicni care s Polskem zmena jako prase - vsude policka, pekny organizovany nahusteny vesnicky, silnice sede (tzn asfalt), obcas hlinene pruseky v mistech kde se stavi dalnice, puda vyuzita a organizovana do posledniho metru. Slovensko nadherny vesnicky v kopcich, malinke, ale utulne, vsechny strechy barvy normalnich tasek a ne dosek porostlych mechem (tak to bylo uz v Polsku). Prelet do Raichu, vsude vetrniky, jak u blbejch :-)
23.6.2014 6:53
... ani prestavam si byt jisty, ze ten burgerking byl alespon neskodne prijatelna varianta. Ale tak snad to vyjde rychle a bezbokestne :-)
23.6.2014 6:53
Vnukovo letiste je parada. Ve dvou kavarnach maji prd ve forme dvou zakusku a sendvice, ze kteryho je me na pohled na bliti. A pak burgerking, coz na snidani neni nic, ale lepsi nez dratem do voka. Internet na pul hodiny a nejde me zmenit MAC adresa, sakra.
22.6.2014 22:23
Total mayham. Na mezinarodnim letisti nekdo neumi anglicky? Tak tady na Vnukovu nemluvi ani slovo anglicky ani borec na checkinu, ani jedna pani ve vobchode s vodou, ani dva borci na security ceku. Vcelku jsem se nedivil, ze to tak vypada ve 4* hotelu v Uglici, ale tady? Paneboze!
22.6.2014 19:10
Zase zpet v Moskve. V baru Help na veceri a pomalu odjezd na letiste.
22.6.2014 16:05
Tak uz jsme 2 hodiny na ceste busem dom. Vsude jenom lesy, louky, obcas dum, jinak prd. Nechapu. Pritom takova normalni krajina. Neobdelana pole, pripadne prolezla plevelem. Tak jeste udajne 2 hodiny do Moskvy, potom hodinu na letiste, potom tam budu sedet do 10 do zitra a pak konecne domu :-)
22.6.2014 16:03
... a Kaliacin ma navic delo. Na coz jsou pysni, protoze Uglic to nema.
22.6.2014 16:03
Zda se, ze kazda dedina obsahuje pruvodkyni, plus pokud tato neumi anglicky, ma s sebou prekladatelku. Kazda dura musi mit alespon dve legendy - o jmene jak vzniklo a potom jeste jednu, aby nebyla nuda.