înregistrare Logare
Puncte:0
Standard avatar Server

Acces refuzat la montarea Partajării Kerberised NFS v4

drapel de
Standard

Vreau să montez o partajare NFS4, dar cu securitatea Kerberos activată. Aceasta este configurația mea:

  • Server Debian (dns fqdn: nfsv4test.subnet.example.org)

  • Client Debian (dns fqdn: nfsv4client.subnet.example.org)

  • Windows ADC, acționează și ca KDC

  • Tărâmul meu este REALM.EXAMPLE.ORG

  • Subrețeaua în care se află ambele mașini Debian se numește subnet.example.org

  • Nu are loc NAT.

  • Ambele aparate sunt la zi.

Deci, deoarece încă mă lupt cu Kerberos, așa am încercat să-mi ating obiectivul:

Capitolul I: Configurare

1- Puneți ambele mașini în același domeniu/domeniu (Acest lucru a fost deja configurat de alții și funcționează)

2- S-au creat doi utilizatori (utilizatori, nu computere!) pe mașină: nfs-nfsv4client, host-nfsv4client, nfs-nfsv4test și host-nfsv4test După creare, am activat criptarea AES256 Bit pentru toate conturile.

3- Setați un principal de serviciu pentru utilizatori:

setspn -S nfs/[email protected] nfs-nfsv4test

Am făcut asta pentru toți cei 4 utilizatori/directori.

3- Am creat tastele pe KDC Windows:

ktpass -princ host/[email protected] +rndPass -mapuser [email protected] -pType KRB5_NT_PRINCIPAL -out c:\temp\host-nfsv4test.keytab56-crypto SHA1

Deci după aceea am avut 4 tastaturi.

4- Unirea tastelor de pe server (și client):

ktutil  
read_kt host-nfsv4test.keytab   
read_kt nfs-nfsv4test.keytab    
write_kt /etc/krb5.keytab

Fișierul are 640 de permisiuni.

5- Exportul directoarelor de pe server; acest lucru a funcționat deja fără kerberos. Cu Kerberos activat, fișierul de export arată astfel:

/srv/kerbnfs4 gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check,nesigur)
/srv/kerbnfs4/homes gss/krb5(rw,sync,no_subtree_check,nesecure)

Rularea exportfs -rav funcționează:

root@nfsv4test:~# exportfs -rav
se exportă gss/krb5:/srv/kerbnfs4/homes
se exportă gss/krb5:/srv/kerbnfs4

...si pe client pot vizualiza monturile de pe server:

root@nfsv4client:~# showmount -e nfsv4test.subnet.example.org
Exportați lista pentru nfsv4test.subnet.example.org:
/srv/kerbnfs4/homes gss/krb5
/srv/kerbnfs4 gss/krb5

6a- krb5.conf are configurația implicită pentru mediul pentru care a fost configurat și nu am schimbat nimic:

[libdefaults]
    durata de viață a biletului = 24000
    default_realm = REALM.EXAMPLE.ORG
    default_tgs_entypes = rc4-hmac des-cbc-md5
    default_tkt__enctypes = rc4-hmac des-cbc-md5
    permitted_enctypes = rc4-hmac des-cbc-md5
    dns_lookup_realm = adevărat
    dns_lookup_kdc = adevărat
    dns_fallback = da

# Următoarele variabile krb5.conf sunt numai pentru MIT Kerberos.
    kdc_timesync = 1
    ccache_type = 4
    forwardable = adevărat
    proxiable = adevărat

# Următorii parametri libdefaults sunt numai pentru Heimdal Kerberos.
    fcc-mit-ticketflags = adevărat

[tărâmuri]
    REALM.EXAMPLE.ORG = {
        kdc = kdc.realm.example.org
        default_domain = kds.realm.example.org
    }

[domeniu_domeniu]
    .realm.example.org = KDC.REALM.EXAMPLE.ORG
    realm.example.org = KDC.REALM.EXAMPLE.ORG

[appdefaults]
pam = {
   debug = false
   durata de viață a biletului = 36000
   renew_lifetime = 36000
   forwardable = adevărat
   krb4_convert = fals
}

6- Apoi mi-am configurat sssd.conf așa, dar nu prea am înțeles ce se întâmplă aici:

[sssd]
domenii = realm.example.org
servicii = nss, pam
config_file_version = 2

[nss]
filter_groups = rădăcină
filter_users = root
default_shell = /bin/bash

[pam]
reconnection_retry = 3

[domeniu/realm.example.org]
krb5_validate = Adevărat
krb5_realm = REALM.EXAMPLE.ORG
subdomain_homedir = %o
default_shell = /bin/bash
cache_credentials = Adevărat
id_provider = ad
access_provider = ad
chpass_provider = ad
auth_provide = ad
ldap_schema = ad
ad_server = kdc.realm.example.org
ad_hostname = nfsv4test.realm.example.org
ad_domain = realm.example.org
ad_gpo_access_control = permisiv
use_fully_qualified_names = Fals
ad_enable_gc = False

7- idmap.conf pe ambele mașini:

[General]

Verbositate = 0
Pipefs-Directory = /run/rpc_pipefs

Domeniu = realm.example.org

[Cartografiere]

Nimeni-Utilizator = nimeni
Nimeni-Grup = fără grup

8- Și /etc/default/nfs-common pe ambele mașini:

NEED_STATD=da
NEED_IDMAPD=da
NEED_GSSD=da

9- Nu în ultimul rând, nfs-kernel-server pe server:

RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids --no-nfs-versiunea 3"
NEED_SVCGSSD="da"
RPCSVCGSSDOPTS=""

10- Apoi, după repornirea serverului și a clientului, am încercat să montez partajarea (ca utilizator root):

mount -t nfs4 -o sec=krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes -vvvv

Dar, din păcate, suportul nu funcționează. Nu am acces. La prima încercare, durează destul de mult și acesta este rezultatul:

root@nfsv4client:~# mount -t nfs4 -o sec=krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes
mount.nfs4: timeout stabilit pentru miercuri, 15 decembrie 15:38:09 2021
mount.nfs4: încercarea de opțiuni bazate pe text 'sec=krb5,vers=4.2,addr=********,clientaddr=*******'
mount.nfs4: mount(2): Permisiune refuzată
mount.nfs4: acces refuzat de server în timpul montării nfsv4test.subnet.example.org:/srv/kerbnfs4/homes

Capitolul II: Depanare

Pentru un jurnal mai detaliat, am alergat

rpcdebug -m nfsd -s lockd
rpcdebug -m rpc -s apel

pe server, dar nu primesc atât de multe jurnale.

Cu toate acestea, când încerc să montez, syslog îmi spune că:

6 decembrie 11:20:02 testserver kernel: [ 2088.771800] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.771808] svc: svc_authenticate (0)
6 decembrie 11:20:02 testserver kernel: [ 2088.771811] svc: apelarea dispecerului
6 decembrie 11:20:02 testserver kernel: [ 2088.771840] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.773222] svc: server 00000000c1c7fb25, pool 0, transport 00000000fc9bd395, inuse=2
Dec 6 11:20:02 testserver kernel: [ 2088.774697] svc: server 00000000c1c7fb25, pool 0, transport 00000000fc9bd395, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.774705] svc: svc_authenticate (6)
6 decembrie 11:20:02 testserver kernel: [ 2088.774711] RPC: Doresc actualizare, refage=120, age=0
6 decembrie 11:20:02 testserver kernel: [ 2088.774712] svc: svc_process close
[... 7x același mesaj ]
6 decembrie 11:20:02 testserver kernel: [ 2088.791514] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.791519] svc: svc_authenticate (1)
6 decembrie 11:20:02 kernel testserver: [ 2088.791521] svc: autentificarea eșuată (1)
Dec 6 11:20:02 testserver kernel: [ 2088.791538] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.791913] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.791918] svc: svc_authenticate (1)
6 decembrie 11:20:02 kernel testserver: [ 2088.791920] svc: autentificarea eșuată (1)
6 decembrie 11:20:02 testserver kernel: [ 2088.791940] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.792292] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2
6 decembrie 11:20:02 testserver kernel: [ 2088.792296] svc: svc_authenticate (1)
6 decembrie 11:20:02 kernel testserver: [ 2088.792298] svc: autentificarea eșuată (1)
6 decembrie 11:20:02 testserver kernel: [ 2088.792316] svc: server 00000000c1c7fb25, pool 0, transport 00000000c5641df0, inuse=2

Deoarece acest lucru nu m-a ajutat deloc, am înregistrat traficul cu tcpdump, ceea ce îmi dă asta:

11:12:02.856200 IP ip-client.740 > ip-server.nfs: Flags [S], seq 763536441, win 65160, options [mss 1460,sackOK,TS val 2364952579 ecr 76262579, ecr 2852626441, opțiuni]
11:12:02.856295 IP ip-server.nfs > ip-client.740: Flags [S.], seq 2444950221, ack 763536442, win 65160, options [mss 1460,sackOK,TS val 94752626,TS val 94752826, TS val 947528 ], lungime 0
11:12:02.856304 IP ip-client.740 > ip-server.nfs: Flags [.], ack 1, win 510, options [nop,nop,TS val 2364952579 ecr 2826266858], lungime 0
11:12:02.856324 IP ip-client.740 > ip-server.nfs: Flags [P.], seq 1:245, ack 1, win 510, options [nop,nop,TS val 2364952579 ecr 2826266824] : cerere NFS xid 4035461122 240 getattr fh 0,2/42
11:12:02.856408 IP ip-server.nfs > ip-client.740: Flags [.], ack 245, win 508, options [nop,nop,TS val 2826266858 ecr 2364952579], lungime 0
11:12:02.856421 IP ip-server.nfs > ip-client.740: Flags [P.], seq 1:25, ack 245, win 508, options [nop,nop,TS val 2826266858 ecr 236495249] : răspuns NFS xid 4035461122 răspuns ERR 20: Acreditări false de autenticare (sigiliu rupt)
11:12:02.856425 IP ip-client.740 > ip-server.nfs: Flags [.], ack 25, win 510, options [nop,nop,TS val 2364952579 ecr 2826266858], lungime 0
11:12:02.867582 IP ip-client.740 > ip-server.nfs: Flags [F.], seq 245, ack 25, win 510, options [nop,nop,TS val 2364952590 ecr 2826266808]
11:12:02.867751 IP ip-server.nfs > ip-client.740: Flags [F.], seq 25, ack 246, win 508, options [nop,nop,TS val 2826266869 ecr 2364952509]
11:12:02.867759 IP ip-client.740 > ip-server.nfs: Flags [.], ack 26, win 510, options [nop,nop,TS val 2364952590 ecr 2826266869], lungime 0

(am redactat adresele IP reale)

Deci partea interesantă aici este Auth Bogus (Sigiliu spart)? Există într-adevăr ceva rău sau este doar eroarea care apare atunci când ceva nu este în regulă? Nu am găsit nimic util despre această eroare pe web.

Deci, pentru a reveni la Kerberos în sine, tasta-cheie pare să fie ok:

root@nfsv4client:~# klist -k -e
Nume tasta de taste: FILE:/etc/krb5.keytab
Principalul KVNO
---- --------------------------------------------- ----------------------------
   7 host/[email protected]
   6 nfs/[email protected]

Când încercați să testați fișierul keytab, pare să funcționeze:

root@nfsv4client:~# kinit -k nfs/nfsv4client.realm.example.org
root@nfsv4client:~#

Dar mai departe această pagină se spune că keytab-ul ar trebui testat cu

kinit -k `nume gazdă -s`$

care se rezolvă să

kinit -k nfsv4client

care nu funcționează deoarece nu a fost găsită nicio cheie pentru [email protected]. Deci este greșită tastatura sau metoda de testare?

