Linux + NFSv4 + Kerberos

Linux-haladó

Szep napot mindenkinek.

van egy olyan gondom, hogy ezutan a parancs utan

mount -o minorversion=1,sec=krb5 psrec-vsanfs-01.psrec.ps.projects.testdomain.com:/vsanfs/testnfsshare /mnt/test_nfs/

ezt kapom (RHEL8):

[root@rhel-nfs-cli mnt]# ll
total 0
drwxrwxrwx. 4 nobody root 0 Oct  5 13:19 test_nfs
 

Magyarul "nobody"-t kap a dir az AD user helyett, ami "testuser" lenne. A share VMWARE fileshare-bol jon.

Mi hianyzik itt?  A cel az lenne, hogy ha ezen a share-en letrehozok egy file-t akkor az a belepett user neveben legyen.

De jelenleg "nobody" minden:

[root@rhel-nfs-cli test_nfs]# ll
total 0
-rw-r--r--. 1 nobody nobody 0 Oct  5 13:19 testfile2.reader
-rw-r--r--. 1 nobody nobody 0 Oct  5 12:08 testfile.reader
 

  • 973 megtekintés

( Zsugabubus | 2023. 10. 11., sze – 09:09 )

Biztos nfs4 (3 is tudott kerberost)?

idmapd-ben a domain megegyezik a szerverével?

( Tom | 2023. 10. 11., sze – 10:35 )

nincs esetleg "all_squash" az export oldalon, vagy esetleg "root_squash" ?

a promptok végén # van, esetleg emiatt nem hozza amit vársz?

hogy csak a root tud mountolni, az tiszta, de ha root-ként hozol létre fájlt (ez ugye nem látszik, csak feltételezem abból hogy mindenhol root prompt van) akkor az sose lesz tesztuser3.

ha müködött korábban, akkor is csak sejteni lehet, az all_squash ill a root_squash csinálja hogy nobody lesz, illetve ha a usernek esetleg nincs kerberos ticketje.

ez a müködött korábban egy igen gyakran használt kulcsszó, nálunk sokszor kiderül hogy korábban se müködött amihez próbálják hozzáfüzni, de ez most mellékkes.

ha nem változtattál semmit és a masik oldal sem változott, továbbá ugyanonnan probálod ugyanazt elérni ugyanazzal a beállítással akkor a végeredmény ugyanaz kell hogy legyen, kivéve ha nem tudsz arról hogy valaki más is bütykölte, mert akkor már nem ugyanaz és nem ugyanazt a végeredmény kapod.

azt is implicit feltételeztem hogy a kerberos be van állítva a szerveren és a usernek van ticketje is.

A fileok nem root-kent lettek letrehozva, csak ugy listaztam oket. (Beleptem a fs-reader neveben es ugy hoztam letre a file a share-en)

Mint lathato a fileok jogosultsagain, ez "nobody", azaz a rendszer tudta, hogy nem lokalis user-ekrol van szo.

A kerberos ticket kerdes egy jo kerdes. Mi a legjobb szimulacioja ennek? Amit csinaltam, beleptem lokalis root-kent a szerverre, majd kertem egy

# kinit admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM

dolgot (ez a user van a szerver oldalon be van allitva a sharehez) , majd listaztam:

[root@rhel-nfs-cli ~]# klist
Ticket cache: KCM:0
Default principal: admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM

ezutam mount-oltam a filerendszert a fent leirt modon.  Jol csinalom a procedurat?

Ha te root vagy, amikor létrehozod a fájlt (bármi is legyen a kerberos ticketben), szerintem az idmap attól még a root usert mappeli, és az megy át a dróton a fájlműveleteknél. Kíváncsi lennék, hogy a túloldalon milyen user lett a tulaj valójában.

Lentebb is írtam, a szerver nem UID-et vissza, hanem nev@domaint. Érdemes lenne esetleg tcpdumppal megnézni, hogy mit is (getattr rpc hívásnál az owner).

De ha egy bármilyen írás nobodyban végződik, akkor engedélyezve van valamilyen guest access, és a kerberos meg nem is működik.

nem gondolom hogy másképp csinálnám.

az még megnézném hogy a user-nek (fs-reader) van-e kerberos tickete, de lassan én is már a buksimat vakarom.

úgy tünik nem tudja az id-t megszerezni és ezért a nobody-ra megy vissza.

amivel én küzdöttem az nem pont nfs, hanem http kerberos auth, ott kellett egy serviceprincipal a userhez: HTTP/host.neve és ezt el kellett tenni egy krb5.keytab fileba. a nfs-nek is kellhet ilyesmi NFS/host.neve (lehet kisbetüvel is) amikor ez megvolt akkor tudott rendesen AD-böl authentikálni.

az nfs cucc elvileg automatikusan hozza kell hogy adodjon, amikor meghivod a mountot/tokent

de sajna ezt meg meg kell neznem ujbol

 

egyebkent ha as fs-reader nem is jon kepbe, akkor is a sima mount utan a dir nem szabadna "nobody" lenni. hanem "admin"

Ha ez egy *nix szerver lenne (a lelke mélyén szerintem az, csak nem férsz hozzá) akkor meg is csinálhatnád kézzel.

Viszont amikor az Appliance-ot beállítod (VMware vSAN) akkor a setup szépen végigvezet a domainba integráláshoz, ahol egy megfelelö jogosultságú Domain Felhasználót kell megadni, ezek után szerintem a szerveren létrehozza a keytabot.

Szerintem a kliens oldalon is kell a NFS kilensnek is egy keytab (/etc/krb5.keytab).

És az sem árt ha a hostok ideje szinkronban van.

Az biztos, hogy kell a kliensen is, de a kinit már működött.

Hogy bele kell-e tenni az nfs service principalt is a keytabba - passz, rég volt.

Most épp ezt találtam gyorsan, hogy kell-e vagy sem:

https://stackoverflow.com/questions/73219365/why-do-we-need-to-add-a-nf…

Időszinkron az alap kerberosban, defaultban max. 5 perc  eltérés lehet.

Egyelore baj van a hozzaadassal: nem tudom inicializalni a kadmin-t

 

[root@rhel-nfs-cli mnt]# kadmin
Authenticating as principal admin/admin@PSREC.PS.TESTDOMAIN:COM with password.
kadmin: Missing parameters in krb5.conf required for kadmin client while initializing kadmin interface
 

...es nem tudok uj principalt hozzaadni...

Pontosan, ha AD van akkor a MS által adott dolgokat kell használni: ktpass.exe, ha keytabot akarsz csinálni

ktpass.exe -princ <principal> -mapuser <aduser> -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL +dumpsalt -out <path to file>\<file name>.keytab

vagy: setspn.exe ha csak Service Principal kell

setspn.exe -s <principal> <aduser>

Listázni is lehet:

setspn.exe -L <aduser>

és persze egy windows amin elérhetöek ezek a parancsok.

gondolom a kadmin is mukodik, miutan autentikalni tud a szerveren..de mivel jelenleg ez nalam meg nem jo, igy az nem hasznalhato

 

egy picit a valaszaitokhoz, csakhogy megertsem (nem vagyok egy nagy Windows guru):

1. itt a cel az lenne, hogy bizonyos service principalokat hozzadajak  a DC-hez, amik engedik az nfs szolgaltatas mapping reszet
    (nfs/.....)..de ezt jelenleg csak a Windows hoszton tudom megtenni a setspn paranccsal?

2. mar van keytab file-om a Redhat alatt, kellene egy ujat generalnom a Windows-ban, majd ramasolnom (felulirnom) a Linuxra?

3. Gondolom itt az "aduser" a fileshare-nek a user-e lenne? Ha ezt hozzaadom a keytabhoz, a kadmin is tud authentikalni es tudok Linux allatt is uj principalokat hozzaadni?

