アクセスとアクセス許可に関する問題のトラブルシューティング

[アーティクル]
02/23/2025

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure DevOps の広範なセキュリティとアクセス許可の構造により、ユーザーが期待するプロジェクト、サービス、または機能へのアクセス権がない理由を調査することが必要になる場合があります。プロジェクトに接続するとき、または Azure DevOps のサービスまたは機能にアクセスするときにユーザーに発生する可能性がある問題を理解し、対処するための詳細なガイダンスを見つけます。

必須コンポーネント

カテゴリ	要件
アクセス許可	組織またはコレクションレベルでアクセス許可またはグループを管理するには:プロジェクトコレクション管理者のメンバーセキュリティグループ。組織またはコレクションを作成した場合は、自動的にこのグループのメンバーになります。
推奨	このガイドを使用する前に、次の内容を理解することをお勧めします。 - アクセス許可とセキュリティグループの設定を始めましょう - 既定の権限とアクセスに関するクイックリファレンス

ヒント

Azure DevOps セキュリティグループを作成するときは、アクセスを制限することを目的としているかどうかを示すラベルを明確に付けます。

アクセス許可は次のレベルで設定できます。

オブジェクトレベル
プロジェクトレベル
組織またはプロジェクトのコレクションレベル
セキュリティロール
チーム管理者ロール

アクセスとアクセス許可に関するよくある問題

プロジェクトメンバーがプロジェクト、サービス、または機能にアクセスできない最も一般的な理由を確認します。

問題	トラブルシューティング方法
メンバーのアクセスレベルがサービスまたは機能へのアクセスをサポートしていない。	それが原因かどうかを判断するには、ユーザーのアクセスレベルとサブスクリプションのステータスを確認します。
セキュリティグループ内のメンバーシップで、機能へのアクセスがサポートされていないか、機能へのアクセス許可が明示的に拒否された。	それが原因かどうかを判断するには、アクセス許可をトレースします。
ユーザーに最近アクセス許可が付与されたが、変更を認識するにはクライアントの更新が必要である。	ユーザーにアクセス許可を更新または再評価してもらいます。
ユーザーは特定のチームのチーム管理者にのみ付与された機能を実行しようとしているが、そのロールが付与されていない。	チーム管理者をロールに追加するには、「チーム管理者を追加または削除する」を参照してください。
ユーザーがプレビュー機能を有効にしていなかった。	ユーザーにプレビュー機能を開いてもらい、特定の機能のオン/オフステータスを確認してもらいます。詳細については、「プレビュー機能の管理」を参照してください。
プロジェクトメンバーが、[プロジェクトスコープのユーザー] グループなどの制限付きスコープセキュリティグループに追加された。	それが原因かどうかを判断するには、ユーザーのセキュリティグループメンバーシップを検索します。

アクセスとアクセス許可に関するそれほど一般的ではない問題

アクセスが制限されるそれほど一般的ではない理由は、次のいずれかのイベントが発生した場合です。

問題	トラブルシューティング方法
プロジェクト管理者がサービスを無効にしました。この場合、無効化されたサービスには誰もアクセスできません。	サービスが無効になっているかどうかを判断するには、「Azure DevOps サービスを有効または無効にする」を参照してください。
プロジェクトコレクション管理者がプレビュー機能を無効にしたため、組織内のすべてのプロジェクトメンバーに対して無効になっています。	「プレビュー機能の管理」を参照してください。
ユーザーのアクセスレベルまたはプロジェクトメンバーシップを管理するグループルールがアクセスを制限しています。	「ユーザーのアクセスレベルとサブスクリプションのステータスを確認する」を参照してください。
カスタムルールが作業項目タイプのワークフローに対して定義されました。	「選択操作を制限する作業項目タイプに適用されるルール」を参照してください。

ユーザーのアクセスレベルとサブスクリプションのステータスを確認する

ユーザーまたはユーザーのグループは次のいずれかのアクセスレベルに割り当てることができます。

利害関係者
Basic
Basic + Test プラン
Visual Studio サブスクリプション

Azure DevOps でのアクセスレベルの制限の詳細については、「サポートされているアクセスレベル」を参照してください。

Azure DevOps 機能を使用するには、適切なアクセス許可を持つセキュリティグループにユーザーを追加し、Web ポータルにアクセスできる必要があります。機能の制限は、ユーザーのアクセスレベルとセキュリティグループに基づいています。

ユーザーは、次の理由でアクセスできなくなる可能性があります。

アクセスできなくなる理由	トラブルシューティング方法
ユーザーの Visual Studio サブスクリプションの有効期限が切れた。	一方、このユーザーは関係者として作業することができ、ユーザーがサブスクリプションを更新するまでユーザーに Basic アクセス権を付与することもできます。ユーザーがサインインすると、Azure DevOps は自動的にアクセスを復元します。
課金に使用される Azure サブスクリプションがアクティブでなくなった。	このサブスクリプションで行われたすべての購入は、Visual Studio サブスクリプションを含めて影響を受けます。この問題を解決するには、Azure アカウントポータルにアクセスしてください。
課金に使用されていた Azure サブスクリプションが組織から削除された。	組織のリンクに関する詳細情報を確認してください。

それ以外の場合、カレンダー月の最初の日に、最も長い時間組織にサインインしなかったユーザーが最初にアクセスできなくなります。アクセスが不要になったユーザーが組織にいる場合は、ユーザーを組織から削除します。

アクセス許可の詳細については、「アクセス許可とグループ」と「アクセス許可検索ガイド」を参照してください。

アクセス許可をトレースする

アクセス許可トレースを使用して、ユーザーのアクセス許可が特定の機能へのアクセスを許可していない理由を判断します。ユーザーまたは管理者がアクセス許可の継承を調査する方法について確認します。 Web ポータルからアクセス許可をトレースするには、対応するレベルのアクセス許可またはセキュリティのページを開きます。詳細については、「アクセス許可レベルの引き上げを要求する」を参照してください。

ユーザーにアクセス許可の問題があり、アクセス許可に既定のセキュリティグループまたはカスタムグループを使用している場合は、トレースを使用してそれらのアクセス許可の取得元を調査します。アクセス許可の問題は変更の遅延が原因である可能性があります。 Microsoft Entra グループメンバーシップまたはアクセス許可の変更が Azure DevOps 全体に反映されるまでに最長で 1 時間かかることがあります。すぐに解決しない問題が発生したユーザーに発生している場合は、1 日待って解決するかどうかを確認します。ユーザーとアクセスの管理の詳細については、「Azure DevOps でユーザーとアクセスを管理する」を参照してください。

ユーザーにアクセス許可の問題があり、アクセス許可に既定のセキュリティグループまたはカスタムグループを使用している場合は、アクセス許可トレースを使用してこれらのアクセス許可の取得元を調査できます。アクセス許可の問題は、ユーザーに必要なアクセスレベルがないことが理由である可能性があります。

ユーザーは、有効なアクセス許可を直接またはグループ経由で受け取ることができます。

管理者がこれらのアクセス許可の取得元を正確に把握し、必要に応じて調整できるように、次の手順を実行します。

[プロジェクト設定]>[アクセス許可]>[ユーザー] の順に選択してからユーザーを選択します。

これで、ユーザー固有のビューが表示され、ユーザーが持っているアクセス許可が表示されます。
一覧表示されているアクセス許可をユーザーが持っている、または持っていない理由をトレースするには、該当するアクセス許可の横にある情報アイコンを選択します。

結果のトレースを使用すると、一覧表示されているアクセス許可を継承している方法を確認できます。その後、ユーザーが参加しているグループに提供されるアクセス許可を調整することで、ユーザーのアクセス許可を調整できます。

[プロジェクト設定]>[セキュリティ] の順に選択し、フィルターボックスにユーザー名を入力します。

これで、ユーザー固有のビューが表示され、ユーザーが持っているアクセス許可が表示されます。
一覧表示されているアクセス許可をユーザーが持っている、または持っていない理由をトレースします。アクセス許可にカーソルを合わせて [理由] を選択します。

継承されたアクセス許可を示すトレースのスクリーンショット、Azure DevOps Server 2019。

詳細については、「特定の機能や関数へのアクセスを管理する」または「アクセス許可レベルの引き上げを要求する」を参照してください。

アクセス許可を更新または再評価する

アクセス許可の更新または再評価が必要になる可能性がある次のシナリオを参照してください。

問題

ユーザーは Azure DevOps または Microsoft Entra グループに追加されます。このアクションにより、継承されたアクセス権が組織またはプロジェクトに付与されます。しかし、すぐにはアクセスできません。ユーザーは、待つか、サインアウトし、ブラウザーを閉じてからサインインし直して、アクセス許可を更新する必要があります。

ユーザーは Azure DevOps グループに追加されます。このアクションにより、継承されたアクセス権が組織またはプロジェクトに付与されます。しかし、すぐにはアクセスできません。ユーザーは、待つか、サインアウトし、ブラウザーを閉じてからサインインし直して、アクセス許可を更新する必要があります。

ソリューション

[ユーザー設定]>[アクセス許可]>[Re-evaluate permissions] (アクセス許可の再評価) に移動します。この機能により、グループメンバーシップとアクセス許可が再評価された後、最近の変更がすぐに有効になります。

選択操作を制限する作業項目タイプに適用されるルール

プロセスをカスタマイズする前に、「Azure Boards の構成とカスタマイズ」を確認することをお勧めします。ここでは、ビジネスニーズに合わせて Azure Boards をカスタマイズする方法に関するガイダンスを提供しています。

操作の制限に適用される作業項目タイプルールの詳細については、次を参照してください。

組織の設定をユーザーに対して非表示にする

ユーザーが自分のプロジェクトのみを表示するように制限されている場合、または組織の設定にアクセスできない場合は、次の情報からその理由がわかる可能性があります。ユーザーが組織の設定にアクセスできないようにするには、[ユーザーの可視性と共同作業を特定のプロジェクトに限定する] プレビュー機能を有効にします。重要なセキュリティ関連の注意事項などについて詳しくは、組織の管理、プロジェクトのユーザーの可視性の制限、その他をご覧ください。

制限付きユーザーの例として、利害関係者、Microsoft Entra ゲストユーザー、セキュリティグループのメンバーなどがあります。有効になると、プロジェクトスコープのユーザーグループに追加されたユーザーまたはグループは、 [概要] と [プロジェクト] を除く [組織の設定] ページへのアクセスが制限されます。追加先のプロジェクトにのみアクセスできます。

制限付きユーザーの例として、利害関係者やセキュリティグループのメンバーなどがあります。有効になると、プロジェクトスコープのユーザーグループに追加されたユーザーまたはグループは、 [概要] と [プロジェクト] を除く [組織の設定] ページへのアクセスが制限されます。追加先のプロジェクトにのみアクセスできます。

詳細については、「組織の管理、プロジェクトのユーザーの可視性の制限、その他」を参照してください。

CLI を使用してアクセス許可を表示、追加、管理する

az devops security permission コマンドを使用して、きめ細かいレベルでアクセス許可を表示、追加、管理できます。詳細については、「コマンドラインツールを使用して権限を管理する」を参照してください。

アクセス許可がより低いグループルール

グループルールの種類は、サブスクライバー > Basic + Test Plans > Basic > 利害関係者の順にランク付けされます。ユーザーは常に、Visual Studio (VS) サブスクリプションを含むすべてのグループルールで使用できる最高レベルのアクセスレベルを受け取ります。

Note

グループルールを通じてプロジェクトリーダーに加えられた変更は保持されません。プロジェクトリーダーを調整するには、直接割り当てやカスタムセキュリティグループなどの代替方法を検討してください。
[ユーザー] ページの [グループルール] タブに表示されているルールを定期的に確認します。 Microsoft Entra ID グループメンバーシップの変更は、グループルールの次回の再評価に表示されます。これは、グループルールが変更されたときにオンデマンドで実行することも、24 時間ごとに自動的に行うこともできます。 Azure DevOps では 1 時間ごとに Microsoft Entra グループメンバーシップを更新しますが、Microsoft Entra ID が動的グループメンバーシップに更新されるまでに最長で 24 時間かかる場合があります。

サブスクライバー検出でグループルールをどのように考慮するかを示す、次の例を参照してください。

例 1: グループルールによりさらに多くのアクセス権が付与される

VS Pro サブスクリプションがあり、Basic + Test Plans を付与するグループルールに参加している場合、どうなりますか?

想定される結果: グループルールが付与する内容が自分のサブスクリプションよりも大きいため、Basic + Test Plans が付与されます。グループルールの割り当てでは、アクセスを制限するのではなく、常により大きいアクセス権が付与されます。

例 2: グループルールによって同じアクセス権が付与される

Visual Studio Test Pro サブスクリプションがあり、Basic + Test Plans を付与供するグループルールに含まれている場合、どうなりますか?

想定される結果: アクセス権がグループルールと同じであるため、Visual Studio Test Pro サブスクライバーとして検出されます。 Visual Studio Test Pro の料金は既に支払っているので、もう一度支払いたくありません。

GitHub を使用する

GitHub を使用して Azure DevOps にコードをデプロイする場合は、次のトラブルシューティング情報を参照してください。

問題

メンバーとして追加しても、チームの残りのメンバーを組織やプロジェクトに取り込めません。メールは届きますが、サインインすると 401 エラーが発生します。

ソリューション

正しくない ID で Azure DevOps にサインインしている可能性があります。手順は次のとおりです。

Azure DevOps を実行していないブラウザーを含め、すべてのブラウザーを閉じます。
プライベートまたはシークレット閲覧セッションを開きます。
次の URL に移動します: https://aka.ms/vssignout

「サインアウト中」というメッセージが表示されます。サインアウトすると dev.azure.microsoft.com にリダイレクトされます。
Azure DevOps に再度サインインして別の ID を選択します。

次の方法で共有

アクセスとアクセス許可に関する問題のトラブルシューティング

必須コンポーネント