บรรจวบ เข้าสู่ระบบ
Score:0
Standard avatar Server

การเข้าถึงถูกปฏิเสธเมื่อเมานต์ Kerberised NFS v4 Share

ธง de
Standard

ฉันต้องการเมานต์การแชร์ NFS4 แต่เปิดใช้งานการรักษาความปลอดภัย Kerberos นี่คือการตั้งค่าของฉัน:

  • เซิร์ฟเวอร์เดเบียน (dns fqdn: nfsv4test.subnet.example.org)

  • ไคลเอ็นต์ Debian (dns fqdn: nfsv4client.subnet.example.org)

  • Windows ADC ทำหน้าที่เป็น KDC

  • อาณาจักรของฉันคือ REALM.EXAMPLE.ORG

  • เครือข่ายย่อยที่เครื่อง Debian ทั้งสองเครื่องตั้งอยู่เรียกว่า subnet.example.org

  • ไม่มี NAT เกิดขึ้น

  • ทั้งสองเครื่องเป็นรุ่นล่าสุด

ในขณะที่ฉันยังคงมีปัญหากับ Kerberos ฉันจึงพยายามบรรลุเป้าหมาย:

บทที่ I: การตั้งค่า

1- ใส่ทั้งสองเครื่องในอาณาจักร / โดเมนเดียวกัน (สิ่งนี้ได้รับการตั้งค่าโดยผู้อื่นแล้วและใช้งานได้)

2- สร้างผู้ใช้สองคน (ผู้ใช้ไม่ใช่คอมพิวเตอร์!) ต่อเครื่อง: nfs-nfsv4client, host-nfsv4client, nfs-nfsv4test และ host-nfsv4test หลังจากสร้าง ฉันเปิดใช้งานการเข้ารหัส AES256 บิตสำหรับบัญชีทั้งหมด

3- ตั้งค่าหลักบริการสำหรับผู้ใช้:

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

ฉันทำสิ่งนี้กับผู้ใช้/อาจารย์ใหญ่ทั้งหมด 4 คน

3- สร้างแท็บคีย์บน Windows KDC:

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

หลังจากนั้น ผมก็มี 4 คีย์แท็บ

4- รวมแท็บคีย์บนเซิร์ฟเวอร์ (และไคลเอนต์):

ktutil  
read_kt โฮสต์-nfsv4test.keytab   
read_kt nfs-nfsv4test.keytab    
write_kt /etc/krb5.keytab

ไฟล์มีสิทธิ์ 640

5- ส่งออกไดเร็กทอรีบนเซิร์ฟเวอร์ สิ่งนี้ได้ผลแล้วหากไม่มี kerberos เมื่อเปิดใช้งาน Kerberos ไฟล์ส่งออกจะมีลักษณะดังนี้:

/srv/kerbnfs4 gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check,ไม่ปลอดภัย)
/srv/kerbnfs4/homes gss/krb5(rw,ซิงค์,no_subtree_check,ไม่ปลอดภัย)

ทำงาน exportfs -rav ทำงาน:

root@nfsv4test:~# exportfs -rav
ส่งออก gss/krb5:/srv/kerbnfs4/homes
การส่งออก gss/krb5:/srv/kerbnfs4

...และบนไคลเอนต์ ฉันสามารถดูการเมานต์บนเซิร์ฟเวอร์ได้:

root@nfsv4client:~# showmount -e nfsv4test.subnet.example.org
รายการส่งออกสำหรับ nfsv4test.subnet.example.org:
/srv/kerbnfs4/บ้าน gss/krb5
/srv/kerbnfs4 gss/krb5

6a- krb5.conf มีการกำหนดค่าเริ่มต้นสำหรับสภาพแวดล้อมที่ตั้งค่าไว้และฉันไม่ได้เปลี่ยนแปลงอะไรเลย:

[libdefaults]
    Ticket_lifetime = 24,000
    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 = จริง
    dns_lookup_kdc = จริง
    dns_fallback = ใช่

