Jihočeská univerzita v Českých Budějovicích Pedagogická fakulta

Jihočeská univerzita v Českých Budějovicích Pedagogická fakulta Katedra informatiky Jednotný systém autentizace a autorizace uživatelů v heterogenním prostředí diplomová práce Autor: David Hartman Vedoucí diplomové práce: Ing. Ladislav Lhotka, CSc. České Budějovice 2004

P ROHLÁŠENÍ: Prohlašuji, že diplomovou práci na téma Jednotný systém autentizace a autorizace uživatelů v heterogenním prostředí jsem vypracoval samostatně s použitím odborné literatury, která je citována v seznamu literatury na konci diplomové práce. V Příbrami dne 5.4.2004.. David Hartman 2

P ODĚ KOVÁNÍ: Děkuji vedoucímu diplomové práce Ing. Ladislavu Lhotkovi, CSc. za pomoc při realizaci praktické části a velmi cenné rady při jejím zpracování. Dále bych chtěl poděkovat vedení Česko-anglického gymnasia, zejména RNDr. Danuši Lhotkové, za možnost vyzkoušet si vše v reálném provozu. 3

Obsah O BSAH... 4 Ú VOD... 6 1. Z ÁKLADNÍ INFORMACE... 7 1.1. Server Samba...7 1.2. Adresářové služby a LDAP...8 1.3. Informace o účtech a hesla uživatelů...12 1.4. Domény Windows, řídící počítač domény...13 1.5. Konfigurace sítě LAN a serveru...14 2. I NSTALACE POTŘ EBNÉHO SOFTWARU... 15 2.1. Stažení, kompilace a instalace Samby...15 2.2. Stažení a instalace OpenLDAP...16 2.3. Stažení a instalace balíku smbldap-tools...16 4. K ONFIGURACE SERVERU O PENLDAP... 17 4.1. Schéma a úprava konfigurace...17 4.2. Konfigurace smbldap-tools...21 5. K ONFIGURACE L INUXU ( MODULY PAM)... 25 5.1. Linux-PAM...25 5.1. Konfigurační soubory modulů PAM...26 5.2. Konfigurace modulů PAM...28 5.3. Testování nastavení...30 6. S OUBOROVÉ SYSTÉMY... 32 6.1. Síťové souborové systémy...33 6.2. Konfigurace serveru NFS...34 6.3. Konfigurace klientů systému NFS...36 6.4. Správa diskových kvót...38 7. K ONFIGURACE S AMBY... 40 7.1. Použití nástroje SWAT...40 7.2. Konfigurace Samby jako PDC...42 7.3. Přihlášení Windows do domény...46 8. S PRÁVA UŽIVATELŮ A JEJICH NASTAVENÍ... 48 8.1. Správa uživatelů pomocí smbldap-tools...48 8.2. Uživatelské profily a jejich nastavení...54 9. WWW ROZHRANÍ PRO SPRÁVU UŽIVATELŮ... 57 9.1. SUDO (propůjčování identifikace)...57 9.2. Konfigurace webového serveru Apache...58 4

9.3. Práva k záznamům LDAP...59 9.4. API rozhraní jazyka PHP pro práci s LDAP...60 9.5. Změna hesla přes webové rozhraní...60 9.6. Správa uživatelů přes webové rozhraní...62 10. D ALŠÍ VYUŽITÍ ADRESÁŘ E LDAP... 70 11. Z ÁVĚ R... 71 S EZNAM POUŽITÉ LITERATURY... 72 Z DROJE DOSTUPNÉ ON- LINE... 73 P Ř ÍLOHY... 74 A. Konfigurační a zdrojové soubory...74 A.1. /etc/openldap/slapd.conf... 74 A.2. /etc/openldap/ldap.conf... 75 A.3. base.ldif... 75 A.4. /usr/local/sbin/smbldap_conf.pm... 77 A.5. /etc/exports (othello.caglan.cz)... 81 A.6. /etc/fstab (othello.caglan.cz)... 81 A.7. /etc/fstab (public.caglan.cz)... 81 A.7. /etc/xinetd.d/swat... 81 A.8. /etc/samba/smb.conf... 82 A.9. /etc/sudoers... 88 A.10. Skript pro změnu hesla uživatele... 88 A.11. Formulář pro změnu hesla... 90 B. Obsah CD...91 5

Úvod Pro každého správce počítačové sítě by byla určitě krásná představa, kdyby měl v síti pouze identické počítače se stejným operačním systémem. Skutečnost je ovšem jiná. Správce dnes a denně stojí před problémy, jak propojit počítače s různými operačními systémy a jak co nejvíce zpříjemnit život uživateli tak, aby tyto problémy vůbec nepocítil. Z hlediska uživatele by bylo jistě příjemné, aby měl jen jedno uživatelské jméno a heslo pro přihlášení ke stanicím s operačním systémem Microsoft Windows, ke stanicím s operačním systémem Linux i pro čtení pošty. Tato diplomovaná práce si klade za cíl vytvořit centrální server pro autentizaci a autorizaci uživatelů pro heterogenní síť, který by byl použitelný pro nasazení v malé či středně velké počítačové síti LAN. V síti budou zapojeny stanice s operačními systémy Microsoft Windows a Linux. Je zde podrobně rozebrána jedna z možností, jak takový server vytvořit. Konkrétně tento server běží na volně šiřitelném operačním systému Linux. Pro sdílení síťových zdrojů, jako jsou tiskárny a soubory, se bude starat server Samba, který používá databázi uživatelů uloženou v adresáři LDAP. Všechny stanice v síti, s operačními systémy Windows nebo Linux, se ověřují proti tomuto serveru. Ukládání informací o jednotlivých uživatelích do adresáře LDAP má hned několik výhod. Nejvýznamnější je velice dobrá podpora pro práci s LDAP záznamy v jednotlivých programovacích jazycích nebo třeba to, že v adresáři se mohou uchovávat i jiné informace než jen ty, které jsou potřebné pro přihlášení ke stanici, tedy například fotografie jednotlivých uživatelů, adresy, telefony apod.. Na konci diplomové práce je na konkrétních příkladech v programovacím jazyce PHP popsána práce s LDAP záznamy. Součástí práce je i webové rozhraní pro centrální správu uživatelů, které naleznete na přiloženém CD. 6

1. Základní informace 1.1. Server Samba Samba je sada nástrojů, které umožňují unixovým systémům využívat protokol SMB (Server Message Block). Tento protokol využívá pro přenos dat v sítích klient-server mnoho operačních systémů včetně Windows nebo OS/2. Jeho podporou umožňuje Samba serverům se systémy Unix komunikovat stejným síťovým protokolem, jaký používají i produkty Microsoft Windows. Díky tomu mohou počítače se systémem Unix a nainstalovanou Sambou vystupovat jako servery v síti, složené z počítačů se systémy Windows a navíc nabízet následující služby: sdílení souborových systémů sdílení tiskáren instalovaných na serveru nebo jeho klientech podpora klientů při prohlížení síťového okolí autentizace klientů, kteří se přihlašují do domény Windows V současné době se Samba skládá z několika programů (démonů), které poskytují sdílení síťových zdrojů klientům SMB v síti. Jednotlivé části jsou: smbd - démon smbd je zodpovědný za správu sdílených síťových zdrojů mezi počítačem se serverem Samba a jeho klienty. Poskytuje souborové a tiskové služby a služby prohlížení klientům SMB v jedné nebo více sítích. Smbd obsluhuje veškerou komunikaci mezi serverem Samba a síťovými klienty. Kromě toho je zodpovědný za autentizaci uživatelů, zamykání prostředků a sdílení dat s využitím protokolu SMB. nmbd - démon nmbd je jednoduchý jmenný server, který sdružuje funkce jmenného serveru NetBIOS a serveru WINS (Windows Internet Naming Service), podobně jako je tomu v případě LAN Manageru. Tento démon přijímá požadavky na jmenný server a poskytuje odpovídající data. Poskytuje také prohlížecí seznamy a účastní se volby prohlížeče. 7

