AD alapú belépés SSSD-vel

Linux-haladó

Az alap szituáció az, hogy egymástól teljesen független ügyfeleknek, cégeknek üzemeltetünk különböző rendszereket. Viszont mindenhova be kell lépkednünk, és a helyileg kezelt userek macerásak. Jelenleg csak a linuxokon gondolkozok, szerencsére ez van több, windows-zal szerintem ez nem is nagyon kivitelezhető.

Az egyszerűbb és gyorsabb jogosultságkezelés érdekében gondolkozok azon, hogy lenne egy központi AD (linux, samba4), ahol fel lennének véve a saját felhasználóink, illetve különböző csoportok, aminek tagjaként mondjuk egy-egy szerverre be tudsz lépni, vagy épp tudsz azon sudozni.

Az AD-ból autentikáció SSSD-vel menne. A kérdés a szükséges portok elérése... LDAPS, Kerberos, stb.. Mennyire secure kitenni public-ba egy sambát? Természetesen csak TLS-sel lenne elérhető, de akkor is... Vagy a másik megoldás, hogy a samba dc-knél egy belső hálót alakítunk ki, amit mondjuk openvpn-nel éri el minden gép. Ez ugye plusz konfig, plusz egy kapcsolat, macerásabb telepíteni, nő a hibalehetőség, stb.

Csinált-e már valaki hasonlót? Láttok benne fantáziát, vagy teljesen agyament? :)

  • 2540 megtekintés

( n.balazs v | 2019. 06. 01., szo – 19:13 )

Első körben a leírás alapján nekem biztonsági aggályaim lennének ügyfél oldalról. Nem érzem biztonságosnak a fenti megvalósítást. Mi történik akkor, ha a nálad lévő linux+samba4 rendszert megtörik? Akkor az összes ügyfelet megtörték.

A "szerverre be tudsz lépni, tudsz sudozni"-hoz nem elég, ha kulcsos authot használtok?
A normál Windows AD esetén a kulcsszó: trust. :) Nem tudom, hogy a samba4 tud-e ilyet, mennyire lehet ezt beállítani ott.

Az üzemeltetés egy veszélyes szakma... :)
Kulcsos authot használunk, de ugyanúgy létre kell hozni minden szerveren.
[szerk] Egyébként egy google authenticator pam modult berakni utána sem vészes (most probáltam ki, 5 perc volt az egész), és sokat dob a securityn.
--
"Sose a gép a hülye."

( zoldnap | 2019. 06. 02., v – 15:31 )

Szerintem definiáld jobban a problémát, mert egy nagyon bonyolult rendszert szeretnél kiépíteni, ahelyett, hogy pár (?) helyi usert létre kelljen hozni..

Ha az egyetlen dolog amit meg akarsz valósítani, hogy távoli user management legyen linuxos rendszerek esetén, akkor több PAM modul közül is válogathatsz, ami LDAP-ból vagy Radiusból authentikál. Ebben az esetben helyi usert nem kell létrehozz a passwd fájlban, mindent a PAM modul intéz.

Az AD egy nagy rakat legacy protokol ötvözete (Kerberos és társai), amit akkor van értelme használni, ha a tényleges AD funkciókat használod (file share, group policy, stb.).

Igen, de ez készen van, egyben van, meg van oldva a kezelése, szinkronizációja... Na és mi van akkor, ha nem minden egyes szolgáltatása lesz használva? Semmi.
Plusz, ha Windows-okat is hozzá akarsz csapni majd, akkor nem nagyon van más lehetőséged, mert oda nem tudsz tetszőleges modult belehekkelni.
--
"Sose a gép a hülye."

A FreeIPA pont ennyire kész van (sőt, ott még sudo rule-okat és ssh kulcsok kezelését is kapod, Linux szervereknél jól jön)...

