(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
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 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
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: quitMeg 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.keytabJogot 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 acPersze 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/adminHa már megy, akkor:
sudo kadmin -p smbkrb5pwd/ubuserver.itthon.cucc -k -t /etc/ldap/slapd.d/openldap-krb5.keytabMennie 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.CUCCKiemelné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=cuccNa 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=cuccparancsot, 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=cuccakkor 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 a 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=cuccHanem 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.
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.soAzaz 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:
Megjegyzés küldése