MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Porovnanie freeIPA a MS Windows Active Directory

DIPLOMOVÁ PRÁCA Lukáš Jakubík

Brno, 2015 Mojím rodičom.

2 Prehlásenie

Prehlasujem, že táto diplomová práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.

V Brne 25. mája 2015 Lukáš Jakubík

Poďakovanie

Týmto chcem poďakovať dr. Zdeňkovi Říhovi, za jeho bezprostredný prístup, že všetko sa dá, len treba chcieť. Za jeho rady k tejto práci, za jeho pôsobenie na fakulte.

3 Anotácia

V práci sa venujeme riešeniu identifikácie a správy užívateľov založenom na Active Directory v prostredí Windows. Porovnávame ho s možnosťami, ktoré poskytuje freeIPA v linuxových doménách. Oba systémy vysvetľujeme do úrovně komponentov, skúšame niekoľko konfiguračných scenárov pri ich nasadení vo virtualizovanom prostredí a o tomto podávame správu v závere.

Annotation

This thesis is devoted to the identification and central management of users basedon Active Directory in Windows environments. We compare it with the solution provided in freeIPA Linux domains. Both we explain to the component level, we try several configuration scenarios for their deployment in a virtualized environment and thatwe report at the end.

Kľúčové slová Keywords

Cenral Management, Active Directory, freeIPA, Windows Server 2012, RHEL, VirtualBox

4 Obsah

1 Úvod...... 7 2 Centralizovaná správa...... 8 2.1 Identifikácia...... 8 2.2 Centralizácia...... 9 2.3 Sieťové prostredie...... 9 2.3.1 Klient...... 9 2.3.2 Server...... 10 3 Active Directory...... 11 3.1 Správa Active Directory...... 13 3.1.1 Účty užívateľov v doméne...... 13 3.1.2 Security Identifier...... 14 3.1.3 Užívateľské oprávnenia a skupiny...... 16 3.1.4 Access Token...... 17 3.1.5 Účty počítačov v doméne...... 18 3.1.6 Ochranné mechanizmy...... 19 3.2 Technológie v AD...... 22 3.2.1 Hlavné komponenty...... 22 3.2.2 Doménové role serveru...... 24 3.2.3 Autentifikácia užívateľov...... 25 3.2.4 Autentifikácia stanice...... 25 3.2.5 Politiky...... 27 3.2.6 Audit...... 28 3.3 Windows Server...... 30 3.3.1 Standard vs. Datacenter...... 30 3.3.2 Licenčná politika...... 31 3.3.3 Vlastnosti Windows Server 2012...... 31 3.3.4 Windows Power Shell...... 32 4 freeIPA...... 34 4.1 Správa linuxového prostredia...... 35 4.1.1 Užívatelia a skupiny...... 35 4.1.2 Pluggable Authentication Modules...... 37 4.2 Technológie freeIPA...... 38 4.2.1 Vízia Identity Managementu...... 38 4.2.2 Hlavné komponenty...... 39 4.3 RHEL, Fedora a ďalší...... 40 4.3.1 Red Hat Subscriptions Model...... 41 4.3.2 Education level subscription...... 42 4.3.3 Shell...... 42

5 5 Porovnania...... 43 5.1 Scenár – Doménové prostredie...... 43 5.1.1 Poznámka k sieti...... 43 5.1.2 Virtuálne prostredie...... 44 5.1.3 Active Directory...... 44 5.1.4 freeIPA...... 45 5.2 Scenár – Noví užívatelia a bezpečnosť...... 47 5.2.1 Noví užívatelia...... 47 5.2.2 Doménový správca v bezpečí...... 48 5.3 Scenár – Homogénne prostredie...... 49 5.3.1 Active Directory...... 49 5.3.2 Windows Server 2012 Core...... 50 5.3.3 Windows 8 ako správca...... 50 5.3.4 freeIPA...... 51 6 Budúci vývoj...... 52 6.1 Azure Active Directory...... 52 7 Záver...... 54 8 Literatúra...... 55

6 1 Úvod

Najskôr krátky príbeh zo sveta ľudí, aby sme postupne ukázali, nakoľko sa otázkam zoznámenia, identifikácie, požičiavaniu si vecí a prístupu k nim podobáme s neskôr uvedenými pojmami v sieťovom prostredí počítačov s centralizovanou správou objektov – v svete domén Active Directory a freeIPA. Vedieť o niekom ako sa volá, že sa nám predstavil, považujeme za priateľské, blízke, vlastne pomerne bezpečné. Poznať jeho identitu, rodinu, prácu, funkciu, určitý spolo- čenský kontext, a to jeho meno... patrí k základným ľudským socializačným prejavom, potrebám. Túto znalosť uplatňujeme pri každom ďalšom stretnutí s ním, našu známosť upevňujeme. Čím viac informácii o človeku máme, tým viac si ho pamätáme, dokonca si vieme chýbajúce údaje odvodiť zo znalosti iných, alebo nám pomôžu jeho kamaráti. A to už len svojou existenciou. Veľmi podobné rozlišovacie schopnosti uplatňujeme aj v našich veciach, pri obyčajných predmetoch. Zdieľame počítače, požičiavame si kolobežky, bicykle či autá, avšak ako majitelia chceme mať vo veciach prehľad, kde sa nachádzajú, komu boli zapožičané, prečo, odkedy a do kedy. Poučili sme zákazníka/zamestnanca o povinnostiach a pravidlách používania, či vynútili sme si ich vehementne?!

A takto môžeme na úvod chápať aj potreby vo svete počítačov – vo svete, kde máme postavenie užívateľa. Máme svoj účet, namiesto firemnej pozície sú to oprávnenia, namiesto kolobežiek si požičiavame na dopoludnie počítače, zdieľame súbory. Pohľad správy vecí jedného užívateľa nie je nijak prekvapujúci, mávneme nad ním rukou, ale dokážeme si predstaviť ovládať pár klikmi celé oddelenia zamestnancov, všetkým naraz zakázať prístup k Internetu, k zmenám akýchkoľvek nastavení v počítači, či zakázať počítače?! A čo vtedy, ak na niektoré môžu, na iné zas nie, a my si chceme všetko evidovať, mať vo veciach našej správy prehľad. Hovoríme o centralizovaných službách vo svete veľkých sietí, domén. V tejto práci popisujeme dva systémy na centralizovanú správu – Active Directory od Microsoftu a z druhej mladý projekt s názvom freeIPA od Red Hatu. Že ide o rozdielne svety je už na pohľad jasné, skúsime ukázať, v čom sú si podobné, v čom zas až tak nie. Budeme ich porovnávať snáď priebežne, snáď k pochopeniu dostatočne. V práci sa často vyskytujú dôležité pojmy k zapamätaniu a taktiež pôvodné anglické termíny, pri prvom výskyte sú písané kurzívou, zavedené skratky v zátvorkách niekoľko krát opakujeme – nech je to jednotiaca snaha nevnucovať nepoužívané preklady. Práca je priebežne písaná s ohľadom na štúdijný obor bezpečnosti IT, takýto typ poznámok nám v jej priebehu prišiel ako vhodný, k zamysleniu i pre odborníka.

7 2 Centralizovaná správa

V tejto kapitole sa snažíme priblížiť širší kontext, prečo sa máme zaoberať centrali- zovanou správou užívateľov a ich zariadení v počítačovej sieti. Takúto správu chápeme ako starostlivosť, administráciu zverených prostriedkov a chceme ju robiť z centrály – miesta, v ktorom sa sústreďuje a odkiaľ sa riadi a koordinuje všetka dôležitá činnosť [Buzássyová, Jarošová (ed.), 2006]. Táto diplomová práca sa venuje doméne, ktorá nie sú nič iné ako panstvo, domínium, ovládané územie, rozhodujúca oblasť pôsobenia [Buzássyová, Jarošová (ed.), 2006]. Na panstvách žili poddaní, ovládaní nevoľníci, ktorí sa raz za čas mali ukázať pánovi a zaplatiť dane. Možno že im náležali nejaké práva, nejaké majetky. Páni si s nimi robili, čo si zaumienili, určovali ich práva, existenciu. V priebehu histórie sme sa vývojom dostali až demokracii, kde svoje práva uplatňujeme vehementnejšie a jednoznačne tak, ako sú pravidla napísané v zákonníkoch, ako ich vyžadujú pravidlá etiky.

2.1 Identifikácia Vo svete IT je analógia s príbehom z úvodu práce až prekvapivo zarážajúca! Užívatelia počítačov sa ovplyvňujú, interferujú, snažia sa niekam hlásiť, niekam dostať, dávajú o sebe vedieť, niečoho sa domôcť. Na identifikáciu nepoužívajú až tak svoje meno akov medziľudských vzťahoch, nemali by, skôr svoj pseudonym. Aby sme boli unikátni, nútia nás servery použiť našu emailovú adresu, tým sa pohodlne zbavujú problému nás od seba odlíšiť, ak by sme sa náhodou volali rovnako s niekým iným. Z adresy sa stal identifikátor. Zároveň ňou samotnou vyjadrujeme kam a ku ktorému neobmedzenému, či firemnému mailboxu patríme. Za istých okolností je z tejto identity jasné s kým sa kamarátime, s kým máme styky, kam organizačne patríme. Pokiaľ si k identite pridáme login, ktorý nemusí byť nutne ten istý a znalosť tajného hesla, tak tam, kde sme už boli sa nám dvere otvárajú, služby sprístupňujú, v informatike to nazývame autentifikáciou a získanie práv nás k iným činnostiam autorizuje. Čoraz častejšie sa stretávame aj s delegovaním identít, že už máme identitu overenú niekde inde a tým pádom aj tuná. Vlastníme počítače a iné zariadenia, chodíme do školy, do práce, kde nachádzame množstvo ďalší zdrojov k použitiu, či k práci, ale predsa nielen my, ale aj naši kolegovia, súrodenci, známi. A to sme už na konci predošlého príbehu. Že počítačový svet, v ktorom sa pohybujeme, tvorí isté ovládané územie miestnym správcom je nepochybné. Môže nám prideliť, či ubrať zdroje, z ľubovôle alebo podľa firemnej politiky nás spraviť mocnými, či zamknutými.

8 Na príbehoch sme kurzívou naznačili niekoľko dôležitých pojmov, ktoré sú akýmsi východzím odrazovým mostíkom k pochopeniu centrálnej správy a k doménovým službám.

2.2 Centralizácia Centralizovanú správu môžme charakterizovať ako: • zjednodušenie administrácie systému ako celku, tak aj jeho častí, objektov, • znižuje časovú náročnosť, pretože niektoré činnosti dokáže zoskupovať, opakovať, • sprehľadňuje organizáciu objektov, dokáže ich organizovať, pomenovať, • môže poskytovať identifikáciu objektov, ktoré spravuje ďalším službám, • vzhľadom na spravované informácie o objektoch, by ich mohla autentifikovať.

V tejto práci hovoríme veľmi často o doménach, doménovom prostredí, myslíme tým najčastejšie sieťové prostredie s centrálnou správou, ktoré je niekým kontrolované po technickej (controller) aj ľudskej stránke (správca). Objekty domén sú evidované, organi- zované.

2.3 Sieťové prostredie Dnes sa už záujem užívateľov nesústredí toľko na lokálne počítače, na vlastné programy, netrápi nás toľko vlastné hardvérové vybavenie nášho stroja, pokiaľ slúži, potrebujeme hlavne k prístup k sieti, k sieťovým službám. V takomto prostredí je náš počítač len klientom, zákazníkom a pripája sa k serverom, poskytovateľom zábavy, práce, dát. Od pracovného prostredia očakávame istú jednotnosť nastavení, možnosť si sadnúť kamkoľvek a pracovať rovnako výkonne. Pokiaľ už ani nehovoríme: „to je môj počítač, moje miesto“, nachádzame sa v Temporary Place, politike dočasných miest vo firmách, známej zo škôl – prídeš, sadneš, odpracuješ, odídeš, zajtra zasa sadneš inam. V takomto aktívnom pracovnom a sieťovom prostredí je centrálna správa užívateľov a týchto počítačov nanajvýš potrebná. Prečo? Aby sa dosiahol dlhodobo udržateľný stav, v ktorom budú nastavenia rovnaké, spravované, aby bol spokojný aj užívateľ, aj správca to množstvo strojov a ľudí bol schopný administrovať.

2.3.1 Klient V prípade nasadenia klientov so zámerom podporiť migráciu užívateľov, teda že užívateľ získava rovnaké služby počítačovej siete bez ohľadu na aktuálne vybranú stanicu, je vhodné zvážiť istú unifikáciu tohto hardvérového vybavenia. Táto voľba zároveň zjed- nodušuje úvodnú prípravu a následnú správu klienta, jedného z mnohých, pretože rovnaký hardvér by mal javiť rovnaké vlastnosti v celej sieti. Dochádza tak k zefektívneniu riešenia problémových situácií v správe sietí. Sekundárne unifikácia zrýchľuje a skrýva pohyb, výmenu uzlov v sieti bez vedomia užívateľov a služby sieťou poskytované sa stávajú doslovne službami. Uzol musí byť teda hlavne schopný pripojiť sa do počítačovej siete danej architektúry a poskytnúť priestor na prácu užívateľa.

9 Zvažujeme tiež možnosť virtuálizácie programového vybavenia, aj klientský operačný systém môže bežať vzdialene na výkonnom serveri a k lokálnej stanici doputujú len obrazové informácie, preberajú sa z nej ovládacie pokyny užívateľa. Nepochybne môže byť klientom v sieťovom prostredí aj iné zariadenie ako počítač, od mobilov po tablety. Takéto zariadenia v sieťovom prostredí určite využívajú prenosové služby siete, bolo by zaujímavé im poskytnúť možnosť vzdialeného ovládania počítača, vzdialeného prihlásenia k iným službám priamo v našich telefónoch. Ich integrácia do centralizovanej správy vyžaduje buď ich úpravu (do inštalovať, nastaviť) alebo v centralizo- vanej správe používať obecné protokoly (výmena správ, web atď.).

2.3.2 Server Uzol počítačovej siete, ktorý svoje služby poskytuje ďalším, už zmieneným klientom sa nazýva server. Z náročnosti tejto role sú na server kladené zvláštne požiadavky ako po stránke výkonného hardvéru, tak spoľahlivého softvéru. Server musí často bežať nepre- tržite, byť neustále dostupný, efektívne spravovať systémové prostriedky. Jadro serveru, moduly, komponenty, všetko musí vyhovovať rôznym bezpečnostným kritériám, byť schopné odolať útokom. Vzdialená správa pomáha efektívnej správe nastavení a kontrole stavu serveru. Z hardvérového hľadiska majú servery viacnásobné, viacjadrové procesory, dostatok operačných pamätí, diskové polia, niekoľko pripojení a toto všetko sa najlepšie sústreďuje do racku. Fyzickú veľkosť serveru potom meriame na jednotky 1 U či 2 U. Nie sú lacné, sú hlučné, komplikovane chladené, proti výpadkom napájania môžu byť chránené záložnými jednotkami Uninterruptible Power Supply (UPS), či celými agregátmi. Týmto však nechceme povedať, že lokálna stanica nastavená ako server nemôže existovať, len jej beh nie je až tak optimálny, jej komponenty k behu 24/7 nie sú určené. Z pohľadu centralizovanej správy je u serverov bežný vzdialený prístup, možnosť sa prihlásiť z iného miesta. V sieťovom prostredí tomu hovoríme, že démon čaká na niektorom otvorenom sieťovom porte. Do mnohých profesionálnych serverov existuje možnosť prihlá- senia na úrovni hardvérového štartu systému, keď nie sú ešte operačným systémom zavedené žiadne služby, tobôž sieťové, žiadny port nie je otvorený. Je to však možné cez vzdialený manažment iLo na HP, či iDrac na DELL serveroch – skrz sieť vidíme to, čo by sme videli na terminály. Týmto je centralizovaná správa výrazne dokonalejšia, ovládame hardvér a ani pri ňom nemusíme byť.

