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ó)
- 403 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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é?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Nincs dokumentáció róla, SSSD nekem teljesen új dolog, meg fogom nézni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Unitban megadva szépen működik, pusztán azt nem értem hogy jelszó bekérése nélkül hogyan és miért. :)
- A hozzászóláshoz be kell jelentkezni
nagyon leegyszerűsítve a systemd (UID=0) processzként tetszőleges UID-del tud processzt létrehozni.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :-)
- A hozzászóláshoz be kell jelentkezni