2012. július 6., péntek

Kerberos LDAP backend-del Ubuntu 12.04-en - ötödik rész

Az előző négy alkalommal telepítettünk OpenLDAP-sémát a Kerberos számára, beköltöztünk a Kerberos-ba, és létrehoztuk az első principalokat, összekapcsoltuk a PAM-ot és az MIT-Kerberost, először a szerveren, majd egy kliensen. Ma munkába vetjük az smbkrb5pwd overlay-t.
(You can read this post in English too.)
Mire is kell nekünk ez az overlay? Két dologra:
  • nem szeretnénk az LDAP-felhasználó létrehozása után külön kerberos-principalt is készíteni
  • azt viszont szeretnénk, ha a Kerberos-jelszó szinkronban lenne az LDAP-jelszóval
Az overlay-t már használtuk, méghozzá arra, hogy az LDAP-ban tárolt userPassword attribútum tartalmát (a felhasználó jelszavát) szinkronizáltuk vele a Samba jelszót tároló sambaNTPassword attribútum tartalmával.

A mai alkalommal hasonlót művelünk, de ma az userPassword attribútum tartalmát a krbPrincipalKey attribútum tartalmával szinkronizáljuk. A mai művünk csak kiegészíti az ottanit, de ha ha te nem használsz Samba-t, akkor is tudod használni ezt az overlay-t.

Valahol (nem találom, hogy hol), azt olvastam, hogy a kerberos cuccai az LDAP-ban nem kerülhetnek közvetlenül az LDAP-gyökér alá, ha ezt az overlay-t használni akarjuk. Ezért is készítettem el úgy a kerberos tárolóját, hogy a cucc a cn=krbcontainer,dc=itthon,dc=cucc alá kerüljön.

Magát az smbkrb5pwd overlay-t a múlkor már letöltöttük, fordítottuk és telepítettük. A konfigurációt akarjuk most úgy megváltoztatni, hogy a samba mellett a Kerberos-t is kezelje az overlay. Az overlay úgy működik, hogy az LDAP-jelszó beállításakor
  • ha már van az LDAP-felhasználónak megfelelő principal, akkor csak a principal jelszavát frissíti
  • ha meg nincs, akkor létre is hozza.
Ha nincs még beizzítva nálad az overlay, akkor először annyi a feladatod, hogy fordítasz, majd elvégzed a betöltést (smbkrb5pwd_betolt.ldif). A smbkrb5pwd_beallit.ldif egy kicsit más lesz, ugyanis nem kell bele az olcSmbKrb5PwdMustChange (a dokumentáció szerint csak a samba figyeli), és a olcSmbKrb5PwdEnable sorba a samba helyett krb5 kerül. Lesz még benne egy olcSmbKrb5PwdKrb5Realm: ITTHON.CUCC sor is.

Ha már kezeli a samba-t az overlay (mint nálam), akkor először is megnézed, hogy hányas számot kapja a konfigurációban:
sudo ldapsearch -Y EXTERNAL -b cn=config
És most, hogy okos lettél, megírod az smbkrb5pwd_kerberos_bekapcs.ldiff fájlt (látod, nálam az overlay száma a 0):
dn: olcOverlay={0}smbkrb5pwd,olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcSmbKrb5PwdEnable
olcSmbKrb5PwdEnable: samba
olcSmbKrb5PwdEnable: krb5
-
add: olcSmbKrb5PwdKrb5Realm
olcSmbKrb5PwdKrb5Realm: ITTHON.CUCC
Majd futtatod ezt a parancsot:
sudo ldapmodify -Y EXTERNAL -f smbkrb5pwd_kerberos_bekapcs.ldiff

Bármelyik utat követted is eddig, a lényeg, hogy a végén a fenti ldapsearch ilyesmit adjon (még egyszer: a samba sor csak akkor kell, ha van is samba nálad) :
# {0}smbkrb5pwd, {1}hdb, config
dn: olcOverlay={0}smbkrb5pwd,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbKrb5PwdConfig
olcOverlay: {0}smbkrb5pwd
olcSmbKrb5PwdMustChange: 2592000
olcSmbKrb5PwdRequiredClass: posixAccount
olcSmbKrb5PwdEnable: samba
olcSmbKrb5PwdEnable: krb5
olcSmbKrb5PwdKrb5Realm: ITTHON.CUCC

Ha most kiadjuk a következő parancsot, akkor nem tudunk kapcsolódni, mert a kerberos még nem tudja, hogy az smbkrb5pwd-nek szabad jelszót változtatnia.
ldappasswd -D cn=admin,dc=itthon,dc=cucc -w titok -s ujjelszo uid=bela,ou=People,dc=itthon,dc=cucc
Result: Connect error (-11)
A syslog-ban ilyesmi látszik:
smbkrb5pwd conn=1021 op=1 : kadm5_init_with_skey() failed for user bela: Invalid argument

Na, akkor tegyünk róla. Az első dolgunk, hogy a szerveren kiadott
hostname -f
parancs a szerver teljes nevét (FQDN - Fully Qualified Domain Name) adja vissza, ami nálam ubuserver.itthon.cucc. (Az utolsó pont nélkül, persze.)
Ha ez megvan, akkor létrehozunk egy principalt az smbkrb5pwd számára, majd a kulcsokat kiexportáljuk abba a fájlba, ahol keresni fogja. Figyeljünk a principal nevére, a szerver FQDN-jét kell beleírnunk. Ami vastaggal, sárga háttérrel van szedve, azt írtuk mi. Látni fogjuk, hogy összesen négy kulcs exportálódik.
sudo kadmin.local 
Password: 
Authenticating as principal root/admin@ITTHON.CUCC with password.
kadmin.local:  addprinc -randkey smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC
WARNING: no policy specified for smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC; defaulting to no policy
Principal "smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC" created.
kadmin.local:  ktadd -k /etc/ldap/slapd.d/openldap-krb5.keytab smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC
Entry for principal smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/ldap/slapd.d/openldap-krb5.keytab.
Entry for principal smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/ldap/slapd.d/openldap-krb5.keytab.
Entry for principal smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/ldap/slapd.d/openldap-krb5.keytab.
Entry for principal smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/etc/ldap/slapd.d/openldap-krb5.keytab. 
kadmin.local:  quit
Meg kell még oldani, hogy az openldap felhasználó olvashassa ezt a keytab-fájlt, más meg ne:
sudo chown openldap:openldap /etc/ldap/slapd.d/openldap-krb5.keytab
Jogot kell adni a frissen létrehozott principalnak arra, hogy új principalokat hozhasson létre (a), és hogy a régieknek megváltoztathassa a jelszavát. Az /etc/krb5kdc/kadm5.acl fájlt kell szerkesztenünk, ami nálam ilyen:
*/admin *
smbkrb5pwd/ubuserver.itthon.cucc ac
Persze a privilégium-állítás miatt ez is kell:
sudo service krb5-admin-server restart
Írtam már, hogy a kadmind nagyon lassan tér magához. Ha van felhasználó, akiről tudjuk, hogy működnie kell vele, tesztelgessük.
kadmin -p kerbadmin/admin
Ha már megy, akkor:
sudo kadmin -p smbkrb5pwd/ubuserver.itthon.cucc -k -t /etc/ldap/slapd.d/openldap-krb5.keytab
Mennie kell. Ha nem, az baj.

És akkor most jön az, amivel vagy négy órát szenvedtem, mire észrevettem. A dolog elején ők vannak az LDAP-ban:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b ou=People,dc=itthon,dc=cucc dn
dn: ou=People,dc=itthon,dc=cucc

dn: uid=bela,ou=People,dc=itthon,dc=cucc

dn: uid=root,ou=People,dc=itthon,dc=cucc

dn: uid=nobody,ou=People,dc=itthon,dc=cucc

dn: uid=suser1,ou=People,dc=itthon,dc=cucc
És nekik van kerberos-principaljuk:
kadmin -p kerbadmin/admin
Authenticating as principal kerbadmin/admin with password.
Password for kerbadmin/admin@ITTHON.CUCC: 
kadmin:  listprincs
bela@ITTHON.CUCC
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
kerbadmin/admin@ITTHON.CUCC
smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC
Kiemelném, hogy bela az egyetlen, akinek van már, a valós felhasználók közül. Neki azért van, mert ennek a Kerberos-os sorozatnak a harmadik részében adtam neki. Béla Kerberos-attribútumai az LDAP-on belül a bela alá kerültek, ellenőrizheted magadnál:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b uid=bela,ou=People,dc=itthon,dc=cucc
És láthatod azt is, hogy a krbcontainer, amit azért készítettünk, hogy majd ide kerüljenek a principal-ok, nem tud Béláról:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc dn
dn: cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc

dn: krbPrincipalName=K/M@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,
 dc=cucc

dn: krbPrincipalName=krbtgt/ITTHON.CUCC@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbconta
 iner,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/admin@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,d
 c=itthon,dc=cucc

dn: krbPrincipalName=kadmin/changepw@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontaine
 r,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/history@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer
 ,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/ubuserver.itthon.cucc@ITTHON.CUCC,cn=ITTHON.CUCC,c
 n=krbcontainer,dc=itthon,dc=cucc

dn: krbPrincipalName=kerbadmin/admin@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontaine
 r,dc=itthon,dc=cucc

dn: krbPrincipalName=smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC,cn=ITTHON.CU
 CC,cn=krbcontainer,dc=itthon,dc=cucc
Na ez az oka annak, hogy hiába futtatod a
ldappasswd -D cn=admin,dc=itthon,dc=cucc -w titok -s ujjelszo uid=bela,ou=People,dc=itthon,dc=cucc
parancsot, Béla esetében ez nem fog működni.

Ha azonban suser1 (azaz egy másik, LDAP-ban létező, de Kerberos principallal még nem bíró felhasználó) jelszavával kísérletezel, az fog menni. Ha kiadjuk, hogy
ldappasswd -D cn=admin,dc=itthon,dc=cucc -w titok -s ujjelszo uid=suser1,ou=People,dc=itthon,dc=cucc
akkor az csuklás nélkül lefut. Ha a syslog-ban megnézzük, látjuk, ahogy az smbkrb5pwd szépen létrehozza a principalt, és beállítja a jelszavakat. Ellenőrizzük csak:
kadmin -p kerbadmin/admin
Authenticating as principal kerbadmin/admin with password.
Password for kerbadmin/admin@ITTHON.CUCC: 
kadmin:  listprincs
bela@ITTHON.CUCC
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
kerbadmin/admin@ITTHON.CUCC
smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC
suser1@ITTHON.CUCC
Íme, suser1-nek van principalja. És ráadásul a jó helyen:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc dn
dn: cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc

dn: krbPrincipalName=K/M@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,
 dc=cucc

dn: krbPrincipalName=krbtgt/ITTHON.CUCC@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbconta
 iner,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/admin@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,d
 c=itthon,dc=cucc

dn: krbPrincipalName=kadmin/changepw@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontaine
 r,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/history@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer
 ,dc=itthon,dc=cucc

dn: krbPrincipalName=kadmin/ubuserver.itthon.cucc@ITTHON.CUCC,cn=ITTHON.CUCC,c
 n=krbcontainer,dc=itthon,dc=cucc

dn: krbPrincipalName=kerbadmin/admin@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontaine
 r,dc=itthon,dc=cucc

dn: krbPrincipalName=smbkrb5pwd/ubuserver.itthon.cucc@ITTHON.CUCC,cn=ITTHON.CU
 CC,cn=krbcontainer,dc=itthon,dc=cucc

dn: krbPrincipalName=suser1@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,dc=itth
 on,dc=cucc
És a kerberos-attribútumok nem suser1 bejegyzés alatt vannak:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b uid=suser1,ou=People,dc=itthon,dc=cucc
Hanem itt:
ldapsearch -x -D cn=admin,dc=itthon,dc=cucc -w titok -LLL -b krbPrincipalName=suser1@ITTHON.CUCC,cn=ITTHON.CUCC,cn=krbcontainer,dc=itthon,dc=cucc

És így megy a dolog. Az egyetlen feladatunk, hogy senkinek se hozzunk létre kézzel kerberos-principalt. És ezt szívesen megígérem.

Na, akkor gondolkodjunk. Amit megalkottunk:

  • Ha az LDAP-ban valakinek a jelszavát közvetlenül az userPassword jellemző átírásával változtatjuk meg, akkor azt az smbkrb5pwd nem veszi észre, és nem fog propagálódni sem a Samba, sem a Kerberos felé.
  • Ha az LDAP-ban valakinek a jelszavát az exop használatával változtatjuk meg, akkor azt az smbkrb5pwd észreveszi, és propagálja mind a Samba, mind a Kerberos felé (sőt, a Keberos principalt létre is hozza).
  • Ha a jelszavunkat Windows-ban változtatjuk meg, akkor a Samba az ldap passwd sync = only beállítás miatt a jelszót exop-pal, csak a Unix-jelszót változtatva tárolja.
  • Viszont az exop miatt az smbkrb5pwd megváltoztatja a Samba és a Kerberos-jelszót is.
  • Ha azonban a Kerberos-jelszó változik, azt az életben észre nem vesszük, következésképp nem fog propagálódni sehova.
  • Azaz jelen állás szerint a Linux kliensen végzett jelszóváltoztatást (ez most a Kerberos-jelszó) nem fogja senki észrevenni.
Mi a megoldás?
Szerencsére nagyon egyszerű. A Linux-rendszereken a PAM segítségével megoldható, hogy más rendszeren történjen az azonosítás és a jelszóváltás. Az azonosításért az /etc/pam.d/common-auth fájl felel, amely jelen állás szerint így néz ki (kommenteket kihagytam):
auth    [success=3 default=ignore]    pam_krb5.so minimum_uid=1000
auth    [success=2 default=ignore]    pam_unix.so nullok_secure try_first_pass
auth    [success=1 default=ignore]    pam_ldap.so use_first_pass
auth    requisite            pam_deny.so
auth    required            pam_permit.so
Azaz elsőnek a Kerberos próbál hitelesíteni, ha neki nem megy, akkor a helyi cucc, ha ott sem megy, akkor az LDAP. Minthogy a Kerberos- és az LDAP-jelszó újabban megegyezik, az LDAP-felhasználónak illene már az első próbálkozásra bejutnia.
Jelszóváltáskor azonban az /etc/pam.d/common-password fájl a főnök. Ez a fájl most és kommentek nélkül ilyen:
password    [success=3 default=ignore]    pam_krb5.so minimum_uid=1000
password    [success=2 default=ignore]    pam_unix.so obscure use_authtok try_first_pass sha512
password    [success=1 user_unknown=ignore default=die]    pam_ldap.so try_first_pass
password    requisite            pam_deny.so
password    required            pam_permit.so
(Az LDAP-os sorból egy use_authok bejegyzést már régen kivettünk.)
Ha a fájlban a kerberos-os sort megjegyzéésé alakítjuk, és a bejelentkezett felhasználóval kiadjuk a passwd parancsot, rögtön látjuk, hogy az LDAP-jelszót akarja megváltoztatni a Linux-kliens. Az meg jó nekünk, épp ezt akartuk! Csak annyi a fontos, hogy az LDAP-jelszóváltás is átmenjen az exop-on, de ezt az /etc/ldap.conf fájl szerkesztésével már egyszer megoldottuk.

Szóval kész a nagy varázslat, megoldottuk a Kerberos-LDAP-Samba jelszószinkront.

Irodalom:
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerberos-and-samba

Nincsenek megjegyzések: