Configuration Managerでセキュリティを構成する
Configuration Manager (現在のブランチ) に適用
この記事の情報を使用して、Configuration Managerのセキュリティ関連のオプションを設定するのに役立ちます。 開始する前に、 セキュリティプランがあることを確認してください。
重要
バージョン 2103 Configuration Manager以降、HTTP クライアント通信を許可するサイトは非推奨となりました。 HTTPS または拡張 HTTP 用にサイトを構成します。 詳細については、「 HTTPS 専用または拡張 HTTP のサイトを有効にする」を参照してください。
クライアント PKI 証明書
インターネット インフォメーション サービス (IIS) を使用するサイト システムへのクライアント接続に公開キー 基盤 (PKI) 証明書を使用する場合は、次の手順に従ってこれらの証明書の設定を構成します。
Configuration Manager コンソールで、[管理] ワークスペースに移動し、[サイトの構成] を展開し、[サイト] ノードを選択します。 構成するプライマリ サイトを選択します。
リボンで、[プロパティ] を選択 します。 次に、[ 通信セキュリティ ] タブに切り替えます。
IIS を使用するサイト システムの設定を選択します。
HTTPS のみ: サイトに割り当てられているクライアントは、IIS を使用するサイト システムに接続するときに常にクライアント PKI 証明書を使用します。 たとえば、管理ポイントと配布ポイントなどです。
HTTPS または HTTP: クライアントが PKI 証明書を使用する必要はありません。
HTTP サイト システムConfiguration Manager生成された証明書を使用する: この設定の詳細については、「拡張 HTTP」を参照してください。
クライアント コンピューターの設定を選択します。
使用可能な場合はクライアント PKI 証明書 (クライアント認証機能) を使用する: HTTPS または HTTP サイト サーバーの設定を選択した場合は、HTTP 接続にクライアント PKI 証明書を使用するには、このオプションを選択します。 クライアントは、自己署名証明書の代わりにこの証明書を使用して、サイト システムに対する認証を行います。 HTTPS のみを選択した場合、このオプションは自動的に選択されます。
クライアントで複数の有効な PKI クライアント証明書を使用できる場合は、[ 変更 ] を選択してクライアント証明書の選択方法を構成します。 クライアント証明書の選択方法の詳細については、「 PKI クライアント証明書の選択の計画」を参照してください。
クライアントチェックサイト システムの証明書失効リスト (CRL): 失効した証明書に対してorganizationの CRL をチェックするには、この設定を有効にします。 クライアントの CRL チェックの詳細については、「 PKI 証明書失効の計画」を参照してください。
信頼されたルート証明機関の証明書をインポート、表示、削除するには、[ 設定] を選択します。 詳細については、「 PKI 信頼されたルート証明書と証明書発行者の一覧の計画」を参照してください。
階層内のすべてのプライマリ サイトに対して、この手順を繰り返します。
信頼されたルート キーを管理する
次の手順を使用して、Configuration Manager クライアントの信頼されたルート キーを事前にプロビジョニングして確認します。
注:
クライアントが信頼されたルート キーをActive Directory Domain Servicesまたはクライアント プッシュから取得できる場合は、事前にプロビジョニングする必要はありません。
クライアントが管理ポイントへの HTTPS 通信を使用する場合、信頼されたルート キーを事前にプロビジョニングする必要はありません。 PKI 証明書による信頼を確立します。
信頼されたルート キーの詳細については、「 セキュリティの計画」を参照してください。
ファイルを使用して、信頼されたルート キーを使用してクライアントを事前プロビジョニングする
サイト サーバーで、Configuration Managerインストール ディレクトリを参照します。 サブフォルダーで
\bin\<platform>、テキスト エディターで次のファイルを開きます。mobileclient.tcfエントリを見つけます。
SMSPublicRootKey. その行から値をコピーし、変更を保存せずにファイルを閉じます。新しいテキスト ファイルを作成し、mobileclient.tcf ファイルからコピーしたキー値を貼り付けます。
ファイルは、すべてのコンピューターがアクセスできる場所に保存しますが、ファイルが改ざんから保護されている場所に保存します。
client.msi プロパティを受け入れる任意のインストール方法を使用して、クライアントをインストールします。 次のプロパティを指定します。
SMSROOTKEYPATH=<full path and file name>重要
クライアントのインストール中に信頼されたルート キーを指定する場合は、サイト コードも指定します。 次の client.msi プロパティを使用します。
SMSSITECODE=<site code>
ファイルを使用せずに、信頼されたルート キーを使用してクライアントを事前プロビジョニングする
サイト サーバーで、Configuration Managerインストール ディレクトリを参照します。 サブフォルダーで
\bin\<platform>、テキスト エディターで次のファイルを開きます。mobileclient.tcfエントリを見つけます。
SMSPublicRootKey. その行から値をコピーし、変更を保存せずにファイルを閉じます。client.msi プロパティを受け入れる任意のインストール方法を使用して、クライアントをインストールします。 次の client.msi プロパティを指定します。
SMSPublicRootKey=<key>ここで<key>、mobileclient.tcf からコピーした文字列を指定します。重要
クライアントのインストール中に信頼されたルート キーを指定する場合は、サイト コードも指定します。 次の client.msi プロパティを使用します。
SMSSITECODE=<site code>
クライアントの信頼されたルート キーを確認する
Windows PowerShell コンソールを管理者として開きます。
次のコマンドを実行します。
(Get-WmiObject -Namespace root\ccm\locationservices -Class TrustedRootKey).TrustedRootKey
返される文字列は、信頼されたルート キーです。 サイト サーバー上の mobileclient.tcf ファイルの SMSPublicRootKey 値と一致することを確認します。
信頼されたルート キーを削除または置き換える
client.msi プロパティ を使用して、 RESETKEYINFORMATION = TRUEクライアントから信頼されたルート キーを削除します。
信頼されたルート キーを置き換えるには、クライアントを新しい信頼されたルート キーと共に再インストールします。 たとえば、クライアント プッシュを使用するか、client.msi プロパティ SMSPublicRootKey を指定します。
これらのインストール プロパティの詳細については、「 クライアント インストール のパラメーターとプロパティについて」を参照してください。
署名と暗号化
サイト内のすべてのクライアントがサポートできるサイト システムの最も安全な署名と暗号化の設定を構成します。 これらの設定は、クライアントが HTTP 経由で自己署名証明書を使用してサイト システムと通信できるようにする場合に特に重要です。
Configuration Manager コンソールで、[管理] ワークスペースに移動し、[サイトの構成] を展開し、[サイト] ノードを選択します。 構成するプライマリ サイトを選択します。
リボンで [ プロパティ] を選択し、[ 署名と暗号化 ] タブに切り替えます。
このタブは、プライマリ サイトでのみ使用できます。 [ 署名と暗号化 ] タブが表示されない場合は、中央管理サイトまたはセカンダリ サイトに接続していないことを確認します。
クライアントがサイトと通信するための署名と暗号化のオプションを構成します。
署名が必要: クライアントは、管理ポイントに送信する前にデータに署名します。
SHA-256 が必要: クライアントは、データの署名時に SHA-256 アルゴリズムを使用します。
警告
すべてのクライアントがこのハッシュ アルゴリズムをサポートしていることを最初に確認せずに SHA-256 を必要 としないでください。 これらのクライアントには、将来サイトに割り当てられる可能性のあるクライアントが含まれます。
このオプションを選択し、自己署名証明書を持つクライアントが SHA-256 をサポートできない場合、Configuration Managerは拒否します。 SMS_MP_CONTROL_MANAGER コンポーネントは、メッセージ ID 5443 をログに記録します。
暗号化を使用する: クライアントは、管理ポイントに送信する前にクライアント インベントリ データとステータス メッセージを暗号化します。
階層内のすべてのプライマリ サイトに対して、この手順を繰り返します。
ロールベース管理
ロールベースの管理では、セキュリティ ロール、セキュリティ スコープ、割り当てられたコレクションを組み合わせて、各管理ユーザーの管理スコープを定義します。 スコープには、ユーザーがコンソールで表示できるオブジェクトと、アクセス許可を持つオブジェクトに関連するタスクが含まれます。 ロールベースの管理構成は、階層内の各サイトに適用されます。
詳細については、「 ロールベースの管理を構成する」を参照してください。 この記事では、次のアクションについて詳しくは説明します。
カスタム セキュリティ ロールを作成する
セキュリティ ロールを構成する
オブジェクトのセキュリティ スコープを構成する
セキュリティを管理するコレクションを構成する
新しい管理ユーザーを作成する
管理ユーザーの管理スコープを変更する
重要
独自の管理スコープは、別の管理ユーザーに対してロールベースの管理を構成するときに割り当てることができるオブジェクトと設定を定義します。 ロールベースの管理の計画については、「ロールベースの管理 の基礎」を参照してください。
アカウントの管理
Configuration Managerは、さまざまなタスクと用途で Windows アカウントをサポートしています。 さまざまなタスク用に構成されたアカウントを表示し、アカウントごとに使用するパスワードConfiguration Manager管理するには、次の手順を使用します。
Configuration Manager コンソールで、[管理] ワークスペースに移動し、[セキュリティ] を展開して、[アカウント] ノードを選択します。
アカウントのパスワードを変更するには、一覧からアカウントを選択します。 次に、リボンの [プロパティ ] を選択します。
[ 設定 ] を選択して、[ Windows ユーザー アカウント] ダイアログ ボックスを開きます。 このアカウントで使用するConfiguration Managerの新しいパスワードを指定します。
注:
指定するパスワードは、Active Directory のこのアカウントのパスワードと一致している必要があります。
詳細については、「Configuration Managerで使用されるアカウント」を参照してください。
Microsoft Entra ID
Configuration ManagerをMicrosoft Entra ID と統合して、環境を簡素化し、クラウドを有効にします。 Microsoft Entra ID を使用して、サイトとクライアントの認証を有効にします。
詳細については、「Azure サービスの構成」の「Cloud Management サービス」を参照してください。
SMS プロバイダー認証
管理者がサイトにアクセスするための最小認証レベルConfiguration Manager指定できます。 この機能により、管理者は、Configuration Managerにアクセスする前に、必要なレベルで Windows にサインインできます。 詳細については、「 SMS プロバイダー認証の計画」を参照してください。
重要
この構成は、階層全体の設定です。 この設定を変更する前に、すべてのConfiguration Manager管理者が必要な認証レベルで Windows にサインインできることを確認してください。
この設定を構成するには、次の手順に従います。
最初に、目的の認証レベルで Windows にサインインします。
Configuration Manager コンソールで、[管理] ワークスペースに移動し、[サイトの構成] を展開し、[サイト] ノードを選択します。
リボンの [ 階層設定] を 選択します。
[ 認証 ] タブに切り替えます。目的の 認証レベルを選択し、[OK] を選択します。
- 必要な場合にのみ、[ 追加] を選択して特定のユーザーまたはグループを除外します。 詳細については、「 除外」を参照してください。
除外
[階層設定] の [ 認証 ] タブから、特定のユーザーまたはグループを除外することもできます。 このオプションは控えめに使用してください。 たとえば、特定のユーザーがConfiguration Manager コンソールへのアクセスを必要とするが、必要なレベルで Windows に対して認証できない場合などです。 また、システム アカウントのコンテキストで実行される自動化やサービスにも必要な場合があります。
次の手順
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示