Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
č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.

červen 18
Proč je forest security boundary a proč nelze oddělit Domain Admins z různých domén stejného forestu

Zase navazuji na něco, co jsem tu už před nějakou dobou nakousl. Jde o to, že celý forest je security boundary. Někdo totiž dělá společný forest a do něho samostatné domény proto, aby oddělil jednotlivé doménové administrátory.

Scénář je obvykle následující. Nadnárodní korporace konsoliduje národní prostředí do společného forestu. Takže někdo pak řeší otázku - jak nechat národní adminy, aby byli členem Domain Admins ve svých doménách. A měli u sebe také nějaká DC (řadiče domény).

Tím chtějí dosáhnout dvou věcí. Jednoduchá správa na straně národní domény a přitom "bezpečnost", aby se národní správci nedostali do ostatních domén.

Blbost. Když budou chtít, dostanou se tam v pohodě. Proč?

Každé DC z celého forestu si replikuje oddíl (partition) Active Directory, který se jmenuje Configuration (CN=Configuration). Každé DC má tuhle část u sebe. A každé DC do jeho celého obsahu umí a může zapisovat - to dál už umí jen skupina Enteprirse Admins z forest root domény. Tohle je zcela zásadní celoforestová konfigurace, kterou všechna DC berou jako autoritativní.

Jestliže do toho uděláme na jednom DC nějakou změnu, všechna DC si věří, takže si to taky poreplikují a podle toho se zařídí. V podstatě tedy stačí spustit nějakou vhodnou modifikaci pod účtem SYSTEM na nějakém DC a hotovo.

Co mě napadlo za vhodné modifikace

Například site linked group policy objects (site GPOs). Nebo přiinstalovat si vlastní NTAuth certifikační autoritu, která umí vydávat přihlašovací certifikáty. Nebo změnit obsah nějakého vhodného active directory property setu.

V podstatě by šlo modifikovat i schema. Prostě byste dočasně seizenuli Schema FSMO roli na svoje DC a pak to zase vrátili. A pak změna default security descriptor.

Ale podívejme se na příklad nejjednodušší - tedy site linked GPO

Scénář - máme subdoménu nazvanou italytraining.com (NetBIOS jméno je IT). Forest se jmenuje gopas.virtual (NetBIOS jméno GPS). Sice ten italytraining.com není subdoména podle jména, ale to je úplně jedno. Prostě je to další doména uvnitř společného forestu, který se jmenuje gopas.virtual.

Jsme správci italytraining.com a chceme se stát správcem libovolné jiné domény z forestu gopas.virtual.

Potom už postupujeme na ukázku podle obrázků níže:

  1. na jednom z našich sub-domain DC italytraining.com spustíme gpmc.msc pod účtem SYSTEM. Použijeme k tomu psexec.
  2. v konzoli vytvoříme nový GPO
  3. tento nový GPO nalinkujeme na správnou AD site. Nebudeme to připojovat na doménu, na naší doméně by nám to bylo na nic. Protože pracujete pod účtem SYSTEM, můžete to připojit na sajtu v pohodě. Jinak byste museli být členem Enterprise Admins a to zrovna právě nejsme.
  4. teď se to bude aplikovat na celou sajtu. Ještě to samozřejmě můžete omezit pomocí security filtering., aby se to nevstahovalo i na členské počítače, které jsou v té sajtě - tedy dáte tam jenom GPS\Domain Controllers.
  5. no a uvnitř objektu se použije už jen běžné Restricted Groups. Prostě tam nastavíte, aby skupina Administrators obsahovala vaši skupinu Domain Admins ze sub-domény italytraining.com. Nebo samozřejmě jakoukoliv jinou sadu uživatelů podle libosti. Zde bych jenom poznamenal, že pro skupinu Domain Admins to nefunguje, protože to je global skupina a nemůže obsahovat členy z jiných domén. Můžete tam dát jenom Administrators, nebo Enteprise Admins.
  6. až tuhle politiku zavede řadič z root domény gopas.virtual, prostě si nastaví obsah Administrators tak, jak chcete vy. Pěkné ne?

