ADのサービスアカウントがAESではなくRC4を使用することによる影響は、Kerberosの場合ですか？
私と一緒に耐えてください、私はこれがずさんなことを知っています、しかしここに裏話があります：
Jiraを使用していて、トークンの特定のグループメンバーシップを想定しているカスタム認証バックエンドでspnegoを使用しているパートナーがいます。提示されたトークンが要件を満たしている場合、ユーザーにはJiraへのSSOアクセスが許可されます。
このパートナーには、子ドメインの1つからの双方向の非推移的な外部信頼があります。これは古くて厳格な外部の信頼であり、選択的なフォレストの信頼ではないため、ADは、Kerberosがドメイン間の対話型ログオン以外で機能するために必要な情報を維持しません。
このサービス用にSPNが登録されていますが、Kerberos参照ができないため、私のクライアントはこのSPNを見つけることができません。これはクライアントがNTLMにフォールバックし、SSOを行わないため、明らかに問題です。
提案された回避策は、サービスアカウントをourの最後にも作成し、SPNを同じサービスに登録することです。パスワードは両側で同一である必要があります。これにより、適切なSPNを見つけるための紹介の必要性がなくなります。これは、適切にSPNをミラーリングし、適切なSPNではなく、子供のクライアントにそれを使用させるためです。また、これらのミラーリングされたアカウントの暗号化アルゴリズムをAESではなくRC4に下げることも提案しています。
これが私の知識が揺らぎ始めるところです、なぜ暗号化アルゴリズムをRC4に下げるステップが必要なのか分かりません。また、それがセキュリティに与える影響についても知りません。
これは何を意味し、なぜこれを機能させるためにAESだけに固執できないのでしょうか。
彼らがRC4を使用する理由について私が考えることができる最大の理由は、Jiraとの互換性のためです（または、このカスタム認証バックエンドは検証できません）。
AES128のサポートは、Server 2008およびVistaとともに導入され、AES256は2008 R2およびWin7とともに導入されました。ただし、KDCは、事前認証中にWindows 2000クライアントなどと通信するときに、（たとえば）RC4に自動的にネゴシエートします。したがって、強制する必要はありません。
もちろん、DES、AES128、AES256などをサポートするかどうかを設定することもできます。
つまり、新しいAESほど強力な暗号化タイプではないということです。しかし、それもひどいことではありません。
彼らがRC4を使用したい理由について、彼らの推論を聞きたいと思います。ミラーリングされたSPNで提案しているトリックは、他の完全なワームですが、クライアントとKDCの間で使用される暗号化タイプは、それが機能するかどうかとは本質的に何の関係もありません。
あなた（または彼ら、変更を提案する人）はRC4に切り替える理由を与えていませんか？ RC4はストリーム暗号であり、特定の場合に脆弱です。
RC4には、新しいシステムでの使用に反対する弱点があります。これは、出力キーストリームの先頭が破棄されない場合、または非ランダムまたは関連キーが使用される場合に特に脆弱です。 （ ウィキペディア ）
したがって、RC4を使用することの影響は、（上記の）脆弱性です。変更の理由がなければ、AESが成立しない理由はわかりません。