About skobayashi

Symptoms キャプティブ ポータル(CP)  ユーザーは始めに必ずユーザー名とパスワードを入力することになります。しかし、キャプティブ ポータル ユーザーがHTTPS ウェブ サイトを訪問するとき、ユーザー名とパスワードを入力するページに遷移しません。結果として、パロアルトネットワークスのファイアーウォールはそのユーザーが誰であるかを認識しません。(これは、HTTPSセッションがキャプティブ ポータルのページをバイパスするためです。) Diagnosis 既知のユーザーにはno decrypt policy を使います。ユーザー名とパスワードを入力した後は既知のユーザーということになります。 無線を利用した未知のユーザーにはdecrypt policy を使って、HTTPSセッション/ウェブサイトを開いた際にキャプティブ ポータルのページが表示されるようにします。ユーザー名とパスワードを入力するまでは未知のユーザーであるため、SSL復号化により、キャプティブ ポータルがトリガーされます。 未知のユーザーに対する復号化ポリシーによって、ユーザーが訪問しようとしているウェブサイトとは別にキャプティブ ポータルのページが提供されます。  Solution 前提条件   SSL復号化の知識 キャプティブ ポータル(CP)の知識 動作しないときのシナリオ 無線用のゾーンから未知のユーザーがhttps://www.google.comを訪問しようとします。 SSLセッションであるため、キャプティブ ポータルがトリガーされません。 ファイアーウォールはユーザーを識別できず、キャプティブ ポータルのページも表示されません。   動作するときのシナリオ ユーザーがHTTPSでどこかのURLを訪問するときに必ずキャプティブ ポータルのページが表示されるように、SSL復号化の設定が必要です。 SSL復号化の設定はここをクリック キャプティブ ポータルの設定はここをクリック   以下のスクリーン ショットと記述を参考にしてください:       動作するときのシナリオ 復号化ポリシー 1は無線経由の既知ユーザーに対するno decryptポリシーです。 復号化ポリシー 2は無線のゾーンから来たすべてのトラフィックに対して復号化するポリシーです。   未知のユーザーが無線のゾーンからhttps://www.google.comにアクセスしようとします。 復号化ポリシー 2がトリガーされ、CPのページが表示されます。 未知のユーザーが別のHTTPSサイトにアクセスしようとしても、復号化ポリシーによって同じようにCPのページが表示されます。 ユーザーがユーザー名とパスワードを入力します。このユーザーは captive-portal-grpに属しています (ADでCPユーザーを認証します)。 この後はファイアーウォールはユーザーを認識でき、復号化ポリシー 1がトリガーされます。これにより既知のユーザーのこれ以降のトラフィックについては復号化されず、認証の警告ページは表示されません。 グループとゾーンを設定したセキュリティー ポリシーもそれぞれ必要です。グループを指定したポリシーは一番上に設定し、ゾーンを指定したポリシーはその下にくるようにしてください。   警告メッセージの説明 未知のユーザーは無線のゾーンからアクセスしてきますが、彼らにファイアーウォールの自己署名証明書をインストールする手段はないので、復号化の際に警告メッセージが表示されることになります。   もしサード パーティーの証明書をCP用に利用できるのであれば、ユーザー認証の後no decryptのルールが適用され、証明書の警告が表示されないようになります。   ありがとう。   Tarang Srivastav   ※この記事は以下の記事の日本語訳です。 Captive Portal Not Working with HTTPS sessions https://live.paloaltonetworks.com/t5/Management-Articles/Captive-Portal-Not-Working-with-HTTPS-Sessions/ta-p/78346   ... View more