---

A folyamat nem teljesen vilagos nekem, mi miert kell?

Ezt csinaltam egy szuz Linux VM-en (persze elotte az admin@... user letre lett hozva a DC-n, mint domain admin):

[root@rhel-nfs-cli ~]yum install realmd oddjob oddjob-mkhomedir sssd samba-common-tools
[root@rhel-nfs-cli ~]yum install krb5-workstation
[root@rhel-nfs-cli ~]realm join -U admin psrec.ps.projects.testdomain.com

[root@rhel-nfs-cli ~]kinit admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM
password: .......

[root@rhel-nfs-cli ~]# klist -l
Principal name                 Cache name
--------------                 ----------
admin@PSREC.PS.PROJECTS.TES KCM:0
 

-----

Ekkor mar VOLT keytab fileom a rendszeren, ha jol emlexem, gondolom ez a Windows-bol jott.

Ezek utan kellene az NFS integracio.

1. A setpsn windows-on fog menni, de csak olyan gépen ami tagja az AD-nak és fel is van telepítve a csomag az AD-hoz (ha PDC vagy BDC akkor fennt kell legyen, illetve van még az RSAT)

2. A realm join hozta létre a /etc/kerb5.keytab fájlt "host/<gépnév>@REALM tartalommal, a gépnév lehet fqdn, ha be volt állítva a join elött, vagy csak hosztnév ha nem (tévedés joga fenntartva, lehet a realm join még ebben is támogat), lényegében egy számítógép fiókot hoz létre.
Ha nem volt és késöbb be lesz állitva az fqdn, érdemes megnézni a keytabot és hozzáfüzni az fqdn-es principalt a keytabhoz és a számítógép fiókhoz, ha nincs ott, vagy a gépet kidobni az AD-böl és újra belépni vele.

A gond az hogy nem vagy bejelentkezve mindig rootként, mégha rootként futnak induláskor a szervizek indítószktriptjei, valahogy kell tudnia authentikálnia akkor is, erre van a keytab.
Ha valaki/valami már megcsinálta, szuper, nem kell új, csak meg kell nézni hogy benne van-e az aminek benne kell lennie, HOST/<fqdn> vagy NFS/<fqdn>, plusz az ad usernél is ott van-e a service principal.
Továbbá nem kevésbé fontos hogy az ugynevezett "KVNO" ugyanaz legyen mindkét oldalon.

A szolgáltatás ha kell neki az AD akkor megnézi hogy van-e számára megfelelö principal pl NFS, ha nincs megnézi van-e HOST, ha ez sincs akkor nem tudnak beszélgetni.

3. az "aduser" az a felhasználói vagy számítógép fiók amihez a Principalt hozzá akarod rendelni, általában nem az admin-hoz szokták, én az Apache-hoz csináltam saját szerviz felhasználót "svc_http", ehhez rendeltem hozzá a szerverek http principaljait (nincs realm join, a mod_auth_gssapi megoldott mindent, ha jó volt a Principal a keytabban).

Ha a keytabban host/szerver@REALM van, de közben hozzájön a domain is akkor a host/szerver.dom.ain@REALM bejegyzést fogja keresni. A host helyett lehet nfs-is, ha az jobban tetszik (a mod_auth_gssapi követelte nálam a http-t, azóta lehet változott), tudtommal a kisbetü/nagybetü nem számít (de azért nem vésném kőbe és nem futtatnám be arannyal) 

A kinit az adott session-be hoz létre kerberos ticketet, az sehogy nem fog kapcsolódni az nfs szolgáltatáshoz, szerintem.

Egy keytabban több bejegyzés is lehet, viszont ekkor macera frissíteni, ezért nem keverik ide bele pl az apache keytab-ját is, annak külön van.

Ok, kicsit vilagosabb a dolog

