Porovnani LDAPu a sdileni /etc/{passwd,shadow,group} (diskuse)

[xxx]

* sprava uzivatelu je oddelena od uzivatele "root" nejak nechapu tu zavorku s tim odstavenim?

[Jan Kundrát (jkt)]

Bezne pouzivany nastaveni prav pro pristup do LDAPu je to, ze si kazdy uzivatel muze menit sve heslo, shell,... a jakysi "LDAP administrator" muze menit vsecko, pridavat nove uzivatele, mazat je,...

Cili zatimco normalne muze root menit uzivatele dle libosti, kdezto s LDAPem ne, pokud se PAMu/NSS nerekne, aby se do LDAPu bindoval jako ten "LDAP admin".

[xxx]

jo tak to je tohle, jsem to nejak nerozpoznal v tom blogu. Jenom si rikam, co je na tom problematickeho. Navic lze jeste vytvorit jakehosi osekaneho ldap admina.

[Honza "tux" Friesse]

Myslím, že nic podstatného neuniklo. Otázka je, co za LDAP server nasadit. Osobně jsem o tomto řešení (v menším měřítku, 3 stroje a asi 900 uživatelů) přemýšlel. Testoval jsem pokusně OpenLDAP (balíček v Debianu 3.1) a moc mě to neuspokojilo. Databáze se sem tam porušila, pokud se klient připojil v době kdy se server startoval došlo "zřejmě" k deadlocku. Prostě problémy. Pokud má někdo lepší zkušenosti, rád se nechám poučit. Nakonec jsem zvolil sice méně bezpečnější a starší variantu sdílení údajú a to NIS. Ten funguje k mé plné spokojenosti.

[Jan Kundrát (jkt)]

CDSS od Symas, coz je RPM pro OpenLDAP pro RHEL.

[Zdeněk Burda]

Co zkusit Fedora DS?

[Jan Kundrát (jkt)]

Nejaky reference by byly?

[Zdeněk Burda]

Fedora DS vychází z iPlanetu, stejně jako SUNovský DS. Nějaké počtení o tom najdeš na domácí stránce projektu.

[Martin Povolný]

Ukladame verkere ucty, konfigurace, kontakty, kalendare, .. a kupi veci do LDAPu, tak, jak pises viz tady.

LDAP repliky po VPNkach... Hostingove servery s ucty v LDAP.

LDAP

• pomerne slozita problematika.
• kontakty do outlooku, thunderbirdu, evolution..., jak pises nedostanes zadarmo - kazdy program pouziva jine tridy, da praci vsechno nastavit tak, aby byla vetsina atributu ve vetsine klientu v poradku...
• autentizace dalsich sluzeb: sice ano, ale libnss-ldap je nejvetsi shit, neznam zavsivenejsi knihovnu a pokud mas vsechny ucty v LDAPu, tak libnss-ldap je pomerne kriticky kus software.
• ne vsechny volani z libc6 jsou cachovany v nscd --> zalezi na konkretnim software a systemovych volani, ktera provadi, jak jsem napsal v blogu: upravoval jsem memcache a cyrus, aby mi nepropadavaly dotazy z autentizace zkrz nscd do ldap (cachuji je v tom memcache). Je potreba proverit jednotlive aplikace, aby neumlatili server nejakym pitomim necachovanym volanim.
• jeste 1x: pozor na vykon LDAP serveru.

[Jan Kundrát (jkt)]

kontakty do outlooku, thunderbirdu, evolution..., jak pises nedostanes zadarmo - kazdy program pouziva jine tridy, da praci vsechno nastavit tak, aby byla vetsina atributu ve vetsine klientu v poradku...

Predpokladam, ze to nikde neni hezky popsany, a tak budu muset UTFG, co...

autentizace dalsich sluzeb: sice ano, ale libnss-ldap je nejvetsi shit, neznam zavsivenejsi knihovnu a pokud mas vsechny ucty v LDAPu, tak libnss-ldap je pomerne kriticky kus software.

Jak tomu mam rozumet? Pada to, a nebo takovy ty klasicky problemy jako ze se pri upgradu z jedny verze na druhou meni defaultni timeouty a tim padem se zpomali boot, protoze mas retardovany nastaveni udev atd? :)

ne vsechny volani z libc6 jsou cachovany v nscd --> zalezi na konkretnim software a systemovych volani, ktera provadi, jak jsem napsal v blogu: upravoval jsem memcache a cyrus, aby mi nepropadavaly dotazy z autentizace zkrz nscd do ldap (cachuji je v tom memcache). Je potreba proverit jednotlive aplikace, aby neumlatili server nejakym pitomim necachovanym volanim.

Hmm, jako v manualu od nscd se pise, ze to necachuje treba getspnam(), ale o getgrent() tam neni ani slovo... Blbej dotaz - povolil jsi dostatecnou velikost cache pro groups? :)

jeste 1x: pozor na vykon LDAP serveru.

Da se nejak hrube odhadnout, "kolik to pozere"?

[Martin Povolný]

Predpokladam, ze to nikde neni hezky popsany, a tak budu muset UTFG, co...

Prijemnou zabavu. Zkus treba vygooglovat jmena atributu pro outlook.

Jak tomu mam rozumet? Pada to, a nebo takovy ty klasicky problemy jako ze se pri upgradu z jedny verze na druhou meni defaultni timeouty a tim padem se zpomali boot, protoze mas retardovany nastaveni udev atd? :)

Ano, pada to, je to plny chyb. Vyvojari chyby neopravuji, nybrz generuji nove verze, ktere maji zase jine chyby....

Distribuce (alespon ubuntu a debian) me v tomhle taky zklamaly, protoze od nich v techto pripadech ocekavam, ze udelaji praci za autory software a budou zaplatovat..

V konkretnim pripade jsem treba resil stav, ze padal FTP server, pokud urcita reprezentace seznamu clenu skupiny mela delku presne 1024 bajtu. 1023 nebo 1025 uz bylo ok.

Hmm, jako v manualu od nscd se pise, ze to necachuje treba getspnam(), ale o getgrent() tam neni ani slovo... Blbej dotaz - povolil jsi dostatecnou velikost cache pro groups? :)

Treba getgrouplist. Velikost cache: ano to je opravdu blby dotaz.

[Jan Kundrát (jkt)]

Prijemnou zabavu. Zkus treba vygooglovat jmena atributu pro outlook.

Tak tohle bylo zrovna fakt easy :)

Ano, pada to, je to plny chyb. Vyvojari chyby neopravuji, nybrz generuji nove verze, ktere maji zase jine chyby....

Existuje nejaka alternativa?

V konkretnim pripade jsem treba resil stav, ze padal FTP server, pokud urcita reprezentace seznamu clenu skupiny mela delku presne 1024 bajtu. 1023 nebo 1025 uz bylo ok.

Fuj :(.

[Filip Jirsák]

Ano, pada to, je to plny chyb. Vyvojari chyby neopravuji, nybrz generuji nove verze, ktere maji zase jine chyby…

To se jedná o nss_ldap od PADL Software? Nebo nějaká jiná knihovna?

[Martin Povolný]

To se jedná o nss_ldap od PADL Software? Nebo nějaká jiná knihovna?

Ano, to je presne ono.

[Filip Jirsák]

Nevím, zda vás to potěší, ale nss_pgql je ještě o něco horší než nss_ldap – nss_ldap mi, když už to jednou začlo fungovat, běželo relativně spolehlivě (pravda, používalo se vlastně jen pro Sambu, lokálně se ti uživatelé nehlásí; uživatelů bylo celkem asi 300, ale najednou se jich může přihlásit asi 40, pak dojdou fyzicky počítače ); nss_pgsql bylo nejprve nutné opravit, aby to alespoň vracelo správné návratové kódy…

Když jsem zprovozňoval nss_ldap a následně nss_pgsql, a byly u toho jen samé problémy, tak jsem si říkal, k čemu vlastně to NSS je, když snad jediný opravdu funkční plugin používá zase klasické soubory

[zde]

Ještě k tomu výkonu.. Nejde až tak o CPU, ale spíš o disk a paměť. OpenLDAP ukládá databázi extrémně neefektivně. Nenamáhá se jakkoliv komprimovat DNs, ani tokenizovat atributy, prostě nic. Vezměte LDIF celé databáze, velikost vynásobte dvěma až třema, přidejte něco na sekundární indexy, a tohle bude na disku. Pokud nebude dost paměti aby to BDB nebo OS cachoval, tak to bude velmi pomalé.

[petr_p]

priklad: uzivatel "franta" ma na sve pracovni stanici roota a chce na ni povolit pristup uzivatelum "franta", "pepa" a "jirka"; zaroven chce, aby souhlasily jejich uid i hesla, kdyz uz ma pres NFS pristupne jejich homes.

Tudiz uzivatel franta ma pristup k homum vsech uzivatelu (protoze NFS a lokalni root) a samozrejme muze sledovat lokalne prihlaseneho uzivatele a ziskat tak pri trose stesti jeho credentials (protoze lokalni root a uzivatel se hlasi z jeho stroje jinam).

[Jan Kundrát (jkt)]

Jo, mas pravdu a vime o tom. Proto tohle nedavame vsem uzivatelum, ale jenom tem, ktery toho roota na tech serverech uz maji :). (Samozrejme pouzivame root_squash, ale jak rikas, lokalni root znamena moznost podvrhu uid.)

[Honza "tux" Friesse]

V RHEL (aspoň verze 4, dřív nevím) by měl být NFSv4, který tento problém elegantně řeší.

[petr_p]

Muzete mne trochu postrcit? Nemuzu prijit na zadny zpusob, jak zabranit lokalnimu rootovi -- tedy jadru, aby na jednu stranu poskytovalo soubory prihlasenemu uzivateli a zaroven je pred rootem -- tedy sebou samym -- schovalo.

Prijde mi, ze to z principu nejde a jsem smiren s tim, ze uzivatel musi adminovi libovolneho serveru verit. Rekneme, ze pri trose opatrnosti si uzivatel muze sve credentials/tickety uchranit (napr. rpc s rozsirenim pro kerberos), ale data uz ne.

[Honza "tux" Friesse]

Popravdě sám jsem NFSv4 ješte nezkoušel, takže odkaz http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-nfs-security.html a vysvětlení, jak jsem to pochopil.

Jde o to, že klient už se neautentifikuje pomocí UID v každém poslaném paketu, ale autentifikuje se jednou pomocí Kerberosu (tj. jménem a heslem). Potom má token a server už mu věří. Celé to jde zautomatizovat pomocí PAMu, takže když se člověk přihlásí k serveru (a to jak na Linuxovém stroji, tak třeba ve Windows přes Sambu), autentifikuje se i do Kerberosu a může si procházet svoje adresáře.

Jak přesně to funguje ale nevím, snad poradí někdo, kdo s tím má zkušenosti.

[Honza "tux" Friesse]

Aha, nedočetl jsem to celé. Tak jak to berete Vy to asi opravdu neuchráním. Uchráním to, že někdo příjde s LiveCD a přimountuje si NFS adresář. Ale pokud má na stroji, kde se hlasí jiní uživatelé, práva uživatele root, tak to asi vážně ne. Jinak token si nahraďte za ticket, v tom vedru se nedá myslet.

[xxx]

Nenastavuje se proto v /etc/exports neco jako no_root_squash. Jinak neni spis problem, ze si nekdo nastavi v /etc/passwd stejneho uzivatele jako je uz v ldapu, a bude se tim padem vydavat za neho. To se tusim resi v /home/nsswitch.conf, kde lze nastavit, ze pokud ldap fail, tak teprve zkusit passwd.

Ps: a nebo taky melu uplny blbost ;)

[Jan Kundrát (jkt)]

Jestli myslis /etc/nsswitch.conf, tak to se tyka pouze toho, jak bude glibc prekladat uid/gid na jmena (plus dalsich veci typu /etc/hosts atd), cili jsi asi myslel /etc/pam.conf (nebo /etc/pam.d/*).

To root_squash zajisti jenom to, ze kdyz stroj, co to ma namounteny, posle nejakej request pro uid 0, tak ze to NFS server bude brat jako request s nejakym definovatelnym "anonymnim uid". Nezabrani to tomu, aby ti klient predstiral, ze se na nej prihlasil uzivatel s uid, jehoz soubory chces dostat.

NFS je zkratka z No File Security btw :)

[xxx]

Jj mate pravdu, stim pamem a nsswitchem. Jsem si nemohl vzpomenout, kde vsude jsem resil jak to nastavit. A po precteni tohodle prispevku mi doslo i jak je snadnej utok z prineseneho notebooku.

[OndraZX]

Sice danemu tematu moc nerozumim (nepouzivam LDAP), ale proc nemate ve vyberu i NIS? Je pro to nejaky duvod? Reseni pomoci sdileni je "zajimave" ale vetsinou se pouziva bud NIS, nebo LDAP.

PS: toto tema mne zajima, proto se ptam a zarazila mne absence NIS.

[Jan Kundrát (jkt)]

Sdileni souboru je soucasny stav, LDAP je to, o cem uvazujem, o NIS jsem slysel jenom neco jako "starsi reseni, ktery je min bezpecny", a navic mam pocit, ze se to uz u nas pred par roky zkouselo a pry to blbe dopadlo.

[Jan Kundrát (jkt)]

raxas me na #gentoo.cs upozornil na to, ze ten skript ma nevyhodu, ze vyzaduje mit aspon r/o pristupny cely /etc/shadow z masteru, a tudiz root na vsech serverech vidi hash rootovskeho hesla z masteru.

[vlanav]

Ja, bych taky chtel premigrovat na LDAP a Sambu i s NT domenou. Neco se mi podarilo rozchodit, ale jeste mam porad strach to preklopit. Celou konfiguraci Samby i LDAP (+ntp server) mam na diskete a programy bezi z CD (distro devil-linux). Na administraci LDAP jsem nasel pekny opensourcovy LDAPadmin. Hledal jsem nejake instantni reseni(TM) - nejlepe LiveCD s webovym rozhranim, ktere by melo v sobe minimalne LDAP+Sambu, ale bohuzel jsem nic takoveho nenasel (ani komercni).

[Lukáš Zapletal]

Zajímalo by mě, jestli existuje nějaké řešení pro webhostingový firmy, postavený kompletně na LDAP. Tedy veškeré informace o uživatelích v LDAP (hesla, limity, cesty, schránky).

Zkoušel jsem totiž současné systémy VHCS a ISPConfig a oba mi připadají značně nemotorné, rozhasí celý systém. Uvažuji o něčem postaveném právě na LDAP (ze kterého by čerpal apache, ftpd, postfix...)

Řešil někdo podobný problém?

[Karel Benák]

Ano, za svých studií jsem se pokoušel něco takového rozběhat a narovinu říkám, není to žádná malá sranda. Pro proftpd, apache i postfix existují moduly a lze je celkem obstojně integrovat, problém ale spíš vidím v návrhu stromu tak, aby efektivně zachycoval vaše zákazníky, jejich konfigurace a nastavení. Zkuste si přečíst mou diplomku, třeba Vám k něčemu bude. Neřešil jsem v ní sice Postfix, ale DHCP a DNS server. Bohužel na experimenty s LDAP serverem už nemám tolik času a hlavně tak solidní zázemí, jako jsem měl na koleji. Pokud byste ale měl zájem něco rozchodit, napište mi a můžeme si o tom popovídat a něco málo i vyzkoušet.

[Lukáš Zapletal]

Díky za odkaz, pokud do toho najdu odvahu, určitě ten text projdu. Nepochopil jsem ovšem, jak myslíte ten problém návrhu struktury. V čem přesně myslíte, že je zakopán pes?

[Martin Povolný]

Tak to jste do toho jeste moc nepronikl , kdyz jeste nevidite, jak je to slozite

My se snazime taky neco takoveho delat. Po rade pokusu jsme ale u nekterych sluzeb ustoupili v tom smyslu, ze si tyto sluzby nectou konfiruraci primo z LDAPu, ale podle LDAPove databaze pro ne konfiguraci generujeme.

Je to mene elegantni ale casto pruznejsi.

Navic celou architekturu systemu mame trojvrsvou:

Sluzby <------------>  LDAP
                        A
                        |
                        |
                        V
Sluzby <------ SAS aplikacni server <------> (Command line / Webove UI)

[Lukáš Zapletal]

Velmi podobně to dělá zmíněný ISPMan. Stále jsem se ale nedozvěděl, co je na vytváření těch struktur tak složitého. Já vím, jaký je LDAP maso, ale neptám se na samotný proces konfigurace, jako spíš na to, jestli je někde zakopán pes (že zkrátka něco tímto způsobem řešit nejde).

Se LDAPem jsem si zatím vždy jen hrál, ale v tomto Howto: Debian + ISPMan je jasně zřetelné, že to nebude procházka růžovým sadem. To rozhodně. Nicméně se mi to jeví jako nejlepší řešení, distribuované, snadno zálohovatelné...

U ISPManu je výhoda, že všechny struktury jsou již vytvořené a stačí je do LDAP serveru jen nahrát. Otázkou bude, nakolik budou funkční a použitelné. ISPMan má velmi špatnou dokumentaci (prakticky žádnou, pár chaotických readmes).

ps - v architektuře ISPManu všechny služby čtou z LDAPu přímo (nebo nepřímo pomocí pam_ldap), konkrétně Apache2, Bind9, Postfix a ProFTPd. jaké konkrétní služby máte na mysli (narážím na to ustoupení od přímého načítání dat z LDAPu)?

[Martin Povolný]

Nemam chut to rozvadet, protoze presvedcovat nekoho, kdo to nezkusil, ze to neni snadne, je plytvani casem. A i kdyby se mi to povedlo, tak vas akorat pripravim o nadseni

Nicmene v dalsich bodech vam neverim. Myslim, ze jste si to dostatecne neprostudoval.

Namatkou jsem proklikal par stranek o ispman a nasel jsem odkazy na skript ispman.ldap2apache, ktery podle toho, co jsem videl generuje konfiguraci apache z LDAP.

Podobne to podle mne bude u Bindu: ispman.ldap2named.

Co se tyce proftpd, tak tam neni problem jet primo z LDAP. Postfix nevim, slysel jsem, ze je to v pohode, ale nemam osobni zkusenost. My pouzivame Exim, tam lze napsat pravidla tak, aby se veskere potrebne udaje hledaly primo v LDAPu.

Dalsi sluzby, treba samba, to jde, ale neni uplne legrace udelat to tak, jak potrebujeme. Zalezi na verzi samby, LDAP kod tam doznal v poslednich verzich podstatnych zmen. Resime to opatchovanim samby.

Rada dalsich sluzeb muze fungovat pres PAM...

[Filip Jirsák]

Postfix je relativně v pohodě, to znamená, že to funguje, akorát Postfix ještě nemá implementováno cachování, takže je dobré mít LDAP zrcadlené na stejném počítači, jako je Postfix, aby dotazy netrvaly dlouho.

[Martin Povolný]

Hmm, mel jsem za to, ze Postfix disponuje nejakym kodem, ktery cachuje LDAP lookupy a chapal jsem to jako jednu z jeho vyhod proti Eximu.

Exim bohuzel necachuje.

LDAP repliku doporucuji na kazde masine, ktera se bude do databaze trosku vic dotazovat.

[Filip Jirsák]

Nikdy jsem to podrobně nezkoumal, ale Postfix psal nějaké hlášky v tom smyslu do logu, a v man ldap_table je napsáno:

cache (IGNORED with a warning)

cache_expiry (IGNORED with a warning)

cache_size (IGNORED with a warning)
     The above parameters are NO LONGER SUPPORTED by Postfix.   Cache
     support has been dropped from OpenLDAP as of release 2.1.13.

[Martin Povolný]

Jak jsem rikal, nejsem expert na Postfix. Ale kdyz jsme hodnotili, jestli z Eximu 3 prechazet na Exim 4, nebo na Postfix, tak jsme cacheing resili.

Po par kliknutich mam pocit, ze separatni cache pro LDAP byla opravdu z Postfixu odstranena. Ale stalo se to proto, ze v postfixu existuje obecna "lookup cache", ktera cachuje vsechny lookupy, cili neni potreba mit dalsi specialne pro LDAP.

[Filip Jirsák]

Je to množné, já také nejsem expert na Postfix Původně to běželo a dostatečně výkonně i přes tu hlášku v logu, tak jsem to neřešil, a později jsme stejně přešli na PostgreSQL, tak jsem to dál nezkoumal…

[Lukáš Zapletal]

Našel jsem dokonce projekt ISPMan, který se to snaží řešit. Dokonce je aktivní. Zkusím.