最近、Netware から Windows ファイル サーバーに移行した結果、大量の AD グループが作成されました。現在、認証とリソースへのアクセスに関していくつかの問題が発生しています。
いくつかの初期トラブルシューティングを行った後、Domain Admins が所属するグループが多すぎる (最新のカウントでは 397) ことと、Kerberos チケットのサイズが 12000 バイトを超えている (13783) (イベント ID 6) ことが判明しました。次の記事を見つけました。そこには、何が起こったのかを正確に説明しているようで、修正方法についての提案もいくつか書かれています。
目的は、レジストリの MaxTokenSize 制限を 65535 に引き上げることです。しかし、これがどのような影響を与えるかについての議論は見つかりませんでした。長期的には、グループ数の増加を合理化することが目的ですが、短期的にはこれで解決できるように思えます。過去にこれについて経験のある方はいらっしゃいますか。また、この変更を展開する前に注意すべき注意事項はありますか。
現在、すべての DC が 64 ビット VM である Server 2008 ドメインおよびフォレスト機能レベルを実行しています。
更新: これについてもう少し調べてみると、Server 2012 では MaxTokenSize の既定値が 48000 に設定されていることがわかりました。これは、採用するのに適切なオプションのように思えます。まだ情報を見つけられないことの 1 つは、ユーザーがより大きなトークンを持つことによる影響です。これにより IIS サーバーのメモリ使用量が増加するという意見もありますが、DC やメンバー サーバー (32 ビット Citrix サーバーなど) でも同じことが起こるかどうかは誰か知っていますか?
答え1
多くの組織では、かなり前にこれを 65535 に設定しました。これを推奨する Microsoft KB 記事は多数あります。以前は 100,000 が推奨されていましたが、Microsoft はその値が機能しないことに気づき、これを 65535 に修正しました。
IIS Web サイト (SharePoint など) で統合 Windows 認証を使用する場合、トークンが大きいと認証に失敗することがあります。この問題は、http.sys サービスの MaxRequestBytes の値を増やすことで簡単に解決できます。これは、各 http 要求にグループを含む Kerberos トークンが含まれているためです。また、統合認証のパフォーマンスを向上させて、最初の要求のみを認証するようにできる IIS 設定もあります。
グループを確認し、セキュリティ グループにする必要が絶対にない限り、いくつかを配布グループに変換することをお勧めします。最大トークン サイズが 65535 であっても、アカウントが多数のグループのメンバーになり、ログオンできなくなる可能性があります。
答え2
これはマックストークンのサイズ。トークンは必要な場合にのみ、その量のメモリを消費します。すべての Kerberos トークンが常に 48000 バイトになるわけではありません。
この問題は通常、長年にわたって蓄積されてきた多数のセキュリティ グループを持つ大企業でのみ発生します。
Windows2012 では、ユーザー アカウントが所属できるグループの数に新しいハード制限 (1,015) が設けられています。
Kerberos トークンの肥大化の問題が発生している場合は、DOMAIN USERS グループがいくつのグループにネストされているかを確認してください。これは悪い習慣です。
DOMAIN USERS が不要なグループのメンバーにならないようにしてください。
参考になる良い記事があります: https://blogs.technet.microsoft.com/shanecothran/2010/07/16/maxtokensize-and-kerberos-token-bloat/