jelenleg ez van a DC-n  (nemet nyelvu, nem baj)

 

--------------

CMD> setspn.exe -L psrec-dc-01

Registrierte Dienstprinzipalnamen (SPN) fr CN=PSREC-DC-01,OU=Domain Controllers,DC=psrec,DC=ps,DC=projects,DC=testdomain,DC=com:
    WSMAN/psrec-dc-01
    WSMAN/psrec-dc-01.psrec.ps.projects.testdomain.com
    ldap/PSREC-DC-01/PSREC
    HOST/psrec-dc-01.psrec.ps.projects.testdomain.com/PSREC
    ldap/psrec-dc-01.psrec.ps.projects.testdomain.com/PSREC
    HOST/PSREC-DC-01/PSREC
    Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/psrec-dc-01.psrec.ps.projects.testdomain.com
    ldap/psrec-dc-01.psrec.ps.projects.testdomain.com/ForestDnsZones.psrec.ps.projects.testdomain.com
    ldap/psrec-dc-01.psrec.ps.projects.testdomain.com/DomainDnsZones.psrec.ps.projects.testdomain.com
    TERMSRV/PSREC-DC-01
    TERMSRV/psrec-dc-01.psrec.ps.projects.testdomain.com
    DNS/psrec-dc-01.psrec.ps.projects.testdomain.com
    GC/psrec-dc-01.psrec.ps.projects.testdomain.com/psrec.ps.projects.testdomain.com
    RestrictedKrbHost/psrec-dc-01.psrec.ps.projects.testdomain.com
    RestrictedKrbHost/PSREC-DC-01
    RPC/8c167458-3d47-46ed-9a80-4f30f00ddd7a._msdcs.psrec.ps.projects.testdomain.com
    HOST/PSREC-DC-01
    HOST/psrec-dc-01.psrec.ps.projects.testdomain.com
    HOST/psrec-dc-01.psrec.ps.projects.testdomain.com/psrec.ps.projects.testdomain.com
    E3514235-4B06-11D1-AB04-00C04FC2DCD2/8c167458-3d47-46ed-9a80-4f30f00ddd7a/psrec.ps.projects.testdomain.com
    ldap/8c167458-3d47-46ed-9a80-4f30f00ddd7a._msdcs.psrec.ps.projects.testdomain.com
    ldap/PSREC-DC-01
    ldap/psrec-dc-01.psrec.ps.projects.testdomain.com
    ldap/psrec-dc-01.psrec.ps.projects.testdomain.com/psrec.ps.projects.testdomain.com

------------------

Magyarul, itt kellene hozzaadnom az nfs/... valamit ? Vagy az csak a fileshare appliance-ben jelenik meg?

Egyaltalan mit kell itt meg hozzaadni?

Majd utana hogyan kerul ez at a linux kliensre? kell keytab-ot ujrageneralni?

 

ez van jelenleg a RHEL kliensen:

[root@rhel-nfs-cli ~]# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 RHEL-NFS-CLI$@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 RHEL-NFS-CLI$@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM…
   2 host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM…
   2 RestrictedKrbHost/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 RestrictedKrbHost/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
   2 RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM…
   2 RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM…

[root@rhel-nfs-cli ~]# klist -l
Principal name                 Cache name
--------------                 ----------
admin@PSREC.PS.PROJECTS.TES KCM:0
RHEL-NFS-CLI$@PSREC.PS.PROJECT KCM:0:48320 (Expired)
 

Ez jobb lett volna: (a DC Principaljai a kliensen nem érdekesek)

setpsn.exe -L RHEL-NFS-CLI$

a keytab rendben van, ott van csak host-al és fqdn-el is a principal, a host elötag elvileg elég.

akkor elkezdhetsz tesztelgeni:

# kinit -kt /etc/krb5.keytab host/RHEL-NFS-CLI@PSREC.PS.PROJETS.TESTDOMAIN.COM
# klist -l
# kdestroy

# kinit -kt /etc/krb5.keytab host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOMAIN.COM
# klist -l
# kdestroy

Illetve, csak a biztonság kedvéért kipróbálnám realm nélkül, nem emlékszem teljesen tisztán hogy ilyenkori is hozzáadja-e a REALM-ot automatikusan vagy sem.

Ha az egyik megy, mennie kellene a többinek is, a RestrictedKrbHost-al is megpróbálnám, biztos ami biztos.

Ez a gépi fiók, hogy ennek van-e joga mindenhez amit el akarna végezni az nfs kliens, azt nem tudom, elvileg nem lehet gond, egy próbát megér:

# kinit -kt /etc/krb5.keytab RHEL-NFS-CLI$@PSREC.PS.PROJECTS.TESTDOMAIN.COM
# klist -l
# kdestroy

ha ez mind megy, akkor a baj nem itt van, lehet az idmapd-t kell megnézni hogy nem ott van-e a turpisság.

CMD> setspn.exe -L RHEL-NFS-CLI$
Registrierte Dienstprinzipalnamen (SPN) für CN=RHEL-NFS-CLI,CN=Computers,DC=psrec,DC=ps,DC=projects,DC=testdomain,DC=com:
        RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com
        RestrictedKrbHost/RHEL-NFS-CLI
        host/rhel-nfs-cli.psrec.ps.projects.testdomain.com
        host/RHEL-NFS-CLI

------

ezt a kinit-es tesztelgeto reszt nem teljesen ertettem. Mit kene itt latnunk?

Meg azt, hogy realm nelkul. Hogy erted ezt? ne adjam hozza a domain-t a vegehez?

"...mind megy" alatt mit ertesz?

 

 

Mellesleg:

[root@rhel-nfs-cli ~]# kinit -kt /etc/krb5.keytab host/RHEL-NFS-CLI@PSREC.PS.PROJETS.TESTDOMAIN.COM
kinit: Keytab contains no suitable keys for host/RHEL-NFS-CLI@PSREC.PS.PROJETS.TESTDOMAIN.COM while getting initial credentials
 

A mind alatt azt értem, hogy a klist-ben felsorol összes Principal megy, hiszen mindegyik ugyanarra a felhasználóra mutat, ha megvan a principal a userhez és minden klappol, akkor a többinek is jónak kell lennie.

Az RHEL-NFS-CLI principaljai rendben vannak, viszont a hibaüzenet az jelzi hogy nincs olyan kulcs ami megfelelö titkosítással van elmentve.

# klist -ke /etc/krb5.keytab

mit mutat?

A realm az ami a  @ után van, a domain meg ami a hostnév és a @ között, ha van olyan.

Pl:

host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOMAIN.COM

realm: PSREC.PS.PROJECTS.TESTDOMAIN.COM
domain: psrec.ps.projects.testdomain.com

Illetve még az is érdekes lehet, hogy egy sikeres kinit után mit ad vissza a 'klist -e'

[root@rhel-nfs-cli ~]# klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 RHEL-NFS-CLI$@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes128-cts-hmac-sha1-96)
   2 RHEL-NFS-CLI$@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes256-cts-hmac-sha1-96)
   2 host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes128-cts-hmac-sha1-96)
   2 host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes256-cts-hmac-sha1-96)
   2 host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM… (aes128-cts-hmac-sha1-96)
   2 host/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM… (aes256-cts-hmac-sha1-96)
   2 RestrictedKrbHost/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes128-cts-hmac-sha1-96)
   2 RestrictedKrbHost/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM (aes256-cts-hmac-sha1-96)
   2 RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM… (aes128-cts-hmac-sha1-96)
   2 RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com@PSREC.PS.PROJECTS.TESTDOM… (aes256-cts-hmac-sha1-96)
 

 

 

[root@rhel-nfs-cli ~]# kinit admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM
Password for admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM:

[root@rhel-nfs-cli ~]# klist -e
Ticket cache: KCM:0
Default principal: admin@PSREC.PS.PROJECTS.TESTDOMAIN.COM

Valid starting       Expires              Service principal
10/16/2023 14:14:58  10/17/2023 00:14:58  krbtgt/PSREC.PS.PROJECTS.TESTDOMAIN.COM@PSREC.PS.PROJECTS.TESTDOMAIN.COM
        renew until 10/23/2023 14:14:55, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
 

Hát kifogytam az ötletekből, az aes256-cts-hmac-sha1-96 mindenhol szerepel, de szerintem mennie kellene a másikkal is.

Mindenesetre amig a keytabbal nem tudsz kapcsolódni, nem fog úgy menni ahogy szeretnéd.

Azért kíváncsi lennék mi felett siklottam el.

Tegnap kísérletezgettem egy kicsit:

  • centos 5-ön a kinit nem ír ki csak egy plusz sort ha debuggolni akarom.
  • rocky linux 9-en viszont eléggé szószátyár lett
# KRB5_TRACE=/dev/stdout kinit -Vkt /etc/krb5.keytab host/RHEL-NFS-CLI

Nem tudom melyik RHEL-ed van, gondolom legalább 8, esetleg ezzel megmondja mi a baja.

Nézd meg még hogy az AES128 és az AES256 be van-e kapcsolva a számítógépfiókban:

https://www.msxfaq.de/windows/kerberos/kerberos_rc4_abschaltung03.gif

(az alsó kettö lenne az érdekes a piros négyzetben, a DES kódolás meg jobb ha nincs bepipálva.)

az admin usernél biztos be van, mert ott megy az AES.

Amit belinkeltel gif-et nem erem el. A direkt linket nem engedi ;) De megtalalta a gugli :D

A szamitogepfioknal nincsen ilyen "account" cucc, az a user fiokoknal van. Legalabbis elsore nem talaltam. 

 

Jah, RHEL 8.8

[root@rhel-nfs-cli ~]# KRB5_TRACE=/dev/stdout kinit -Vkt /etc/krb5.keytab host/RHEL-NFS-CLI
[7219] 1697528877.878573: Resolving unique ccache of type KCM
Using new cache: 0:4618
Using principal: host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
Using keytab: /etc/krb5.keytab
[7219] 1697528877.878574: Getting initial credentials for host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM
[7219] 1697528877.878575: Looked up etypes in keytab: aes128-cts, aes256-cts
[7219] 1697528877.878577: Sending unauthenticated request
[7219] 1697528877.878578: Sending request (251 bytes) to PSREC.PS.PROJECTS.TESTDOMAIN.COM
[7219] 1697528877.878579: Initiating TCP connection to stream 10.17.72.15:88
[7219] 1697528877.878580: Sending TCP request to stream 10.17.72.15:88
[7219] 1697528877.878581: Received answer (138 bytes) from stream 10.17.72.15:88
[7219] 1697528877.878582: Terminating TCP connection to stream 10.17.72.15:88
[7219] 1697528877.878583: Response was from master KDC
[7219] 1697528877.878584: Received error from KDC: -1765328378/Client not found in Kerberos database
kinit: Client 'host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM' not found in Kerberos database while getting initial credentials

----------------

update: kozben megneztem az "admin" user-nel, ott sincsenek bepipalva az AES dolgok.

 

Mellesleg:

[root@rhel-nfs-cli ~]# kinit -kt /etc/krb5.keytab host/RHEL-NFS-CLI@PSREC.PS.PROJETS.TESTDOMAIN.COM
kinit: Keytab contains no suitable keys for host/RHEL-NFS-CLI@PSREC.PS.PROJETS.TESTDOMAIN.COM while getting initial credentials

Itt elírtad a PROJECTS szót PROJETS-re, azért írta hogy nincs ilyen kulcs a keytabban.