10 3 Active Directory

Active Directory (AD) je názov pre centralizovanú správu užívateľov a objektov v sieťovom prostredí od Microsoftu. Voľne by sme pojem mohli preložiť ako adresáre, živé adresáre, ktoré sú hierarchicky usporiadané, ako to poznáme z adresárov/zložiek pri bežnej správe súborov. Zároveň to štruktúra rozšíriteľná o vlastné administratívne položky, nastavenia. AD fungujú ako centrálna databáza, ktorá má nástroje a funkcie na správu domény, ako sme ju vysvetlili v druhej kapitole. Databáza AD zahrnuje doménové účty, informácie o užívateľoch a prostriedkoch/zdrojoch, ktoré sa nachádzajú v spoločnej doméne. Sprí- stupňuje ich rôznym autentifikačným procesom a aplikáciam za účelom identifikácie a overenia užívateľov kdekoľvek v tomto prostredí – s jedným užívateľským účtom sa môže užívateľ prihlásiť na obecne ktorýkoľvek počítač, prihlásiť sa k rôznym službám v sieti. Rieši autentifikáciu osôb, celých skupín a tiež počítačov ako objektov, ktoré združuje do organizačných jednotiek Organization Units (OU), akoby kontajnerov, pomocou nich štruktúru organizácie sprehľadňuje. OU je možné vnárať do ďalších OU, vytvárať tak hierarchickú logickú štruktúru, v jednoduchom pohľade však ide hlavne o admini- stratívnu evidenciu – kde, čo je, kto, kam patrí – každý objekt vždy patrí len do jednej organizačnej jednotky. Takéto delenie umožňuje ľahšie vyhľadávanie, administráciu menších celkov, delegovanie a prideľovanie samostatných nastavení. AD prideľuje objektom a organizačným jednotkám oprávnenia, určuje a posiela politiky, ktoré je možné vhodne previazať práve s existujúcimi OU. V zásade sa Microsoft týmto produktom snaží vytvoriť komplexný nástroj pre centralizovanú správu sieťových zdrojov a užívateľov v rozsiahlom sieťovom prostredí svojich operačných systémov Windows, pri použití Windows Server edícií na správu. Bázovým prvkom doménového prístupu je potom jeden server ako doménový radič Domain Controller (DC), ktorý je nositeľom informácii z AD. Jeho násobne kopírované, synchronizované umiestnenie v sieti nazývame replikácia a umožňuje skvalitnenie služieb, istú decentralizáciu riadenia, podstatné informácie sú rozdistribuované po celej sieti a v prípade potreby sa vyžiadajú na najbližšom DC, nie nutne v centrále. Je už vecou správne nastavenej replikácie, aby sa zmeny propagovali medzi DC v rozumnej dobe. Microsoft však vznikom AD cielil aj na vznik doménových zón, akýchsi pobočkových celkov, ktoré dokážu bez pripojenia na centrálny DC ďalej a bezproblémovo existovať so svojim miestnym radičom, ktorý je čiastočne autonómny. Problémy s autonómnosťou, samozrejme, nastávajú pri fyzickom presune užívateľov medzi jednotlivými zónami s nesynchrónnymi DC – už zabudnutá zmena hesla v prvej zóne sa v druhej ešte ani nepre- viedla, užívateľ sa nevie prihlásiť. Iný druh autonómnosti počítača a jeho užívateľa nachádzame pri strate spojenia počítača na doménu, počítač je odpojený, odišli sme z

11 firemného prostredia na dovolenku. Užívateľ aj počítač sú objekty AD, overujú sa voči nej, avšak fungujú aj samostatne. Predpokladá sa, že užívateľ sa už k počítaču predtým prihlásil pri funkčnom spojení s AD a lokálne sa uložil jeho prihlasovací token, ktorý mu dovolí počítač používať aj mimo firmu, viac informácií uvádzame v kapitole 3.1.4. V logickom návrhu AD sa nachádzajú základné komponenty ako objekty, združujú sa do organizačných jednotiek, ktoré spravujú hlavné funkčné jednotky doménové radiče. Doména je vo výsledku kolekcia objektov, centrálna databáza, ktorá má zmienenú adre- sárovú štruktúru a túto najbližšie prirovnávame k telefónnemu zoznamu užívateľov s množstvom údajov o nich. Nie všetky informácie sú verejné, tajomstvá užívateľov si doména chráni, ako popisujeme v kapitole 3.1.6. Existencia viacerých domén, ktoré sú na seba hierarchicky previazané, udáva vznik tzv. doménových stromov, kde je badateľný vzťah rodič – potomok, možnosť ďalších potomkov potomka. Toto už roky poznáme z domé- nových menných služieb (DNS), teda systému adries serverov v rámci Internetu (.com » .google.com » mail.google.com), avšak menné služby tieto nie sú priestupné ako adresárová štruktúra. Doména musí mať jednoznačné označenie, rodič udáva sufix, každý potomok ho potom musí v názve obsahovať, viz obr. 3.1.

Obrázok 3.1: Doménový strom Active Directory (vľavo) a objekty, ktoré doňho nemôžu patriť, lebo majú iné DNS meno.

V AD je možné naviac nastaviť angl. trust, čiže dôveryhodnosť v rámci stromu, či medzi stromami, ktorá urýchľuje komunikáciu medzi radičmi. Iný typ dôveryhodnosti, akési prenesené overenie, že niekto niekoho pozná, zaňho sa zaručuje, nájdeme pod pojmom federácia. Viaceré stromy vytvárajú doménový les, častejšie sa nazýva z angl. forest a tento potom predstavuje celý svet Active Directory. Fyzickú štruktúru v návrhu AD, pojednanie o tom, čo je to AD Schema, AD Site a detaily multi-master replikácie možno nájsť prehľadne popísanú vo [Stanek, 2013], my ju tu už ďalej nerozvádzame.

12 Vzhľadom na celkové vyznenie princípov freeIPA v kapitole 4 a tam popísaných skôr technologických komponentov, čo je pre Linux obvyklé, ďalšej obecnej AD architektúre sa v tejto práci nevenujeme, nedá sa s riešením freeIPA vôbec porovnať, v tomto ohľade produkty nesmerujú na rovnaké využitie.

Prehľad kapitoly a ďalšie zdroje Microsoft predstavil Active Directory v roku 1999 s operačným systémom Windows Server 2000 a vo všetkých nasledujúcich vydaniach ich používa na centrálnu správu objektov v doméne a centrálne miesto identifikácie a autentifikácie. Súvislostiam s identitami, právami a bezpečnosťou sa venujeme podrobne a v súvislostiach celého sveta Windows (kapitola 3.1). AD sú technicky implementované ako systémové služby, množstvo štandardov a menších komponentov, ktoré vymenovávame z odborného pohľadu (3.2). Diskutujeme tu aj politiky (3.2.5), záznamy, audit (3.2.6) a na konci tohto celku uvádzame súčasné vlastnosti a funkcie Windows Server 2012 a Windows Server 2012 R2 (3.3). I keď sú AD síce zdarma ako služba serveru, finančnú nákladnosť Microsoft softvéru pre servery, licenčné súvislosti popisujeme v kapitole 3.3.2. Od roku 2010 Microsoft zverejnil vlastnú infraštruktúru cloudu, teda desiatky aplikácií bežiacich na vzdialených serveroch v celosvetovom pohľade, ku ktorým má klient kdekoľvek na svete prístup a túto infraštruktúru ponúka pod názvom Microsoft Azure. Doménové služby v nej spravujú Azure Active Directory (AAD) a dokážu komunikovať s AD. Prístup do Azure je spoplatnený, väčšinou sa platí za časové obdobie, množstvo aplikácií, pridelených prostriedkov v cloude. Krátko o AAD píšeme v kapitole . K ďalšiemu štúdiu AD spomedzi všetkých možných zdrojov, doporučujeme: • optimalizáciu serveru, nastavenie jeho služieb [Stanek, 2013], • ovládanie AD pomocou príkazov a skriptov z PowerShellu [Holmes, 2013], • skúsenosti s AD z bezpečnostného pohľadu [Ševeček 2011, 2015a], • online video kurzy CBT Nuggets [Conrad, 2012], Windows User Group.

3.1 Správa Active Directory

3.1.1 Účty užívateľov v doméne S potrebou vytvárať užívateľom počítačov ich vlastný pracovný priestor, mať vlastné súbory a pamätať si ich nastavenia sa stretávame od počiatku operačných systémov. Takýto prístup rozdeliť zdroje počítača pre viac užívateľov nazývame multiuser a stretávame sa s ním na domácich počítačoch už od Windows XP, na Linuxe odjakživa. Každému jednot- livcovi vytvárame jeho vlastný užívateľský účet a k nemu náleží jeho užívateľský profil. V serverovom prostredí užívateľský účet reprezentuje určitú osobu, teda umožňuje jednoznačnú identifikáciu osoby v lokálnom aj sieťovom prostredí a neskôr jej umožňuje delegovaný, overený prístup k ďalším zdrojom. Nositeľom informácii o účte je množstvo priradených atribútov, tak ako ich poznáme z databázového sveta. Ich konkrétnu ukážku možno nájsť neskôr na obr. 3.3.4.1 na str. 33.

13 Jednoznačnosť identity užívateľa v prostredí Windows zaisťuje existencia viacerých lokálnych a doménových databáz, kde spoločným reprezentantom identity je Security Iden- tifier (SID). Takýto identifikátor je priradený osobám aj skupinám, neskôr sa dozvieme, že aj počítačom. Na základe zrejmej väzby objekt + povolené alebo zakázané oprávnenie hovoríme o Access Control Lists (ACL), zoznamoch oprávnení. Najmocnejší užívateľských účet je super užívateľ, vo Windows účet Administrator. Nanešťastie, vo väčšine domácich počítačoch nevhodne používaný na každodenné činnosti. Na porovnanie sa super užívateľ vo svete Linuxu volá root, oprávnenia sa uňho nekontrolujú. Prenesene používame sloveso rootnuť, napríklad keď upravujeme linuxový systém telefónu k našej predstave, presne na to potrebujeme také práva roota, aby nás nič nezastavilo. Ďalšie porovnania viz v kapitole 4.1.1 o užívateľoch Linuxu na str. 35. Systém Windows na ukladanie informácii o užívateľov využíva svoj register, vytvára sa tu tzv. Security Account Manager (SAM)1. Pre meno užívateľa sa vo Windows a Active Directory používajú dva tvary užívateľského mena a sú zameniteľné [Ševeček, 2015a, 2. modul]: • Krátky lokálny SAM Account Name (FIMUNI\lukas) používa len 20 znakov a dopo- ručuje sa bez bodky. Táto databáza sa používa už od Windows NT2. • Dlhý doménový User Principal Name (UPN) ([email protected]) má do 64 znakov. Je možné použiť užívateľský účet aj v tvare odpovedajúcemu skutočnej emailovej adrese, i keď v tomto prípade o reálnu, ani kontaktnú adresu ísť nemusí, nič menej je to užívateľsky príjemné. V prípade použitia UPN musí byť dodržaná jeho unikátnosť v rámci celom forrest. Ide nastaviť ďalšie alternatívne UPN sufixy.

S druhým UPN názvom účtu sa teda stretávame hlavne v doménovom prostredí. Medzi doporučené nastavenia pre doménové účty naproti lokálnym účtom patrí dopredu nastaviť exspiráciu účtu, pokiaľ ide o krátkodobého užívateľa, aby sa naňho nezabudlo, v rozumnej miere nastaviť exspiráciu hesiel, aby sa napadnutý účet nedal s odstupom času už zneužiť, pretože bude mať nové heslo, uplatňovať politiku bezpečnosti hesiel a taktiež pridať vo vlastnostiach užívateľa na DC zoznam/tlačítko Log On To dovolených sieťových staníc, na ktorých sa v doméne môže užívateľ prihlasovať.

3.1.2 Security Identifier Security Identifier (SID) je jednoznačný identifikátor objektu v lokálnom Windows prostredí alebo AD doméne, je numerického tvaru s dĺžkou až 30 znakov.

1 Registrový kľúč: HKLM\SAM\SAM\Domains\Account\Users\Names je však nutné v nastavenia dovoliť čítanie tejto položky registru, manipulácia s ňou sa však nedoporučuje vôbec. 2 SAM trpí niekoľkými známymi bezpečnostnými oslabeniami, hlavne čo do kvality tvorby a používania hashov hesiel (NT hash a LanMan hash), čiastočne situáciu zlepšila implementácia SYSKEY, ktorý popisujeme v kapitole Chyba: Zdroj odkazu nenalezen.

14 S- 1- 5- 21-2772668801-3422537352-4003572955- 1001 Textový znak verzia SID identifikátor lokálny alebo doménový identifikátor, RID pre SID autority je jedinečný, ale jednotný

Tabuľka 3.1.2.1: Prehľad jednotlivých častí Security Identifier (SID) lokálneho užívateľa.

Všetky číselné skupiny SID u ručne vytváraného užívateľa sú vysvetlené v tab. 3.1.2.1, najdlhšia časť je spoločným znakom pôvodu – všetci lokálni užívatelia ju majú rovnakú, všetky doménové objekty tiež. Kratšie SID bez tejto časti majú obecní, východzí užívatelia. O správu SID sa stará lokálna a DC databáza, vznikajú za sebou ako inkrement poslednej číselnej skupiny tzv. Relative Identifier (RID). Každé vytvorenie je jedinečné a neopakovateľné, aj v prípade, že zadáme rovnaké údaje. Po zmazaní užívateľa zostáva SID s prihlasovacím menom uložený ako Tumbstone. Zoznam všetkých SID lokálneho užívateľa stanice s Windows 8 vytvoreného po inštalácii je na obr. 3.1.2.1. Pre správcu je zaujímavé sledovať RID. Napríklad sufix -500 je označenie pre miestneho správcu BUILTIN\Administrator, sufixy -1000 a vyššie značia ručne vytvorený objekt. Relatívne krátke SID bez lokálneho alebo doménového identifikátora sú vstavaní užívatelia a skupiny, ich zoznam je oficiálne zverejnený3. Pokiaľ v súborovom systéme NTFS napr. na prenosnom médiu, disku tieto SID nastavíme, budú sa uplatňovať aj na iných počítačoch, preto nejde NTFS z tohto pohľadu (len) kontroly oprávnení zamieňať s ochranou dát šifrovaním. Oprávnenia nastavené výhradne na niektorého konkrétneho používateľa budú po novej inštalácii systému, samozrejme, neplatné, pretože sa zmenil lokálny identifikátor. Súbory prevezme lokálny administrátor a znova ich pridelí novo vytvorenému užívateľovi. Každý užívateľ v Linuxe má priradené User Identifier (UID) a Group Identifier (GID), ide principálne o malé čísla oproti SID. Viac o užívateľoch Linuxu v kapitole 4.1.1.

3 https://support.microsoft.com/en-us/kb/243330

15 Obrázok 3.1.2.1: Zoznam SID a oprávnení lokálneho užívateľa fi-win8\david na lokálnej stanici pri použití utility whoami

3.1.3 Užívateľské oprávnenia a skupiny Užívateľský účet ako identifikátor je zároveň nositeľom schopností a oprávnení. Tieto môžeme priraďovať užívateľovi osobitne, postupne, pracne alebo je vhodné použiť pripravené skupiny oprávnení, ktoré zahrnujú viac činností podobného charakteru. Od najnižších oprávnení v prostredí Windows hovoríme o užívateľských skupinách Guests, Everyone, User, Power User či najvyššiu Administrators a mnohé ďalšie, ktoré majú vymedzené práva od manipulácie so súbormi, nastavenie času, sieťových zdrojov, inštaláciu softvéru až po samotné pridávanie, odoberanie a správu ostatných užívateľov – príklad možno nájsť v tab. 3.1.3.1. V prostredí Windows je špecifická možnosť užívateľa niektorých práv zbaviť tým, že ho z niektorej skupiny oprávnení odoberieme. Ponuka skupín sa s vývojom operačných systémov Windows zmení, naposledy boli vo Windows Server 2012 pridaní Protected Users, u ktorých je vyžadovaná politika ochrany hesiel najvyššieho dostupného stupňa, naopak do verzie Windows 2000 bola skupina Everyone aj pre anonymných užívateľov, čo prinášalo bezpečnostné riziko sprístupnenia zdrojov, súborov aj celkom neznámym užívateľom [Ševeček].

16 Poznamenajme, že pre miestny účet BUILTIN\Administrator neplatí politika zamy- kania účtu pri neúspešnom prihlasovaní, pri možnom útoku hrubou silou, preto je z bezpečnostných dôvodov dobré tento účet hneď v systéme zakázať. V núdzovom režime použiť pôjde, aj keby bol zakázaný. Dokonca sa doporučuje každého BUILTIN\Admini- stratora premenovať, aby útočník neskúšal predvídateľný login vzdialene. Systém Windows nehlási, že login je neplatný, ale kombinácia login + heslo sú neplatné ako celok, takže možný útok prebieha do prázdna [Ševeček, 2010, 2015a, 2. modul].

Everyone skupina, do ktorej patria všetky účty BUILTIN\Administrators lokálni správcovia BUILTIN\Users lokálni užívatelia NT AUTHORITY\Authenticated Users autentifikovaní užívatelia NT AUTHORITY\SYSTEM servisná, člen Administrators (proces) NT AUTHORITY\NETWORK SERVICE servisná, nižšie oprávnenia (proces) NT AUTHORITY\LOCAL SERVICE servisná, nižšie oprávnenia (proces) NT AUTHORITY\INTERACTIVE pridaná pri prihlásení k stanici LOCAL miestne účty, prihlásenie prebehlo na fyzicky pripojenom termináli NT AUTHORITY\NTLM Authentication autentifikácia prebehla cez NTLM NT AUTHORITY\This Organization východzia organizačná jednotka, kvôli uplatneniu niektorých politík Mandatory Label\Střední povinná úroveň sandbox so stredným zabezpečením, prítomné od Windows Vista Tabuľka 3.1.3.1: Prehľad skupín a oprávnení u lokálneho správcu vo Windows 8. Sú tu uvedené aj oprávnenia, do ktorých nespadá identita správcu ale jeho procesov.

V doménovom prostredí sa na AC DC stretávame so skupinami Administrators, Account Operators, Domain Admins, či Enterprise Admins a títo užívatelia môžu manipu- lovať na rôznej úrovni s objektami radiča [Stanek, 2013, s. 1379]. Obecne doporučeným riešením je používať skupiny oprávnení prekrývajúce organizačné skupiny OU, a to s čo najnižšími oprávneniami, pre zreťazených (a tým pádom skrytých) užívateľských skupín.

3.1.4 Access Token Každý proces vo Windows po spustení získava pamäťovú štruktúru Access Token, ktorý vytvoril proces lsass.exe predstavujúci Local Security Authority Subsystem Service (LSASS). Ide o miestnu logickú bezpečnostnú autoritu, ktorá je zodpovedná za dodržovanie bezpeč- nostných politík, zodpovedá za autentifikáciu užívateľov do lokálneho alebo doménového účtu. Služby tejto autority sú natoľko kritické, že býva často obeťou napadnutia malwarom. Access token potom obsahuje informácie o užívateľovi a jeho skupinách formou podrobného výpisu SID4, ako boli vypísané napr. na obr. 3.1.2.1. Token teda reprezentuje

4 Kompletný výpis SID, ktoré bude mať užívateľ po prihlásení na klienta nie je vhodné usudzovať len z karty Member of, ale musíme si nastaviť View – Advanced Features a pozrieť sa do AD Users and Computers – User Properties – Attribute Editor – atribut objectSid. Ďalej si nastaviť

17 identitu užívateľa vo všetkých procesoch, prístupoch k súborom alebo službám, token platí lokálne a aj v celom svete domény AD. Takýto Token sa obvykle dedí medzi procesmi toho istého užívateľa, v majoritnom procese explorer.exe sa spúšťajú všetky ďalšie nesystémové procesy. Access Token získaný po overení užívateľa v doméne sa ukladá aj do vyrovnávacej pamäte cache počítača5 a počet slotov na uloženie užívateľov v počítači je 10. Každý takýto token reprezentuje jedného užívateľa, nie jedno jeho prihlásenie, takže aj odpojený počítač z domény je schopný prihlásiť až toľkoto užívateľov. Počet slotov cache sa dá redukovať6, nemal by však zostať len jeden, pretože môže byť zabraný tokenom systémového procesu a užívateľ sa už nebude môcť do počítača úspešne prihlásiť [Ševeček, 2015a]. K téme tokenov a s tým súvisiacich Kerberos tiketov sa ešte vraciame v kapitole 3.2.6 z pohľadu auditu, kedy a za akých okolností, pri akej udalosti tiket vznikol.

3.1.5 Účty počítačov v doméne Radič domény AD musí mať svoje meno ako stanica a ďalšie dve mená ako DC, poznávací znak domény ako celku, ktorý sa bude propagovať ďalej do siete. • Meno domény má až 64 znakov (fi.muni.cz.virtual), čo je tvarom podobné DNS záznamom, avšak pridáva sa sufix (.internal či .virtual, .primary, .secondary). • Druhé meno domény pre NetBIOS kompatibilitu je krátke, 15 znakov ( FIMUNI). V prostredí Active Directory platí aj pre počítače obdobný spôsob identifikácie a overovania ako pre užívateľov, sú tiež členmi domény, musia v nej mať účet. Každý počítač, pracovná stanica predstavuje samostatný doménový objekt, ako sme ho popisovali na samom začiatku kapitoly. Meno počítača je až na znak doláru ($) podobné menu užívateľa v doméne (FIMUNI\fi-win8$). $ sa v prostredí Windows sietí používal ako sufix skrytej zložky, v tomto prípade ide o rozlíšenie zhodnosti, ktorá by mohla nastať, ak by existoval užívateľ s rovnakým menom. O opakované prihlásenie počítača do domény sa stará služba Netlogon a je súčasťou už zmienenej autority LSASS v podkapitole 3.1.4. Kvôli jednoznačnej identifikácii počítača nestačí len jeho meno, ale je tu povinnosť mať v doménovom svete svoj vlastný SID, ktorý bude v správe radiča. K takémuto účtu patria oprávnenia alebo celé skupiny oprávnení, ako sme už popísali pri užívateľoch, akurát sa aplikujú v zmysle počítačov. Počítač môže do domény prihlásiť len niektorí z oprávnených správcov zo skupín Administrators, Account Operators, Domain Admins, či Enterprise Admins [Stanek, 2013, s. 1379]. Účet počítača potom ako objekt spadá do základnej OU počítačov v DC, a preto je vhodné ho pridať/pripraviť skôr než sa pripojí fyzicky. Túto činnosť nejde vykonať

filter Constructed – atribut tokenGroups. Týmto postupom získame prehľad naozaj všetkých SID doménového užívateľa [Ševeček, 2015a, 1. modul]. 5 Registrový binárny kľúč: HKLM\SECURITY\Cache obsahuje účty doménových používateľov, ktorí sa kedysi do počítača prihlásili. 6 Politika: Local Security Policy\Local Policies\Security Options\Interactive logon: Number of previous logons to cache (in case domain controller is not availible) obsahuje počet dovolených účtov uložených vo vyrovnávacej pamäti cache.

18 vzdialene, zo servera ku klientovi, musia byť prevedené zmeny nastavení z lokálneho správcovského účtu počítača! V praxi sa podľa Ševečka [2011], bohužiaľ, stretávame s obrovským bezpečnostným rizikom vyzradenia a straty hesla administrátora radiča v prospech malwaru, ktorý môže v neznámom klientskom počítači čakať na svoju príležitosť. Teda AD sa aj k počítaču správa ako k užívateľovi, a preto možno neočakávanou vlastnosťou AD je, že aj účty počítačov si generujú svoje prístupové heslá [Ševeček, 2011]. Iniciatívne si ich menia po 30 dňoch. Bezpečnosť takéhoto hesla je vysoká, je zložené zo 120 znakov i keď len US ASCII. Heslo počítača je uložené v jeho lokálnom registri7.

3.1.6 Ochranné mechanizmy Na tomto miestne uvádzame niekoľko implementačných princípov, ktoré Microsoft používa na ochranu hesiel užívateľov, počítačov a obecne mnohých citlivých položiek vo svojich registroch na lokálnych staniciach i v doméne. Inšpiratívne zistenia priniesol Graf- netter [2015]. V prvom rade je obecne známy prístup ochrany hesiel pomocou ich hashovania, teda prevod skutočnej podoby hesla (Pa$$word) na jeho otlačok hash (MD5: 44fbfffe5ff- c7618de5dd2c3c464f295), z ktorej ho nejde spätne získať. Avšak kedykoľvek je potrebné overiť užívateľa, porovná sa ním zadané heslo, prepočítané na hash s uloženým hashom. Takto uložené hashe by bolo vhodné nejako chrániť, aby predsa len útočník nevyužil znalosť hashu užívateľa na dohľadanie jeho pôvodného tvaru – útoky pomocou Rainbow Tables. V takýchto tabuľkách miliárd vygenerovaných hashov sa dá spätne nájsť heslo, z ktorého bol hash vypočítaný. Dopredu vypočítané Rainbow Tables môžu dosahovať tera- bajtových veľkostí, dajú sa zakúpiť, na druhú stranu je vyhľadávanie v nich na optimalizovanom hardvéri, za ďalšie peniaze, už v rádoch hodín. Lámanie hesla pred- stavuje dosahuje až desaťročia. V druhom rade je ochrana proti Rainbow Tables možná tzv. solením hesla, kedy sa pred výpočtom hashu z hesla najskôr k nemu pridá netriviálne množstvo textu, tzv. soľ, a až z takto doplneného hesla sa nechá spočítať hash. Overovací proces si k zadanému heslu soľ pridá a spočíta hash až v tomto náhodnejšom tvare. Princíp je to nenáročný, ale v zmysle bezpečnosti veľmi významný, Rainbow Tables sú už nepoužiteľné. Ďalšie zvýšenie kvality hashu zaručuje kvalitne zvolená hashovacia funkcia podľa aktuálneho štandardu (MD vyšších verzií, dnes nahradené SHA algoritmami) a za bezpečnejšie sa považuje aj opakované prepočítanie hasha z hashu v niekoľkých následných iteráciách, viac v štan- darde PBKDF8. Microsoft v politikách AD vo východzom tvare vyžaduje komplexné heslá, to sú také, ktoré majú aspoň 3 zo 4 skupín znakov: malé, veľké, numerické a zvláštne znaky. Nami uvedené heslo Pa$$word túto politiku spĺňa. V AD je možné nastaviť minimálnu dĺžku hesla, zákaz predošlých hesiel. V procese ochrany týchto citlivých dát (pretože aj hash 7 Registrový kľúč: HTML\SECURITY\Policy\Secrets\$MACHINE.ACC\CurrVal obsahuje heslo počítača pripojeného v doméne, v šifrovanom tvare. Komentár k extrakcii možno nájsť v [Ševeček, 2015a, 3. modul], pričom autor udáva, že nejde o hacking, takúto manipuláciu s registrami robí aj Cisco AnyConnect VPN klient. 8 Súčasť PKCS #5 http://tools.ietf.org/html/rfc2898

19 môže byť v útoku na LM prihlásenie replikovaný) Microsoft postupuje podľa následu- júcich postupov (schém na obrázkoch). Na ochranu databázy Security Account Manager (SAM), ktorú sme spomínali pri užívateľských menách a má pôvod už vo Windows NT, Microsoft do registrov uchováva generovaný kľúč SYSKEY. Tento kľúč sa po rôznych úpravách nakoniec použije v procese ochrany hlavného hesla databázy Pasword Encryption Key (PEK). Je však uložený v tvare, ktorý možno z registra extrahovať a preto je možné odhaliť samotný PEK, dokonca hashe ním chránené, ako ukážeme na poslednej schéme [Dolan-Gavitt, 2008 a Grafnetter, 2015]. Podľa obr. 3.1.6.1 sa hodnota SESKEY najskôr pomieša permutáciou, potom rozdelí na na viac častí, ktoré zostanú uložené v rôznych častiach registra9

Obrázok 3.1.6.1: Schéma operácii s kľúčom SYSKEY [Grafnetter, 2015].

Na ďalšom obr. 3.1.6.2 sa z hodnôt SYSKEY a prednastavenej PEK SALT (soli), ktorá bude heslo chrániť, najskôr počítajú MD5 hashe v zreťazenom postupe podľa PBKDF (s otáznikom preto, že takýto režim nie je v štandarde). S výslednou hodnotou sa pomocou RC4 šifry zašifruje kľúč PEK.

Obrázok 3.1.6.2: Schéma ochrany systémového PEK [Grafnetter, 2015].

9 Registrový kľúč: HKLM\SYSTEM\CurrentControlSet\Control\Lsa s hodnotami JD, Skew, GBG, Data. Pričom kľúč Skew1 nie je súčasťou registra v otvorenom tvare.

20 Na ochranu hashu užívateľského hesla sa vo Windows, v prípade SAM databázy, používa nižšie uvedený postup – aby bol vo výsledku tento hash zašifrovaný a chránený pred zneužitím behom Replay Attack (útoku zopakovaním). Do procesu vstupujú hash, jeho soľ a užívateľov Relative Identifier (RID) – posledný sufix z jeho SID čísla, a hlavný šifrovací kľúč databázy PEK. Na tieto vstupy sa použijú kryptografické metódy podľa schémy na obr. 3.1.6.3 a užívateľov hash je nakoniec zašifrovaný.

Obrázok 3.1.6.3 Schéma operácii na ochranu hashu hesla užívateľa pomocou jeho osobného RID, systémového PEK, solenie a šifrovanie [Grafnetter, 2015].

Útočníkom tieto zistenia o slabosti v koncepte ochrany kľúčov a hashov, samoz- rejme, ale dnes sú už obecne známe. Preto sa v niektorých bezpečnostných politikách, pri ochrane vysokých hodnôt uplatňujú len autentifikačné metódy na báze Kerbera.

21 3.2 Technológie v AD

3.2.1 Hlavné komponenty

X.500 hierarchická štruktúra pre kontajnery a objekty AD Domain Services (AD DS) (DC) LDAP a miestne registre spoločne s Global Catalog (GC) JET Blue prístupová metóda Doménová štruktúra mien

Autentifikačný server na sprí- Kerberos v5 Kerberos autentifikácia stupnenie zdrojov v doméne procesy netlogon, winlogon

databáza a miestne registre Užívateľské účty a heslá Security Account Manager (SAM) autorita LSASS, NTLM hash

Tabuľka 3.2.1.1: Zoznam princípov, názvov služieb a konkrétnych implementácii v AD.

AD DS, v tejto práci a bežnej praxi naďalej nazývané ako Domain Controller (DC), je nositeľom údajov z AD. Na realizáciu je použitá adresárová štruktúra LDAP. Aspoň na jeden DC sa pridáva Global Catalog (GC), ktorý obsahuje obmedzené množstvo údajov o užívateľovi, ale má ich z celého doménového forestu (logického lesa). AD sa skladá zo súborov NTDS.DIT a súborov registrov uložených na DC, ide o databázové súbory, ktoré sú uložené pomocou technológie JET Blue10. Z bezpečnostného hľadiska sú tieto súbory primárnym cieľom útočníkov, obsahujú množstvo databázových záznamov, ktoré obsahujú nielen verejné atribúty o užívateľoch, ale aj ich Kerberosie pove- renia, NTLM hashe, primárne kľúče DC ai. [Grafnetter, 2015] Vzájomné vzťahy medzi komponentami AD a Local Security Authority (LSASS) sú uvedené na obr. 3.2.1.1.

Obrázok 3.2.1.1: Autorita LSASS vo vzťahu k službám AD. Z ľavej strany je výpis otvorených portov a ich účel [Ševeček, 2015b]. 10 Rýchla databázová technológia.

22 Obrázok 3.2.1.2: Autorita LSASS, otvorené porty vo vzťahu ku klientským OS a službám, ktoré s ňou komunikujú [Ševeček, 2015b].

Na obr. 3.2.1.2 je zobrazený ešte jeden konkrétny oddialený pohľad na komponenty AD, akým spôsobom z vonku pristupujú jednotlivé služby – od staručkých, stále podporo- vaných klientov NT4 závislých na slabo zabezpečenej SAM databáze, cez všetky modernejšie Windows 2000 a novšie klientské stanice komunikujúce s Kerberos Distribution Center (KDC). Pre komunikáciu na úrovni domény musia byť otvorené aj ďalšie porty na LDAP dotazovanie a replikáciu radičov.

23 3.2.2 Doménové role serveru Zoznam rolí a funkcií uvádzame s vysvetlením v tab. 3.2.2.1 a tab. 3.2.2.2.

AD Certificate Server (AD CS) služby vydávania a revokácie certifikátov užívateľom, staniciam a serverom, zahrňuje ďalšie podradené role serveru ako certifikačnú autoritu, politiky atď. AD Domain Serives (AD DS) všetky doménové služby ako databáza, globálny katalóg, manažment, tvorí základ AD, je rolou prvej voľby pri nastavovaní serveru. V minulosti sa používal pre časť úloh spojených s touto roľou názov radič domény, Domain Controller (DC), ktorý sa v praxi zaužíval, avšak už názvom nepokrýva všetky služby AD. AD Federation Services (AD FS) federovaná identita, základ služieb overovania a riadenia prístupu smerom von z AD, napr. na WWW, zahrňuje ďalšie podradené role. AD Lightweight Directory Services (AD LDS) odľahčená verzia adresárového serveru pre aplikácie, ktoré s doménou potrebujú komunikovať na jednoduchšej úrovni, skúša sa aj v skriptoch PowerShellu. AD Rights Management Services (AD RMS) služby kontroly prístupu, napr. k ochrane emailových správ, dokumentov. Tabuľka 3.2.2.1: Primárne role Windows Server 2012 [upravené z Stanek, 2013, s. 230].

Application Server aplikačný server pre ASP.NET atd. DHCP Server dynamické prideľovanie IP adries staniciam. DNS server menné služby, často nutný základ AD. Fax Server File and Storage Services súborové a ukladacie služby, nie však zálohu. Hyper-V podpora virtuálizácie, tvorba a správa hosťov. Network Policy and Access Services (NPAS) základ pre ďalšie sieťové riadenie prístupu. Print and Document Services tlač a centralizácia skenovania. Remote Access podporuje vzdialené služby, pri nasadení VPN... Remote Desktop Services podpora vzdialeného pripojenia. Volume Activation Services manažment automatických aktivácii v licenčnej politike Microsoftu. Web Server (IIS) Internet Information Services vytvára serverovú časť webových služieb pre statický aj dynamický obsah. Windows Deployment Services (WDS) služby potrebné pri nasadení v korporáciách. Windows Server Update Services (WSUS) podpora Windows Update na lokálne stanice. Tabuľka 3.2.2.2: Sekundárne role/služby Windows Server 2012 [upravené z Stanek, 2013, s. 230].

24 Windows servery vždy obsahovali vedľa primárnych rolí aj tzv. funkcie serveru, ktoré zasahujú do samotnej jeho správy, ide o rôzne nástroje a ďalšie funkcie, ktoré môže server v sieťovom prostredí poskytovať. My v tejto práci uvádzame napríklad Group Policy Management Center, Windows PowerShell a jeho doplnkové prostredie. Kompletný prehľad všetkých funkcií v [Stanek, 2013, s. 232-236]. Z pohľadu centralizovanej správy pribudla vo Windows Server 2012 nová možnosť pridania doménových rolí aj vzdialenému serveru priamo z nášho miestneho Server Manager, pokiaľ sú na druhej strane minimálne Windows Server 2012. Výborné riešenie na centralizovanú správu väčšieho množstva doménových radičov.

3.2.3 Autentifikácia užívateľov Ako sme v úvode kapitoly rozvádzali, je primárnym zmyslom existencie AD udržovať prehľad o užívateľoch a strojoch, tieto pre ďalšie potreby aplikácii/služieb/počítačov na vyžiadanie autentifikovať. Proces autentifikácie užívateľa v AD prebieha takto: 1. Užívateľ zadáva svoj login + heslo. 2. Stanice se pýta DNS, kde se nachádza LDAP a Kerberos služba pre miestnu doménu, DNS odpovie IP adresou. 3. Stanica kontaktuje DC a žiada o autentifikáciu užívateľa, ktorý sa prihlasuje. 4. Radič overí platnosť, pokiaľ je zároveň globálnym katalógom (GC) odpovie, inak si informáciu ďalej overuje. 5. Radič potvrdí právo prihlásenia, užívateľ sa prihlási.

K prístupu do GC dochádza podľa Ševečka [2011] najčastejšie z Outlooku.

3.2.4 Autentifikácia stanice Pri autentifikácii stanice v AD, viz obr. 3.2.4.1 na ďalšej strane vo veľkom prevedení, zohráva úlohu aj jej sieťové nastavenie, či má svoju IP adresu (alebo si ju vyžiada z DHCP), či pozná svoje okolie a preklad mien (alebo si ho zistí z DNS), aby konečne mohla riešiť vlastnú autentifikáciu, ktorá sa skladá z týchto bodov: 1. Stanica v sieti vyhľadá DC, kontaktuje najbližšiu alebo vnútenú repliku. 2. Overuje sa jej existencia v DC, kontroluje sa zhoda doménového mena. 3. Aby získala tiket od Kerbera, tým pádom je autentifikovaná. 4. Mohla dostať politiky, ďalšie nastavenia na ňu vztiahnuté.

25 Obrázok 3.2.4.1: Autentifikácia stanice v doménovom prostredí [Bukač, 2012]. 3.2.5 Politiky Z angl Group Policy (GP) sa vo svete Windows staníc a aj AD domén vytvárajú tzv. politiky, niekedy prekladané ako zásady skupiny, aby zjednodušili správcovskú prácu, zjednotili nastavenia prostredia. Vo Windows môže ich použitie efektívne obmedziť lokálneho užívateľa tým, že mu zakážeme zmenu šetriča, ikôn, ponuky Štart alebo rovno prístup do Ovládacích panelov. Takto prevedené nastavenia zásad skupiny11 je možné importovať alebo exportovať a použiť na inom počítači. Stranou stoja ešte zásady zabezpečenia12, v ktorých možno editovať napr. Windows firewall. Prehľad 3 nástrojov na editovanie rôznych typov politík uvádzame na obr. 3.2.5.1. Čo samotná politika znamená, ako ju Microsoft správcovi v textovom komentári vysvetľuje, je vidieť na obr. 3.2.6.1, až na stránke 29. Táto konkrétna politika/zásada sa týka nastavení vlastností auditu. Všeobecne pre politiky platí, že nastavenia o ich uplatnení môžu byť podľa binárne – áno/nie, vymenované – loguj aj prihlásenie, aj odhlásenie, uplatňovaní na zoznamy – týchto užívateľov, tieto objekty apod. Možností je veľa, miest nastavenia ešte viac.

Obrázok 3.2.5.1: Prehľad niektorých nástrojov Windows na úpravu politík/zásad skupiny.

V doménovom prostredí majú oveľa väčší význam, a to rádovo, pretože sa v nich ukladajú nastavenia a vynútené pravidlá ako pre radič, tak pre všetkých užívateľov a počítače v doméne. Uveďme napr. bezpečnostné konsekvencie s politikou nastavenia zamykania účtu pri neúspešnom prihlásení, doba zámku, kvalita hesiel, nastavenia Kerbera. V AD sú uložené ako SYSVOL a sú reprezentované ako Group Policy Objects (GPO), pretože sa s nimi manipuluje v rámci rôznych kontajnerov, OU. Výsledkom správneho používania GP správcom domény je jednotná konfigurácia nastavení zariadení a jednotných pravidiel v celej počítačovej sieti. Pomocou politík je možné definovať činnosti pri prihlasovaní/odhlasovaní na domé- novej stanici, používajú sa na jednotnú aktualizáciu, a to nielen nastavení OS (nezamieňať s aktualizáciami v zmysle Windows Update), ale aj ďalšieho nainštalovaného softvéru, ktorý ich implementuje. Nutno konštatovať, že zväčša ide o Office, Outlook, Internet Explorer – všetky nastavenia týchto aplikácii sú teda skryté a editovateľné v GP, v domé-

11 gpedit.msc 12 secpol.msc novom svete môžeme vzdialene upraviť chovanie ďalších súčastí OS. Ucelený pohľad, aké všetky oblasti politiky zasahujú vidieť na obr. 3.2.5.2.

Obrázok 3.2.5.2: Prehľad skupín politík na klientovi a DC AD [Stanek, 2013, s. 1391].

Na správu politík vo Windows Server 2012 sa používa GP Management Editor. Z dôvodu ďalšieho rozsiahleho nastavovania, delegovania, vytvárania šablón zásad odka- zujeme do step-by-step príručky [Stanek, 2013], dokonca je pri vačšine GPO v lokálnom aj doménovom prostredí obsiahlo zmysel politiky popísaný priamo v nástroji, ktorým ju spúšťame/nastavujeme.

3.2.6 Audit Pod angl. log (záznam), zaužívané aj ako sloveso logovať, rozumieme proces, ktorý sleduje a zaznamenáva priebeh rôznych events (udalostí), aktivít a ich výsledkov v operačnom systéme. Nás v centrálnej správe zaujímajú hlavne udalosti logon (prihlásenia), prístup k doménovým prostriedkom access a prípadne log of (odhlásenie). Avšak pozor, hovoríme o udalostiach, ktoré nastanú v zmysle interakcií s AD DC, teda pri dotazovaní sa na identitu a overenie niektorého užívateľa z domény sediaceho pri stanici v doméne. Pri audite overujeme obsah logov, skúmame detaily udalostí, činíme závery. Audit má rozsiahle bezpečnostné využitie ako základ proaktívnych a reaktívnych scenárov chovania na vzniklé udalosti. Bezpečnostný audit analyzuje prostredie, prechádza sa checkpoint list, vo

28 výsledku môže byť udelená certifikácia z rady ISO 2700013. Pre naše potreby možno použiť nástroj System Center Operation Manager (SCOM) – Audit Collection Services alebo komerčný produkt Nagios14. Ševeček [2015a, 5. modul] uvádza, že logy 20 aktívnych užívateľov v AD za 14 dní predstavujú až 500 MB textových dát! Autentifikačné služby v AD sú podľa neho „ukecané“, a preto produkujú obrovské množstvo udalostí. Z tohto dôvodu nastavenia striktného logovania nemožno za bežných podmienok dlhodobo prevádzkovať. Použitie externých nástrojov je možné na výsledných logoch, nie však na množstve udalostí, ktoré zaznamenáva DC. Ako príklad toho, čo sa môže auditovať na každej lokálnej stanici, sú udalosti príchodu a odchodu užívateľa. Takéto nastavenie a priamo komentár od Microfotu k politike auditu prihlasovania, viz obr. 3.2.6.1. Odborníka neprekvapí, že v komplexnom svete Windows, kde sú nastavenia uložené väčšinou v registroch systému alebo užívateľa, aj samotný audit sa spúšťa v nastaveniach zabezpečenia, v rôznych politikách, ako sme ich v predošlom vysvetľovali.

Obrázok 3.2.6.1: Východzie miesto spustenia auditu – miestne zásady zabezpečenia a ukážka komentáru jednej takej politiky.

V prípade záujmu o audit prihlasovania v AD, čo je len jedna úzka skupina možností udalostí na radiči, môžeme v správcovi GP nastaviť tieto politiky15:

13 Poskytuje odporúčania osvedčených postupov v oblasti riadenia informačnej bezpečnosti, rizík a ovládacích prvkov v kontexte celkového systému riadenia informačnej bezpečnosti (ISMS). 14 https://www.nagios.com/solutions/audit-log-monitoring 15 Group Policy Manager: Local Security Policy: Security Settings\ Local Policies\Audit Policy\

29 • Audit Credential Validation – pre lokálne prihlásenia NTLM, či certifikátom, • Audit Other Account Logon events, • Audit Kerberos Authentication Service – pre kerberizované prihlásenia, • Audit Kerberos Service Ticket Operations.

A potom sa budeme zaujímať o tieto konkrétne udalosti: • Logon Event – bol či nebol vytvorený Access Token na lokálnej stanici. • Account Logon Event – v zmysle použitia hesla, autentifikácia ako ju poznáme – overenie hashu hesla voči databáze atď. Prebieha na úrovni databáze lokálnej stanice (SAM, registre) alebo AD databáza na radiči AD DC (súbor NTDS.DIT).

Zhrňme, že prihlásenie sa vykonáva ako sled udalostí – užívateľ na stanici vyvoláva dialóg na zadanie login + hesla (známy troj hmat ctrl+alt+del alebo odsunutie pre-login screenu od Windows 8), potom sa v pamäti vytvorí pomocou procesu LSASS štruktúra Access Token – tým vzniká zmienená auditovaná udalosť typu Logon Event. V tomto momente v slede udalostí preberá úlohu DC, ktorý overí heslo užívateľa – tým vzniká zmienená auditovaná udalosť typu Account Logon Event. Nakoniec samotný Access Token v procese winlogon.exe. Account Logon udalosti nevznikajú tak často pri autentifikácii Kerberom, hlavne z dôvodu až desať hodinovej exspirácie Kerberos Tiketu, ktorý užívateľ drží [Ševeček, 2015a, 5. modul]. Ďalšie možnosti auditu, napríklad súborového serveru, možno nájsť v [Stanek, 2013].

3.3 Windows Server Windows Server je operačný systém Microsoftu určený do sieťového prostredia, aby poskytoval služby, tvoril isté centrum, miesto centralizovanej správy. V tejto práci sa zaoberáme vlastnosťami Windows Server 2012 a jeho druhej edície. Ide o 6. vydanie serverovej verzie, bol vyvíjaný súčasne s Windows 8, z ktorého preberá napr. design Metro. Pre správu systému je obvyklé používať GUI nástroje, ktorých poskytuje veľké množstvo, nič menej je vo východzom nastavení inštalácie nastavený na minimálnu verziu Server Core – bude ovládaný len pomocou príkazov. Prostredie je možné neskôr pridať, ale vzhľadom na časté inštalácie vo virtualizovanom prostredí je každý ušetrený GB výhodou.

3.3.1 Standard vs. Datacenter Windows Server je možné získať v niekoľkých komerčných edíciách, ktoré sa líšia cenou a sprístupnenými funkciami v doménovom prostredí. Oproti minulosti došlo k výraznej redukcii z 10 rôznorodých verzií na tieto 4 – Foundation, Essentials, Standard a Datacenter. Edícia Foundation je len pre OEM účely do 15 užívateľov, druhá edícia Essentials je tiež špecifická, určená pre malé podniky s limitným počtom 25 užívateľov. V produkčnom rozsiahlom prostredí zostáva na výber Standard alebo Datacenter, aby sme mohli vytvoriť

30 doménu s niekoľkými radičmi AD DC a tieto replikovať pre stovky potenciálnych užíva- teľov a rozsiahle zdroje v sieti.

