LDAP és Kerberos
Mezei Tamás
[email protected] Simonyi Károly Szakkollégium
Célok ●
sok számítógép
●
még több felhasználó
●
jónéhány szolgáltatás
●
biztonságos autentikáció
●
központosított felhasználókezelés
●
címtár
●
…
Mire építjük fel a várat?
LDAP ●
címtárhozzáférési protokoll ●
● ●
lightweight directory access protocol
változtatható backend hierarchikus adatbázis: szinte bármilyen információ tárolható benne, de címtárnak tervezték ●
kis adatmennyiségek
●
főként olvasás
Milyen céljaink is voltak? ●
biztonság ●
szerver-kliens architektúra
●
ACL-ek
●
titkosítás
●
redundánssá tehető
●
egyszerű kezelhetőség
●
skálázhatóság
●
elterjedtség
LDAP biztonság ●
autentikáció
●
titkosítás
●
hozzáférés-korlátozás ●
●
ACL akár attribútumokra, akár Kerberossal (GSSAPI) is
SASL
Skálázhatóság ●
●
cserélhető backend ●
alapesetben: Berkeley DB, GDBM
●
lehet még: SQL, shell, Perl…
hierarchikus kapcsolatok ●
●
LDAP backend
server-side sorting ●
gyorsabb, mint a kliensoldali
Menedzselhetőség ●
replikáció ●
OpenLDAP: master-slave
●
FDS/RDS, Sun LDAP: multimaster
●
online/offline backup
●
egyszerű konfiguráció ●
plaintext fájlok (OpenLDAP) - offline
●
adatbázison belül (FDS/RDS) - online
Támogatás ●
nsswitch ●
●
nss_ldap szinte minden platformra (Solaris, AIX, Linux, *BSD, HP-UX stb.)
jónéhány program támogatja a címtárakat ●
Sun Calendar Server
●
Sympa
●
Postfix, Exim, Sendmail
●
PowerDNS
●
…
Miért ne használjunk LDAP-t? ●
adminisztrációs nehézségek ●
sémakezelés
●
SSL cert kezelés
●
Kerberos illesztés
●
bonyolult parancssori konfiguráció
Az autentikációs probléma ● ● ● ●
felhasználók és szolgáltatások ki vagy? mit akarsz? miért kérdezgetsz még mindig?
POAS ●
„plain old authenticaion system”
●
passwd/shadow/master.passwd fájlok
●
sok rendszer, sok felhasználó, sok szolgáltatás
●
NIS, NIS+, yp
●
kényelmetlen és nem is biztonságos!
Kerberos ●
az LDAP címtárrendszernek készült ●
●
igazából nem autentikációs megoldás, de arra is használható
a Kerberos pedig jelszókezelő rendszer ●
volt Krb4, most Krb5 (biztonságosabb)
●
jelszóosztályok
●
hozzáférési módok
●
titkosítás
●
NFS, AFS, AD
A céljainkról mégegyszer… ●
●
biztonság ●
pontosan ezért készült!
●
ACL-ek
egyszerű kezelhetőség ●
megszokható nehézségű adminisztráció
●
skálázhatóság
●
elterjedtség
Elterjedtség, támogatás ●
login ● ●
●
PAM modulként a legegyszerűbb pam_krb5, de ennek használatához jónéhány programot újra kell forgatni
jónéhány alkalmazás natív Kerberos támogatással ●
NFS, LDAP
Pro és kontra ● ●
megnövekedett biztonság több felhasználó és rendszer egyszerűbb kezelhetősége
●
körülményesebb kezdeti rendszerbeállítás
●
nem túl sok grafikus menedzsment eszköz ●
commandline wizardok előnyben
Kerberos alapok
A Kerberos… ●
háromfejű kutya
●
felhasználónév – jelszó párosokat tárol ●
●
●
adatbázis: kb. mint az /etc/shadow
a jelszavak az esetek nagy részében nem utaznak a hálózaton a szerver a kulcsokat a felhasználó jelszavával titkosítja, mások ezt jelszó nélkül nem tudják visszafejteni
A Kerberos működése ●
●
amikor a felhasználó autentikál, akkor „ticket”-et (jegy) kap ●
korlátozott érvényességi idő
●
hasznos NFS, IMAP stb. esetében
a Kerberos autentikációs, és nem autorizációs rendszer! ● ●
megmondja, hogy a felhasználó valóban X-e azt nem mondja meg, hogy az X felhasználó jogosult-e valamire a rendszerben
Alapfogalmak ●
●
●
principal ●
felhasználónév
●
instance (role): principaltípus, szerepkört mutat meg
realm ●
adott Kerberos domain neve
●
általában nagybetűs
KDC, TGS, AS, TGT, ST, RS
például: ●
ropi/
[email protected]
Tranzakció ●
●
5+1 üzenet ●
KRB_AS_REQ / REP
●
KRB_TGS_REQ / REP
●
KRB_AP_REQ / (REP)
Lehetséges problémák?
LDAP alapok
Sémák ●
●
objektumok attribútumainak leírására szolgál ●
kötelező és opcionális attribútumok
●
pl. posixAccount, posixGroup
egy objektum többféle osztállyal (sémával) rendelkezhet ●
pl. uid=ropi,ou=2003,dc=sch,dc=bme,dc=hu lehet posixAccount, inetOrgPerson is
Séma példa attributetype ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'RFC1274: user identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY DESC 'Abstraction of an account with POSIX attributes' MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )
DN ● ●
●
distinguished name – egyedülálló név bottom-up, left-right címzés, mint egy webes URL ●
uid=ropi,ou=2003,dc=sch,dc=bme,dc=hu
●
cn=Mezei Tamás,ou=2003,dc=sch,dc=bme,dc=hu
hierarchikus fa-rendszer ●
X.500 címzés (o,c)
●
elterjedtebb: domain component (dc)
LDIF ●
lightweight data interchange format
●
dn és a hozzá tartozó attribútumok
dn: uid=ropi,ou=2003,dc=sch,dc=bme,dc=hu objectClass: person objectClass: inetOrgPerson objectClass: posixAccount gecos: Mezei Tamás uid: 1000 gid: 1001
Egy kicsi demó... ●
●
ha van érdeklődő, tartsunk nagyobb tervezési demót másfél-két órában! most csak alapdolgokra van idő és erő(m) ;-(
Köszönöm a figyelmet! Kérdések?
