A múltkorjában nekikezdtünk Kerberos-t telepíteni az OpenLDAP szerverünk mellé, és odáig jutottunk, hogy az OpenLDAP-pal megetettük a kerberos-sémát. Ma a szerveren megoldjuk az MIT Kerberos V telepítését, és ki is próbáljuk.
(You can read this post in English too.)
Az első dolgunk, hogy megkérdeztetünk mindent magunktól a telepítés során:
(You can read this post in English too.)
Az első dolgunk, hogy megkérdeztetünk mindent magunktól a telepítés során:
sudo dpkg-reconfigure debconfés itt az alacsony prioritást választjuk. Aztán telepítünk.
sudo apt-get install krb5-kdc krb5-admin-server krb5-kdc-ldapA válaszok (feltéve, hogy a szerverünk neve ubuserver.itthon.cucc):
Kerberos servers for your realm: ubuserver.itthon.cucc
Administrative server for your Kerberos realm: ubuserver.itthon.cucc
Create the Kerberos KDC configuration automatically? Yes
Run the Kerberos V5 administration daemon (kadmind)? Yes
Miután mindent megválaszoltunk, elkezdődik a programok indulása, és egyszer csak olyat látunk, hogy:
krb5kdc: cannot initialize realm ITTHON.CUCC - see log file for details
Az következik, hogy a kerberos-nak elmondjuk, hogy milyen jelszót kell használnia, ha az LDAP-ban akar túrni. De hova kell ezt tenni? Az /etc/krb5.conf fájlban volt egy ilyen kitétel:
Néhány próbálkozás következik, főként ellenőrzés végett. Először létrehozunk egy principal-t:
Saját felhasználónkkal adjuk ki, hogy:
Administrative server for your Kerberos realm: ubuserver.itthon.cucc
Create the Kerberos KDC configuration automatically? Yes
Run the Kerberos V5 administration daemon (kadmind)? Yes
Miután mindent megválaszoltunk, elkezdődik a programok indulása, és egyszer csak olyat látunk, hogy:
krb5kdc: cannot initialize realm ITTHON.CUCC - see log file for details
Na persze.
Szerkesszük az /etc/krb5.conf állományt:
[libdefaults] default_realm = ITTHON.CUCC [realms] ITTHON.CUCC = { kdc = ubuserver.itthon.cucc admin_server = ubuserver.itthon.cucc default_domain = itthon.cucc database_module = openldap_itthon.cucc } [domain_realm] .itthon.cucc = ITTHON.CUCC itthon.cucc = ITTHON.CUCC [dbdefaults] ldap_kerberos_container_dn = cn=krbcontainer,dc=itthon,dc=cucc [dbmodules] openldap_itthon.cucc = { db_library = kldap ldap_kdc_dn = "cn=admin,dc=itthon,dc=cucc" ldap_kadmind_dn = "cn=admin,dc=itthon,dc=cucc" ldap_service_password_file = /etc/krb5kdc/service.keyfile ldap_servers = ldap://ubuserver.itthon.cucc ldap_conns_per_server = 5 } [logging] kdc = SYSLOG:info:local1 admin-server = SYSLOG:info:local2 default = SYSLOG:err:auth
Ha megvagyunk, akkor kialakítjuk az LDAP-ban az épülő kerberos realmunk helyét:
sudo kdb5_ldap_util -D cn=admin,dc=itthon,dc=cucc create -subtrees dc=itthon,dc=cucc -r ITTHON.CUCC -s
Menet közben megkérdez egy ilyet:
Enter KDC database master key:
Enter KDC database master key:
és ekkor megadhatjuk a database Master Password-öt. Milyen szép, hogy két neve is van:) Mindenetsetre jól tegyük el, mert elvileg sohasem fog kelleni, és ha mégis, akkor tutira nem fogunk emlékezni rá...
Ellenőrizzük, hogy mit csináltunk eddig:
sudo ldapsearch -Y EXTERNAL -b cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc dn -Q -LLL
Az következik, hogy a kerberos-nak elmondjuk, hogy milyen jelszót kell használnia, ha az LDAP-ban akar túrni. De hova kell ezt tenni? Az /etc/krb5.conf fájlban volt egy ilyen kitétel:
ldap_service_password_file = /etc/krb5kdc/service.keyfile
Akkor ezekszerint ide kell jönnie.
sudo kdb5_ldap_util -D cn=admin,dc=itthon,dc=cucc stashsrvpw -f /etc/krb5kdc/service.keyfile cn=admin,dc=itthon,dc=cuccHáromszor is kérdez:
Password for "cn=admin,dc=itthon,dc=cucc": Password for "cn=admin,dc=itthon,dc=cucc": Re-enter password for "cn=admin,dc=itthon,dc=cucc":
Az első kérdés a -D után megadott entitás jelszavát kérdi, a másik kettővel meg azt adjuk meg, hogy mit tároljon a fájlban. Ez a három történetesen ugyanaz nálam.
Lehetne még változtatgatni az /etc/krb5kdc/kdc.conf fájlban, de hagyjuk, ahogy van. Esetleg nézzük meg, hogy mi van benne. Aztán végre indítsuk el a KDC-t, meg az admin szervert:
sudo service krb5-kdc restart sudo service krb5-admin-server restart
A syslog-ban ilyet találunk:
<= bdb_equality_candidates: (krbPrincipalName) not indexed
Aki a múltkor megcsinálta az LDAP-indexelést, annak ismerős lesz a dolog, és sejti, hogy mi a teendő.
Első ízben csatlakozunk a Kerberos-hoz, egy olyan segédprogrammal, amely csak a keberos-szerverünkön futhat, ott is csak root-ként. Ezzel további jelszó nélkül adminisztrálhatjuk a Kerberos-szervert (vastaggal, amit mi írunk be):
sudo kadmin.local Authenticating as principal root/admin@ITTHON.CUCC with password. kadmin.local: listprincs K/M@ITTHON.CUCC krbtgt/ITTHON.CUCC@ITTHON.CUCC kadmin/admin@ITTHON.CUCC kadmin/changepw@ITTHON.CUCC kadmin/history@ITTHON.CUCC kadmin/ubuserver.itthon.cucc@ITTHON.CUCC kadmin.local: quit
Ha megnézzük, azt látjuk, hogy olyan principal (kerberos-felhasználó) nevében csatlakozunk (root/admin), ami nincs is - a listából látszik. Ezért van az, hogy csak sudo-val, és csak helyileg használható a parancs.
Néhány próbálkozás következik, főként ellenőrzés végett. Először létrehozunk egy principal-t:
kadmin.local: addprinc kiskutya WARNING: no policy specified for kiskutya@ITTHON.CUCC; defaulting to no policy Enter password for principal "kiskutya@ITTHON.CUCC": Re-enter password for principal "kiskutya@ITTHON.CUCC": Principal "kiskutya@ITTHON.CUCC" created. kadmin.local: quitA WARNING miatt ne aggódjunk, az jól van úgy. A házirendekről (policy) meg itt olvashatunk.
Saját felhasználónkkal adjuk ki, hogy:
kinit
kinit: Client not found in Kerberos database while getting initial credentials
Ez kábé annyit tesz, hogy "be szeretnék jelenkezni a kerberos-rendszerbe (is)" - "nincs ilyen felhasználó" (Persze, ha a felhasználónevünk történetesen kiskutya volt, akkor nem kapunk ilyen hibaüzenetet.
Most adjuk ki azt, hogy:
Most adjuk ki azt, hogy:
kinit kiskutya Password for kiskutya@ITTHON.CUCC: klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: kiskutya@ITTHON.CUCC Valid starting Expires Service principal 2012-04-25 13.58.14 2012-04-25 23.58.14 krbtgt/ITTHON.CUCC@ITTHON.CUCC renew until 2012-04-26 13.58.12
Azaz most nem a saját, hanem a kiskutya nevű kerberos-principal nevében akarunk cselekedni. Ilyen principal van, ezért jelszót kérdez. A klist megmutatja, hogy épp ki nevében vagyunk bejelentkezve, és meddig érvényes a kapott TGT.
Adjuk ki a következő két parancsot:
Na akkor töröljük le kistkutya-t, elég volt belőle:)
Ha most újraindítjuk a gépet, akkor baj lesz, mert közvetlenül az LDAP-szerver indulása előtt arról panaszkodik a kerberos, hogy nem tud az LDAP-szerverhez kapcsolódni - ami ugye érthető:) Cseréljük meg az indulási sorrendet. Debian-alapú rendszereken a 2-es az alapértelmezett futási szint (runlevel), nézzünk hát be az /etc/rc2.d könyvárba. Ilyet látunk:
Szóval megy az MIT Kerberos V, és a cuccait szépen belepakolja az LDAP-ba. Legközelebb megoldjuk, hogy be is lehessen lépni kerberos-jelszóval a szerverünkre.
Adjuk ki a következő két parancsot:
kdestroy klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1000)Az első parancs a kerberos-identitásunk eldobása, a másik kimenetéből látható, hogy ezek után tényleg senkik lettünk a kerberos számára.
Na akkor töröljük le kistkutya-t, elég volt belőle:)
sudo kadmin.local kadmin.local: delprinc kiskutya Are you sure you want to delete the principal "kiskutya@ITTHON.CUCC"? (yes/no): yes Principal "kiskutya@ITTHON.CUCC" deleted. Make sure that you have removed this principal from all ACLs before reusing.
Ha most újraindítjuk a gépet, akkor baj lesz, mert közvetlenül az LDAP-szerver indulása előtt arról panaszkodik a kerberos, hogy nem tud az LDAP-szerverhez kapcsolódni - ami ugye érthető:) Cseréljük meg az indulási sorrendet. Debian-alapú rendszereken a 2-es az alapértelmezett futási szint (runlevel), nézzünk hát be az /etc/rc2.d könyvárba. Ilyet látunk:
S18krb5-admin-server S18krb5-kdc S19slapd S20libnss-ldapÚgyhogy változtassunk rajta:
sudo mv /etc/rc2.d/S18krb5-admin-server /etc/rc2.d/S21krb5-admin-server sudo mv /etc/rc2.d/S18krb5-kdc /etc/rc2.d/S21krb5-kdc
Szóval megy az MIT Kerberos V, és a cuccait szépen belepakolja az LDAP-ba. Legközelebb megoldjuk, hogy be is lehessen lépni kerberos-jelszóval a szerverünkre.
Nincsenek megjegyzések:
Megjegyzés küldése