Hogyan tudom azt pamban beállítani valamilyen formában, hogy egy adott user/group nem cserélhet jelszót? Eddig soha nem volt ilyenre szükségem... Guglival nem nagyon találtam semmit.
Extraként: Viszont amit találtam a kutakodás közben, hogy groupnak is lehet jelszót adni. Ezt minek?
- 1826 megtekintés
Hozzászólások
A Google a "linux prohibit password change for user" keresőszavakra első helyen ezt dobta ki:
http://www.linuxquestions.org/questions/linux-general-1/disable-passwd-…
- A hozzászóláshoz be kell jelentkezni
Igen, ezt megtaláltam, de ez csak lokális user esetén működik. Azért lenne jó pamból, mert akkor mindegy hol van a user, ldap, sql, yellow pages, ad, stb, akkor is meg lehet tiltani a jelszó cserét.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
chage -m 99999 [user]
Ezt a pam betartatja, ha nem, akkor az adott jelszócserélő cucc pam beállításain kell finomítani. Ha meg valami direktben hegeszti pl. a passwd file-t (nem szokásos), akkor nem tudsz vele mit kezdeni.
- A hozzászóláshoz be kell jelentkezni
Nos, kipróbáltam a tesztrendszeren:
ip-192-168-33-69:/etc # chage -m 99999 myuser
Enter login(LDAP) password:
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
Authentication failure.
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
error trying to bind as "cn=myuser,ou=people,dc=suse-vbox,dc=local" (Invalid credentials).
LDAP information update failed: Invalid credentials
Error while changing aging information.
ip-192-168-33-69:/etc #
Biztosan ez az ldap root pass pedig. Mi nem jó?
[szerk] Persze ldap megy, gép elérhető, loginolni is tud a myuser.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
nincs ldap auth-os gépem, így próbálkozni nem tudok. de olyan rémlik régebbről, hogy adott attribútumokat ldapban saját user jogon akar megváltoztatni (azt hiszem, hogy a password lejárat dátumánál bukott ki nálam az, hogy mindenki magának tudja módosítan pwd váltás nélkül).
Adott dolgokat egy ldap.conf-ban(?) megadott userrel csinálta, másokat saját jogon... egyre inkább ez rémlik, ldap acl beállítás közben jöttem erre rá.
De Nálad azt nem értem, hogy miért a root password-el próbálkozol, mikor "cn=myuser...."-rel akar bind-olni?
- A hozzászóláshoz be kell jelentkezni
Nem értem miért a myusert akarja, mivel annak nincs joga írni az ldapba természetesen. Jól is néznénk ki, ha az adott user saját maga tudja módosítani pl. a jelszó policyt :).
Igen, ldap.conf-ban megpróbáltam megadni, hogy
rootdn "cn=root,dc=suse-vbox,dc=local"
de a helyzet változatlan.
Azért, mert az ldapba csak az ldap root tud módosítani :).
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
próbáld ki, hogy ideiglenesen adsz jogot a myusernek! ha igaz amit korábban írtam, működni fog..!
[szerk] most, hogy így jönnek elő az emlékek, azt hiszem, hogy a userpassword mezőre külön acl kellett, hogy egyáltalán menjen a pw váltás..
- A hozzászóláshoz be kell jelentkezni
Nem adtam semmi extra jogot myusernek, de jelszót tud cserélni.
Egyrészt, ha adok neki írási jogot az ldapba az azért nem jó, mert bármit írhat, másrészt hiába tiltom meg neki, belép és saját magának módosítja...
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Egy próba erejéig sem tudsz +jogot adni, hogy úgy megy-e egyáltalán a chage??
Az üzenetből is egyértelmű, hogy ez kellene hozzá...sajnos ezt vmiért így találták ki.
---
btw. én az alábbi okok miatt nem használtam "távoli" gépen futó ldap-ot:
- ldaps kell hozzá, hogy ne plaintext-ben szaladgáljanak a jelszavak a hálón (ez elég erőforrásigényes)
- a pam userének a jelszava a hoston tárolva van
- fő ok: ha az nscd leáll/lehal, akkor egy find vagy ls sok file-ra = ddos attack az ldap ellen (és az összes azt használó gép ellen -> uid/gid feloldás minden egyes file-ra (connt/search/disc / file!)
- fő ok2: az ldap admin, "rosszab" mint egy root user 1 gépen: az ldap-ot használó összes gépen root lehet, csak a saját uid-jét kell 0-ra állítania...
- a teljes rendszer működése az ldap(ok)tól is függ, önállóan nem mennek sokra
+1, pont ami Neked is a bajod (pwd lejárat manipulálhatósága)
- A hozzászóláshoz be kell jelentkezni
De tudnék jogot adni, de így semmi értelme. Nekem olyan megoldás kéne, hogy a user saját maga ne tudja visszamódosítani a lejáratot. Ilyen ezek szerint nincs?
Az ldaps nem hiszem, hogy egy mai átlagos gépnek őrületesen megnövekedett terhelést okozna.
A pamnak nem kell user, olvasni az érzékeny infókat (pl. password mező) leszámítva lehet auth nélkül is az ldapot.
Az nscd nem nagyon szokott lehalni :), de egyébként ahol nincs rá szükség, ott én magam gyepálom ki.
Az ldap admin általában megegyezik egyébként is a root-tal.
Igen, ahogy az összes, valamilyen módon központi címtáras rendszer működése esetén.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
"de így semmi értelme": ezt a pam_ldap fejlesztőinek is el kellene mondani :)
látom kaptál tisztán pam-os megoldást, így van ilyen, de az ldap vmiért nem így megy.
nscd-vel még a hőskorban voltak bajaim, ott láttam olyat, hogy pofáraesett, ill. valahogy nem volt mindig tiszta, hogy hol jár az igazság, mikor mennyi idő alatt jutnak el a változások a kliensekhez. mindenesetre bizalmatlan vagyok, de lehet, hogy ez csak az én hibám :)
ldap admin vs. root.. : ahol n gép van és 1-2 root, ott nem gond, de ahol n=100+ és sok admin, ott már nem mind1..
- A hozzászóláshoz be kell jelentkezni
> Extraként: Viszont amit találtam a kutakodás közben, hogy groupnak is lehet jelszót adni. Ezt minek?
Azert, mert newgrp-vel tudsz uj groupot felvenni / groupot valtani. Igy meg lehet olyat csinalni, hogy nem adod hozza a usert a www-admin grouphoz pl, hanem jelszot teszel a groupra, es aki tudja, az at tud newgrp-zni. Aki meg nem tudja, az igyjart.
Hogy ez mire jo az mar egy masik kerdes, de biztos van ra igeny valahol. Vagy legalabbis volt. Ha nem lennek tul faradt, biztos ki tudnek talalni jopar helyzetet, amikor ez hasznos.
Jelszovaltas vs PAM: /etc/pam.d/common-password kornyeken nezz korul (legalabbis Debian rendszeren). Mashol a password service korul keresendo a valasz szerintem.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Köszi az extra magyarázatot, világos. :)
Valami konkrétabb linket tudnál adni erről a debianos common-passwordről, ahol ilyesmiről írnak?
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
man pam.d lehet a baratod, valamint /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz es a libpam-doc csomag tartalma. Ezekbol mar szerintem ossze tudod keresgelni, hogy pontosan mikent oldhato meg az, ami neked kell.
Egyebkent valoszinuleg ez kell neked:
password required pam_deny.so
--
|8]
- A hozzászóláshoz be kell jelentkezni
De nem mindenkinek akarom letiltani a jelszó cserét, csak a megadott usernek/groupnak.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Akkor PAM admin manual valo neked :)
--
|8]
- A hozzászóláshoz be kell jelentkezni
Na akkor megnézem majd, köszi.
[szerk] Arra gondolsz, aminek 2005-ben volt egyetlen 0.1b kiadása, és azóta se semmi?
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Nem. /usr/share/doc/libpam-doc/txt/Linux-PAM_SAG.txt.gz: Version 1.1.1, 16. December 2009.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Nálam nincs ilyen, de még hasonló sem.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Debianon libpam-doc csomagban van. Mashol nem tudom hol.
De online is elerheto, pl itt. Elso talalat a "linux pam system administrator guide" -ra (legalabbis DDG-n, feltetelezem googlen is).
--
|8]
- A hozzászóláshoz be kell jelentkezni
Átfutottam, de nem találtam olyan modult, ami ezt tudná.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
*sigh*
password required pam_ldap.so akarmi
password sufficient pam_succeed_if.so user notingroup nopwchg
password required pam_deny.so
Az elso azt irja elo, hogy ahhoz, hogy password valtashoz eloszor a pam_ldap-nak (megfeleloen parameterezve) vissza kell jeleznie, hogy mehet, de ezutan meg folytatodik az ellenorzes, es megy tovabb a masodik modulra. Ami azt irja elo, hogy ha a user nincs a "nopwchg" groupban, akkor rendben vagyunk, es nem kell tovabb nezni. Ha nincs benne, akkor pedig tovabbmegyunk. Ha tovabbmentunk, akkor pedig deny.
Osszessegeben ez azt hozza ossze, hogy az osszes olyan user, aki valthatna jelszot, de nopwchg groupban van, az nem fog tudni valtani. A tobbiek meg igen.
Felhasznalt irodalom:
apropos pam
man pam.conf
man pam_succeed_if
A man a baratod.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam, működik... Köszönöm.
Nem tudom hogy mentem át ezen a modulon. Mondjuk azt se tudtam pontosan, hogy mit keresek. De a lényeg, hogy megvan.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
A passwd parancs futtatási jogait korlátozod?
--
Én egy divathupper vagyok. :)
- A hozzászóláshoz be kell jelentkezni
Egyrészt csúnya, másrészt semmilyen grafikus asztali környezet nem passwd-vel cserél jelszót. Viszont pam-on keresztül működik. Ezért lenne jó ott beállítani, mert az mindig mindenhol működik.
--
Discover It - Have a lot of fun!
- A hozzászóláshoz be kell jelentkezni
Sub
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni