Tham gia Đăng nhập
Điểm:2
Alek_A avatar Server

NFS4 + Kerberos does not work since 5.10 kernel

lá cờ pe
Alek_A

Since I updated to Debian Bullseye, nfs clients stopped working:

# mount -vvt nfs4 -o sec=krb5 nfs11:/srv /mnt
mount.nfs4: timeout set for Wed Sep 15 20:25:49 2021
mount.nfs4: trying text-based options 'sec=krb5,vers=4.2,addr=x.y.11.63,clientaddr=x.y.11.42'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting nfs11:/srv

When I install 5.9 kernel (linux-image-5.9.0-0.bpo.5-cloud-amd64) on the same system - it works.

I also tried:

  • Debian Testing Kernel (kernel 5.14) - does not work
  • Ubuntu 21.10 Impish (kernel 5.13) - does not work
  • Ubuntu 20.04 Focal (kernel 5.4) - works

Provided, that all the systems has an identical NFS/Kerberos setup, my conclusion: Something has changed in the kernel that does not allow to mount NFS/Kerberos shares.

  • My KDC - Samba4 AD
  • My Kerberos and NFS setup is pretty mach standard, as in any how-to
  • HOSTNAME$@REALM nfs/fqdn@REALM host/... principles are there in the client and server key-tab

I put RPCGSSDOPTS="-vvv" in /etc/default/nfs-common for debugging. In the following logs:

  • nfs11 - my test nfs server (Debian 11, kernel 5.10)
  • tst2 - my test nfs client (Debian 11)

Here is the syslog when the client is attempting to mount nfs share:

nfs client booted with 5.9 kernel (mounts successfully)

rpc.gssd[446]: #012handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2' (nfs/clnt0)
rpc.gssd[446]: krb5_use_machine_creds: uid 0 tgtname (null)
rpc.gssd[446]: Full hostname for 'nfs11.my.domain' is 'nfs11.my.domain'
rpc.gssd[446]: Full hostname for 'tst2.my.domain' is 'tst2.my.domain'
rpc.gssd[446]: Success getting keytab entry for '[email protected]'
rpc.gssd[446]: gssd_get_single_krb5_cred: principal '[email protected]' ccache:'FILE:/tmp/krb5ccmachine_MY.DOMAIN'
rpc.gssd[446]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631755378
rpc.gssd[446]: creating tcp client for server nfs11.my.domain
rpc.gssd[446]: DEBUG: port already set to 2049
rpc.gssd[446]: creating context with server [email protected]
rpc.gssd[446]: doing downcall: lifetime_rec=36000 [email protected]
rpc.gssd[446]: #012handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2' (nfs/clnt0)
rpc.gssd[446]: krb5_use_machine_creds: uid 0 tgtname (null)
rpc.gssd[446]: Full hostname for 'nfs11.my.domain' is 'nfs11.my.domain'
rpc.gssd[446]: Full hostname for 'tst2.my.domain' is 'tst2.my.domain'
rpc.gssd[446]: Success getting keytab entry for '[email protected]'
rpc.gssd[446]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631755378
rpc.gssd[446]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631755378
rpc.gssd[446]: creating tcp client for server nfs11.my.domain
rpc.gssd[446]: DEBUG: port already set to 2049
rpc.gssd[446]: creating context with server [email protected]
rpc.gssd[446]: doing downcall: lifetime_rec=36000 [email protected]
nfsidmap[524]: key: 0x3b88d120 type: uid value: [email protected] timeout 600
nfsidmap[524]: nfs4_name_to_uid: calling nsswitch->name_to_uid
nfsidmap[524]: nss_getpwnam: name '[email protected]' domain 'my.domain': resulting localname 'root'
nfsidmap[524]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
nfsidmap[524]: nfs4_name_to_uid: final return value is 0
nfsidmap[525]: key: 0x317cb571 type: gid value: [email protected] timeout 600
nfsidmap[525]: nfs4_name_to_gid: calling nsswitch->name_to_gid
nfsidmap[525]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
nfsidmap[525]: nfs4_name_to_gid: final return value is 0

nfs client booted with 5.10 kernel (does not mount)

