MENU

Intune Company Portal for Linuxが表示されない原因と条件付きアクセス(CA)除外の対処法（Service Principal作成・PIM回避策）

Azure

Intune Company Portal for Linux のサインインログはあるのに、Microsoft Entra ID の「エンタープライズ アプリケーション」に出てこない。さらに条件付きアクセス(CA)で除外できず、Graph でも ServicePrincipalNotFound…という沼にハマりがちです。原因の切り分けと、実務で効いた対処・回避策を整理します。

目次

現象：Linux Company Portal の認証は発生しているのに「アプリが存在しない」ように見える

今回のポイントは、同じ「Intune Company Portal for Linux」でも、テナントによって サービス プリンシパル(Service Principal) の状態が異なり、結果として Microsoft Entra 管理センター上の見え方や、条件付きアクセス(CA)での扱いが変わることです。

観点テナントAテナントB管理上の影響
エンタープライズ アプリケーション表示「Microsoft Intune Company Portal for Linux」が表示される（作成日時: 2025/2/19）検索しても表示されないテナントBではGUIで属性編集・CA対象選択が進まない
サインインログ（通常どおり）「Microsoft Intune Company Portal for Linux」の認証イベントあり
AppId: b743a22d-6705-4147-8670-d92fa515ee2b		「使われているのに見えない」ため原因が分かりにくい
やりたいことカスタム セキュリティ属性付与→CAフィルターで利用同左テナントBでは ServicePrincipalNotFound 等で詰まりやすい

この状態で起きる典型的な困りごとは次の2つです。

  • カスタム セキュリティ属性を付けたくても、編集対象のエンタープライズ アプリ（=サービス プリンシパル）が見つからない
  • 条件付きアクセス(CA)で Linux Company Portal をブロック対象から除外したいのに、GUIでアプリ選択できない／Graphで除外を入れようとしても ServicePrincipalNotFound で失敗する

まず最初に押さえるべき「構造」：サインインログのAppIdと、テナント内のService Principalは別物として扱う

サインインログに表示される AppId（b743a22d-6705-4147-8670-d92fa515ee2b）は「その認証で参照されたアプリケーション」を示します。一方、エンタープライズ アプリケーション画面で操作できるのは、テナント内に存在するサービス プリンシパルです。

つまり、テナントBでは次のような状態になり得ます。

  • 認証は発生している（ログはある）
  • しかし、管理対象となるサービス プリンシパルがテナント内に作られていない／可視化されていない
  • その結果、GUIで見つからない・Graphで参照しても見つからない（ServicePrincipalNotFound）

切り分けの最短ルートは「テナントBに当該 AppId のサービス プリンシパルが存在するか」をまず確認することです。

Graphで存在確認（最短チェック）

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Directory.Read.All"

$appId = "b743a22d-6705-4147-8670-d92fa515ee2b"

# サービスプリンシパル確認（フィルターは最初はシンプルに）

$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -ConsistencyLevel eventual

$sp | Format-List Id,DisplayName,AppId,Tags

$sp が空なら「テナント内に SP がない（≒可視化されていない）」可能性が濃厚です。ここから先は、SPを明示的に作ることで前に進めます。

対処：テナントBにサービス プリンシパルを作成して可視化する

「Microsoft Intune Company Portal for Linux」をエンタープライズ アプリとして扱えるようにするには、AppId を指定してサービス プリンシパルを作成します。実務的には AzureAD/AzureADPreview ではなく、今後の互換性を考えて Microsoft Graph PowerShell を推奨します。

作業おすすめ手段最低限必要になりやすい権限（例）補足
Service Principal作成Microsoft Graph PowerShell（委任）Application.ReadWrite.All管理者による同意が必要な場合があります
存在確認・参照Microsoft Graph PowerShell（委任）Directory.Read.All読み取りだけならこちらで足りることが多い
カスタム セキュリティ属性の定義GUI（Entra管理センター）Attribute Definition Administrator 等組織のロール設計に合わせて最小権限に
カスタム セキュリティ属性の割り当てGUI/GraphAttribute Assignment Administrator 等定義と割り当ては別ロールで分離されがち

手順：Microsoft Graph PowerShellでサービス プリンシパルを作成

  1. PowerShellを管理者コンテキストで起動（運用ルールに従って実施）
  2. Microsoft Graph PowerShell を準備して接続
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Application.ReadWrite.All","Directory.Read.All"

$appId = "b743a22d-6705-4147-8670-d92fa515ee2b"

# 既に存在するか確認
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -ConsistencyLevel eventual

if (-not $sp) {
  # 存在しない場合は作成
  $sp = New-MgServicePrincipal -AppId $appId
}

$sp | Format-List Id,DisplayName,AppId,Tags
  1. Entra管理センターで確認
  • Microsoft Entra ID → エンタープライズ アプリケーション
  • 検索で Microsoft Intune Company Portal for Linux を確認

この時点で、少なくとも「アプリが見えない・属性編集ができない」という最初の詰まりは解消しやすくなります。

参考：AzureAD/AzureADPreview を使う場合（非推奨寄りの位置づけ）

既存スクリプト資産の都合で AzureAD/AzureADPreview を使うケースもありますが、モジュールのライフサイクル観点から新規はGraph寄りが無難です。どうしても使う場合は AppId 指定で SP を作成します。

Install-Module AzureADPreview -Scope CurrentUser
Connect-AzureAD

New-AzureADServicePrincipal -AppId "b743a22d-6705-4147-8670-d92fa515ee2b"

カスタム セキュリティ属性を付与してCAの「フィルター」で扱えるようにする

今回の目的のひとつが「このアプリにカスタム セキュリティ属性を付与し、条件付きアクセス(CA)のフィルター条件で使う」ことです。手順は大きく 定義 と 割り当て に分かれます。

手順：属性を定義する（Entra管理センター）

  1. Microsoft Entra 管理センター → 「カスタム セキュリティ属性」へ移動
  2. 属性セット（例：CAFilter）を作成
  3. 属性（例：LinuxEnrollmentException）を作成
    • 型は運用に合わせて（文字列/ブールなど）
    • 「許可する値」を絞れる場合は絞る（運用ミス防止）

手順：対象アプリ（サービス プリンシパル）に属性を割り当てる

  1. Microsoft Entra ID → エンタープライズ アプリケーション → Microsoft Intune Company Portal for Linux を開く
  2. 「カスタム セキュリティ属性」の割り当て画面から、先ほどの属性セット/属性に値を設定
  3. CA 側で「アプリのフィルター」条件にその属性を利用

ここで重要なのは、そもそもサービス プリンシパルがテナントに存在しないと割り当て自体ができない点です。今回の「見えない問題」は、まさにこの前提で詰まります。

次の壁：条件付きアクセス(CA)でアプリを選べない（GUIに出ない）問題

サービス プリンシパルを作ってエンタープライズ アプリに表示されるようになっても、条件付きアクセスのポリシー編集画面で、対象/除外アプリの検索に Linux Company Portal が出てこないことがあります。

実務上は、Graph からサービス プリンシパルに特定のタグを付けることで、CA のアプリ選択画面に現れるようになるケースがあります。

手順：サービス プリンシパルにタグを付与する（Microsoft Graph PowerShell）

ポイントは 既存の Tags を壊さずに追加することです。上書きすると、別用途のタグが消えて別の副作用を生むことがあります。

Connect-MgGraph -Scopes "Application.ReadWrite.All","Directory.Read.All"

$appId = "b743a22d-6705-4147-8670-d92fa515ee2b"
$tagToAdd = "WindowsAzureActiveDirectoryCustomSingleSignOnApplication"

$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'" -ConsistencyLevel eventual
if (-not $sp) {
  throw "Service Principalが見つかりません。先にNew-MgServicePrincipalで作成してください。"
}

# 既存タグを保持しつつ追加（重複は排除）
$tags = @()
if ($sp.Tags) { $tags += $sp.Tags }
if ($tags -notcontains $tagToAdd) { $tags += $tagToAdd }

Update-MgServicePrincipal -ServicePrincipalId $sp.Id -BodyParameter @{ tags = $tags }

# 確認
(Get-MgServicePrincipal -ServicePrincipalId $sp.Id).Tags

これで CA ポリシーの「クラウド アプリ」選択や「除外」画面で Microsoft Intune Company Portal for Linux が検索に出てくるようになることがあります。

項目タグ付与前タグ付与後期待する変化
エンタープライズ アプリに表示表示される/されない（テナント依存）表示される属性編集が可能になる
CAのアプリ選択（GUI）検索に出ないことがある検索に出ることがある除外指定がGUIで可能になる

注意：タグ操作は「万能の公式手順」として常に保証されるものではなく、テナントの状態やMicrosoft側の内部実装変更で挙動が変わる可能性があります。必ず検証テナントで確認し、変更履歴を残してから本番適用してください。

それでもCA除外が効かずブロックされるケース：なぜ起きるのか、どう切り分けるか

ここが一番ハマりやすいところです。やっていることとしては正しそうに見えます。

  • サービス プリンシパルを作成した
  • CAのGUIにアプリが出るようにした
  • 「すべてのアプリ(include All)」のブロックポリシーで、Linux Company Portal を除外に指定した

それでも Linux Company Portal からのサインインがブロックされ続けることがあります。

最重要：ブロックされている「実際のクラウドアプリ」が別である可能性

Linux Company Portal は単体で完結せず、バックエンドの別サービス（別クラウドアプリ）に対してトークン取得やAPI呼び出しを行うことがあります。その結果、CA の評価対象が「Company Portal」ではなく、別のリソース側アプリになっていると、Company Portal の除外だけではブロックが解けません。

この切り分けは、サインインログを「イベント単位で」丁寧に見るのが最短です。

切り分け手順：サインインログで“どのアプリにCAが掛かったか”を特定する

  1. Microsoft Entra 管理センター → サインインログ
  2. 対象ユーザー、OS（Linux）、失敗（ブロック）でフィルター
  3. 該当イベントを開き「条件付きアクセス」タブを確認
見る場所確認ポイント意味次のアクション
アプリケーション名 / AppIdブロックされたイベントのAppが本当にLinux Company Portalか除外すべき対象のズレを見つける別AppIdなら、そのアプリも除外候補に入れる/ポリシー設計を変える
条件付きアクセスの結果どのCAポリシーでブロックされたか意図していないポリシーが当たっていないか確認対象ユーザー/対象アプリ/条件の見直し
クライアントアプリブラウザー/モバイル/その他クライアント等「その他クライアント」条件が広すぎると巻き込みやすいクライアントアプリ条件の絞り込み
相関ID（Correlation ID）関連するサインインイベントを追跡連鎖する別アプリ呼び出しの特定に有効相関IDでログ検索し、どのリソースで止まっているか見る

ServicePrincipalNotFound が出るときの実務メモ

Graph で CA 例外設定を入れようとして ServicePrincipalNotFound になる場合、典型は次のどれかです。

  • そもそもテナントにサービス プリンシパルが存在しない（まず作成が必要）
  • 対象にしているのが「アプリケーション(アプリ登録)」で、CAが参照する「サービス プリンシパル」と取り違えている
  • 複数の関連アプリがあり、除外すべき AppId が別にある

まずは「対象 AppId の SP が存在するか」「ブロックされたイベントの AppId は何か」を確定させると、迷路から抜けられます。

現実的な回避策：アプリ除外にこだわらず、PIMグループで“登録時だけ”CAを一時解除する

スレッド内で最終的に採用された実務的な落としどころが、アプリ単位の除外ではなく、ユーザー/グループ単位の除外です。特に「Linuxデバイス登録の瞬間だけブロックを緩めたい」「でも誰でも登録できる状態は避けたい」という要件にフィットします。

狙い

  • 通常時：Linux からのサインインは原則ブロック（セキュア）
  • 登録作業時のみ：限られたユーザーが、短時間だけ例外を得て登録できる
  • 例外の付与/解除を自動化（有効期限で戻る）し、監査ログも残せる

構成：PIMグループ + CA除外

要素例設定のコツ期待する効果
CA除外用グループCA-Exclude-LinuxEnrollment用途を名前に明記し、メンバー直追加を禁止運用にCAの例外をユーザー単位で制御
ブロックCAポリシー対象: 全ユーザー/全アプリ、プラットフォーム: Linux、制御: Block除外に上記グループを指定グループに入っている間だけブロック回避
PIMグループメンバーシップを eligible 化有効化にMFA/理由/承認を要求、最短30分などの短時間に「必要な時だけ例外」を実現

手順：管理者側（設計〜セットアップ）

  1. Entra IDでグループを作成（例：CA-Exclude-LinuxEnrollment）
  2. Linuxブロック用のCAポリシーを用意し、「ユーザーとグループ → 除外」に当該グループを設定
  3. PIMで当該グループを管理対象にし、対象ユーザーを eligible で割り当て
  4. PIMの有効化ルールを決める（例：MFA必須、理由入力必須、必要なら承認必須、有効時間30〜60分など）

手順：ユーザー側（登録のたびに行う運用）

  1. Linux端末を登録する直前に、PIMから CA-Exclude-LinuxEnrollment をアクティブ化
  2. 有効化時間内に Company Portal で登録作業を完了
  3. 時間切れで自動的に例外が外れ、以降は通常どおりLinuxブロックに戻る

この方式の良さは、アプリ除外の不安定さに引きずられず、「登録できる人」を統制しながら、作業時間だけ確実に通す運用に落とし込める点です。監査上も「誰がいつ例外を有効化したか」が追えるため、セキュリティと運用のバランスを取りやすくなります。

実務でのCA設計ヒント：Linuxブロックは“強い”ので、意図しない巻き込みを避ける

「プラットフォーム: Linux」「対象アプリ: すべて」「ブロック」は非常に強力です。強力ゆえに、次のような巻き込みが起きやすい点は意識しておくとトラブルが減ります。

  • 登録だけでなく、管理者の調査（ログ確認、Graph操作、ポータル操作）までLinux環境からできなくなる
  • 例外アプリが増えて、運用が“除外だらけ”になって破綻する
  • 結果として「一時的に全部オフ」という危険な運用に流れやすい

そこで、次のような設計に寄せると安定します。

  • 「原則ブロック」は維持しつつ、例外は アプリよりユーザー（PIM）で管理する
  • 例外付与の条件をPIM側（MFA、理由、承認、有効時間）に寄せる
  • CAの「What If」やサインインログで、ブロックの根拠が説明できる状態を保つ

Linux Company Portal / エージェント側の注意点：登録できてもチェックインが不安定ならOS側も見る

スレッド内コメントとして、Linux側の実務注意点も挙がっています。登録（Enrollment）が通っても、運用フェーズで「チェックイン失敗」「動作が重い」となると結局つらいので、初期段階で押さえておくと後が楽です。

よくある症状

  • エージェントが Java（JDK 11）系で動作しており、プロセスのメモリ使用量が増え続けるように見える
  • systemd のサービスが自動起動しておらず、再起動後にチェックインが止まる
  • クラッシュしても自動復旧せず、手動での再起動が必要になる

運用で効きやすい対策の方向性

環境によりサービス名や配置は異なるため、まずは systemctl で該当サービスを特定してください（例：microsoft-intune-agent 等）。そのうえで、次のような考え方で安定化を図ります。

観点対応例狙い注意点
自動起動systemctl enable --now <service>再起動後のチェックイン停止を防ぐ他の依存関係（ネットワーク、証明書等）も確認
再起動ポリシーsystemdで Restart=always 等クラッシュ時の自動復旧クラッシュループ時はログ肥大化に注意
メモリ制御JAVA_OPTS で上限、または systemd のリソース制御メモリ暴走の影響を抑える上限を低くしすぎると動作不安定になる

systemdの上書き設定（例：考え方のサンプル）

既存ユニットファイルを直接編集せず、overrideで上書きするのが安全です。

# 例：override編集（サービス名は環境に合わせて置き換え）
sudo systemctl edit <service>

# エディタが開いたら例として以下のような方針で設定
[Service]
Restart=always
RestartSec=10
Environment="JAVA_OPTS=-Xms128m -Xmx512m"

さらに厳密にやるなら、systemd側のリソース制御（MemoryMax 等）も検討対象ですが、まずは「自動起動」「再起動」「ログ確認」の3点セットが現場では効きやすいです。

トラブルシュートのチェックリスト：詰まりポイントを順番に潰す

最後に、今回の「見えない／CAで扱えない」問題を、現場で手戻りなく進めるためのチェックリストをまとめます。

フェーズチェック項目OKの目安NGなら次にやること
事実確認サインインログに該当AppIdが出ているかb743a22d-6705-4147-8670-d92fa515ee2b が確認できるログフィルター（ユーザー/時間/OS/失敗）を見直す
SP存在確認テナント内に当該AppIdのService PrincipalがあるかGraphで Get-MgServicePrincipal が返るNew-MgServicePrincipal -AppId で作成
可視化エンタープライズ アプリに表示されるか検索で見つかる作成結果（Id/DisplayName）を再確認
CA選択CAポリシー編集画面でアプリ検索に出るかアプリ選択/除外に現れるタグ付与を検討（既存タグ保持に注意）
CA除外効果除外してもブロックされないか登録/サインインが通るブロックされたイベントの“実際のアプリ”をログで特定
最終回避PIMグループで登録時のみ例外化できるか短時間だけ例外が動くCA設計をユーザー例外中心に寄せる

まとめ：この順番で進めると、最短で「管理できる状態」に到達できる

  • サインインログに AppId b743a22d-6705-4147-8670-d92fa515ee2b が出ているのにエンタープライズ アプリに見えない場合、まず サービス プリンシパルがテナントに存在するかをGraphで確認し、なければ作成する
  • サービス プリンシパルができれば、カスタム セキュリティ属性の付与など「管理対象としての操作」が可能になる
  • CAのGUIでアプリを選べない場合は、Graphで タグ付与により選択できるようになるケースがある（既存タグの保持が重要）
  • それでもCA除外が効かない場合は、ブロックされている実体が別アプリである可能性を疑い、サインインログで“どのアプリにCAが掛かったか”をイベント単位で特定する
  • 根本解決が難しい／登録時だけ確実に通したい場合は、PIMグループ方式でユーザー単位に短時間例外を付与する運用が、現時点で現実的かつセキュアに成立しやすい
Azure
Linux Intune Microsoft Graph Entra ID Company Portal 条件付きアクセス PIM

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次