unix domain logon

UNIX haladó

Számítógéprendszer egységesítési törekvéseim hasznára indítanám ezt a topikot.
Általam ismertebb unix rendszerekbe való bejelentkezés - igaz, sok és sokféle rétegen keresztül, de végérvényesen - lokálisan zajlik (/etc/passwd, shadow és társai).
A kérdésem az, hogy van-e olyan software, vagy lib, amivel a legkevesebb módosítással központosított hálózati authentikációra állíthatjuk a gépeket? Úgy mint a Domain Logon az Ablakok háza táján.
A legtöbb hasonlót megvalósító leírás LDAP, samba, winbind-et alkalmaz. Nekem feleslegesek az ezek által nyújtott többletek, elég kellene egy quasi "remote mounted /etc/passwd", vagy remote AAA service - ha elég transzparensen be lehet építeni a rendszerbe.
Tehát csak az UID/GID hozzárendelés [...] kell.
(egyébként debián kiadások lesznek az áldozatok)
Biztosan van valami mainframe érából maradt módszer erre...

  • 8246 megtekintés

Biztonság terén nincs igazán a topon, meg azért az sem mindegy, hogy mekkora user, illetve kliensszámról van szó... Nem véletlen a NIS+ megszületése, mint ahogy az sem, hogy a NIS/YP meg a NIS+ eléggé ritka állatfaj manapság.

És persze _ha_ működk. LDAP-hoz van csillió+1 tool, leírás, ráadásul kétféle ember használ/üzemeltet ldap-ot (boldog-boldogtalan), ergo online segítséget is többet kap ldap-hoz, mint az őskövület NIS-hez. Szerintem...

Cserébe a NIS végtelenül egyszerű. Valamit valamiért. Nekem is volt NIS is, meg van LDAP is, mindkettőnek meg van a helye. Persze a NIS hamar kieshet a kosárból pl. a titkosítás hiánya miatt (asszem csak a NIS+ titkosítja a forgalmat), de a jelen esetben elsőnek a NIS-t próbálnám. Utána jönne az LDAP, már csak azért is, mert ki tudja hogy mit hoz a holnap.

ugye nem arra gondolsz h olyan easter egg-ek vannak benne, mint az NFS-ben, hogy maximum 32 csoporttagságot visz át amikor hozzáférést kérek egy fájlhoz és ha group szerint hozzáférnék de az NFS nem viszi át azt a csoportnevemet/GID-emet, akkor nem férek hozzá.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

kipróbáltam ezt a lehetõséget.
tehát [sshd] -> [pam_unix] -> (nscd) -> [libnss] -> [mysql],
ill. [login] -> [pam_unix] -> ...
irányban törtenik a bejelentkezés.

sajnos, nem annyira transparens, mit vártam. a bejelentkezés oké, nagyjából meg tudom feleltetni az /etc/{passwd,shadow} fájlokat adatbázistábláknak. (a libnss egyébként annyira nem ragaszkodik a unix hagyományokhoz és inkább kihasználja az sql adta elõnyöket: kapcsolótáblában tartja nyilván a user-group hozzárendeléseket, nempedig az /etc/group 4. mezõjében)
de más account mũveletek: passwd, chfn, chsh, useradd, ... továbbra is a helyi passwd fájlt nyaggatnák.

Ezekbe nincs belefũzve a libnss vagy további beállításokat kell eszközölni?

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Az nsswitch-ben gondolom akkor beállítottad a megfelelö paramétereket.

Nem néztem ennyire utána. Nekem megfelelt az adatbázisban "túrkálás" a passwd illetve useradd/usemod parancsok megfelelöjeként.

Föleg ha az egy központi gépen van akkor akár egy (pl: mysql) workbench-szerű vagy *myadmin webes tool-al megoldható. Bár én SQL konzolban szoktam felvinni a usereket. Söt scripttel, ha több user-t kell felvenni.
Több netes példa és saját összerakott SQL db alapján nálam csak 3 táblába kell írni. Nem egy nagy kunszt... bár izlések és pofonok...
A useradd/passwd és hasonló tool-okat az ilyen gépeken "elfelejtettem", együtt élek a "hiányukkal". Annó próbáltam rá megoldást keresni, de idö hiányában abbahagytam.

kiforrottabb technológiának éreztem, de úgy látszik nem erre haladt a fejlesztés.
ldap tudna ilyet? hogy pl. passwd paranccsal az ldap accountomnak változtatnám a jelszavát? - bár ez annyira nem is igény. én is - ahogy írtad - elfelejteném ezeket a standard tool-okat és a webfelületrõl kezeltetném.

közben módosítanék a témafelvetésen:
igaz, hogy egységesíteni akarok, de irónikus módon arra is szükségem van, hogy egyes authentikátoroknál, más látszódjon: egyszer más logon shell, másszor más account lejárat. tehát munkaállomásonként meg tudjam különböztetni a folyamatot.
vagy erre az ldap sincs erre kihegyezve?

