私たちのドメインは(同じフォレスト内ではなく)外部ドメインを信頼しており、外部ドメインからドメインのDomain Adminsグループにグループを追加する必要があります。
Domain Adminsグループはglobalグループであるため、他のドメインのグループをグループに追加できないことを理解しています。しかし、私はインターネットでいくつかの回避策を見てきましたが、これらのどれも私たちの状況ではうまくいかないようです。
universalグループとドメインローカルグループを作成しようとしましたが、どちらもDomain Adminsグループに追加できず、ドメインLocalグループを使用すると、外部の信頼されたドメインからアカウントを追加できます。
グローバルセキュリティグループ(例Domain Admins)
ユニバーサルセキュリティグループ(例Enterprise Admins)
ドメインローカルセキュリティグループ(例Administrators)
| Group can contain members of type |
| Group type | Global | Universal | Domain local | Trusted Foreigners |
|--------------|--------|-----------|--------------|--------------------|
| Global | Yes | | | |
| Universal | Yes | Yes | | |
| Domain local | Yes | Yes | | Yes |
GlobalDomain Adminsグループには、他のGlobalグループのみを含めることができます。
また、Globalグループは、外部ドメインの原則を直接(または間接的に)含むことはできません。
ひどい回避策は次のとおりです。
ドメイン内のすべてのマシンのすべてのローカルAdministratorsグループに追加したいグループがあります。
ドメイン内のすべてのマシンのAdministratorsグループにグループを追加するにはどうすればよいですか?
働けないa ドメインローカルグループに他のドメインローカルグループを含めることはできません。
私が見ることができる唯一の回避策は、ローカルドメインのすべてのユーザーに対して重複するアカウントを手動で作成することです
短所:ネットワークセキュリティの低下、ユーザーの生産性の低下、管理の複雑化、管理制御の悪化、ポリシーの不整合、TCOの増加。
Microsoft Windows Serverのアプリケーション仕様から、第5章、セキュリティサービス:
シングルサインオン(SSO)を使用すると、企業ネットワークユーザーは、最初にネットワークにアクセスするときに実行される単一の認証に基づいて、承認されたすべてのネットワークリソースにシームレスにアクセスできます。 SSOは、ネットワークユーザーの生産性を向上させ、ネットワーク運用のコストを削減し、ネットワークセキュリティを向上させることができます。
Better network security。 Windowsで使用できるすべてのSSOメソッドは、安全な認証を提供し、ネットワークリソースとのユーザーのセッションを暗号化するための基盤を提供します。複数のパスワードを排除することで、ユーザーがパスワードを書き留めるというセキュリティ違反の一般的な原因も減少します。
ユーザーの生産性の向上。ユーザーは、複数のログオンを覚える必要がなくなり、ネットワークリソースにアクセスするために複数のパスワードを覚える必要もなくなりました。これは、パスワードを忘れた場合の要求を減らす必要があるヘルプデスク担当者にとってもメリットです。
シンプルな管理。 SSO関連のタスクは、他の管理タスクに使用されるのと同じツールを使用して、通常のメンテナンスの一部として透過的に実行されます。
管理制御が向上します。すべてのSSO固有の情報は、単一のリポジトリであるActive Directoryに保存されます。各ユーザーの権限と特権の信頼できる一覧が1つあるため、管理者はユーザーの特権を変更して、結果がネットワーク全体に広がることを知ることができます。
異種ネットワークの統合。異種ネットワークに参加することにより、管理作業を統合し、管理のベストプラクティスと企業のセキュリティポリシーが一貫して適用されるようにします。
これは、特に難しいように設計されています。これは良い習慣に反しているだけでなく、一般的には不適切な助言です。
基本的に、ドメインの制御を、セキュリティ、ポリシー、監査、および手順が自分の制御外および外部にある別のエンティティに引き渡しています。さらに、環境の攻撃面が少なくとも2倍(おそらくそれ以上)ある
あなたが求めているものを「達成する」には、(私の観点から)2つの適切な方法があります。
ADへの管理アクセスが必要ない場合(つまりサーバー/ワークステーションなどの管理を探しているだけ)、ドメイン管理者はnotドメインコントローラー以外のコンピューターの管理者である必要はありません。
ワークステーションの管理には専用アカウントを使用し、サーバーの管理には別の専用アカウントを使用する必要があります。
これらのアカウントは、カスタムドメインローカルグループに追加する必要があります。GPOを介して、適切なメンバーコンピューターのローカルAdministratorsグループに含めるように簡単に構成できます。 Domain Adminsは、すべてのメンバーサーバーのローカルAdministratorsグループから(GPOまたはその他の手段により))明確に削除する必要があります。
更新された質問に合わせて更新された回答
Group Policy Restricted Groups を使用します。 GPOこれはドメインコントローラーに影響を与えません)を介して、「すべてのローカルAdministratorsグループに追加したいグループ」のエントリーを、「メンバー」と書かれたボックスに作成します。 "Administrators"を追加すると、 "すべてのローカルAdministratorsグループに追加したいグループ"ドメインローカルグループが、上記のポリシーの影響を受けるすべてのコンピューターのローカルAdministratorsグループに追加されます。
制限されたグループと「管理者」を使用する場合は、ドメインコントローラがこのポリシーに含まれていないか、影響を受けないように特に注意してください(委任、セキュリティフィルタリング、WMIフィルタリング、または適切なGPリンクを通じて)。
いいえ、組み込み製品は使用できません。また、Domain Adminsはほぼすべての権限を組み込みのドメインAdministratorsグループから取得するため、通常はこれを行う必要はありません。他のドメインのメンバーを持つことができます。
また、メンバーサーバー/ワークステーションへのアクセスを許可するための個別の管理グループが必要です。
時間ベースのグループメンバーシップのために信頼できる管理フォレストからDomain Adminsにアカウントを追加できる製品Microsoft Identity Managerがありますが、それはおそらくあなたが探しているもの以上のものです。