linux "tartomány"

Linux-kezdő

Sziasztok!

Egy egyszerűbb windows tartományhoz hasonló rendszert szeretnék létrehozni, egy ubuntu szerverrel és pár ubuntu klienssel. Extra dolgok nem kellenének, csak a bejelentkezési hitelesítés a szerveren menjen.
Merre induljak?

  • 11727 megtekintés

( SzBlackY | 2013. 05. 08., sze – 11:48 )

LDAP, Kerberos, Samba4+linuxokon winbind, NIS... van egy-két megoldás :)

Ha később Windows kliensek is lehetnek, akkor samba, egyébként meg ahogy érzed, akár sajátot is csinálhatsz (kell egy PAM modul és egy nss modul hozzá)

BlackY
ui.: Talán a legegyszerűbb, ha próbaképp egy virtuális környezetben csinálsz magadnak egy demó cuccot valami rendszerrel, ami out-of-box támogatja ezeket (openSUSE, CentOS), aztán megnézed, hogy milyen konfigokat csinált a grafikus beállító

Igen, erre gondolok. Elkezdtem beleásni magam, de más sürgősebb tennivalók picit visszafogtak az utóbbi időben, így csak a számomra (majd) fontos néhány funkciót próbálgattam - pl. azt, hogy gipszjakab melyik IPA-ból authentikáló szerveren milyen szolgáltatásokat használhat, windows-os kliensről hogyan megy a kerberos-os, ssh-kulcsos, illetve jelszó-alapú azonosítás - egyelőre úgy néz ki, hogy jó - lenne az egész, ha lenne magyar felülete is, mert sajna az is kell... Valahol belefutottam egy fordítós oldalba, ahol lehet önkéntesen fordítani ezt-azt, köztük a freeipa-t is, de eddig még nulla lefordított string állapotban van - időm meg nem nagyon van rá jelenleg...

( djsmiley v | 2013. 05. 08., sze – 12:21 )

Zentyal3 kell neked.

Egyébként ha Linux szerver - Linux kliens, akkor NIS a megoldás, de egy Out-of-the-box megoldás a legjobb, ezért javaslom a Zentyalt, it just works :)

Noha amúgy egyetértek, fogalmazzuk meg úgy: amikor és amire kitalálták, akkor és arra jó:

- flat namespace, már pár száz gép esetén se jó ötlet, pedig a NIS ott még pont jó lenne
- delegálhatóság hiánya -"-
- UNIX(-like) OS-eket feltételez
- megbízható lokális hálózatot feltételez
- mintha rémlene valami skálázódási probléma is vele

Ebből az igazi fő baj a 4. pont. Amúgy én is szeretem, mert tényleg faék egyszerűségű de eljárt felette az idő. Kicsit olyan, mint egy NFS v3, egy ideiglenes eléréshez még mindig sokkal könnyebb belőni (itt egy exportfs, ott egy mount, oszt jónapot), mint Samba-t, de a világ a Samba irányába megy.

Ott a pont. A "szarul van kitalálva" számomra sem azonos az "eljárt felette az idő" kitétellel. A megbízható lokális hálózat problémája is kezelhető - látott már a világ kritikus rendszeren kötelezően telnet-et használó alkalmazást... (Szerver: HP-UX, és az app igényei miatt /etc/shadow sem volt).

Értsd jól!
Amikor kitalálták, még nem volt fontos a security.
Aztán amikor rájöttek, hogy mégsem jó ez így, jött a NIS+. Na azt meg senki sem használta. Biztos azért, mert az is jól sikerült.
A NIS-t már 10 éve sem ajánlotta a SUN, 2013-ra már tényleg kihalhatott volna.

Az, hogy "szarul van kitalálva" az egyféleképp érthető. A NIS+ jobb volt, de a vegyes PC-s/UNIX-os környezetek terjedése miatt nem terjedt el, a PC-s világ meg hozott jobbat, okosabbat, szebbet :-P
Egyébként a "minden fájl" elv is szarul van kitalálva a mai világfelfogás szerint, az is igazán kipusztulhatott volna :-D