Distribuce Samby také obsahuje několik nástrojů, spouštěných z příkazového řádku: smbclient - unixový klient, podobný FTP, který je možné použít pro připojení ke sdíleným prostředkům Samby smbtar - program pro zálohování sdílených dat, podobný nástroji tar, známému z prostředí systému Unix nmblookup - program, který provádí vyhledávání jmen pomocí protokolu NetBIOS nad TCP/IP smbpasswd - program, který umožní správci změnu zašifrovaných hesel, které Samba používá smbstatus - program, jehož výstupem je seznam aktivních síťových připojení ke zdrojům na serveru Samba testparm - jednoduchý program pro ověření platnosti konfiguračního souboru Samby testprns - program, který provádí testování různých tiskáren a zjišťuje, jestli jsou tyto tiskárny rozpoznatelné démonem smbd 1.2. Adresářové služby a LDAP LDAP (Lightweight Directory Access Protocol) je odlehčená verze protokolu DAP (Directory Access Protocol), který je součástí sady protokolů X.500 [http://www.itu.int/]. Protokol X.500 byl poněkud těžkopádný, zejména kvůli různým dodatečným operacím při transakcích a skutečnosti, že pro běžný síťový provoz používal komplikovaný síťový protokol OSI, který byl na osobních počítačích obtížně implementovatelný. LDAP byl původně vyvinut jako brána k adresáři X.500, přičemž k síťové komunikaci používal rozšířenější a jednodušší protokol TCP/IP a umožňoval tak osobním počítačům s implementovaným protokolem TCP/IP přistupovat k adresářovým službám. LDAP poskytuje adresářové služby takovým způsobem, že správně navržený adresář dovoluje uživatelům přistupovat k datům jednoznačně identifikovaných 8

v globálním měřítku. Každá položka je jednoznačná v tom smyslu, že žádné dvě položky na světě nemají stejný přístupový identifikátor. Server LDAP byl vytvořen a optimalizován pro zpracování jednoduchých dat, která se po zapsání jen zřídka mění. Tradiční databáze byly vytvořeny pro transakce a optimalizovány pro operace čtení a zápisu dat, zatímco LDAP je adresářový systém optimalizovaný na zpracování dotazů (tedy čtení textových dat). Ve skutečnosti jsou aktualizace dat (zápis) na LDAP velmi pomalé. Servery LDAP obvykle používají jednoduché základní databáze, jako jsou databáze Berkeley DB nebo GDBM (GNU Database Manager). Ty poskytují potřebné funkce bez dalších zbytečností a nároků. Na následujícím obrázku je zobrazen organizační diagram uspořádaní dat v adresáři LDAP, který budeme používat v našem případě. Jednotliví uživatelé jsou jednoznačně určeni hierarchií tohoto stromu. Obrázek 1.2.1. : Organizační diagram uspořádání dat Strom je rozdělen do čtyř úrovní znázorněných na obrázku 1.2.1.. Každá úroveň je pojmenována a má přiřazenu konkrétní hodnotu (např. první úroveň má název dc a hodnotu CZ). Chceme-li nalézt data uživatele s uživatelským jménem hartman, postupujeme od kořene stromu směrem k listu a cestu zapíšeme v obráceném pořadí: uid=hartman, ou=users, dc=cag, dc=cz. 9

Krátce se ještě zastavíme u obecné terminologie LDAP: Položka položka je pro adresář zhruba totéž, co pro databázi záznam. Uzel obsahující uživatelské jméno hartman může (a musí, aby se uživatel mohl přihlásit) obsahovat také další informace. Celý uzel jako takový se nazývá položka. Označuje se také jako DSE (Distinguished Service Entry = rozlišená položka služby). Atributy atribut je pro adresář tím, čím je pro databázi pole záznamu. Pole v položce hartman označující jeho jméno je označeno cn a má přiřazenu hodnotu David Hartman to je příklad atributu. Dalším může být například atribut obsahující emailovou adresu s názvem mail a hodnotou hartman@cag.cz. Položka hartman je tedy tvořena několika atributy. Rozlišený název (DN) název používaný k jednoznačné identifikaci uživatele David Hartman je uid=hartman, ou=users, dc=cag, dc=cz. To je rozlišený název neboli DN (Distinguished Name). Atribut, v našem případě uid, je zde vybrán jako klíč, který bude položku představovat. Cesta vedoucí k položce a její hodnoty vytvářejí právě rozlišený název. Proto je tedy DN jednoznačným identifikátorem každé položky. Relativní rozlišený název (RDN) jak již bylo řečeno, každý záznam je přístupný pomocí svého jedinečného jména DN, které je tvořeno ze jména samotného záznamu RDN (Relative Distinguished Name) a celé cesty vedoucí k položce od kořene stromu. V našem případě má záznam David Hartman RDN uid=hartman a DN uid=hartman, ou=users, dc=cag, dc=cz. Schéma schéma adresáře LDAP definuje rozvržení informací obsažených v adresáři a jejich uspořádání. Klienti nebo externí rozhraní tak mohou určit, jak jsou data v adresáři uložena a jak k nim lze přistupovat v případě hledání, přidávání, odstraňování, změn atd. Tyto základní termíny budeme v textu dále používat. Zbytek poměrně rozsáhlé terminologie LDAP není v našem případě potřeba. 10

Pro výměnu dat mezi klienty a serverem LDAP se nejčastěji používá formát LDIF (LDAP Data Interchange Format = formát výměny dat LDAP). Nejedná se ale o jediný způsob výměny dat. Data se mohou předávat prostřednictvím řetězců s položkami oddělenými čárkou nebo dokonce pomocí jazyka XML. Jazyk LDIF byl definován s ohledem na lehkost LDAP. LDIF je textový formát, takže binární data (např. obrázky) je zapotřebí převést metodou base64 do textové podoby a pak je lze teprve uložit jako součást definice LDIF. Když si klienti vyměňují protokolem LDAP informace se serverem LDAP, odesílají a přijímají atributy a položky vyjádřené pomocí formátu LDIF. Kromě toho poskytuje formát LDIF čitelnou podobu dat uložených v adresáři. Vlastní uložení dat na serveru LDAP je ve formátu daném konkrétně využívanou základní databází, který nemá s LDIF nic společného! LDIF lze považovat za jakýsi jazyk LDAP a má i svá úskalí, jako je například nutnost ukládat binární atributy v textovém vyjádření. S tímto problémem se setkáme při ukládání fotografií uživatelů do adresáře LDAP. Nyní si ukážeme, jak takové LDIF vyjádření uživatelských dat vypadá: dn: uid=hartman, ou=users, dc=cag,dc=cz displayname: Hartman David lmpassword: 2F0421A3F32CFBT6VAD3B435B51404EE primarygroupid: 1201 objectclass: inetorgperson objectclass: posixaccount objectclass: sambaaccount smbhome: \\OTHELLO\homes userpassword:: e1ntsef9njm5l2j4dxghr2djmmo5r0r2rugvwuzqy3lrqnmwmdm= scriptpath: hartman.cmd ou: administrator mail: hartman@cag.cz uid: hartman uidnumber: 1304 cn: Hartman David loginshell: /bin/bash homedrive: H: gidnumber: 100 o: Anglo-Czech High School rid: 3608 gecos: Hartman David description: Hartman David homedirectory: /home/z/hartman ntpassword: 27B384FF53JCE2CDAF44734AF2BFBAB2 Výpis je zkrácen a nejsou zde uvedeny všechny atributy, včetně zakódovaných dat atributu jpegphoto, který obsahuje fotografii uživatele. Jak je z výpisu patrné, 11

na každém řádku je uveden vždy jeden atribut a za oddělovačem : (dvojtečka) následuje jeho hodnota. Na pořadí jednotlivých atributů nezáleží. Jak jsme si řekli v předchozím textu, atribut dn je jednoznačný identifikátor každé položky, který sleduje cestu k položce od nejvyšší úrovně, takzvaného kořene. Když budeme postupovat k této položce od vrcholu stromu v diagramu našeho adresáře (viz obrázek 1.2.1.) uvidíme, že DN této položky je uid=hartman, ou=users, dc=cag, dc=cz, což je shodné s hodnotou atributu dn ve vyjádření LDIF. Atribut dn se skládá z názvů RDN oddělených čárkami, přičemž nejvíce vlevo je obvykle atribut samotné položky. Jako RDN této položky jsme stejně tak mohli použít například atribut mail. Její DN by pak bylo mail=hartman@cag.cz, ou=users, dc=cag, dc=cz. Stejně jako v případě atributu uid je zde daná položka jednoznačně určena. Bylo by ale chybné použít například atribut cn, který jako hodnotu obsahuje celé jméno uživatele. V systému se mohou vyskytovat dva uživatelé, kteří mají stejné jméno a příjmení, zatímco uživatelské jméno považujeme v celém systému za jednoznačné. 1.3. Informace o účtech a hesla uživatelů Ve standardní instalaci Samby jsou informace o uživatelských účtech a hesla uživatelů, potřebná pro přihlášení do systému Windows, uložena v souboru /etc/smbpasswd. Vinou nekompatibility LAN Manager a NT hesel je nutné, aby uživatel byl nejprve vytvořen jako uživatel systému Unix (uvedený v /etc/passwd) a až poté může být pro něj vytvořen záznam v /etc/smbpasswd. To nevadí pro malý počet uživatelů a v systémech, kde se noví uživatelé přidávají jen zřídka. V ostatních případech to však může způsobit problémy. Jelikož je nutné, aby uživatel byl uveden v /etc/passwd, musí se tento soubor replikovat na všechny linuxové stanice, které se přes server Samba vzdáleně ověřují. Pokud stanice uživatele nenajde ve svém lokálním souboru /etc/passwd, nemůže uživatele přihlásit, protože nemá informace o jeho UID, GID, domovském adresáři a shellu. Kopírování souboru na všechny linuxové stanice při každém přidání nového uživatele do systému je neefektivní a problematické. 12

Uložením všech informací o jednotlivých uživatelích a jejich hesel pro systémy Windows i Linux na jedno místo - do adresáře LDAP se odstraní potřeba kopírování souboru /etc/passwd na jednotlivé stanice a usnadní správa. V každém záznamu pro uživatele v adresáři LDAP jsou uloženy informace potřebné pro přihlášení do Linuxu i Windows a další informace. 1.4. Domény Windows, řídící počítač domény Nadstavbou protokolu SMB, vyvinutou firmou Microsoft, jsou tzv. domény Windows. Doména je skupina počítačů obsahující server, který pracuje jako tzv. řídící počítač domény (Domain Controller - DC). Pro existenci domény je tento server nutnou podmínkou. DC domény (přihlašovací server) je ústředním bodem domény Windows. Jednou z jeho hlavních funkcí je proces autentizace (ověření) a autorizace (přidělení nebo odepření uživatelského přístupu) ke sdíleným síťovým zdrojům. Řídící počítač domény tedy obsahuje centrální seznam hesel, které jsou svázány s uživatelskými jmény, což je mnohem efektivnější než uchovávání stovek hesel na klientských počítačích ke každému sdílenému síťovému zdroji. Aktivní DC domény se nazývá primární řídící počítač domény (Primary Domain Controller - PDC). Kromě toho může v doméně existovat jeden nebo více záložních řídících počítačů domény (Backup Domain Controllers - BDCs), které přebírají funkci primárního DC v případě jeho výpadku. Záložní DC provádějí synchronizaci dat s primárním DC. Kopie dat mají pouze pro čtení a mohou se aktualizovat jen v případě synchronizace s PDC. Samba může bez jakýchkoli problémů pracovat jako PDC pro počítače s operačními systémy Windows 95/98, Windows 2000 a Windows XP. Operační systémy Windows 95/98 používají starší šifrovací systém zděděný ze síťového softwaru LAN Manager, zatímco klienti a servery na bázi NT používají novější šifrovací systém. V adresáři LDAP jsou uloženy obě varianty hesel. Problém může 13

nastat se staršími verzemi Windows 95, kde není šifrování hesel podporováno vůbec. 1.5. Konfigurace sítě LAN a serveru Ke konfiguraci Samby jako PDC pro stanice s operačním systémem Microsoft Windows předpokládejme, že všechny stanice jsou ve stejné síti 192.168.1.0/24 a doména má název CAG. Server, který slouží jako PDC má IP adresu 192.168.1.1/32, NetBIOS jméno OTHELLO a zároveň slouží a jako server WINS. Informace o uživatelských účtech, heslech, počítačích a skupinách jsou uloženy v serveru LDAP s RDN dc=cag,dc=cz. Server (obrázek 1.5.1.) je od firmy Compaq (ProLiant DL350M) a je určen pro menší a střední počítačové sítě. Hardwarová konfigurace je 1x CPU Intel Pentium III (1,13 GHz FC-PGA, 256KB L2 cache), 512 MB RAM (PC 133MHz, ECC SDRAM DIMM), integrovaný Ultra2 SCSI řadič a 2x Fast Ethernet síťový adaptér (Intel 82557/8/9 a 3c905C-TX). Data se ukládají na dva SCSI pevné disky s celkovou kapacitou 72 GB a přenosovou rychlostí 160 MB/s. Na serveru je nainstalován operační systém RedHat Linux 7.3 a server zároveň Obrázek 1.5.1. : ProLiant DL350M slouží jako webový a poštovní server. 14

2. Instalace potřebného softwaru Abychom mohli nakonfigurovat server Samba jako PDC, potřebujeme stabilní verzi Samby [www.samba.org], serveru OpenLDAP [www.openldap.org] a balík skriptů pro správu uživatelských účtů a skupin z příkazového řádku smbldap-tools [www.idealx.com]. Samba je nyní ve verzi 3.x.x, ale pro naše potřeby plně postačí i poslední stabilní verze 2.2.8a-1. 2.1. Stažení, kompilace a instalace Samby Samba je dostupná ve formě jak binárních, tak zdrojových souborů na několika zrcadlených místech v Internetu. Primární domovský server Samby lze najít na adrese http://www.samba.org. Abychom Sambu mohli používat spolu s LDAP serverem, musíme ji zkompilovat ze zdrojových souborů nebo si vytvořit RPM balíčky Samby s podporou LDAP. Na serveru je nainstalována distribuce Linuxu od firmy RedHat [www.redhat.com], a proto je výhodnější druhá možnost. Nejprve stáhneme a nainstalujeme poslední verzi balíčku zdrojových souborů samba-2.2.8a-1.src.rpm (rpm ivh samba-2.2.8a-1.src.rpm). Po úspěšné instalaci se v /usr/src/redhat/build/ objeví adresář se stejným jménem jako je název balíčku se zdrojovými soubory. Než přistoupíme ke kompilaci RPM souborů musíme nejprve upravit soubor /usr/src/redhat/specs/samba.spec, který obsahuje možnosti pro kompilaci. Zapneme podporu pro LDAP (--with-ldapsam), podporu modulů PAM (--with-pam) a podporu tiskového serveru CUPS (--enable-cups). Příkazem cd /usr/src/redhat/specs/ && rpm ba samba.spec spustíme kompilaci RPM souborů. Pokud vše proběhne v pořádku, najdeme v adresáři /usr/src/redhat/rpms/i386/ RPM soubory samba-common-2.2.8a-1.rpm, samba-2.2.8a-1.rpm a samba-client-2.2.8a-1.rpm, které stačí nainstalovat 15

příkazem rpm ivh samba-*. Před instalací nových RPM souborů je nutné odinstalovat všechny předchozí balíčky Samby! 2.2. Stažení a instalace OpenLDAP Instalace serveru LDAP je o něco jednodušší. Stačí stáhnout z ftp://ftp.redhat.com nebo jiného mirroru RPM balíčky openldap-2.0.27-2.7.3, openldap-clients-2.0.27-2.7.3 a openldap-servers-2.0.27-2.7.3 a ty nainstalovat příkazem rpm ivh openldap-*. Tato verze opět není poslední, ale je ověřeno, že se Sambou bezproblémově spolupracuje. 2.3. Stažení a instalace balíku smbldap-tools Smbldap-tools je balíček skriptů, naprogramovaných v jazyce Perl, sloužící k základním operacím s uživatelskými účty. Všechny tyto příkazy se používají z příkazového řádku. Ještě před instalací je nutné zkontrolovat, zda je v systému nainstalován modul pro Perl s názvem Net::LDAP a samozřejmě Perl samotný. Samba musí být nainstalována na stejném stroji jako tyto skripty, ale server OpenLDAP může být spuštěn na jiném počítači. V takovém případě je nutné zkontrolovat bezchybnou komunikaci se serverem LDAP pomocí standardních nástrojů. Instalace skriptů je snadná. Stačí ze stránek http://samba.idealx.org/ stáhnout soubor se zdrojovými kódy s názvem smbldap-tools-0.7.2.tgz, rozbalit jej a všechny soubory nakopírovat do adresáře /usr/local/sbin/. Pro systémy s distribucí RedHat autoři doporučují použít připravený RPM balíček, který se instaluje příkazem rpm ivh smbldap-tools-0.7-2.i386.rpm. Pro verzi Samby 3 je určen stejnojmenný balík skriptů ve vyšší verzi. Ten nově umožňuje uživatelům změnu hesla z příkazového řádku. To je dáno zejména rozdělením jednoho konfiguračního souboru na dva. První může číst pouze uživatel root a obsahuje definici administrátorského účtu pro připojení k serveru LDAP. Druhý obsahuje nastavení globálních parametrů, které mohou číst všichni uživatelé. 16

4. Konfigurace serveru OpenLDAP Před vlastním spuštěním serveru OpenLDAP je nutné udělat několik změn v konfiguračních souborech tak, aby byl schopen sloužit jako databáze uživatelů, počítačů a skupin pro Sambu a systém Linux. Musí akceptovat LDAP schéma, které používá Samba verze 2.x.x, běžet na základu dc=cag, dc=cz a obsahovat povinné záznamy. Struktura stromu může vypadat například takto: dc=cag,dc=cz +--- ou=users : k ukládání uživatelských účtů (posixaccount a sambaaccount) pro Unixové a Windows systémy +--- ou=computers : k ukládání účtů počítačů (sambaaccount) pro Windowsové systémy +--- ou=groups : k ukládání systémových skupin (posixgroup) pro Unixové a Windows systémy Pro ukládání objektů je možné použít i jiný strom, ale tato struktura je doporučena vývojáři Samby a je podporována skripty z balíku smbldap-tools. Účty pro uživatele systému Windows, stejně jako účty jednotlivých počítačů (pracovních stanic), se ukládají pomocí třídy objektů sambaaccount (samba.schema). Účty pouze pro Unix se ukládají pomocí třídy objektů posixaccount (nis.schema) a uživatelské skupiny pomocí třídy posixgroup. 4.1. Schéma a úprava konfigurace Soubor samba.schema je dodáván se zdrojovými kódy Samby a je uložen v adresáři /usr/src/redhat/build/samba-2.2.8a/examples/ldap/. Tento soubor je potřeba zkopírovat do adresáře /etc/openldap/schema/. Pokud se bude zároveň používat schéma inetorgperson, je nutné v souboru samba.schema zakomentovat typ atributu displayname, který je již tímto schématem definován. Pokud se používat nebude, nemusíme dělat žádné úpravy. 17

Dalším nezbytným krokem je správné nastavení serveru slapd (Stand-alone LDAP Daemon). Do souboru /etc/openldap/slapd.conf přidáme schéma pro Sambu a nastavíme údaje pro přihlášení administrátora, který má neomezený přístup ke všem uloženým záznamům. soubor /etc/openldap/slapd.conf pro SAMBA-LDAP include include include include include database sufix rootdn rootpw directory /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /etc/openldap/schema/samba.schema ldbm "dc=cag,dc=cz" "cn=manager,dc=cag,dc=cz" tajneheslo /var/lib/ldap Celý soubor je v příloze. Direktiva database ldbm označuje základní databázi, kterou bude server LDAP používat a direktiva directory /var/lib/ldap říká serveru, kde najde vlastní databázi a indexové soubory. K tomuto konfiguračnímu souboru musí mít přístup pouze uživatel, pod kterým je spouštěn LDAP server a nesmí mít v žádném případě nastaven atribut čtení pro zbytek světa. Heslo administrátora je zde uloženo jako prostý text, což není z hlediska bezpečnosti příliš dobré, a proto je lepší heslo do konfiguračního souboru uložit v zašifrované podobě. [hartman@othello /]$ /usr/sbin/slappasswd -h {CRYPT} -s tajneheslo {CRYPT}qBCGp7afTjd3A Takto získané heslo stačí do souboru uložit místo původního hesla. Utilitu /usr/sbin/slappasswd budeme také používat pro generování zašifrovaného uživatelského hesla (atribut userpassword) při jeho změně přes webové rozhraní. Ke generování LAN Manager (LM) a NT hesel (atributy lmpassword a ntpassword) naopak budeme používat utilitu /usr/local/sbin/mkntpwd, která je součástí balíčku smbldap-tools. Řádek s heslem by pak vypadal takto: ( ) rootpw ( ) {CRYPT}qBCGp7afTjd3A 18

Posledním souborem, který ještě musíme před spuštěním upravit, je /etc/openldap/ldap.conf. Tento soubor může mít nastaven atribut čtení pro zbytek světa, ale nesmí mít pro tuto skupinu nastaven atribut zápisu. soubor /etc/openldap/ldap.conf pro SAMBA-LDAP LDAP Defaults HOST 127.0.0.1 BASE dc=cag,dc=cz BINDDN cn=manager,dc=cag,dc=cz Nyní je server připraven k prvnímu spuštění. Pokud při spuštění dojde k nějakým chybám, je nutné zkontrolovat schémata a zda adresář /var/lib/ldap/ vlastní uživatel, pod kterým se spouští server LDAP. Pokud je vše nastaveno správně a přesto nelze server spustit, může pomoci dokumentace (man ldap). Server spustíme na systémech RedHat příkazem: [root@othello root] service ldap start Startuji slapd: [ OK ] Pokud spuštění serveru slapd proběhlo bez problémů, je potřeba vytvořit stromovou strukturu, která je popsána v úvodu této podkapitoly. Soubor base.ldif je součástí balíku smbldap-tools. Jsou v něm kromě základních prvků stromu definovány i všechny skupiny, které budou pak k dispozici pro Windows i unixové uživatele. Většina z nich se ale nikdy nepoužije. Celý soubor najdete v příloze. Popsaný LDIF soubor přidáme příkazem: [hartman@othello tmp]$ ldapadd -x -h localhost -D \ > "cn=manager,dc=cag,dc=cz" -f base.ldif W Enter LDAP Password: Po zadání hesla administrátora se vytvoří požadovaná struktura. Pro její kontrolu můžeme použít nějaký nástroj pro správu záznamů, jakým je například LDAP Browser/Editor [http://www.iit.edu/~gawojar/ldap/]. Tento program je celý napsaný v programovacím jazyce JAVA a funguje v operačních systémech Windows i Linux. Na serveru jsou jednotlivé záznamy uloženy v kódování 19

Unicode UTF-8, které tento program korektně zobrazuje i ukládá v systému Windows (testováno na Windows XP SP1). Pokud je naším cílem pouze záznamy prohlížet, nemusíme při vytváření nového připojení vyplňovat DN pro administrátora ani jeho heslo, ale musíme zaškrtnout možnost pro anonymní přístup (Anonymous bind). Nové připojení by pak mohlo vypadat následujícím způsobem (obrázek 4.1.1.). Obrázek 4.1.1. : LDAP Browser/Editor nové připojení Po uložení nově definovaného připojení se připojíme k serveru. Pokud jsou všechny údaje v pořádku, zobrazí se struktura, která byla vytvořena v předchozí části. Správný výpis struktury stromu vypadá následovně (obrázek 4.1.2.). Obrázek 4.1.2. : LDAP Browser/Editor struktura adresáře LDAP 20

4.2. Konfigurace smbldap-tools Ještě zbývá upravit konfigurační soubor smbldap_conf.pm balíku smbldap-tools, který se nachází ve stejném adresáři jako skripty. Tento soubor musíme upravit podle nastavení serveru OpenLDAP, zejména musíme zadat heslo administrátora, adresu serveru LDAP a specifické informace o uložení uživatelských profilů a domovských adresářů. Při konfiguraci narazíme na dvě matoucí proměnné: slaveldap a masterldap. V našem případě máme jen jeden server LDAP, a proto vyplníme obě hodnoty stejně, tj. 127.0.0.1 (nebo localhost). Pokud by byl server LDAP spuštěn na jiném počítači, vyplnili bychom zde jeho IP adresu. Slave LDAP : needed for read operations Ex: $slaveldap = "127.0.0.1"; $slaveldap = "localhost"; Master LDAP : needed for write operations Ex: $masterldap = "127.0.0.1"; $masterldap = "localhost"; LDAP Suffix Ex: $suffix = "dc=idealx,dc=org"; $suffix = "dc=cag,dc=cz"; Abychom mohli jednotlivé záznamy uživatelů pomocí těchto skriptů také měnit, musíme zadat údaje pro přihlášení administrátora, který má právo zápisu pro celý strom. Zde bohužel musí být heslo uvedeno v nezašifrované podobě. Tento problém neřeší ani nejnovější verze těchto skriptů. Credential Configuration Bind DN used Ex: $binddn = "cn=manager,$suffix"; for cn=manager,dc=idealx,dc=org $binddn = "cn=manager,$suffix"; Bind DN passwd used Ex: $bindpasswd = 'secret'; for 'secret' $bindpasswd = "tajneheslo"; 21

Poslední úpravou je nastavení cesty k domovskému adresáři pro Windows (bude po přihlášení přimapován jako disk H:\) a cestu k uživatelskému profilu s nastavením. Skripty ve výchozím nastavení počítají s uložením uživatelských profilů na jiném místě než v domovském adresáři. My budeme adresář s nastavením vždy ukládat do domovského adresáře každého uživatele (např. /home/z/hartman/profile/). The UNC path to home drives location without the username last extension (will be dynamically prepended) Ex: q(\\\\pdc-netbios-name\\homes) for \\PDC-netbios-name\homes $_usersmbhome = q(\\\\othello\\homes); The UNC path to profiles locations without the username last extension (will be dynamically prepended) Ex: q(\\\\pdc-netbios-name\\profiles) for \\PDC-netbios-name\profiles $_userprofile = q(\\\\othello\\homes\\profile); The default Home Drive Letter mapping (will be automatically mapped at logon time if home directory exist) Ex: q(u:) for U: $_userhomedrive = q(h:); Za zmínku ještě stojí proměnná, která určuje název přihlašovacího skriptu. Ve výchozím nastavení není jeho název definován a při vytvoření nového uživatele se automaticky použije hodnota UživatelskéJméno.cmd. Zkušenost ale ukázala, že to není dobré řešení, protože vždy po vytvoření nového uživatele je nutné tento soubor vytvořit ručně v adresáři /etc/samba/netlogon/. Výhodnější je použít univerzální přihlašovací skript, například s názvem startup.cmd, pro všechny uživatele. Pokud nějaký uživatel bude mít specifický přihlašovací skript, lze tento název změnit v jeho záznamu (atribut scriptpath) a tento soubor potom nakopírovat do výše uvedeného adresáře. Tím je konfigurace globálních proměnných u konce, ještě ale provedeme drobnou úpravu vlastního skriptu pro vytvoření nového uživatele. Bylo by určitě příjemné, kdybychom mohli server LDAP využívat v emailových klientech také jako adresář (pouze pro čtení). Podporu serveru LDAP jako adresáře obsahuje většina 22

z nich a nejpropracovanější je určitě v programech Ximian Evolution (Linux) a Netscape Mail (Windows). Základní podporu najdeme i v programech od firmy Microsoft (Outlook, Outlook Express) a dalších. Aby fungovala funkce vyhledávání emailových adres podle jména a příjmení uživatele, musíme ke každému záznamu přidat atribut s názvem mail, který bude obsahovat emailovou adresu ve tvaru UživatelskéJméno@cag.cz. Ještě přidáme atribut o (Organization), kde bude hodnota napevno nastavena na Anglo-Czech High School. Ve skriptu smbldap-useradd.pl najdeme část, kde se vytváří pole hodnot jednotlivých atributů a přidáme mail a o následujícím způsobem (zvýrazněno tučně): smbldap-useradd.pl ( ) o: Anglo-Czech High School cn: $username sn: $username uid: $username mail: $username\@cag.cz uidnumber: $useruidnumber gidnumber: $usergidnumber ( ) Další kosmetickou úpravou tohoto skriptu bude přidání atributu ou (Organizational Unit), kde hodnotou bude třída, kterou student navštěvuje. Učitelé zde budou mít uloženu hodnotu teacher a ostatní other. Zde již není úprava tak jednoduchá. Musíme umožnit zadání hodnoty z příkazového řádku a ošetřit případ, kdy hodnota nebude zadána explicitně. Nejprve otestujeme, zda jsou všechny parametry správně zadány. Pokud tomu tak není vypíšeme nápovědu, kde jsme přidali novou volbu -e, za kterou by měl následovat název třídy (např. Prima, Sekunda, Tercie,,1.ročník atd.). my $ok = getopts('axnmwpg:u:g:d:s:c:e:k:a:b:c:d:e:f:h:?', \%Options); ( ) print " -s shell\n"; print " -c gecos\n"; print " -e department (probably class)\n"; ( ) my $userdepartment = $Options{'e'}; if (!defined($userdepartment)) { $userdepartment = 'other'; } ( ) 23

Pokud je zadána volba -e a za ní následuje název třídy, pak se tato hodnota uloží do proměnné $userdepartment. Není-li hodnota zadána, místo názvu třídy se použije řetězec other. Nakonec tuto proměnnou uložíme jako atribut ou, podobně jako tomu bylo v předchozím případě (úpravy jsou zvýrazněny tučně). ( ) o: Anglo-Czech High School cn: $username sn: $username uid: $username mail: $username\@cag.cz ou: $userdepartment uidnumber: $useruidnumber gidnumber: $usergidnumber ( ) Pro ilustraci je na obrázku 4.1.3. ukázka prohledávání adresáře LDAP v programu Netscape Mail 7.1.. Po zadání části jména nebo příjmení se prohledají všechny záznamy a zobrazí se jen ty, které odpovídají zadanému kritériu. Tento program samozřejmě obsahuje i pokročilejší funkce pro vyhledávání. Ve sloupci Name je zobrazena hodnota atributu cn, ve sloupci Email hodnota atributu mail, Company je atribut o a nakonec sloupec Department je atribut ou. Podobným způsobem fungují i ostatní klienti pro práci s adresářem LDAP. Obrázek 4.1.3. : Netscape Mail - vyhledávání v adresáři LDAP 24

5. Konfigurace Linuxu (moduly PAM) V době, kdy neexistoval žádný univerzální autentizační systém, musela každá aplikace, která poskytovala nějakou službu, provést kontrolu uživatele sama. Některé služby měly své bezpečnostní mechanismy velmi slabé a mnoho lidí se je snažilo oklamat za účelem získání nepovoleného přístupu. Další vadou na kráse zabudovaných systémů ověřování identity byla nemožnost jejich rozšiřování. Například při přechodu na systém stínových hesel, kdy jsou hesla uchována ve zvláštním, běžným uživatelům nepřístupném souboru /etc/shadow, bylo nutné upravit zdrojové kódy programu login a všech podobných aplikací, které využívaly k ověřování uživatelů soubor /etc/passwd. 5.1. Linux-PAM Hlavní myšlenkou PAM je, aby uživatelské programy byly nezávislé na konkrétních autentizačních postupech. Aplikace chce obvykle vědět, zda má službu poskytnout nebo ne, ale nezajímá ji, jakým způsobem je ověření uživatele realizováno. Linux-PAM (Pluggable Authentication Modules for Linux) je systém modulů, který ovládá autentizační úlohy aplikací/služeb systému. Nejdůležitější vlastností PAM je, že administrátor může úpravou seznamu modulů libovolně určovat postup autentizace. Pro mnoho serverů je jím stále jednoduchý soubor s hesly. Modul PAM je knihovna, kterou lze připojit k uživatelským i systémovým programům. Když programy potřebují provést autentizaci nebo autorizaci uživatele, zavolají funkci, která se nachází v knihovně PAM. Volaná funkce hledá konfigurační soubory dané aplikace a jestliže žádný takový soubor není, použije modul PAM implicitní konfigurační soubor /etc/pam.d/other. Konfigurační soubor sděluje knihovně, jaké typy ověření se musí provést za účelem autentizace a autorizace uživatele. Na základě toho se volá příslušný modul. Ten může zkontrolovat cokoli, například může jednoduše nahlédnout do souboru s hesly nebo provést nějakou složitější 25

kontrolu - např. zavolat server LDAP, jako tomu bude v našem případě. Poté co modul provedl kontrolu, vrátí volající aplikaci zprávu ověřeno/neověřeno. 5.1. Konfigurační soubory modulů PAM Stejně jako ostatní programy v distribuci RedHat si i systém PAM ukládá své konfigurační soubory do adresáře /etc/, konkrétně /etc/pam.d/. Soubory mají stejný název jako je název aplikace, pro kterou je modul určen. Jestliže aplikace používající modul PAM nemá vlastní konfigurační soubor, automaticky se použije konfigurační soubor s názvem /etc/pam.d/other. Konfigurační soubor modulu PAM je zajímavý tím, že každý řádek se v průběhu procesu ověřování vyhodnocuje. Každý řádek specifikuje modul, který provádí činnost spojenou s autentizací nebo autorizací a vrací příznak úspěchu nebo neúspěchu. Celkový výsledek se vrací do programu, který modul PAM zavolal. Pojmem neúspěch není zde míněno selhání programu. Znamená to, že při ověřování toho, zda by uživatel mohl provést určitou činnost, se vrátila hodnota NE. Každý soubor se skládá z řádků v následujícím formátu: module_type control_flag module_path arguments kde module_type označuje jeden ze čtyř typů modulů: Auth, Account, Session nebo Password. Poznámky musí začínat křížkem (). V tabulce 5.1.1. jsou uvedeny typy těchto modulů a jejich stručný popis. Typ modulu Auth Account Session Funkce Přikazuje aplikačnímu programu, aby vyzval uživatele k zadání hesla a uděluje práva uživatelů a skupin. Neprovádí autentizaci ani autorizaci, ale vymezuje přístup na základě jiných faktorů, jako např. čas nebo místo, kde se uživatel nachází. Přihlášení superuživatele může proběhnout např. jen prostřednictvím konzole. Určuje, jaká činnost (pokud taková existuje) se musí provést před přihlášením uživatele nebo po něm. Password Určuje, který modul umožní uživateli změnu hesla. Tabulka 5.1.1. : Typy modulů a jejich funkce 26

Control_flag nám umožňuje určit, jak naložíme s úspěchem nebo neúspěchem určitého modulu autorizace. Řídící příznaky (Control Flags) jsou popsány v tabulce 5.1.2.. Parametr module_path určuje platnou cestu do adresáře modulu, který provádí autentizaci nebo autorizaci. Kompletní seznam modulů najdete na webové stránce věnované modulům PAM [www.kernel.org/pub/linux/libs/pam/]. Řídící příznak Required Requisite Suffiscient Funkce Jestliže je specifikován tento příznak, modul MUSÍ provést autorizaci jednotlivce úspěšně. Tento příznak je podobný příznaku required, pouze s tím rozdílem, že když requisite neuspěje při ověřování, moduly uvedené v konfiguračním souboru za ním se nevolají a aplikace obdrží návratovou hodnotu neúspěch. Máme tak možnost vyžadovat splnění určitých podmínek ještě před vlastním přihlášením (podmínkou může být např. to, že uživatel se nachází v lokální počítačové síti a není přihlášen z Internetu). Jestliže modul suffiscient vrátí hodnotu úspěch a v konfiguračním souboru se nevyskytují žádné další řídící příznaky required nebo suffiscient, modul PAM vrátí volající aplikaci hodnotu úspěch. Optional Tento příznak umožňuje, aby modul PAM dále kontroloval další moduly, a to i v případě, že tento modul neuspěl. Můžeme jej použít tehdy, když je povoleno přihlášení uživatele i přesto, že určitý modul neuspěl. Tabulka 5.1.2. : Řídící příznaky a jejich funkce Posledním údajem v konfiguračním souboru modulu PAM je položka arguments. Jsou to parametry, které se předávají modulu. Ačkoli jsou tyto parametry pro každý modul specifické, mají několik všeobecných voleb, které se dají použít u všech modulů. Tyto parametry jsou popsané v tabulce 5.1.3.. Jak jsme již zmínili dříve, když nemůže modul PAM najít konfigurační soubor specifický pro danou aplikaci, použije místo toho univerzální (generický) konfigurační soubor. Tento soubor se nazývá /etc/pam.d/other. Implicitně je tento 27

soubor nastaven tak, že všechny pokusy o autorizaci se zaprotokolují a poté okamžitě zamítnou. Toto nastavení by se nemělo měnit! Parametr debug no_warn use_first_pass try_first_pass Funkce Zasílá podrobné výpisy o ladění log-souborům systému (nejčastěji do adresáře /var/log/). Nepředává volající aplikaci žádné výstražné zprávy. Nevyzývá uživatele k dvojímu zadání hesla. Místo toho se k potvrzení jeho způsobilosti ke vstupu do systému použije heslo, které uživatel zadal u předchozího modulu. Tato volba je podobná jako use_first_pass, kde uživatel neobdrží výzvu k zadání hesla. Jestliže ale stávající heslo způsobí, že modul vrátí neúspěch, uživatel je nucen zadat heslo podruhé a modul to zkouší znovu. use_mapped_pass Předává heslo z předchozího modulu do modulu aktuálního, stejně jako use_first_pass. Heslo se však použije k vygenerování šifrovacího nebo dešifrovacího klíče. Tabulka 5.1.3. : Parametry modulu PAM a jejich funkce Pokud při konfiguraci modulů PAM uděláme chybu, může se stát, že se do systému nebudeme moci přihlásit ani jako superuživatel root. Pro minimalizaci tohoto rizika, je dobré si vytvořit zálohu původního (funkčního) konfiguračního souboru a ze systému se neodhlašovat dříve, než vše řádně vyzkoušíme. Pokud se ale náhodou přece jen stane, že se nelze přihlásit, stačí systém restartovat v jednouživatelském režimu a nahradit změněný konfigurační soubor funkční zálohou nebo vrátit všechny změny zpět. 5.2. Konfigurace modulů PAM Pro ověřování pracovních stanic proti serveru LDAP je nutné vhodně upravit konfigurační soubory modulů PAM tak, aby se kromě souboru s hesly kontrolovaly i záznamy LDAP. V zásadě existují dva postupy, jak toho docílit. Prvním z nich je ruční editace souboru /etc/pam.d/system-auth a druhým použití konfiguračního nástroje /usr/sbin/authconfig, ve kterém jen nastavíme údaje o serveru LDAP a on upraví potřebné soubory sám. Druhý způsob je k dispozici jak v textové konzoli, tak i grafickém prostředí (/usr/bin/authconfig-gtk). 28

Obrázek 5.2.1. : GNOME konfigurace PAM Obrázek 5.2.2. : GNOME konfigurace PAM Na obrázcích 5.2.1. a 5.2.2. je ukázka Konfigurace autentizace v prostředí Gnome distribuce RedHat. Na těchto dvou kartách povolíme podporu LDAP a pokud v systému běží démon nscd (Name Service Cache Deamon), můžeme povolit i kešování uživatelských informací, což by mohlo ulehčit serveru LDAP při opakovaných dotazech a zrychlit jeho odezvu. Pro přihlášení do systému jen samotné zapnutí podpory LDAP nestačí. Musíme ještě nastavit informace, na kterém stroji server LDAP běží a v jaké části stromu se mají informace o uživatelích hledat. Obrázek 5.2.3. : GNOME nastavení LDAP Na obou kartách po kliknutí na tlačítko Konfigurace LDAP vyplníme údaje, jako jsou na obrázku 5.2.3. Informace o uživatelích jsou uloženy v části s DN: ou=users,dc=cag,dc=cz a adresa serveru LDAP je othello.caglan.cz. Po potvrzení obou dialogových oken se změny zapíší do souboru /etc/pam.d/system-auth. %PAM-1.0 This file is auto-generated. 29

User changes will be destroyed the next time authconfig is run. auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so account sufficient /lib/security/pam_ldap.so password required /lib/security/pam_cracklib.so retry=3 type= password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/pam_ldap.so use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so Změny v konfiguračním souboru jsou zvýrazněny tučně. V kapitole 4.1. jsme upravovali konfigurační soubor /etc/openldap/ldap.conf. Nyní do něj připíšeme další nastavení. Nejdůležitější je změna způsobu vyhledávání z výchozího?one na?sub, která je nutná právě díky rozdělení jednotlivých účtů počítačů (ou=computers,dc=cag,dc=cz) a uživatelů (ou=users,dc=cag,dc=cz). soubor /etc/openldap/ldap.conf pro SAMBA-LDAP ( ) nss_base_passwd dc=cag,dc=cz?sub nss_base_shadow dc=cag,dc=cz?sub nss_base_group ou=groups,dc=cag,dc=cz?one ssl no pam_passwords md5 - The End 5.3. Testování nastavení K otestování korektní komunikace systému se serverem LDAP vytvoříme uživatelský učet s názvem testuser a zkusíme tohoto nového uživatele přihlásit. K vytvoření uživatele použijeme skript z balíku smbldap-tools s názvem smbldap-useradd.pl. [root@othello /] smbldap-useradd.pl -m -c "Test User" testuser [root@othello /] smbldap-passwd.pl testuser Changing password for testuser New password : Retype new password : all authentication tokens updated successfully 30

Uživatele se podařilo vytvořit a to znamená, že balík smbldap-tools a server OpenLDAP jsou správně zkonfigurovány a že spolu komunikují. Nezbývá nic jiného než otestovat zda se podaří uživatele do systému přihlásit. [root@othello /] ssh testuser@othello testuser@othello's password: Last login: Mon Dec 15 10:49:34 2003 from hartman.caglan.cz [testuser@othello testuser]$ id uid=1363(testuser) gid=100(users) skupiny=100(users) [testuser@othello testuser]$ finger testuser Login: testuser Name: Test User Directory: /home/testuser Shell: /bin/bash On since Fri Mar 5 22:37 (CET) on pts/1 from othello.caglan.cz No mail. No Plan. Uživatel se úspěšně přihlásil přes ssh klienta a to ukazuje, že i PAM moduly jsou bezchybně nakonfigurovány. Systém při ověřování uživatele nejprve hledá uživatele lokálně a pak až prohledává adresář LDAP. To je správné, protože jen tak se může přihlásit k systému i superuživatel root, který je veden pouze lokálně. O úspěšném přihlášení bychom našli záznam i v systémových log-souborech. Jelikož tohoto uživatele již nepotřebujeme, tak ho smažeme i s jeho domovským adresářem, který mu byl při založení vytvořen. [root@othello /] smbldap-userdel.pl -r testuser 31

6. Souborové systémy Každý uživatel přihlášený do systému potřebuje místo pro uložení svých specifických konfiguračních souborů. Tímto místem je domovský adresář, který umožňuje všem uživatelům pracovat ve svém vlastním upraveném prostředí. V tomto adresáři se ukládají nejen konfigurační soubory každého uživatele, ale i jeho pracovní soubory, dokumenty a profil s nastavením pro stanice s Windows (jak bude popsáno v dalších kapitolách). Z důvodu konzistence většina serverů umísťuje adresáře jednotlivých uživatelů do adresáře /home/ pod stejným názvem, jako je jeho uživatelské jméno. Výjimkou jsou systémové účty, jako např. účet superuživatele, který má tradičně podobu /root/. Umístění domovských adresářů do /home/ není povinné. Má to však svůj organizační význam. Z hlediska lepší přehlednosti je v systémech s velkým počtem uživatelů vhodné jejich domovské adresáře ještě dále členit do podadresářů. Toho s výhodou využijeme například při nastavení diskových kvót pro jednotlivé skupiny uživatelů. V našem případě budeme adresáře ukládat do tří podadresářů: /home/z/, kde budou uloženy domovské adresáře pro zaměstnance, /home/s/ pro studenty a /home/o/ pro všechny ostatní. Místo, kde má systém hledat domovský adresář přihlášeného uživatele, je uloženo jako atribut homedirectory (např.: homedirectory: /home/z/hartman) v jeho záznamu LDAP. V kapitole 5 jsme nastavili linuxové pracovní stanice a server pro ověřování uživatelů proti serveru LDAP. Na serveru, kde mají uživatelé své adresáře uloženy lokálně, proběhne celý proces přihlášení v pořádku i s načtením jeho konfiguračních souborů. Na pracovních stanicích je situace jiná. Uživatel se sice přihlásí, ale jeho konfigurační soubory se nenačtou, protože domovský adresář uživatele se nepodařilo nalézt. Tento problém se dá na linuxových stanicích vyřešit pomocí NFS (Network File System). Umístěním domovských adresářů na diskové oddíly připojené přes NFS umožníme uživateli přístup do jeho domovského adresáře z jakékoli linuxové pracovní stanice v síti. V prostředí s různými operačními systémy 32

je to velmi výhodné, protože uživatelé se nemusí obávat přechodu mezi jednotlivými stanicemi. Pro každý operační systém mají specifická nastavení, která se navzájem neovlivňují a z každého z nich mohou přistupovat ke svým dokumentům. 6.1. Síťové souborové systémy Unix umožňuje sdílení souborů a aplikací v rámci počítačové sítě prostřednictvím síťového souborového systému NFS (Network File System), jehož podstata je podobná sdílení disků ve Windows. Hlavní podobnost spočívá v tom, že oba operační systémy umožňují připojovat síťové disky a pracovat s nimi jako s lokálními. Kromě této vlastnosti mají síťový souborový systém OS Linux a Windows více rozdílného než společného. Pro připojování a odpojování síťových disků platí stejné principy jako pro souborové systémy. Nesmí se však zapomenout nakonfigurovat server tak, aby povolil uživatelům sdílení určitých diskových oddílů. Připojení síťového souborového systému si objasníme na následujícím příkladu. Chceme-li na pracovní stanici public sdílet domovské adresáře všech studentů /mnt/shomes/s/ ze serveru othello tak, aby se jevil jako lokální adresář /home/s/, musíme zadat: [root@public /] mkdir -p /mnt/nfs/shomes [root@public /] mount othello:/mnt/shomes/ /mnt/nfs/shomes [root@public /] ln -s /mnt/nfs/shomes/s/ /home/s Připojit síťový nebo souborový systém lze jen do existujícího adresáře. Z hlediska přehlednosti vytvoříme adresář /mnt/nfs/shomes/, do kterého příkazem v druhém řádku připojíme sdílený souborový systém ze serveru othello. Nakonec vytvoříme symbolický odkaz /home/s na adresář /mnt/nfs/shomes/s/. Pro kontrolu zkusíme vypsat obsah adresáře /home/s/. [root@public /] cd /home/s/ [root@public S] ll celkem 1224 drwx------ 18 adamek users 4096 úno 15 10:15 adamek drwx------ 22 altera users 4096 led 13 13:57 altera drwx------ 6 ambroz users 4096 úno 23 10:15 ambroz... výpis zkrácen 33

Kontrola byla úspěšná. V adresáři /home/s/ jsou skutečně adresáře jednotlivých uživatelů, v našem případě ale jen studentů. Jak sdílet celou strukturu adresáře /home/* ze serveru othello na pracovních stanicích bude rozebráno později. 6.2. Konfigurace serveru NFS Server NFS lze nastavit ve dvou krocích. Prvním z nich je vytvoření souboru /etc/exports, který definuje, jaké části disku serveru budou sdíleny s ostatními uživateli sítě. Soubor také stanoví pravidla sdílení. V souboru /etc/exports je například uvedeno, zda má určitý uživatel právo z disku jen číst nebo také zapisovat. Druhým krokem je spuštění serveru NFS, který se řídí instrukcemi zapsanými v souboru /etc/exports. Server NFS má jen jeden konfigurační soubor, kterým je /etc/exports. Formát každé položky tohoto souboru je následující: /dir/to/export client1 (permissions) client2 (permissions) kde /dir/to/export znamená adresář, který chceme sdílet s ostatními uživateli, client1, client2 atd. jsou jména stanic klientů NFS (pozor na správnou funkci DNS nebo chyby v souboru /etc/hosts) a permissions jsou přístupová práva příslušející dané klientské stanici. V tabulce 6.2.1. jsou platná přístupová práva s jejich popisem. Řídící příznak secure ro noaccess no_root_squash Funkce Číslo portu, po kterém klient požaduje připojení. Musí být menší než 1024 (standardní nastavení). Přístupová práva pouze po čtení. Klientovi bude odepřen přístup do některých podadresářů adresáře /dir/to/export/. Tento parametr umožňuje klientovi připojit například adresář /home/, přičemž přístup do adresáře /home/secret/ zakázat. Standardní bezpečnostní opatření, které způsobí, že server ignoruje požadavky na diskový oddíl superuživatele přes síťový systém NFS. Žádný superuživatel z klientských stanic nebude mít do adresáře přes NFS přístup. 34