SMBセッションがKerberos5でセットアップされている場合、Windowsドメインコントローラー上のIPC $共有へのアクセスが拒否されました
ユーザーログインを実行し、ネットワーク内のSMB共有へのシングルサインオンアクセスを提供するシステムを書いています。
ユーザーのログインはKerberos 5で行われ、ユーザーのIDを確認してTGTチケットを取得します。 SMB共有にアクセスする場合、TGTチケットは、共有がホストされているサーバーのTGSチケットを取得するために使用され、セッションのセットアップはそのTGSで実行されます（SSOを達成することによって）。
ユーザーがDC上のSMB共有にアクセスしようとするまで、すべて正常に機能します。その場合、DC以下に含まれるリンクに示されているように、STATUS_ACCESS_DENIEDをツリー接続要求に返します。
ユーザーはDomainAdminsグループのメンバーです。そのため、IPC $共有にアクセスできる必要があります
興味深いのは、TGSでセッションセットアップを実行する代わりに、（同じユーザーの資格情報を使用して）NTLMSSPで実行すると、DCallows共有に接続します。
実行される認証（NTLMSSPとKerberos 5）に応じて、SMBセッション）に異なるアクセス許可が割り当てられるのはなぜですか？
これはGPO/GPP構成のようなにおいがしますが、それに関する私の知識は非常に限られています。
Kerberos5を使用する場合のDC）に対するセッションセットアップでさらに手順が必要ですか？または、サーバーがSTATUS_SUCCESSを返した場合、正しく実行していると想定しても安全ですか？
いくつかの注意事項：
- SMBクライアントは、必要な共有に接続する前に、常にIPC $共有に接続して、いくつかのIOCTLを実行しようとします。
- システムの日付と時刻がDCの日付と同期していることを確認しました
- このシステムはLinux上で開発されています。 heimdalのlibkrb5と独自のSMBクライアント（両方のライブラリを変更する機能があります））を使用しています
更新：IPC $共有への接続をスキップし、必要な共有に直接接続する場合でも、動作は同じです。 DCは、ツリー接続要求にSTATUS_ACCESS_DENIEDを返します。
Windows DCデフォルトで必須 SMBメッセージ署名。これは、DC in Negotiate Protocol ResponseのSecurity Mode部分.
（独自の）SMB問題のクライアントは、Kerberosを使用し、署名されていないツリー接続要求を実行するときに、このセキュリティフラグを無視していました。これにより、サーバー（DC）は共有へのアクセスを拒否しました。
SMBクライアントを変更し、Kerberos資格情報が使用されているときにSigning requredフラグを尊重し、DCに接続することを保証した後） SMB共有が可能になりました。