Informatika | Hálózatok » Ti Leggett - Központosított hitelesítés és vállalati címtár megvalósítása

Üzemeltetés Központosított hitelesítés és vállalati címtár megvalósítása (1. rész) Ti Leggett sorozatában arról lesz szó, hogy hogyan lehet biztonságos vállalati címtárat létrehozni, amely támogatja az egyszeri bejelentkezést, és amely felhasználók ezreit képes kiszolgálni. V állalati címtárat szeretnénk tehát, de nincs vállalati költségvetésünk. Az egyszeri bejelentkezés elõnyeit szeretnénk élvezni, mely mind az adminisztrátor, mind a felhasználók életét megkönnyíti. Ha ez a cél, és ráadásként elfogadnak egy biztonságos és egységesített hitelesítési és személyazonosság-nyilvántartási rendszert, akkor érdemes kitartóan végigolvasni e sorokat. Elindítom az olvasót a rendszergazda-mennyországba vezetõ úton. Ebben a cikksorozatban megmutatom, hogyan lehet építkezni a már elõállított és helyretett alapelemekbõl, hogyan lehet újabbakat is beépíteni, és miként lehet ezek együttesét munkára bírni. A

hitelesítést intézõ kiszolgálóktól kezdve a levélkézbesítésig és kliensgépek integrálásáig (beleértve a Microsoft Windows vagy OS X operációs rendszert futtató gépekig) mindent végiggondolunk. Sok mindenrõl kell szót ejtenünk, úgyhogy kezdjünk is bele! továbblépnénk, érdemes elolvasni a Linuxvilágból a „Központosított hitelesítés Kerberos 5-tel” cikksorozat elsõ részét
linuxvilag.hu/ node/3002370, valamint az „OpenLDAP mindenütt” címû cikket
linuxvilag.hu/node/3001551, illetve Jászberényi József esettanulmányát 2006 szeptemberében és októberében. (Lásd az on-line forrásokat, valamint a Google-beli „LDAP OpenSUSE” keresõkifejezés is jó magyar bevezetõt ad az LDAP témához – a ford.) Onnan lépünk tovább, ahová ezek az írások eljutottak. Azt érdemes még szem elõtt tartani, hogy a mi Kerberos tartományunk (realm) a CI.PELDACOM, így bázis DN-ünk az o=ci, dc=pelda, dc=com lesz. (DN = Distinguished

Name, megkülönböztetõ név; o = organization, szervezet; dc = domain component, tartománykomponens) A cikkben hivatkozott összes konfigurációs fájl megtalálható a megjelölt on-line források között. Gentoo Linuxon futtatott MIT Kerberos V v1.41-et használunk hitelesítésre és OpenLDAP v2130-at címtárként, azaz személyazonosságkezelésre. Három kiszolgálónk lesz: kdc.peldacom, ldappeldacom és mail.peldacom (A beszédes nevek az alábbiakra utalnak: KDC=Key Distribution Center, Kulcselosztó Központ; LDAP=Lightweight Directory Access Protocol, címtár szolgáltatások elérését szabályozó protokoll) Mielõtt A továbbiak megértéséhez ezt a részt nem kötelezõ elolvasni, de olyan hálózatok építõi számára, akik több szerveren is SSL-t használnak, melegen ajánlott. Bár minden kiszolgáló alá tudná írni a maga számára a tanúsítványt, így elveszne valami az egységességbõl és a saját CA futtatásával járó sokféle

lehetõségbõl. Az OpenSSL részletei iránt érdeklõdõknek jó A korábbi építõkockák felhasználása SSL Tanúsítvány Hatóság (Certificate Authority, CA) létrehozása szívvel tudom ajánlani a Network Security with OpenSSL címû könyvet (John Viega, Matt Meisser, Pravir Chandra – O’Reilly). Legyen a /etc/ssl/pelda.com könyvtár az alapkönyvtár, ahol az összes aláírt tanúsítványt, visszavont tanúsítványlistát (certificate revocation list, CRL) és azonosítói információt tartjuk. Ha e könyvtár elkészült, hozzuk létre benne a certs, crl, newcerts és private alkönyvtárakat, valamint ugyanitt egy üres /etc/ssl/pelda.com/indextxt fájlt. Írjuk egy „01”-t a /etc/ssl/ pelda.com/serial nevû fájlba Ez utóbbiakat megtehetjük pl. az alábbi módon: # # # # touch /etc/ssl/ pelda.com/indextxt echo 01 > /etc/ssl/ pelda.com/serial Végül hozzunk létre a CA számára egy OpenSSL konfigurációs fájlt /etc/ssl/pelda.com/ca-sslcnf néven

Jelentkezzünk be olyan felhasználói néven, aki a /etc/ssl/pelda.com könyvtár rekurzív tulajdonosa (valószínûleg a root felhasználó). Az õ nevében az alábbiakat kell tennünk egy ön-aláírt CA tanúsítvány létrehozásához: # # # # # export OPENSSL CONF= /etc/ssl/pelda.com/ ca-ssl.cnf openssl req -x509 -days 3650 -newkey rsa -out /etc/ssl/pelda.com/
ci-cert.pem -outform PEM 45 Üzemeltetés # # # # cp /etc/ssl/pelda.com/ ci-cert.pem /etc/ssl/certs /usr/bin/c rehash /etc/ssl/certs Az openssl req parancs részleteire vonatkozóan eligazítást ad a req(1) kézikönyv (man) oldal. Fontos, hogy a CA kulcs jelszava (passphrase) igen biztonságos helyen legyen, mert ha a CA titkos kulcsa kitudódik, megbízhatatlanná válnak az általa aláírt tanúsítványok. Az is fontos, hogy a CA számítógép maga, illetve az elérése is biztonságos legyen. Ennek a biztonságnak a szintje az adminisztrátortól és az általa képviselt igényektõl függ, de mihelyt

egy illetéktelen felhasználó fizikailag vagy a hálózaton keresztül hozzá tud férni e géphez, már meg is szerezte a CA titkos kulcsát. Ahogy már fentebb említettem, a CA titkos kulcsának veszélyeztetése lerombolja az egész bizalmi láncot, bizonytalanná és megbízhatatlanná válik az összes aláírt tanúsítvány. Egyesek szerint az a legjobb megoldás, ha a CA gép fizikailag el van különítve mindenféle hálózattól. A tanúsítványok aláírására úgy kerülhet sor egy ilyen környezetben, hogy Tanúsítványregisztrációs Központok (Registration Authorities, RA) fogadják a beérkezõ Tanúsítványaláírási Kérelmeket (Certificate Signing Request, CSR). Itt ezeket a CSR kéréseket egy megbízható adathordozón átviszik a CA gépre, ahol sor kerül az aláírásra és a tanúsítványoknak az adathordozóra történõ visszaírására, amit a Tanúsítványregisztrációs Központtól a végfelhasználó átvehet. Amennyiben erre van

szükségünk, akkor az OpenCA projekt ilyen biztonsági szintet céloz meg; támogatja az aláírt tanúsítványok LDAP-ben való eltárolását is. Elkészítettük immár a CA számára az OpenSSL konfigurációs fájlunkat, de ez csak egyetlen tanúsítvány igénylésére és aláírására alkalmas. Elõ kell állítanunk még egy olyan konfigurációs fájlt is, amelyet mostantól normál gazdagép- és felhasználói tanúsítványok igénylésére is lehet használni. Erre szolgál a /etc/ssl/ pelda.com/sslcnf A kliensgépek konfigurálása a CA-nál egy kissé összetettebb feladat, mivel többféle tanúsítvány-változatot kell kell kezelnie 46 Most, hogy már van egy kliens konfigurációs fájlunk, generáljunk egy gazdagép tanúsítványt is az LDAP kiszolgáló számára. A CSR (Tanúsítvány-aláírási Kérelem) elõállítása normál felhasználóként történhet: # # # # # export OPENSSL CONF= /etc/ssl/pelda.com/ ssl.cnf openssl req -new -nodes -keyout

ldap-key.pem -out ldap-req.pem Az openssl req kapcsolói lényegében ugyanazok, mint amiket a CA CSR legyártásához használtunk. Az egyetlen újdonság a -nodes opció, ami egy kódolatlan titkos kulcsot gyárt (man req). A nyilvános tanúsítvány elkészítéséhez vezetõ következõ lépés a CSR aláíratása a CA-val. Ezt ismét root-ként kell megtenni: # # # # # export OPENSSL CONF= /etc/ssl/pelda.com/ ssl.cnf openssl ca -policy policy anything -out ldap-ckert.pem -in ldap
reqpem Ebben a pillanatban három fájlunk van: az ldap-cert.pem, a nyilvános tanúsítvány ; az ldap-keypem, a titkos kulcs; valamint az ldap-req.pem, a CSR (Tanúsítvány-aláírási Kérelem). Ez utóbbi eldobható, mihelyt a tanúsítványt aláírta a CA. Itt is hangsúlyoznunk kell, mennyire fontos a titkos kulcs védelme, annál is inkább, mert nincs kódolva. Érdemes ezt a root birtokában tartani és 0400 jogosultsággal ellátni. Legyen biztonságos az LDAP Annak ellenére, hogy

nincsenek jelszavak az LDAP címtárban, mégis van itt sok más értékes információ. Vélhetõleg a felhasználók nem örülnének, ha az interneten nyilvánosságra hoznák a telefonszámaikat, e-mail címeiket vagy munkavállalói azonosító számaikat. Ha olvasták az „OpenLDAP mindenütt” címû írást és van egy mûködõ LDAP kiszolgálójuk, akkor szükség van arra is, hogy biztonságosan történhessen az adatok átvitele és a címtár elérése. Az adatátvitel biztosításának elsõ lépése az OpenSSL használata. Elõször is másoljuk át az aláírt tanúsítványunkat illetve kulcsunkat a /etc/openldap/ssl/slapd-cert.pem és a /etc/openldap/ssl/slapd-key.pem helyekre.A slapdconf-ban meg kell adnunk öt adatot: TLSCipherSuite (opcionális), TLSCACertificatePath, TLSCertificateFile, TLSCertificateKeyFile és TLSVerifyClient. A slapdconf(5) kézikönyv oldalak eligazítást adnak ezek mibenlétérõl. (TLS: Transport Layer Security; a protokoll elsõdleges

célja a titkosság és az adatintegritás biztosítása) Most, hogy biztonságosakká tettük a kábeleken áthaladó adatforgalmat, biztosítanunk kell a Kerberos KDC által használt hitelesítést is. Az OpenLDAP „kerberizált”; SASL-t („Simple Authentication and Security Layer”; „Egyszerû hitelesítési és biztonsági réteg”) hitelesítési mechanizmust használ. Elõször is tudatnunk kell a slapd-vel, hogy hol találja a kulcsokat tartalmazó keytab fájlt. Ezt a /etc/conf.d/slapd szerkesztésével tehetjük meg, vagy a slapd indítása elõtt a megfelelõ indító szkriptben létrehozott KRB5 KTNAME változó segítségével. A slapdconf-ban meg kell még adni a sasl-secprops és a sasl-regexp értékét. E pillanatban mind a TLS, mind a SASL mechanizmus használható, de ezek akár nélkülözhetõek is. Még két opció van a slapd.conf-ban (security és allow), melyek arra használhatóak, hogy megadjuk a biztonsági mechanizmust és a titkosítás

erõsségét, melyet néhány mûvelet elvégzése megkövetel. Gyõzõdjünk meg arról is, hogy az hozzáférés-szabályozó listák (ACL; Access Control List) megfelelõen be vannak-e állítva. Javasolt kézikönyv-oldalak: slapd.access(5) A Kerberos biztonságos átvezetése Kezdjük azzal, hogy átvezetjük („replikáljuk”) a Kerberos adatbázisunkat a kdc.peldacom-ról az ldap.peldacom-ra Ha valami miatt a kdc.peldacom elromlana, az ldap.peldacom át tudja majd venni a szerepét. Emlékeztetnék rá, hogy egy idõpontban csak egyetlen kadmin kiszolgáló lehet a hálózati Üzemeltetés tartományunkban. Máskülönben nem lehetne tudni, ki az illetékes az adatbázis-frissítések ügyében. A Kerberos tartalmazza a kprop és kpropd programokat. Ezek megfelelõ módon, biztonságosan el tudják terjeszteni a Kerberos adatbázist. Elõször is meg kell adnunk a kpropd-t, mint ismert szolgáltatást. Írjuk a /etc/services fájlba: krb5 prop 754/tcp Definiálnunk

kell egy ACL fájlt is, a /etc/krb5kdc/kpropd.acl-t, ami felvilágosítja a kpropd-t arra vonatkozóan, hogy mely gépek jogosultak a az adatterjesztésre. Igazából csak egy KDC fõfiókot kell megadnunk a fájlban, de megadható akár az összes KDC gép is. Ekkor hiba esetén választhatunk egy új fõfiókot, elindíthatjuk rajta a kadmin szolgáltatást, és tõle kezdõdhet az adatterjesztés a szolgagépek felé. Ezek után a szolgagépeken megadjuk az xinetd szolgáltatás-definíciót a /etc/xinetd.d/kpropd fájlban; (újra)indítjuk az xinetd-t; kiírjuk az adatbázist a kdc.peldacom gépen; és átvisszük a szolgagépekre az alábbi kezdõkonfigurációval: # # # # /usr/sbin/kdb5 util dump /etc/krb5kdc/slavedump /usr/sbin/kprop -f /etc/krb5kdc/slavedump ldap.peldacom Végül minden szolgagépen létrehozunk egy biztonsági (stash) fájlt, mégpedig annak a mesterkulcsnak a segítségével, amit a kdc.peldacom adatbázisának beállításakor használtunk; aztán