Závěr

Ano, tohle je jenom jeden demonstrační příklad, kterému lze jednoduše zabránit. Jenže takových příkladů může být v podstatě nekonečně. Princip je jasný. Jestliže každé DC replikuje něco (Configuration partition), co jiná DC mohou v pohodě změnit, není ochrana. I kdybyste zablokovali každý jednotlivý nápad, který někdo vymyslel, určitě vymyslí někdo další ještě něco jiného.

Oddělit domény lze pouze do samostatných forestů. Pokud to bude v jednom, má to prostě společného admina a hotovo.

červen 17
MVP Summit v Rusku

Všechny související pousty i fotky týkající se MVP summitu v Rusku, jehož se nadšeně účastním i jako přednášející, najdete zde:

červen 11
MVP Summit v Rusku

Od příštího úterý budu na MVP summitu v Rusku. Začíná to v Moskvě a pokračuje to celonoční cestou vlakem do Ribinsku. Už se těším. Bude to paráda. Prozatím jsem si koupil knížku v ruštině, abych si to trošku zopáknul. A taky jsem vyhledával, jak vypadá zásuvka.

No našel jsem toto: http://www.thinkgeek.com/images/products/zoom/vilcus_plug.jpg - pijoňér vyděržaj, akorát asi vyšší level pro vzrosteljší komsomolce.

Od příštího týdne zde začnou opět nabíhat reportážní fotografie a moje komenty.

Otázka - můžu používat BitLocker s TPM v Rusku?

To není špatná otázka. Nechat si rovnou na letišti zabavit noťas s prezentací, kvůli které tam v podstatě letíte, není úplně lahůdka. Tak jsem rovnou zaslal dotaz do MS Russia a dozvěděl se toto:

Do not worry about that.
It’s been restriction several years ago, now as far as I know it’s totally legal an you can bring it with no problem.

nebo: there never been any restrictions for personal use. if you have no plans to cross the border with a hundred of laptops for sale in your luggage you'll be fine

Tak snad to bude v pohodě :-) Pokud to v pohodě nebude, tak se tu už pak zřejmě žádné další pousty objevovat nebudou :-)

červen 10
Duplicitní SIDy

Ne, že by se vám to asi mělo stávat, ale je samozřejmě možné, že máte v Active Directory nějaké objekty s duplicitními SIDy. Stát se to může po nesprávně provedené obnově RID managera (RID master FSMO), nebo při jeho nesprávně provedeném násilném převodu pomocí seize operace.

Tu je skript, který vám vyhledá duplicitní SIDy v celém forestu. Neděste se, samozřejmě se tam budou vyskytovat nějaké výchozí zabudované, ale to není problém. Hlavně aby tam nebyly duplicitní žádné doménové SIDy.

$sidy = dsquery * forestRoot -filter "(objectSID=*)" -limit 0 -attr objectSID -uc | % { $_.Trim() } | sort