A NIS+ a NIS egyetlen előnyét, hogy egyszerű volt beállítani, ölte meg...ezért nem használta senki.
Az egyszeri(ű) Unix adminoknak kellett valami, amivel tudtak központi useradatbázist csinálni, hogy ez mennyire biztonságos, a 90%-át nem érdekelte (most sem igazán szokta...), úgyhogy erre valóban jó volt a NIS. Egyszerű rendszer egyszerű embereknek.

Én biztos ráengedném az LDAP-ot, SSL/TLS-el, ha rajtam múlna, hogy mit kell választani. Számomra nem szívás a beállítása az LDAP kliensnek. A lusta/nemtörődöm/felkészületlen admin nyilván a NIS-t fogja választani.

A NIS-t kb. a WEP-pel tenném egy kategóriába security terén...pedig ez utóbbit is okos emberek találták ki.

Apró különbség a web és a nis között, hogy az utóbbi alá lehet gyakorlatilag teljesen zárt rendszert rakni, olyat, amihez harmadik fél nem férhet hozzá, illetve amelynél a hozzáférési kísérletek detektálása és az ellenük való aktív védekezés adott. A rendszer _egy_ komponense önmagában nem teszi az egészet sérülékennyé, ezt nagyon sokszor el szokás felejteni. Példának okáért egy adatgyűjtő PC-n, ami időnként modemen keresztül továbbítja a gyűjtött adatokat, és a fizikai hozzáférésre csak korlátozottan és dokumentáltan van lehetőség, van-e szükség szigorú jelszópolicy használatára?

Nem beágyazott rendszerről beszéltem - amikor a NIS-t kitalálták, akkor azok az eszközök kifejezetten célrendszereket futtattak... Az, hogy egy tetszőlegesen kiherélt libc-ben mi van meg és mi nincs, az fejlesztői döntés, ezek az embedded cuccok nem valók ilyen környezetbe, ez csak és kizárólag ennyit jelent.

Gondolom telnet-et, meg crypt()-tel titkosított jelszót a passwd fájlba se. Mégis láttam olyan igen-igen kritikus és fontos rendszert pár éve, ahol biza' a userek telnettel mentek be a gépre, és shadow fájlt nem használt a rendszer - mert az azt "magával hozó" komponenssel nem volt garantált az adott kiszolgálón futó üzleti alkalmazás működése.

te hogy man-in-the middle-ned a NIS?
azt irod, hogy latszanak a pw hash-ak, feltetelezhetoleg a halora gondolsz. Na, ha LDAP-t hasznalsz ott meg clear text-ben latszik minden, ezert kell hozza az SSL vagz TLS amit viszont nem mindenhol tudsz eletre hivni.
Vannak regebbi rendszerek amik hash-t varnak az SSL/TLS esetleg Kerberos helyett.
Eloszor en is azt akartam, de donteni kellett. Vagy valami user managemented ami mukodik es kesobb tudod reszelni/lecserelni vagy radszakad az egesz.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

Hat ha nem is Mitm-nek mondanam, de emlekeim szerint kb. annyibol all a dolog, hogy megkerdezem egy kedves, joszandeku kollegat, hogy

- "Bocs, mit is kell beallitani domain-nek ahhoz, hogy mukodjon a $RANDOM_HALOZATI_ALKALMAZAS? Lekerdezni ugy kell, hogy kiadod parameterek nelkul a ``domainname'' parancsot."

Es innentol a kezemben van a NIS-domainname, altalaban innentol kezdve maris csatlakozhatok a NIS-szerverre, merthogy a ypbind-nak meg megmondhatom, hogy ki a szervere, azaz kihez csatlakozzon. (Igen, tudom, hogy ez a domainname parancs nem az amire O gondol ,de nekem ez pont jo.)

Ez nem igaz. A nis serveren megmondod h ezek a serverek plus csak oket engedsz tuzfallal replikalni. Akar macre is szurve. Es igaz h tan ez a max amit tud a nis.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

Hogy man-in-the-middle-zöl?
A NIS kliens és szerver közt semmi hitelesítés, shared secret, egyéb dolog nincs, csak a domain név, elég, ha valahogy ráveszed a klienst, hogy a te "fake" NIS szerveredhez csatlakozzon. Különösen jó, ha az ypbind a broadcast opcióval fut, akkor még az ARP-t vagy DNS-t se kell hekkelni.

Amúgy régebben még az ypcat shadow.byname is működött bárkinek...