Egyébként többé-kevésbé "hivatalos" ajánlás pár évvel ezelőttről a Samba team-től (hivatalos ajánlás úgyis, mint "kipróbáltuk, és csak kicsit volt retek bug-os" :) ): tisztán, natív IPv6 felett IPsec-kel védve akár ki is lehet tenni publicba, hogy ne kelljen VPN-nel játszani. (forrás: https://sambaxp.org/archive_data/SambaXP2015-SLIDES/wed/track1/sambaxp2…)

Szerk.: typo javítva

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Rövid frissítés: a legutóbbi SambaXP konf szerint egy kis LDAP séma bővítéssel és pár sor SSSD konfiggal AD-ból is lehet ssh kulcsokat kukázni: https://sambaxp.org/fileadmin/user_upload/sambaxp2019-slides/brown_samb…

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( zeller | 2019. 06. 03., h – 01:10 )

Alapvetően a felhasnzálók kezelése az adott üf. rendszerében _kell_ hogy történjen, ha tetszik, ha nem. Ezzel magadat is, és az üf. rendszereit is véded, illetve minden üf. külön független entitás marad.
Amit lehet csinálni, az minden üf.-hez egy ugrógépet odarakni, ami egyik "lábbal" vpn-en bent lóg a ti rendszeretekben, a másik lábbal meg "rálát" az üf. meghatározott gépeire. Ezeknek az ugrógépeknek az usereit ti kezelitek, de akár sssd-vel lehet "keverni" a local, a saját IPA meg az üf. oldai AD-ból történő authentikációt is - igény szerint.

Igen a userek kezelesevel van a problema az elgondolasodban.
Ha tegyuk fel nekem mint ugyfelednek eloadnad ezt hogy legyen nalad egy kozponti rendszer es authentikaljanak az en mint ugyfel rendszereim, egy olyan kozponti rendszerbol ami nem nalam van, nem ferek hozza, nem latok ra hogy kinek es milyen jogosultsagok vannak benne beallitva es mindezt azert mert neked kicsit kenyelmetlen kezelni a szamodra adott hozzaferest akkor azzal a lendulettel bontanam fel veled a szerzodest.

+1 Ezt próbáltam finoman előadni én is. Még ha az üf. kap megfelelő jogosultságot a supportos társulat jogkezelő rendszerében (jóváhagyó, lekérdező) sem vállalható 100%-ban a dolog.
Egyébként jóváhagyói szerepkörben mindenképp be kell vonni az ügyfelet a hozzáférések kezelésébe, hiszen jobb helyen a vpn-jogosultságot is személyre szólóan kell kiosztani, illetve az adatgazdának tudnia kell, hogy adott időpontban ki és milyen megállapodás alapján mihez férhet hozzá.

( snitt_ | 2019. 06. 03., h – 11:45 )

Uramisten, ez az elgondolás.

Melyik cég is vagy(tok)?

Disclaimer: raktam már össze SSSD-t mind AD-ból vett SSH kulcsos, mind AD-s jelszavas autentikációhoz 100 fölötti szerver számossághoz, de az OP ötlete ebben a jogi és üzemeltetési környezetben nagyon, nagyon rossz.

De hogy konstruktív is legyek: user felvételhez/törléshez ansiblet, autentikációhoz AuthorizedKeysCommand sshd-opció kreatív használatát javaslom.

( uid_395 v | 2019. 06. 03., h – 19:38 )

"Mennyire secure kitenni public-ba egy sambát?"

semennyire .... mind1 milyen auth van előtte, itt meg is bukott az egész.

ja, meg egy VPN-t, meg két tűzfalat + IP korlátozást, stb, akkor mehet a "samba publicba" :)

A samba public az nekem azt takarja itt, hogy van egy samba szerver, ami hallgatózik a világ fele minden féle védelem nélkül. (a 2F authot + egyebeket most ne hozzuk ide) . Remek kipublikálni. :) Volt már ilyen ... khm... kolléga aki kipublikálta a sambát a világ felé és tádám, megtörték. Ezért nem javaslom a Sambát publicra. :)

( hnsz2002 v | 2019. 10. 25., p – 14:30 )

Kezd éledezni a kis setup... Eddig minden szuper, jó. Csak egy probléma van.
IPA-sok: oszt' az úgy jól van, hogy ha a base dn-t tudod, akkor auth és kerberos ticket nélkül nélkül kb. mindent (pár mező kivételével) le lehet kérdezni az LDAP-ból?
--
"Sose a gép a hülye."

Az IPA egy tree-ben tárol mindent - én csináltam olyan webes frontendet hozzá (Perl rulz :-) ), hogy adott admin user csak a vele azonos csoportba tartozó felhasználókat látta, őket tudta pátyolgatni, illetve a saját elsődleges csoportjába tudott usereket felvenni, illetve letiltani/"törölni" - ez utóbbi olyan letiltást jelentett, amivel a saját csoportjából ki lett véve az adott user, ami után az adott partner adminja már nem látta, csak mi az ipa eredeti felületén.

https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/disab…

(szerk.: na, az új felület miatt állhatok neki leküzdeni az izomreflexem, hogy "Enter-Enter-BlackY"-vel zárom a hozzászólásaim, mert ez így üres bekezdést szúr be :( )

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)