AD alapú belépés SSSD-vel

 ( hnsz2002 | 2019. június 1., szombat - 18:29 )

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? :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

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

es nss infoja honnan lesz?

SSSD-t be lehet állítani, hogy LDAP-ból olvassa ki a szükséges információkat, de javíts ki ha tévedek.

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/sambaxp2015-wed-track1-David_Holder-DeployingIPv6OnlySamba4Environments.pdf)

Szerk.: typo javítva

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

Natív IPv6 - A gépek legalább fele kiesett... És akkor ez még azt hiszem jó arány (az IPv6 arányát tekintve; bár én mindig is IPv6 buzi voltam :))
--
"Sose a gép a hülye."

+1 az IPA-nak, vegyes környezetben, ha a Windows-os AD-ben vannak az userek, akkor trust, oszt' jónapot :-)

IPA +1

Köszönöm, ez tűnik a legjobb megoldásnak, úgyhogy ez irányba fogok indulni, ha lesz egy kis időm. :D
--
"Sose a gép a hülye."

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_sambaxp2019_default_directory.pdf

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

Viszont sudo rule-okat meg HBAC-ot nem biztos, hogy fogsz tudni vele csinálni. (Jó, HBAC talán, hostonként bejelentkezhet_ide csoportokkal kireszelhető...)

A Kerberos ugyan legacy, meg igencsak nem mai "gyerek"', de na'on jó dolog...

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.

Mindent elérünk VPN-nel, nem azzal van probléma, hanem a userek kezelésével.
--
"Sose a gép a hülye."

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

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.

+1.

+1. Én is ugyanezt írtam, de a topicnyitó nem értette az aggályomat. Sebaj.

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

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

Azért ez így nem teljesen igaz.

Ha tesz elé egy Apache+WeDav+TLS, akkor nem probléma :)

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. :)

Apache+WebDav+TLS + cert-auth only

Igy nincs direktbe kirakva a Samba, és csak megfelelő cert-el auth-ol, persze kliensenként egyedi cert.

És ebből hogy lesz IdP?

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

+1
azert publicba sambat kitenni, olyan, mikor AD-t raksz publicba. Mindegyik belso halora valo. ennyi. sssd+ldaps meg ok, ha a szerverek nem public IP-n lognak.
nalunk a szerverek elott bigip is, de az a burzsoa kategoria...