この記事は、以下の記事の日本語訳です。 Getting Started: User-ID https://live.paloaltonetworks.com/t5/Featured-Articles/Getting-Started-User-ID/ta-p/69321     ファイアウォールで、ユーザーの識別もできます！   ユーザー名によるユーザーの識別には幾つかのオプションがあり、これらを利用して何ができるのかを見ていきましょう。以下ではUser-IDエージェントを使った設定の仕方と、エージェントレス モードとの比較、キャプティブ ポータルの設定、セキュリティー ポリシー内のグループ マッピング設定についてご説明します。     Windowsの設定   まず、User-IDエージェントをSupport Portal の"Software Updates"からダウンロードします。インストーラーをダウンロードしたら、Active Directoryが動作しているサーバーにインストールすることをお勧めします。ただ、これは必須ではありませんので、別のサーバーの方が望ましい場合はそちらを利用してください。WindowsのUAC(ユーザー アクセスコントロール)機能を考慮し、Administrator権限でインストールしてください。コマンド プロンプトを”Run as administrator(管理者として実行)"オプションで起動し、インストーラーを保存したフォルダに移動してコマンド ラインから実行します。       インストールが完了したら、User-IDエージェントをスタート メニューから起動し、”edit”をクリックして設定を行います。   はじめに、サービスを実行するためのユーザー名を設定する必要があります。このアカウントは少なくとも以下の権限があることを確認してください(権限の不正/不完全により”Start service failed with error 1069”というエラーが出るため)。ユーザー権限については  How to Install User-ID Agent and Prevent 'Start service failed with error 1069'    にてステップ バイ ステップで設定方法をご紹介しています。　 Event Log Readers (Windows Server 2003のセキュリティー ログ監査・管理) Server operator (サービスとして実行させるため) DCOM Users (WMIプローブのため) もしわかりづらいようであれば、Administratorアカウントを使って設定を進めるのがよいでしょう。関連のURLは一番下に記載しておりますので、User-ID導入について詳細を確認したい方はそちらをご参照ください。   admin guideにもリストされている通り、User-IDエージェントはlogon_successとauth_ticket_granted/renewのイベントを吸い上げます。 Windows Server 2003—イベントIDは672 (Authentication Ticket Granted:認証チケットが承認されました)、 673 (Service Ticket Granted:サービスチケットが承認されました)、および 674 (Ticket Granted Renewed:チケットが更新されました)です。 Windows Server 2008/2012 (R2を含む) または MS Exchange—イベントIDは 4768 (Authentication Ticket Granted: 認証チケットが承認されました )、 4769 (Service Ticket Granted: サービス チケットが承認されました )、 4770 (Ticket Granted Renewed: チケットが更新されました )、および 4624 (Logon Success:ログオンが成功しました)です。   AD上でauditが有効化されSuccessになっていることを確認してください。この状態でADのログからイベントを捕捉することができます:     User-ID エージェントの設定     User-IDを利用するためのユーザーをまだ作成していない場合は、Administratorアカウントで設定を進めてください。このアカウントは後から変更することもできますが、その際は推奨となっている設定をよくご確認の上実施してください。"Setup"をクリックし、ポップアップしたウィンドウの最初(一番左)のタブでユーザー名を設定します。     次の”Server Monitor”タブでログを読み取る頻度を設定します。これはイベント ログを何秒に一度吸い上げてログイン成功イベントを確認し、送信元IPアドレスとそれに紐付けるユーザー アカウントをリストに追加していく頻度になります。多くの場合では、デフォルトとなっている1秒が推奨です。   サーバー セッションをenableにすると、クライアントとサーバー間のコネクションをモニターすることができます。これにより多くのクライアントがADにマップされたドライブを持っている場合、ユーザー アカウントがまだログイン中でコネクションが生きている状態かどうかを判断するのに有益です。   ”Client Probing"タブでWindowsクライアントに対してまだそのアカウントでログオンしているかどうかを定期的にプローブしてチェックするかどうかと、そのチェックの間隔を設定することができます。これらのプローブはローカル アカウントでログオンしたPCや、突然ネットワークから離脱したPCがある場合に、ユーザーとIPのマッピングを解除します。ただし、クライアントでもこのプローブ機能をサポートする必要があるため、この機能の展開には注意が必要です。例えばファイアウォールのポリシーでプローブが許可されていなかったり、クライアント側でUser-IDエージェントで設定しているユーザー アカウントからのプローブに対応できるようになっていないと、プローブが失敗し、ユーザーとIPのマッピングが解除されてしまいます。もし、クライアントがプローブをサポートしているかどうか不明な場合は、サーバーおよびクライアントいずれのプローブ機能も無効化してください。   ”Cache”タブではユーザーとIPのマッピング情報について、そのタイムアウトを設定できます。特にプローブ機能が無効化されている場合は、タイムアウトを設定することによって、最新ではない情報を削除することができます。AD上ログイベントが検知された場合はタイムアウト値はリセットされます。   もし、ユーザーとIPアドレスがほぼ固定のオフィスなら、タイムアウト値は600分以上に設定しておくのが無難です。これはkerberosのデフォルトの有効期間が10時間になっているためです。反対に、多くのユーザーがワーク ステーションを共有しており、ユーザーとIPのマッピングが頻繁に変わるような環境であれば、タイムアウト値は短く設定しておくほうがよいでしょう。   "Agent Service"タブでは、ファイアウォールとのコネクションに使用する待受ポートを変更することができます。   通常は"eDirectory"タブと"syslog"タブの設定はそのままでよいので、"OK"をクリックしてください。設定内容のサマリーとUser-IDエージェントにアクセスできるデバイスのIPアドレスまたはサブネットを制御するためのAccess Control Listを設定、表示する画面になります。"Commit"をクリックして設定を反映させます。   サービスが正常に起動していれば、メイン ページで"Agent is running"と表示されますので、確認してください: もし、エージェントが起動していなければ、"Start"をクリックして、手動で開始してください。   次にUser-IDエージェントがユーザー アクティビティの情報を取りに行くために接続するActive Directoryサーバーを設定します。"Directory"ページで"Auto Discovery"をクリックすると、User-IDエージェントがインストールされているサーバーが持つ情報をもとに、アクセス可能なサーバーをリストします。表示されたサーバー以外のサーバーも利用する場合は、手動で設定します。このケースのようにマルチ ホーム環境で複数がリストされている時は、必要に応じて余分なエントリを削除することもできます。   ユーザーのログイン イベントをモニターする、またはモニターから外すサブネットを"Include/Exclude list"で指定することができます。   "Monitoring"ページでユーザー名とIPアドレスのマッピングが確認できます。User-IDエージェントが最初に起動した際はActive Directoryの最新の50,000のログ エントリを確認し、以降毎秒新しいエントリをモニターします。これは1日のうちのどの時間かということやサーバーのイベント ログの動きにもよりますが、User-IDエージェントの"Monitoring"タブで表示されるエントリが正しくアクティブなIPアドレスと紐付けされるようになるまで、しばらく時間がかかります。(セキュリティポリシーを適用する際にこのことを考慮してください。)   エージェントの準備ができましたら、ファイアウォールのGUIを確認してください。"Device"タブの"User Identification"で先ほどUser-IDエージェントで設定したものと同じ項目が設定できるようになっていますが、これはエージェントレスの時に使用します。エージェントレスは小規模で展開する際や、Active Directory上でソフトウェアをインストールできない場合などに有効です。大規模なネットワークにおいては、ファイアウォールに多大な負荷となるため、エージェントレスによるUser-IDの展開は推奨されていません。   ファイアウォールからUser-IDエージェントに接続する設定は、左から2番目の"User-ID Agent"タブで行います。"Add"をクリックして、User-IDエージェントの情報を入力してください。 "Name"にはどのUser-IDエージェントか区別しやすい名前を入力し、"Host"にはUser-IDエージェントのIPアドレスを入力します。"Port"はUser-IDエージェントの"Agent Service"タブで設定した待受ポートと同じポート番号を入力します。"Collector"はある特定のファイアウォールがログオン イベントの収集を行い、他のファイアウォールがそのファイアウォールから情報をもらう場合に設定します。キャプティブ ポータルでブラウザのNTLM認証を利用する場合は、少なくとも1つ以上のエージェントをProxyとして動作させる必要があります。その場合はこのオプションは有効化しておいて下さい。キャプティブ ポータルの設定箇所でNTMLの設定について後述します。   コミットして少しすると、"Connected"の行のランプがグリーンになります。   次に、User-IDを使うゾーンで、ユーザー識別を有効化します。インターネット向けのゾーンでユーザー識別を有効化することはお勧めできませんので、利用する場合は本当に必要なゾーンの必要なサブネットに限定するACLを記述してください。これを怠るとファイアウォールから、外部向けインターフェイスに接続されたすべてのIPアドレスに対してクエリーを送出してしまいます。   ゾーンでユーザー識別機能を有効にするには、"Network"タブ→"Zone"からTrust側のゾーンを開き、"Enable User Identification"にチェックをつけてください。   必要なゾーン全ての設定が終わったらコミットしてください。コミット後から、トラフィック ログでユーザー情報が表示されるようになります:     キャプティブ ポータル     Active Directoryのイベント ログを通じてユーザー情報を採取することができないユーザーがいる場合、キャプティブ ポータルを導入することもできます。ブラウジング セッションを待ち受けでき、ユーザーのブラウザがNTMLを利用した資格情報のクエリーに対応しているか、またはユーザー名とパスワードを入力するウェブ画面を提供できる環境でキャプティブ ポータルを構築することができます。   ユーザーは認証が求められるポータルのページにリダイレクトされるので、組織外でも信頼された証明書を所定の場所に用意しておくのがベストです。サーバー証明書の作成にCA認証局が利用できる場合は、リダイレクト時にエラー メッセージはポップアップされません。ローカルのCAが利用できない場合は自己証明書を生成して手動でインポートしておくことで、同じようにリダイレクト時のエラーがポップアップされないようすることができます。   PAのGUIで"Device"タブの中で自己証明書を作成したり、ユーザー組織の証明書をインポートできます。下の例ではCAとして証明書を発行していますが、これは必須ではありません。Common NameはPAのインターフェイスのアドレスをリダイレクトIPとして利用するので、それをそのまま入力してもよいですが、内部DNSで名前解決できる場合は"captiveportal.mycompany.com"のようにFQDNを指定してリダイレクトに使うこともできます。 次に、"Device"タブ->"Certificate Management"下の"SSL/TLS Service Profile"でキャプティブ ポータル用のサーバー証明書を選択し、サポートするTLSのバージョンを設定してください:   キャプティブ ポータル設定の前に、もう一つ認証の設定が必要です。"LDAP Server Profile"画面で、Active Directoryサーバーのための新しいLDAPプロファイルを作成してください。 LDAPサーバーの設定が完了したら、Authentication Profileの設定をします。環境に応じたLogin Attributeになっているか確認してください。例えばActive Directoryの場合は通常 'sAMAccountName'を使用します。 "Advanced"タブで認証するユーザーのグループを制限できますが、ここでは"All"を選択します。   次にキャプティブ ポータルを設定します。   リダイレクト モードの場合、ユーザーはファイアウォールのインターフェイスに設定されたランディング ページにリダイレクトされます。先ほど作成した証明書により、この時エラー メッセージが出ないようになります。トランスペアレント モードの場合はファイアウォールがもともとのHTTP/SリクエストのURLになりすまし、HTTP 401(Unauthorized)が返されます。インラインであることで適切な証明書をクライアントに予め入れておくことが難しいため、証明書のエラーは毎回発生することになります。 SSL/TLS Service Profileには、キャプティブ ポータル用の証明書を指定します。 Authentication ProfileではLDAPのAuthentication Profileを指定します。 Redirect Hostにはリダイレクトに使うファイアウォールのインターフェイスのIPアドレスを入力します。前述の通り、名前解決できるようなら証明書のCommon Nameと同じFQDNを指定することもできます。 リダイレクトを動作させるのに、応答ページの設定が必要です。応答ページは"Interface Management profile"で設定します。" Getting started"シリーズの   Layer3 installment ではInterface Management profileでPingを許可する設定をご紹介していますが、同じ箇所で応答ページも有効化できます:   最後にキャプティブ ポータルのポリシーを作成します。下の図の1行目はbrowser-challenge用で2行目はweb-formのものです。"captive-NTLM"のアクション、"browser-challenge"によりファイアウォール側からブラウザに対してNTLM認証を試行します。これが失敗すると、2行目のポリシに従い、ユーザーはweb画面でユーザー名とパスワードを入力することになります。     グループ マッピング   これまでの作業でLDAP Profileが作成されているので、あと1つ設定を行えばActive Directoryからグループの情報も取得可能になります。グループ情報はセキュリティ ポリシーの中で利用することができ、ユーザー アカウントやグループの所属に応じてAllowやdenyのアクションを取ることができます。   "Device"タブ->"User Identification"で、新規にグループマッピングのプロファイルを作成します。"Server Profile"はLDAP Profileを指定し、"User Domain"にはNetBIOSのドメインを入力します。 Update Intervalはデフォルトで3600秒(60分)になっています。ユーザーのグループ設定が頻繁に変わる環境なら、この間隔は短くしたほうが良いでしょう。"Group Include List”ではどのグループの情報をファイアウォールに反映するかを決めます:     利用するグループを選択したら、設定をコミットします。コミット後、セキュリティ ポリシーのユーザーの項目で、これらのグループが利用できるようになります。     以下はユーザーのグループ情報を使ったセキュリティ ポリシーの例です:     CLI コマンド   ユーザーの識別とグループ マッピングが正しく動作しているかを確認するCLI コマンドが幾つかあります:     "show user group name <groupname>" は特定のグループのメンバーを表示します > show user group name "cn=domain users,cn=users,dc=example,dc=com" short name:  example.com\domain users source type: ldap source:      groupmapping [1     ] example.com\administrator [2     ] example.com\astark [3     ] example.com\bstark [4     ] example.com\cgrimes [5     ] example.com\dtargaryen [6     ] example.com\jlannister [7     ] example.com\jsnow [8     ] example.com\lgrimes [9     ] example.com\rgrimes [10    ] example.com\tlannister [11    ] example.com\varys   "show user group-mapping state all" は グループ マッピング プロファイルの状態と直近の更新時間/次回更新までの時間を表示します > show user group-mapping state all Group Mapping(vsys1, type: active-directory): groupmapping         Bind DN    : administrator@example.com         Base       : DC=example,DC=com         Group Filter: (None)         User Filter: (None)         Servers    : configured 1 servers                 10.192.16.98(389)                         Last Action Time: 3418 secs ago(took 0 secs)                         Next Action Time: In 182 secs         Number of Groups: 3         cn=it staff,cn=users,dc=example,dc=com         cn=human resources,cn=users,dc=example,dc=com         cn=domain users,cn=users,dc=example,dc=com   "show user ip-user-mapping all" はユーザー識別が行われた現時点での全アクティブ ユーザーとどのような情報からユーザー識別が行われたかを表示します > show user ip-user-mapping all IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 10.0.0.188      vsys1  UIA     example\rgrimes                   1304           1304          10.0.0.29       vsys1  CP      example\administrator             561            2593          Total: 2 users > show user ip-user-mapping all type   AD        Active Directory   CP        Captive Portal   EDIR      eDirectory   GP        Global Protect   SSO       SSO   SYSLOG    Syslog   UIA       User-ID Agent   UNKNOWN   Unknown   XMLAPI    XML API   上記の他に   User-ID CLI cheat sheet  でも便利な  CLI コマンドをご紹介しています。   その他、User-IDの展開に役立つ情報としては以下があります:   Best Practices for Securing User-ID Deployments   User-ID エージェントが読み取る全イベントIDのリストは   admin guide でご確認頂けます。   この記事は気に入って頂けましたか？元記事のコメント欄に遠慮なくコメント頂ければ幸いです。 過去記事のリスト   Getting Started: the series もご参照ください。   Tom ... View more