rpc.gssd[450]: #012handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,3,1,2' (nfs/clnt3)
rpc.gssd[450]: krb5_use_machine_creds: uid 0 tgtname (null)
rpc.gssd[450]: Full hostname for 'nfs11.my.domain' is 'nfs11.my.domain'
rpc.gssd[450]: Full hostname for 'tst2.my.domain' is 'tst2.my.domain'
rpc.gssd[450]: Success getting keytab entry for '[email protected]'
rpc.gssd[450]: gssd_get_single_krb5_cred: principal '[email protected]' ccache:'FILE:/tmp/krb5ccmachine_MY.DOMAIN'
rpc.gssd[450]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631656676
rpc.gssd[450]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631629984
rpc.gssd[450]: creating tcp client for server nfs11.my.domain
rpc.gssd[450]: DEBUG: port already set to 2049
rpc.gssd[450]: creating context with server [email protected]
rpc.gssd[450]: WARNING: Failed to create krb5 context for user with uid 0 for server [email protected]
rpc.gssd[450]: WARNING: Failed to create machine krb5 context with cred cache FILE:/tmp/krb5ccmachine_MY.DOMAIN for server nfs11.my.domain
rpc.gssd[450]: creating tcp client for server nfs11.my.domain
rpc.gssd[450]: DEBUG: port already set to 2049
rpc.gssd[450]: creating context with server [email protected]
rpc.gssd[450]: WARNING: Failed to create krb5 context for user with uid 0 for server [email protected]
rpc.gssd[450]: WARNING: Failed to create machine krb5 context with cred cache FILE:/tmp/krb5ccmachine_MY.DOMAIN for server nfs11.my.domain
rpc.gssd[450]: WARNING: Machine cache prematurely expired or corrupted trying to recreate cache for server nfs11.my.domain
rpc.gssd[450]: Full hostname for 'nfs11.my.domain' is 'nfs11.my.domain'
rpc.gssd[450]: Full hostname for 'tst2.my.domain' is 'tst2.my.domain'
rpc.gssd[450]: Success getting keytab entry for '[email protected]'
rpc.gssd[450]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631656676
rpc.gssd[450]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631656676
rpc.gssd[450]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_MY.DOMAIN' are good until 1631629984
rpc.gssd[450]: creating tcp client for server nfs11.my.domain
rpc.gssd[450]: DEBUG: port already set to 2049
rpc.gssd[450]: creating context with server [email protected]
rpc.gssd[450]: WARNING: Failed to create krb5 context for user with uid 0 for server [email protected]
rpc.gssd[450]: WARNING: Failed to create machine krb5 context with cred cache FILE:/tmp/krb5ccmachine_MY.DOMAIN for server nfs11.my.domain
rpc.gssd[450]: creating tcp client for server nfs11.my.domain
rpc.gssd[450]: DEBUG: port already set to 2049
rpc.gssd[450]: creating context with server [email protected]
rpc.gssd[450]: WARNING: Failed to create krb5 context for user with uid 0 for server [email protected]
rpc.gssd[450]: WARNING: Failed to create machine krb5 context with cred cache FILE:/tmp/krb5ccmachine_MY.DOMAIN for server nfs11.my.domain
rpc.gssd[450]: ERROR: Failed to create machine krb5 context with any credentials cache for server nfs11.my.domain
rpc.gssd[450]: doing error downcall

I googled a lot and didn't find anything related... Currently as a workaround I run backported kernel from previous release in all nfs client systems. But I think it is dangerous, and something tells me it may break at any time.

Has anyone experienced such a problem? Maybe I should adjust something to match changes in kernel? Maybe I should fill the kernel bug?

UPDATE. Added KDC logs.

KDC while mounting from client with 5.9 kernel - successfully

[2021/09/21 21:55:12.061264,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'dcesrv: NT_STATUS_CONNECTION_DISCONNECTED'
[2021/09/21 21:55:44.743415,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ [email protected] from ipv4:x.y.11.42:38701 for krbtgt/[email protected]
[2021/09/21 21:55:44.747105,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client sent patypes: 150, 149
[2021/09/21 21:55:44.747154,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for PKINIT pa-data -- [email protected]
[2021/09/21 21:55:44.747178,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for ENC-TS pa-data -- [email protected]
[2021/09/21 21:55:44.747209,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: No preauth found, returning PREAUTH-REQUIRED -- [email protected]
[2021/09/21 21:55:44.751030,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ [email protected] from ipv4:x.y.11.42:50506 for krbtgt/[email protected]
[2021/09/21 21:55:44.753959,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client sent patypes: encrypted-timestamp, 150, 149
[2021/09/21 21:55:44.754060,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for PKINIT pa-data -- [email protected]
[2021/09/21 21:55:44.754114,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for ENC-TS pa-data -- [email protected]
[2021/09/21 21:55:44.754187,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
[2021/09/21 21:55:44.754275,  3] ../../auth/auth_log.c:635(log_authentication_event_human_readable)
  Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[[email protected]] at [Tue, 21 Sep 2021 21:55:44.754261 +06] with [arcfour-hmac-md5] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:x.y.11.42:50506] became [MYDOM]\[tst2$] [S-1-5-21-3408476796-3867293677-901807371-6619]. local host [NULL] 
  {"timestamp": "2021-09-21T21:55:44.754359+0600", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "dd24014b273cc7a8", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:x.y.11.42:50506", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "[email protected]", "workstation": null, "becameAccount": "tst2$", "becameDomain": "MYDOM", "becameSid": "S-1-5-21-3408476796-3867293677-901807371-6619", "mappedAccount": "tst2$", "mappedDomain": "MYDOM", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "arcfour-hmac-md5", "duration": 3366}}
[2021/09/21 21:55:44.761108,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ authtime: 2021-09-21T21:55:44 starttime: unset endtime: 2021-09-22T07:55:44 renew till: 2021-09-22T21:55:44
[2021/09/21 21:55:44.761282,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client supported enctypes: arcfour-hmac-md5, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96, using arcfour-hmac-md5/arcfour-hmac-md5
[2021/09/21 21:55:44.761368,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Requested flags: renewable-ok, forwardable
[2021/09/21 21:55:44.767382,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ [email protected] from ipv4:x.y.11.42:39570 for nfs/[email protected] [canonicalize, renewable, forwardable]
[2021/09/21 21:55:44.773999,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ authtime: 2021-09-21T21:55:44 starttime: 2021-09-21T21:55:44 endtime: 2021-09-22T07:55:44 renew till: 2021-09-22T21:55:44
[2021/09/21 21:55:44.774695,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'

KDC while mounting from client with 5.10 kernel - failed to mount

[2021/09/22 00:31:39.893723,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ [email protected] from ipv4:x.y.11.42:46094 for krbtgt/[email protected]
[2021/09/22 00:31:39.899112,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client sent patypes: 150, 149
[2021/09/22 00:31:39.899162,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for PKINIT pa-data -- [email protected]
[2021/09/22 00:31:39.899186,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for ENC-TS pa-data -- [email protected]
[2021/09/22 00:31:39.899221,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: No preauth found, returning PREAUTH-REQUIRED -- [email protected]
[2021/09/22 00:31:39.901942,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ [email protected] from ipv4:x.y.11.42:39303 for krbtgt/[email protected]
[2021/09/22 00:31:39.905030,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client sent patypes: encrypted-timestamp, 150, 149
[2021/09/22 00:31:39.905080,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for PKINIT pa-data -- [email protected]
[2021/09/22 00:31:39.905105,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Looking for ENC-TS pa-data -- [email protected]
[2021/09/22 00:31:39.905171,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
[2021/09/22 00:31:39.905270,  3] ../../auth/auth_log.c:635(log_authentication_event_human_readable)
  Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[[email protected]] at [Wed, 22 Sep 2021 00:31:39.905248 +06] with [arcfour-hmac-md5] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:x.y.11.42:39303] became [MYDOM]\[tst2$] [S-1-5-21-3408476796-3867293677-901807371-6621]. local host [NULL] 
  {"timestamp": "2021-09-22T00:31:39.905331+0600", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "8511280d720bd92c", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:x.y.11.42:39303", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "[email protected]", "workstation": null, "becameAccount": "tst2$", "becameDomain": "MYDOM", "becameSid": "S-1-5-21-3408476796-3867293677-901807371-6621", "mappedAccount": "tst2$", "mappedDomain": "MYDOM", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "arcfour-hmac-md5", "duration": 3429}}
[2021/09/22 00:31:39.912509,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: AS-REQ authtime: 2021-09-22T00:31:39 starttime: unset endtime: 2021-09-22T10:31:39 renew till: 2021-09-23T00:31:39
[2021/09/22 00:31:39.912597,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Client supported enctypes: arcfour-hmac-md5, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96, using arcfour-hmac-md5/arcfour-hmac-md5
[2021/09/22 00:31:39.912663,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Requested flags: renewable-ok, forwardable
[2021/09/22 00:31:39.918313,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ [email protected] from ipv4:x.y.11.42:59850 for nfs/[email protected] [canonicalize, renewable, forwardable]
[2021/09/22 00:31:39.924869,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ authtime: 2021-09-22T00:31:39 starttime: 2021-09-22T00:31:39 endtime: 2021-09-22T10:31:39 renew till: 2021-09-23T00:31:39
[2021/09/22 00:31:39.925340,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
[2021/09/22 00:31:39.928319,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: TGS-REQ [email protected] from ipv4:x.y.11.42:59852 for nfs/[email protected] [renewable, forwardable]
[2021/09/22 00:31:39.930936,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Server (nfs/[email protected]) has no support for etypes
[2021/09/22 00:31:39.930998,  3] ../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Failed building TGS-REP to ipv4:x.y.11.42:59852
[2021/09/22 00:31:39.931336,  3] ../../source4/smbd/service_stream.c:67(stream_terminate_connection)
  stream_terminate_connection: Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'

I see Server (nfs/[email protected]) has no support for etypes error. Google finds an old issues related to old enctypes, nothing useful. All the packages are up to date.

I have made some progress, thanks to the comments. I installed fresh Samba DC, joined both client (5.10 kernel) and server to new KDC - and it worked! New KDC allows NFS clients with any kernel to mount shares. It seems that the problem is in my production Samba DC. I looked into ldap DBs and it seems they are similar, except very few additions on fresh dc like 3 new objects and some fields. Currently I don't know what I should tweak in the production DC to make it behave like fresh one. Reinstall would be the last resort, because it involves A LOT of time.

Production DC was created long ago, and was migrated several times using standard samba replication or backups. Production and fresh DC info:

  • oEMInformation: Provisioned by SAMBA 4.1.6-Ubuntu
  • oEMInformation: Provisioned by SAMBA 4.13.5-Debian

Currently DCs are running under identical Debian operating systems.

UPDATE 2. Solved!

See the solution is below.

523
0 + 0
nfs
Michael Hampton avatar
lá cờ cz
Michael Hampton
Kiểm tra nhật ký trên máy chủ NFS và trên KDC.
1
Hồi đáp
user1686 avatar
lá cờ fr
user1686
Bạn có thể thử `sysctl sunrpc.rpc_debug=0xFFFF` để lấy thêm nhật ký không? Ngoài ra, mô-đun tiền điện tử `cts` có sẵn không?
0
Hồi đáp
Alek_A avatar
lá cờ pe
Alek_A
@MichaelHampton, Cảm ơn bạn đã gợi ý! nó cho phép tôi đạt được một số tiến bộ. Tôi đã cập nhật bài đăng. Tôi không bao gồm nhật ký máy chủ vì chúng không chứa lỗi hoặc cảnh báo.
0
Hồi đáp
Alek_A avatar
lá cờ pe
Alek_A
@ user1686, Cảm ơn vì Ý tưởng, tôi đã làm điều đó cũng như gỡ lỗi nfsd, nhưng tiếc là nhật ký không thể hiện rằng có điều gì đó không ổn. Bạn có thể giải thích mô-đun `cts` là gì không và làm cách nào để kiểm tra xem nó có sẵn không?
0
Hồi đáp
user1686 avatar
lá cờ fr
user1686
Không chắc liệu có liên quan đến giải pháp tìm thấy của bạn hay không, nhưng thông báo "Máy chủ (nfs/[email protected]) không có hỗ trợ cho etypes" nghe có vẻ giống như tài khoản AD của máy chủ NFS của bạn thiếu "Hỗ trợ AES128/AES256" đang được bật, vì vậy KDC cho rằng nó chỉ dành cho RC4 (sắp trở nên lỗi thời).
0
Hồi đáp
user1686 avatar
lá cờ fr
user1686
(Tôi không chắc ý của bạn khi "tham gia ứng dụng khách vào DC mới" mặc dù – bạn đã thiết lập một miền hoàn toàn mới chưa? Bạn nên có một DC mới cho cùng một miền, sau đó hạ cấp và hủy bỏ DC cũ, giữ nguyên chính xác cùng một nội dung thư mục theo cách đó nhưng vẫn nhận được một DC sạch với sự hỗ trợ của AES.)
0
Hồi đáp
Alek_A avatar
lá cờ pe
Alek_A
@ user1686 Đối với `Máy chủ .. không hỗ trợ etypes`, tôi nghĩ đó là thông báo gây hiểu nhầm, vì tôi nghi ngờ rằng máy chủ NFS mới với cài đặt mặc định trong HĐH mới nhất và được cập nhật có vấn đề với etypes. Bạn có thể cho tôi biết cách kiểm tra xem máy chủ có hỗ trợ AES không? Nhưng nó có thể liên quan đến một số lỗi DC bên trong do các tham số LDAP cũ gây ra. "đã tham gia ứng dụng khách vào DC mới" - Ý tôi là thực sự đã tham gia các máy chủ đó vào dc hoàn toàn mới với `msktutil`, dc hoàn toàn mới mà không giữ nội dung LDAP. Không cần hạ cấp và nuke cái cũ, chúng có thể cùng tồn tại.
0
Hồi đáp
user1686 avatar
lá cờ fr
user1686
Hãy để chúng tôi [tiếp tục cuộc thảo luận này trong cuộc trò chuyện](https://chat.stackexchange.com/rooms/129872/discussion-between-user1686-and-alek-a).
0
Hồi đáp
Điểm:2
Birger avatar Server
lá cờ us
Birger

Linux đã xóa hỗ trợ cho RC4-HMAC-MD5 khỏi Kerberos trong 5.10. Máy khách của bạn sử dụng loại mã hóa đó như có thể thấy trong đầu ra nhật ký của máy chủ:

[21/09/2021 21:55:44.761282, 3]../../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
  Kerberos: Các kiểu mã được máy khách hỗ trợ: arcfour-hmac-md5, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96, sử dụng arcfour-hmac-md5/arcfour-hmac-md5

Nếu có sẵn các loại AES, Samba nên chọn aes256-cts-hmac-sha1-96.

Nó không có trong bất kỳ nhật ký nào của bạn nhưng tôi đoán là lỗi TGS-REQ yêu cầu des3-cbc-sha1, aes128-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96. Điều này có thể được xác minh bằng cách bắt đầu rpc.gssd với các thông số -vvvrr. Trong trường hợp đó, tài khoản AD của khách hàng không được kích hoạt các loại mã hóa bắt buộc. Điều này sẽ xảy ra nếu khách hàng tham gia miền vào thời điểm Samba không hỗ trợ AES. Bạn có thể kích hoạt các loại mã hóa bằng cách đặt lại mật khẩu tài khoản AD của khách hàng hoặc tham gia lại miền. Bạn cũng sẽ cần đảm bảo rằng các loại mã hóa được thêm vào tab khóa của máy khách. Điều này có thể được xác minh đang chạy klist -ke trên máy khách.

Trong trường hợp bạn sử dụng hiệu trưởng dịch vụ cụ thể, hãy đảm bảo thêm rõ ràng các loại mã hóa vào tài khoản của khách hàng (trên ADC chạy bộ mã hóa quảng cáo ròng được đặt <ACCOUNTNAME> 24). Nếu không, chỉ các loại ARCFOUR sẽ được xuất.

0 + 0
Alek_A avatar
lá cờ pe
Alek_A
Tôi rất vui vì câu trả lời của bạn giúp được mọi người, đánh giá bằng cách nâng cấp;) Tôi chắc chắn đã làm những gì bạn đề xuất và hơn thế nữa. Thật không may, giải pháp duy nhất trong trường hợp cụ thể của tôi là tôi đã mô tả. Có thể là do tên miền đã được cung cấp từ lâu hoặc do thực tế là tên miền đó đã từng được đổi tên. Vì vậy, việc sửa các thuộc tính LDAP của DC đã giúp ích.Dù sao cảm ơn thời gian của bạn!
0
Hồi đáp
Điểm:1
Alek_A avatar Server
lá cờ pe
Alek_A

Giải pháp trong trường hợp của tôi là như sau: Tôi đã thử tạo LDAP DB trên DC sản xuất của mình trông giống như LDAP DB trên DC mới (đang hoạt động). Vì vậy, tôi đã thay đổi một số lĩnh vực. Khởi động lại mọi thứ. Va no đa hoạt động!

Những gì tôi đã thay đổi chính xác.

Tôi đã thêm/thay đổi các trường sau trong đối tượng dn: DC=của tôi,DC=miền sử dụng ldbedit -H /var/lib/samba/private/sam.ldb:

msDS-Hành vi-Phiên bản: 4
msDS-NcType: 0
máy chủTrạng thái: 1

DC sản xuất đã được đổi tên trong quá khứ, nhưng tôi đã tìm thấy phần còn lại (tên cũ) trong các đối tượng sau:

dn: CN=<tên cũ>,CN=*,CN=ypServ30,CN=RpcServices,CN=System,DC=my,DC=domain

Tôi đã sửa lỗi này bằng cách đổi tên chúng bằng ldbrename, Ví dụ:

ldbrename -H /var/lib/samba/private/sam.ldb 'CN=<tên cũ>,CN=bootparams,CN=ypServ30,CN=RpcServices,CN=System,DC=my,DC=domain' 'CN =<actual-name>,CN=bootparams,CN=ypServ30,CN=RpcServices,CN=System,DC=my,DC=domain'

Có thể không phải tất cả những thay đổi này là cần thiết, nhưng nó hoạt động ngay bây giờ. Cảm ơn bạn đã bình luận của bạn!

0 + 0
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.