elindítjuk a KDC szolgáltatást: # /usr/sbin/kdb5 util stash # /etc/init.d/mit-krb5kdc start A KDC adatbázis rendszeres elterjesztése érdekében indítsunk egy cron parancsot a kdc.peldacom-on Jason Garmannek (és az O’Reilly által megjelentetett „Kerberos: The Definitive Guide” címû könyvének) köszönhetõen kezünkben van egy mûködõ cron parancs. Kézenfekvõ, hogy ezt a szkriptet óránként indítsuk a /etc/cron.hourly könyvtárból. Ezek után Kerberos adatbázisunk biztonságosan vezetõdik át a fõfiókból a szolgagépek sokaságára. Ha a fõfiók elromlik, lehetõségünk van arra, hogy valamelyik szolgagép könnyen-gyorsan átvegye a feladatát, minimális adatvesztéssel (vagy szerencsés esetben anélkül). Ha már át tudjuk vezetni a Kerberos változásokat egy-egy szolgagépre, akkor nyilvántartásba vehetjük õket a krb5.conf fájlban, mint érvényes KDC-ket. Az OpenLDAP biztonságos átvezetése Minden fontos rendszerben kerülnünk kell

az egy pontból eredõ hibaforrásokat, SPOF-okat (Single Point of Failure; egypontos hiba). Problematikus lenne csak egyetlen helyen tárolni az LDAP címtárunkat; nem kevés kritikus információ veszne el hiba esetén, sõt a felhasználóink még be sem tudnának jelentkezni, lehetetlenné válna az e-mailek megnézése és számos egyéb napi teendõ. Az LDAP címtár átvezetése ezt küszöböli ki. Replikáljuk tehát az LDAP címtárat az ldap.peldacom-ról a kdcpeldacom-ra Az OpenLDAP-nak van is egy háttérprogramja (démonja), ami pontosan ezért felel: a slurpd. Sajnos a slurpdnek nincs olyan beállítási lehetõsége, amivel meg lehetne neki adni, melyik Kerberos keytab fájlt kellene használnia, így szükség lesz egy kis kézimunkára. Szerkesszünk bele a slapdconf fájlba a ldap.peldacom-on, megadva a replogfile és replica opciókat, majd indítsuk újra a slapd-t. Létre kell hoznunk egy Kerberos alapú LDAP fõszolgáltatást, egy SSL tanúsítványt és egy

kulcsot a kdc.peldacom számára, ahogyan azt a ldap.peldacom esetében is tettük, és a slapd.conf fájlt is be kell állítanunk ugyanitt. Ez szinte ugyanolyan, mint amilyet az ldap.peldacom-on készítettünk, néhány kulcsfontosságú különbséggel Ugyanabból az okból, mint ami miatt csak egyetlen Kerberos fõkiszolgálónk van, itt is csak egyetlen LDAP címtárat tartunk naprakészen, és ezen hajtjuk végre a változtatásokat. Az egyetlen felhasználó, akinek lesz jogosultsága írni a szolgagépek címtárába, az alábbi módon írható le: uid=host/ldap.peldacom,cn=GSSA
PI,cn=auth Õ nem más, mint a fõfiók Kerberos gazdája; így a szolgagépek hozzáférés-szabályozó listáit (ACL-jeit) jóval szigorúbbra kell szabni. A slapd-nek arról is kell tudnia, hogy az updatedn és updateref opciók által megadott módon ki fog a slurp révén frissítéseket küldeni. Most újra irányítsuk figyelmünket az ldap.peldacom-ra Létre kell hoznunk a

/etc/conf.d/slurpd fájlt, vagy be kell állítanunk a KRB5CCNAME változót, mielõtt a megfelelõ szkript elindítja a slurpd-t. Ezek után beszerezzük az indításhoz szükséges Kerberos igazolványokat (credentials): # KRB5CCNAME=/var/ # run/slurpd.krb5cache # /usr/bin/kinit -k Majd az egész címtárat kiíratjuk egy fájlba: ldap# /etc/init.d/slapd stop ldap# /usr/sbin/slapcat -l
/tmp/slavedump.ldif ldap# /etc/init.d/slurpd start Minthogy a slurpd csak a fõfiókra hat, nekünk kell benépesítenünk a szolgagépek címtárait a fõfiók tartalma alapján. Ezt úgy tesszük meg, hogy a /tmp/slavedump.ldif fájlba kiírt fõfiók-adatbázist (amit az imént már elkészítettünk) átmásoljuk a kdc.peldacom-ra, ahol a fájl beolvasása után elindíthatjuk a slapd-t: kdc# /usr/sbin/slapadd -l
slavedump.ldif kdc# /etc/init.d/slapd start ldap# /etc/init.d/slapd start Ellenõrizzük, hogy a szolgagép címtára megfelelõ-e: # ldapsearch -H # ldap://kdc.peldacom -ZZ

Próbáljuk ki, hogy jól mûködik-e az átvezetés. Módosítsunk vagy adjuk hozzá új adatot az ldap.peldacom címtárához, majd keressünk rá a kdc.peldacom-on, hogy megbizonyosodjunk arról, hogy a változtatások átvezetõdtek-e Ha meggyõzõdtünk arról, hogy a slurpd mûködik, hozzunk létre egy 47 Üzemeltetés alkalmas cron parancsot az ldap.peldacom-on, hogy meggátoljuk az igazolványok elévülését Az igazolványok érvényességének alapértelmezett ideje tíz óra, így ha pl. nyolc óránként futtatjuk a cron parancsot, az megfelelõ lesz. Végül fel kell vennünk a kdc.peldacom-ot az érvényes LDAP kiszolgálók közé az nss ldap számára. Azaz: be kell illesztenünk a kdc.peldacom-ot abba a kiszolgálófelsorolásba, ami a /etc/ldapconf „host” („gazdagép”) opciójában szerepel. A Postfix levélkezelõ beállítása Postfix levélkezelõt (mail transport agent, MTA) fogunk használni. A 2.15-ös verziójú Postfixben már jól kiépített