for ($i = 0; $i -lt ($sidy.Count - 1); $i ++) {

  if ($sidy[$i] -eq $sidy[$i + 1]) {

    write-host $sidy[$i]

    $sid = [System.Security.Principal.SecurityIdentifier] $sidy[$i]

    $sidBytes = New-Object byte[] $sid.BinaryLength
    $sid.GetBinaryForm($sidBytes, 0)

    $binSIDinStr = '\{0}' -f [BitConverter]::ToString($sidBytes).Replace('-', '\')

    $duplSids = dsquery * forestRoot -filter "(objectSID=$binSIDinStr)" -limit 0 -uc
    write-host ($duplSids | Out-String)
  }
}

Vyhlašuju soutěž, kdo najde skutečně duplicitní SID?

červen 05
Bába a telefon

Dneska jeden pro zasmání:

Maník je na turistice a okradou ho o peněženku, tak borec nemá už peníze na cestu domů. Snaží něco vyžebrat a zazvoní u jedné prehistorické babky, a že jestli by mu nedala nějaké peníze. A bába, že ne, že ale má novej mobil, takže jestli ho chce, že mu ho dá, pokud jí to třikrát udělá.

No maník se vzpouzí, nechce se mu, ale nakonec je mobil lepší než nic, to snad někde prodá.

Tak na to vlítnou, je to hnus, ale co se dá dělat.

Když je hotovo, tak jako že by chtěl ten mobil.

A bába na to: "tak si piš, ogare: 602 ..."

červen 04
RDP restricted admin režim, (ne)vykrádání hesel a Kerberos ověření

Předevčírem jsem dostal komentář k článku o vykrádání hesel z paměti (neboli pass-the-hash a pass-the-password). Je to velmi zajímavá novinka, takže samostatný článeček k tomuto tématu. Komentář upozorňuje na novou, Windows 2012 R2 a Windows 8.1 funkci RDP klienta a RDP serveru, nazvanou Restricted Admin.

Nejprve bych chtěl říct, že to je zrovna krásná metoda, jak omezit přenos plain-textových hesel z MSTSC klienta do RDP serveru.

Celé to vyžaduje jen spustit MSTSC klienta s parametrem /RestrictedAdmin:

mstsc /restrictedadmin

Když to uděláte, objeví se vám normální okno klienta. Změna je ale vidět hned, jak zadáte jméno nějakého RDP serveru. Políčko User name zešedne a dole pod ním se objeví hláška Your Windows logon credentials will be used to connect. To je stejný projev, jako když máte zapnut RDP SSO (single-sign-on) pomocí Credentials Delegation - Allow Delegating Default Credentials.

Jak v případě credentials delegation, tak i v případě restricted admin režimu, to vyžaduje nejprve Kerberos vzájmené před-ověření (authentication) jak MSTSC klienta tak i vzdáleného RDP serveru. Po připojení se vám to projeví ikonkou zámečku v horní liště a nápisem The identity of the remote computer was verified by using Kerberos.

Jenže při credentials delegation tam klient posílá plaint-text heslo. Zatímco při restricted admin režimu tam neposílá v podstatě nic. Tedy posílá tam jen TGS tiket pro ten terminálový server (tedy SPN - service principal name - TERMSRV).

Jestliže tam posíláte jen TGS tiket, tak tam vlastně neposíláte nic jiného, než normálně předáváte na vzdálený server při přístupu do sdíleného adresáře (SMB), do SQL serveru, do Exchange serveru, nebo přes HTTP do SharePoint. Jen mu bezpečně (mutual authentication, AES) prokazujete svoji identitu.

Cílový server tak nebude mít nic v paměti, co by šlo vykrást. Na druhé straně tam taky nemá nic, s čím byste mohli chodit dále po síti. Znamená to, že pracovat můžete jen lokálně na tom RDP serveru, můžete lokálně přistupovat na jeho vlastní síťové služby, ale to je všechno. Do sítě se už dál nedostanete. To by musel mít ten RDP server povolenu Kerberos delegaci - a musím ještě vyzkoušet, jestli to s ní vůbec funguje.

Tedy dostanete, pokud se vás to zeptá na login a heslo.

Dobrý ne? Takže suprovní ochrana hesla. Pokud tedy nepoužíváte čipovou kartu. Stejně na tom vzdáleném počítači chcete jen něco upravit a do sítě nejspíš ani moc chodit nepotřebujete. Hlavně se tam neposílá plné heslo. Pokud nevíte, kdo je tam lokálním adminem, tak mu takhle nic nedáváte od ruky.

červen 03
Poznámky k přednášce o zvládání SharePoint bestie

V pátek jsem měl v GOPASu přednášku o zvládání SharePoint bestie. Slíbil jsem poznámky uveřejnit, tak to činím teď:

  • rozjeďte si TLS připojení mezi SharePoint a SQL serverem. Detaily k nalezení zde a zde.
  • až budete dělat SQL alias pomocí CLICONFG nástroje, nezapomeňte ho udělat ten stejný ještě pro 32bitové registry. Musíte spustit ten stejný program, ale z adresáře %windir%\SysWow64\cliconfg.exe.
  • protože SharePoint 2010 doporučuje a SharePoint 2013 vyžaduje mít na SQL serveru nastaveno Max Degree of Paralelism na hodnotu 1, já zase doporučuju mít na to vyhrazenou SQL instanci. Více SQL instancí nic nestojí.
  • farm account (v mém případě to byl sp-farm) - tedy účet, pod kterým běží SharePoint Timer Service nebo centrální administrace (central administration) - udělejte klidně členem lokální skupiny Administrators, tedy pokud ho pořádně oddělíte a používáte ho opravdu jen na běh těch služeb, které to potřebují. Jinak skript na přípravu SharePoint farmy najdete zde.
  • heslo libovolného servisního účtu, ať už heslo služby, nebo heslo aplikačního fondu (app pool) z IIS, dostanete podle článku zde.
  • udělejte si instalační adresář, do kterého si dávejte postupně všechny instalačky, jazykové balíčky, aktualizace i úpravy web.config souborů, které postupně za roky děláte. Bude se vám to jednou hodit, až budete muset nějaký server přeinstalovat, nebo budete chtít další přidat.
  • nesahejte na certifikátový binding v IIS na sajtě SharePoint Web Services. Je tam ve skutečnosti přihozený certifikát, který ale není přes IIS konzoli vidět. Zobrazit si ho můžete pomocí NETSH HTTP SHOW SSLCERT.
  • na členech SharePoint usedlosti si vypněte automatickou aktualizaci trusted root certification authorities. SharePoint používá vlastní vnitřní certifikační autoritu, kterou samozřejmě aktualizace nestáhne. A zrychlíte tím některé okamžiky při startování. Jedná se o položku v Group Policy, v oblasti Administrative Templates, nazvanou Turn off Automatic Root Certificate Update.
  • pokud chcete SSO - single sign on - tedy aby vás klient neotravoval s opakovaným zadáváním hesla, vydám na to v brzku (zřejmě dnes v noci) oddělený článek. Obecně, hlavně chcete zapnout Kerberos, bez toho se neobejdete.
  • pokud zapínáte Kerberos, vřele doporučuju v DNS dělat A záznamy a nikoliv CNAME. Vyhnete se různým podivnostme při přístupu z různých verzí klientů.
  • zahřívací skript na SharePoint usedlost najdete zde.
  • změny IIS binding je ideální dělat tak, že přes centrální správu dáte Remove SharePoint from IIS web site a znovu proveďte Extend. Klidně můžete odstarnit i Default zónu a znovu ji vytvořit. To se vám nic nestane. Jen počítejte s tím, že se vám ztratí web.config. Jestli jste do něho dělali nějaké ruční úpravy, musíte je zopakovat. To je právě ta rada s tím distribučním adresářem.

Děkuji za pozornost.

červen 03
Prezentace k mým specializovaným kurzům v GOPASu

Slajdy ve formě PDF pro prohlížení i XPS pro tisk jsou všechny ke stažení ve složkách zde. Nebo přímo podle následujícího seznamu. Jejich aktualizaci dělám automatickým skriptem, takže cokoliv tam nového přidám, v brzku se to tam nejspíš objeví:

 

Všechny tyto kurzy můžete navštívit v GOPASu.

květen 29
Export PowerPoint prezentace z PPTX do PDF a XPS pomocí PowerShell

Mám dost prezentací a nechce se mi to pokaždé ručně exportovat. Tak jsem si na to napsal scriptík, který vyexportuje PPTX prezentaci do PDF souboru. Druhý skript vytiskne PPTX do XPS. Nemyslím, že to potřebuje další komenty, pokud si to chcete upravit, všechno ostatní už vygůglujete podle toho zdrojáku.

Podstatné na tom kódu jsou různé hodnoty a typy, které se hůře hledají a, metoda volání COM pomocí psobject.BaseObject a uklízení paměti pomocí ReleaseComObject().

function Save-PptAs ([string] $pptFile, [string] $saveAs)
{
  $ppt = New-Object -ComObject PowerPoint.Application 

  # FileName, ReadOnly, Untitled, WithWindow
  $withWindow = [Microsoft.Office.Core.MsoTriState]::msoFalse
  $slideDeck = $ppt.Presentations.Open($pptFile, [Microsoft.Office.Core.MsoTriState]::msoTrue, [Microsoft.Office.Core.MsoTriState]::msoTrue, $withWindow)

  Add-Type -AssemblyName Microsoft.Office.Interop.PowerPoint
  $saveOptions = [Microsoft.Office.Interop.PowerPoint.PpSaveAsFileType]::"ppSaveAs$saveAs"

  $outFile = [System.IO.Path]::ChangeExtension($pptFile, $saveAs.ToLower())
  if (Test-Path $outFile) { Remove-Item $outFile -Force }
  $slideDeck.SaveAs($outFile, $saveOptions)


  $slideDeck.Close()
  [void] [System.Runtime.Interopservices.Marshal]::ReleaseComObject($slideDeck)

  $ppt.Quit()
  [void] [System.Runtime.Interopservices.Marshal]::ReleaseComObject($ppt)
}

 

function Print-PptAsXPS ([string] $pptFile, [string] $printAs, [string] $printHow)
{
  $ppt = New-Object -ComObject PowerPoint.Application 

  # FileName, ReadOnly, Untitled, WithWindow
  $withWindow = [Microsoft.Office.Core.MsoTriState]::msoFalse
  $slideDeck = $ppt.Presentations.Open($pptFile, [Microsoft.Office.Core.MsoTriState]::msoTrue, [Microsoft.Office.Core.MsoTriState]::msoTrue, $withWindow)


  Add-Type -AssemblyName Microsoft.Office.Interop.PowerPoint
  $slideDeck.PrintOptions.OutputType = [Microsoft.Office.Interop.PowerPoint.PpPrintOutputType]::"ppPrintOutput$printAs"
  
  Add-Type -AssemblyName Office
  $slideDeck.PrintOptions.FitToPage = [Microsoft.Office.Core.MsoTriState]::msoTrue
  
  $slideDeck.PrintOptions.HighQuality = [Microsoft.Office.Core.MsoTriState]::msoTrue
  $slideDeck.PrintOptions.NumberOfCopies = 1
  $slideDeck.PrintOptions.RangeType = [Microsoft.Office.Interop.PowerPoint.PpPrintRangeType]::ppPrintAll
  $slideDeck.PrintOptions.ActivePrinter = "Microsoft XPS Document Writer";
  
  # we must do it synchronously in order to wait before .Close() and .Quit()
  $slideDeck.PrintOptions.PrintInBackground = [Microsoft.Office.Core.MsoTriState]::msoFalse
  $slideDeck.PrintOptions.FrameSlides = [Microsoft.Office.Core.MsoTriState]::msoTrue
  $slideDeck.PrintOptions.PrintColorType = [Microsoft.Office.Interop.PowerPoint.PpPrintColorType]::"ppPrint$printHow"


  $outFile = [System.IO.Path]::ChangeExtension($pptFile, 'xps')
  if (Test-Path $outFile) { Remove-Item $outFile -Force }

  [System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo] 'en-US'

  [string[]] $paramNames = @('PrintToFile', 'Collate')
  [object[]] $paramValues = @($outFile, [Microsoft.Office.Core.MsoTriState]::msoTrue)
  [void] $slideDeck.psobject.BaseObject.GetType().InvokeMember(
    'PrintOut', 
    [Reflection.BindingFlags]::InvokeMethod, 
    $null, 
    $slideDeck.psobject.BaseObject, 
    $paramValues, 
    $null, # ParameterModifiers
    ([System.Globalization.CultureInfo] 'en-US'), 
    $paramNames
    )

  $slideDeck.Close()
  [void] [System.Runtime.Interopservices.Marshal]::ReleaseComObject($slideDeck)

  $ppt.Quit()
  [void] [System.Runtime.Interopservices.Marshal]::ReleaseComObject($ppt)
}

Tak užívejte :-)