# ตัวแปร krb5.conf ต่อไปนี้ใช้สำหรับ MIT Kerberos เท่านั้น
    kdc_timesync = 1
    ccache_type = 4
    ส่งต่อได้ = จริง
    ใกล้เคียง = จริง

# พารามิเตอร์ libdefaults ต่อไปนี้ใช้สำหรับ Heimdal Kerberos เท่านั้น
    fcc-mit-ticketflags = จริง

[อาณาจักร]
    REALM.EXAMPLE.ORG = {
        kdc = kdc.realm.example.org
        default_domain = kds.realm.example.org
    }

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

[ค่าเริ่มต้นของแอป]
แพม = {
   ดีบัก = เท็จ
   Ticket_lifetime = 36000
   ต่ออายุ_lifetime = 36000
   ส่งต่อได้ = จริง
   krb4_convert = เท็จ
}

6- จากนั้นฉันก็ตั้งค่า sssd.conf แบบนี้ แต่ฉันไม่เข้าใจจริงๆว่าเกิดอะไรขึ้นที่นี่:

[sssd]
โดเมน = realm.example.org
บริการ = nss, แพม
config_file_version = 2

[nss]
filter_groups = ราก
filter_users = ราก
default_shell = /bin/ทุบตี

[แพม]
reconnection_retries = 3

[โดเมน/realm.example.org]
krb5_validate = จริง
krb5_realm = REALM.EXAMPLE.ORG
subdomain_homedir = %o
default_shell = /bin/ทุบตี
cache_credentials = จริง
id_provider = โฆษณา
access_provider = โฆษณา
chpass_provider = โฆษณา
auth_provide = โฆษณา
ldap_schema = โฆษณา
ad_server = kdc.realm.example.org
ad_hostname = nfsv4test.realm.example.org
ad_domain = realm.example.org
ad_gpo_access_control = อนุญาต
use_fully_qualified_names = เท็จ
ad_enable_gc = เท็จ

7- idmap.conf บนทั้งสองเครื่อง:

[ทั่วไป]

ความฟุ่มเฟือย = 0
Pipefs-Directory = /รัน/rpc_pipefs

โดเมน = realm.example.org

[การทำแผนที่]

ไม่มีใคร-ผู้ใช้ = ไม่มีใคร
ไม่มีใครกลุ่ม = nogroup

8- และ /etc/default/nfs-common บนทั้งสองเครื่อง:

NEED_STATD=ใช่
NEED_IDMAPD=ใช่
NEED_GSSD=ใช่

9- สุดท้าย แต่ไม่ท้ายสุด nfs-kernel-server บนเซิร์ฟเวอร์:

RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNDTOPTS="--manage-gids --no-nfs-เวอร์ชั่น 3"
NEED_SVCGSSD="ใช่"
RPCSVCGSSDOPTS=""

10- จากนั้น หลังจากรีบูตทั้งเซิร์ฟเวอร์และไคลเอ็นต์ ฉันพยายามเมานต์แชร์ (ในฐานะผู้ใช้รูท):

เมานต์ -t nfs4 -o วินาที = krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes -vvvv

แต่น่าเศร้าที่เมาท์ไม่ทำงาน ฉันไม่ได้รับการเข้าถึง ในการลองครั้งแรก ใช้เวลานานพอสมควร และนี่คือผลลัพธ์:

root@nfsv4client:~# mount -t nfs4 -o sec=krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes
mount.nfs4: หมดเวลาที่กำหนดไว้สำหรับวันพุธที่ 15 ธันวาคม 15:38:09 น. 2564
mount.nfs4: ลองใช้ตัวเลือกแบบข้อความ 'sec=krb5,vers=4.2,addr=*******,clientaddr=*******'
mount.nfs4: mount(2): ปฏิเสธการอนุญาต
mount.nfs4: การเข้าถึงถูกปฏิเสธโดยเซิร์ฟเวอร์ขณะเมานต์ nfsv4test.subnet.example.org:/srv/kerbnfs4/homes

บทที่ II: การดีบัก

ฉันวิ่งไปเพื่อบันทึกรายละเอียดเพิ่มเติม

rpcdebug -m nfsd -s lockd
rpcdebug -m rpc -s โทร

บนเซิร์ฟเวอร์ แต่ฉันไม่ได้รับบันทึกมากนัก

อย่างไรก็ตาม เมื่อพยายามเมานต์ syslog บอกฉันว่า:

6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.771800] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.771808] svc: svc_authenticate (0)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.771811] svc: เรียกโปรแกรมเลือกจ่ายงาน
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.771840] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.773222] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000fc9bd395, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.774697] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000fc9bd395, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.774705] svc: svc_authenticate (6)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.774711] RPC: ต้องการอัปเดต refage=120 อายุ=0
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.774712] svc: svc_process ปิด
[... 7x ข้อความเดียวกัน ]
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791514] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791519] svc: svc_authenticate (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791521] svc: การตรวจสอบสิทธิ์ล้มเหลว (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791538] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791913] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791918] svc: svc_authenticate (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791920] svc: การตรวจสอบสิทธิ์ล้มเหลว (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.791940] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.792292] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.792296] svc: svc_authenticate (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.792298] svc: การตรวจสอบสิทธิ์ล้มเหลว (1)
6 ธันวาคม 11:20:02 เคอร์เนลเซิร์ฟเวอร์ทดสอบ: [ 2088.792316] svc: เซิร์ฟเวอร์ 00000000c1c7fb25, พูล 0, ขนส่ง 00000000c5641df0, inuse=2

เนื่องจากสิ่งนี้ไม่ได้ช่วยอะไรฉันเลย ฉันจึงบันทึกทราฟฟิกด้วย tcpdump ซึ่งให้สิ่งนี้:

11:12:02.856200 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [S], seq 763536441, ชนะ 65160, ตัวเลือก [mss 1460,sackOK,TS val 2364952579 ecr 2826266858,nop,wscale 7], ความยาว 0
11:12:02.856295 IP ip-server.nfs > ip-client.740: ค่าสถานะ [S.], seq 2444950221, ack 763536442, win 65160, options [mss 1460,sackOK,TS val 2826266858 ecr 2364952579,nop,wscale 7 ], ความยาว 0
11:12:02.856304 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [.], ack 1, ชนะ 510, ตัวเลือก [nop,nop,TS val 2364952579 ecr 2826266858], ความยาว 0
11:12:02.856324 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [P.], seq 1:245, ack 1, ชนะ 510, ตัวเลือก [nop,nop,TS val 2364952579 ecr 2826266858], ความยาว 244 : คำขอ NFS xid 4035461122 240 getattr fh 0,2/42
11:12:02.856408 IP ip-server.nfs > ip-client.740: ค่าสถานะ [.], ack 245, ชนะ 508, ตัวเลือก [nop,nop,TS val 2826266858 ecr 2364952579], ความยาว 0
11:12:02.856421 IP ip-server.nfs > ip-client.740: ค่าสถานะ [P.], seq 1:25, ack 245, win 508, options [nop,nop,TS val 2826266858 ecr 2364952579], ความยาว 24 : NFS ตอบกลับ xid 4035461122 ตอบกลับ ERR 20: Auth Bogus Credentials (ประทับตราเสีย)
11:12:02.856425 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [.], ack 25, ชนะ 510, ตัวเลือก [nop,nop,TS val 2364952579 ecr 2826266858], ความยาว 0
11:12:02.867582 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [F.], seq 245, ack 25, ชนะ 510, ตัวเลือก [nop,nop,TS val 2364952590 ecr 2826266858], ความยาว 0
11:12:02.867751 IP ip-server.nfs > ip-client.740: ค่าสถานะ [F.], seq 25, ack 246, ชนะ 508, ตัวเลือก [nop,nop,TS val 2826266869 ecr 2364952590], ความยาว 0
11:12:02.867759 IP ip-client.740 > ip-server.nfs: ค่าสถานะ [.], ack 26, ชนะ 510, ตัวเลือก [nop,nop,TS val 2364952590 ecr 2826266869], ความยาว 0

(ฉันแก้ไขที่อยู่ IP จริง)

ดังนั้นส่วนที่น่าสนใจนี่คือ Auth Bogus (Seal Broken)? มีอะไรไม่ดีจริง ๆ หรือเป็นเพียงข้อผิดพลาดที่ปรากฏขึ้นเมื่อมีบางอย่างผิดปกติ? ฉันไม่พบสิ่งใดที่เป็นประโยชน์เกี่ยวกับข้อผิดพลาดนี้บนเว็บ

ดังนั้นเพื่อกลับมาที่ Kerberos เอง แท็บคีย์บอร์ดดูเหมือนจะใช้ได้:

root@nfsv4client:~# klist -k -e
ชื่อแท็บคีย์: FILE:/etc/krb5.keytab
ครูใหญ่ KVNO
---- --------------------------------------------- ----------------------------
   7 โฮสต์/[email protected]
   6 nfs/[email protected]

เมื่อพยายามทดสอบไฟล์ keytab ดูเหมือนว่าจะใช้งานได้:

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

แต่บน หน้านี้ มีการระบุไว้ว่าควรทดสอบแท็บคีย์ด้วย

kinit -k `ชื่อโฮสต์ -s`$

ซึ่งมีมติให้

kinit -k nfsv4client

ซึ่งใช้งานไม่ได้เนื่องจากไม่พบคีย์ [email protected]. แท็บคีย์บอร์ดผิดหรือวิธีทดสอบ

บันทึกอื่นที่ฉันพบในเครื่องไคลเอนต์การเมานต์ (ในข้อความ):

 เคอร์เนล nfsv4client: [ 4355.170940] svc: กำลังเริ่มต้นพูล 0 สำหรับการโทรกลับ NFSv4
 เคอร์เนล nfsv4client: [ 4355.170940] nfs_callback_create_svc: สร้างบริการแล้ว
 เคอร์เนล nfsv4client: [ 4355.170941] NFS: สร้างข้อมูลการโทรกลับต่อเน็ต สุทธิ=f0000098
 เคอร์เนล nfsv4client: [ 4355.170942] svc: กำลังสร้างการขนส่ง tcp-bc[0]
 เคอร์เนล nfsv4client: [ 4355.171032] nfs_callback_up: บริการเริ่มต้น
 เคอร์เนล nfsv4client: [ 4355.171033] svc: svc_destroy (การโทรกลับ NFSv4, 2)
 เคอร์เนล nfsv4client: [ 4355.171034] NFS: nfs4_discover_server_trunking: การทดสอบ 'nfsv4test.subnet.example.org'
 เคอร์เนล nfsv4client: [ 4355.171040] RPC: งานใหม่ที่เริ่มต้น, procpid 9204
 เคอร์เนล nfsv4client: [ 4355.171041] RPC: งานที่จัดสรร 000000006bdb9e01
 เคอร์เนล nfsv4client: [ 4355.171042] RPC: 110 __rpc_execute ค่าสถานะ = 0x5280
 เคอร์เนล nfsv4client: [ 4355.171044] RPC: 110 call_start nfs4 proc EXCHANGE_ID (ซิงค์)
 เคอร์เนล nfsv4client: [ 4355.171045] RPC: 110 call_reserve (สถานะ 0)
 เคอร์เนล nfsv4client: [ 4355.171046] RPC: wake_up_first(000000005af696f3 "xprt_sending")
 เคอร์เนล nfsv4client: [ 4355.171047] RPC: 110 req ที่สงวนไว้ 00000000d1a7d1a4 xid 04f914c3
 เคอร์เนล nfsv4client: [ 4355.171047] RPC: 110 call_reserveresult (สถานะ 0)
 เคอร์เนล nfsv4client: [ 4355.171048] RPC: 110 call_refresh (สถานะ 0)
 เคอร์เนล nfsv4client: [ 4355.171049] RPC: gss_create_cred สำหรับ uid 0, รส 390004
 เคอร์เนล nfsv4client: [ 4355.171050] RPC: gss_create_upcall สำหรับ uid 0
 เคอร์เนล nfsv4client: [ 4355.171052] RPC: __gss_find_upcall ไม่พบอะไรเลย
 เคอร์เนล nfsv4client: [ 4355.201976] RPC: __gss_find_upcall พบ msg 000000000e5abcbc
 เคอร์เนล nfsv4client: [ 4355.201978] RPC: gss_fill_context ส่งคืนข้อผิดพลาด 13
 เคอร์เนล nfsv4client: [ 4355.201982] RPC: gss_pipe_downcall กลับมา 16
 เคอร์เนล nfsv4client: [ 4355.201986] RPC: gss_create_upcall สำหรับ uid 0 ผลลัพธ์ -13
 เคอร์เนล nfsv4client: [ 4355.201987] RPC: 110 call_refreshresult (สถานะ -13)
 เคอร์เนล nfsv4client: [ 4355.201988] RPC: 110 call_refreshresult: การรีเฟรช Creds ล้มเหลวโดยมีข้อผิดพลาด -13
 เคอร์เนล nfsv4client: [ 4355.201989] RPC: 110 ส่งคืน 0 สถานะ -13
 เคอร์เนล nfsv4client: [ 4355.201990] RPC: 110 ปล่อยงาน

มันเยอะมาก แต่ผมหาความหมายของ error -13 ไม่เจอ ยกเว้นว่า Permission Denied

บทที่ III: คำถาม

หลักการจะอยู่ในแท็บคีย์ ดังนั้นเมื่อไคลเอนต์ถามเซิร์ฟเวอร์เกี่ยวกับการแชร์ NFS และพยายามเข้าถึง ทั้งสองควรมีคีย์เพื่อโต้ตอบกัน แต่ด้วยเหตุผลบางอย่างมันไม่ได้ผล อาจเป็นเพราะการกำหนดหลักให้กับบัญชีผู้ใช้?

ฉันจะทำให้สิ่งนี้ทำงานได้อย่างไร ฉันจะได้รับข้อมูลที่ดีขึ้นเมื่อทำการแก้ไขข้อบกพร่องได้อย่างไร ขออภัยสำหรับข้อความกำแพงจีน

ปล. ผมติดตามเป็นหลัก กวดวิชานี้. มันดูเหมาะกับสภาพแวดล้อมของฉัน..

161
0 + 0
nfs
Semicolon avatar
jo flag
Semicolon
เครื่องและผู้ใช้ของคุณน่าจะอยู่ใน REALM.EXAMPLE.ORG แต่คุณกำลังพยายามใช้ SPN กับ SUBNET.EXAMPLE.ORG ทำไม นอกจากนี้ "ชื่อเครือข่ายย่อย" คืออะไร ฉันไม่แน่ใจ แต่ก็ไม่มีผลต่อ SPN
0
ตอบกลับ
Score:0
Semicolon avatar Server
ธง jo
Semicolon

เปลี่ยนความคิดเห็นของฉันเป็นคำตอบ ...

SUBNET.EXAMPLE.ORG ไม่มีอยู่จริง (น่าจะ) อาณาจักร/โดเมน/ฟอเรสต์ของคุณคือ REALM.EXAMPLE.ORGดังนั้นทุกวัตถุในโดเมนนั้นมีขอบเขตนั้น ดูเหมือนว่า subnet.example.org เป็นเพียงสิ่งที่คุณสร้างขึ้นเพื่อความสะดวกในการตั้งชื่อ

ดังนั้นหากคุณต้องการใช้ SUBNET.EXAMPLE.ORGคุณต้องมีบันทึก SRV ที่เหมาะสมสำหรับ realm subnet.example.org พวกเขาจะต้องชี้ไปที่ตัวควบคุมโดเมน AD AD จะต้องกำหนดค่าเพื่อใช้เป็นขอบเขตนามแฝง (ไม่แน่ใจว่าเป็นไปได้อย่างเคร่งครัดหรือไม่กับ การใช้งานของ Microsoft) นอกจากนี้ ไคลเอนต์ที่เชื่อมต่อและตัวควบคุมโดเมนควรแก้ไข FQDN เป็น IP และ IP เป็น FQDN

ฉันจะลบ "ชื่อย่อ" ทั้งหมดออกจาก SPN ของคุณด้วย ติดกับ <service>\<FQDN>, โฮสต์ \<FQDN> หรือ UserPrincipalName

บรรทัดนี้ใน sssd.conf ของคุณไม่ถูกต้อง ad_hostname = nfsv4test.subnet.example.org

คอมพิวเตอร์ทั้งหมดในโดเมน realm.example.com มี FQDN ของ <ชื่อคอมพิวเตอร์>@realm.example.com. ตอนจบของเรื่อง. คุณสามารถใช้ DNS เพื่อแก้ไขเครื่องด้วยชื่ออื่น แต่ใน AD/LDAP บัญชีคอมพิวเตอร์จะตามมาเท่านั้น <ชื่อคอมพิวเตอร์>@realm.example.com

กล่าวโดยย่อ เพื่อให้สิ่งนี้ทำงานได้ทันที ให้เปลี่ยน subnet.example.org กับ realm.example.org ในทุกสิ่งที่คุณได้พยายามและคุณน่าจะใช้งานได้

0 + 0
Standard avatar
de flag
Standard
`SUBNET.EXAMPLE.ORG` มีอยู่จริง เนื่องจาก FQDN ของเครื่องคือ nfsv4test.subnet.example.org อย่างน้อยนั่นคือสิ่งที่ฉันได้รับเมื่อฉันเรียกใช้ `ชื่อโฮสต์ --fqdn` และอย่างที่ฉันเขียนไว้ข้างต้น คุณสามารถเข้าถึง KDC ได้ เพราะเมื่อฉันลงชื่อเข้าใช้ nfv4client ด้วยผู้ใช้ AD ฉันจะได้รับตัวหลักเริ่มต้น (`[email protected]`) และตัวการหลักบริการ (`krbtgt/REALM. [email protected]`). และเนื่องจากบทช่วยสอน/คำแนะนำทั้งหมดที่ฉันได้อ่านกล่าวว่าผู้หลักจำเป็นต้องมี FQDN อยู่ในนั้น ฉันจึงใช้ `nfsv4test.subnet.example.org`
0
ตอบกลับ
Semicolon avatar
jo flag
Semicolon
คุณสามารถล็อกอินเข้าสู่กล่องได้เนื่องจากคุณได้ระบุขอบเขตอย่างถูกต้องในไฟล์ sssd.conf ของคุณ (krb5_realm = REALM.EXAMPLE.ORG) ในสถานการณ์นี้ ฉันไม่คิดว่าเครื่องของคุณคิดว่า FQDN คืออะไร หากเครื่องของคุณ NFSV4TEST อยู่ในโดเมน REALM.EXAMPLE.ORG ดังนั้น FQDN (อย่างน้อยสำหรับ Kerberos) จะเป็น nfsv4test.realm.example.org โดยพฤตินัย นี่ไม่ใช่การเดาหรือทฤษฎี นี่คือข้อเท็จจริง
0
ตอบกลับ
Standard avatar
de flag
Standard
ในที่สุดฉันก็ได้ทดสอบสิ่งนี้ด้วย subnet แทนที่ด้วย realm ฉันลบและสร้าง SPN ใหม่ สร้างแท็บคีย์ใหม่ นำเข้า (อย่างน้อยก็ใช้งานได้) อัปเดต sssd.conf; แต่ข้อผิดพลาดยังคงเหมือนเดิม (Auth Bogus Credentials (seal เสีย) ใน tcpdump การเข้าถึงถูกปฏิเสธสำหรับคำสั่ง mount) ฉันจะตรวจสอบได้อย่างไรว่าเมื่อมีการร้องขอคีย์ที่ถูกต้องจากแท็บคีย์
0
ตอบกลับ
ธงชาติไทย
Kulap
คำถามนี้เป็นภาษาอื่นๆ:

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา