Management Articles

Featured Article
Overview The following procedure explains how to configure Radius on Windows 2008 Server.   Details To configure RADIUS (or Network Policy Server, in Windows 2008), add a RADIUS client. Inside the Network Policy Server (Start > Administrative Tools > Network Policy Server), right-click on RADIUS Clients and select New RADIUS Client. Complete the form using the IP address on the Management Interface of the Palo Alto Networks device and the password configured for RADIUS in the Palo Alto Network device. Then click OK. Use the default Connection Request Policy. There is no need to create a new one.   Configure a Network Policy, right-click Network Policies within the Network Policy Server, then click New.   Other User Groups besides the Domain Users group can be used:   Select Unencrypted Authentication (PAP, SPAP):   Click Next, the Defaults are fine.   Click Next, the Defaults are fine.   owner: panagent
View full article
nrice ‎09-14-2018 01:08 PM
7,375 Views
0 Replies
1 Like
Las funciones de múltiples factores de autentificación de Palo Alto Networks a partir de PAN-OS 8.0. S e mostrará como poder hacer la integración con DUO Security, como poder hacer MFA para autentificar aplicación Web, y como poder hacer MFA en aplicación NO-Web (solicitando autentificación a través del agente de GlobalProtect).
View full article
MarceloRey ‎05-09-2018 10:24 AM
3,717 Views
0 Replies
2 Likes
La Automatización de Palo Alto Networks a partir de PAN-OS 8.0, y los Dynamic Address Group (DAG). El mismo tiene una utilidad importante para lograr generar un Data Center auto-defendido, sin necesidad de tener que aplicar políticas manualmente.
View full article
MarceloRey ‎02-06-2018 12:49 AM
3,219 Views
0 Replies
2 Likes
Issue When using a group in the "allow list" for the authentication profile that Global Protect uses, the login attempt fails with the following error: "Reason: User is not in allowlist"   However, the login works fine if the allow list is set to "all" in the authentication profile.   Resolution Confirm that the group you are using is in the include list in a Group Mapping configuration under Device > User Identification > Group Mapping Settings: Group Mapping Confirm that the group in question contains the user attempting to login. Run the CLI command: show user group name <value> For example: > show user group name pantac\vpn-user short name:  pantac\vpn-user source type: ldap source:      Pantac2003 [1     ] pantac\user1 [2     ] pantac\admin1 [3     ] pantac\administrator [4     ] pantac\user2 [5     ] pantac\user4 Confirm that the LDAP server profile used for your Group Mapping and your Global Protect authentication profile contain the Netbios domain name (short name) in the domain field. Do not use the DNS name for the domain (domainname.com) In most cases this is the same profile. This can also be left blank in many cases. The LDAP server profile is under Device > Server Profiles > LDAP In PAN-OS 7.0 and later, the domain section was moved to Device > User Identification > Group Mapping Settings :  User Domain   In PAN-OS 8.0 the User Domain can also be controlled in the Authentication Profile User Domain in the Authentication Profile Confirm that the group name in the allow list in the Global Protect authentication profile is listed with the long name of the group. This value can be pasted into this value from the output of the "show user group list" CLI command. Authentication Profile Allow List   owner: jteestel
View full article
jteetsel ‎11-20-2017 05:04 AM
91,294 Views
23 Replies
1 Like
Everything you need to know related to deploying, managing, and supporting Palo Alto Networks GlobalProtect.
View full article
ekampling ‎10-19-2017 02:58 AM
50,736 Views
1 Reply
6 Likes
  This article discusses retrieval of groups from the Active Directory failing if the  nested group level exceeds  the limit.   Following log could be seen in the useridd.log stating  that the nested-group-level limit has been exceeded :   2017-07-14 00:06:07.109 -0400 Warning: pan_ldap_ctrl_query_single_inc luded_group(pan_ldap_ctrl.c:34 91): nested group level (11) exceeds the limit (10) for group 'cn=testdev,ou=groups,ou=dept,dc=d2-dept,dc=com'   Workaround The default setting for the nested groups is 10 which can be increased by configuration to 20, please see the command below:   >configure # set group-mapping <group-mapping name> nested-group-level 20  For example: # set group-mapping "Test" nested-group-level 20   If the workaround of incrementing the nested-group-level to 20 is used, it is recommended that the configuration of Active directory is reviewed to ensure that the limit of 20 does not breach, which may cause further issue with pulling of the groups.   Note: Since this is a configure command, no commit is needed.     
