LDAP kliens jelszava

UNIX haladó

Sziasztok,

LDAP kliens jelszava csak plaintext-ben lehet a /etc/ldap.conf-ban?


binddn cn=ldapbind,ou=service account,dc=domain,dc=hu
bindpw plain_jelszo

Ha a /etc/ldap.conf jogosultságát beállítom 600-ra, akkor ha pam ldap auth történik (ssh-n csatlakozik az ldap-ban tárolt user), akkor az azonosítás megtörténik, de a továbbiakban a user nem fér hozzá az ldap.conf fájlhoz a jogosultság miatt, pedig ez szükséges lenne a uid, gid kiolvasáshoz is...

ssh bejelentkezés után:

id: cannot find name for user ID 10006
id: cannot find name for group ID 10002
id: cannot find name for user ID 10006
$ ls -la
drwxr-xr-x 2 10006 10002 4096 May 11 09:14 .
drwxr-xr-x 9 root root 4096 May 11 09:14 ..
-rw-r--r-- 1 10006 10002 33 May 11 09:14 .bash_logout
-rw-r--r-- 1 10006 10002 176 May 11 09:14 .bash_profile
-rw-r--r-- 1 10006 10002 124 May 11 09:14 .bashrc

Gondoltam jó megoldás lesz, hogy ki teszem a jelszót a /etc/ldap.secret fájlba. Ez esetben a /etc/ldap.conf idevonatkozó része a man szerint erre módosul:


rootbinddn cn=ldapbind,ou=service account,dc=domain,dc=hu

Igaz, plain text-ben van a jelszo ldap.secret fájlban, de legalább 600 jogosultsággal. De minek is, ha userként nem tudja futtatni az id parancsot?

Mi erre a megoldás?

Próbáltam saslauthd-vel. testsaslauthd parancs működik is jól, de pam-on keresztül már nem. Nincs dokumentálva sehol se, hogy valójában mit is kell beállítani ldap.conf-ban ahhoz, hogy a localban működő saslauthd socket-hez csatlakozzon. testsaslauthd parancsnál látszódik szépen strace-el a connect /var/lib/saslauthd/mux-hoz, 'id usernev' parancsnál semmi. :(

  • 919 megtekintés

( vl v | 2010. 05. 11., k – 10:18 )

az a jelszó az a jelszó, amivel a user megnézheti a /etc/passwd-ekvivalens adatbázist az ldap-ban. mivel az /etc/passwd 644, ezért mezei user is meg tudja nézni. na ezzel ekvivalens az a jelszó, amit 644-es jogosultsággal elérhetővé kell tenned. az gondolom természetes, hogy ez az ldap user read-only kell, hogy legyen.

az ldap.secret azért 600, mert az lesz a root-ekvivalens (read-write) user jelszava, akivel a rootként futó programok meg tudják csinálni azokat a dolgokat, amiket /etc/passwd esetén az írásjogukkal meg tudnának csinálni (/etc/shadow-ból password kiolvasás, adatok módosítása).

alternatív megoldás: nscd használata. ilyenkor a mezei user az nscd-vel beszélget, és elég a jelszó az nscd-nek, mert az ldap-ban csak ő fog nézelődni.

Igen, a /etc/passwd ekvivalens 'eszmefuttatást' tiszta:)
Csak az nem volt meg, hogy lehet úgy beállítani, hogy ne tudja user olvasni a plain text jelszót tartalmazó fájlt!

nscd-vel működik jól, köszönöm a segítséget!

A ldap-pam-saslauthd problémával nem foglalkoztál? Az még lenne egy jó megoldás erre...

rühellem az sasl-t. ahol tehetem, elkerülöm. egyelőre ez minden gépemen még működik :)

nem látom, hogy miért lenne ezzel probléma.

a nekem 'secure' megoldás, hogy
- minden ldap-ban van
- jelszó ldap-ban cryptelve
- authentikáció: pam (ldap bind útján), a kliensnek clear text jelszót kell adnia az ldap connecthez, az ldap szerver meg majd eldönti, hogy érvényes-e
- módosítás, jelszóváltás: csak off-line módon (pl. egy webes felületen)
- emiatt csak a read-only user/jelszó kell az /etc/ldap.conf-ba,
- a root sem fér hozzá az encryptált jelszavakhoz, módosítás nincs pam-on keresztül, tehát rootbinddn és /etc/ldap.secret nem is kell

előnyök:
szenzitív infókhoz csak a webes felület fér hozzá

hátrányok:
csak clear text jelszóval operáló protokollok tudnak authentikálni (ppp chap kiesik)

( golgota | 2010. 05. 11., k – 11:54 )

binddn minek?
minden felhasználó bindolja magának a saját nevében jelszavával
van valami speckó oka, hogy külön bind-olod egy service felhasználóval?