3.3.2 Licenčná politika Obstarávacie ceny edícii vychádzajú zo súčasnej aktualizovanej licenčnej politiky Micro- softu, z počtu jadier procesorov na serveri (2× quadcore = 8 licencií). K tomu sa pripočítava licencia každého jedného užívateľa alebo zariadenia pristupujúceho k serveru, tzv. Client Access Licence (CALs) [Soukup, 2014]. Licenčné náklady predstavujú v poradí za Essentials $ 501, Standard $ 882, Datacenter $ 6.155 [Microsoft, 2013c]. Cena jednej CAL licencie na užívateľa je okolo $ 40 a zariadenia 35 amerických dolárov [Abacus, 2015]. Microsoft ponúka svoje virtualizačné prostredie Hyper-V a toto sa premieta aj do možností nasadenia edícii serverov. Pri Essentials je na voľbe zákazníka jedna virtuálna alebo reálna inštalácia obmedzeného serveru, v Standard sa predpokladá nižšia miera virtuálizácie (2× virtuálne + prístupová inštancia), ale už so všetkými službami plnohod- notného serveru. V Datacenter horný limit inštancií obmedzený dlhodobo nie je, inštaláciu sa doporučuje previesť pomocou aktivačných AVMAA kľúčov. Produkt Microsoft Hyper-V Server je špecifická inštalácia prostredia Hyper-V dostupná zdarma, určená primárne na ďalšie inštalácie virtualizovaných serverov, ktoré máme v tomto prostredí licenčne zaistené. Nástroj Hyper-V Console potom slúži k správe klientov. Podrobne sa téme virtualizácie pomocou Hyper-V a jej optimalizácii venuje [Dušek, 2011]. Služby Active Directory sú však principiálne zdarma, pokiaľ máme zakúpený server. Pre potreby tejto práce sme v rámci akademického programu Microsoft Developer Network Academic Alliance (MSDNAA) získali edíciu Windows Server 2012 Datacenter. Je však možné využiť aj program MSDN pre vývojárov/študentov16, edície všetkých možných serverov a jazykových mutácii sú tam dlhodobo dostupné.

3.3.3 Vlastnosti Windows Server 2012 Obecnú znalosť ako sa líši server od klienta, v čom ho server hardverovo prevyšuje sme popísali v kapitole 2.3.2. Detailný prehľad obecných funkcí Windows Servera možno nájsť na [Microsoft, 2013]. Tu uvádzame niekoľko nových technológii a nástrojov, ktoré sú dostupné vo Windows Server 2012 (z 9/2012) a Windows Server 2012 R2 (z 10/2013) [Kantůrek, 2014]: • doplnený nový nástroj na správu doménového radiča AD System Centre, ktorý ponúka aj tzv. best practices a pokročilé skenovanie nastavení DC, • podpora a začlenenie virtualizačných mechanizmov (Hyper-V v3), • prepojenosť s cloudom (Microsoft Azure), • prítomnosť Windows Server Management (WS-MAN), na správu Windows služieb skrz Windows Management Infrastucture (WMI),

16 http://dreamspark.com

31 • vzdialená aktualizácia politík v Group Policy Manager, ktorý umožňuje vzdialenú správu politík lokálnych počítačov (cez WMI), • správa sieťových úložísk skrz štandard Storage Management Initiative-Speci- fication (SMI-S) a sieťových prvkov, administrácia portov skrz protokol Open Management Infrastructure (OMI), • užívateľské funkcie pri virtuálizácii s použitím Enhanced Session Mode (od R2, Windows 8.1), priama podpora rozšíreného používania užívateľských funkcií ako prenos zvuku z hosťa, pripojenie lokálnych diskov alebo prídavných USB diskov tak, aby boli v hosťovi zobrazené, technicky cez: ◦ Remote desktop – doterajšie riešenie, ◦ VMBus – nová zbernica na prenos spojenia, • migrácia virtuálneho hosťa za behu, aj komprimovaná, aj do sieťového úložiska (od R2), a replikácia Hyper-V Replica, je nutné však prihliadať na doporučené replikačné scenáre, napríklad pri replikácii databázového serveru môže dôjsť k strate konzistencie, • užívateľská podpora režimu bring your own device (BYOD), pričom zariadenie klienta ako telefón, vlastný notebook sa stanú autentifi- kovanými zariadeniami v rámci firemnej AD, správa identít sa rieši potom najčastejšie cez on premise identity alebo hybrid identity typické pre Azure, • diskové polia na softvérovej báze pomocou Windows File Server Cluster, ktoré obslúžia aj nemanažované disky, akoby boli v diskovom poli RAID s pokročilou správou, architektúru výrazne zlepšuje niekoľko SSD diskov. • Web ApplicationProxy (od R2) publikovanie aplikácii do Internetu tak, aby boli ovládateľné skrz tablet...

3.3.4 Windows Power Shell Microsoftu sa vo flamewars Windows vs. Linux dlhodobo vyčíta, že ide o prostredie určené len na klikanie myšou v Graphical User Interface (GUI) a správa systému pomocou príkazov nie je efektívne možná. Naopak Linux laikov odradzuje sústredením na Command Line Interface (CLI). Rozumný bliss point sa hľadá ťažko. Microsoft od roku 2006 integroval do prostredia Windows nový Power Shell (PS). Na rozdiel od známej príkazovej riadky Command integruje skripty, nové príkazy tzv. cmdlets, do istej miery dovoľuje programovať, prepojuje samostatné Microsoft technológie .NET, COM, WMI, XML a Active Directory [Holmes, 2013]. Power Shell teda umožňuje lokálnu aj vzdialenú správu AD na Windows Serveri pokročilím skriptovacím a príkazovým tzv. interaktívnym režimom. V AD musí byť povolená možnosť Active Directory Service Interface a svoje pokusy môžeme skúšať voči Active Directory Lightweight Services (AD LDS) namiesto produkčnej doméne AD. Na obr. 3.3.4.1 je príklad užitia PS v reálnom prostredí AD, príkazom zobrazujeme detaily o užívateľovi z domény, ktorá je špecifikovaná v príkaze pomocou konkrétnych atribútov. Takto konštruované príkazy v Linuxe používame bežne. V PS je však nutné

32 strážiť možnosť automatického spúšťania skriptov (executionpolicy Restricted, set-executi- onpolicy allsigned), ktoré by mohli byť potenciálne nebezpečné v tak citlivom prostredí ako je DC.

Obrázok 3.3.4.1: Výpis všetkých atribútov užívateľa lukas v AD pomocou nástroja repadmin. Zvýraznený je atribút supplementalCredentials, ktorý obsahuje Kerberos tiket.

PowerShell vo Windows 2012 prináša niekoľko noviniek [Kantůrek, Knotek, 2014]: • použitie integrovaného prostredia na skripty Windows PowerShell ISE: ◦ IntelliSense – ponúka rozdelenie cmdletov na moduly podľa použitia (k správe účtov, Group Policy, Active Directory…) a zobrazí očakávaný kód, povinné para- metre, ◦ Code Snippets – použitie pokročilých programovacích skriptovacích funkcií, cyklov, podmienok bez nutnosti si pamätať konkrétnu syntax, • cez 3000 cmdletov, samostatných príkazov, ktoré niečo ovládajú, spustia apod., • webová prístupnosť v prehliadači, v zmysle pripojenia z iného zariadenia a to aj v prostredí s nízkou spoľahlivosťou spojenia, napr. je možné spustiť dávku príkazov, ktoré sa vykonávajú v dlhšom horizonte a nie je nutné byť pripojený do vnútor- ného prostredia, alebo ak pripojenie momentálne zlyhalo a toto je možné obnoviť, z bezpečnostného pohľadu sa nastavuje zvlášť pre jednotlivých správcov a pre jednotlivé servery, • plánovanie úloh priamo z prostredia PowerShellu.

Domnievame sa, že Microsoft vytvorením PowerShellu (11/2006), posledná verzia 4 (10/2013) veľmi výrazne prospel možnostiam administrácie serveru, centrálnej správe a to hlavne v duálnom prístupe cez GUI alebo skriptovací, pokročilý režim práve v PS. Nakoľko je cesta ovládania serveru cez množstvo nástrojov v úvode mätúca, rôznorodá, tak príkazy a parametre v PS túto rozdrobenosť zjednocujú.

33 4 freeIPA

Z angl. slov free, identity, policy a audit vznikol open-source projekt freeIPA17. Ide o komplexný manažment identít, užívateľských politík a auditu, pričom posledná časť názvu je zatiaľ neurčitá, na oficiálnom webe18 uvádzaná ako trust, čiže práca s účtami a nastavovanie dôveryhodnosti v sieťovom prostredí. Ide o nesporne rozsiahly soft- vérový projekt, ktorý sa snaží vytvoriť jeden súdržný systém pre centrálnu správu v linuxovom prostredí, nielen overovanie užívateľov, overenie počítačov, ako sme ho poznali doteraz na lokálnych staniciach alebo miestnych linuxových serveroch. freeIPA spadá do pôsobnosti softvérovej firmy Red Hat a s ňou spojených linuxových živých distribúcii (Fedora, CentOS, RHEL). Ucelený prehľad ďalších distribúcii, kto ďalší vyšiel z Red Hatu, možno nájsť v schéme [Lundqvist, 2012]. Obecnú doménovú štruktúru, ktorá je základom centralizovanej správy z logického pohľadu, sme už popísali v úvode kapitoly 3 o Active Directory (AD), tu na ne voľne nadvä- zujeme, ich znalosť je však nutná z predošlého textu. Rovnaké ciele, aspoň z pohľadu objektov, ich administráciu do skupín a riešenie prenositeľných práv, oprávnení sa snaží dosiahnuť aj freeIPA. Taktiež rieši adresárovú štruktúru na uchovávanie informácii o užívateľoch, má schopnosť ich autentifikovať a overenú identitu formou tiketov ďalej predávať v rámci siete. Rieši politiky, synchronizáciu času v sieti ai. Obsahuje aj veľmi pokročilé serverové služby ako sú menné služby, vydá- vanie certifikátov. Ide teda o integračné riešenie existujúcich protokolov a linuxových nástrojov, ktorých prehľad popisujeme v kapitole 4.2. Vzťah vybraných linuxových distribúcii a dopad Red Hatu na trh Linuxu je popísaný samostatne v kapitole 4.3, aby linuxový svet týchto potenciálnych serverov s centralizo- vanou správou pomocou freeIPA bolo možné aspoň prehľadom porovnať s Windows Server a jeho správou Active Directory v kapitole 3.3. freeIPA je vyvíjaná pod open-source licenciou GPLv319 ako otvorený softvér, teda jeho zdrojové kódy sú voľne dostupné, preto je prenositeľná. Vstupné náklady môžu byť minimálne, pokiaľ zvolíme pre server voľne dostupnú distribúciu, napríklad Fedoru alebo CentOS. Avšak v doménovom prostredí vysokého rizika a bezpečnostných politík je nutné uvážiť aj niektorý komerčný Linux s vývojárskou a telefonickou podporou užívateľom, s biznis garanciami, napríklad Red Hat Enterprise Linux (RHEL). Licenčnú politiku Red Hat Subscription Model a možnosti podpory Support-level Access uvádzame v kapitole 4.3.1. Red Hat k freeIPA poskytuje veľmi živý devel/user maillisting, ktorý sme viac rokov sledovali –

17 Vzhľadom na jednotnosť textu používame i v ďalšom názov s minuskulou tak, ako je v logu. 18 http://www.freeipa.org/page/Main_Page 19 http://www.gnu.org/licenses/gpl-3.0.html

34 najčastejšie tu správcovia z rôznych firiem riešili svoje problémy s inštaláciou a jej použitím, vývojári navrhovali, diskutovali. Red Hat projekt freeIPA vyvíja od roku 2007, testuje a dokumentuje, propaguje, významnou mierou sa na tom podieľa práve brnenská pobočka firmy, českí tím je podpísaný pod mnohým. Súčasná verzia freeIPA v4 (7/2014). Doporučené zdroje – freeIPA je prehľadne popísaná na projektovom webe20, hlavne v historických súvislostiach, jej konfiguráciu možno nájsť aj v kompaktnom manuáli [Ballard, Čapek a Petrová, 2015a]. Túto kapitolu sme napísali v rovnakej štruktúre ako Active Directory, aby boli uvedené tvrdenia o systémoch, ich vlastnosti priamo porovnateľné! V texte priebežne uvádzame spätnú väzbu.

4.1 Správa linuxového prostredia

4.1.1 Užívatelia a skupiny Užívateľ a jeho zaradenie v OS sú základné premisy ďalšej práce na stanici s Linuxom, ako tomu bolo aj vo Windows. Existencia užívateľskému účtu je nevyhnutná, užívateľ tým získava oprávnenia. Základné údaje o užívateľoch Linux uchováva v súbore /etc/passwd a v chránenej podobe potom ich heslá ako solené hashe v súbore /etc/shadow. Ako sme už uvádzali vo Windows sa užívatelia rozlišujú podľa Security Identifier (SID), v Linuxe je to User Identifier (UID) a Group Identifier (GID). Podobne ako vo Windows si OS udržuje prehľad o spus- tených procesoch, ich pôvodcoch, manažuje prístup k súborom, aplikáciam práve podľa užívateľského účtu. Zvláštne postavenie super užívateľa, ktorého oprávnenia sa nekon- trolujú tu má užívateľ root. Prehľad položiek týchto súborov uvádzame v tab. 4.1.1.1 a tab. 4.1.1.2. V tomto súdime linuxový svet ako oveľa prehľadnejší, súbory ide jednoducho vypisovať (pri správe sa pohy- bujeme ako root, samozrejme), dajú sa s nimi prevádzať zreťazené príkazy, filtrovanie apod., takto prehľadné informácie vo Windows získame len ťažko, aj keď zlepšenie priniesol PowerShell, tak nad textovými dátami nepracujeme. login šifrované heslo alebo x UID GID užívateľské užívateľský interpret ako odkaz na shadow meno domovský príkazov adresár fedor: x: 1000: 1000: fedor: /home/fedor: /bin/bash root: x: 0: 0: root: /root: Tabuľka 4.1.1.1: /etc/passwd – výpis údajov lokálneho užívateľa fedor a správcu root.

20 http://www.freeipa.org/

35 login solený hash hesla dátum min. doba max. doba doba platnosť pre už exspirácia zmeny platnosti platnosti varovania exspirované účtu hesla hesla hesla platnosti heslo hesla fedor: $6$GeZ$c5vnaoQ 16571: 0: 99999: 7: : : Juj2J/0T7mmhP16 pN7Mu7Okau51G B.Mpq542SLfTdY um3oNYlxlXJ8O XPOfBaglEx7yC NP6xv50PZG/: Tabuľka 4.1.1.2: /etc/shadow – výpis údajov lokálneho užívateľa fedor.

Užívatelia serverov sú uložení v miestnych súboroch serveru, pričom servery s lepším hardvérovým vybavením umožňujú až niekoľko násobnú úroveň multi-user prístupu, každý užívateľ má svoj domovský adresár, kontext, pridelené zdroje atď. K prístupu na server by sme chceli doporučiť používanie ssh kľúčov, pretože autentifikácia voči serveru môže byť procesne jednoduchšia, rýchlejšia. Vyššiu formu jednotnej autentifi- kácie a jednotného užívateľského mena, ďalšie autentifikačné moduly vysvetľujeme ďalej. V priebehu kapitoly 3.1.1, o užívateľoch Windows na str. 13, sme načrtli jednu zaujímavú súvislosť – nakoľko sa pojmy zo sveta počítačov prenášajú aj do sveta telefónov? Deje sa tak preto, lebo operačné systémy v nich môžu byť rovnako ako v počítačoch postavené na Linuxe. Zmienili sme rootovanie, išlo o rootovanie Adroidu. V Linuxe sa tiež už asi 15 rokov používa aj tzv. povinné riadenie prístupu Mandatory Access Control (MAC), ktoré prinieslo významné zvýšenie bezpečnosti systému na celkom nízkej úrovni, integ- rácia do jadra systému (kernel). Toto riadenie prístupu sa objavilo v Security-Enhanced Linuxe (SELinux) a Red Hat má na jeho vývoji veľký podiel. Užívateľom sa tak už nielen kontroluje, či niekam môžu nahliadnuť – Discretoniary Access Control (DAC), ale aj to, či má ich proces (na úpravu súborov napríklad) s týmto súborom vôbec niečo spoločné. SELinux sa už nachádza a uplatňuje aj v Androide21. V Linuxe sa narozdiel od Windowsu vytvára pre každého užívateľa primárna skupina Group, ktorá nesie jeho meno, až potom tie skupiny sekundárne, ktoré zhrňujú viacero užívateľov s rovnakými oprávneniami v linuxovom svete. Výpis informácii o skupine môže vypadať, ako je uvedené v tab. 4.1.1.3. meno skupiny šifrované heslo alebo x GID zoznam ďalších členov skupiny, ako odkaz na shadow oddelení čiarkou fedor: x: 1000: wheel: x: 10: fedor kvm: x: 36: qemu Tabuľka 4.1.1.3: /etc/groups – výpis údajov lokálnej skupiny fedor, ktorá nemá viac členov ako seba a servisnej skupiny wheel (špeciálne privilégiá konať ako správca), ktorá má člena fedora a servisnej skupiny kvm (hypervizor virtuálizácie) s členom qemu (nástroj).

21 http://source.android.com/devices/tech/security/selinux/

36 Svet administrácie Linuxu je obsiahly, nie je účelom tejto práce ho popisovať na lokálnej stanici, ďalšiu správu možno naštudovať v [Mallett, 2014]. V serverovom prostredí je pre Linux typické používať centrálne databáze ako OpenLDAP na správu informácii o užívateľoch alebo Kerberos na single sign-on autentifikáciu.

4.1.2 Pluggable Authentication Modules Systém, ktorý sa v linuxových OS stará o tieto rozširujúce možnosti autentifikácie sú moduly Pluggable Authentication Modules (PAM). Systém týchto modulov bol prítomný už v pôvodnom komerčnom UNIXe a v súčasnosti sa vývoj, prítomnosť jednotlivých modulov líši podľa konkrétnej distribúcie, hlavný vývoj modulov je sústredený v Red Hate. Moduly ako také je možné v autentifikačnom postupe zoradiť, určiť ich prioritu, v akej budú užíva- teľovi predkladané, tzv. PAM reťaz. V konfigurácii sa určuje aj povinnosť ich splnenia užívateľom, prípadne počet možných pokusov. Niektoré moduly sú informačné ako napr. správa dňa, počet prijatých emailov, zmena domovského adresára a i. [Kasprzak, 2010]. Jednotlivé programy, ktoré užívateľa autentifikujú, musia byť istým spôsobom modi- fikované a prelinkované s PAM knižnicou tak, aby svoju pôvodnú funkciu overovať heslo, teraz rozšírili aj na ďalšie pokročilejšie operácie – konverzáciu s užívateľom vo viacerých krokoch, overovanie, vypisovanie apod. Hlavnou výhodou, ktorú PAM priniesol je to, že jednotlivé programy nemusia riešiť správnu implementáciu autentifikačné schémy samy, ale spoľahnú sa na implementáciu v PAM. Behom autentifikačného procesu sa rozlišujú tietointerface: [Ballard, Čapek a Petrová, 2015b, s. 129]: • account – overuje sa prítomnosť užívateľa v systéme, oprávnenie sa prihlásiť v daný čas, exspirácia; • auth – samotná autentifikácia, požaduje sa a overí sa platnosť hesla, prípadne biometriky, čipovej karty, PINu apod., v tejto fáze je možné nastaviť prihlasovacie údaje, ako je napríklad členstvo v skupinách alebo kerberosie tikety; • password – prevádzajú sa zmeny v autentifikácii, pokiaľ bolo heslo exspirované môže sa povoliť jeho posledné použitie a vyžiadať zadanie hesla nového; • session – konfiguruje a spravuje sa užívateľská relácia samotná, moduly stýmto rozhraním môžu tiež vykonávať ďalšie úlohy, ktoré sú potrebné po získaní prístupu, ako je pripojenie domovského adresára, poštovej schránky, či nastavenie limitov a obmedzení.

Pokiaľ by sme mali porovnať PAM s freeIPA, sú tieto moduly jej intergrálnou súčasťou, teda je možné pomocou modulov integrovať dnes najčastejšie autentifikačné zariadenia - čítačka prístupových kariet, čítačka odtlačkov prstov, či overenie užívateľa voči niektorej centrálnej databáze užívateľov ako sú LDAP, či tikety Kerbera.

37 4.2 Technológie freeIPA

4.2.1 Vízia Identity Managementu V niektorých zdrojoch k freeIPA sa možno stretnúť s označením Identity Management (IdM). V tomto manažmente ide o definíciu potrieb – identifikácie objektov, autentifikácie, autorizácie, oprávnení skrz celý systém podniku, aby sa zvýšila bezpečnosť a produktivita, pri ktoré freeIPA naplňuje. Podľa príručky RHEL 7, ktorá popisuje doménové služby, autentifikáciu a politiky, je úlohou centralizovanej správy zjednodušiť režijné náklady so správou linuxových systé- mov. Užívatelia, počítače, služby a politiky sú nastavené na jednom mieste pomocou jedných a tých istých nástrojov. Všetky zdroje sa môžu centralizovane nastaviť už tým, že sa pripoja do domény. freeIPA/IdM je postavený na 3 princípoch [Ballard, Čapek a Petrová, 2015a, s. 5]: • Vytvára sa linuxová doména z linuxových nástrojov. Doména aj jej klienti majú OS Linux alebo Unix. Dokonca sa dokážu synchronizovať voči Active Directory vo svete Windows Server domén, ale nie je vhodný nástroj na správu Windows klientov. Slúži linuxovým doménam. • Centralizuje správu identít a politík, uľahčuje prácu správcov. • Systém je vytvorený na existujúcich natívnych linuxových aplikáciach a proto- koloch, voči ktorým už panuje dôvera medzi užívateľmi Linuxu. I keď IdM svojou komplexnosťou predstavuje množstvo nových procesov a implementácii, tech- nológie v jeho základoch sú už overené.

Vlastnosti klientov v IdM [Ballard, Čapek a Petrová, 2015a, s. 13]: • Klientom domény, stanicou môže byť ktorýkoľvek počítač s Linuxom/UNIXom, ktorý má nastavené služby siete, autentifikáciu voči doménovému serveru. • Na klientovi nie je potrebný démon, ani inštalácia konkrétneho produktu, stačí služby nastaviť systémovo.

38 4.2.2 Hlavné komponenty

Adresárová služba užívateľov a služieb 389 Directory Server LDAP

Autentifikácia, Single Sign-on MIT Kerberos v5 Kerberos

Certifikačná autorita, X.509 certifikáty Dogtag Certificate PKI

Webový server Apache httpd HTTP Správa pomocou GUI a príkazov vlastný web design WebUI, CLI

Doménové menné služby Berkeley Internet Name Domain (BIND) DNS

Sieťový protokol na synchronizáciu času Network Time Protocol NTP

Tabuľka 4.2.2.1: Prehľad princípov, konkrétnych implementačných nástrojov vo freeIPA a skratka používaná v našich diagramoch.

Najdôležitejšiu komponentu freeIPA tvorí spoločná adresárová štruktúra vytvorená pomocou protokolu LDAP (OpenLDAP), v ktorej budú centrálne uložené informácie o objektoch domény – užívatelia, stanice, nastavenia. O služby autentifikačné sa stará MIT implementácia Kerbera, okrem doménového mena (ipa.example.fake) má tak server aj tzv. realm Kerbera (@EXAMPLE.FAKE). Na správnu funkciu musí byť v spravovanom sieťovom prostredí synchronizovaný čas, pretože tikety majú svoju platnosť.

Obrázok 4.2.2.1: Obecná štruktúra freeIPA a jej správcovské komponenty. Server synchronizácie času (NTP), webový server (HTTP), adresárová služba (LDAP), správa freeIPA príkazmi (CLI) alebo cez web (WebGUI), single sign-on služba (Kerberos) a vydávanie certifikátov vlastnou certifikačnou autoritou (PKI)

39 freeIPA ďalej poskytuje nevyhnutné sieťové služby ako synchronizáciu času Network Time Protocol (NTP) a od druhej verzie aj menné služby Domain Name Services (DNS). Podpora certifikačnej autority a infraštruktúry verejných kľúčov Public Key Infrastructure (PKI) pomocou Dogtag Certificate System je dnes už taktiež zahrnutá. Pomocou freeIPA je tiež možné vydávať certifikáty. Prevažuje konfigurácia celého integračného prostredia príkazmi v bashi Command- line Interface (CLI). Tieto príkazy sú veľmi komplexné a bohaté po stránke parametrov aj atribútov, viz obr. . Pre užívateľa je nemenej dôležitý interaktívny režim, keď sa príkaz prevádza, požiadavky a otázky na užívateľa sú jednoznačné, s východzími nastaveniami a pomerne dobre vysvetľujúce všetky chyby. freeIPA implementuje aj Kerberos cez HTTP (MS-KKDCP), autentifikáciu One-time Password (OTP) formou FreeOTP aplikácii. Tieto sú dostupné na zariadenia užívateľov s Androidom alebo iOSom, prípadne je možné použiť Yubikey ako univerzálny USB token na dvojfaktorovú autentifikáciu pomocou jednoduchej biometriky otlačkom prstu. Dvojfak- torové overenie v tomto prípade znamená zloženie hesla z jednorázového kódu poskytnutého z OTP a súkromnej tajnej časti hesla užívateľa. Poznáme ju aj ako sled hesla a overenia skrz SMS alebo vo firemnou prostredí kedysi populárne RSA tokeny s malým displejom, kde sa časť hesla zobrazovala.

4.3 RHEL, Fedora a ďalší Vo svete Linuxu nie je tak jednoduché a jednoznačné povedať, o ktorú verzia systému sa jedná, koľkátou je v poradí, ako sme uviedli v konkrétnom prípade Windows Serveru 2012. Dochádza k premenovaniu projektov, vyhasnutiu živosti tej ktorej distribúcie. Situáciu komplikuje o to viac fakt, i keď v pozitívnom duchu, že ide o svet otvoreného softvéru, teda zdrojové kódy sú dostupné. freeIPA by mohla byť v mnohých distribúciach, v rôznych Linuxoch. My sa sústredíme na použitie v distribúciach odvodených z Red Hatu, preto je nutné uviesť ich kontext a ponuku. Rozšírenosť Red Hat distribúcii už aj v minulosti potvrdzuje staršia kniha z O'Reillyho vydavateľstva [Smith, 2006, s. 11]: „Red Hat je zďaleka najrozšírenejšou linu- xovou distribúciou v Severnej Amerike, zvlášť pokiaľ sa pod Red Hat započítate i Fedoru,“ prehľadne a vecne uvádza aj: „Fedora Core je voľne šírená verzia Red Hat Linuxu. Jej vývojový cyklus je kratší než vývojový cyklus Red Hat Linuxu a distribúcia slúži čiastočne ako testovacie prostredie balíkov určených pre Red Hat Linux. Fedora je dobrou voľbou pre tých, ktorí majú radi Red Hat, nemajú dosť peňazí na komerčnú distribúciu a zaobídu sa bez oficiálnej podpory.“ Tieto slová platia aj po desiatich rokoch [Red Hat, 2014], akurát došlo k premenovaniu platenej verzie Red Hat Linux na Red Hat Enterprise Linux (RHEL) vo verzii 7 a Fedora je bez „core“ už vo verzii 21. Podľa článku hodnotiaceho nasadenie Linuxu obecne v rôznych sektoroch [Compa- reBusinessProducts.com, 2010]: „Ministerstvo obrany US predstavuje najväčšiu inštalačnú

40 základňu Red Hat Linuxu na svete… a predstavuje najväčšieho zákazníka“. Tieto infor- mácie potvrdzuje aj Red Hat vo svojich propagačných materiáloch. Obecne patrí medzi základné východzie linuxové distribúcie (popri Debiane, Slackware) a technológie z jeho základu nájdeme v mnohých ďalších odvodených distribúciach (CentOS, Scientific), či komunitnej distribúcii (Fedora) [Lundqvist, 2012]. Bázový rozdiel medzi použitím distribúcie Fedora a RHEL je nutné vnímať v niekoľkých ohľadoch. Fedora je distribúcia, ktorá je dostupná zdarma, avšak býva uvoľ- ňovaná podľa nášho názoru až príliš často – Fedora 19 (7/2013), Fedora 20 (12/2013), Fedora 21 (12/2014), Fedora 22 (5/2015). Kto v minulosti skúsil upgrade systému na vyššiu verziu, to už opakovať nechce, na druhú stranu žiť v distribúcii, ktorá zastaráva nejde, balíčky prestanú byt' aktualizované, bugy budu zatvorené – ide sa ďalej, bohužiaľ. Ako sme už písali zo zdroja desať rokov starého, v politike Red Hatu pretrváva použitie Fedory ako sandboxu, miesta na pokusy a ďalší vývoj. Uchytené a overené balíčky, nové funkcie sú potom prevzaté do platenej distribúcie RHEL. V tomto ohľade Red Hat ponúka úplne inú ligu na trhu linuxových operačných systémov. Je nutné si uvedomiť, že ide o profesionálny produkt, ku ktorému náleží podpora, dokumentácia, prioritná aktualizácia. Red Hat i po vydaní novšej verzie, a že ich nie je toľko, naďalej spätne garantuje podporu verzii RHEL 5 (už od 3/2007), RHEL 6 (11/2010), RHEL 7 (6/2014). Minorovým verziám (7.1) dáva načas (až 3/2015). V dobe uvedenia dnes ešte podporovaného RHEL 5 sa používala dnes už zabudnutá Fedora Core 6, a toto dokazuje zásadné rozdiely medzi týmito distribúciami.

4.3.1 Red Hat Subscriptions Model Niekoho prekvapí, že sa v sieťovom prostredí dá za Linux platiť. Obecný trend užívateľ- ských a komunitných distribúcii, ktoré vznikajú vďaka otvorenému zdrojovému kódu, neplatí vo firemnom prostredí. Tu už nie je možné sa ako produktívna firma spoliehať len na podporu zo strany komunity, wiki, diskusí, či know-how sebe lepšieho správcu linu- xových serverov, uplatňujú sa princípy známe z korporácii – odhad realizácie IT riešenia, ponuky, nákup, garancie, podpora, starostlivosť, B2B. Preto vedľa zdarma dostupných distribúcii odvodených z Red Hat, možno použiť plnohodnotný systém Red Hat Enterprise Linux (RHEL), ktorý sa predáva a jeho používanie licencuje. Licenčnej politike tzv. Red Hat Subscriptions Model rozumieme v preklade ako záväzku, či upísaniu sa. Zákazník za ročný poplatok získava prístup k balíčkovým repozi- tárom konkrétnej verzie RHEL, z ktorých svoje inštalácie môžeme aktualizovať. Red Hat rozlišuje v licenčnej politike hlavne časový údaj – a to rok alebo tri roky, na koľko sa zákazník zaväzuje. Počas tohoto obdobia má zákazník technicky i právne, licenčne dovolený upgrade i downgrade na všetky aktuálne podporované verzie (dnes RHEL 5, RHEL 6 a RHEL 7). Pri inštalácii RHEL sa zohľadňuje počet procesorov, každý nadlimitný sa znova platí. Cena22 RHEL Desktopu23 do 8 GB RAM 1.300 Kč, pracovná stanica 4.600 Kč, s podporou 7.700 Kč.

22 Ceny sú orientačné, oficiálna politika je nechať si vypracovať návrh realizácie od Red Hat partnerov a samostatných poradenských firiem v oblasti IT, uvedené ceny sú z prehľadného e- shopu zdroj http://redhat.initshop.cz/ 23 http://www.redhat.com/en/files/resources/en-rhel-7-desktops-12006017.pdf

