サーバーごとのサービスごとのグループマネージドサービスアカウント（ベストプラクティス？）と長い名前？
私たちの環境でグループマネージドサービスアカウントを使用するためのベストプラクティスについて、数人の同僚と話しました。
理想的には、サーバー（SQLDEV01など）ごとにサービス（SQLエージェントサービスなど）ごとに1つのgMSAを作成するようです。
これにより、関心の分離が最大化され、サービスアカウントに問題（侵害、削除、ロック、破損など）が発生した場合に、関連付けられている単一のサービスと単一のサーバーにのみ影響するようになります。
このアプローチの唯一の短所の1つは、作成するgMSAが多数存在する可能性があることです。とはいえ、一度作成すれば、今後は管理する必要はあまりありません。
私が直面しているもう1つの問題は、gMSAの命名です（15文字以下である必要があると思います）。アカウントがgMSAであり、特定のサービス用であり、特定のサーバー用であることを示す名前を思い付くのは非常に難しいようです。
たとえば、一般的な規則に従った一般名は次のようになります。
- gMSA_SQLDEV01_SQLAGT（20文字）
次のように短縮できます。
- gmsaSQLDEV01AGT（15文字）
上記の例は正確に15文字であり、他の潜在的により長いサーバー名またはサービス名のために余裕がありません。
これらの状況を処理するためのベストプラクティスまたは方法はありますか？
- 関心の分離を伴うグループマネージドサービスアカウント？
- 長い名前のグループマネージドサービスアカウント？
関心の分離の側面は、環境に大きく依存し、特定のシナリオでアカウントを共有することの単純さと、物事を分離する煩わしさを比較検討します。つまり、元のMSAに対するgMSAの主な機能の1つは、複数のシステムで使用できることです。
長い名前について...
gmsaのようなプレフィックスを付けないことで、簡単にスペースを解放できます。通常のユーザーアカウントに関連するobjectClass属性で多くの共通クラスを共有しますが、msDS-GroupManagedServiceAccountと呼ばれる独自のクラスも含まれているため、フィルターに含めることができます。またはそれらを除外します。 gMSAは、ADUCなどのGUIツールでも視覚的に区別されます。したがって、仮想的には、人々は日常の活動で通常のユーザーアカウントと混同することはありません。
これで遊んでいると、別のことに気づきました。 New-ADServiceAccountコマンドレットは実際に-SamAccountNameに15文字の制限を適用しますが、ADSIEditを使用して手動でmsDS-GroupManagedServiceAccountオブジェクトを作成すると、20文字の制限のみが適用されます。
20文字の長さのgMSAを実際にテストすることはできませんでした。ですから、それが実際に何かで機能するかどうかはわかりません。ただし、命名規則にもっと余裕が必要な場合は、さらにテストする価値があります。