View full article
syadav ‎08-07-2017 04:43 PM
5,009 Views
0 Replies
Overview When it comes to authenticating users based on the user-groups, most of the deployments make use of LDAP authentication profile. This document describes the configuration that is required on the Palo Alto Networks firewall and sheds some light on how to pull the Palo Alto Networks User Group Attribute to ensure successful user-group based VPN authentication using secure RSA.   prerequisite: group information on the Palo Alto Networks firewall needs to be populated through an LDAP profile as described in this article: How to Configure Active Directory Server Profile for Group Mapping and Authentication before starting these configuration steps   Steps Go to Device > Server Profiles > RADIUS and add a RADIUS server. Go to Device > Authentication Profile and create a RADIUS authentication profile by referencing the RADIUS server profile created in Step 1. Shown in the above screenshot, see that although we have referenced the LDAP user groups in the allow list, we are making use of RADIUS server profile to relay the Authentication request to the RADIUS server. Please note that Authentication will NOT happen on the Palo Alto Networks firewall. Instead, it takes place on the RADIUS server. As a result, the RADIUS server should have the capability to pass the user-group information highlighted in the below screenshot, which is possible through "Palo Alto Networks Dictionary file".   Palo Alto Networks Dictionary installs on the RADIUS server and defines authentication attributes needed for communication between a Palo Alto Networks firewall and the RADIUS server.   See Also To download the dictionary file and for more information, reference the following link: RADIUS Dictionary   owner: tshivkumar
View full article
tshiv ‎06-30-2017 03:11 AM
6,835 Views
0 Replies
2 Likes
Issue When authentication attempts exceed the number of permitted failed attempts, the user will be in a locked state, and the error message below will appear in the authd logs:   "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".   Cause If the user tries to authenticate for the first time, and if the Failed Attempts is configured to 2 and the Lockout Time is configured to 10 minutes, it will check the first Profile. If the attempt fails it will then check "Profile 2", and if that too fails, then the user will be pushed into a locked state for a brief moment, which is specified in the Lockout Time.   f Failed Attempts is configured to 3, it will check profile "Profile" for the first attempt, then profile "Profile 2" for the second attempt and then finally again profile "Profile" for the third attempt. If a user has 2 Authentication Profiles and if the failed attempts is configured as 1, then the second profile "Profile 2" will not even be evaluated and the user will be immediately moved to the locked state.   Go to Device > Authentication Sequence, as shown below:   Note: If the lockout time is configured as 0 minutes, then the user will not be unlocked after a specific amount of time, but will need to be unlocked manually by an administrator via the Device > Administrators tab for administrators and Device > Authentication Profile for other users.   When users are locked, the logs below appear when running the following CLI command: > tail follow yes mp-log authd.log   After two attempts, the user is disabled and put into a locked state:   The syslog generates the following logs, which suggests the account is locked and placed in the locked users list:   Resolution Go to Device > Authentication Profile. On the last column,"Locked Users," click the Unlock icon: The user will be unlocked as shown below: The user can also be unlocked under Device > Administrator:   owner: dantony
View full article
dantony ‎04-06-2017 12:05 AM
13,959 Views
0 Replies
    Overview Service devices that are neither a component of the corporate domain nor have a real user behind them are often overlooked when designing the User-ID topology. These devices, 'bring your own device' (BYOD) and smart phones, behave as employee workstations and generate sessions to the corporate firewall, creating additional stress on the User-ID topology. Smart phones double the number of users that need to be identified and matched to the correct security policy. Because of this scenario, it is possible to reach the  limit for unknown IP addresses and User-ID agents probed on the Palo Alto Networks firewall.   Issue Users are not identified and appear as 'unknown' in the the firewall’s user-IP mappings. This can result in users matching a wrong rule and cause traffic to be dropped or blocked. The following message appears in the User-ID log (useridd.log): > tail follow yes mp-log useridd.log 2014-01-20 14:07:45.498 +0100 pan_user_id_agent_update_unknown_ip_rate_limit: Unknown IP rate is now 101, enabling rate limiting for VM1_collector   A check on the number of unknown IP-user mappings returns a high value, for example:  > show user ip-user-mapping all type UNKNOWN option count Total: 349 users   Cause This process happens when the rate of sending queries for unknown IP addresses from the firewall to the User-ID Agent becomes over 100 unknown IP addresses per second. In the time when this log is generated, the firewall has many unknown IP addresses in the user-IP mappings. At this point, if any request for an unknown IP address needs to be sent to the User-ID Agent, the query is dropped and the mapping is not requested from the User-ID Agent. Note: The limit on the firewall is 100 requests for unknown IP addresses per second, which is a high rate even for the largest implementations. Most users, with even the default settings, likely don't notice this issue during the lifespan of the firewall.   The rate limiting normally lasts for a couple of seconds (depending on the network) and the administrator can see the rate limiting being removed in the same log file (useridd.log): 2014-01-20 14:07:45.498 +0100 pan_user_id_agent_update_unknown_ip_rate_limit: Unknown IP rate is now 101, enabling rate limiting for VM1_collector 2014-01-20 14:07:47.504 +0100 pan_user_id_agent_update_unknown_ip_rate_limit: Unknown IP rate rate is now 76, disable rate limiting for VM1_collector   Running the same operational command after the rate-limiting is finished results in a significantly smaller number of unknown users. For example: > show user ip-user-mapping all type UNKNOWN option count Total: 21 users   During that period (2 seconds in the above example), all users that needed IP-user mapping were discarded. The rate-limiting period is small and the “unknown” ip-user-mappings have significantly smaller expiration timers than the identified users. However, it is possible that users are matched to wrong rules due to this limiting process. This will be accompanied by unusual traffic logs, where a user is mapped as a source of traffic, followed by an “unknown” user as a source from the same IP address, then later followed by the user being correctly mapped again. The process depends on the activity of the user. If the user initiates another session, then a new request is sent to the User-ID Agent because the firewall has “unknown” user assigned to that IP address. The agent replies with the mapping.   The high rate of unknown user-IP requests from the firewall can occur when there are many systems that don't have users behind them. They include IP phones, mobile phones, printers, wireless access points, servers and workstations that are not part of the domain, and other machines used in the corporation. Since these devices are frequently initiating sessions and don't have users behind them, the Palo Alto Networks firewall is constantly trying to map them.   Resolution To resolve the issue, use the User Identification ACLs on the zones where the User Identification is enabled. Go to Network >  Zones. Select the zone where the user identification is enabled. Add an exclude or/and include list, if needed. Both lists are empty by default, which means that the firewall attempts to identify users behind all IP addresses that generate traffic. If the include list is empty, the firewall includes all the IP addresses, except those on the exclude list.   To review the zone configuration, see the same setup on the CLI. For example: > configure # show zone Trust-L3 Trust-L3 {   network {     layer3 [ ethernet1/2 loopback.4 vlan.30];   } enable-user-identification yes;   user-acl {     exclude-list [ 10.2.13.0/24 10.8.97.0/27 172.120.5.0/25 Androids "http servers dynamic group" iPhones];   } }   This limits the number of requests that the firewall sends to the User-ID Agent, by not showing any interest for the objects given in the exclude list. Users behind those addresses aren't identified and don't appear in the logs. The list can have IP addresses, networks, objects, or object groups (static or dynamic).   FAQ- More Info See below for some FAQ's and more information about this issue: What is the actual impact of Userid enabling rate-limiting for unknown IPs?   The PA is rate-limiting the send requests for ip-user-mapping because there are more than 100 unknown-users per second generating traffic that was hitting the DP. The rate-limiting period is small and the “unknown” ip-user-mappings have significantly smaller expiration timers than the identified users. However, it is possible that users are matched to wrong rules due to this limiting process. This will be accompanied by unusual traffic logs, where a user is mapped as a source of traffic, followed by an “unknown” user as a source from the same IP address, and then later followed by the user being correctly mapped again. The process depends on the activity of the user. If the user initiates another session, then a new request is sent to the User-ID Agent because the firewall has “unknown” user assigned to that IP address. The agent will reply with the mapping. Are there any mitigations available besides zone include/exclude ACLs that we should know about?  Global on Firewall You may want to use the feature below but this only implies to the user-ip mapping that you would like to learn. Define Subnetworks to Include/Exclude for User Mapping Device > User Identification > User Mapping Use the Include/Exclude Networks list to define the subnetworks that the User-ID agent will include or exclude when performing IP address-to-username mapping (discovery). Per Zone on Firewall w/UserID enabled on it: See documentation in current article BIG CAVEAT - From the Online Help: "If you add entries to the Exclude List but not the Include List, the firewall excludes user mapping information for all subnetworks within the zone, not just the subnetworks you added." We are including the RFC1918 networks in the Include List since the excludes have precedence over the includes. Is there a "nerd knob" that can be adjusted on larger platforms to raise the threshold?  No, the Rate is hardcoded to 100 unknown-users per second regardless of platform.   owner: ialeksov