květen 29
Zajímavý scénář nasazení PXE a Windows imidž

Čtenář se mě ptal, jestli mu poradím s takovým speciálním PXE scénářem - a je to jistě zajímavé, tak to tu uvádím, protože je škoda, aby to skončilo schované v mém mailboxu. Kdybyste někdo chtěli jeho kontakt, klidně a rád mu vaše dotazy přepošlu:

Mam taku mozno specificku poziadavku - snazim sa rozbehat PXE doma na konfiguracii:
Synology NAS - PXE/TFTP
Linksys E2000 router - DHCP
Neriesim teraz konfiguraciu ako povedat DHCPcku kde je PXE a pod - k tomu myslim mam informacie postacujuce (bezi mi tam dd wrt). Otazka je ohladom vytvorenia image OS, pricom tento som chcel vytvorit pomocou win technologie.
Image sa pokusam spravit z win 2008 R2 kde mam nainstalovany WDS. Akurat ze WDS mi vytvori RemoteInstall folder na localhoste (alebo mozno aj na inom PC v domene, co ale nie je moj pripad lebo doma efektivne domenu nevyuzivam).
Preto by som sa chcel spytat ci je mozne a funkcne veci vytvorene vo WDS na lokale nasledne premigrovat na Synology share (manualne copy/paste?)
Co sa tyka Deployment Bench tam mozem vytvorit Deployment Share priamo na zdielany priecinok na mojom Syno NASe.