kinit: Client 'host/RHEL-NFS-CLI@PSREC.PS.PROJECTS.TESTDOMAIN.COM' not found in Kerberos database while getting initial credentials

Itt már azt mondja hogy a szerver nem találja a usert ilyen service principallal.

elvileg ha ez 2016-nál nagyobb szerver akkor már alapból az AES128/256 engedélyezve van (de lehet már 2012-töl így van), nem kell felhasználónként engedélyezni (illetve volt rá egy KB ist ami kikapcsolta az RC4-et)

szóval tévedtem, nem kell pipálni semmit, csak az emékeimben volt hogy nekem valahol még kellett.

>Itt már azt mondja hogy a szerver nem találja a usert ilyen service principallal.

Ez user, vagy host?

Ha ez az. Hol kell ezt megtalalnia? a kliens oldalon benne van a keytabban a hosthoz, a server oldalon meg ezt latom:

:\Users\wwww>setspn.exe -L RHEL-NFS-CLI$
Registrierte Dienstprinzipalnamen (SPN) für CN=RHEL-NFS-CLI,CN=Computers,DC=psrec,DC=ps,DC=projects,DC=testdomain,DC=com:
        RestrictedKrbHost/rhel-nfs-cli.psrec.ps.projects.testdomain.com
        RestrictedKrbHost/RHEL-NFS-CLI
        host/rhel-nfs-cli.psrec.ps.projects.testdomain.com
        host/RHEL-NFS-CLI

------

Egyaltalan kell kerberos ticketet kernunk a Linux hostnak is?

Ez elso kinit-et nem a host neveben kellene kiadni? De ott mi a jelszo?

mivel nem tudja melyik felhasználó ezért a megadott Principallal szür egyet az ldapra (az is lehet hogy csak a normál felhasználókra szür, a gépi fiókokra nem, ezt nem tudom) ha megvan folytatja a folyamatot. szerintem ticketet nem hoz létre (bár ezt nem merném teljes biztonsággal állítani), nem vagyok ennyire benne az ldap+kerberos dolgokban. Ha nincs ldap objektum a felételeknek megfelelöen, akkor kapod a "not found in Kerberos..."-t, ha nincs olyan nevü kulcs a keytabban akkor meg a másikat.

a keytab azért kéne hogy jelszó nélkül tudjon dolgozni, pontosabban azért hogy ne kelljen a jelszót minden alkalommal begépelni, a keytabban a (nagy vonalakban) a jelszó hash van eltárolva ezt hasonlítja össze a Kerberos adatbázissal (AD), ha passzol ok, ha nem akkor újabb hiba.

alapból ha beléptetsz egy gépet az AD-ba akkor a gépnév plusz dollár lesz a CN és a jelszó is, a windowsos gépek ezt idöközönként frissítik, a realm parancs linuxon nem tudom mit ad meg jelszónak.

Ha ez csak egy Teszt AD, Teszt NFS-el, akkor még nem adnám fel, de kezdünk olyan mélységekbe hatolni ahol már az én tudásom / nem tudásom elfogy.

A többi elhagyott szállal én még próbálkoznék mielött feladnám, de lehet egyszerübb ha keresel valaki aki nem csak egyszer véletlenül tudja összerakni, hanem háttal állva balkézzel és egy nyitott szemmel bármikor amikor kedve szottyan rá. (Nem olyan mükedvelö mint én)

elhagyott szálak (nem teljes):

  • az összes Principal végigpróbálása
  • kinit -S kapcsoló próbálgatása
  • kliens kiszedése az AD-böl, takarítás az AD-ban és a kliensen, visszarakás az AD-ba
  • Felhasználói fiók lérehozása, SPN hozzárendelése, keytab létrehozása és azzal próbálkozás, nem csak host/RestrictedKrbHost, hanem HOST (igen nagybetüvel, kizárni a unix/windows kis- és nagybetü másképp kezelését), esetleg nfs vagy NFS

és még biztos van pár elvarratlan szál.