akkor a következõ subtopic: howto compose an PMA plugin?

jelenlegi nsswitch.conf:
passwd: compat mysql
group: compat mysql
shadow: compat mysql

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Csak halkan szólok, hogy a PAM mechanizmusnak 4-féle funkciója van, és ebből az egyik - amit sajnos szeretnek nem, vagy nem jól implementálni -, azt úgy hívják, hogy "password" (man pam_chauthtok, azaz change authentication token), és rendes pam modulok esetén pontosan arra szolgál, hogy a "jelszó" megváltoztatását az adott modul használata esetén lehetővé tegye. Azaz pl. pam_ldap (vagy ezzel kompatibilis) modult használva autentikációra, képesnek kellene legyen simán az LDAP adatbázisban tárolt password módosításra is simán az alaprendszer passwd paranccsal. A hangsúly az (el nem hangzott) "elméletileg" kitételen van, azaz nincs róla listám, ogy mely pam modulok valósítják meg az auth / account / session / password fuknciók mindegyikét korrekten.

( mauzi v | 2012. 07. 19., cs – 14:18 )

A "remote mounted /etc/passwd" neve a UNIX világban: NIS.

A NIS mindamellett eléggé fapados, én biztos LDAP-ot használnék.

( egeresz | 2012. 07. 19., cs – 14:22 )

nem lesz egyszerű.

A 'modern unixok' de legalábbis a debian PAM -ot használ az azonosításra.
A PAM az /etc/pam.d/ -ben lakik.

Nagyjából arról van szó, hogy az azonosítást igénylő szoftverek (ssh szerver, grafikus bejelentkezés, karakteres bejelentkezés) ide fordulnak, hogy hogyan is azonosítsák a usert.
Az itt található apró szöveges konfigokkal lehet megmondani, hogy hogyan is.

Alapesetben a tradicionális unix (pam_unix.so) modul van ott, ami a /etc/passwd és társait használja az azonosításhoz.

Rengeteg PAM modul van. Az egyik a központi LDAP -ot használja. A másik a központi LDAP+KRB párost (ami megfelel az Active Directory technológiájának).
De lehet a 20 éves unixos megoldás (NIS, NIS+, de nem javaslom) vagy éppen egy központi mysql szerverbe való bejelentkezés, bármi: rengeteg féle PAM modul van.

Sajons nem tudok olyan debiános megoldásról, ami neked kényelmesen összerekná az egészet, tehát épeszűen felrakná a központi szervert, és felkonfigurálná hozzá a klienseket. Amikor ilyet csinálok, mindig editálom a /etc/pam.d/ tartalmát, nem egyszerű.

HTH

a központi szerver felkonfigurálása nem akadály, azt úgyis mindig birizgálni kell, a kliensek teendõ változtatások aggasztottak inkább, pl. ne kelljen kernelt forgatni hozzá vagy ilyesmi...

tehát elég lenne csak egy pam modult engedélyezni és beállítani hozzá, ez kedvezõ.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

( dhary | 2012. 07. 19., cs – 15:09 )

lehet én értem félre, de nem a likewise-open-t keresed?

( viraghj v | 2012. 07. 20., p – 14:13 )

A Redhat/Fedora rendszerekben mostanában a System Security Services Daemon-t (SSSD)

http://fedorahosted.org/sssd/

használják (ami mögött lehet távoli LDAP, Kerberos, OpenID vagy más adatbázis). Sőt az alábbi levél szerint a fentebb említett klasszikus UNIX megoldásokat mind lecserélik erre:

---------------------
Intent to retire: nss_ldap
Jakub Hrozek jhrozek at redhat.com
Thu Jun 7 21:20:46 UTC 2012

Hi,

I would like to retire PADL's nss_ldap and pam_ldap from current Rawhide.

SSSD has been the default in Fedora for quite a few releases with
nss-pam-ldapd as another option for deployments that, for some reason,
do not want to migrate to the SSSD. nss_ldap also seems to be abandoned
upstream.

Are there still any users of nss_ldap? If so, what are the reasons
keeping you from using either nss-pam-ldapd or the SSSD?
--------------------

Úgy látom, a Debianban is van SSSD csomag, nem tudom, próbálta-e már valaki a Kollégák közül.

http://packages.debian.org/unstable/main/sssd

( Zsugabubus | 2012. 10. 08., h – 15:59 )

Ha már megy az LDAP szerver, onnan szerintem nincs olyan disztribúció, ahol ne lehetne pár kattintgatással/2-3 textbox kitöltésével használatra bírni.
A NIS az egy IT történelmi múzeumba való, 2012-ben ne már...