Nem biztos... Normális esetben minden érzékeny adatokat továbbító hálózatnak képesnek kéne lennie detektálnia és megakadályoznia az illetéktelen hozzáférést - egy 5-10 gépes oktatóteremben pl. nem biztos, hogy ez célja a hálózatnak - viszont az egységes namespace jól jöhet ott is.

Na jó, meg lettem győzve...ha legközelebb ilyen melóm lesz, dehogy fogok én openldappal szenvedni, előveszem ezt a jól bevált NIS-t, aztán hadd szóljon :D Végül is a userek 99%-a nem hekker, nem fogja más jelszóhasheit törögetni, meg fake NIS szervert beállítani az amúgy is szuperül levédett hálózatba :)

Már úgy érzem, hogy olyan dolgon vitatkozunk, hogy otthon miért nem olajkályhával fűtök, annak is megvoltak az előnyei...meg a Win3.1-nek is, az is egyszerű volt...na mind1, részemről a téma zárva.

Hálózatosként és Linuxosként állítom: a szerverek közötti védett hálózat használata egyébként is megkerülhetetlen, akár tűzfallal, vlanokkal. Sokkal inkább a mac filtert választanám a switchen + talán még egy Radius, mint LDAP+TLS. Ha már választani kell a kettő között. Bár egyik se ér semmit, ha valaki fizikailag bent van a szervereknél.
--
#conf t
#int world
#no shut

??? Nem ypserv, hanem ypbind szerepelt, ez pedig a kliens oldalon van. Nem replikálni (szervert hamisítani) akarok, hanem lekérdezni információt a szervertől, aki pedig általában a legcsekélyebb ellenőrzés nélkül ideadja nekem k123b user adatait, amikor kedves felhasználó be szeretne jelentkezni.

+egy még valami. NIS authentikálom a userem de igazából ssh-t használok akkor még is csak titkosított.
+ kulcsos auth fut nem passw. amikor passw akkor nincs NIS.
A hálózatra meg tényleg nem dughatja rá akárki a gépét. Oké, ha betörtnek de akkor már betörtek....
van még vlami érv?

és igen, összességében az LDAP rugalmasabb, skálázhatóbb és jobban bővíthető + menedzselhető.
de 2 drb usernek.... :( nem hiszem hogy kell.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

A barlang is egyszerűbb, mint a téglaház, én mégse laknék benne...
A NIS egy elavult szar, már akkor se volt jó, amikor kitalálták. A jelszóellenőrzés kliensoldalon történik, amúgy meg az összes jelszóhash bárki számára elérhető.
A flat fileokban tárolt adatok skálázhatósága = 0.
Én inkább "cumizok" az LDAP-pal. Az NFS nem tudom, hogy jön ide, az egy hálózati fájlrendszer.

LDAP(s) tuti biztonságosabb, jobban is van implementálva. RedHat alatt meg baromi egyszerű is belőni.
Egyszerűség kedvéért simán lehet NIS-el csinálni ezt.
NFS úgy jön ide, hogy ha már van egy auth szerver, akkor gondolom valami központi "storage" féle is kellene (bár nem szerepelt a kiírásban), és arra meg ez a megoldás, mert szerintem smbmount v. cifs az nem megfelelő.

Btw. LTSP-t én is LDAP-al üzemeltetek, pam-ldap-ot pl. Debian alatt jól beállítani sokkal nagyobb cumizás, mint a NIS-t. Persze azon nem akarok veled összeveszni, hogy az LDAP-os megoldás jobb-e, mert egyetértek abban, hogy jobb.
Zentyal-al még az LDAP szerver rész is pofon egyszerű, a klienseken kell kicsit machinálni, hogy menjen és lesz egy jó rendszere a kollégának.

Akkor olyan rendszert kell használni, ahol egyszerű belőni az LDAP-ot :) NIS-t meg elfelejteni örökre...
Bár emlékeim szerint az nss_ldap install debconf-on keresztül végigkérdezi az ldap paramétereket, úgyhogy az sem lehet olyan nagy kihívás.
Az NFS amúgy a másik kedvencem auth szempontból, lévén az AUTH_SYS az minden, csak nem authentikálás. Az milyen már, hogy a kliens azt mondja, hogy én vagyok Jóska, a szerver meg csak úgy elhiszi, kérdés nélkül?

