使用 Kerberos 5 設置 SMB 會話時，拒絕訪問 Windows 域控制器上的 IPC$ 共享
我正在編寫一個執行使用者登錄並提供對網路內 SMB 共享的單點登錄訪問的系統。
使用者登錄是使用 Kerberos 5 完成的，以驗證使用者的身份並獲得 TGT 票證。訪問 SMB 共享時，TGT 票證用於獲取託管共享的伺服器的 TGS 票證，並使用該 TGS 執行會話設置（通過實現 SSO）。
在使用者嘗試訪問 DC 上的 SMB 共享之前，一切正常。在這種情況下，DC 將向 Tree Connect 請求返回 STATUS_ACCESS_DENIED，如下面的連結所示。
該使用者是 Domain Admins 組的成員。因此，應該有權訪問 IPC$ 共享
有趣的是，如果不是使用 TGS 執行會話設置，而是使用 NTLMSSP（使用相同使用者的憑據）執行它，DC允許連接到共享。
為什麼根據執行的身份驗證（NTLMSSP 與 Kerberos 5）為 SMB 會話分配不同的權限？
這聞起來像 GPO/GPP 配置，但我對此的了解非常有限。
使用 Kerberos 5 時，在針對 DC 的會話設置中是否需要進一步的步驟？或者如果伺服器返回 STATUS_SUCCESS 是否可以安全地假設我做對了？
幾點注意事項：
- SMB 客戶端總是嘗試連接到 IPC$ 共享以在連接到所需的共享之前執行一些 IOCTL。
- 我已驗證我的系統的日期和時間與 DC 的同步
- 本系統是在Linux上開發的，。我正在使用 heimdal 的 libkrb5 和專有的 SMB 客戶端（我有能力修改這兩個庫）
更新：即使跳過連接到 IPC$ 共享，我直接連接到所需的共享，行為也是一樣的。DC 將向 Tree Connect 請求返回 STATUS_ACCESS_DENIED。
預設情況下，Windows DC需要SMB 消息簽名。這是由 DC 在協商協議響應的**安全模式部分中公佈的。
有問題的（專有）SMB 客戶端在使用 Kerberos 並執行未簽名的樹連接請求時忽略了此安全標誌。這導致伺服器 (DC) 拒絕訪問共享。
在修改 SMB 客戶端並確保它在使用 Kerberos 憑據時遵守Signing requred標誌後，連接到 DC 的 SMB 共享成為可能。