Un alt jurnal pe care l-am găsit pe mașina client de montare (în mesaje):

 Nucleu nfsv4client: [ 4355.170940] svc: inițializarea pool-ului 0 pentru apel invers NFSv4
 Nucleul nfsv4client: [ 4355.170940] nfs_callback_create_svc: serviciu creat
 Nucleu nfsv4client: [ 4355.170941] NFS: creați date de apel invers per-net; net=f0000098
 kernel nfsv4client: [ 4355.170942] svc: crearea transportului tcp-bc[0]
 kernel nfsv4client: [ 4355.171032] nfs_callback_up: serviciul a început
 Nucleu nfsv4client: [ 4355.171033] svc: svc_destroy (apel invers NFSv4, 2)
 Nucleu nfsv4client: [ 4355.171034] NFS: nfs4_discover_server_trunking: testarea „nfsv4test.subnet.example.org”
 Nucleu nfsv4client: [4355.171040] RPC: sarcină nouă inițializată, procpid 9204
 kernel nfsv4client: [ 4355.171041] RPC: sarcină alocată 000000006bdb9e01
 Nucleu nfsv4client: [ 4355.171042] RPC: 110 __rpc_execute flags=0x5280
 Nucleu nfsv4client: [ 4355.171044] RPC: 110 call_start nfs4 proc EXCHANGE_ID (sincronizare)
 Nucleu nfsv4client: [ 4355.171045] RPC: 110 call_reserve (starea 0)
 Nucleu nfsv4client: [ 4355.171046] RPC: wake_up_first(000000005af696f3 "xprt_sending")
 Nucleu nfsv4client: [ 4355.171047] RPC: 110 rezervat req 00000000d1a7d1a4 xid 04f914c3
 Nucleu nfsv4client: [ 4355.171047] RPC: 110 call_reserveresult (starea 0)
 Nucleu nfsv4client: [ 4355.171048] RPC: 110 call_refresh (starea 0)
 Nucleu nfsv4client: [ 4355.171049] RPC: gss_create_cred pentru uid 0, aromă 390004
 Nucleu nfsv4client: [ 4355.171050] RPC: gss_create_upcall pentru uid 0
 Nucleul nfsv4client: [ 4355.171052] RPC: __gss_find_upcall nu a găsit nimic
 Nucleul nfsv4client: [ 4355.201976] RPC: __gss_find_upcall găsit mesajul 000000000e5abcbc
 Nucleul nfsv4client: [ 4355.201978] RPC: gss_fill_context returnează eroarea 13
 Nucleul nfsv4client: [ 4355.201982] RPC: gss_pipe_downcall returnează 16
 Nucleu nfsv4client: [ 4355.201986] RPC: gss_create_upcall pentru uid 0 rezultat -13
 Nucleu nfsv4client: [ 4355.201987] RPC: 110 call_refreshresult (starea -13)
 Nucleul nfsv4client: [ 4355.201988] RPC: 110 call_refreshresult: reîmprospătarea creditelor a eșuat cu eroarea -13
 Nucleu nfsv4client: [ 4355.201989] RPC: 110 returnează 0, starea -13
 Nucleu nfsv4client: [ 4355.201990] RPC: sarcină de lansare 110

Sunt o mulțime de lucruri, dar nu pot găsi semnificația erorii -13, cu excepția faptului că este Permisiune refuzată.

Capitolul III: Întrebarea

Principalii sunt acolo în keytab. Deci, atunci când clientul întreabă serverul despre partajarea NFS și încearcă să o acceseze, ambii ar trebui să aibă cheile pentru a interacționa unul cu celălalt. Dar din anumite motive nu funcționează. Poate fi din cauza atribuirii directorilor la conturile de utilizator?

Cum pot face asta să funcționeze? Cum obțin informații mai bune la depanare? Îmi pare rău pentru zidul din China de text.

PS. Am urmărit în principal acest tutorial. Mi s-a părut o potrivire perfectă cu mediul meu..

