STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE
S P R Á VA L I N U X O V É H O S E RV E R U JAN KALINA
Z Á V Ě R E Č N Á M AT U R I T N Í P R Á C E
BRNO 2011
Prohlášení Prohlašuji, že tato závěrečná maturitní práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: Ing. Zdeněk Píša
ii
Shrnutí Cílem této maturitní práce je navržení a realizace doménového serveru, svou rolí podobného Active Directory serveru. Na rozdíl od Active Directory ale bude založen na Open Source softwaru a autentizaci uživatelů nebude poskytovat pouze pracovním stanicím s Windows, ale také stanicím a serverům s operačním systémem Linux, popřípadě i jiným službám. Nejdůležitější částí aplikace je webová administrace, která tuto doménu umožní uživatelsky přívětivě spravovat.
iii
Obsah Prohlášení.............................................................................................................................................ii Shrnutí.................................................................................................................................................iii Obsah....................................................................................................................................................1 Anotace.................................................................................................................................................2 1 Koncepce...........................................................................................................................................3 1.1 Existující řešení..........................................................................................................................3 2 Návrh multiplatformního řešení........................................................................................................4 2.1 Databáze uživatelských účtů......................................................................................................4 2.2 Relační databáze a Adresářové služby.......................................................................................4 2.3 Uživatelé Linuxu a jiných Unix-like systémů...........................................................................5 2.3.1 PAM a NSS........................................................................................................................5 2.3.2 Linuxové stanice se vzdálenými domovskými adresáři.....................................................6 2.4 Uživatelé Windows....................................................................................................................6 2.4.1 Samba.................................................................................................................................6 2.4.2 SID.....................................................................................................................................7 3 Realizace řešení.................................................................................................................................8 3.1 NSS............................................................................................................................................8 3.2 PAM...........................................................................................................................................9 3.3 Samba.........................................................................................................................................9 4 Webová administrace.......................................................................................................................10 5 Vylepšení.........................................................................................................................................12 5.1 Zablokování a zamčení uživatelského účtu i v Linuxu............................................................12 5.2 Přesměrování složek cestovního profilu..................................................................................13 5.3 DHCP a bootování ze sítě........................................................................................................14 Závěr...................................................................................................................................................15 Seznam literatury................................................................................................................................16 Seznam zkratek...................................................................................................................................16 Seznam ilustrací..................................................................................................................................17 Seznam tabulek...................................................................................................................................17 Seznam příloh.....................................................................................................................................17 Obsah přiloženého CD.......................................................................................................................17
1
Anotace Vznikne přívětivá webová administrace doménového serveru sítě pro uživatele, skupiny a počítače v doméně, v LDAP databázi. Je určena pro Sambu i Linuxový server (pomocí PAM+NSS). Aplikace bude založena zejména na PHP, případně Javascriptu.
2
1 Koncepce Z pohledu uživatele bude v síti existovat „jakási doména“, ve které bude mít uložen svůj uživatelský účet a profil. Ať už přijde ke své pracovní stanici, cizí pracovní stanici nebo veřejnému terminálu, pokaždé se přihlásí stejnými přihlašovacími údaji k doméně. Přitom na něm najde stejnou plochu, dokumenty a síťové jednotky, jako by seděl u své vlastní pracovní stanice.
Ilustrace 1: Systém centrální autentizace z pohledu běžného uživatele
1.1 Existující řešení Podobnou funkci poskytuje i služba Active Directory společnosti Microsoft, kde je implementována jako LDAP server, k němuž se přihlašuje skrze protokol Kerberos. Souborové systémy jsou v síti sdíleny protokolem SMB (Server Message Block), někdy také nazývaným Sdílení Windows, protože poskytuje především Sdílení souborů a tiskáren systému Windows. Active Directory je ale uzavřené řešení, které se jen obtížně aplikuje na jiné služby, než které poskytuje samotný systém Windows. Proto se budu zabývat návrhem multiplatformního řešení.
3
2 Návrh multiplatformního řešení Cílem je vytvoření autentizačního serveru poskytujícího ověřování uživatelů různým službám, zejména pracovním stanicím s různými operačními systémy. Půjde jednak o nejrozšířenější platformu, bez jejíž podpory se podobný systém jednoduše nemůže ujmout v síti žádné reálné organizace, tedy Microsoft Windows a to jak v nyní nejrozšířenější verzi XP, tak novějších verzích, Windows Vista a Windows 7. Zároveň je nezbytné umožnit použití svobodných operačních systémů, aby vytvořené řešení nebylo závislé na jediném dodavateli software. Přestože většina softwaru používaného v organizacích závisí na této majoritní platformě, není žádoucí tyto vazby na cizí dodavatele utužovat. Jako zástupce svobodného operačního systému jsem vybral linuxovou distribuci Debian ve verzi 6 (squeeze), která je velmi významná zejména mezi distribucemi používanými na serverech, ale je bez problému použitelná i na pracovních stanicích nebo terminálech. Navíc je velmi podobná distribuci Ubuntu, která je z něj odvozena a která je poměrně více rozšířena na pracovních stanicích. Postupy aplikované na Debian je možné až na drobné odlišnosti bez problému aplikovat také na Ubuntu a jeho deriváty. Často se postupy příliš neliší ani pro jiné Unix-like systémy. V dalších částech práce se proto budu zabývat pouze Debianem.
2.1 Databáze uživatelských účtů S návrhem podobného systému je vhodné začít od databáze. Do ní potřebujeme ukládat uživatelské účty, tedy přihlašovací jména, hesla a případně i další informace o uživateli, jako například jeho celé jméno. To sice není nezbytné, ale pokud bude jméno uživatele zobrazováno v jeho přirozené podobě, určitě to zlepší nejen dojem, ale také přehlednost různých výpisů uživatelů. Hesla se samozřejmě nebudou ukládat jako čistý text, nýbrž jako hash. V tomto případě je nejdůležitějším kritériem pro výběr podpora dané databáze v aplikacích, kterým chceme ověření uživatele poskytovat. Musíme se tedy informovat, jaké databáze tyto aplikace podporují. Podpora jednotlivých zdrojů uživatelů je obvykle implementována prostřednictvím modulů nebo pluginů dané aplikace.
2.2 Relační databáze a Adresářové služby Je třeba se rozhodnout mezi relační databází, jakou je například MySQL, a adresářovou službou, jakou je například OpenLDAP. Relační databáze jsou více optimalizovány pro časté změny obsahu databáze – poskytují bezpečí transakcí a také pohodlí dotazovacího jazyka SQL. Oproti tomu adresářové služby, jako je LDAP nepředpokládají časté modifikace informací v databázi. Adresářové služby se totiž naopak zaměřují na vysokou rychlost čtení. To samozřejmě předpokládá důsledné indexování, které ale zase znamená pomalý zápis. Rovněž chybí transakce a zamykání tabulek, tedy funkce, které nejvíce oceníme při častém zápisu. Protože v roli autentizačního serveru musíme data velmi často číst a naopak zápis provádíme jen ojediněle, je zřejmé že se pro tento účel více hodí adresářové služby. Veškeré změny v této databázi totiž provádí administrátoři. Jediným údajem, který mohou změnit sami uživatelé jsou jejich vlastní 4
hesla. Ty ale můžeme zanedbat, jednak protože častěji než jednou týdně si většina lidí heslo nemění (naopak je častým negativním jevem, že si uživatelé heslo nezmění vůbec) a jednak také proto, že podle hesla nikdy nevyhledáváme. (Jinak můžeme vyhledávat prakticky podle čehokoli, od jména a příjmení až po různá identifikační čísla, která budou rozebrána níže. Podle hesla nemůžeme vyhledávat už jenom proto, že je uloženo v hashi.) Adresářové databáze také na rozdíl od relačních neuchovávají data v tabulkách, ale ve stromové struktuře. Tento fakt ale naše rozhodování příliš neovlivní – při tvorbě struktury budeme stejně omezeni schopnostmi aplikací, pro které databázi zhotovujeme. OpenLDAP je implementace adresářového serveru používající protokol LDAP. (Lightweight Directory Access Protocol – odlehčený protokol pro přístup k adresáři) Je nejběžnějším adresářovým serverem pod operačním systémem Linux. Proto s ním také počítá široké spektrum různých aplikací a proto bude použit jako databázový server naší domény.
2.3 Uživatelé Linuxu a jiných Unix-like systémů Unix-like operační systémy obvykle uživatelské účty ukládají do souborů ve větvi /etc souborového systému. Soubor /etc/passwd obsahuje uživatelská jména, hesla, identifikátor uživatele (UID), identifikátor primární skupiny (GID), domovský adresář uživatele a také shell. (Příkaz který se spustí po přihlášení uživatele, obvykle /bin/bash. Pokud chceme uživateli zabránit v přihlášení, můžeme místo něj použít například /bin/false, který uživateli neumožní provést žádný příkaz) Tento soubor je čitelný všemi uživateli. Jakýkoli uživatel tak může přeložit UID na uživatelské jméno (například když chce zjistit vlastníka souboru), ale všichni také mohou číst hesla všech uživatelů, což rozhodně není žádoucí. Hesla tak ukládáme do souboru /etc/shadow. (v /etc/passwd místo hesla napíšeme znak vykřičníku nebo hvězdičky) Těmto heslům pak říkáme stínová a tento postup se využívá ve většině dnešních linuxových distribucí. Dalším významným souvisejícím souborem je /etc/group, který obsahuje skupiny uživatelů. (Respektive jejich název, identifikátor (GID) a členy) Každý uživatel má jednu skupinu jako primární. Ta se určí jako GID v souboru /etc/passwd, tedy u záznamu uživatele, nikoli u skupin. 2.3.1 PAM a NSS Všechny tyto informace ale potřebujeme získávat z LDAP. Naštěstí současné linuxové distribuce výše uvedené soubory obalují obecnou vrstvou NSS a PAM. Ty ve výchozí konfiguraci získávají informace přímo z výše uvedených souborů, ale pozměněním jejich konfigurace, konkrétně instalací jejich modulů pro LDAP, dosáhneme získávání uživatelů z obou zdrojů – z lokálních konfiguračních souborů i z databáze LDAP. V případě nedostupnosti LDAP serveru (například při špatně nakonfigurovaném síťovém rozhraní stanice) se tak stále budeme moci přihlásit na lokální uživatelské účty. Abychom tohoto dosáhli, musíme nakonfigurovat pro práci s LDAP jak NSS tak i PAM. Proč? NSS by se dal považovat za ekvivalent souboru /etc/passwd a /etc/group – shromažďuje seznam uživatelů, například pro překlad identifikátoru UID/GID na jméno uživatele/název skupiny. Oproti němu, PAM se stará spíše o ověření uživatele. Konfiguraci je vhodné začít od NSS. Pokud bude NSS fungovat správně, bude možné se přihlásit na uživatele LDAP příkazem su. Teprve poté je 5
vhodné začít konfigurovat PAM. Nakonec by měl být uživatel schopen se normálně přihlásit, jako při přihlašování na lokální uživatelský účet. Obě služby se přitom k LDAP přihlašují nejprve anonymně, pod anonymním uživatelem v databázi najdou uživatelský účet podle přihlašovacího jména a pomocí takto získaného DN (adresy záznamu v adresáři používaném také jako přihlašovací jméno k LDAP) se na uživatele pokusí přihlásit. Pracovní stanice tak nemají k LDAP žádný nadstandardní přístup, takže ani když případný hacker stanici úspěšně napadne (k čemuž, pokud má fyzický přístup ke stanici, stačí obyčejné bootovací CD) nezíská tím žádný přístup k LDAP. Podrobnosti konfigurace budou rozebrány v kapitole Realizace řešení. 2.3.2 Linuxové stanice se vzdálenými domovskými adresáři Již na začátku práce byla zmíněna společná plocha, dokumenty a uživatelská nastavení na všech pracovních stanicích. Jak ale něco takového dokázat? V Linuxu se všechny tyto informace ukládají do domovského adresáře uživatele. Stačí tedy abychom měli stejný domovský adresář na všech stanicích. Toho můžeme dosáhnout umístěním větve /home souborového systému na server a jeho následným připojením do /home na pracovních stanicích. Problém je ale v oprávněních – takto by totiž root pracovní stanice mohl zasahovat do domovských adresářů všech uživatelů. A protože pro bezpečnost domény nepovažujeme pracovní stanice za důvěryhodné, musíme toto vyřešit jinak. Skvělým řešením je modul PAM – pam_mount. Tento modul umožní přihlašovat uživatele například k SSH serveru a následně pak jeho domovský adresář na tomto serveru připojit jako jeho lokální domovský adresář. Na každé pracovní stanici tak jsou přístupné domovské adresáře pouze aktuálně přihlášených uživatelů. I kdyby se někomu podařilo nad touto stanicí získat plnou kontrolu, dostal by se pouze do domovských adresářů přihlášených uživatelů.
2.4 Uživatelé Windows Na začátku práce bylo zmíněno také to, že operační systémy Windows podporují centrální autentizaci, ale pouze proti Windows Serveru. Co ale ještě zmíněno nebylo, je to, že toto omezení se snaží obejít open source projekt Samba. 2.4.1 Samba Samba je program běžící na Unix-like operačních systémech, emulující funkci Windows NT Serveru. V současných verzích Samba bez problému nahrazuje funkci primárního i sekundárního řadiče domény Windows. Jedná se však o doménu Windows NT a je tak horší podpora nejnovějších verzí systému Windows, které očekávají doménu sobě rovné verze serveru, podporující Active Directory. Stabilní verze Samby ale Active Directory nepodporuje. Sice je již ve vývoji Samba verze 4, která má zahrnovat plnou podporu Active Directory, ale protože je stále ve vývojové verzi, není vhodná k produkčnímu nasazení. Budeme se zde tedy zabývat pouze verzí stabilní. Samba tedy emuluje doménu Windows, do které jsou schopny se přihlásit pracovní stanice opatřené operačním systémem Windows. (S výjimkou jejich Home/Starter verze, které z marketingových důvodů centrální autentizaci vůbec neumožňují)
6
2.4.2 SID Windows používají pro identifikaci uživatelů SID – bezpečnostní identifikátor. Ten se používá rovněž pro označování domén, počítačů a skupin. Na rozdíl od Unix-like identifikátorů UID a GID, které jsou zcela numerické, SID se zapisuje v následujícím tvaru:
S-1-5-21-3623811015-3361044348-30300820-1013 Verze specifikace
Typ autority
Autorita (doména/počítač)
Relativní ID (RID)
Ilustrace 2: Tvar bezpečnostního identifikátoru SID Jak je z tohoto schématu vidět, jediná část SID, kterou se musíme zabývat je číslo za poslední pomlčkou, která identifikuje objekty v rámci domény. Proto ho nazýváme RID – relativní identifikátor. Celý zbytek SID představuje SID domény a v rámci celého našeho projektu bude vždy stejný. RID tedy budeme odvozovat od UID pro uživatele a od GID pro skupiny. Problém je ovšem v tom, že na linuxových systémech může UID a GID navzájem kolidovat. Použijeme všeobecně užívaný převod, kdy UID i GID vynásobíme dvěma, ale ke GID navíc přičteme jedničku. Tím budou všechna sudá SID náležet uživatelům a všechna lichá SID skupinám. Mimo odlišného identifikátoru uživatelů používá platforma Windows také odlišnou hashovací funkci pro ukládání uživatelů. To by samo o sobě nevadilo, pokud by se hesla v tomto hashi pouze ukládala na Windows Serveru. Problém je v tom, že hesla takto zašifrovaná putují i po síti. Je tak nezbytné mít v LDAP databázi heslo nejenom v hashi používaném samotným LDAPem k autentizaci uživatelů přistupujících k databázi (a tím pádem využívaném i PAMem), ale také v tomto NT hashi. Pokud bychom chtěli umožnit přihlášení do naší domény i stanicím s operačním systémem Windows 98, museli bychom heslo ukládat také v dnes již nedostatečně bezpečném LM hashi. Kvůli bezpečnostním problémům nejenom LM hashe, ale i tohoto operačního systému tuto možnost nedoporučuji.
7
3 Realizace řešení Na doménovém serveru bude nainstalován LDAP server, jenž bude obsahovat informace o uživatelích, skupinách a počítačích. Přitom budou díky konfiguraci PAM a NSS také systémovými uživateli a skupinami na serveru. Díky tomu se budou moci přihlásit k SSH serveru. To využijeme k přihlašování uživatelů k linuxovým stanicím. Samba server bude zároveň vytvářet doménu Windows s uživateli a skupinami z LDAP. V obou případech budou mít uživatelé přístup ke svým domovským adresářům na doménovém serveru, což využijeme k cestovním profilům.
Ilustrace 3: Celkový pohled na systém centrální autentizace Připravili jsme tedy server s nainstalovanou distribucí Debian Linux (v tomto případě verze 6 – squeeze), provedli základní konfiguraci (nastavení sítě, instalace základních nástrojů) a spustili instalaci balíčku slapd obsahující OpenLDAP server. Na požádání instalátoru jsme zvolili heslo pro administrátora LDAP serveru. Bohužel po instalaci nebylo jasné, jaké tento administrátor dostal přihlašovací DN. Nemohli jsme se tedy na něj přihlásit. Pomocí příkazu slapcat se nám ale podařilo obsah databáze vypsat bez potřeby přihlášení – pomocí přímého přístupu k souborům databáze. Zjistili jsme tak, že kořen serveru byl pojmenován dc=nodomain. (Normálně by byl pojmenován podle domény počítače, kterou jsme zadali při instalaci operačního systému, kterou jsme ale neprozřetelně nevyplnili.) Přihlašovací DN administrátora tak byla cn=admin,dc=nodomain. Úspěšně jsme se pomocí ní a hesla zadaného při instalaci slapd přihlásili k LDAP a vytvořili strukturu LDAP. Ta je ve formátu LDIF připojena jako příloha.
3.1 NSS Po instalaci LDAP jsme nainstalovali modul NSS pro LDAP – libnss-ldap a nakonfigurovali jej pomocí konfiguračního souboru /etc/libnss-ldap.conf. Nenastavili jsme přitom přihlašovací údaje k LDAP – NSS bude k LDAP přistupovat anonymně. Také jsme nastavili použití tohoto modulu v 8
konfiguraci NSS - /etc/nsswitch.conf. Správnost této konfigurace jsme ověřili pomocí nabídky pro změnu vlastníka souboru v souborovém manažeru mc. (Soubor – Změna vlastníka – následně by se měl zobrazit i seznam uživatelů a skupin jak lokálních, tak těch v LDAP)
3.2 PAM Jako další jsme nainstalovali modul PAMu pro LDAP – libpam-ldap a nakonfigurovali jej konfiguračním souborem /etc/libpam-ldap.conf podobně jako NSS. Také jsme nastavili použití tohoto modulu, tentokrát v konfiguračních souborech PAMu: /etc/pam.d/common-*. Jestliže jsme postupovali správně, mělo by nyní být možné přihlásit se k účtu v LDAP na konzole serveru nebo přes SSH. Jinak zkontrolujeme konfiguraci provedenou v posledních dvou bodech.
3.3 Samba Protože je tímto hotova serverová část linuxového přihlašování, přejdeme ke konfiguraci Samby, která bude konstruovat Doménu Windows, aby se skrze ni mohly přihlašovat uživatelé stanic s operačním systémem Windows. Základní nastavení domény Windows jsme provedli už při vytváření struktury LDAP, konkrétně záznamu domény. V konfiguraci Samby, /etc/samba/smb.conf zbývá nastavit: [global] workgroup = DOMENA security = user encrypt passwords = true passdb backend = ldapsam:ldap://localhost ldap suffix = dc=domena,dc=nodomain # Kořen LDAP stromu (pro Sambu) ldap admin dn = cn=admin,dc=nodomain # Prihlasovaci DN administratora v LDAP ldap machine suffix = cn=machines,ou=users # Větev počítačů ldap user suffix = ou=users # Větev uživatelů ldap group suffix = ou=users # Větev skupin logon path = # Výchozí umístění síťové jednotky, pokud není nastavena v LDAP logon drive = # Výchozí písmeno síťové jednotky logon home = # Výchozí umístění domovského adresáře logon script = # Výchozí přihlašovací skript (ze sdílení netlogon, bez adresy) unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *New\spassword:* %n\n *Re*password:* %n\n *changed*
Ilustrace 4: Konfigurace Samby (/etc/samba/smb.conf) Heslo administrátora LDAP pro Sambu uložíme do databáze Samby příkazem smbpasswd -w heslo. Po restartu Samby by mělo být možné stanice s Windows připojit do nové domény. V případě problémů můžeme ověřit spojení Samby a LDAPu příkazem net user -U admin (kde admin je přihlašovací jméno doménového administrátora, na jehož heslo budete vzápětí dotázáni), který vypíše seznam uživatelů, jak je zná Samba. Tímto je hotova konfigurace doménového serveru. 9
4 Webová administrace Nyní se dostáváme k nejdůležitější části maturitní práce – uživatelsky přívětivému webovému rozhraní, které nám umožní doménu vytvořenou v předchozích částech spravovat.
Ilustrace 5: Rozhraní webové administrace pro správu počítače Struktura webové administrace je inspirována návrhovým vzorem MVC (Model-View-Controller) a MVP (Model-View-Presenter).
Ilustrace 6: UML diagram webové administrace Presenterem je soubor index.php v kořeni webu. Je volán webovým serverem při požadavku na zaslání stránky. Nejprve načte do paměti všechny třídy Modelu. Všechny části Modelu jsou společné pro všechny stránky aplikace. Každá stránka má ale svůj vlastní View a Controller. View je běžná PHP stránka – HTML prokládané krátkými PHP tagy. Tvoří tak primitivní šablonovací 10
systém, založený na faktu, že samo PHP je šablonovacím jazykem. Controller je tvořen třídou Control. Název vychází ze slova Controller (řadič), ale pro omezení chyb v psaní jeho názvu je zkrácen na pouhé Control (řízení). Každá stránka má vlastní Controller. V paměti je načten pouze Controller právě zobrazené stránky. Stránky tak na sobě nemohou navzájem záviset. Oproti tomu třídy Modelu jsou v paměti načteny stále. (Respektive se do paměti načítají při volání každé stránky – aplikace generující webové stránky totiž svůj život začínají při obdržení požadavku webového prohlížeče a po vygenerování žádané stránky svůj život zase končí) Z pohledu uživatele (doménového administrátora) obsahuje administrace následující stránky: Přehled
home
Hlavní strana aplikace fungující hlavně jako rozcestník
Uživatelé
users
Správa uživatelů v doméně – přidávání, změna hesla atd.
Skupiny
groups
Správa skupin v doméně – přidávání, přehled členů atd.
Počítače
machines
Správa počítačů v doméně – přidávání, nastavení atd.
Tabulka 1: Přehled stránek webové administrace Model pak tvoří globálně přístupné třídy: Ldap
Komunikace s LDAP serverem
Linux
Spouštění Linuxových příkazů na serveru, práce se soubory pod uživatelem root
SmbHash Knihovna pro práci s NT a LM hashem z OSS projektu LDAP Account Manager Dhcp
Práce se záznamy ve větvi DHCP serveru v LDAP, umožňuje nastavit informace, které dostane určitá MAC adresa od DHCP serveru, jako IP adresa, maska podsítě, brána, DNS server a také obraz pro nabootování po síti
Machine
Práce s počítači v LDAP. Zároveň spravuje i jejich DHCP záznamy skrze třídu výše. Mimo to umožňuje zjistit dostupnost počítače (ping), zapnout počítač (WakeOnLan) nebo ho vypnout skrze SSH
Group
Práce se skupinami. Při smazání skupiny vyvolá také smazání uživatelů, kteří mají odstraňovanou skupinu jako svoji primární skupinu.
Users
Práce s uživateli. Spravuje obě části jejich účtu v LDAP (Samby i Linuxu) i domovské adresáře uživatelů.
Tabulka 2: Přehled tříd modelu Za zmínku stojí také způsob, jakým webová administrace přistupuje k LDAP databázi: Při přihlášení uživatele se aplikace nejdříve k LDAPu přihlásí anonymně a vyhledá přihlašovací jméno uživatele. Když takto zjistí adresu jeho záznamu (DN), použije ji jako přihlašovací jméno k LDAP a přihlásí se k LDAP uživatelským účtem uživatele, který se přihlašuje k webové administraci. Přihlašovací adresa i heslo uživatele jsou pak uloženy do SESSION a aplikace pak po celou dobu, kdy je uživatel přihlášen pracuje pod jeho účtem. Sama webová administrace sama o sobě nemá k LDAP databázi přístup. Ani přečtením jejích konfiguračních souborů tak případný útočník nezíská kontrolu nad LDAP serverem.
11
5 Vylepšení 5.1 Zablokování a zamčení uživatelského účtu i v Linuxu Skrze změnu záznamu uživatelského účtu v LDAP můžeme uživatelský účet zablokovat, zamknout nebo vynutit změnu hesla uživatele při jeho příštím přihlášení. Tato nastavení platí pro Sambu a tím i pro Windows stanice. Modul PAMu ale na tyto atributy nebere zřetel a k Linuxovým stanicím a serverům se tak mohou přihlásit i uživatelé se zablokovaným nebo zamčeným účtem. Připravil jsem tedy bashový skript, který zkontroluje, zdali se uživatel o daném uživatelském jménu může přihlásit. Následně tento bashový skript necháme spouštět modulem PAMu, pam_exec. Ten zajistí, že pokud tento skript vrátí něco jiného než 0, skončí přihlášení neúspěchem. #!/bin/bash if [ "$PAM_USER" == "root" ]; then exit 0; fi query="cn=$PAM_USER" attr="sambaAcctFlags" ldap_host="localhost" ldap_searchbase="ou=users,dc=domena,dc=nodomain" ldap_cmd="ldapsearch -h ${ldap_host} -x -b ${ldap_searchbase}" result=$(${ldap_cmd} -LLL ${query} ${attr} | grep "^${attr}:") if [ "${result}" != "" ]; then result=$(echo ${result} | sed -e 's/^.*: //') if [[ ${result} = *D* ]]; then exit 2 # Ucet je zablokovany fi if [[ ${result} = *L* ]]; then exit 3 # Ucet je zamceny fi exit 0 # Uzivatel se muze v poradku prihlasit else exit 1 # Uzivatel nebyl nalezen v LDAP fi
Ilustrace 7: Skript volaný pam_exec pro ověření zdali se uživatel může přihlásit account account account
requisite sufficient sufficient
pam_exec.so /etc/pam.d/samba-skript.sh pam_unix.so pam_ldap.so
Ilustrace 8: Kofigurace PAM - /etc/pam.d/common-account Tímto jsme znemožnili přihlášení uživatelů se zablokovaným nebo zamčeným účtem.
12
5.2 Přesměrování složek cestovního profilu Profil uživatele je v operačním systému Windows adresář se jménem shodným s přihlašovacím jménem uživatele (až na výjimky), nacházející se v adresáři C:\Documents and Settings (na Windows NT až Windows XP) nebo C:\Users (na Windows Vista a Windows Seven). Každý profil obsahuje plochu, dokumenty a další data uživatele. Mimo ně zde jsou také další soubory – NTUSER.DAT, obsahující uživatelskou větev registru Windows (HKEY_CURRENT_USER), NTUSER.POL, obsahující uživatelskou část Zásad skupiny a NTUSER.INI obsahující konfiguraci samotného profilu. Pokud se k počítači přihlašuje uživatel, který na něm nemá svůj profil, je mu vytvořen nový zkopírováním profilu Default/Default user. Funkce domény systému Windows umožňuje použití tzv. Cestovních profilů – uživatelský profil je pak uložen na serveru a při přihlášení uživatele je zkopírován na danou pracovní stanici. Následně s ním uživatel může pracovat stejně jako s běžným lokálním profilem. Při jeho odhlášení je profil zkopírován zpět na server. Tato funkcionalita sama o sobě zajišťuje, že ať se uživatel přihlásí ke kterékoli stanici, je postaven vždy před stejné prostředí se stejnou plochou, dokumenty atd. Protože se ale celý profil kopíruje při každém přihlášení a odhlášení, může být přihlašování a odhlašování uživatele velmi pomalé – zejména pokud má ve svém profilu uloženy objemné soubory. Bylo by tedy podstatně praktičtější, pokud bychom soubory neukládali do profilu, ale přímo na síťovou jednotku – domovský adresář na serveru. To je ale nepohodlné – většina programů navádí při ukládání souborů k použití adresáře dokumenty a plocha je zase stále „po ruce“. Naštěstí systém Windows, třebaže neumožňuje mít celý profil pouze na serveru, umožňuje základní složky profilu přesměrovat do jiného umístění. Ve Windows Seven stačí otevřít složku profilu (v nabídce Start pod názvem uživatelského účtu), zde otevřít vlastnosti jednotlivých složek profilu a na kartě Umístění změnit adresu složky profilu. Doporučuji použít stejný adresář pro dokumenty Windows Seven i dokumenty Windows XP a ostatní složky profilu analogicky. Třebaže tak budou různé operační systémy používat různé profily, samotné soubory (na ploše a v dokumentech) budou pro všechny operační systémy společné. Navíc se takto každá změna provádí ihned na serveru, takže nevzniká problém při několikanásobném přihlášení stejného uživatele. Problematičtější je přesměrování složek ve Windows XP, který umožňuje graficky přesměrovat pouze složku dokumenty. Přesměrování ostatních složek je nutné nastavit v uživatelské větvi registru. (Zdůrazňuji že v uživatelské větvi – díky tomu bude toto nastavení cestovat spolu s cestovním profilem a není třeba nastavovat toto na každé stanici zvlášť. Naopak je nutné toto nastavit pro každého uživatele zvlášť. Tomu se můžeme vyhnout vhodně vytvořeným výchozím profilem, jehož kopií nově vytvořené uživatelské účty jsou.) Umístění složek profilu lze v registru nastavit prostřednictvím klíčů v umístění: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Například hodnotu Desktop změňte z %USERPROFILE%\Plocha na Z:\Plocha (Za předpokladu, že se domovský adresář serveru připojuje při přihlášení jako disk Z:) Změny těchto nastavení se projeví až při dalším přihlášení. (Pro otestování se tedy odhlaste a znovu přihlaste) 13
5.3 DHCP a bootování ze sítě Používání dynamické IP adresy (získané z DHCP serveru) často představuje problém, jsme-li v roli správce sítě a potřebujeme se připojit k některé pracovní stanici, například protokolem VNC (vzdálená plocha) nebo SSH (vzdálený příkazový řádek). Jak už z principu dynamických adres vyplývá, není snadné určit jakou IP adresu která stanice má. V naší doméně tedy použijeme DHCP server, který ale bude pracovním stanicím přidělovat IP adresy z LDAP databáze. Když se tak počítač se známou MAC adresou (respektive MAC adresou, která je v LDAP přiřazena některé stanici) dotáže DHCP serveru na svoji IP adresu, dostane IP adresu, která byla stanici přidělena při jejím zařazení do LDAP databáze. Pokud DHCP server nebude MAC adresu znát, může přidělit adresu dynamickou (pokud bude v LDAP u záznamu podsítě uveden atribut dhcpRange, tedy rozsah dynamicky přidělovaných adres), nebo může přidělení IP adresy odmítnout a znesnadnit tak neoprávněné připojení cizího zařízení do sítě. (Toto je dobrá obrana před nezkušenými uživateli, lze ji ale snadno obejít ručním nastavením sítě – i zkušeného uživatele ale může potřeba ruční konfigurace odradit) Mimo IP adresy poskytuje DHCP server také další informace nutné k připojení k síti (masku sítě, bránu atd.), ale také adresu zavaděče pro spuštění operačního systému ze sítě. Je-li v konfiguraci BIOSu povoleno bootování ze sítě, BIOS po spuštění počítače kontaktuje DHCP server. Poskytne-li mu tuto adresu souboru, stáhne jej z TFTP serveru a spustí. Zavaděč (např. PXELINUX) pak za pomoci dalších souborů (jádra a initrd) stažených z TFTP serveru spustí operační systém. Ten je zcela nezávislý na operačním systému uloženém na pevném disku a hodí se tak jako nástroj k opravě poškozeného systému. V rámci této maturitní práce byla připravena také upravená distribuce TinyCoreLinux (Linuxová distribuce s velikostí pod 11 MB, tedy vhodná k zavedení ze sítě). Ta po svém startu ze serveru stáhne bashový skript (generovaný PHP skriptem) a spustí jej. Webová aplikace skript generuje v závislosti na IP adrese ze které přišel požadavek. Má-li tak stanice nastaven instalační obraz, přepíše pomocí programu partimage pevný disk tímto obrazem disku. Protože je přitom původní operační systém zcela přepsán, jsou tímto vyřešeny veškeré softwarové závady. Problémem jsou pouze případné chybějící ovladače a duplicitní název počítače v síti. (Předpokládáme totiž, že jeden obraz použijeme pro větší množství počítačů) Je tedy třeba po prvním spuštění počítač odpojit od domény, změnit jeho název a opět k doméně připojit. Nemusíme se už ale zabývat instalací softwaru, který již byl nainstalován při pořizování obrazu disku. Obraz disku je totiž přesnou kopií obsahu pevného disku včetně zavaděče, operačního systému, nainstalovaného softwaru i uživatelských dat. (I když ta v tomto případě nejsou žádoucí, proto je před pořízením obrazu disku odstraníme) Je tedy možné přepsat operační systém pracovní stanice jen vhodným nastavením ve webové administraci a povolením bootování ze sítě v konfiguraci BIOSu stanice.
14
Závěr Bylo úspěšně vytvořeno multiplatformní řešení pro centrální autentizaci uživatelů. Pomocí jednotných přihlašovacích údajů se můžeme přihlásit jak k pracovním stanicím s Windows, tak k pracovním stanicím a serverům s Linuxem, webové administraci domény i dalším aplikacím podporujícím autentizaci skrze protokol LDAP. Díky připojování domovských adresářů v Linuxu a přesměrování složek profilu ve Windows máme jednu plochu a dokumenty společné pro všechny stanice, napříč různými operačními systémy.
15
Seznam literatury 1. Roderick W. Smith: Linux ve světě Windows (elektronická verze z Google knihy: http://books.google.com/books?id=uDO_I1kIRBYC&printsec=frontcover) 2. Samba-HOWTO-Collection (http://www.samba.org/samba/docs/man/Samba-HOWTOCollection/introduction.html) 3. Debian Wiki – LDAP (http://wiki.debian.org/LDAP) 4. Microsoft TechNet – Přesměrování složky (http://technet.microsoft.com/cscz/library/cc732275.aspx) 5. Ubuntu Documentation: OpenLDAPServer (https://help.ubuntu.com/community/OpenLDAPServer) 6. The System Administrator's Guide - pam_exec (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-pam_exec.html) 7. renemoser.net – Bash script: ldap-query.sh (http://www.renemoser.net/2008/02/bash-scriptldap-querysh/) 8. Wikipedia: Security Identifier (http://en.wikipedia.org/wiki/Security_Identifier) 9. Správa systému Windows 7: Profily (http://kurzy.ucn.muni.cz/Win7/Lekce3/10) 10. Petr Včelák: Bootování přes LAN (http://petr.vcelak.cz/project/clone/reseni.php)
Seznam zkratek LDAP Bash BIOS DHCP DN GID IP adresa MAC adresa mc MySQL NSS OpenLDAP PAM PHP RID Samba SID SMB SQL SSH TFTP UID VNC
Lightweight Directory Access Protocol, protokol pro přístup k adresáři Bourne-again shell, příkazový interpretr používaný na Unix-like systémech Basic Input-Output System, standardní rozhraní firmwaru Dynamic Host Configuration Protocol, protokol pro automatickou konfiguraci Distinguished Name, adresa záznamu v LDAP adresáři Identifikátor skupiny používaný na Unix-like systémech Internet Protocol address, adresa počítače v síti Media Access Control address, fyzická adresa síťového rozhraní (síťové karty) Midnight Commander – Semigrafický správce souborů My Structured Query Language, databázový server používající jazyk SQL Name Service Switch, systém jmenné služby Svobodná implementace adresářového serveru LDAP serveru Pluggable authentication modules, mechanismus pro modulární autentizaci Hypertext preprocessor, interpretovaný skriptovací jazyk Relative ID, část SID identifikující jednotlivé objekty domény (zbytek SID označuje doménu objektu; objekty jsou uživatelé, počítače, skupiny apod.) Svobodná implementace SMB protokolu Security identifier, identifikátor objektů domény Windows (uživatelů, skupin apod.) Server Message Block, síťový protokol používaný operačním systémem Windows Structured Query Language, strukturovaný dotazovací jazyk pro práci s databází Secure Shell, protokol bezpečného vzdáleného příkazového řádku Trivial File Transfer Protocol, primitivní protokol pro přenos souborů Identifikátor uživatele používaný na Unix-like systémech Virtual Network Computing, protokol vzdálené plochy
16
Seznam ilustrací Ilustrace 1: Systém centrální autentizace z pohledu běžného uživatele...............................................3 Ilustrace 2: Tvar bezpečnostního identifikátoru SID............................................................................7 Ilustrace 3: Celkový pohled na systém centrální autentizace...............................................................8 Ilustrace 4: Konfigurace Samby (/etc/samba/smb.conf).......................................................................9 Ilustrace 5: Rozhraní webové administrace pro správu počítače.......................................................10 Ilustrace 6: UML diagram webové administrace................................................................................10 Ilustrace 7: Skript volaný pam_exec pro ověření zdali se uživatel může přihlásit.............................12 Ilustrace 8: Kofigurace PAM - /etc/pam.d/common-account.............................................................12
Seznam tabulek Tabulka 1: Přehled stránek webové administrace...............................................................................11 Tabulka 2: Přehled tříd modelu...........................................................................................................11
Seznam příloh Příloha č. 1
Struktura LDAP databáze
Obsah přiloženého CD www runas reinstal pam netlogon etc zdroje
Soubory webové administrace (/var/www) Program umožňující webové administraci spouštět příkazy jako root (viz. readme.txt) TinyCoreLinux upravený pro potřeby obnovy OS z obrazu disku (viz. kapitola 5.3) Konfigurace PAM, včetně skriptu z kapitoly 5.1 (/etc/pam.d) Adresář sdílený Sambou jako netlogon – adresář přihlašovacích skriptů, včetně automatické instalace OpenSSH a vybídnutí k ruční instalaci TightVNC (/home/netlogon) Konfigurační adresář testovacího serveru (/etc) Soubory, jejichž části byly použity ve webové aplikace (viz. readme.txt)
(Některé adresáře se na CD nacházejí jednak v čisté podobě a jednak v komprimovaném archivu, zejména kvůli omezení ISO 9660 týkající se pojmenování souborů.)
17