View full article
ialeksov ‎04-03-2017 02:30 PM
10,241 Views
1 Reply
4 Likes
This article is out of date and no longer valid.  A Newer article exists here: How Does the Device Manage Offloaded Session?
View full article
sjamaluddin ‎03-22-2017 09:12 AM
10,612 Views
0 Replies
1 Like
Symptoms Users would be unable to generate API keys or use basic authentication API. The same username and password would work for SSH and WebGUI login. Diagnosis The user would get invalid credentials when trying to generate API key though the username and password is correct. Example: $ curl -k ' http://10.129.80.155/api/?type=keygen&user=user01&password=user#01 ' <response status = 'error' code = '403'><result><msg>Invalid credentials.</msg></result></response>   Or Would get a missing parameter error: Example: $ curl -k ' http://10.129.80.155/api/?type=keygen&user=user02&password=#02user ' <response status = 'error' code = '400'><result><msg>Missing value for parameter &quot;password&quot;.</msg></result></response>   Or  When using basic authentication, you would get unable to resolve host name: $curl -k ' http://user01:user#01@10.129.80.155//api/?type=op&cmd=<show><system><info></info></system></show> ' curl: (6) Could not resolve host: user01 <<<<<<   In all the cases the password contains special character #. The issue is with the way cURL and browsers treat #. RFC :  https://tools.ietf.org/html/rfc3986#section-3.5 In section 3.5 : A, fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. Hence, anything after the # is considered frag of the URI. Now, looking at cURL official documents :  https://curl.haxx.se/ Curl supports fragments fine when a URL is passed to it, but the fragment part is never actually sent over the wire,  so it doesn't make a difference to curl's operations whether it is present or not.   Hence the # is never sent across the wire, resulting in such behaviour.       Solution A possible workaround is to URL-encode the # symbol (%23) as defined in the same RFC3986 or to avoid using # special character in the password.
View full article
crajariyap ‎03-13-2017 05:16 AM
5,627 Views
3 Replies
1 Like
Issue PAN-OS 7.0+ supports TACACS+ authentication  and some customers will use open source implementation of TACACS+ server in Linux distros like CentOS or Ubuntu. In this situation,  existing Cisco devices will function just fine, but PAN-OS devices using TACACS+ authentication will fail and the logs will show error "Returned status: 2"   Authentication to TACACS+ server at 'SERVER_IP' for user 'username' Server port: 49, timeout: 3, flag: 4 Egress: 172.18.0.21 Attempting CHAP authentication ... CHAP authentication request is created Sending credential: xxxxxx CHAP authentication request is sent CHAP authentication failed: Attempting PAP authentication ... PAP authentication request is created PAP authentication request is sent Returned status: 2 Authentication failed against TACACS+ server at SERVER_IP:49 for user 'username' Verification The debugging options should be enabled inside the TACACS+ server to figure out what is actually happening when authentication. This can be enabled by starting the daemon with –d switch with 2 8 16 32 64 128   In the debug, look for the error like below: No chap or global secret for <user name> If we that message in the TACACS+ daemon then the steps mentioned below can be followed to fix it.   On the Palo Alto Networks CLI, you can also run the following command to test: > test authentication authentication-profile <TACACS-Profile> username <test> password   Resolution The resolution for this error needs to be performed on the TACACS server and not on the PAN device. The following user_attr should be added to the user in tac_plus.conf pap = des <des_string_password>   For example, the test user config under tac_plus.conf should look like user = test { pap = des <des_string_password> pap = PAM chap = cleartext "chap password" login = <password_spec> enable = <password_spec> }   Note: Some attributes might not be present in this example, as this is just for illustration.   After adding it to the tac_plus.conf on the TACACS server, the daemon should be restarted to take effect and after that, the authentication should succeed.  
View full article
shganesh ‎02-14-2017 12:31 PM
27,917 Views
2 Replies
Palo Alto Networks devices allow SSH connection to the system for management purposes. Each time the user is connected to the device via SSH, there will be a session created.   Details for each SSH session (PAN-OS 7.X) By default, the firewall allows for a maximum of 4 authentication attempts. If a user enters the wrong password 4 times, the single session will be closed and the SSH connection reset. For each unsuccessful attempt, there is an event generated in the system logs as follows: ( eventid eq auth-fail ) and ( subtype eq general ) and ( severity eq medium ) and ( description contains 'failed authentication for user \'admin\'. Reason: Invalid username/password From: xxx.xxx.xxx.xxx.' )   Details for each SSH session (PAN-OS 6.X) By default, the firewall allows for a maximum of 6 authentication attempts. If a user enters the wrong password 6 times, the single session will be closed and the SSH connection reset. For each unsuccessful attempt, there is an event generated in the system logs as follows: ( eventid eq auth-fail ) and ( subtype eq general ) and ( severity eq medium ) and ( description contains 'failed authentication for user \'admin\'. Reason: Invalid username/password From: xxx.xxx.xxx.xxx.' )   The maximum number of failed authentication attempts per session cannot be changed .   
View full article
TACWEIWEI ‎02-14-2017 01:08 AM
3,249 Views
0 Replies
Symptoms RADIUS authentication fails when Microsoft Network Policy Server (NPS) passwords contain accented characters. For example: ó, ò, ñ Diagnosis NPS does not encode RADIUS password in UTF-8 as expected by RFC286.   NPS is encoding password in EASCII.   As we comply with RFC, passwords will mismatch when received and checked by Palo Alto Networks firewall authentication daemon (authd). Solution Avoid using any accented characters in the NPS password.
View full article
nbilly ‎01-04-2017 10:21 AM
2,706 Views
0 Replies
Question Are group names case sensitive when configured in allow-list of an authentication profile case? Answer When configuring a group name in allow-list of an authentication profile, goup names are case sensitive. It is important as we are using allow-lists for various authentication protocols (LDAP, RADIUS, TACACS+ and so on).   Case might be problematic when using capital or uppercase letters in group names in allow-lists configured for an LDAP Active Directory server.   You may have configured your group name in Active Directory server containing capital or uppercase letters, but LDAP then converts the group name to lowercase, according to RFC 4510.   If you are configuring group names in allow-lists in accordance with group names configured on Active Directory server (containing uppercase letters, authentication will fail for user members of this group.   When the Palo Alto Networks device fetches the LDAP groups from the Active Directory server, group names will be lowercase, mismatching group names configured in an allow-list containing capital or uppercase letters.
View full article
nbilly ‎01-03-2017 08:10 AM
5,087 Views
0 Replies
This article examines reasons for SSO faliure with error 'GSS_S_Failure.' For information related to configuring Kerberos for Admin or Captive portal authentication, please click here     Details:   Error message in authd logs while Kerberos SSO authentication:      Reason 1:   - Algorithm used while generating keytab is different from algorithm used while TGS issues service ticket to the clients.       Keytab was generated using algorithm AES256-SHA1 while the service ticket issued to client by TGS uses the default algorithm RC4-HMAC   In this case, either the keytab should also be generated using default algorithm RC4-HMAC or Kerberos administrator should be contacted to configure same algorithm for issuing service tickets.     Reason 2:   Window/Linux client instance, KDC and/or the firewall has a time difference of more than ~3-4 mins. It is always better to have their time in sync for SSO to operate correctly.
View full article
hagarwal ‎12-06-2016 07:26 PM
2,779 Views
0 Replies
Symptoms Users are prompted to refresh the page several times to get the Captive Portal login page, in all versions of Android OS, including   Lollipop  and   Marshmallow.  This behavior is seen only for the first instance, when they connect to the new wifi network, or when they forget an exisiting network, and rejoin as a new user. Diagnosis Whenever the Android device establishes a connection to the wifi network, it automatically tries to visit a particualr site and tries to get a file name "generate_204". If it fails to get this information, it will generate a exclamation symbol next to the wifi icon identifying there is no internet connectivity.   This is expected behavior and it is hard coded in the Android OS. The sites differ for different Android OS versions.   This is a code that is used to detect if there is a Captive Portal configured somewhere in the network, and it will prompt to redirect to use a browser to complete the CP authentication process.   See the link below for the codes used in Marshmallow , Lollipop and KitKat:   1. KitKat http://androidxref.com/4.4.4_r1/xref/frameworks/base/core/java/android/net/CaptivePortalTracker.java   2. Lollipop http://androidxref.com/5.1.1_r6/xref/frameworks/base/packages/CaptivePortalLogin/src/com/android/captiveportallogin/CaptivePortalLoginActivity.java   3. MarshMallow http://androidxref.com/6.0.0_r1/xref/frameworks/base/packages/CaptivePortalLogin/src/com/android/captiveportallogin/CaptivePortalLoginActivity.java   See the example screenshots below:         This results in overburdening the captive portal service on the Palo Alto Networks firewall, the Palo Alto Networks firewall will wait for the request to timeout, and then post the login page to the user. The default timeout value configured in the Android OS is 10.000 milliseconds. Solution The solution for this is to create a custom URL category and include the following sites, and exclude from captive portal authentication.    KitKat Version: clients3.google.com/ clients3.google.com/generate_204   Lollipop Version: connectivitycheck.android.com connectivitycheck.android.com/generate_204   MarshMallow Version: connectivitycheck.gstatic.com connectivitycheck.gstatic.com/generate_204            
View full article
smalayappan ‎11-09-2016 10:58 AM
7,053 Views
0 Replies
1 Like
Symptom User-ID updates sent to the User-ID Agent via XML with a timeout value are not removed from the User-ID Agent when the timeout expires but they are removed on the Palo Alto Networks firewall. Although this is not a serious issue, customers may want to look at the User-ID Agent GUI to see the connected users.   Cause The User-ID Agent does not proactively time out entries. However, it keeps track of each entry's time-stamp and timeout value. When the User-ID Agent receives an get-all or query-ip, each entry will be examined and deleted if it has timed out.   Resolution To trigger a get-all, perform one of the following steps: Close and reopen the User-Id Agent GUI. This will trigger a get-all to the agent service and the timed-out entries will be deleted. Run the following command on the Palo Alto Networks firewall to trigger a get-all: > debug user-id refresh user-id agent <name> In this case, the agent service will delete the timed-out entries and then inform all connected firewalls. The User-ID Agent GUI will show that all entries for timed-out users are removed.
View full article
sberti ‎11-03-2016 06:12 AM
6,328 Views
1 Reply
1 Like
Issue Users cannot authenticate through the LDAP authentication. The system logs return the following errors: 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   Resolution An invalid LDAP Bind DN (Distinguished Name) for the directory server and password results in authentication failures. Go to Device > LDAP server profile, and make sure the following fields are entered correctly in the LDAP server profile and reflect the correct user a/c information: Bind DN Bind Password   The Bind DN can be verified by navigating to Device > User Identification > Group Mapping.  If the Bind DN is correct, the tree updates and pulls the information based on the LDAP schema settings configured on the LDAP profile. An incorrect Bind DN displays an "Invalid Credentials" error.   The Bind DN information can be acquired from the Active Directory server by searching for the appropriate user in the LDAP server profile: Right-click to Properties to navigate to the Administrator Properties > Attribute Editor:   owner: bsyeda
View full article
bsyeda ‎07-13-2016 01:37 AM
46,734 Views
1 Reply
Question Can uPN (userPrincipalName) be used for retrieving ip-to-user mapping or user-group mapping?   Answer   Currently, only the 'sAMAccountName' value is supported to retrieve the user-group mapping and ip-to-user mapping; uPN is not supported.   Feature Request FR ID : 3405, is open for this feature. If you require this feature, you may contact your account team or SE team to vote for this feature.   Note: uPN can be used for authentication but not to retrieve mappings.
View full article
crajariyap ‎06-23-2016 08:47 AM
5,362 Views
9 Replies
 The following information describes the ports used for communication between the Palo Alto Networks firewall, User-ID Agent (as well as for agentless User-ID), and Active Directory Domain Controller communication protocols.   Protocols   1. LDAP (Ports used to talk to > LDAP (for authentication and group mapping) • TCP 389 > TCP port 389 and 636 for LDAPS (LDAP Secure) • TCP 3268 > Global Catalog is available by default on ports 3268, and 3269 for LDAPs     2. RADIUS: UDP port 1812 is used for RADIUS authentication. Some network access servers might use UDP port 1645 for RADIUS authentication messages   3. Kerberos: Uses UDP port 88 by default     User-ID (Ports used to talk to User-ID Agent)   • TCP 5007 (The default Windows User-ID Agent service port number is 5007, though it is changeable) Ports Used for Active Directory Protocols and User-ID Communications to Firewall     Agentless   • Agentless User-ID uses WMI to pull security logs that initially use port 389, but then negotiate using dynamic random ports for data. Hence, allow all ports need to be allowed.   See Also User-ID Best Practices - PAN-OS 5.0, 6.0
View full article
saryan ‎05-06-2016 04:28 PM
7,030 Views
0 Replies
This document describes checks and commands to troubleshoot Captive Portal on a Palo Alto Networks firewall.   Details Make sure that captive portal is enabled. Make sure user identification is enabled on the ingress zone. Make sure there is a captive portal policy. Keep in mind that a security policy needs to be matched first before the session is redirected to captive portal, thus if a deny policy is matched the packets will be dropped and the session will not be redirected to the captive portal. Note: In order for captive portal to work, the following is needed in the security policy: Web-browsing and DNS must be allowed for the captive portal page is brought up on http port 80 DNS query is needed for URL look up. This action spawns the captive portal redirect. Captive portal uses SSL to connection on ports 6080,6081,6082,6083 not 443. Use the following command to reset any captive portal session (the client will have to authenticate again). The IP address in the following commands is the IP address of the client: > debug user-id reset captive-portal ip-address 1.1.1.1   Use the following commands to check the captive portal log: > less mp-log appweb3-l3svc.log   For more details, enable l3svc debug level: >  debug l3svc on debug   Captive portal session counter can be viewed through global counter: > show counter global | match session_svc   The following is a capture of a captive portal session. Captive portal redirects the session to an internal/local captive portal port (6080) and captive portal zone (N/A): 1435247/1 10.16.2.112[1078]/l2-lan-trust/6        72.240.47.70[80]/l2-lan-untrust web-browsing    DISCARD FLOW    1449020/1 10.16.2.112[1103]/l2-lan-trust/6        72.240.47.70[6080]/N/A          ssl            ACTIVE  FLOW  ND 1449021/1 10.16.2.112[1102]/l2-lan-trust/6        72.240.47.70[80]/N/A            web-browsing    ACTIVE  FLOW  ND 1432627/1 10.16.2.112[1060]/l2-lan-trust/6        72.240.47.70[21]/l2-lan-untrust ftp            DISCARD FLOW    1436228/1 10.16.2.112[1081]/l2-lan-trust/6        207.68.173.76[80]/l2-lan-untrus web-browsing    DISCARD FLOW   For more information about the session via the CLI, type:   > show session id 1449020 session 1449020 c2s flow: source: 10.16.2.112[l2-lan-trust] dst: 72.240.47.70 sport: 1103 dport: 6080 proto: 6 dir: c2s state: ACTIVE type: FLOW ipver: 4 src-user: 0 dst-user: 0   s2c flow: source: 127.3.1.1[N/A] dst: 10.16.2.112 sport: 443 dport: 1103 proto: 6 dir: s2c state: ACTIVE type: FLOW ipver: 4 src-user: 0 dst-user: 0 start time : Thu Jul 24 17:10:04 2008 timeout : 1800 sec time to live : 1749 sec total byte count : 3872 layer7 packet count : 12 vsys : vsys1 application : ssl rule : captive-portal session to be logged at end : no session in session ager : yes session sync'ed from HA peer : no address/port translation : destination layer7 processing : enabled URL filtering enabled : no session terminated on host : yes captive portal session : yes   See also: How to Configure Captive Portal   owner: jnguyen
View full article
jnguyen ‎04-18-2016 08:10 PM
27,398 Views
5 Replies
1 Like
Symptoms   Admins are having issues accessing accounts over the command line using RADIUS VSA authentication for the first time. Diagnosis When using RADIUS VSA accounts, the firewall hasn’t created an account for the user, so there is no user profile or other settings created, and the user is unable to login. By logging into the GUI, the firewall is forced to go to the RADIUS server to verify the account and create it on the firewall.   This problem is unique to authenticating via RADIUS VSA-based accounts because all other account types require an account to be created on the firewall manually first, which means the account already exists when they attempt to login. Solution Log into the GUI site of the firewall first. After this, you should be able to log in to the account through the CLI.
View full article
cagnew ‎02-03-2016 04:46 PM
2,546 Views
1 Reply
  Issue You have configured your portal and gateway to use the authentication profile and certificate profile 2 factor authentication, but you see the below error message in the status page of the GlobalProtect client when try to connect the GlobalProtect on the client computer: "Required Client Certificate is not found"   You also see this error message in the PanGP Service Log: 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.   Solution These errors occured because there is no correct/valid certificate in the client computer. The certificate imported to the client machine must match with the 'Server Certificate' in the portal and gateway setting. In cases of self-signed certificates, the certificate will need to be imported to both personal and trusted root CA. For instructions of how to import the certificate to the client computer, please click here and refer to step #2.   Follow these instructions to import the certificate in P12 format to the client computer (Windows Machine):   Click Start > Run mmc. Click File > Add/Remove Snap-In. Select Certificate and click Add, and select Computer Account. Click OK. Now you can import the Certificate to 'Personal' and 'Trusted Root CA.'
View full article
hsanada ‎01-22-2016 07:26 AM
32,314 Views
2 Replies
Symptoms When attempting to log in to the terminal (GUI and SSH are not affected by this), a message in all caps of "LOGIN INCORRECT" shows. Diagnosis The terminal driver in the Linux root system causes this behavior. When entering all capital letters at the first attempt to log in will set the terminal driver to assume that the entry mechanism is not capable of lower-case letters. This forces the output to show in all upper case, such as:   PA-500 login: ALLCAPS PASSWORD: LOGIN INCORRECT   Note that the prompt has changed from the typical "Password" to all caps "PASSWORD".   What is actually happening is that the output is all caps, but the Linux system is converting the input to all lower case, including the password. Solution A workaround for this issue exists:   When first attempting to log into the terminal, first enter a semi-colon as the user name. The system will tell you the login was incorrect, but will not revert to an all-caps format.   PA-500 login: ; Login incorrect login: ALLCAPS Password: Welcome ALLCAPS.   If the first login has already been attempted using all caps, hitting enter 6-7 times (depending if you attempted the password on the first attempt already) will bring you back to the standard login attempt. At this point the above workaround can be completed successfully:   PA-500 login: ALLCAPS PASSWORD: LOGIN INCORRECT LOGIN: PASSWORD: LOGIN INCORRECT LOGIN: PASSWORD: LOGIN INCORRECT LOGIN: PASSWORD: LOGIN INCORRECT PA-500 login: ; Login incorrect login: ALLCAPS Password: Welcome ALLCAPS.   Moving to a user name with at least one lower-case letter will prevent this issue from happening at all.
View full article
gwesson ‎11-13-2015 04:57 PM
2,991 Views
0 Replies
Cause   When connecting an iOS device to wifi, it will automatically start making several outbound connections to services on the domains listed below. If captive portal is configured these connections will trigger captive portal redirects but these will not be visible to the user as the conenctions are made in the background. To prevent overtaxing the Captive Portal service, the number of connections to the service is limited per source. This could cause a legitimate safari connection to remain blank for a while, until the background connections time out and more CP threads are made available to the client.      Resolution   To prevent the user from getting a blank screen or long load time , you can whitelist the below listed domains.     Android Captive Portal Detection: Domain names to white list:       clients3.google.com   iOS 6: Domain names to white list:   gsp1.apple.com *.akamaitechnologies.com www.apple.com apple.com   iOS 7: Domain names to white list:   www.appleiphonecell.com *.apple.com www.itools.info www.ibook.info www.airport.us www.thinkdifferent.us *.apple.com.edgekey.net *.akamaiedge.net *.akamaitechnologies.com     Then create a no captive portal rule and keep this on top of the existing captive portal rule.     Commit the changes and attempt new connections from the iOS devices.   It will still prompt the iOS user to enter user credentials from their default Safari browser when their device connects to your network, and enforce the Internet access policy of that user base on his/her AD security group membership.
View full article
rsriramoju ‎10-28-2015 07:08 PM
7,390 Views
0 Replies
1 Like
Palo Alto AD Integration The Palo Alto Networks firewall can be integrated with Microsoft’s Windows Active Directory through LDAP. The new version of PAN-OS allows agentless authentication with Active Directory Domain controller; however, WMI settings (Windows Management Instrumentation) on the AD Domain Controller must be modified and you must be Domain Admin to do so.   Prerequisites Before you integrate a Palo Alto Networks device with AD, you must create a user ID in AD that you'll use to access LDAP. At a minimum, this account must be a member of the built-in Server Operators group in AD. For security reasons and to be compliant with the best practices, you should adhere to the minimum access rights for this account. For this demonstration, we created a user, paloaltoladap@paynetonline.com, in AD with an appropriate password, and we added this account to Server Operators Group.     Definitions   Windows Management Instrumentation (WMI) is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components. CIM is developed and maintained by the Distributed Management Task Force (DMTF).   Obtaining management data from remote computers makes WMI useful. Remote WMI connections are made through DCOM. An alternative is to use Windows Remote Management (WinRM), which obtains remote WMI management data using the WS-Management SOAP-based protocol.   Management applications or scripts can get data or perform operations through WMI in a variety of languages.   Common Information Model version 2 is an open standard that defines how managed elements in an IT environment are represented as a common set of objects and relationships between them. The Distributed Management Task Force maintains the CIM to allow consistent management of these managed elements, independent of their manufacturer or provider.   One way to describe CIM is to say that it allows multiple parties to exchange management information about managed elements. However, this description falls short because CIM not only represents these managed elements and the management information, but also provides means to actively control and manage these elements. By using a common model of information, management software can be written once, then work with many implementations of the common model without complex and costly conversion operations or loss of information.   The Palo Alto Networks operationg system is based on the Unix platform, an open standard that anyone can modify, but the industry also agreed to some standards ensure the devices can talk to each other. This is why you need to make small changes to WMI on the Domain Controller in the agentless integration with AD.     Modifying WMI After you log in as a Domain Admin to Domain Controller, launch WMI by entering wmimgmt.msc on the Start Run menu. The following GUI displays:       Highlight WMI Control (Local), go to the properties and click the Security tab to access the root of CIMV2:       Double-click Root to expand it and navigate to the root of CIMV2. Expand it to get to Security folder, where you add the paloaltoladap@paynetonline.com user account.         Grant Enable Account and Remote Enable permissions to the paloaltoladap@paynetonline.com account.     Save all the changes, and you're ready to configure the Palo Alto Networks integration with the AD.     Overview of the Palo Alto Networks WebGUI   The Web-based GUI is user friendly, but some functions are unique to Palo Alto Networks. Gear boxes allow users to access additional configuration options.     Locate the Add button at the bottom of the GUI.     Changes to the configuration file do not take effect until you Commit the changes. Saving changes does not commit them. The GUI has three options in the upper right corner: Commit, Lock, and Save:     Commit  is grayed out if there are no changes to the config file — if there are changes, the option is light blue. Lock prevents any changes to the config file. Save allows changes without committing them.   Config changes do not require rebooting.   The main GUI is divided into two sections — tabs on the top and the left pane with configuration settings for each option defined in tabs.     Subtabs allow configuring additional options.     To integrate with the Windows AD, you must enter the IP addresses of the Windows DNS servers and the NTP server. After you log in to the Palo Alto Networks device, click the Device tab and Setup in the left pane. From the subtab menu, click the Services tab, then the Gear box in the corner, as shown in the following example.     Under Services, add IP addresses for the Primary and Secondary DNS servers.        Under NTP, add the IP address for the NTP server.     After you configure DNS settings, familiarize yourself with the following options in the left pane: Administrators, User Identification, Server Profiles > LDAP, and Authentication Profile.       It's a good idea to follow a specific sequence to configure integration with AD to eliminate errors. We recommend starting with LDAP configuration. You will expand the Server Profiles section and navigate to LDAP. In the lower left corner of the GUI, click Add.     LDAP—at the lower left corner of the GUI, click the Add button to add LDAP Server Profile.     The LDAP Server Profile displays, allowing you to configure authentication with the LDAP server. Because you can have more than one LDAP Server Profile, it's important to give each one a logical name.   Have the following information ready before proceeding with the configuration: LDAP server name LDAP server IP address LDAP port number User account and the password that you used in WMI configuration Base pointers Because there are multiple implementations of LDAP and Palo Alto Networks supports SSL to authenticate with the LDAP, the setting for LDAP type is set to other and the SSL option is checked.   You must name the LDAP Server Profile or you'll be unable to save the configuration. Select a clear and logical name, since you may have multiple LDAP Server Profiles. This name can also follow company naming standards. A clear and understandable naming scheme is extremely helpful when troubleshooting.     The LDAP Servers configuration box is divided into columns and rows. Each row has a cell that must be populated with the appropriate values. To populate the cell, click until it turns Yellow and the cursor starts blinking. After you fill out information in the cell, tab to the next one.      For the type of the LDAP server, select active-directory from the drop-down menu.     The Base can be entered manually or it will populate after you enter Bind DN login id and the password.  If you don’t have SSL configured to connect to LDAP, then uncheck the SSL or you won't be able to connect to the LDAP Server.     After you click OK, commit the change to the running config. Now you are ready to establish WMI connection with the Windows Domain Servers.   Click User Identification in the left pane, User Mapping tab, then the Gear box to enter the same credentials you used to configure WMI settings on the Domain server — in this case, the credentials are paloaltoldap.       Specify the domain where the user account resides —i n this case, it is paynetonline\paloaltoldap.     Complete all the steps, then add your Windows Domain Controllers by clicking Discover in the Server Monitoring section. The Domain Controllers self-populates with a status of Connected. This is indicates that you have successfully established connection with the Windows AD LDAP.  A status of Disconnected (Red) means a mistake in the configuration, most likely, an authentication issue.  Verify WMI configuration and account credentials.      The next step is to create the Authentication Profile. There could be several authentication profiles; therefore, it is important to logically name them. Click Authentication Profile in the left pane, then click Add.     It's important to use a clear and logical name for Authentication Profile because you may have multiple profiles with various users’ rights. Secondly, Palo Alto Networks PAN-OS doesn't allow saving an Authentication Profile without a name. Switch Authentication type from Local Database to LDAP by clicking the arrow to expand the drop-down menu.       Select the Server Profile you just created in the previous section and set the Login Attribute to sAMAccountNAme.       sAMAccountNAme is an important setting. This attribute specifies the login name used to support clients and servers running LAN manager and older versions of the operating system, such as Windows NT 4.0, Windows 95, and Microsoft Windows 98.   cn: SAM-Account-Name ldapDisplayName: sAMAccountName attributeId: 1.2.840.113556.1.4.221 attributeSyntax: 2.5.5.12 omSyntax: 64 isSingleValued: TRUE schemaIdGuid: 3e0abfd0-126a-11d0-a060-00aa006c33ed systemOnly: FALSE searchFlags: fPRESERVEONDELETE| fANR | fATTINDEX rangeLower: 0 rangeUpper: 256 attributeSecurityGuid: 59ba2f42-79a2-11d0-9020-00c04fc2d3cf isMemberOfPartialAttributeSet: TRUE systemFlags: FLAG_SCHEMA_BASE_OBJECT |  FLAG_ATTR_REQ_PARTIAL_SET_MEMBER schemaFlagsEx: FLAG_ATTR_IS_CRITICAL   You cannot log in using your Windows login user name if the sAMAccountNAme attribute is undefined.   The last step is to add or create login accounts for the firewall’s administrators. The accounts have to match account naming conventions used in your Active Directory. Click the Administrators link in the left pane, then click Add.     The name must match the user ID in the Active Directory. For the Authentication Profile, select the profile you just created in the previous section — in this case, it is Paynet Admins.     After you switch the Authentication Profile, you do not have to enter any passwords. By default, all the Firewall Admins are set to Superuser.     Firewall Admin rights can be set to: Superuser Superuser (read-only) Device administrator Device administrator (read-only)   Finally, the following is what you see after the configuration is complete. Notice that the Authentication Profile column tells you which profile is being used by each user.    
View full article
rchougale ‎10-27-2015 08:44 PM
70,971 Views
0 Replies
5 Likes
Yes, There is a limit on how many entries can be added for Access Control List (ACL) on the User-ID Agent. The current ACL limit is 1024 entries.   owner: ssharma  
View full article
ssharma ‎09-10-2015 02:42 PM
3,685 Views
0 Replies
Details The following attributes for LDAP authentication can be used: Login= sAMAccountName Firstname = givenName Lastname  = sN Email = mail   Under Authentication Profile, the above attributes are entered for the "Login Attribute" value:     Example On Active Directory: logon name: paloalto Email: palo.alto @ pan.com First name: palo Last name: alto   The ip-user-mappings (captive portal login) will show the following: For attribute "sAMAccountName" 192.168.163.100 vsys1 CP      pan\paloalto For attribute "mail" 192.168.163.100 vsys1 CP      pan\palo.alto For attribute "givenName" 192.168.163.100 vsys1 CP      pan\palo For attribute "sN" 192.168.163.100 vsys1 CP      pan\alto Note: The same information will appear under Monitor > Logs > Traffic > Source User.   owner: rsingh
View full article
rsingh ‎09-10-2015 05:27 AM
9,525 Views
0 Replies
Overview There is a limited number of LDAP servers that can be configured on one LDAP Profile on Palo Alto Networks assets. Four LDAP servers are supported in an LDAP Profile.   Details Usually four LDAP servers are more than enough to authenticate all the users in the domain, and to provide redundancy in case a LDAP server goes down. Sometimes, larger companies have more than four LDAP servers with distributed environments in which users connect to dedicated LDAP servers. Users may contact LDAP servers that are not one of the four servers, and will try to authenticate to them.   If adding four LDAP servers in the LDAP Profile (under Device > Server Profiles > LDAP) the "plus" button will be greyed out, and it will not be possible to add more servers in the profile.   This limitation for authentication with only four LDAP servers can be overcome with the use of another LDAP Profile, which includes the rest of the LDAP servers. For example:     Create authentication profiles for both of the LDAP Profiles, Under Device > Authentication Profile.   Authentication profiles can be combined in an authentication sequence. If a user is not found on one of the LDAP servers in the first authentication profile it will attempt the next one, which should result in a successful authentication attempt as a whole on the firewall. This is configured under Device > Authentication Sequence:   This sequence can now be used for any purpose, such as GlobalProtect authentication:   owner: ialeksov
View full article
ialeksov ‎09-09-2015 01:46 PM
3,448 Views
0 Replies
1 Like