161
0 + 0
nfs
Semicolon avatar
drapel jo
Semicolon
Mașinile și utilizatorii dvs. sunt probabil în REALM.EXAMPLE.ORG și, totuși, încercați să utilizați SPN-uri cu SUBNET.EXAMPLE.ORG. De ce? De asemenea, ce este un „nume de subrețea”? Nu sunt sigur, dar nu are nicio legătură cu SPN
0
Răspunde
Puncte:0
Semicolon avatar Server
drapel jo
Semicolon

Transformând comentariul meu într-un răspuns...

SUBNET.EXAMPLE.ORG nu există de fapt (probabil). Tărâmul/domeniul/pădurea dumneavoastră este REALM.EXAMPLE.ORG, deci fiecare obiect din acel domeniu are acel domeniu. Se pare că subnet.example.org este doar ceva pe care l-ați inventat pentru comoditatea denumirii, probabil.

Deci, dacă ai vrut să folosești SUBNET.EXAMPLE.ORG, ar trebui să aveți înregistrări SRV adecvate pentru domeniul subnet.example.org, acestea ar trebui să indice controlerele domeniului AD, AD ar trebui configurat pentru a le utiliza ca domeniu alias (nu sunt sigur dacă acest lucru este strict posibil cu implementarea Microsoft). De asemenea, clientul care se conectează și controlorii de domeniu ar trebui să rezolve FQDN-ul la IP și IP-ul la FQDN.

De asemenea, aș elimina toate „numele scurte” din SPN-urile dvs. Ramane cu <service>\<FQDN>, gazdă\<FQDN> sau UserPrincipalName

Această linie din sssd.conf este nevalidă. ad_hostname = nfsv4test.subnet.example.org

Toate computerele din domeniu realm.example.com au FQDN-uri ale <computername>@realm.example.com. Sfarsitul povestii. Puteți utiliza DNS pentru a rezolva mașinile cu alte nume, dar în AD/LDAP contul de computer va fi întotdeauna <computername>@realm.example.com

Pe scurt, pentru ca acest lucru să funcționeze prompt, înlocuiți subnet.example.org cu realm.example.org în tot ceea ce ai încercat și probabil ar trebui să fii funcțional.

0 + 0
Standard avatar
drapel de
Standard
`SUBNET.EXAMPLE.ORG` există, deoarece FQDN-ul mașinii este de fapt nfsv4test.subnet.example.org. Cel puțin asta primesc când rulez `hostname --fqdn`. Și așa cum am scris mai sus, KDC poate fi atins pentru că atunci când mă conectez la nfv4client cu un utilizator AD, voi obține de fapt un principal implicit (`[email protected]`) și un principal de serviciu (`krbtgt/REALM. [email protected]`). Și din moment ce toate tutorialele/ghidurile pe care le-am citit au spus că directorii trebuie să aibă FQDN-ul în el, am folosit `nfsv4test.subnet.example.org`.
0
Răspunde
Semicolon avatar
drapel jo
Semicolon
Vă puteți conecta la casetă deoarece ați specificat corect domeniul în fișierul dvs. sssd.conf (krb5_realm = REALM.EXAMPLE.ORG). ÎN acest scenariu, nu cred că contează ce crede că mașina dvs. este FQDN-ul său. Dacă mașina dvs. NFSV4TEST este în domeniul REALM.EXAMPLE.ORG, atunci FQDN-ul său (cel puțin pentru Kerberos) este de facto nfsv4test.realm.example.org. Aceasta nu a fost o presupunere sau o teorie, acesta este un fapt.
0
Răspunde
Standard avatar
drapel de
Standard
Așa că, în sfârșit, am ajuns să testez asta cu subrețea înlocuită cu tărâm. Am șters și recreat SPN-urile, am generat noi keytab-uri, le-am importat (cel puțin funcționează), am actualizat sssd.conf; dar eroarea rămâne aceeași (Auth Bogus Credentials (sigiliu rupt) în tcpdump, Acces refuzat pentru comanda mount). Cum pot verifica dacă, atunci când montez, cheia corectă este solicitată din keytab?
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.