Sziasztok,
Ennek a posztnak nem problémamegoldás a célja,
csupán szeretném megérteni hogy Linuxon ez általában hogyan működik (és így kellene-e jól működnie ahogy nálunk megy).
Adottak RedHat VM-ek, [nagyon]nagyvállalati környezetben, amiben én csak end-user vagyok.
A gépekhez a CyberARK megoldásnál keresztül, lényegében egy jumpserver ahol egy generált account-ot kapok a session-ben.
Technikai userek hozzéférését kezelése egy külön fejlesztett rendszeren keresztül lehet rendelni, ezek képesek jumpserver nélkül is SSH session-t nyitni,
viszont sudo nem érhető el a számukra.
Systemd service-t szeretnék egy AD user nevében futtatni, igényeltem neki hozzáférést, futik is.
Jelszót nem kért és itt kezdtem el gondolkodni hogy ez technikailag hogyan lehet megoldva?
SU-val kontextust tudok váltani a technikai userre, de érdekes módon működik olyan userre is, amire biztosan nem kértem hozzáférést.
Hogyan működik az impersonation AD userekkel Linuxon általában?
Miért enged user context-et váltani jelszó nélkül? (mi történik ilyenkor a motorháztető alatt?)
(/etc/passwd-ben nincsenek userek, realm csomag nincs telepítve, nem tudom hogyan megy az AD integráció)
Hozzászólások
Az AD userekkel pont ugyanúgy működik mint sima local userekkel, ilyen szempontból nincs különbség. Az AD usereke meg RHEL-en SSSD-ne keresztül jönnek.
Domain, tárhely és webes megoldások: aWh
Ez azt jelenti hogy amikor su-zok vagy elinditok egy systemd service az AD user nevében, akkor- Windowsal ellentétben - tényleges authentikáció nem történik az AD felé?
Ha su/sudo van, akkor ugyanúgy kell jelszót ellenőrizni, úgyhogy az AD-t megkérdezi az sssd (hacsak nincs a cache-ben credential, ekkor csak a jelszó módosításának az idejét próbálja meg lekérni, ha minden igaz), ha a sudoers-ben nopasswd van, akkor a sudo nem fog jelszóellenőrzést csináltatni. A service/unit az uid=0 -> uid=tetszőleges átmenetet csinál, úgyhogy ott nincs auth.
Szia,
a CA-nak tobb funkcioja is letezik. A kepernyofelveteltol a jelszo szefekig.. A CA helyes telepites eseten Windows es Linux oldalon is egy nagyjabol virtualis proxy-n keresztul auth-ol a target gepekre. Nagyvallalati kornyzetben kb van egy felhasznalod, amely arra van feljogositva, hogy belepj a DESKTOP-ra majd ezzel ki tudod olvasni szerver oldali masik felhasznalo a jelszavat, be tudjal lepni vele anelkul, hogy tudnad a felhasznalo jelszavat szerver oldalra. Beallitott szabalyok szerint idokozonkent a jelszavak lecserelodnek.
Amikor már bent vagyok a gépen és SU-zok egy AD felhasználóra, akkor szerintem a CA már nem kerül képbe (de ebben nem vagyok teljesen biztos).
Az adott gépen az authentikációt mi és min keresztül csinálja? Mert halovány különbségek azért lehetnek a samba/sssd/pbis/satöbbi használatánál abban, hogy a sudoers-ben mit és hogyan, illetve a pam oldalon is vannak taposóaknák itt-ott... (pl. lokális usernek a jelszócseréje nem működik bizonyos konstellációban)
Nincs dokumentáció róla, SSSD nekem teljesen új dolog, meg fogom nézni.
Az sssd jó dolog, volt, ahol FreeIPA (kerberos), volt, ahol sima, mezei AD volt mögötte, és (ha csak nem ment tele a /var fájlrendszer...), akkor teljesen jól működött/működik. (Ha a /var tele van, akkor nem megy csak olyan userrel (vagy olyannal se...) a login, akinek még a credential cache-ben ott van az adata, úgyhogy AD/IPA backend esetére mindenképp javasolt (erősen...) egy lokális, borítékos jelszavas user...
Akár sssd, akár pbis, a sudoers simán megeszi az "%adgroup" -ot,mint csoportot. Ha az sssd.conf-ban use_fully_qualified_names = False, akkor a login és a sudoers is csak a usernevet igényli @domain nélkül, ha True, akkor mindkét esetben ad_usernev@domain forma kell.
"Systemd service-t szeretnék egy AD user nevében futtatni" - A nevében futtatni (ez a unit-ban megadható), vagy systemctl start/stop/restart service parancsot kiadni? Ez utóbbi sudoers pimpeléssel megy.
Unitban megadva szépen működik, pusztán azt nem értem hogy jelszó bekérése nélkül hogyan és miért. :)
nagyon leegyszerűsítve a systemd (UID=0) processzként tetszőleges UID-del tud processzt létrehozni.
De akkor ennek az UID-nak nincs köze az AD-hoz, Kerberos ticket nem jön létre csupán egy virtuális lokális userrel fut a service?
A systemd - kerberos "párosítást" még nem néztem, de alapesetben nincs service-hez rendelt ticket. A szolgáltatás nem "virtuális lokális userrel" fut, hanem azzal az UID-del, amit az adott AD-s userhez hozzárendelt az sssd. És mivel a service indulása során "csak" egy UID=0 -> UID=ad-s_user_uid-je váltás történik, ez a DC-n nem fog megjelenni, mint user tevékenység/login.
Az AD -ba fel lehet venni a user publikus SSH kulcsat. Bejelentkezeskor ha be van toltve pl. a Putty Agent -be a privat kulcs, akkor az sshd es az sssd kooperaciojakent az sssd letolti az AD -bol (sima LDAP-on keresztul) a publikus kulcsot, amit utana az sshd ellenoriz a szokott modon, vagyis nincs jelszo begepeles.
Ha a user AD csoportja szerepel a sudoers -ben, akkor az ott levo parancsokat (vagy barmit ha *) ujabb auth nelkul le tudja futtatni, peldaul at tud alakulni mas felhasznalova.
Nem ismerem sem az infratokat, sem a CyberArk -ot, de ha ez utobbi general kulcsokat, aminek a publikus reszet felnyomja az AD-ba, a privatot pedig betolti a sessionhoz tartozo agentbe, akkor ezzel szamodra transzparensen megoldja a (kulcsos) autentikaciot es elkeruli a tovabbi interaktiv, begepelos authentikaciokat.
De ez csak egy tipp, nem ismerem a CyberArkot, ez csak az a modszer, amit en csinalnek a helyeben. :-)