Egyszer csak valahol felvillan a lámpa, mint amikor rájöttem hogy a ktpass.exe /pass kapcsolója mindig új jelszót ad a felhasználónak és növeli a kvno értékét és azért nem mennek a régebben csinált keytabok (mert copy-paste volt a leirásból ott meg csak az állt hogy a felhasználó jelszava, az nem hogy vigyázz mert jelszót cserél akkor is ha ugyanazt adod meg)

uj fejlemeny, hogy hozzadtam az nfs/.... cuccot a keytabhoz, majd az admin userrel belepve ssh-n chown-oltam az nfs_share konyvtarat az admin@ nevere. Ez mukodott. 

Lehet, nem is kellett volna hozaadni az nfs/..  cuccot, ezt majd kiprobalom.

Ezutan belepve egy AD userrel  SSH-n a korrekt ID-kat rendelte hozza a tesztfileokhoz.

 

Magyraul ha utolag valtoztatom meg a user-t, akkor van remeny a mukodesre. Sajna az AD csoportoknal meg hiba van.

--

a cel nyilvan az lenne, hogy az egyes system user-ek, amik futnak a Linux hoston mappelve legyenek az egyes konyvtarakhoz a share-n, es csak a sajt konyvtarukat tudjak irni/olvasi..na ez meg kerdeses......

( wyx v | 2023. 10. 11., sze – 11:15 )

Szerkesztve: 2023. 10. 11., sze – 11:15

[root@rhel-nfs-cli test_nfs]# id fs-reader@PSREC.PS.PROJECTS.TESTDOMAIN.COM
uid=1770803249(fs-reader@psrec.ps.projects.testdomain.com) gid=1770800513(domänen-benutzer@psrec.ps.projects.testdomain.com) groups=1770800513(domänen-benutzer@psrec.ps.projects.testdomain.com),1770803247(fs_reader_group@psrec.ps.projects.testdomain.com)

 

 

[root@rhel-nfs-cli test_nfs]# chown fs-reader@PSREC.PS.PROJECTS.TESTDOMAIN.COM:domänen-benutzer@psrec.ps.projects.testdomain.com  testfile2.reader
chown: changing ownership of 'testfile2.reader': Operation not permitted

---

Ez sem ugy mukodik, mint elvarnam. Hol hibazok itt? a user-ek AD-bol jonnek.

a szerver oldalon úgysem tudod megváltoztatni, egy próbát meg megér kliens oldalon. a sec=krb5 az csak authentikál, ha krb5i, krb5p lenne, akkor lehet nem müködne mert akkor már kódolgatna is.

a a szerveren van root, vagy bármi más 0 uiddal, akkor müködnie kéne.

nem is azt írtam hogy ez nem az amit szeretnél. viszont ki lehet próbálni hogy mondjuk ilyenkor az fs-reader hogyan viselkedik (nobody lesz-e vagy sem) illetve a chown megy-e rootként.

ha nem jó az id a rootnál sem akkor az admin@xyz-ból is nobody lesz, az meg nem tud chown-t futtatni.

egyre inkább az a gyanúm hogy az nfs kliens nem tud mit kezdeni a kerberos tikettel, nem tudja ellenörizni az AD-ban.

> egyre inkább az a gyanúm hogy az nfs kliens nem tud mit kezdeni a kerberos tikettel, nem tudja ellenörizni az AD-ban.

 

En is erre gyanakszom, de a kerdes az, hol kellene latnom hibat a kliens oldalon a logokban, ugyanis jelenleg sehol nem latok ilyet....az sssd verbosity mar 9.

( naszta v | 2023. 10. 16., h – 10:58 )

Szerkesztve: 2023. 10. 16., h – 11:00

Ha jól emlékszem, a Kerberos exclusive lock-ol keytab olvasáskor, amihez kell valami varázslat NFS oldalon. (Ha jól értem a problémát.)

https://naszta.hu