41 Subscription sa líši aj do level/úrovne funkčnosti pre server, kedy nižšie úrovne ponúkajú základ, vyššie napr. prístup k pokročilej virtuálizácii, ďalšie moduly, manažment. Ďalej sa subscription líši, čo do úrovne podpory Support-level Agreements (SLA), inštalácia RHEL Server24 – bez podpory (9.000 Kč), 12 hodinová podpora v pracovnom týždni cez formulár či telefón (20.000 Kč) a najvyššia garantovaná odozva do hodiny (33.500 Kč). Oficiálny materiál o RHEL Server uvádza podporu Identity Managementu, na trhu sú však aj produkty adresárového servera (130.000 Kč), vrátane replikácie a už veľkej doménovej štruktúry (390.000 Kč). Je škoda, že tieto informácie nie sú celkom dobre verejne dostupné, nedajú sa jedno- značne porovnať a overiť.

4.3.2 Education level subscription MSDN pre Windows umožňuje lacnejšie, či úplne nenákladové zaobstaranie inštalácii OS, v prípade RHEL možno zaistiť verzie pre vzdelávacie inštitúcie. Tu sa nám podarilo zistiť náklady dopytovou komunikáciou s dodávateľom, náklady však nie sú nulové – za ročný subscription pre RHEL server bez podpory (2.300 Kč) a skupinu Rhel desktop (1.100 Kč) na tridsať staníc – za učebňu je to 36.000 Kč ročne, trojročný level priemerne k 100.000 Kč.

4.3.3 Shell Prostredníctvom shellu (interpret príkazov) je správa Linuxu a linuxových riešení veľmi prehľadná, pre dlhodobých užívateľov celkom bežná. Príkazy sú štrukturované na para- meter a atribút, výstupy a vstupy je možné prepojiť, v bashi skriptovať atď. Takéto vlastnosti využívame v centralizovanej správe pri každej jednej činnosti s viacerými vstupmi, pridávanie užívateľov apod. História shellu siaha ďaleko pred zave- denie Power Shellu vo Windows, i keď toto názvoslovie Microsoftu môže byť mätúce, vytvárať dojem lepšieho interpretra, pritom je to jednoznačne naopak – bash víťazí, „jednoduchosťou“.

24 http://www.redhat.com/en/files/resources/en-rhel-7-server-datasheet-12182617.pdf

42 5 Porovnania

Súčasťou tejto práce je popis niekoľkých bázových scenárov nasadenia, použitia serverov s centralizovanou správou v prostredí Windows a Linuxu – Active Directory vs. freeIPA. Množstvo našich pokusov nie je jednoduché zatriediť do vytýčených scenárov. a technológie skryté na pozadí týchto rozsiahlych systémov sme uviedli v predošlých kapitolách, preto je väčšina porovnaní terminologických explikácii prostá.

5.1 Scenár – Doménové prostredie Ide o východzí scenár pre všetky pokusy, v ktorom nasadíme základné prostredie oboch typov serverov pomocou virtualizačných nástrojov. Zhodnotíme jednoduchosť inštalácie, priebeh, výsledok, serverov aj klientov. Nastavíme servery a pridáme doménového užívateľa. Chceme vzťahy server-klient, server-klient.

Úspech scenára je autentifikácia nového doménového užívateľa na doménovom klientovi, na ktorom nebol nikdy predtým prihlásený. Prebehne komunikácia klienta so serverom, získanie informácii z domény.

Do východzie prostredia boli zvolené servery Windows Server 2012 Datacenter (na trhu od 9/2012) a Fedora 21 Server (12/2014), virtualizačné prostredie Oracle VirtualBox 4.3.16 (9/2014). Klienti Windows 8 (10/2012) a Fedora 21 (12/2014), CentOS 6.6 (10/2014). Šlo o 64 bitové verzie, ale Windows 8 a Fedora boli x86. Sieťové prostredie v rámci VirtualBox internal LAN riešil softvérový routrom/firewallom pfSense 2.2.2 (4/2015).

5.1.1 Poznámka k sieti Vo virtualizačnom prostredí sme na radu niekoľkých diskusných fór použili naviac v konfi- gurácii zmienený softvérový router pfSense postavený na FreeBSD. Poskytuje možnosť nastavenia služieb DNS, DHCP, VPN atď. a svoju vlastnú vzdialenú správu z WebUI. Bežal v samostatnej virtuálke, vždy spustenej. Manažoval internú virtuálnu LAN, cez dve sieťové rozhrania – prvé do LAN a druhé do WAN – do Internetu v hostiteľskom OS. Podobná možnosť správy už dávno mala byť v samotnom VirtualBoxe. Ich súčasné riešenie rozsiahlej siete 10.0.0.0/24 s interným DHCP nevyhovovalo našim scenárom. Nastavenie sieťového adaptéru vo všetkých spravovaných virtuálkach viz obr. 6.1.1.

43 5.1.2 Virtuálne prostredie

Obrázok 5.1.2.1: Zoznam virtuálnych serverov a klientov, nastavenie internej LAN (v krúžku).

5.1.3 Active Directory Server sme konfigurovali ako (1) Active Directory Domain Services (AD DS). Vytvoril sa nový doménový radič – buď ako člen existujúcej domény, nový potomok existujúcej domény alebo nový domain forest – v našom malom testovacom prostredí to bol teda forest. Radič môže byť konfigurovaný s obmedzeniami staršej verzie Windows Server 2008, alebo len na čítanie, čo je výhodné pri inštalácii radiča určeného len na replikáciu. Ďalej sme vybrali rolu (2) Domain Name Services (DNS), pretože klienti majú v reálnej sieti s DC častú komunikáciu a táto služba sa doporučuje ako primárna rola DC. Pridali sme užívateľa (lukas) v základnej správe AD DS, dali mu atribúty. Inštaláciu klienta Windows 8 (fi-win8) nebudeme rozoberať, nie je to účelné. Pripo- jenie do domény prebehlo úspešne, novo vytvorený užívateľ (lukas) na DC sa poprvýkrát prihlásil bez problémov. Atribúty z jeho mena sa preniesli z radiča na stanicu a zobrazili.

44 5.1.4 freeIPA Server freeIPA sme nainštalovali na edíciu Fedora 21 Server, toto nové značenie edícii už aj podľa účelu (nielen spiny, zmenené window managery) môže byť mätúce! Podľa nášho názoru nám takáto edícia reálne nič navyše nepriniesla, proklamovaný serverovský manager cockpit (údajne dokáže manažovať aj freeIPA) nebol nainštalovaný. Úsmevné je aj to, že pred pripravená edícia na servery, pri inštalácii centralizovanej správy (povedzme, že je to už najviac, čo zo serveru ide získať) aj tak pri inštalácii free-ipa- server, čo predstavovalo asi 300 nových balíčkov, chcela ďalších +230 MB. CentOS 7 stiahol ipa-server s rovnakým počtom balíčkov za +160 MB. Ide o hrubé čísla, ale aj z tohto dôvodu sme sa rozhodli v ďalšom, pokiaľ to bude možné, server sústrediť na túto distribúciu. Pri inštalácii serveru freeIPA sme zistili silnú závislosť na DNS záznamoch, ich kontrolu démonom BINDu. Pri inšpirácii z tohoto návodu [Adamson, 2012]25 sme „ohli“ nastavenia DNS a vytvorili si vlastné záznamy (example.fake.zone a 192.168.1.zone), v ktorých sme potom už server rozbehli. Našou výhodou bola prítomnosť dvoch záložných DNS (pfSense, dokonca spustený radič AD z iného pokusu), takže sa stanice mali koho dotazovať (+google 8.8.8.8, keď naše pokusy boli naozaj bezvýchodné).

