ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 GLOBALPROTECT: ONE-TIME PASSWORD-BASED TWO FACTOR AUTHENTICATION https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8ICAS     原文はSivasekharan   Rajasekaranによるものです。 @ srajasekar   背景   企業では社内リソースへのアクセスの許可のために、ワンタイム パスワード(OTP)のような、より強力な認証手段が求められています。OTPベースの認証を要求することで、企業は攻撃者が不正にユーザーの資格情報を入手したり、承認されないアクセスをすることを防ぐことができます。しかしOTPを要求するどの実装も、エンドユーザーがOTPを使いづらく感じ、敬遠する恐れがあります。   目的   GlobalProtectはOTPベース認証をサポートし、ユーザー体験を維持する手段を提供します。この文書の目的は、企業の管理者に異なるGlobalProtectのOTP認証のワーク フローと、彼らのセキュリティとコンプライアンスの要求に合致しつつ、ユーザー体験を簡潔に維持するGlobalProtectの認証シナリオを決定する一助となることです。     GlobalProtectのOTP認証   GlobalProtectはRADIUSまたはSAML経由のOTPベースの認証をサポートし、OTPベンダーに全く依存しません。 RADIUSかSAMLをOTPベンダーが対応している限り、どのOTPベンダーも使用できます。OTPサービスをどのように設定したか次第で、ユーザーは2つのワーク フローのいずれかに従って認証されます。 ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークン コードのいずれかを使用します。 ユーザーはユーザー名を入力し、Challengeを待つことなくワンタイム パスワード(あるいは同時にパスワード)を即認証します。 GlobalProtectはこれらのワークフローをサポートします。  Duoによる2つのワークフローを行うRADIUS設定のサンプルはこちらです。   Always-OnモードでのOTPベース認証が必要な場合 - こちらを参照   On-DemandモードでのOTPベース認証が必要な場合   GlobalProtectをOn-Demandモードで展開している場合、ユーザーは手動で必要に応じてGlobalProgtectに接続します。このモードは一般的な安全なリモート アクセスのユース ケースで、リモートのユーザーは社内データ センターのリソースにアクセスするためにVPNトンネルをセットアップし、内部のデータ センターへのアクセスが必要なくなったときにはVPNを切断します。   ユース ケース1: RADIUSを使用したOn-DemandモードでOTPを使用する   On-Demandによる接続では、GlobalProtectエージェントは、ユーザーがGlobalProtectへの接続を開始する毎に、常に最初にポータル、続いてゲートウェイを認証します。OTP認証がポータルとゲートウェイ両方に必要ということは、ユーザーが二回OTP認証を促されることを意味します(一回はポータル、続く一回はゲートウェイ)。しかし(PAN-OS 7.1およびGlobalProtect 3.1以降から)、ユーザーの認証の回数を最小化する認証オーバーライド機能を提供しています。認証オーバーライドの詳細は、Enhanced Two-Factor Authenticationをご覧ください。   推奨の設定: ポータルとゲートウェイ両方にOTP認証を必要とする。 ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注: 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。 Configuration on the Portal   Configuration on the Gateway   この設定にて、エンドユーザーがGlobalProtectに手動で接続するとき、エンドユーザーの体験は次のようになります。   ワーク フロー – 1 ワーク フロー – 2       ユース ケース2: SAMLを使用したOn-DemandモードでOTPを使用する   GlobalProtectは、PAN-OS 8.0とGlobalProtect 4.0からSAML認証をサポートします。SAMLを使用するとGlobalProtectエージェントはSAMP IdPからの認証ページを、Web/組み込みブラウザーで表示し、ユーザーを認証します。ブラウザが異なる(組み込みブラウザー)ため、 GlobalProtectの認証により得られたSAMLクッキーは、他のSAML有効化アプリケーションによるSSOには使用できません。逆もまた同様です。 GlobalProtect の認証により得られたSAMLクッキーは、再起動やログアウト後には残りません。 SAMLによるOTPを使用した場合、透過的な認証を行うために推奨される設定は次のようになります。 ポータルとゲートウェイの両方にSAML認証を使用します。 IdP設定により、SAMLクッキーの有効な期間を決定します。SAMLクッキーが継続し有効である限り、ユーザーからみてGlobalProtectへの透過的な認証になります。 Oktaを使用したGlobalProtectのSAML認証の設定方法はこちらをご覧ください。   GlobalProtect認証オーバーライドを用いて、再起動やログアウト後も透過的な認証を提供する   ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注: 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。   GlobalProtect Always-OnモードでのOTP認証の推奨については、このシリーズのこちらの次記事を参照してください。   設定例   2つのワーク フロー実現のためのDuoによるサンプル設定です。 DuoによるOTP認証を提供する方法の詳細については、こちらをご覧ください。   ワーク フロー1: ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークンコードのいずれかを使用します。   [ad_client] host=<AD-Server> service_account_username=<administrator> service_account_password=<administrator’s password> search_dn=DC=acme,DC=com   [duo_only_client] [radius_server_challenge] ikey=<duo-integration-key> skey=<duo-security-key> api_host=<duo-host-name> radius_ip_1=<firewall-mgmt-ip> radius_secret_1=<radius-secret> client=ad_client failmode=safe port=1812
記事全体を表示
TShimizu ‎10-11-2018 01:23 AM
4,428件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 GlobalProtect failed to connect - required client certificate is not found https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-failed-to-connect-required-client-certificate-is/ta-p/70192 問題 2要素認証を使用するように認証プロファイルと証明書プロファイルをGlobalProtect ポータルとゲートウェイで構成しましたが、クライアント コンピューターでGlobalProtectに接続しようとした際に、GlobalProtect クライアントのステータス ページに以下のエラーメッセージが表示されます: "Required Client Certificate is not found"   また、PanGP サービス ログでは以下のエラー メッセージが表示されます: Debug(3624): Failed to pre-login to the portal XX.XX.XX.XX. Error 0 Debug(1594): close WinHttp close handle. Debug(3588): prelogin status is Error Error(3591): pre-login error message: Valid client certificate is required Debug(1594): close WinHttp close handle. Debug(4213): portal status is Client Cert Required. Debug(3697): Portal required client certificate is not found.   解決方法 これらのエラーはクライアント コンピュータに正しい/有効な証明書がないため発生します。 クライアント マシンにインポートされた証明書はGlobalProtect ポータル及びゲートウェイで設定されたサーバ証明書と一致する必要があります。 自己署名証明書の場合は、"個人"及び"信頼されたルート証明機関"の両方にインポートする必要があります。 クライアント コンピュータに証明書をインポートする方法については、ここをクリックして"step 2"を参照してください。   次の手順に従い、P12形式の証明書をクライアント コンピュータ(Windows マシン)にインポートします:   スタートをクリックし、mmcを実行します。 ファイル > スナップインの追加と削除をクリックします。 スナップインから"証明書"を選択し、追加をクリック、コンピューター アカウントを選択し完了をクリックします。 OKをクリックしスナップインの追加と削除を閉じます。 "個人"と"信頼された証明機関"に証明書をインポートします。
記事全体を表示
tsakurai ‎07-02-2018 02:42 AM
5,624件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Configure Palo Alto GlobalProtect with Azure Multi-Factor Authentication https://live.paloaltonetworks.com/t5/Management-Articles/Configure-Palo-Alto-GlobalProtect-with-Azure-Multi-Factor/ta-p/79117   AzureのRADIUS認証で多要素認証 (MFA) を使ったGlobalProtectの設定方法について記述します。設定の注意点として、AzureはPAP と MSCHAPv2 認証のみのサポートなので、Palo Alto Networks GlobalProtectでは、PAP認証方式のみ設定が可能です。   Azure MFA設定は、オンプレミスのMFA Server RADIUS(Microsoft推奨)を使用します。 注意: MFA Serverが既にインストールされており、ADとユーザー情報がSync済みであることを前提としています。   Radius認証を有効にします。 クライアント タブでは、Azure Multi-Factor Authentication RADIUS serviceがRADIUS リクエストを受け付けるポートをスタンダードポート以外にする必要がある場合、認証、アカウンティングポートを変更します。これはPalo Alto Networks上の設定も同様です。 クライアント欄で、Addをクリック Palo Alto Networks ファイアウォールのManagement IPをAzure Multi-Factor Authentication Serverに認証するIPアドレスとして設定します。 名前を入力します(任意設定) 共有暗号鍵 (shared secret) を入力します。 'Require Multi-Factor Authentication user match' チェックボックスをクリック。 もしユーザがAzure Multi-Factor Authenticationモバイルアプリ認証を使用していて、OATHのパスコードを、外線通話、SMS、プッシュ通知の際に利用したい場合は、‘Enable fallback OATH token’ チェックボックスをクリックします。      8. Targetタブで、機器がドメインに参加している場合は‘Windows domain’を選択、そうでない場合は’LDAP bind’を選択します。       GlobalProtect設定 注意: Azure MFA SeverはPAPとMSCHAPv2のみのサポートです。GlobalProtectの設定で、PAP認証を設定する必要があります。デフォルト設定はAutoです。もし違う認証が選択された場合、authd.logに不正ユーザ名/パスワードのエラーメッセージのみが記録されます。 RADIUS CHAP認証モードをPAN-OS 7.0.3、それ以前で、CLI、WebUIから手動設定で外すオプションはありません。 PAN-OS 7.0.4以降では、以下のコマンドで、手動設定でRADIUS認証タイプを選択できます。 > set authentication radius-auth-type <auto|chap| pap >   Palo Alto Networks ファイアウォールにログインします。 Device> サーバー プロファイル > RADIUSに移動し、以下のプロファイルを作成します。 a. プロファイル名 (Profile Name) -  MFA serverの名前 b. 場所 (Location) - 共有 (Shared) c. タイムアウト (Timeout) – 30~60秒で、multi-factor認証、Radiusアクセス・リクエスト処理の送受信など、ユーザ認証に必要な時間(以下のスクリーンショットを参照) d. 再試行 (Retries) – 3回 e. 追加 (Add) をクリックし、RADIUS ServerにWindows Azure Multi-Factor Authentication serverのFQDNもしくはIP アドレスと、以前に設定したshared secretを入力 f. ポート (Port) - 1812 (デフォルト). Network > ゲートウェイ(ゲートウェイは設定済みであることが前提) 全般 > 認証プロファイルでステップ2で作成したプロファイルを選択           著者: smisra  
記事全体を表示
kkondo ‎06-12-2018 11:32 PM
2,470件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Integrating Cisco ISE Guest Authentication with PAN-OS https://live.paloaltonetworks.com/t5/Integration-Articles/Integrating-Cisco-ISE-Guest-Authentication-with-PAN-OS/ta-p/98295     Cisco ISEがPAN-OSにユーザーID情報を送付する設定について記述したものです。この設定例では、Cisco ISE 1.4.0-253とPAN-OS 6.1/7.0を使用しています。  この設定例では、ユーザーIDがActive Directoryで既に動作しています。ゲスト情報のみをCisco ISEから得ることを設定者は考えています。この振る舞いは、正規表現にてサブネットを追加/削除することにより変更できます。   Cisco ISEはネットワーク上のユーザーを認証するためのRADIUSサーバーとして動作します。RADIUS認証、アカウンティングログをPAN-OSに送付することができます。   — 詳細   Cisco ISE上で新規Remote Log Targetを設定します。デバイスはPAN-OS装置になります: Administration > System > Logging > Remote Logging Targets を選択します。 Addをクリックします。 Nameにご自由に名前を入れて、Target TypeにはUDP Syslogを選択します。IP addressには、PAN-OS管理インターフェイスのIPアドレスを入力します。 Submitをクリックします。   他にUser-IDログ情報を送りたいデバイスがある場合は、操作を繰り返します。   ISEでPassed Authentication Syslog Messages転送設定をします。 Administration > System > Logging > Logging Categoriesを選択します。 Passed Authenticationsをクリックします。 先程作成したremote log targetを選んで、“Available”欄から、“>”をクリックして、“Selected”欄に移します。 Saveをクリックします。    ユーザー ID Syslog リスナー UDPをPAN-OS上で有効にします。 Device > セットアップ > 管理インターフェイス設定を選択します。 ユーザー ID Syslog リスナー UDP のチェックボックスを選択します。 OKをクリックします。   Syslog 解析プロファイルを送付されてくるsyslog messagesとマッチするように設定します。 Device > ユーザー ID > ユーザー マッピングを選択します。 Palo Alto Networks ユーザー ID エージェント設定を編集、Syslog のフィルタをクリックします。 追加を選択します。 下記のようにすべての情報を入力します。   ここは注意が必要な個所です。-- 無線装置には、Cisco ISEはUser-ID情報を認証ログのみに、そして有線装置にはUser-ID情報をアカウンティングログのみに送付します。   参照例としては、   10.10.130.0/24 = 無線ゲスト 10.10.30.0/24 = 無線ゲスト 10.10.140.0/24 = 有線ゲスト イベントの正規表現は以下のようになります。   Syslog 解析プロファイル: Cisco ISE イベントの正規表現: ([A-Za-z0-9].*CISE_Passed_Authentications.*((Framed-IP-Address=10\.10\.130)|(Framed-IP-Address=10\.10\.30))|([A-Za-z0-9].*CISE_RADIUS_Accounting.*(Framed-IP-Address=10\.10\.140))) ユーザー名の正規表現: (?<=UserName=|User-Name=)[\w-]+ アドレスの正規表現: Framed-IP-Address=([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})  OKをクリックします。   Cisco ISE 2.1のsyslog 解析プロファイルは以下のようになります。 Event Regex ([A-Za-z0-9].*CISE_Passed_Authentications.*Framed-IP-Address=.*)|([A-Za-z0-9].*CISE_RADIUS_Accounting.*Framed-IP-Address=.*) Username Regex User-Name=([a-zA-Z0-9\@\-\\/\\\._]+)|UserName=([a- zA-Z0-9\@\-\\/\\\._]+) Address Regex Framed-IP-Address=([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1 ,3}\.[0-9]{1,3})   ISEサーバーをサーバー モニタリングに追加します。 Device > ユーザー ID > ユーザー マッピングを選択します。 サーバー モニタリングにて、追加をクリックします。 名前と内容は自由に入力します。 タイプでは、Syslog Senderを選択します。 ネットワーク アドレスにはCisco ISEのIPアドレスを入力します。 接続タイプはUDPを選択します。 フィルタにはCisco ISEを選択します。 デフォルト ドメイン名にはNetbiosドメイン名、もしくは、環境に即した情報を入力します。 OKをクリックして閉じ、Commitをクリックします。     準備ができました。PAN-OS装置はCisco ISEからUser-ID情報を受け取れているはずです。以下のコマンドで動作確認をすることができます。   show user server-monitor state  show user ip-user-mapping all type SYSLOG test user-id user-id-syslog-parse tail follow yes mp-log useridd.log   参考情報 Configuring Cisco ACS to send RADIUS Accounting directly to the firewall using Syslog Configuring ISE to Forward User Login Events to CDA   著者: Marcos
記事全体を表示
kkondo ‎04-25-2018 08:44 PM
3,149件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Unlock Users on the Lock List for Failed Maximum Authentication Attempts https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Unlock-Users-on-the-Lock-List-for-Failed-Maximum/ta-p/66195   事象 認証の試行が許容されたログイン回数を超えると、ユーザーはロックされた状態になり、以下のエラーメッセージがauthdログに表示されます。   "pan_authd_generate_alarm(pan_authd.c:808): Generating alarm for auth failure log: Admin jai failed to authenticate 2 times - the unsuccessful authentication attempts threshold reached. Admin jai's account is being disabled due to excessive failed authentication attempts".   原因 ユーザーが最初に認証しようとしたときに、許容ログイン回数が2に設定され、ロックアウト時間が10分に設定されている場合、最初の プロファイルがチェックされます。試行が失敗すると "Profile2" がチェックされ、それでも失敗すると、ロックアウト時間に指定された短い時間ロックされた状態にプッシュされます。   失敗した試行が3に設定されている場合、最初の試行でプロファイル  "Profile" を確認し、2回目の試行で "Profile2" をプロファイルし、3回目の試行で プロファイル "Profile" を再度チェックします。ユーザーに2つの認証プロファイルがあり、失敗した試行が1と設定されている場合、2番目のプロファイル "Profile2" は評価されず、ユーザーは直ちにロックされた状態に移行します。   デバイス> 認証シーケンス は以下になります:   注 : ロックアウト時間が0分に設定されている場合、ユーザーは特定の時間が経過してもロックが解除されないため、対象者が管理者の場合は Device > 管理者 タブ、ほかのユーザーの場合は Device > 認証プロファイル を使用して管理者が手動でロックを解除する必要があります。   ユーザーがロックされると、次のCLIコマンドを実行した際に以下のログが表示されます。 >   tail follow yes mp-log authd.log   2回試行した後、ユーザーは無効になり、ロック状態になります:   syslogは次のログを生成します。これは、アカウントがロックされ、ロックされたユーザーリストに置かれていることを示しています。   解決策 デバイス > 認証プロファイル に移動します 最後「ロックされたユーザー」列で、「ロック解除」アイコンをクリックします: 対象ユーザーは以下のようにロックが解除されます: デバイス> 管理者 で対象の管理者ユーザーのロックを解除することもできます:   owner: dantony
記事全体を表示
dyamada ‎04-17-2018 09:12 PM
2,676件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Certificate config for GlobalProtect - (SSL/TLS, Client cert profiles, client/machine cert) https://live.paloaltonetworks.com/t5/Configuration-Articles/Certificate-config-for-GlobalProtect-SSL-TLS-Client-cert/ta-p/131592   この文書はGlobalProtectセットアップにおける証明書の設定の基礎について説明します。この文書でカバーされないGlobalProtect用の証明書の展開方法もありうることを、ご承知おきください。   A. SSL/TLS サービス プロファイル - ポータル/ゲートウェイのサーバー証明書用。ポータル/ゲートウェイはこれを一つ必要とします。 B. 証明書プロファイル(必要に応じて) - ポータル/ゲートウェイがクライアント/マシン証明書を要求するために使用します。 C. クライアント機器へのクライアント/マシン証明書のインストール     A. SSL/TLS サービス プロファイル GlobalProtectの枠組みにおいて、このプロファイルはGlobalProtectポータル/ゲートウェイの"サーバー証明書"と、SSL/TLSプロトコルのバージョン範囲の規定に使用されます。同じインターフェイスがポータルとゲートウェイ両方に使われている場合、同じSSL/TLS サービス プロファイルをポータル/ゲートウェイに使用できます。異なるインターフェイスで ポータル/ゲートウェイを通して提供する場合、証明書が両方のポータル/ゲートウェイのIP/FQDNをそのサブジェクト代替名(SAN)に含んでいれば同じSSL/TLS サービス プロファイルを使用できます。含んでいない場合は、ポータルとゲートウェイにそれぞれ異なるプロファイル作成します。   SSL/TLS サービス プロファイルに"サーバー証明書"とそのチェーンをインポート/生成するには、以下のとおり操作します。 外部で作成した証明書をインポートするには、Device > 証明書の管理 > 証明書 に移動し、下部にある'インポート'をクリックします。 ファイアウォールで証明書を生成するには、Device > 証明書の管理 > 証明書 に移動し、下部にある'生成'をクリックします。   サーバー証明書が公なサードパーティ認証局や内部のPKIサーバーによって署名されている場合 1. ルート認証局証明書をインポートします(秘密鍵のインポートはオプションです)。 2. 中間認証局証明書がある場合はインポートします (秘密鍵のインポートはオプションです)。 3. 上記の認証局によって署名された証明書を秘密鍵とともにインポートします。     重要! サブジェクト代替名(SAN)がない証明書の場合:この証明書の共通名(CN)はポータル/ゲートウェイのIPまたはFQDNにマッチしなければなりません。 サブジェクト代替名が1つ以上存在する場合、そのポータル/ゲートウェイで使用されるIPかFQDNは、SANのリストの中の一つにマッチしなければなりません。 認証局であってはなりません。エンド エンティティでなければなりません。 ベスト プラクティスとして、IPよりFQDNの使用が望ましいです。設定上、およびエンドユーザーによるGlobalProtect クライアント上での"ポータル:"欄での入力において、FQDN/IPを一貫して使用するようにしてください。例えば、ポータル/ゲートウェイがFQDN   'vpn.xyz.com' かIP '1.1.1.1'で到達できるとします。証明書の参照が'vpn.xyz.com'であれば、ユーザーは1.1.1.1ではなく、'vpn.xyz.com'を使用しなければなりません。   4. SSL/TLS サービス プロファイル (  Device > 証明書の管理 > SSL/TLS サービス プロファイルにあります) 名前 - 任意の名前を入力します 証明書   - 前述の手順3のサーバー証明書を参照します プロトコル設定   - クライアント サーバー間のsslトランザクションで使用されるssl/tlsの最小と最大のバージョンを選択します   5. このSSL/TLS サービス プロファイルを、必要なポータル/ゲートウェイで参照します。   サーバー証明書をPalo Alto Networksファイアウォールで生成する必要がある場合 1. ルート証明書をユニークな共通名(ポータル/ゲートウェイのIP、FQDN以外)で生成します   ( Device > 証明書の管理 > 証明書にて下部の "生成"をクリックします)   2. (オプション )上記のルート証明書で署名をした中間証明書を生成します。共通名はユニークなもの(ポータル/ゲートウェイのIP、FQDN以外)にします。   3. 上記の中間証明書で署名されたサーバー証明書を生成 a. この証明書の共通名は、サブジェクト代替名(SAN)が存在しない場合、ポータル/ゲートウェイのIPかFQDNにマッチ思案ければなりません。Palo Alto Networks ファイアウォールではSANは'証明書の属性'のタイプを'Host Name'、'IP'、'Email'で作成できます。 b. 一つ以上のSANがある場合、ポータル/ゲートウェイで使用するIPかFQDNがSANのリストに存在しなければなりません。 c.  認証局であってはいけません。 d. 実践においては、IPではなくFQDNの使用が望ましいです。 設定上、およびエンドユーザーによるGlobalProtect クライアント上での"ポータル:"欄での入力において、FQDN/IPを一貫して使用するようにしてください。例えば、ポータル/ゲートウェイがFQDN   'vpn.xyz.com' かIP '1.1.1.1'で到達できるとします。証明書の参照が'vpn.xyz.com'であれば、ユーザーは1.1.1.1ではなく、'vpn.xyz.com'を使用しなければなりません。        4. SSL/TLS サービス プロファイル (  Device > 証明書の管理 > SSL/TLS サービス プロファイルにあります) 名前 - 任意の名前を入力します 証明書   - 前述の手順3のサーバー証明書を参照します プロトコル設定   - クライアント サーバー間のsslトランザクションで使用されるssl/tlsの最小と最大のバージョンを選択します    5. このSSL/TLS サ ービス プロファイルを、必要なポータル/ゲートウェイで参照します。   B. 証明書プロファイル ( Device > 証明書の管理 > 証明書プロファイルにあります) 証明書プロファイルは認証局と中間認証局のリストを定義します。証明書プロファイルが設定上で適用されると、ポータル/ゲートウエイは、証明書プロファイルの認証局または中間認証局で署名されたクライアント/マシン証明書クライアント証明書を、クライアントに要求します。このプロファイルにはルート認証局だけでなく、中間認証局も設定することを奨めます。    重要! - 'user-logon’/'on-demand'が接続方式となっているとクライアント証明書はユーザーの証明書となり、ユーザーの認証に使用されます。 - 'pre-logon'が接続方式となっているとクライアント証明書はマシン証明書となり、ユーザーではなく、機器の認証に使用されます。   1. クライアント/マシン証明書を署名したルート認証局をDevice > 証明書の管理 > 証明書  にて インポートします(秘密鍵はオプション)。 2. クライアント/マシン証明書を署名した中間認証局がある場合は、Device > 証明書の管理 > 証明書 にてインポートします (秘密鍵はオプション)。 3. Device > 証明書の管理 > 証明書プロファイル に移動して、追加をクリックします。 4. プロファイルの名前を入力します。 5. 手順1と2のルート認証局証明書と中間認証局証明書を追加します。   6. 注: ユーザー名フィールドはデフォルトで'None'となっており、典型的なセットアップではLDAP/RADIUS認証から引用されるので、'None'のままとしておくことができます。一方、証明書のみによる認証の場合(つまりポータル/ゲートウェイが使用するRADIUS/LDAPがない場合)、ユーザー名フィールドはユーザー名をクライアント証明書の共通名またはEmail/プリンシパル名から抽出するために'None'から'サブジェクト'または'サブジェクト代替名'に変更しなければなりません。さもないとCommit失敗となります。   7. (オプション)CRLまたはOSCPによるクライアント/マシン証明書の無効化ステータスの確認が必要な場合、'証明書状態が不明な場合にセッションをブロック'をチェックしていると、クライアントの接続に失敗しますのでご注意ください。   8. この証明書プロファイルを必要なポータル/ゲートウェイから参照します。   C. クライアント/マシン証明書をクライアント端末にインストール   クライアント/マシン証明書をインポートする際、秘密鍵を含むPKCSフォーマットでインポートを行ってください。   Windows での手順を以下に説明します。   1.スタート > ファイル名を指定して実行にてmmcを入力して、Microsoft 管理コンソールを開きます: 2. ファイル > スナップインの追加と削除をクリックします。     重要! 3. 証明書 > 追加 を行い、以下のどちらか、ないしは両方を行います:     a. クライアント(ユーザー)証明書を'ユーザー アカウント'を選択して追加します。これは  ' user-logon 'と' on-demand 'で ユーザーを認証するためです。 b. マシン(機器)証明書を'コンピューター アカウント'を選択して追加します。これは  ' pre-logon ' でマシンを認証するためです。             4. クライアント/マシン証明書をmmcにインポートします。 a. クライアント証明書をインポートする場合、'証明書-現在のユーザー'下の'個人'フォルダにインポートします。 b. マシン証明書をインポートする場合、'証明書(ローカル コンピューター)' 下の'個人'フォルダにインポートします。         5. 同様にルート認証局証明書を'信頼されたルート証明機関'に、(あれば)中間認証局証明書を'中間証明機関'にインポートします。     重要! 6. 一旦インポートしたら、インポートしたクライアント/マシン証明書をダブルクリックして、以下を確認します。 a. 秘密鍵(訳注:日本語版Windowsでは"秘密キー"と表記されます)を持っているか。 b. ルート認証局までの完全な証明書チェーンがあるか。もしルート認証局や中間認証局までのチェーンに欠落がある場合は、手順5での説明に従い、それらの認証局証明書を該当するフォルダーにインポートします。           7.この時点で証明書はクライアントにインストールされていますので、mmcコンソールをセーブすることなくクローズして構いません。
記事全体を表示
TShimizu ‎03-07-2018 09:54 PM
8,288件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 How to Configure LDAP Server Profile https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-LDAP-Server-Profile/ta-p/58689   手順 Device をクリック Server Profiles 配下にある LDAP をクリック Add をクリックして LDAP Server Profile ダイアログを表示 Server名、IP Address、ポート番号を入力 (389 はLDAP) LDAP サーバー type をドロップダウン メニューから選択。ドメインのベース識別名 (Base Distinguished Name) を入力。バインドDN と そのサーバー アカウントのバインド パスワードを入力。SSL のチェックボックスをはずす。 (ドメイン コントローラーが ポート 636 で LDAP SSL を待ち受けている場合、SSLが利用可能) 変更をCommit   著者: bnelson
記事全体を表示
dyamada ‎03-19-2017 11:42 PM
5,279件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 LDAP Configuration Error: failed to connect to server, Invalid credentials https://live.paloaltonetworks.com/t5/Management-Articles/LDAP-Configuration-Error-failed-to-connect-to-server-Invalid/ta-p/58929     問題 LDAP 認証でユーザーの認証ができず、システムログで以下のエラーが記録される。 06/18 12:45:55 ldap cfg plano2012-ldap failed to connect to server 10.111.10.10:389, source: 10.111.10.254: Invalid credentials 06/18 12:45:56 ldap cfg plano2012-ldap failed to connect to server 10.111.10.11:389, source: 10.111.10.254: Invalid credentials   解決策 該当のディレクトリー サーバーへの誤った LDAP バインド DN  (Distinguished Name:識別名)とパスワードにより、認証が失敗しています。[Device ] > [サーバープロファイル] > [該当の LDAP サーバーの名前] に移動し、以下の欄が LDAP サーバー プロファイルで正しく入力され、正しいユーザーの情報を反映していることを確認します。 バインド DN バインド パスワード     バインド DNは [Device] > [ユーザー ID] > [グループ マッピング設定] で正常性の確認ができます。もしバインド DN が正しければ、LDAP プロファイルでの LDAP スキーマの設定にしたがって、ツリーの更新と情報の取得ができます。不正確なバインド DN の場合は "Invalid Credentials" のエラーが表示されます。   バインド DN の情報は LDAP サーバープロファイルに設定したユーザーを Active Directory サーバーから検索することで得られます。 右クリックで Properties を選択し、[Attribute Editor] を確認します。 訳注: Attribute Editor タブを表示するには、予め Active Directory Users and Computers のメニューから [View] > [Advanced Features] をチェックしておく必要があります。   著者:bsyeda
記事全体を表示
TShimizu ‎07-26-2016 02:12 AM
7,119件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Configuring Administrator Authentication with Windows 2008 RADIUS Server (NPS/IAS) https://live.paloaltonetworks.com/t5/Configuration-Articles/Configuring-Administrator-Authentication-with-Windows-2008/ta-p/61651     概要 本文書はWindows 2008 RADIUS サーバーを使用した管理者認証を設定する手順を記載します。 設定を行うための前提条件: 管理インターフェースからのL3接続、あるいはデバイスのRADIUSサーバーへのサービス ルート ドメイン アカウントを確認できるWindows 2008サーバー   手順 パート 1:Palo Alto Networksファイアウォールの設定 [Device] > [サーバー プロファイル] > [RADIUS]に移動し、RADIUS サーバー プロファイルを追加します。 [Device] > [認証プロファイル]を開き、認証プロファイルを追加します。 [Device] > [管理者ロール]に移動し、管理者ロールを追加します。今回の場合は仮想システム用(vsys)の管理者ロールとし、デバイス全体への適用はしません。 [Device] > [アクセス ドメイン]に移動し、アクセスドメインを追加します。 [Device] > [セットアップ[ > [管理] > [認証設定]を開き、上記で作成した、RADIUSの認証プロファイルが選択されていることを確認します。 [Device > [管理者を開き、認証される必要のあるユーザーが予め定義されていないことを確認します。 コミットをクリックして、設定を反映させます。   パート 2:Windows 2008 serverの設定 (Server RoleとしてNPS(Network Policyand Access Services)が必要です) [Start] > [Administrative Tools] > [Network Policy Server]をクリックして、NPS設定画面を開きます。 Palo Alto NetworksデバイスをRADIUSクライアントとして追加します。 [RADIUS Clients and Servers]を開きます。 [RADIUS Clients]を選択します。 右クリックして、[New RADIUS Client]を選択します。 注:[Name and Address]のFriendly name:とAddress、[Shared secret:]を追加するだけです。[Vendor name:]は標準設定の"RADIUS Standard"のままにしておきます。 RADIUS Clientを追加した後の一覧は、以下のようになります: [Policies]に移動し、[Connection Request Policies]を選択します。 Windowsユーザーを認証するポリシーが設定/チェックされているかを確認します。 [Overview]タブを確認し、ポリシーが有効になっていることを確認します。 [Conditions]タブを確認します。 [Settings]タブを確認し、ユーザーの認証方法を確認します。 [Network Policies]上で右クリックし、新しいポリシーを追加します。 [Policy name:]を入力します。 [Conditions]タブを開き、認証することができるユーザーを選択します(グループによる指定が望ましい)。 [Constraints]タブを開き、"Unencrypted authentication (PAP, SPAP)"が有効になっていることを確認します。 [Settings]タブに移動し、ユーザーに正しい管理者ロールとアクセスドメインが割り当てられるよう、VSA (ベンダー固有属性)を設定します。 [RADIUS Attributes]から"Vendor Specific"を選択します。 右側の画面にて、[Add]ボタンをクリックします。 [Vendor:]ドロップダウン リストから"Custom"を選択します。 [Attributes:]リスト内にある唯一の選択肢が、"Vendor-Specific"の状態になります。 [Add]ボタンをクリックします。 The Attribute Information ウィンドウを開きます。 左側にある[Add]ボタンをクリックして、 Vendor-Specific Attribute Information ウィンドウを開きます。 VSAを設定します。 [Enter Vendor Code]を選択し、"25461"を入力します。 "Yes. It conforms"を選択すると、設定した属性が、RADIUS RFCでの"Vendor Specific Attributes"の定義に準拠することになります。 "Configure Attribute…"をクリックします。 管理者ロールの[Vendor-assigned attribute number:]は"1"とします。 [Attribute format:]は"String"を選択します。 [Attribute value:]は管理者ロールの名前のことであり、今回は"SE-Admin-Access"を入力します。 [OK]をクリックします。 [Add]ボタンをクリックして、2つ目の属性を必要に応じて設定します。[Vendor-assigned attribute number:]の"2"はアクセスドメイン 用となります。 ユーザーは、"User-Group 5"に設定する必要があります。 注:グループは手動で入力して、該当するポリシーの中で使うことができます。 異なるアクセス/認証オプションが、(一般的なアクセスのために)既知のユーザーを使用する場合だけでなく、より安全なリソース/ルールを適用するためにRADIUSが返したグループでも利用することができます。 属性の一覧は、以下のように表示されます。 すべてのオプションが保存されるまで、[OK]をクリックし続けます。 既存のポリシーを右クリックして、実施したいアクションを選択することもできます。   パート 3:設定の確認 ファイアウォール上での確認: Palo Alto Networksファイアウォール上で、誤ったパスワードを使用して、以下のシステム ログが表示されるかを確認します。[Monitor] > [ログ] > [システム] 正しいパスワードを使用すると、ログインは成功して以下のログ エントリーが表示されます。 アクセス権を確認します。   NPS側での確認: イベント ビューワーから( Start > Administrative Tools > Event Viewer)、  以下を探します: Security Event 6272, “Network Policy Server Granted access to a user.” Event 6278, “Network Policy Server granted full access to a user because the host met the defined health policy.” Windows ログ内のセキュリティー ログを選択します。 Task Category の中で “Network Policy Server” を探します。   参照: 類似の設定方法として、以下のドキュメントも参照してください。 RADIUS VSA dictionary file for Cisco ACS - PaloAltoVSA.ini   著:srommens  
記事全体を表示
hshirai ‎07-20-2016 01:41 AM
2,525件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 RADIUS Vendor-Specific Attributes (VSA) https://live.paloaltonetworks.com/t5/Configuration-Articles/RADIUS-Vendor-Specific-Attributes-VSA/ta-p/60273   概要 この文章ではRADIUSベンダー識別子(VSA: Vendor-Specific Attributes)をPalo Alto Networks次世代ファイアウォール、Panoramaサーバーに設定する方法について記述します。Palo Alto Networks ファイアウォール機器と、Panoramaサーバー設定は基本的に同じです。 注: Palo Alto Networksはベンダーコード25461を使用します。   属性には、以下の5つがあります。 PaloAlto-Admin-Role: 属性第1 – 初期のadmin role名かcustom admin role名のいずれかです。 PaloAlto-Admin-Access-Domain: 属性第2 - Palo Alto NetworksデバイスにてマルチVsysを有効にした場合に使用します。これはDevice > Access Domainsで設定されたアクセス ドメイン名です。 PaloAlto-Panorama-Admin-Role: 属性第3 – Panoramaの初期のadmin role名かcustom admin role名のいずれかです。 PaloAlto-Panorama-Admin-Access-Domain: 属性第4 - これはPanoramaのDevice > Access Domainsで設定されたアクセス ドメイン名です。 PaloAlto-User-Group: 属性第5 – 認証プロファイルで使用するグループ名です。   RADIUSサーバが準備されていない場合、作成を完了してください。グループ情報を取り出すのはベンダー識別子(VSA)特有機能で、通常のRADIUS設定では不必要です。 認証プロファイルの作成します。RADIUS認証でログインできるユーザーをグループ名でフィルターしたい場合、追加ユーザーのAllow Listウィンドウにグループ名を入力します。この例で使われているグループ名はtestgroupです。 注: Allow Listの追加はオプショナルです。 Panorama設定 PanoramaアクセスのAdmin Role設定します。これによりユーザー アクセスがどのような権限を持っているかPanoramaに知らせることができます。 Device > Admin RoleにアクセスしAdmin Roleを作成します。このロールは、ユーザーがログインした時に正しい権限を譲渡します。この設定例では、testroleを使っています。 "デバイス グループとテンプレート" のオプションは、アクセス ドメイン中の特定のデバイスに対するアクセス許可を与えるように、必ずチェックしてください。 アクセス ドメインの設定はPanoramaにユーザーがどのような権限を持っているか知らせます。 認証プロファイルをPalo Alto Networksデバイス、もしくはPanoramaに適用する場合、Palo Alto Networksデバイスの場合は、Device > Setup > Management > Authentication Profile、Panoramaの場合は Panorama > Setup > Management > Authentication Profileに移動します。   Windows 2003: Palo Alto Networksベンダー識別子を(VSA)をWindows 2003サーバーに設定する。 想定 : RADIUSクライアントとRemote Access Policyが既に設定されていること。 既存のRemote Access Profileを編集します。 Remote AccessプロファイルのEdit Profileボタンをクリックします。 Advancedを選択し、Addをクリックします。 Vendor-Specificまでスクロールし、Addをクリックします。 次のウィンドウで、Addをクリックし必要な属性を作ります。 ベンダー識別子(Vendor-Specific Attribute)情報ウィンドウでVendorコードを選択し、25461を右側フィールドに入力します。続いて、"Yes, It conforms," を選択し、 "Configure Attribute…"をクリックします。 次のウィンドウで、このドキュメントの冒頭に説明した、ベンダー識別子番号(Vendor-assigned attribute number)を入力します。識別子のフォーマットは "String" であるべきです。識別子の値は、設定次第になります。 以下が Palo Alto Networks デバイスに設定した、ロール (testrole) の例です。   以下が、Palo Alto Networks装置のVsys (vsys1)設定例です。   以下が、Panoramaサーバーに設定した、ロール(testrole)の例です。   以下が、Panoramaサーバーに設定したアクセス ドメイン(Domain1)の例です。   以下が、Palo Alto Networks装置、Panoramaサーバーに設定したグループ(testgroup)の例です。   以下が、カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPalo Alto Networksデバイスに設定した例です。これらはこの文章の冒頭部分で設定されています。   Windows 2008ネットワーク ポリシー サーバー: Palo Alto Networksベンダー識別子(VSA)をWindows 2008サーバーに設定する。 想定: RADIUSクライアントとネットワーク ポリシーが既に設定されていること。 既存のNetwork Policiesを右クリックから編集を選択し、プロパティを選択します。 Settingsタブから、Vendor Specificを選び、Addボタンをクリックします。 Attributesボックスをスクロールダウンし、Vendor-Specificを選びます。 Addボタンをクリックします。 Vendor-Specific Attribute Informationウィンドウで、Enter Vendor Codeを選び、25461を右側フィールドに入力します(以下の図を参照)。次に"Yes, It conforms,"を選択し、"Configure Attribute…"をクリックします。 次のウィンドウで、この文章の冒頭部分で説明したようにベンダーが割当てた識別番号を入力します。識別フォーマットは "String" であるべきです。識別子の値は、設定次第です。以下の設定例では、Palo Alto Networks デバイス、Panoramaサーバーの識別子の設定が可能です。 以下が、Palo Alto Networksデバイスのロール (testrole)設定例です。   以下が、Palo Alto NetworksデバイスのVsys (vsys1)設定例です。   以下が、Panoramaサーバーのロール (testrole)設定例です。   以下が、Panoramaサーバーのアクセス ドメイン (Domain1)設定例です。   以下が、Palo Alto Networksデバイス、Panoramaサーバーのグループ(testgroup)設定例です。   以下が、カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPalo Alto Networksデバイスに設定した例です。これらはこの文章の冒頭部分で設定されています。   Cisco ACS 次にベンダー識別子(VSA)をCisco ACS 4.0 サーバーに設定します。 想定: RADIUSが設定され、Panoramaサーバー上で動作していること。   palalto.ini という名前のファイルをCisco ACS サーバーのUtilsフォルダーに作成します。   以下がiniファイルに記述するサンプル例です。 iniファイルを保存し、ACSサーバーのbinフォルダーにあるCSUtil.exeコマンドを起動して、それをACSサーバーに反映させます。 コマンド例: CSUtil.exe –addUDV 0 C:\Program Files\CiscoSecure ACS v4.0\Utils\paloalto.ini ACS サーバーにて、Interface設定ページを選び、"RADIUS (PaloAlto)"をクリックします。 使用したい識別子を選びます。以下のサンプル例ではすべてを選択しています。Submitをクリックします。 ACS Groupの識別子を編集します。testgroupというグループを作成します。 グループ設定で、以下の図のように、jump toで"RADIUS (PaloAlto)"が選択できます。 ご使用になられたいオプションを設定します。カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPanoramaサーバーに設定した例です。これらはこの文章の冒頭部分で設定されています。   参考 Configuring Cisco ACS 5.2 for use with Palo Alto Vendor Specific Attributes  (英文)   著者: rnit
記事全体を表示
kkondo ‎07-15-2016 07:25 AM
6,459件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Admin-Admin Does Not Work After Factory Reset https://live.paloaltonetworks.com/t5/Management-Articles/Admin-Admin-Does-Not-Work-After-Factory-Reset/ta-p/57669   問題 : デフォルトの管理者アカウント(admin/admin)がファクトリー リセット後動作しない   解決方法 : ファクトリー リセット後、CLIコンソール プロンプト(例:PA-500)は、管理者アカウント(admin/admin)を受け付けるまでに、以下のように遷移していきます。   1.  500 login: 2.  PA-HDF login: 3.  PA-500 login:   3番目の「PA-500 login」になったとき(何度かEnterキーを打って、コンソール プロンプト出力が変わるかご確認ください)管理者アカウント(admin/admin)を受付け準備ができた状態です。   著者:  achitwadgi
記事全体を表示
kkondo ‎07-12-2016 12:15 AM
3,015件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Addressed: Palo Alto Networks Product Security Regarding the June 5th OpenSSL Security Advisory https://live.paloaltonetworks.com/t5/Threat-Articles/Addressed-Palo-Alto-Networks-Product-Security-Regarding-the-June/ta-p/59677     更新: 本文書に書かれた問題は既に対応済みです。 この問題は、PAN-OS 6.0.4, 5.1.9, 5.0.14にて対応済みです。これらのバージョン、もしくはそれ以降のバージョンにすることで問題は回避されます。   要約 Palo Alto Networks PAN-OS ソフトウェアは、特定の限られたケースにおいて、マン・イン・ザ・ミドル (MITM) 攻撃に繋がる脆弱性CVE-2014-0224の影響を受ける可能性があります。これに対応するため、Palo Alto Networksは、全てのサポート対象のバージョンに対し、次に予定されているメンテナンス リリースにおいて弊社の製品で使われているOpenSSLソフトウェアにパッチを適用します。なお、GlobalProtectは影響を受けません。   注: 2014年6月5日に報告されたOpenSSLの脆弱性のうち、その他6つのCVEに関しては、弊社のソフトウェア プラットフォームは影響を受けません。   詳細 Palo Alto Networksの製品セキュリティ エンジニア チームは2014年6月5日に報告されたOpenSSLの脆弱性が弊社の製品に影響を及ぼすかどうか解析を行いました。記載されている7つのCVEのうち、CVE-2014-0224のみが弊社のソフトウェアに関連していることがわかりました。残りのCVEに関しては、弊社のソフトウェアは DTLS (Datagram Transport Layer Security)、及びアノニマス ECDH (Elliptic curve Diffie-Hellman) を使わないため影響はありません。CVE-2014-0224による影響も限られています。何故なら、影響を受けるのはクライアントとサーバーが同時に脆弱である場合であるためです。PAN-OSはクライアントとしては影響を受けますが、サーバーとしては影響を受けません。結果、マン・イン・ザ・ミドル (MITM) 攻撃の影響を受ける可能性があるのは、脆弱性のあるOpenSSLバージョン(OpenSSL 1.0.1 and 1.0.2-beta1)を使っている外部のサーバーに弊社のソフトウェアが接続をしにいった際に作られるセッションのみに限られます。   お客様の設定によって、MITMに対して脆弱なサービスは様々です。例えば、脆弱なOpenSSLサーバーを動かしているプロキシをSSLを用いて使うファイアウォールのサービスであったり、脆弱なOpenSSLサーバーを動かしているsyslogサーバーへSSLでログ転送するサービスであったり、脆弱なOpenSSLサーバーを動かしているディレクトリ サーバーに接続に行くユーザーIDエージェントなどがあります。GlobalProtectポータルとゲートウェイは脆弱でないため、GlobalProtectは影響を受けません。   これに対応するため、Palo Alto Networksは、全てのサポート対象のバージョンのPAN-OS、ユーザーIDエージェント、GlobalProtectに対し、次に予定されているメンテナンス リリースにおいて弊社の製品で使われているOpenSSLソフトウェアにパッチを適用します。お客様は、自身が運用するサーバーにおいて脆弱性のあるOpenSSLのバージョン(1.0.1 and 1.0.2-beta1)を使わないようにすることで、上記に書かれた問題を回避することができます。不明な点がありましたら、Palo Alto Networks サポートチームにお問い合わせ下さい。    OpenSSL アドバイザリ: https://www.openssl.org/news/secadv_20140605.txt  (英文)   著者: gwesson
記事全体を表示
ymiyashita ‎07-11-2016 02:34 AM
2,940件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Using LDAP to Authenticate to the Web UI https://live.paloaltonetworks.com/t5/Configuration-Articles/Using-LDAP-to-Authenticate-to-the-Web-UI/ta-p/53445   概要 この記事には Web UI の認証のための LDAP の設定手順が記載されています。   手順 LDAP Server Profile を作成し、ファイアウォールが通信により LDAP ツリーにクエリを行うことができるようにします。 Device タブ (もしくは、Panorama 上の場合は Panorama タブ) > Server Profiles 配下の LDAP をクリック > Add をクリック。 ポートを 389 のままにしておく場合は必ず SSL のチェックを外します。LDAP サーバーが LDAP over SSL で動作するように設定されている場合は、チェックが入ったままにしサーバー ポートを 636 に変更します。 Domain – ファイアウォールがマルチ ドメイン環境に設置されていなければ、Domain フィールドはブランクのままにします。 Base – クエリが開始する LDAP ツリーのレベル。そのレベル以降のユーザーはすべて PAN によってアクセス可能となります。 Bind DN – LDAP ツリーにクエリを行う権限をもつユーザーへのパスです。 上記で新規に作成した LDAP Server Profile を使用して Authentication Profile を作成します。 Device タブ (もしくは、Panorama 上の場合は Panorama タブ) > Authentication Profile をクリック > Add をクリック。 Authentication は LDAP になります。前の手順で作成したサーバー プロファイルを選択し、Login Attribute は "sAMAccountName" とします。これには大文字・小文字の区別があります。 この例では、Allow List はすべてのユーザーを許可します。このリストは必要に応じて制限することができます。 Palo Alto Networks デバイス上で Administrator アカウントを作成します。 Device タブ (もしくは、Panorama 上の場合は Panorama タブ) > Administrators > Add をクリック。 Authentication Profile のドロップ ダウンから、前の手順で作成した LDAP Authentication Profile を選択します。 Administrator の名前が LDAP サーバーに存在するユーザー名と一致するようにします。 コミットします。 現在の Web UI セッションからログアウトし、作成した LDAP ツリーに存在する Administrator アカウントを使用してログインを試みます。   著者: jseals
記事全体を表示
kishikawa ‎07-10-2016 10:40 PM
2,870件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Troubleshooting RADIUS Authentication https://live.paloaltonetworks.com/t5/Management-Articles/Troubleshooting-RADIUS-Authentication/ta-p/59200   訳注:本文書にはPAN-OS 4.1以前の情報を元にした、2016年7月現在サポートされるPAN-OSでは該当しない記述が含まれます。     グループのメンバーシップが正しいことを確かめます。 [Monitor]タブ > [ログ] > [システム] “user is not in allow list”がないか探してください。   これは該当のユーザーが選択されている認証プロファイルのグループにいないことを意味します。   CLIからは以下のコマンドで確認できます(訳注:現在サポートされるPAN-OSにはこのコマンドはありません)。 > show user pan-agent user-IDs   該当のユーザ名を"/"に次いでタイプしてサーチし、パロアルトネットワークスのデバイス上で、そのユーザーをどのグループに関連付けているか確認します。   上記のエラーに該当しない場合は、RADIUSサーバー側の可能性が考えられます。   よくあるサーバー関連の問題としては以下が有ります。 誤ったIPアドレスがRADIUSサーバーの設定に入力されている。 共有暗号鍵 (Shared Secret) のミスタイプ。シークレット フィールドにパスワードを貼付けしないでください。 誤ったIPアドレスがRADIUSサーバーのクライアント設定に入力されている。 RADIUSサーバーのポリシーが以下で不正となっている。 誤ったWindowsのグループ NAS-IP アドレス PAP   RADIUSサーバーのイベントは  [Event Viewer] > [System]ログ > IASで確認ができます。   Windows 2008 のEvert Viewerの Systemログ、 IAS表示例   誤ったIPアドレスがRADIUSサーバーの設定で使用されていた場合、以下のシステム ログの出力が確認できます。   CLIで以下のコマンドで"authd.log"(認証関連のログ)を確認できます。 > less mp-log authd.log   共有暗号鍵 (Shared Secret) が間違っている場合、同様のエラーがauthd.logに表示されます。RADIUSサーバー側でもエラーが確認でき、RADIUS server 2003では以下の様にEvent Viewerで表示されます。 誤ったIPアドレスがRADIUSサーバーのクライアント設定で使用されている場合、以下のエラーメッセージがEvent Viewerで確認できます。   不正なポリシーがRADIUSサーバーで設定されている場合、ファイアウォールではシステム ログのエントリーは先の事例と同様になりますが、authd.logの表示は異なったものとなります。    誤ったWindowsグループ、誤ったNAS-IPアドレス、あるいはPAP認証が設定されていない場合、RADIUSサーバー上のEvent Viewerでは以下のエラーが表示されます。   RADIUS認証が成功した場合   > [Monitor]タブ > [ログ] > [システム]   > less mp-log authd.log   著者:bnitz
記事全体を表示
TShimizu ‎07-06-2016 12:36 AM
4,164件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Troubleshoot LDAP Authentication https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-LDAP-Authentication/ta-p/61818   概要 この文章では、次のようなLDAP認証上でのトラブルについてどのように問題を切り分けるかを記載します。 LDAP認証が、デバイスの管理者アクセス、Captive Portal、GlobalProtectに対して設定されていますが、認証が常に失敗します。   この問題の予備知識: LDAPサーバーはMicrosoft Active Directoryサーバーを使用 許可リストは設定された認証プロファイルで設定されていません( 許可リスト の使用を前提にすると他の問題を推考してしまうため、この文章では対象外とします)   手順 認証のプロセスは、管理プレーン上のauthdプロセスによって動作します。すべてのデバッグ ログはmp-logのauthd.logに出力されます。 1.   LDAPサーバー プロファイルを確認します。 # show shared server-profile ldap ldap {   ad2008 {     server {       myadserver {         port 389;         address 10.0.0.10;       }     }     ldap-type active-directory;     base DC=panw,DC=dom;     bind-dn admin@panw.dom;     timelimit 30;     bind-timelimit 30;     bind-password -AQ==LEkLjmi5LnnONEwl89h/wpfRI0Y=AgBprzhy+CcbuOsMV p+mJg==;     ssl no;   } }   1.1   TCPポートの389番が一般的なLDAP通信では使われます。389番ポートを使用する場合、必ずSSL設定がされていない (ssl no;)ことを確認してください。 仮にSSLが有効だと、LDAPサーバー側でLDAPSがサポートされていること、そしてTCPポートの636番(LDAPSのデフォルトポート)が設定されたサーバー プロファイルで設定されていることをご確認ください。 # show shared server-profile ldap l dap {   ad2008 {     server {       myadserver {         port 636;         address 10.0.0.10;       }     }     ldap-type active-directory;     base DC=panw,DC=dom;     bind-dn admin@panw.dom;     timelimit 30;     bind-timelimit 30;     bind-password -AQ==LEkLjmi5LnnONEwl89h/wpfRI0Y=AgBprzhy+CcbuOsMV p+mJg==;     ssl yes;   } }   1.2   LDAPサーバー プロファイルで、ベースのドロップ ダウンリストから選択されれば(Device > LDAP > LDAP Server Profile)ベースDNはPalo Alto Networks装置から自動的に取得されるはずです。自動取得されたものをLDAPサーバー ベースとして使用することを強く推奨します。.   1.3   LDAPサーバー プロファイルで、ドメイン名を手動で設定することができます。この個所を空白のままにしておくことを推奨します、そうすればPAN-OSは自動的にドメイン名を推測することができます。この設定は、複数のADドメインが存在していて、各々を特定化するために使用されます。   1.4   LDAP接続を確認する方法としては、Group-Mapping 設定をする際にLDAPツリー ブラウザーを参照することです(該当のLDAPサーバーをサーバー プロファイルで選択してください) 上記画面のようにLDAP情報が参照できれば、LDAPサーバー プロファイルは正しく設定されていることを意味します。   2. デバッグ ログauthd.logを確認する authd.logログ出力をCLIの”tail follow yes mp-log authd.log”で確認すると、次のような典型的なログ出力が成功例、失敗例で確認できます。   「認証成功例」 Jan 08 14:00:46 pan_authd_service_req(pan_authd.c:2604): Authd:Trying to remote authenticate user: user1 Jan 08 14:00:46 pan_authd_service_auth_req(pan_authd.c:1115): AUTH Request <'vsys1','adauth','user1'> Jan 08 14:00:46 pan_authd_handle_nonadmin_auths(pan_authd.c:2245): vsys, authprof <vsys1,adauth> doesnot exist in db, trying 'shared' vsys Jan 08 14:00:46 pan_authd_common_authenticate(pan_authd.c:1511): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,username user1 Jan 08 14:00:46 pan_authd_authenticate_service(pan_authd.c:663): authentication succeeded (0)   「認証失敗例 」 Jan 09 23:21:15 pan_authd_service_req(pan_authd.c:2604): Authd:Trying to remote authenticate user: user1 Jan 09 23:21:15 pan_authd_service_auth_req(pan_authd.c:1115): AUTH Request <'vsys1','adauth','user1'> Jan 09 23:21:15 pan_authd_handle_nonadmin_auths(pan_authd.c:2245): vsys, authprof <vsys1,adauth> doesnot exist in db, trying 'shared' vsys Jan 09 23:21:15 pan_authd_common_authenticate(pan_authd.c:1511): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,username user1 Jan 09 23:21:21 pan_authd_authenticate_service(pan_authd.c:663): authentication failed (6) Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1531): Authenticating user using service /etc/pam.d/pan_ldap_shared_adauth_0,usename user1 failed - trying other hosts Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_1 Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_2 Jan 09 23:21:21 pan_authd_common_authenticate(pan_authd.c:1506): Skipping LDAP server due to missing Auth-Profile: pan_ldap_shared_adauth_3 Jan 09 23:21:21 authentication failed for user <shared,adauth,user1> Jan 09 23:21:21 pan_authd_process_authresult(pan_authd.c:1258): pan_authd_process_authresult: user1 authresult not auth'ed Jan 09 23:21:21 pan_authd_process_authresult(pan_authd.c:1282): Alarm generation set to: False. Jan 09 23:21:21 User 'user1' failed authentication.  Reason: Invalid username/password From: 192.168.0.17   これらのログ出力は認証失敗したとても一般的な出力で、他の問題と混同しがちです。 同様のログ出力は、様々なケースで見受けられます。 LDAPサーバーに接続できない(サービス ルート設定を確認) 存在しないLDAPサーバーを設定している ユーザ名もしくは、パスワード、その両方が間違っている サーバー プロファイル設定のバインドDNフォーマットもしくはパスワード、その両方が間違っている   3. サービス ルート設定の確認 サービス ルート 設定がUIDエージェント サービス用に設定されている場合、グループ マッピング テストは成功しますが、LDAP認証が失敗する可能性があります。それは、Palo Alto Networksデバイスはマネージメント インターフェイスを送信元のインターフェイスとして利用するからです。確かに、Group Mapping はUseriddプロセスが管理していますが、前述したとおり、認証サービスはAuthdプロセスが管理していてこのサービスに対して個別の サービス ルート 設定ができません。もしLDAP認証のリクエストにマネージメント インターフェイスが設定されていない場合、個別のLDAPサーバーIPアドレスを、以下の設定例のように宛先として、 サービス ルート 設定する必要があります。
記事全体を表示
kkondo ‎04-08-2016 11:18 PM
5,017件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community