ActiveDirectoryとMIT Kerberos）間のクロスレルム信頼
現在、Windows Server 2016を実行するマシンを追加することにより、これまでLinuxサーバーのみを実行していた開発環境を拡張するプロセスを進めています。認証プロセスはMITKerberosによって処理されます。新しいWindowsマシンでは、ActiveDirectoryの使用を計画しています。 2つのシステムでユーザーを管理したくないので、WindowsADと既存のMITKerberosインストールとの間にレルム間の信頼を設定しています。
そのために、私はこのガイドに従いました： https://bluedata.zendesk.com/hc/en-us/articles/115007484067-How-To-Establish-Cross-Realm-Trust -from-MIT-KDC-to-AD 。
これで、LinuxマシンのADからユーザーのWindowsADからチケットを取得できることに気付きました。kinit [email protected]の実行はエラーなしで完了し、期待どおりにチケットを受け取ります。
一方、MITKerberosセットアップのアカウントを使用してWindowsマシンにログインすることはできません。テストアカウント（MITレルムDOMAIN.LOCALからの[email protected]）を使用してログインしようとすると、次のエラーがスローされます。
「サーバー上のセキュリティデータベースには、このワークステーションの信頼関係のためのコンピューターアカウントがありません」。
私が気付いているもう1つのことは、コマンドnetdom trust DOMAIN.LOCAL /Domain:AD.DOMAIN.LOCAL /Kerberos /verbose /verifyを使用して信頼関係を確認しようとすると、次のエラーメッセージが表示されることです。
ドメインDOMAIN.LOCALに接続できません。コマンドを正常に完了できませんでした。」
WindowsADがMIT Kerberosインストールと通信できないようですが、これは明らかに逆の方法で機能するため、奇妙に思えます。すべてのDNSレコード（domain.local、ad.domain.local、およびKDCのFQDN）が正しいIPアドレスに解決されることをすでに再確認しました。問題を調査しているときに、この投稿に出くわしました https://stackoverflow.com/questions/45236577/using-mit-kerberos-as-account-domain-for-windows-ad-domain 、最初は有望に見えましたが、問題を解決するのに役立ちませんでした。どんな助けでも大歓迎です！
戒厳令、この分野での私の知識はこの時点で非常に古くなっています。 2000年代初頭のように、Windows2003時代のActiveDirectory。そのため、現在は動作が異なる可能性があります。
主な問題は、WindowsがデフォルトでMITレルムのKDCを見つける方法を知らないことです（皮肉なことに、ADの場合のようにDNSを使用して検索するだけではありません）。 ksetup.exe というユーティリティがあり、レルム名を1つ以上のKDCサーバーにマップできます。最終的に、このユーティリティはいくつかのレジストリ値を設定するだけです。したがって、必要に応じてグループポリシーを使用してこれを自動化できます。
更新：@grawityは、適切なSRVレコードが存在し、少なくともレルムを定義するためにksetupが使用されている限り、Windowsが実際にDNS経由でKDCを見つけることができる可能性があると述べました。
また、MITレルムで定義されたユーザーと一致する、ADの本質的に「シャドウ」アカウントであったものもありました。これらのアカウントのパスワードは重要ではなく、存在する必要がありました。また、何らかの方法でMITレルムに関連するUPNやSPNなどの追加の属性を設定した可能性もあります。しかし、記憶はかすんでいます。
注意すべきもう1つの点は、ADとMITレルム間でサポートされている暗号化タイプです。両方ともかなり最近のものであれば、おそらく大丈夫でしょう。しかし、これを行っていたとき、MITレルムは古く、ADにグループポリシーを追加して、MITレルムがサポートするいくつかのレガシー暗号化タイプを追加する必要がありました。
うまくいけば、これはあなたが正しい方向に進むようになるはずです。