Cisco ISE on Azure を Marketplace からデプロイしたあと、Azure Portal 上で VM が running になっていても、それだけで Cisco ISE として利用可能になったとは判断できません。Azure 側の VM 起動、ネットワーク到達性、ISE アプリケーションの起動、管理 UI への到達は、分けて確認する必要があります。
この記事では、Cisco Identity Services Engine （ISE）を Azure 上にデプロイした直後に、何を確認すれば次の設定フェーズへ進めるのかを整理します。対象は、RADIUS / TACACS+、証明書、ポリシー設定に入る前の初期確認です。
結論から言えば、デプロイ後は Azure リソースの作成、NSG と経路、SSH 接続、show application status ise、管理 UI を順番に確認します。特に重要なのは、Azure Portal の VM 状態ではなく、ISE 側のアプリケーション状態を見ることです。
書籍
Cisco ISE / Azure / RADIUS 設計の参考書籍
Cisco ISE、RADIUS、NAC、クラウド上のネットワーク設計を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
Azure Portal の running と ISE の起動完了は別である
Azure Portal で VM が実行中になっていることは、OS レベルで起動していることを示します。しかし、Cisco ISE はその上で複数の内部サービスを起動します。Database、Application Server、M&T、API Gateway、pxGrid、Profiler、証明書関連サービスなどが順番に立ち上がるため、VM が起動してから ISE として利用可能になるまでには時間差があります。
そのため、デプロイ直後に管理 UI へアクセスできない場合でも、すぐに失敗と判断するのは早いです。まず SSH でノードに入り、ISE アプリケーションの状態を確認します。
| 確認対象 | 見ること | 失敗時に疑う場所 |
|---|---|---|
| Azure VM | VM が作成され、running になっているか | デプロイ失敗、VM サイズ、ディスク、リージョン制約 |
| ネットワーク | Private IP、Subnet、NSG、経路、DNS、NTP | NSG、ルートテーブル、名前解決、時刻同期 |
| SSH | iseadmin で接続できるか | SSH 鍵、NSG、送信元制限、管理経路 |
| ISE アプリケーション | show application status ise の主要サービス | 初回起動中、内部サービス異常、リソース不足 |
| 管理 UI | https://<ISE の IP または FQDN> に到達できるか | HTTPS 許可、証明書、ISE 起動未完了 |
Marketplace の選択肢を間違えない
Azure Marketplace では、Cisco ISE に関連する複数の選択肢が表示されることがあります。名称が似ているため、ISE 本体を Azure に建てたいのか、ログ連携や周辺機能を使いたいのかを分けて見る必要があります。
| 選択肢 | 位置づけ | 注意点 |
|---|---|---|
| Cisco Identity Services Engine （ISE） Azure Application | Azure Application として ISE ノードをデプロイする選択肢 | Marketplace テンプレートで入力項目が整理される |
| Cisco Identity Services Engine （ISE） Virtual Machine | VM イメージとして ISE をデプロイする選択肢 | user-data など、初期設定の自由度が高い場合がある |
| Cisco Identity Services Engine （ISE） SaaS | SaaS として ISE を利用する選択肢 | ネットワーク配置や責任分界が VM 版とは異なる |
| Cisco ISE Azure Application | ISE ログ連携や Microsoft Sentinel 連携系の名称として出る場合がある | ISE 本体のデプロイと混同しない |
この記事では、Azure 上に ISE ノードを作り、デプロイ直後の起動状態を確認する観点に絞ります。Marketplace の提供形態は変わる可能性があるため、実際に選択する時は提供元、製品名、説明、作成される Azure リソースを確認してください。
まず Azure 側のリソースを確認する
デプロイ完了後、最初に見るのは ISE の画面ではなく、Azure 側のリソースです。VM、NIC、ディスク、NSG、Public IP の有無、Private IP、Subnet、Route Table を確認します。
| 項目 | 確認内容 |
|---|---|
| VM | 対象 VM が作成され、Power state が running になっているか |
| NIC / IP | Private IP が想定通りか。固定 IP として使うなら変更されない設計になっているか |
| NSG | 管理元から SSH と HTTPS が許可されているか。RADIUS / TACACS+ を後で使う場合の通信設計と混ざっていないか |
| Route Table | 管理端末やオンプレミス側から ISE の Private IP へ到達できる経路があるか |
| DNS / NTP | ISE が名前解決と時刻同期に使うサーバーへ到達できるか |
Microsoft の NSG は、サブネットや NIC に関連付けて通信を許可または拒否する仕組みです。ISE の初期確認では、まず管理元から SSH と HTTPS が通ることを確認します。RADIUS / TACACS+ 用の通信は、初期ログイン後の設計で改めて整理した方が安全です。
SSH で ISE ノードに入る
Azure 側の VM とネットワークに問題がなければ、ISE ノードへ SSH で接続します。ここでは例として、秘密鍵 ise-ssh-key と ISE の Private IP 192.168.0.100 を使います。
ssh -i ise-ssh-key iseadmin@192.168.0.100SSH 接続できることは、OS レベルでは起動しており、管理経路が通っていることの確認になります。ただし、ここで止めてはいけません。SSH が通ることと、ISE アプリケーションが起動完了していることは別です。
show application status ise で起動状態を見る
SSH 接続後、最も重要なのが show application status ise です。ISE の内部サービスが起動しているかを確認します。
show application status ise初回起動直後は、すべてのサービスがすぐ running になるわけではありません。starting、not running、disabled が混在することがあります。disabled は機能が無効であることを示す場合もあるため、disabled があるだけで異常とは限りません。重要なのは、利用に必要な主要サービスが起動しているかです。
ISE PROCESS NAME STATE
------------------------------------------------
Database Listener running
Database Server running
Application Server running
M&T Session Database running
M&T Log Processor running
Certificate Authority Service running
ISE Messaging Service running
ISE API Gateway Service running
Protocols Engine running上記のように主要サービスが running になっていれば、ISE としての起動はかなり進んでいます。実際の出力では、pxGrid、Profiler、PassiveID、Prometheus、Grafana、SXP、Duo、Meraki 連携など、利用機能に応じて enabled / disabled が分かれます。使わない機能が disabled であること自体は問題ではありません。
application start ise は最初に打つコマンドではない
ISE には application start ise というコマンドがあります。ただし、デプロイ直後に管理 UI が見えないからといって、反射的に実行するものではありません。
application start ise初回起動時は、内部サービスの初期化に時間がかかります。まず show application status ise を何度か確認し、状態が進んでいるのか、まったく変化していないのかを見ます。起動処理が進んでいる途中で余計な操作を重ねると、かえって切り分けが難しくなります。
長時間まったく状態が変わらない、主要サービスが停止したまま戻らない、ログ上明確に失敗している、という場合に、再起動や application start を検討します。通常の確認では、まず待つことと状態を見ることが重要です。
管理 UI へアクセスする
ISE の主要サービスが running になったら、管理 UI にアクセスします。Private IP で確認する場合は、次のような URL になります。
https://192.168.0.100FQDN を使う場合は、DNS の向き先と証明書の名前も関係します。初期確認では IP アドレスで到達性を確認し、その後に FQDN、証明書、管理用 DNS 名を整えると切り分けやすくなります。
管理 UI に到達できない場合は、ISE アプリケーションが起動しているか、NSG で HTTPS が許可されているか、管理端末から Private IP へ経路があるか、ブラウザーが証明書警告で止まっていないかを確認します。
次の設計フェーズへ進む前に見ること
管理 UI に入れたら、すぐ RADIUS / TACACS+ の設定へ進む前に、基盤としての前提を確認します。ここを飛ばすと、後続の認証トラブルが Azure 側の問題なのか、ISE 側の問題なのか、証明書や時刻同期の問題なのか分かりにくくなります。
| 確認項目 | 理由 |
|---|---|
| 時刻同期 | RADIUS、証明書、ログの整合性に影響する |
| DNS | AD / LDAP、証明書、FQDN、外部連携に影響する |
| 証明書 | 管理 UI、EAP、pxGrid、外部連携の信頼境界になる |
| ライセンス | 機能利用と評価期間の前提になる |
| バックアップ | 初期設定前後の戻し先を作る |
| 管理経路 | 障害時に ISE へ到達できる経路を確保する |
Cisco ISE は認証基盤です。認証基盤が不安定だと、利用者やネットワーク機器側の問題に見えても、実際には DNS、NTP、証明書、管理経路の問題だったということが起こります。初期確認では、まず ISE を安定して管理できる状態にすることが大切です。
まとめ
Cisco ISE on Azure のデプロイ後確認では、Azure Portal 上の VM 状態だけを見て終わらせないことが重要です。VM が running であること、管理経路が通ること、SSH で接続できること、ISE アプリケーションの主要サービスが running であること、管理 UI に到達できることを順番に確認します。
特に show application status ise は、Azure 上で ISE が本当に利用可能になっているかを見るための中心的な確認です。管理 UI が開かない時も、まずこのコマンドで内部サービスの状態を見れば、単なる待ち時間なのか、ネットワーク到達性の問題なのか、ISE 側の起動問題なのかを分けやすくなります。
ここまで確認できれば、証明書設計、AD / LDAP 連携、RADIUS / TACACS+、ポリシーセット、ERS、pxGrid などの設計フェーズへ進む準備が整った状態と言えます。
参考情報
参考：
関連する記事
あわせて読みたい：
関連記事
Cisco ルーターの初期設定 – SSH、enable secret、VTY を最初に整える
Cisco BGP の基本設定 – neighbor / network / AS 番号と経路広告を確認する
Cisco HSRP と Object Tracking – デフォルトゲートウェイ冗長化で上流障害を反映する
Cisco コンフィグ変更に正規表現を使う – 既存設定から投入用コンフィグを作る
Cisco 1812J のコンパクトフラッシュ交換 – IOS イメージと起動メディアを扱う
Cisco ルーターのリンクアグリゲーション – EtherChannel / Port-Channel を L3 uplink として使う
Cisco Nexus で no feature lldp が再起動後に戻る理由 – LLDP 無効化と設定永続化
10GBASE-T と 10GBASE-SR を両方使う Cisco スイッチ選定 – RJ45、SFP+、光モジュールを分けて考える