Idáig oké, csak NFS helyett Linuxok között mit használnál? :) Nagyon jobb ötletem nincsen, el lehet menni brutál irányba pl. AFS, meg társai, de az már szerintem erre az ágyú és a veréb esete.
Az nss_ldap valóban végigkérdezi és odáig oké is, out-of-the box megy is. A pam_ldap a szívatós, authentikációhoz meg az is szükségeltetik. PAM nélkül meg hááát khm :)

( Anmage | 2013. 05. 08., sze – 12:55 )

A zentyalt-t ismerem, virtualboxban már próbálkoztam is vele, tényleg teljesen jó és egyszerű, de a már belakott ubuntu szervert szeretném használni. Azt hiszem elindulok a samba vonalon, idővel lehet, hogy beléptetem a windowsos klienseket is....

Köszi mindenkinek a segítséget.

Két Samba nemigen lehet egy gépen. A portok ütköznének.
Hogy a meglévő smb.conf-ot integrálja-e azt nem hinném. De ha elmented, annak a beállításait az admin felületen biztosan jó közelítéssel be tudod állítani!
És ugyanez vonatkozik az Apache-ra is, meg a Squid-re is.
Itt kattintgatva és paramétereket megadva elég jól lehet beállítani a dolgokat.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ha valaki még nem látott smb4-et, akkor fogalma sem lesz arról h. mi az h. "domain provision".
Ha nem most akarja megtanulni, akkor jobb ha használ kész megoldást. Ha meg bele akarja ásni magát, akkor majd megnézi h. mi a helyzet.
MMC -vel meg manageld lécci a DHCP-t, DNS-t, stb. Ezért Zentyal.

Véleményem. :) Ha gyorsan akarod összerakni, ne gondolkodj, a meglévő rendszeredre tegyél fel egy Zentyal-t (előtte biztonsági image mentés, ha bármit elszúrsz, vissza tudd állítani), minimális IT rutinnal is be fogod tudni konfigolni, tényleg csak kattintgatnod kell.
(és ha már felpakoltál egy szervert, meg a néhány kliensed és ezeket összelógattad, akkor ez a rutinod megvan)
Ha van sok időd a feladatra, tanulni akarsz, meg akarod érteni mélyebben a folyamatokat, akkor meg ess neki és darabokból építsd fel a rendszered. Jó és izgalmas időtöltés, aminek az ára az idő.
Jó munkát.

( palotti | 2013. 05. 10., p – 09:39 )

Épp hasonlót csináltam, csak debianos kliens környezetben. A következő a tapasztalat:
free-ipa:
jó megoldás, de nem feltétlen debianos környezetben (ubuntu alatt van kliens, de nem a legstabilabb), komplex rendszer, nem csak authentikációra (authorizáció, dns), viszont HA építés problémás. Debian kliens esetén a squeeze alatti sssd nagyon régi, wheezy változat rebuild után ok, viszont készülj sok csomag rebuildjére (10+).

openidm:
szintén nehézsúlyú versenyző, elég komplex

openldap + sssd:
egyszerű, jól konfigurálható debian környezetben is, ami nagy előnye a cache

openldap + nssldapd:
egyszerű, jól konfigurálható debian környezetben is, elérhető a cache, sudo support esetén vagy sudo vagy sudo-ldap, nem cachelhető, viszont a debianos változatban sudo-ldap esetén nincs sudoers file, sudo esetén meg ldap support, ami szopóca lehet. megoldás: sudo rebuild --with-ldap opcióval. Cache akkor sincs, de legalább a local user tud sudozni.

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

( jupiter2005ster v | 2013. 05. 16., cs – 22:43 )

+egy még valami. NIS authentikálom a userem de igazából ssh-t használok akkor még is csak titkosított.
+ kulcsos auth fut nem passw. amikor passw akkor nincs NIS.
A hálózatra meg tényleg nem dughatja rá akárki a gépét. Oké, ha betörtnek de akkor már betörtek....
van még vlami érv?

és igen, összességében az LDAP rugalmasabb, skálázhatóbb és jobban bővíthető + menedzselhető.
de 2 drb usernek.... :( nem hiszem hogy kell.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/