támogatás található az SASL hitelesítésre, valamint olyan LDAP finomságok támogatására, mint az álnevek (aliasok). Mivel a Postfix beállításának alapoktól történõ bemutatása túlmutatna e cikk keretein, most csak azzal foglalkozunk, hogy hogyan lehet rávenni a programot az SASL és a TLS használatára. A Postfix részletes beállítására vonatkozóan: információk a cikkhez tartozó források között. A Postfixnek két fõ konfigurációs fájlja van: a /etc/postfix/main.cf és a /etc/ postfix/master.cf A maincf elsõsorban a bejövõ levelek fogadásáért felelõs, míg a master.cf inkább a levélkézbesítõ programok (mail delivery agent, MDA) mûködtetéséért. Egy példa main.cf megtekinthetõ a cikkhez tartozó források között, de a részletek megértéséhez érdemes ismerni a Postfix dokumentációját és weboldalát. Három fõ kulcsszó határozza meg azt, hogy SMTP (Simple Mail Transfer Protocol – kommunikációs protokoll az e-mailek

továbbítására) kiszolgálónk hogyan értekezzen más SMTP kiszolgálókkal: smtp sasl auth enable, smtp use tls és smtp tls note starttls. Ha SMTP kiszolgálónk ki lesz téve az internet viharainak, akkor ezeket a változókat a lehetõ legrugalmasabb módon kell beállítani, hogy biztosan sikerüljön más SMTP kiszolgálókkal a kapcsolatfelvétel. Ha ez csak egy belsõ SMTP kiszolgáló, akkor viszont biztonságosabbra lehet szabni ezeket a beállításokat. 48 Az érdekesebb feladat annak beállítása, hogy miként adjuk meg a felhasználóink és számítógépeink kapcsolódását a levélkezelõnkhöz a levelek elküldésekor. Néhány egyéb opció, amit ezzel kapcsolatban jó ismerni: smtpd sasl auth enable, smtpd sasl security options, smtpd sasl tls security options, smtpd use tls, smtpd tls cert file, smtpd tls key file és smtpd tls auth only. Ha IMAP rendszerû levélkézbesítést használunk, akkor gyõzõdjünk meg arról, hogy be van-e állítva a

master.cfben a mailbox transport változó értéke, valamint az smtp és cyrus átviteli (transport) mechanizmus. Az OpenLDAP-hez hasonlóan a Postfix is kerberizált; SASL-t használ a hitelesítési képesség-egyeztetéskor és SSL segítségével tudja biztosítani az adatátvitelt. A Postfix biztonságossá tételéhez, az SASL használatára való beállításához lesz néhány teendõnk a main.cf módosításán túl is Elõször létrehozunk egy SSL tanúsítvány/ kulcs párt és elhelyezzük e két összetevõt a /etc/ssl/postfix/smtp-cert.pem és a /etc/ssl/postfix/smtp-key.pem fájlba, miközben megbizonyosodunk arról, hogy a postfix felhasználó és a mail csoport tulajdonában vannak, és hogy a kulcs csak a postfix felhasználó számára olvasható. Ezután elkészítünk egy fõfiókot a mail.peldacom számára, és elmentjük a normál helyére. Egy fõszolgáltatást is létrehozunk, „smtp/ mail.peldacom@CIPELDACOM”ként, ezt pedig a /etc/postfix/

smtp.keytab-ba mentjük el Ezt a fájlt a root felhasználó tulajdonában kell tartani, és ugyanolyan jogosultságokkal felruházni, mint az smtp-key.pem fájlt. Ezek után még létre kell hoznunk egy SASL konfigurációs fájlt /etc/sasl2/smtpd.conf néven, és át kell szerkesztenünk a /etc/conf.d/ saslauthd-t. A Postfix a saslauthd háttérprogramot használja arra, hogy információt kapjon a hitelesítési mechanizmusokról. A fenti két fájl adja az SASL tudtára, hogy hogyan ellenõrizze a jelszavakat, milyen mechanizmusok támogatottak, és mi legyen a minimálisan használt biztonsági szint. A minimum layer felvehetõ értéke megegyezik az OpenLDAP-ben megadható biztonságossági faktoréval („Security Strength Factor”, SSF). Végül pedig a /etc/conf.d/postfix fájllal megmondjuk a Postfixnek, merre találja a Kerberos keytab fájlját. (Vagy, mint ahogy eddig már többször láthattuk: a Postfix indítása elõtt a megfelelõ indító szkriptben létrehozott

KRB5 KTNAME változó segítségével is megtehetjük ugyanezt). Ha mindezekkel végeztünk, elindíthatjuk a saslauthd-t és a Postfixet indító szkripteket. Az LDAP nem pusztán a személyazonosság-szervezés és hitelesítés miatt hasznos, hanem amiatt is, mert a Postfix számára átadható álnevek (aliases) szótárát is tudja kezelni. Egyszerû használni és karbantartani, és feleslegessé teszi azt, hogy minden változáskor újrageneráljuk az álnévadatbázist. Címtárunk akkor válik elõször igazán erõs eszközzé, amikor az álnévszótárat is rendelkezésére bocsátjuk. Ezt azzal tehetjük meg, hogy átadjuk a miscschema-t a slapd konfigurációnak, majd létrehozunk a címtárban egy elágazást (branch) az álnevek számára. Használjuk ezt: ou=aliases,o=ci,dc=pelda,dc=com (Itt ou = organizational unit; a többi rövidítést lásd fentebb). Az utolsó feladatrész abból áll, hogy megmondjuk a Postfixnek, hogy az LDAP-ot használja az álnevek

beazonosításához. Ezt az ldap:/etc/postfix/aliases.cf-nek a main.cf-beli alias maps opciójához való beírásával tehetjük meg, valamint ezzel párhuzamosan a /etc/postfix/aliases.cf fájl létrehozásával, ami megadja, hogy hogyan kell az LDAP-hez kapcsolódni, s hogy hol is vannak az álnevek az LDAPben. Újraindítjuk a slapd-t, majd a Postfix-et; íme, készen állunk arra, hogy létrehozzunk egy e-mail álnevet. Hozzunk létre egy LDIF fájlt, nevezetesen az alias.ldif-et, és vegyük fel a címtárba. Tá-dááám! Készen vagyunk! A cyrus IMAP levélkézbesítõ beállítása A cyrus IMAP levélkézbesítõ program 2.210-es verzióját fogjuk használni (A cyrus egy jól skálázható vállalati levelezõrendszer, mely megbirkózik sokféle szabványra épülõ technológiával; használható egyedülálló gépeknél, de akár óriási, centralizált intézeti hálózatban is – a ford.) A cyrus IMAP kiszolgáló részletes beállításának bemutatása

túlmutatna e cikk keretein, de mûködõképes példák fellelhetõk a források között. A cyrus IMAP kiszolgálót ugyanaz a csoport fejlesztette, aki a cyrus SASL-t is, így az SASL és az egyszeri bejelentkezés az elvárásoknak megfelelõen mûködik. A Postfixhez hasonlóan a cyrus IMAPnak is két konfigurációs fájlja van: a /etc/imapd.conf és a /etc/cyrusconf Most csak a /etc/imapd.conf-fal foglalkozunk Itt is adott néhány elõfeltétel: SSL tanúsítvány/kulcs pár, fõfiók és fõszolgáltatás; ez utóbbit hívjuk így: „imap/mail.peldacom@CIUCHICA GO.EDU”, és tároljuk el a /etc/ imap.keytab fájlban Az SSL beélesítéséhez adjuk meg alkalmas módon a tls ca path, tls cert file és tls key file opciókat. Az SASL használatához meg kell adnunk a sasl pwcheck method, sasl mech list és sasl minimum layer opciókat is. Ezek értékei egyezzenek meg azzal, mint amiket a Postfix számára megadtunk a /etc/sasl2/smtpd.conf fájlban Üzemeltetés A Postfixhez

hasonlóan a cyrus IMAP számára is meg kell mondanunk, hogy hol van a keytab fájlja, mégpedig a /etc/conf.d/cyrus fájl révén (Vagy, mint ahogy ez már szinte a könyökünkön jön ki: az IMAP háttérprogram indítása elõtt a megfelelõ indító szkriptben létrehozott KRB5 KTNAME változó segítségével is megtehetjük ugyanezt). Ha mindezzel elkészültünk, gyõzõdjünk meg arról, hogy valóban fut-e a saslauthd program, és ha igen, akkor futtassuk az IMAP indító szkriptjét. Vízre bocsátás Meglehetõsen nagyot kaszáltunk rövid idõ alatt, de megérte a fáradozás: egy biztonságos és jól skálázható vállalati címtár lett az eredménye. Lábra állítottunk egy rendszert, amely akár néhány, egy helyre tömörült felhasználót/számítógépet, akár a világban szétszóródott tízezernyit is képes kiszolgálni. Következõ cikkemben azzal fogunk megbirkózni, hogy munkánk gyümölcseként miként tudunk Linux és Apple OS X kliensgépeket is

hálózatunkba kapcsolni. Köszönetnyilvánítás Munkámban segítséget nyújtottak: Matematikai, Információtechnológiai és Számítástudományi tanszék (Office of Advanced Scientific Computing Research, Office of Science), az Amerikai Energiaügyi Minisztérium a W-31109-ENG-38 számú szerzõdés szerint. További támogatást kaptam a Chicagoi Egyetem Számítástudományi Intézetétõl és a Nemzeti Tudományos Alaptól. Linux Journal 2006., 140 szám Ti Leggett (leggett@mcs.anlgov) a Futures Laboratory of the Mathematics and Computer Science Division rendszergazdája az Argonne National Laboratoryban; emellett a Chicagoi Egyetem Számítástudományi Intézetében is dolgozik. KAPCSOLÓDÓ CÍMEK
www.linuxjournalcom/article/8581 49 Üzemeltetés Központosított hitelesítés és vállalati címtár megvalósítása (2. rész) Ti Leggett folytatja sorozatát a biztonságos testületi címtár építésérõl. M últ hónapban átverekedtük magunkat az

egyszeri bejelentkezés és a testületi címtár infrastruktúra elindításán. Ebben a cikkben eddigi kemény munkánk eredményét használjuk fel a Linux és Mac OS X kliensgépek csatlakoztatásához, ezek megfelelõ konfigurálásával. Bár ez alkalommal nem lesz annyi megvizsgálandó részlet, mint a múltkor, de most is sok mindenrõl szót kell ejtenünk, úgyhogy álljunk is neki! A konfigurációs fájlokat ez alkalommal is megtalálják a cikkhez tartozó források között. Ebben a részben arról lesz szó, hogy hogyan lehet csatlakoztatni a Gentoo Linuxot és a Red Hat Enterprise Linux (RHEL) 3. és 4 kiadását; értelemszerûen a legtöbb más Linux terjesztést is többékevésbé hasonlóan kell konfigurálni. Szót ejtünk a Mac OS X 10.4-es „Tigris” (Tiger) kiadásának kliensgépként történõ integrálásáról is. A következõ rész számol be majd arról, hogy miként lehet rávenni a Microsoft Windows kliensgépeket az általunk elkészített

hitelesítési és engedélyezési rendszer használatára; ez lényegében a Samba csomag konfigurálását és beállítását jelenti. Az egyszeri bejelentkezés lehetõvé tételéhez a Linux és a Tigris kliensgépek számára meg kell adnunk a kulcsokat tartalmazó Kerberos keytab fájlt. Ez ugyanúgy történik, mint ahogy az eddigi keytab fájlok esetén. Mind a Linux, mind a Tigris kliensgépek számára a /etc/krb5.keytab fájlban adhatjuk meg a kulcstáblázatot. Linux kliensek beállítása Nem minden felhasználó szeretné/tudja megoldani, hogy a gépe teljes mértékben beépüljön a Kerberos tartományba (realm), különösen a hordozható gépeknél. Ha nincs teljes körû jogosultságunk az összes gép fölött, melyekrõl a felhasználók csatlakozni akarnak, kénytelenek vagyunk megengedni a hagyományos jelszavas hitelesítést is. Bár a jelszavak hálózaton át történõ küldözgetése a Kerberos több biztonsági célkitûzését meghiúsítja,

mindaddig, amíg rendszergazdaként ennek tudatában vagyunk, és csak megfelelõ korlátok között tesszük lehetõvé a használatát, nem követünk el nagyobb hibát, mintha nem is használnánk a Kerberost. A Kerberosnak még mindig számos elõnye van olyan eljárásokkal szemben, melyek például a /etc/password-re, NIS-re vagy a jelszavak LDAP tárolására épülnek. Jóval egyszerûbben lehet kikényszeríteni bizonyos jelszószabályokat a Kerberos-szal, mint más módszerekkel, és a jelszavak tárolása is biztonságosabb egy Kerberos adatbázisban. Érdemes elolvasni a Linuxvilágból Alf Wachsmann: „Központosított hitelesítés Kerberos 5-tel” címû cikksorozatának elsõ részét, fõleg azt a bekezdést, mely a kerberos PAM hitelesítés lehetõvé tételérõl szól.
linuxvilaghu/ node/3002370 Craig Swanson és Matt Lung az „OpenLDAP mindenütt” címû cikkben érintik a /etc/nsswitch.conf, a /etc/ldap.conf és a /etc/openldap/ ldap.conf beállítását


linuxvilaghu/ node/3001551. Ezeket a fájlokat mi is fogjuk fésülgetni, hogy a sebesség és biztonság tekintetében még kifinomultabb hatást érjünk el. Elõször is nézzük a /etc/openldap/ldap.conf-ot Ez a fájl határozza meg az OpenLDAP 1. Lista /etc/openldap/ldapconf BASE "o=ci,dc=example,dc=com" URI ldaps://ldap.examplecom
ldaps://kdc.examplecom TLS CACERTDIR /etc/ssl/certs TLS REQCERT allow parancssori eszközeinek (mint az ldapdadd és az ldapsearch) alapértelmezett beállításait. A mi /etc/openldap/ ldap.conf fájlunkat az 1 Lista mutatja További információk és opciók az ldap.conf(5) kézikönyv (man) oldalakon találhatóak Mivel nincs mód arra, hogy a /etc/openldap/ldap.conf-ban megadjuk, hogy a StartTLS-t szeretnénk használni, kifejezetten meg kell adnunk egy ldaps://URL-t. Ezek után adjunk ki egy egyszerû ldapsearch parancsot, amely alapértelmezetten SASL hitelesítést használ, és így a /etc/openldap/ldap.conf-ban kell keresnie az

