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

18.7.2006 14:54 | Přečteno: 2557× | poslední úprava: 18.7.2006 23:04

V jedne organizaci mame neco kolem deseti serveru, kterych se tento problem tyka (a na dalsi stovky se mozna bude rozsirovat), a radove stovky uzivatelu. Potrebujeme na nich nejak sdilet seznam uzivatelu.

V soucasne dobe system funguje tak, ze je z "master serveru" pres NFS exportovan cely root FS a mimo jine i malicky skript. Tenhle skript dela v podstate jenom to, ze vezme /etc/{passwd,group,shadow} z masteru, v shadow zmeni heslo roota na puvodni pro dany stroj (to zjistuje z lokalniho shadow) a soubory prekopiruje. Tenhle skript je na vsech strojich nacronovan, aby se poustel v nejakych periodicky definovanych intervalech. Planujeme prejit na LDAP, nicmene bylo by dobry mit nejake shrnuti vyhod a nevyhod. Inu, tohle me napadlo:

porovnani LDAPu se sdilenim souboru /etc/{passwd,group,shadow}

(+ .. vyhoda, - .. nevyhoda, * .. vlastnost)

stavajici setup:

• + odolnost proti jakemukoli vypadku mimo cas synchronizace (coz je nam k nicemu, protoze stejne exportujeme /home z jednoho stroje pres NFS)
• + relativne jednoduchy system
• - nesystemove reseni
• - kompromitace masteru by znamenala kompromitaci vsech ostatnich stroju
  • utocnik by mohl prepsat synchronizacni skript; tomu by se dalo branit jeho presunem na stanice, ktere se maji synchronizovat, nicmene to by znamenalo vice prace pri pripandych upgradech etc
  • moznost pridani dalsich uzivatelu s uid 0 (tj. utocnik si muze udelat sveho roota)
• - vynucene se sdili vsechny ucty krome roota, tedy i ty systemove (da se obejit upravou skriptu, nicmene jediny spolehlivy zpusob by byla kontrola uid, coz je opet dalsi prace navic)
• - vypadek behem kopirovani souboru muze mit zajimave nasledky
• - vsechny servery vidi hash rootovskeho hesla na masterovi

LDAP:

• + zmeny se promitnou okamzite, resp. v radu sekund a ne hodin
• + systemove a overene reseni (LDAP je naprosto standardni vec, mj. i soucast ActiveDirectory od Microsoftu)
• + neni problem sdilet hesla se Sambou (bez vynuceneho vypinani sifrovani) a jinymi platformami
• + snadna integrace se stroji uzivatelu

  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

• + proti LDAPu se mohou autentifikovat i dalsi sluzby (napriklad mail na sosne)
• + moznost vyhledavani lidi a kontaktu (mailove klienty - Outlook,...), do databaze se daji dat i telefonni cisla,...
• * hash hesla nemusi byt ulozen na vsech strojich, ale jen na LDAP serverech (kterych na druhou stranu muze byt mnoho)
• * sprava uzivatelu je oddelena od uzivatele "root"

  (pro pristup k databazi se musi administrator do LDAPu prihlasit jako databazovy superuzivatel, nikoli jako root stroje, na kterem DB bezi, i kdyz i to je v pripade potreby mozne, nicmene ne zcela jednoduche - musel by se docasne odstavit LDAP server,...)

• * "single point of failure" - plati *pouze* tehdy, kdyz by nebyly nasazeny zadne repliky, coz nechceme
• - dalsi bezici sluzba
• - jine prikazy na pridavani uzivatelu
• - o malo vetsi load (minimalne, protoze nscd a repliky)

Co si o tom myslite? Uniklo mi neco?

       

Komentáře

[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.