/var/named/example.fake.zone $TTL 3D @ IN SOA ns1.example.fake. hostmaster.example.fake. ( 201107111 ; serial# 3600 ; refresh, seconds 3600 ; retry, seconds 3600 ; expire, seconds 3600 ) ; minimum, seconds

NS ns1 ; Inet Address of nameserver example.fake. MX 10 mail ; Primary Mail Exchanger ns1 A 192.168.1.200 server A 192.168.1.200 client1 A 192.168.1.201 client2 A 192.168.1.202 ipa CNAME server

; DNS auto discovery of services _ldap._tcp SRV 10 10 389 server.example.fake. _kerberos._udp SRV 10 10 88 server.example.fake. _kerberos._tcp SRV 10 10 88 server.example.fake.

/var/named/192-168-1.zone $TTL 2d ; 172800 seconds $ORIGIN 1.168.192.IN-ADDR.ARPA.

25 http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

45 @ IN SOA ns1.example.fake. hostmaster.example.fake. ( 201107111 ; serial number 3600 ; refresh, seconds 3600 ; retry, seconds 3600 ; expire, seconds 3600 ) ; minimum, seconds

IN NS ns1.example.fake. 200 IN PTR server.example.fake. 201 IN PTR client1.example.fake. 202 IN PTR client2.example.fake.

Scenár bol veľmi náročný na ustavenie funkčného úvodného nastavenia, pretože sme ho robili v obmedzenom virtualizačnom prostredí. Ťažké bolo všetko správne nachystať, zaheslovať (AD a jeho politika bezpečných hesiel z troch skupín znakov – nevypínali sme ju), rozdeliť a dodržovať IP adresy serverov, klientov. Windows Server sa inštaloval bez akýchkoľvek prekvapení. Možno len úsmevne – niekomu môže nevyhovovať Metro, je to neskutočne náročné vo verzii R1, ktorá vyšla z Windows 8 trafiť štart, či vypínanie. freeIPA sa inštalovala v poriadku, nepríjemné a dlho blokujúce akýkoľvek ďalší scenár bolo nastavenie samotného hostiteľského serveru, jeho sieťové rozhranie – aby bral našu fake doménu. Oba klienti sa do svojej domény prihlásili a noví užívatelia boli v poriadku autentifi- kovaní. Skúsili sme požiadať doménu o ďalšie mená a bolo nám odpovedané.

46 5.2 Scenár – Noví užívatelia a bezpečnosť Z východzej konfigurácie serverov v doméne sme porovnávali možnosti ďalšieho manaž- mentu skúška pridania viacerých užívateľov. Pokúsili sme sa tiež pridať novú stanicu do domény s dôrazom na bezpečnosť prevedenia!

Úspešné zvládnutí scenár je v prípade importu niekoľkých užívateľov a stanica bude v doméne bez možnosti vyzradenia hesla doménového administrátora.

5.2.1 Noví užívatelia V systémoch Windows Server je obvyklé nájsť rôzne silné nástroje/konzoly pre správu (.msc), ktoré z rôznych uhlov prístupu nastavujú to isté. K správe DC pribudol nový Active Directory Administrative Center, ktorý omnoho lepšie preväzuje potreby správy cez GUI a možnosti správy cez Power Shell (PS). Overili sme, že každá operácia prevedená správcom v GUI AD Administrative Center sa zaznamenávala a prevádzala na parametrizované príkazy v PS, viz obr. 5.3.1.1. Púšťanie skriptov na AD v GUI prostredí považujeme za nebezpečné, preto Microsoft pridal možnosť podpisovania skriptov a zaviedol politiku, ktorá ich spustenie zakazuje vo východzom stave. Ďalšie skriptovanie, množstvo parametrov, sme si nechali poradiť, z manuálov. Vo freeIPA stačilo pochopiť parametre, potom sme použili bash. Výhodnejšie bolo skúsiť WebUI. Princíp pridávania užívateľov v korporátivnom prostredí stojí na CSV súboroch, ktoré vygeneruje human resources, v tomto je potreba použiť PowerShell Pri štúdiu materiálov sme narazili na dôležitú bezpečnostnú hrozbu, že na neznámej stanici, ktorá má prísť do domény, sa bežne zadáva heslo admina domény, čo môže odchytiť malware. Preto je nutné nastaviť nového, obmedzenejšieho admina v doméne, ktorý túto operáciu prevedie, viz obr nižie. Korporatívne komplexné prostredie s preme- novanými adminami, a rozdelením staníc podla účelu viz obr. 5.3.1

Obrázok 5.2.1.1: Pridávanie stanice do domény v DC, nastavenie iného správcu ako by štandardne mal byť práve doménový administrátor 47 48 5.3 Scenár – Homogénne prostredie V tomto scenári sme previedli niekoľko administratívnych úprav východzieho domé- nového prostredia, pridali ďalšie servery a klientov, hľadali sme rozdielnosti v nastavení medzi verziami. Ide o centralizovanú správu toho istého (homogénneho) prostredia, aby sme ukázali, že je možné ich jednoducho spoločne spravovať, bez rozdielu.

Úspechom tohoto scenára bude rozbehnúť viac klientov, viac serverov a ich služby prepojiť, možno replikovať, možno aspoň zálohovať.

5.3.1 Active Directory Tam kde sme v úvodnom rozprávaní 3 kapitoly o Active Directory – svet, vlastne celý „les“, ktorý môže v tejto službe vzniknúť je obrovsky. Používa sa vo firemnom prostredí mnohých pobočiek, po celom svete. Závisí na veľkom počte doménových radičov, ktoré sa navzájom replikujú, migrujú apod. vzájomné ovládanie je možné skrz System Administration Center je možné konfigurovať jeden radič z druhého. Toto prostredie viz obr. 5.3.1.1 Tohoto riešenie sme z nedostatku RAM nepreviedli. Museli sme zvoliť inštaláciu s menšími nárokmi viz Server Core.

Obrázok 5.3.1.1: Náhľad na nový AD Administrative Center, ktorý prináša viac možností správy AD, v spodnej časti sa každá vykonaná udalosť prepísala ako skript do PowerShellu.

49 5.3.2 Windows Server 2012 Core Do východzieho doménového prostredia sme teda pridali k Windows Server 2012 druhú inštanciu – a to najnovšiu možnú verziu, druhé vydanie, ktoré malo priniesť nové funkcie v PowerShelli – Windows 2012 R2 Update (4/2014). Ide o snahu Microsoftu distribuovať ISO obrazy inštalácie s najnovšou sadou aktualizácii26 v zmysle ako býval Service Pack, čo ešte viac skomplikovalo názov „Windows Server 2012 R2 Datacenter Update 5CAL supported“ už takmer nerozumieme, viz distribúcie v kapitole 3.3.1. Pre Windows Server 2012 je východzou možnosťou inštalácia tzv. Server Core, teda len jadra OS s pridruženými službami. Vo väčšine prípadov si správca Windows prostredia volí GUI, my sme skúsili konfiguráciu servera pomocou príkazov. Nešlo o čisto textové užívateľské rozhranie, grafický režim bol načítaný, konfigurovalo sa príkazmi. Nový doménový radič, pretože sme zvolili neprezieravo forest, sa samozrejme „bil“ s už exis- tujúcim radičom z východzieho scenára, radiče AD sú v lokálnom prostredí často aj mennými službami či DHCP, preto ich existenciu ide dobre detekovať.

5.3.3 Windows 8 ako správca Overili sme aj možnosť pristúpiť na radič z Windows 8 klienta, nie remote desktop, ale ponúknutou „aktualizáciou“ od Microsoftu – priamo lokálnym nástrojom Remote Server Administration Tool. Prekvapila nás politika distribúcie nástrojov (utilít) ako aktualizácii (update) s typickým číslom KB*. Vyskytli sa problémy s autentifikáciou stanice voči Kerberu, čo pripisujeme nesprávnej virtualizácii – uloženie stavu virtuáliek a návrat po čase, teda strata synchronizácie, neplatnosť tiketu. Obrázok Windows 2012 spravovaný vo Windows 8 viz. 5.3.3.1.

Obrázok 5.3.3.1: Príprava vzdialenej správy Windows Server 2012 (radič fi-dc) sprístupnený na lokálnej stanici Windows 8.

26 http://blogs.windows.com/bloggingwindows/2014/08/05/august-updates-for-windows-8-1-and- windows-server-2012-r2/

50 5.3.4 freeIPA Pridať akéhokoľvek ďalšieho klienta do domény, trebárs bude inej verzie, čísla – nebol žiaden problém. Je pravdou, že sme skúšali východzie Red Hat distribúcie, teda Fedoru a CentOS, ale snažili sme sa overiť prístup z rôznych window managerov, z rôznych pôvodných zdrojov (iso, vha). Riešili sme aj inštaláciu na inú distribúciu, Ubuntu je tiež veľmi rozšírené, i keď sú tu isté nejasnosti s vlastníckou štruktúrou, a naše pochybnosti, či príliš časté vydávanie nových verzií (apríl, október, apríl atď.) nie je v serverovskom prostredí stability veľké riziko. Samozrejme verzia LTS (long term support) ale i tak sme moc neuspeli. Nešlo o nedostupnosť balíčkov freeIPA, ide skôr o našu neznalosť a neprehľadný systém konfigu- račných nastavení siete, pretože inštalácia servera freeIPA vyžaduje značné ohýbanie vrstvy LAN a služieb DNS, pokiaľ nemáme svoju naozajstnú DNS doménu. Veľmi oceňujeme kvalitu spracovania distribúcie CentOS, nakoniec sme freeIPA server prevádzkovali aj na ňom, bol oproti Fedore spoľahlivejší – bez prekvapení. Fedoru sa nám podarilo natoľko poškodiť, nevhodnou inštaláciou VirtualBox Additions27

27 Balík nepovinných doplnkov VirtualBoxu, ktorý úpravou jadra vo virtuálke umožní pokročilé presuny vstupov, schránky host <> hostiteľ.

51 6 Budúci vývoj

Na základe veľkého množstva súvislostí, ktoré sa v doménovom svete objavujú, je neľahké predpokladať budúci vývoj. Očakávame väčšie rozšírenie cloudu, ktorý by mohol byť dostupný na rôznych zariadeniach stále ľahšie a ľahšie, prívetivejšie a technicky jednoducho. Možno sa zmení aj jeho cenová politika (pretože dnes je Microsoft Azure za časové poplatky), ostatné riešenia od Amazonu Elastic Compute Cloud 2, či Red Hat Open Stack sú známe v technickom svete veľkých riešení na clustry. Vo svete hardvéru serverov je vývoj natoľko rýchly, že niektoré stroje už počítame na jednotky, vo virtualizácii platíme za nody, sme schopní nainštalovať radu serverov aj lokálne. S takouto rozsiahlou inštaláciou súvisia doménové služby, centralizovaná správa. Domnievame sa, že bude

6.1 Azure Active Directory

Obrázok 6.1.1 Vzťah Web Application Proxy (uprostred dvoch kruhov) na prostredie AD. Užívateľ skrz svoje zariadenia a cloud pristupuje k uzavretému firemnému prostrediu, za pomoci proxy serverov alebo federovaných služieb AD [zjednodušené z Kantůrek, Knotek, 2014b].

Pôvodným zámerom služby Windows Azure (2008) bolo poskytovať online priestor pre vývojárov, fyzicky umiestnený v datacentrách Microsoftu, kde by mohli bežať ich

52 projekty, webové a databázové servery. Dnes, už rok po premenovaní na Microsoft Azure (2014), je v tejto službe možné spravovať vlastné virtuálne stroje, kupovať si priestor k zálo- hovaniu, služba už tvorí solídny základ cloudu. Technicky ju zabezpečuje virtualizácia pomocou Microsoft Hyper-V, prítomné sú aj ďalšie automatizačné, migračné a samoobs- lužné nástroje v spojení s veľkou dostupnosťou cloudu.

6.2 Užívateľ v centre diania Z užívateľského pohľadu sa vnára Google Drive či OneDrive, akési jednoducho povedané spoločné úložisko. Dalo by sa premýšľať o propagácii a federovaní identít medzi týmito systémami tak, aby užívateľ mal len jednu online identitu. Dnes je ňou emailová adresa, pretože je unikátna, možno to do budúcnosti budú firemné účty, osobné identifikačné čísla, čokoľvek čo zároveň ochráni osobné údaje nositeľa a zároveň mu prácu s ICT sprí- jemní, zjednotí. Microsoft tomuto riešeniu už dnes hovorí Same Sign-on, všade rovnako pomenovaný.

6.3 Centralizovaná správa užívateľov Z pohľadu centralizovanej správy sa vývoj Microsoft doménových riešení pozvoľna uberá k hybridným identitám, teda vo svete Windows, aj cloudu bude stačiť jedna identita. Celkovo je vývoj noviniek a ďalších funkcií vo Windows Serveroch pozitívny, možno až príliš pro-reklamujúci, ponúkajú známe technológie pod novým menom. Toto sme bohužiaľ zistili možno trošku neskoro a je to v texte cítiť. Z pohľadu freeIPA sa možno tešiť na v5, keď si pozrieme, akými míľovými skokmi prešla v predošlých ôsmych rokoch, ako pridala do kroku: • v1 (2007) nič moc, hlavne integrácia a prihlasovanie voči LDAP and Kerberu, • v2 (2011) pridané politiky, certifikáty, pluginy, • v3 (2013) začiatky dôveryhodnosť s AD, klientská aplikácia na tokeny SSSD, • v4 (2014) koncept prístupových práv, HMAC, DNSSEC...

53 7 Záver

Predstavili sme tu dva svety doménových služieb, ktoré sú na prvý pohľad natoľko odlišné, že sa mohlo zdať, že nepôjdu porovnať – Active Directory, starousadlíka trhu centralizovanej správy vo Windows prostredí a open-sourcový projekt freeIPA ako integ- račný projekt mnohých serverový služieb v Linuxe, ktoré zjednocuje a manažuje. Zistili sme pri pokusoch, že sú to veľmi, veľmi komplexné systémy, preto sme ich v textovej časti popísali tak, aby boli medzi kapitolami 3 a 4 vizuálne porovnateľné. Domény predstavujú obrovské svety rôznych technológii, že sme sa ich snažili v prvom rade dekom- ponovať na základné časti a tieto vysvetľovať: (a) kto je v nich užívateľ, kam patrí, čo o ňom vieme = obe riešenia to robia LDAP, (b) potom sme pridali technológie, role serverov, komponenty, pohľad dole = obe riešenia podporujú Kerberos, aj DNS služby, otvárajú na servery porty, poskytujú napr. HTTP server, všetko je vecou nastavení, (c) v prípade Active Directory sme rozviedli auditovanie = ktoré vo freeIPA v4 nie je, i keď tu vidíme možnosť využiť služby SELinuxu. Zistili sme, že: (d) spätná kompatibilita autentifikačných metód v AD voči starším Windows klientom je značným bezpečnostným rizikom, i keď je možné vynútiť Kerbera, môžeme stratiť autentifikáciu voči starým OS, možno sú už stratené samy, (e) synchronizácia času v AD má väčšie časové okno, mnoho autentifikačných procesov má voľnejšie pravidlá, nastaviteľné široké množstvo politík, (f) doménové služby dokážu byť poriadne blokujúcim faktorom v testovaní virtuali- začného prostredia, DNS záznamy sme museli komplikovane upraviť, (g) konfigurovanie a flexibilita Linuxu je násobne väčšia, (h) vo Windows prostredí vládne lock-in, kto raz začne s Microsoftom, už ide na Microsoft technológiách do konca, čo môže byť (i) integračné úsilie, ktoré freeIPA predstavuje je neoceniteľné, potvrdzujeme rých- losť inštalácie, prehľadnosť CLI, prehľadné WebUI, (j) CentOS vyhráva nad Fedorou, možno pretože vychádza z RHELu, je zdarma, je svižný, je malý a spoľahlivý, ideálny k nasadeniu freeIPA serveru. Aby bol prínos tejto diplomovej práce možno využiť vo výuke, dodávame nakonfigu- rovanú aktuálnu CentOS 7 VirtualBox inštanciu do predmetu PV181 – CryptoLabu I.

54 8 Literatúra

1. ADAMSON, Weston Andros, 2012. NFS and FreeIPA [online]. 2012-03-01, [cit. 2015-05-01]. Dostupné z: http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA

2. BALLARD, Elena Deon, Tomáš ČAPEK a Aneta PETROVÁ, 2015a. Linux Domain Identity, Authentication, and Policy Guide. In: Red Hat Enterprise Linux 7. Red Hat. Dostupné z: http://tinyurl.com/phe7yew

3. BALLARD, Elena Deon, Tomáš ČAPEK a Aneta PETROVÁ, 2015b. System-Level Authentication Guide. In: Red hat Enterprise Linux 7. Red Hat. Dostupné z: http://tinyurl.com/oqmr6y4

4. BUKAČ, Vít, 2012. Základy AD, single sign-on [online]. Študijný materiál, FI MU, 2012- 3-12. Dostupné po prihlásení z: https://is.muni.cz/auth/el/1433/jaro2012/PV176/um/PV176_04.pptx?studium=667853

5. BUZÁSSYOVÁ, K. a A. JAROŠOVÁ, 2006. Slovník súčasného slovenského jazyka. A – G. Bratislava: Veda, vydavateľstvo Slovenskej akadémie vied 2006. 1134 s. ISBN 978-80-224- 0932-4. Dostupné z: http://slovniky.korpus.sk

6. CompareBusinessProducts.com, 2010. 50 Places Linux is Running That You Might Not Expect [online]. CompareBusinessProducts.com, 2010-03-23, [cit. 2015-05-01]. Dostupné z: http://www.comparebusinessproducts.com/fyi/50-places-linux-running-you-might- not-expect

7. CONRAD, James, 2012. Microsoft Windows Server 2012 70-410 [kurz]. CBT Nuggets, 2012. Dostupné za poplatok z: http://www.cbtnuggets.com/trainers/james-conrad

8. DOLAN-GAVITT, Brendan. SysKey and the SAM [online]. 2008-02-21, [cit. 2015-05-01]. Dostupné z: http://moyix.blogspot.cz/2008/02/syskey-and-sam.html

9. DUŠEK, Libor, 2011. Testování výkonnosti virtualizačního prostředí Hyper-V [online]. Brno, 2011. Diplomová práca. Masarykova univerzita, Fakulta informatiky. Dostupné z: http://is.muni.cz/th/208035/fi_m/dp_kpgxnuia.pdf

10. FORGESON, Jonathon a Tomáš KANTŮREK, 2015. Správa identit a řízení přístupu [online]. Microsoft Virtual Academy, 2015-03-02, [cit. 2015-05-01]. Dostupné z: http://www.microsoftvirtualacademy.com/training-courses/sprava-identit-rizeni- pristupu

55 11. GRAFNETTER, Michael, 2015. Jak Active Directory nakládá s Vaším heslem [online]. Windows User Group, 2015-01-20, [cit. 2015-05-01]. Dostupné z: https://www.wug.cz/zaznamy/255-Jak-Active-Directory-naklada-s-Vasim-heslem

12. HOLMES, Lee, 2013. Windows PowerShell Cookbook. Sebastopol : O'Reilly, 2013. 3. vydanie. 1007 s. ISBN 978-1-449-32068-3

13. KANTŮREK, Tomáš a Miroslav KNOTEK, 2014a. Windows Server 2012 R2 [online]. Microsoft, Windows user group, 2014-02-26, [cit. 2015-05-01]. Dostupné z: https://www.wug.cz/zaznamy/210-Windows-Server-2012-R2

14. KANTŮREK, Tomáš a Miroslav KNOTEK, 2014b. Windows Server 2012 R2 - 02_WUG_WS2012_R2_WhatIsNew_NoHyper-V_1.2 [prezentace]. Microsoft, Windows user group, 2014-02-26, [cit. 2015-05-01]. Dostupné z: https://www.wug.cz/brno/akce/GetFile.ashx?EventStoredFileID=222

15. KASPRZAK, Jan, 2010. UNIX Programování a správa systému II. Študijný materiál, FI MU, 2010. Dostupné po prihlásení z: https://is.muni.cz/auth/el/1433/jaro2010/PV077/um/

16. LUNDQVIST, Andreas, 2012. Linux Distribution Timeline.svg [súbor]. Wikimedia, 2012, [cit. 2015-05-01]. Dostupné z: http://commons.wikimedia.org/wiki/File:Linux_Distribution_Timeline.svg

17. MALLET, Andrew, 2014. Linux System Administration Fundamentals [kurz]. Plulralsight, 2014-09-12, [cit. 2015-05-01]. Dostupné za poplatok z: http://www.pluralsight.com/courses/linux-system-administration-fundamentals

18. Microsoft, 2005. Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 [online]. Microsoft, 2005, [cit. 2015-05-01]. Dostupné z: http://download.microsoft.com/download/8/d/6/8d608524-0763-48b5-840b- 0ae446996a14/MS_WSS_Dec_05.pdf

19. Microsoft, 2013a. Active Directory [online]. Microsoft, TechNet, 2013-08-01, [cit. 2015-05- 01]. Dostupné z: https://technet.microsoft.com/cs-cz/library/dn283324.aspx

20.Microsoft, 2013c. Windows Server 2012 R2 Licensing Datasheet [online]. Microsoft. 2013-08- 07, [cit. 2015-05-01]. Dostupné z: http://aka.ms/ws2012r2licensing

21. Microsoft, 2015. CentOS and Red Hat Enterprise Linux virtual machines on Hyper-V [online]. Microsoft, TechNet. 2015-03-15, [cit. 2015-05-01]. Dostupné z: https://technet.microsoft.com/en-us/library/dn531026.aspx

22. Red Hat, 2014. Red Hat Enterprise Linux: What's the diference between rebuilds and Red Hat Enterprise Linux ? [online]. Red Hat, 2014-12-30, [cit. 2015-05-01]. Dostupné z: https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux? rd=RHEL#What.27s_the_difference_between_Fedora_and_Red_Hat_Enterprise_Linux.3 F

56 23. SHIWAL, Rajnesh Kumar, 2013. IPA [online]. YouTube kanál, 2013-01-12, akt. 2014-05-19, [cit. 2015-05-01]. Dostupné z: https://www.youtube.com/playlist?list=PLdKXnZQzEG- LoE8X2lKY7BHFTKjzrrYiM

24. SMITH, Roderick W., 2006. Linux ve světě Windows. Průvodce administrátora heterogenních sítí. Praha : Grada, 2006. 443 s. ISBN 80-247-1470-1.

25. SOUKUP, Ondřej, 2012. Windows Server 2012: další licence úplně jinak [online]. Daquas, 2012-09-27, [cit. 2015-05-01]. Dostupné z: http://www.daquas.cz/articles/537-windows- server-2012-dalsi-licence-uplne-jinak

26. STANEK, William R., 2010. Group Policy: Zásady skupiny ve Windows. Brno: Computer Press, 2010. 351 s. ISBN 978-80-251-2920-3.

27. STANEK, William, 2013. Windows Server 2012 Inside Out. Redmond: Microsoft Press, 2013. 1538 s. ISBN: 978-0-7356-6631-3.

28. ŠEVEČEK, Ondřej, 2010. PKI ve Windows Server 2008 R2 a Windows 7 [online]. Windows user group, 2010-04-02, [cit. 2015-05-01]. Dostupné z: https://www.wug.cz/zaznamy/23- PKI-ve-Windows-Server-2008-R2-a-Windows-7

29. ŠEVEČEK, Ondřej, 2011. Klientské interakce Active Directory [online]. Windows User Group, 2011-10-28, [cit. 2015-05-01]. Nahral Pavel Krc. Dostupné z: https://www.youtube.com/watch?v=iJJEJwSuZLM

30. ŠEVEČEK, Ondřej, 2015a. Bezpečnost Windows pro pokročilé: Identity [online]. Microsoft Virtual Academy, 2015-02-17, [cit. 2015-05-01]. Dostupné zdarma po prihlásení z: http://www.microsoftvirtualacademy.com/training-courses/bezpecnost-windows-pro- pokrocile-identity?m=14886

31. ŠEVEČEK, Ondřej, 2015b. Windows Server 2012 – Active Directory Internals and Troubleshooting [online]. GOPAS, GOC171, 2015-04-09, [cit. 2015-05-01]. Dostupné z: https://www.sevecek.com/Presentations/GOC171/

57