Neporadil jsem mu :-)

Ale vyřešil si to sám a tu je jeho vlastní odpověď sama sobě:

Pohral som sa s tym a funguje to v domacom prostredi v kombinacii Synology NAS a router (DHCP). Pricom win image su vytvarane Deployment Benchom na sharovany folder na NASe (+ ine softy ako Hirens, recovery disk, ubuntu live su nakopirovane povacsine vo formate ISO v rovnakom share foldri a vytvoreny zaznam v pxelinux.cfg default subore ktory robi menu pri PXE bootovani).

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
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.
22.6.2014 16:03
Akorat ty sedacky jsou trosku prosezeny, prave jsem si vrazil trubku do zadku
22.6.2014 16:03
Kdyz sme odjizdeli z Ugliče, nakonec to nebylo spatne mesto :-) ale hlavne zrovna letime po volze v Rakete, naprosto uzasna rychlolod co lita po vode. Skoro to nedela vlny a prakticky se to nehne. Zradlo. Takze aji kolegove emvipi co se do rana nalivali jamesonem nemaji zaludecni potize :-)
22.6.2014 16:03
Toaletě rabotajet
21.6.2014 18:43
Zbytek Ugliče - kostel kde zabili syna Ivana Hrozneho. Plus velikej "turist paradise". Nakoupil jsem dary, takze vsechno je splneno.
21.6.2014 18:39
Prohlidka mesta - v podstate tu neni nic. Maji vodni elektrarnu, u ktere je muzeum. Puvodne se rozmysleli, jestli vubec otevrit to muzeum uplne pro verejnost, nebo jenom pro inzenyry s bumazkou, nakonec ustoupili ze svych principu a je to pro vsechny. Ale do elektrarny se nejde, protoze je to strategicky objekt.
21.6.2014 11:20
Cesta z Ribinsku do Ugliče přinesla několik poznání. Zaprve nechapu jejich "vesnie". Vzdycky to ceduli s nazvem, ale jsou to treba tri domky. Zadny namesti, obchod, nic. nekdy obchod ve forme boudy u cesty. Potom opet par kilometru lesy a pak zase to stejny. Ve vesnicich nejsou asfaltky, takze maximalne tak ta prujezdna na hlavni silnici. Rikam maximalne, protoze dvakrat byla ta hlavni silnice normalne z kamenu a pisku.

Vsechny domky ze dreva. 50% v rozpadu, ale zda se ze obydlenych. Pri tom obrovskym mnozstvi lesu okolo nechapu proc si to neopravi. Zrejme to jsou ajtaci. Taky nemam doma na nic cas :-)