alapértelmezett gazdagépet és hálózati faszerkezet gyökerét (base). Most állítsuk munkába a névkiszolgáló kapcsolót (Name Service Switch, NSS). Természetesen ehhez az nss ldap csomagot telepíteni kell, mégpedig lehetõleg a legújabb verzióját, mert a régebbiek nem kezelik bizonyos szolgáltatásoknak, pl. a hálózati csoportoknak (netgroups) az LDAP alapú tárolását. Elõször is magát az nss ldap csomagot kell beállítanunk a /etc/ldap.conf szerkesztésével Ez nem ugyanaz, mint a /etc/openldap/ ldap.conf – ez utóbbi ugyanis csak az OpenLDAP eszközök számára érvényes, míg az elõbbi kifejezetten az 69 Üzemeltetés 2. Lista /etc/ldapconf host ldap.examplecom
kdc.examplecom base o=ci,dc=example,dc=com ssl start tls tls checkpeer no tls cacertfile /etc/ssl/
certs/ci-cert.pem nss base passwd ou=people,
o=ci,dc=example,dc=com nss base group ou=group,
o=ci,dc=example,dc=com nss base hosts ou=hosts,
o=ci,dc=example,dc=com nss base

services
ou=services,o=ci,
dc=example,dc=com nss base netgroup
ou=netgroups,o=ci,
dc=example,dc=com nss ldap konfigurációs fájlja. A 2 Listában láthatjuk, hogy hogyan kell a /etc/ldap.conf-nak kinéznie Érdemes alaposabban megvizsgálnunk, hogy mit állítanak be ezek a sorok; annál is inkább, mert erre a fájlra vonatkozóan nincs kézikönyv oldal (bár jó magyar nyelvû segítség található itt:
http://panther.infeltehu/ linux/postfix-ldap-kerberos.html – a ford.) Az elsõ sor adja meg az LDAP gazdagépeket, amikhez kapcsolódni lehet, a második pedig a hálózati faszerkezet gyökerét, ahonnan a keresés indul (base). A következõ három sor a TLS kapcsolat létrehozásáról szól. Mint látható, az nss ldap ismeri a StartTLS-t, így használhatjuk ezt a módszert a TLS kapcsolat felhúzására. Az utolsó sorok a kereséskezdõ gyökereket írják le a különbözõ nss által vezérelt attribútumok számára. Ezeket a teljesítmény-optimalizáció

miatt kell beállítanunk. Ha egy felhasználónevet keresünk, amely a faszerkezet egy adott ágában található, akkor nincs értelme a teljes címtárat bejárnunk. Például az nss base passwd adja meg azon információk keresési kezdõpontját, amelyek egy klasszikus rendszerben a /etc/passwd-ben voltak eltárolva. De ha úri kedvünk úgy diktálja, lehet akár több ágban is tárolni felhasználóneveket, csak akkor ezt az opciót nem 70 lehet használni. Egy sereg egyéb opció is megadható ebben a fájlban; ezek megtalálhatóak az nss ldap csomaghoz tartozó ldap.conf példafájlban Gyõzõdjünk meg arról, hogy megvane a CA tanúsítvány a /etc/ssl/certs-ben, és futtassuk le a c rehash-t. Ugyanezt a mûveletsort kell elvégezni mindazokon a gépeken, amelyek SSL kapcsolaton keresztül fordulnak az LDAP kiszolgálóhoz valamilyen információért. Most a /etc/nsswitch.conf fájl szerkesztése következik – itt adható meg az LDAP számára, hogy hol keresse az

információkat. Ne tegyük az elejére az LDAP-t, mert így nem leszünk képesek feloldani az LDAP-kiszolgáló nevét. Ha van olyan felhasználó, akit a helyi gépen a /etc/passwd vagy /etc/shadow fájlhoz adtunk, hogy az LDAP-tõl függetlenül hitelesítse magát, töröljük vagy tegyük megjegyzésbe. Ezután már ki lehet próbálni, mûködik-e minden: # getent passwd leggett leggett:x:1001:100:Ti Leggett:/
home/leggett:/bin/bash # id leggett uid=1001(leggett)
gid=100(users) Ha mindkét parancs mûködik, továbbléphetünk. Néhány program újraindítást igényel a /etc/nsswitchconfban történt változások érzékeléséhez; például az OpenSSH is ilyen. Indítsuk tehát újra az sshd-t, és kíséreljük meg az slogin futtatását. Eddigi tevékenységünk eredményeként már lehetséges a kapcsolódás Gentoo és RHEL kliensgépekrõl, de nézzük még át, miket kell ezeken a gépeken helyileg beállítani. A Kerberos hitelesítéshez szükséges fájlok: •

• • /etc/krb5.conf /etc/krb5.keytab /etc/pam.d/system-auth Az OpenLDAP rendszerû felhasználókezelést az alábbi fájlok teszik lehetõvé: • • • • • /etc/openldap/ldap.conf /etc/ldap.conf /etc/nsswitch.conf /etc/ssl/certs/ci-cert.pem (Gentoo) /usr/share/ssl/certs/ci-cert.pem (RHEL) E sorok írásakor az RHEL 4 használatára vonatkozóan van egy megszorítás. Ha a /etc/ldapconf-ban gépneveket használunk IP-címek helyett, hiba lép fel. Emiatt az a javaslatom, hogy használjuk az LDAP-ot a /etc/nsswitch.conf-beli gépnevek felkutatására, és használjunk DHCP-t a kliensgépek IP-címeinek felderítésére. Ha azt tapasztaljuk, hogy a hálózat lábra állítása laphibát (segfault) okoz a dhclient-ben, változtassuk meg a gépneveket IP-címekre a /etc/ldap.conf-ban A Gentoo és az RHEL 4 alatt pillanatok alatt rávehetõ az sshd az egyszeri bejelentkezés használatára. Mindössze ennyit kell beállítani a /etc/ssh/sshd config fájlban:

GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes Ezen sorok beírása után újraindítható az sshd. Sajnos az RHEL 3-ban található sshd egy régi GSSAPI (GSS: General Security Service, Általános Biztonsági Szolgáltatás) mechanizmust támogat, amely érzékeny a beékelõdéses (manin-the-middle típusú) támadásra. Ezt a gssapi programot késõbb lecserélték a gssapi-with-mic nevûre – ezt használja már az RHEL 4 és a Gentoo is. Úgy gyõzõdhetünk meg arról, hogy az aktuális sshd-nk melyik mechanizmust támogatja, hogy tegyük lehetõvé a GSSAPI hitelesítést az sshd config fájlban, majd próbáljunk meg SSHkapcsolatot létrehozni a -v (verbose, bõbeszédû) kapcsolóval. Ekkor részletes jelentést kapunk arról, hogy milyen kapcsolódási mechanizmusokat támogat az adott sshd. Ha a kliens és a szerver egymástól eltérõ mechanizmust támogat, akkor jelszót fog kérni a program. Ilyenkor ugyanis az igazolványok átküldése kissé

eltérõen és egymás mechanizmusaival összeegyeztethetetlenül történik. Célunk, hogy a felhasználóknak csak naponta egyszer kelljen beírniuk a jelszavukat, és hogy ez a jelszó ne közlekedjen a hálózat kábelein. Miért verekednénk át magunkat megannyi problémán, ha a felhasználóink minden e-mail ellenõrzéskor elküldenék a hálózaton a jelszavukat? Szerencsére egyre több e-mail kliensprogram Üzemeltetés támogatja a GSSAPI mechanizmust. A Mozilla Thunderbird használóknak nincs szerencséjük (e sorok írásakor), azonban van néhány más alternatíva, például a KDE KMail 1.8-as változata vagy az Ximian Evolution 2.2-es verziója is rendelkezik GSSAPI támogatással (Ma már a Thunderbird is – a ford.) Sosem használtam KMailt, így inkább arra szorítkozom, amit ismerek. Az Evolutiont nem nehéz rávenni a GSSAPI használatára Csak ki kell választani a GSSAPI-t, mint hitelesítési módot, mind a „levelek küldése”, mind a „levelek

fogadása” fülön (1. ábra) Ha a „biztonságos kapcsolat használata” („Use Secure Connection”) opciót az „amikor csak lehetséges” („Whenever Possible”) állapotba kapcsoljuk, akkor az Evolution a StartTLS-t használja a biztonságos adatátvitelhez. Mac OS X kliensgépek A Tigrissel kezdõdõen az Apple az operációs rendszer szinte minden összetevõjét kerberizálta. Ha Panther 10.3-at futtató kliensgép hálózatba kapcsolására lenne szükség, keressen fel e-mailben; jó adag tudnivalóra lesz szükség. A Tigris beillesztése azonban viszonylag egyszerû. Kezdjük a /Library/Preferences/ edu.mitKerberos fájl szerkesztésével Ez meglehetõsen hasonlít linuxos megfelelõjéhez, a /etc/krb5.conf-hoz, néhány egészen apró különbségtõl eltekintve, ami a 3. Listában látható. Ha már be van állítva a Kerberos, akkor a következõ lépés az, hogy gépünk számára elõállítjuk a megfelelõ kulcsokat tartalmazó /etc/ krb5.keytab fájlt

Futtathatjuk a kadmin-t az OS X kliensgépen, de a 10.4-es változattal érkezõ program apró hibái miatt érdemes odaírni a -O kapcsolót: #/usr/sbin/kadmin -p <admin #princ> -O Ezzel készen is vagyunk a Kerberos alapú hitelesítéssel Tigris gépeken. E cikk írásakor sajnos van egy olyan hiba, amely a gép hitelesítõ rendszerének leállásához vezet. Ez abban az esetben lép fel, amikor egy hálózati felhasználó akkor próbál sudo-val futtatni egy parancsot, amikor már 1. ábra Evolution 22 – Postafiók beállítások érvényes Kerberos igazolvánnyal rendelkezik. Az Apple-lel együttmûködve keressük ennek a megoldását, így azt javaslom, hogy amennyiben ez a hiba megmarad, vegyék fel velem a kapcsolatot. A Mac OS X nem használ nsswitch-et a névszolgáltatáshoz. Ehelyett egy „Címtár Szolgáltatás”-nak (Directory Services) nevezett rendszert használ e célra. Elmagyarázom, hogy hogyan kell beállítani a címtár szolgáltatásokat egy

grafikus felületû eszközzel, melynek neve: „Belépés a címtárba” („Directory Access”). Jó tudni azonban, hogy ez az eszköz végül is csak ezt a két fájlt módosítja: a /Library/Preferences/DirectoryService /DSLDAPv3PlugInConfig.plist-et és a /Library/Preferences/DirectoryService /SearchNodeConfig.plist-et A grafikus felület az Alkalmazások/ Eszközök alatt található (Applications/ Utilities). Elõször is kapcsoljuk be az LDAPv3 beépülõt, majd válasszuk ki és kattintsunk a „Beállít” gombra 3. Lista /Library/Preferences/ edu.mitKerberos [libdefaults] ticket lifetime = 600 default realm =
CI.EXAMPLECOM default tkt enctypes = des3
hmac-sha1 des-cbc-crc default tgs enctypes = des3
hmac-sha1 des-cbc-crc dnsfallback = no [realms] CI.EXAMPLECOM = { kdc = kdc.examplecom:88 kdc = ldap.examplecom:88 admin server =
kdc.examplecom:749 } [domain realm] .examplecom =
CI.EXAMPLECOM example.com = CIEXAMPLECOM 71 Üzemeltetés eszköz, a dscl, amely

többféle címtárban való keresésre szolgál: az LDAPon kívül lehet vele NetInfoban, NISben is keresni, és az összes olyan helyen, amit a „Belépés a címtárba” („Directory Access”) megjelenít. Elõször arról gyõzõdjünk meg, hogy tudunk-e az LDAP kiszolgálón közvetlenül keresni: 2. ábra Új „LDAP Címtárhoz kapcsolódás” megadása OS X alatt # dscl localhost list /LDAPv3/ldap.examplecom/Users Ha a dscl-t kapcsolók nélkül futtatjuk, kapunk egy használati útmutatót és egy parancssort. Álljon itt még két példa a dscl használatára: # # # # 3. ábra LDAP keresés finomítása OS X alatt (Configure). Ha bent vagyunk, kattintsunk az „Opciók” legördülõ menüre („Show Options”), majd az „Új”-ra („New”), hogy megadhassunk egy új LDAP kiszolgálót. Írjuk be az LDAP szerver nevét, és mindhárom jelölõnégyzetet jelöljük be (2. ábra), majd a „Folytat” („Continue”) gomb következik. Ezek után válasszuk az

RFC 2307 (Unix) sablont, írjuk be az LDAP gyökereket, „Folytat” gomb, végül adjuk meg a konfiguráció nevét („Configuration Name”). Készen is vagyunk! Részletesen megadható, hogy a Címtár Szolgáltatások keresõfunkciója mely könyvtárakban pásztázzon, csak úgy, mint Linux alatt a /etc/ ldap.conf-ban Ha kiválasztunk egy 72 megfelelõ címtár szolgáltatást és rákattintunk a „Szerkeszt” („Edit”) gombra, megjelennek a kifinomultabb opciók. Kattintsunk a „Keresés és megfeleltetés” („Search & Mappings”) fülre. Itt látható egy „Bejegyzéstípusok és tulajdonságok” („Record Types and Attributes”) fejléccel ellátott lista. Bármelyik sor kiválasztásával megadható egy részletesebben megfogalmazott kereséskezdõ gyökér (3 ábra) Két kattintás az OK-ra, majd az „Alkalmaz”-ra („Apply”) – és már életbe is léptek és mentésre kerültek a friss beállítások. Természetesen ilyenkor szeretnénk

ellenõrizni, hogy a címtárban végbevitt változtatások helyesen mûködnek-e. Az OS X-ben van egy parancssori dscl localhost list /Search/Users dscl localhost read /Search/Users/leggett Itt a /Search-et (keresés) használjuk, amely minden bekapcsolt címtáron keres. Vagyis, ha van helyi felhasználó a NetInfo címtárban, valamint LDAP felhasználóink is vannak, a /Search mindkét címtárban fog keresni, és az egyesített listát fogja megjeleníteni. A második példában az olvasási mûveletet (read) használjuk; ez mutatja meg az adott ág (konkrétan a /Search/Users/leggett) végpontjaihoz tartozó részletes információkat. A dscl igen hasznos, ha csak konzol elérésünk van egy OS X-et futtató géphez. Miután ellenõriztük, hogy az LDAP felhasználóink elérhetõek, meg kell gyártanunk a helyi home könyvtárakat a frissen készült LDAP felhasználók számára: # install -d -o leggett # /Users/leggett # ln -sf /Users /home Az OS X 10.4-es verziójának

finomabb házirend-beállítási lehetõségei vannak, mint amit a standard POSIX nyújt az operációs rendszer bizonyos összetevõinek elérését illetõen. Alapértelmezésben az admin csoport tagjainak van adminisztrátori jogosultsága Ez a csoport azonban helyileg van eltárolva az egyes gépek NetInfo címtárában. Állítólag igen nagy meggondolatlanság lenne törölni vagy átnevezni ezt a csoportot. Sajnos még csak felül Üzemeltetés sem bírálható egy másik, hasonló nevû LDAP csoporttal, mert a keresési sorrendben elsõbbsége van a helyi NetInfo címtárnak. A /etc/authorization fájl szerkesztésével azonban megoldható, hogy valamely helyi csoport szerepét egy LDAP csoport vegye át. Ez egy egyszerû Apple plist-formázott fájl (plist: Property List, tulajdonságlistát leíró fájlformátum). Ezzel a rendszer különbözõ összetevõihez adhatunk meg szerepeket. Ha a különbözõ jogosultságok megadásánál megváltoztatjuk a sorokat errõl:

<key>group</key> <string>admin</string> erre: <key>group</key> <string>ldap-admins</string> akkor ezáltal az ldap-admins csoport tagjainak adjuk át az adminisztrátori jogosultságot az adott a gépen. Ez eltér a /etc/sudoers-ben megadott sudo jogosultságtól; a programok telepítésére és rendszerbeállítások módosítására vonatkozik. Ezen a ponton be kell tudnunk lépni legett felhasználóként. A Tigris sshd-je minden GSSAPI mechanizmust támogat, a gssapit és a gssapiwith-mic-et is. A korábbi OS X változatok csak a gssapit támogatták, így csak jelszóval lehetett bejelentkezni OS X kliensre (vagy onnan máshova). Az egyszeri bejelentkezés támogatása az sshd-tõl teljesen független, így ezzel kapcsolatban nem kell konfigurációs fájlokat szerkesztenünk. Ahogy korábban megállapítottam, a 10.4-es verziótól kezdve az OS X szinte minden beépített szolgáltatása és alkalmazása kerberizált – így az

levelezést lehetõvé tevõ Mail.app is az. Ha saját CA-t futtatunk vagy önaláírt tanúsítványokat használunk, akkor elõször importálni kell a CA-nk tanúsítványát a rendszer-kulcsláncba, hogy a Mail.app ne panaszkodjon, amikor önaláírt, SSL-re épülõ szolgáltatáshoz kapcsolódik, mint amilyen az IMAP és az SMTP. Másoljuk a CA tanúsítványt az OS X kliensre, majd futtassuk sudo-val a certtool-t: 4. ábra OS X Kerberos alkalmazás sudo certtool i ci-cert.pem v k=/System/Library/Keychains/
X509Anchors Most már el lehet indítani a Mail.app-t Van egy apró trükk, amivel a felhasználói fiókok legyártásakor már be tudjuk kapcsolni a GSSAPI-t. Töltsük ki a felhasználói nevet, és hagyjuk üresen a jelszót. Ha nincs érvényes igazolványunk, akkor a Kerberos jelszót fog kérni. Mihelyt elkészült a felhasználói fiók, térjünk vissza és kapcsoljuk be az IMAP SSL támogatását. Alapértelmezetten nincs bekapcsolva, és a Mailapp nem teszi

lehetõvé a választást a felhasználói fiók létrehozásakor. Az OS X különbözõ változatai (a 10.3as verziótól kezdve) rendelkeznek egy Kerberos.app nevû grafikus alkalmazással (4 ábra), ami lehetõvé teszi a Kerberos igazolványok egyszerû kezelését. Ez azonban jól el van temetve a /System/Library/CoreServices mélyére. Ezt a hasznos alkalmazást érdemes felvenni a panelra és a betöltéskor elindítandó programok közé. Ez automatikusan megújítja a lejárt tanúsítványokat, és több más hasznos funkciója mellett kijelzi például a hátralevõ érvényességi idõtartamot. Az Apple számos szolgáltatása és alkalmazása teljesen kerberizált, például a Safari, a VPN, az Xgrid és AFP, melyek által az Apple felhasználók és rendszergazdák teljes értékû polgárai lesznek hálózatunknak. Sínre tétel Most már valószínûleg mindenki látja, micsoda lehetõségek rejlenek az LDAP címtárakban és a Kerberos hitelesítésben. Hatékony

és skálázható infrastruktúránk van, valamint ezt teljes mértékben használó kliensgépeink. A következõ cikkben a Microsoft Windows kliensgépek integrálásáról lesz szó. Addig is élvezzük munkánk gyümölcsét! Köszönetnyilvánítás Munkámban segítséget nyújtottak: Matematikai, Információtechnológiai és Számítástudományi tanszék (Office of Advanced Scientific Computing Research, Office of Science), az Amerikai Energiaügyi Minisztérium a W-31-109-ENG-38 számú szerzõdés szerint. További támogatást kaptam a Chicagoi Egyetem Számítástudományi Intézetétõl és a Nemzeti Tudományos Alaptól. Linux Journal 2006., 141 szám Ti Leggett (leggett@mcs.anlgov) a Futures Laboratory of the Mathematics and Computer Science Division rendszergazdája az Argonne National Laboratoryban; emellett a Chicagoi Egyetem Számítástudományi Intézetében is dolgozik. KAPCSOLÓDÓ CÍMEK
www.linuxjournalcom/article/8636 73