Configuration Articles

Featured Article
This document is a 'how to' guide in configuring Captive Portal in a Vwire Deployment. It will provide documentation on implementing either Transparent or Redirect mode with Client Certificate Authentication.   Transparent Mode:   Transparent—The firewall intercepts the browser traffic per the Captive Portal rule and impersonates the original destination URL, issuing an HTTP 401 to invoke authentication. However, because the firewall does not have the real certificate for the destination URL, the browser will display a certificate error to users attempting to access a secure site. Therefore you should only use this mode when absolutely necessary, such as in Layer 2 or virtual wire deployment.   Generate the Captive Portal Server Certificate. In this instance, I'm using the Trusted Root CA also used to sign the intermediate/client certificate. You can certainly create a separate Server Certificate if you wish.       Create the authentication profile to utilize. In this case, LDAP is used to authenticate unknown users.       Enable Captive Portal using Transparent Mode. As noted, we are using the previously created LDAP authentication profile and the Captive Portal Server Certificate.       Configure your Captive Portal Policies: (Note, to trigger CP on SSL enabled websites, SSL Decryption will need to be enabled)     After committing your changes, open up a web-browser on the system (the source IP must be an unknown user otherwise you will not get a captive portal prompt) behind the Vwire Trust zone (Note, make sure this zone is enabled for user identification). My host IP is 192.168.125.111 and it's currently unknown on the PA's ip-user-mapping.   admin@lab-26-PA5050> show user ip-user-mapping all   admin@lab-26-PA5050>     As previously mentioned, when using transparent mode, all browsers will issue a warning indicating that the destination url does not match the common name found in the certificate.       After accepting the exception for the common name mismatch, you will be presented with the Captive Portal Web Form requesting for the credentials to authenticate the user.     Upon completing the web form and entering the correct credentials, users will be redirected to the original requested URL/website.     The session table and IP mapping will appear as follows:   admin@lab-26-PA5050> show user ip-user-mapping all     IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.111 vsys1  CP      rkalugdan                        888            3462 Total: 1 users       admin@lab-26-PA5050> show session id 33570653     Session        33570653             c2s flow:                 source:      192.168.125.111 [vtrust]                 dst:         209.95.138.162                 proto:       6                 sport:       39066           dport:      80                 state:       ACTIVE          type:       FLOW                 src user:    rkalugdan          <==================================== via Captive Portal                 dst user:    unknown             s2c flow:                 source:      209.95.138.162 [vuntrust]                 dst:         192.168.125.111                 proto:       6                 sport:       80              dport:      39066                 state:       ACTIVE          type:       FLOW                 src user:    unknown                 dst user:    rkalugdan             DP                                   : 1         index(local):                        : 16221         start time                           : Tue Jan 27 08:27:52 2015         timeout                              : 3600 sec         time to live                         : 3593 sec         total byte count(c2s)                : 1381         total byte count(s2c)                : 1006         layer7 packet count(c2s)             : 13         layer7 packet count(s2c)             : 12         vsys                                 : vsys1         application                          : web-browsing         rule                                 : vwire         session to be logged at end          : True         session in session ager              : True         session updated by HA peer           : False         layer7 processing                    : enabled         URL filtering enabled                : True         URL category                         : content-delivery-networks         session via syn-cookies              : False         session terminated on host           : False         session traverses tunnel             : False         captive portal session               : False         ingress interface                    : ethernet1/6         egress interface                     : ethernet1/4         session QoS rule                     : N/A (class 4)         end-reason                           : unknown         Redirect Mode:     Redirect—The firewall intercepts unknown HTTP or HTTPS sessions and redirects them to a Layer 3 interface on the firewall using an HTTP 302 redirect in order to perform authentication. This is the preferred mode because it provides a better end-user experience (no certificate errors). However, it does require additional Layer 3 configuration. Another benefit of the Redirect mode is that it provides for the use of session cookies, which enable the user to continue browsing to authenticated sites without requiring re-mapping each time the time outs expire. This is especially useful for users who roam from one IP address to another (for example, from the corporate LAN to the wireless network) because they will not need to re-authenticate upon IP address change as long as the session stays open. In addition, if you plan to use NTLM authentication, you must use Redirect mode because the browser will only provide credentials to trusted sites.   (To use the captive portal in redirect mode, you must enable response pages on the interface management profile assigned to the Layer 3 interface to which you are redirecting the active portal.)     In this example, I've generated a Trusted Root CA, an intermediate CA which is then signing the client certificate for use in client certificate authentication. For the Trusted CA, which will be used as the Captive Portal Server certificate, I will use 'cpcaroot.pantac2008.com' as the CN and the client cert will have its CN as 'renato.' We will use 'renato' to help identify the users being captive portal'd via the client cert profile.       The 'CA_Root', 'intermediate' certificates are exported  in PEM format from the PA and imported into the host client. This can be done more seamlessly in a production environment via GPO.  In this scenario, I've imported them to the Trusted Root and Intermediate CA stores respectively.             The client certificate signed by the intermediate cert will need to be exported in PKCS12 format as it will require both the private and public keys to make this work. It will then be imported into your Personal Certificate store accordingly.             The same Captive Portal Policies apply as shown below.       Create the Certificate Profile to utilize for Client Certificate Authentication. Insert both the Trusted Root CA and Intermediate CA within the CA Certificates option. Username Field will be 'Subject' defaulting to common-name. You can modify this option to help identify your users. As mentioned, we'll be using the CN 'renato' to help identify the Captive Portal user by choosing Subject in the Username Field.       Enable the Captive Portal and choose 'Redirect' mode. This will enable other fields that require your attention. I'm using the same Trusted Root CA as the server certificate. The CN used was 'cpcaroot.pantac2008.com. This will be the redirect host configured and we then point to the client cert profile previously created.       In this example, I will have to make sure my host machine knows how to reach 'cpcaroot.pantac2008.com' so I have to configure the host file accordingly. This should not be a problem in a production environment if DNS is able to resolve the fqdn defined as your Redirect Host which should also match the CN for your server certificate.     Windows host file output:   # Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 192.168.125.2     cpcaroot.pantac2008.com     In Vwire deployment while using redirect mode, we'll need to burn an L3 interface on the PA device to get this functional. The interface is assigned to the L3-Trust zone and has a mgmt profile enabled with at the very least, response pages. Notice the IP address used is 192.168.125.2, which is what my system will be redirected to once Captive Portal is triggered given the use of the CN 'cpcaroot.pantac2008.com' in the Captive Portal Server Certificate.   Also, keep in mind that the redirected host will need to be in the same broadcasts domain as the client so that it will respond to arp requests accordingly. If the Captive Portal redirect interface is outside the of the clients broadcast domain and the traffic needs to traverse the v-wire you will need to create an exception policy to allow the traffic destine to this interface a Captive Portal intervention       Here's the screenshot of the host attempting to open a socket to www.google.com. The browser then submits the client cert to the PA device as we're using client certificate authentication instead of LDAP in this scenario. I subsequently redirect the browser to www.jimmyr.com and I'm now presented the web page and CP has identified me as 'renato' per my client certificate.           Previously seen as unknown for 192.168.125.223:   admin@lab-26-PA5050> show user ip-user-mapping all     IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.223 vsys1  Unknown unknown                          2              5 Total: 1 users     Upon completing the client certificate authentication, the PA now reflects the following:     admin@lab-26-PA5050> show log system direction equal backward 2015/01/27 09:05:58 info     general        general 0  User admin logged in via CLI from 192.168.125.223 2015/01/27 09:05:58 info     general        auth-su 0  User 'admin' authenticated.   From: 192.168.125.223. 2015/01/27 09:05:40 info     general        general 0  Captive Portal authentication succeeded for user: renato on 192.168.125.223, vsys1 2015/01/27 09:05:40 info     general        general 0  Captive Portal client certificate authentication successful from ::ffff:192.168.125.223.         admin@lab-26-PA5050> show user ip-user-mapping all     IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.223 vsys1  CP      renato                           899            3518 192.168.125.111 vsys1  CP      rkalugdan                        261            1037 Total: 2 users             admin@lab-26-PA5050> show session id 33571113     Session        33571113     c2s flow: source:      192.168.125.223 [vtrust] dst:         216.58.216.2 proto:       6 sport:       51049           dport:      80 state:       ACTIVE          type:       FLOW src user:    renato   <====================================================== dst user:    unknown     s2c flow: source:      216.58.216.2 [vuntrust] dst:         192.168.125.223 proto:       6 sport:       80              dport:      51049 state:       ACTIVE          type:       FLOW src user:    unknown dst user:    renato     DP                                   : 1 index(local):                        : 16681 start time                           : Tue Jan 27 09:05:41 2015 timeout                              : 3600 sec time to live                         : 3580 sec total byte count(c2s)                : 3637 total byte count(s2c)                : 9854 layer7 packet count(c2s)             : 10 layer7 packet count(s2c)             : 14 vsys                                 : vsys1 application                          : web-browsing rule                                 : vwire session to be logged at end          : True session in session ager              : True session updated by HA peer           : False layer7 processing                    : enabled URL filtering enabled                : True URL category                         : web-advertisements session via syn-cookies              : False session terminated on host           : False session traverses tunnel             : False captive portal session               : False ingress interface                    : ethernet1/6 egress interface                     : ethernet1/4 session QoS rule                     : N/A (class 4) end-reason                           : unknown       Here's an example of client certificate authentication using an Ubuntu client with Firefox as the browser. I've installed the Root CA and intermediate certificate in the Trusted store for Firefox whereas the client certificate is associated with 'Your Certificates' store.         Here's Firefox presenting the client certificate upon the user's attempt to access www.jimmyr.com           Finally, the original requested website is presented to the user       PA CLI output fo the syslog and ip-user-mapping below:   admin@lab-26-PA5050> show user ip-user-mapping all IP Vsys   From User IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.111 vsys1  CP renato 893            3561         Total: 1 users dmin@lab-26-PA5050> show log system direction equal backward Time Severity Subtype Object EventID ID Description =============================================================================== 2015/01/27 13:24:07 info general        general 0 Accepted keyboard-interactive/pam for admin fr om 192.168.125.111 port 50672 ssh2 2015/01/27 13:23:45 info general        general 0  User admin logged in via CLI from 192.168.125.1 11 2015/01/27 13:23:44 info general        auth-su 0  User 'admin' authenticated.   From: 192.168.125 .111. 2015/01/27 13:23:11 info general        general 0  Captive Portal authentication succeeded for use r: renato on 192.168.125.111, vsys1 2015/01/27 13:23:11 info general        general 0  Captive Portal client certificate authenticatio n successful from ::ffff:192.168.125.111.   The following is an example from a MacOS client using the Chrome browser. We've copied the same certs using the Keychain Access Certificates and My Certificates folder respectively.           As you can see once again, PA is requesting client certificate authentication and Chrome is presenting said client certificate as expected.             admin@lab-26-PA5050> show user ip-user-mapping all   IP Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.113 vsys1 Unknown unknown 3              6 Total: 1 users   admin@lab-26-PA5050> show user ip-user-mapping all   IP Vsys   From    User                             IdleTimeout(s) MaxTimeout(s) --------------- ------ ------- -------------------------------- -------------- ------------- 192.168.125.113 vsys1 CP      renato                           899            3585 Total: 1 users     Time Severity Subtype Object EventID ID Description =============================================================================== 2015/01/27 13:00:40 info     general        general 0  WildFire update job succeeded  for user Auto update agent 2015/01/27 13:00:39 info     general        general 0  Wildfire package upgraded from version <unknown version> to 51969-58674 by Auto update agent 2015/01/27 13:00:37 info     general        general 0  Installed wildfire package: panup-all-wildfire-51969-58674.tgz 2015/01/27 13:00:35 info     general        general 0  WildFire version 51969-58674 downloaded by Auto update agent 2015/01/27 13:00:34 info     general        general 0  Connection to Update server:  completed successfully, initiated by 10.46.32.26 2015/01/27 13:00:23 info     general        general 0  Connection to Update server: updates.paloaltonetworks.com completed successfully, initiated by 10.46.32.26 2015/01/27 13:00:21 info     general        general 0  Connection to Update server: updates.paloaltonetworks.com completed successfully, initiated by 10.46.32.26 2015/01/27 13:00:20 info     general        general 0  Captive Portal authentication succeeded for user: renato on 192.168.125.113, vsys1 2015/01/27 13:00:20 info     general        general 0  Captive Portal client certificate authentication successful from ::ffff:192.168.125.113.    
View full article
gswcowboy ‎09-14-2018 11:44 AM
41,498 Views
0 Replies
Issue The User-ID Agent contains an ignore-list.txt file with the list of users that need to be ignored and also has NetBios probing enabled. The firewall should not be aware of the users in the ignore-list file and should be redirected to a Captive Portal page for Web authentication.   This occurs when the user logs in to the same host machine twice, first using regular corporate credentials that are not included in the ignore-list.txt file and a second time with one of the usernames included in the ignore-list.txt file, for example ignore-this-user1. When this happens, the User-ID Agent doesn’t update the change by binding the host’s IP to the new username and ignores it, which furthers implies that the association with previous user stays on the firewall.   The newly logged user can pass through the firewall without being redirected to the Captive Portal authentication page.       Cause This occurs when the client doesn’t perform a proper log-off and log-on but instead just switches from one username to another on a Windows host machine. In that case, the windows machine can preserve both users and reply with both usernames to NetBIOS probe. In the example below, we can see the host machine replying with both usernames, one after another, making the User-ID Agent believe that the old user is still logged in and active:   04/24/15 10:46:03:652[Verbo 398]: tid 4288: NetBIOS user enumeration on IP 192.168.178.175: tac-emea\ignore-this-user1   <<<<<<<<<<< new user 04/24/15 10:46:03:652[Verbo 398]: tid 4288: NetBIOS user enumeration on IP 192.168.178.175: tac-emea\ dragoslav <<<<<<<<<<< old user 04/24/15 10:46:03:652[Debug 480]: tid 4288: NetBIOS query found IP 192.168.178.175 with username europe\ dragoslav. 04/24/15 10:46:03:652[Debug 132]: Done probing IP 192.168.178.175, tid 4288, jobID 7895710. 04/24/15 10:46:03:652[Verbo 190]: pool(probing): thread 4288 finished work 7895710
View full article
djoksimovic ‎08-28-2018 10:33 AM
2,651 Views
0 Replies
Steps Click Device. Under Server Profiles, click on LDAP. Click Add to bring up the LDAP Server Profile dialog. Enter Server name, IP Address and port (389 LDAP). Select LDAP server type from drop down menu. Enter the Base Distinguished Name for the domain. Enter the Bind DN and Bind Password for the service account. Uncheck SSL checkbox (SSL can be used if the Domain Controller will listen for LDAP SSL on port 636).   Commit changes.   owner: bnelson
View full article
bnelson ‎06-26-2018 03:19 AM
42,308 Views
4 Replies
 What is GlobalProtect with On-Demand?   As the name says, on-demand (at user's will), the user has control over when to connect or disconnect from GlobalProtect. Once connected to GlobalProtect, the user will see a 'disconnect' option to disconnect when needed.   This document explains basic GlobalProtect configuration for on-demand with the following considerations:   Authentication - local database Same interface serving as portal and gateway. Root, intermediate and server certs are generated on PAN   1. Generate a root CA, intermediate CA and a server cert as explained in this document: https://live.paloaltonetworks.com/t5/1-Submit-and-Collaborate/Certificate-config-for-GP-SSL-TLS-Client-cert-profiles/ta-p/131592         2. Create an SSL/TLS profile under Device > Certificate Management > SSL/TLS service profile, referencing the above created 'server certificate'.   3. Create an authentication profile under Device > Authentication Profile > Add.   Name- Give a name to this authentication profile Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement)   Advanced Tab > Allow List > Add - Select all (If you have groups, you may restrict it to required groups) Click OK to save.         4. Create a tunnel interface under Network > Interfaces >Tunnel. Give a tunnel number, virtual router and security zone. It is recommended to create a separate zone for VPN traffic as it gives better flexibility to create separate security rules for the VPN traffic.       Configure GlobalProtect Portal   5. Go to Network > GlobalProtect > Portals > Add. General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.      6. Authentication Tab.   a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.   7. Agent Tab. Add a new client config. a. Authentication tab: Give any name to this client config Client certificate - leave it to none, this will only be needed if we want to push any client certificate to clients for authentication purpose. Save user credentials - Yes(default) (Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '.     b. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if needed)   Important! Gateways tab.  Under 'External gateways', click Add. Give any name to it. Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of step 1. In this example we enter 'gp.portal-gw01.local'        d. App tab. Under 'Connect-method' drop down, select 'On-demand (Manual user initiated connection)'.  Note: To change this GP setup from 'On-demand' to 'user-logon', just change the 'connect-method' from 'on-demand' to 'user-logon'.     e. Click OK to save. f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time.   g. Click OK to save and close GP portal config.     Configure GlobalProtect Gateway   8.  Go to Network>GlobalProtect>Gateways>Add. General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.    9. Authentication Tab. This is similar to step 6 but this is for gateway. a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.     10. Agent Tab. a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down.  b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.   c. Timeout settings - leave them to defaults. For any changes to this, refer to GP admin guide. d. Client settings   Click Add> Give a name to authentication override tab   -(Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate is selected here under portal, the same needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.     e. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if wanted).    Important! If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive IP address from gateway. Common issues here are when the user is identified by GlobalProtect as 'domain\user' but the firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown identical at both places by overwriting domain field in user-identification>group mapping.      f. Network Settings.  Under the Ip-pool:     Very Important! The GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages. (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing the same IP pool range as your primary IP pool.   g. Access Route. This defines which subnets can be reached by GP clients once they are connected to gateway. If left blank, it takes it as 0.0.0.0/0 ie all the traffic from GP client will be forced to go through GP tunnel. For split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc so that GP client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, th is is called split tunneling.   h. Click OK to save and close client settings. One more OK to save and close GP gateway settings.   11. Create a local username/password under Device>Local user database>users for testing. 12. Create security and NAT policies for the newly created VPN zone to give access appropriately. 13. Commit the changes.   To test on client machine   1. From the browser, go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn> 2. Enter the credentials 3. Download the GlobalProtect client  4. In the GlobalProtect client, enter the Portal address and credentials, click connect.    
View full article
dreputi ‎06-18-2018 12:40 PM
20,984 Views
2 Replies
1 Like
Enabling SSO on Aperture requires information from your IDP.  The following section provides details on how to add Aperture as an Application on your IDP and then using information from your IDP to configure SSO on Aperture. Okta is used as IDP.
View full article
ptarra ‎04-23-2018 08:33 AM
7,157 Views
3 Replies
 What is GlobalProtect with User-logon (Always On)?   As the name says, user-logon, the GlobalProtect is connected after a user logs on to a machine. When this is used with SSO (Windows only) or save user credentials (MAC) , the GlobalProtect gets connected automatically after the user logs into the machine. The idea behind user-logon is to have the user 'always' stay connected to GlobalProtect. Once connected to GlobalProtect, the user will see the 'disable' option (if allowed by admin) to disable the GlobalProtect application when needed.   This document explains basic GlobalProtect configuration for user-logon with the following considerations:   Authentication - local database Same interface serving as portal and gateway. Root, intermediate and server certs are generated on PAN   1. Generate a root CA, intermediate CA and a server cert as explained in this document: https://live.paloaltonetworks.com/t5/Configuration-Articles/Certificate-config-for-GP-SSL-TLS-Client-cert-profiles/ta-p/131592       2. Create an SSL/TLS profile under Device > Certificate Management > SSL/TLS service profile, referencing the above created 'server certificate'.   3. Create an authentication profile under Device > Authentication Profile > Add.   Name- Give a name to this authentication profile Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement) Advanced Tab > Allow List>Add - Select all (If you have groups, you may restrict it to required groups) Click OK to save.            4. Create a tunnel interface under Network > Interfaces > Tunnel. Give a tunnel number, virtual router and security zone. We recommend creating a separate zone for VPN traffic as it gives better flexibility and more security to create separate security rules for the VPN traffic.       Configure GlobalProtect Portal   5. Go to Network > GlobalProtect > Portals > Add. General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.      6. Authentication Tab a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.       7. Agent Tab. Add a new client config    a. Authentication tab: Give any name to this client config Client certificate - leave it as none, this will only be needed if we want to push any client certificate to clients for authentication purpose. Save user credentials - Yes (default) (Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate is selected here under portal, the same certificate needs to be selected under Gateway's  config for encrypt/decrypt cookie .      b. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups, if needed)   IMPORTANT! Gateways tab. c. Under 'External gateways', click Add. Give any name to it. Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of Step 1. In this example we enter 'gp.portal-gw01.local'         d. App tab. Under 'Connect-method' drop down, select 'User-logon (Always On)'.  Note: To change this GP setup from 'User-logon' to 'On-demand', just change the 'connect-method' from 'user-logon' to 'on-demand'.    e. Click OK to save. f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time. g. Click OK to save and close GP portal config.     Configure GlobalProtect Gateway   8.  Go to Network > GlobalProtect > Gateways > Add. General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.    9. Authentication Tab. This is similar to step 6 but this is for gateway. a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.     10. Agent Tab. a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down.  b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.   c. Timeout settings - leave them to defaults. For any changes to this, refer to the GlobalProtect admin guide. d. Client settings Click Add> Give a name to authentication override tab -(Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate was selected in step 7 under portal, the same certificate needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.   e. User/User group tab. Leave the OS and User group to 'any' (you may restrict it to required groups if wanted).    IMPORTANT! If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive an IP address from gateway. Common issues here are when the user is identified by GlobalProtect as 'domain\user' but  the firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown as identical at both places by overwriting domain field in user-identification>group mapping.    f. Network Settings.  Under the Ip-pool:       IMPORTANT! GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages. (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing the same IP pool range as your primary IP pool.   g. Access Route. This defines which subnets can be reached by GlobalProtect clients once they are connected to gateway. -If left blank, it takes it as 0.0.0.0/0 ie all the traffic from the GlobalProtect client will be forced to go through GlobalProtect tunnel.   For Split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc. so that the GlobalProtect client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, this is called split tunneling.   h. Click OK to save and close client settings. One more OK to save and close GlobalProtect gateway settings.   11. Create a local username/password under Device > Local user database>users for testing. 12. Create security and NAT policies for the newly created VPN zone to give access appropriately. 13. Commit the changes.   To test on client machine   1. From the browser, go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn> 2. Enter the credentials 3. Download the GlobalProtect client  4. In the GlobalProtect client, enter the portal address and credentials, click connect.    
View full article
dreputi ‎01-25-2018 03:39 AM
41,417 Views
0 Replies
3 Likes
"Result: 'FAIL'  Message: 'Bad request timestamp".
View full article
mgarg ‎12-18-2017 01:03 PM
2,297 Views
0 Replies
Symptoms Captive portal will not work if an Authentication Sequence is referenced as the Authentication Profile in an Authentication Enforcement object, as shown below:    Diagnosis Authentication Enforcement objects do not support Authentication Sequence. Only Authentication Profiles with additional factors can be used.  If an auth-sequence is added to the Auth Enforcement object it is treated as no-captive-portal behaviour. Solution Authentication sequence CAN be used if a default web-form Authentication Enforcement object is used in an Authentication policy and if the Authentication sequence is referenced in Captive Portal Settings under Device -> User Identification, as seen below:  
View full article
nkajgana ‎11-07-2017 12:49 AM
2,508 Views
1 Reply
1 Like
In this video tutorial, Ion demonstrates how to configure Cisco ISE 2.1 with RADIUS vendor ID for Palo Alto Networks and its associated VSAs.
View full article
Ion.Ermurachi ‎03-15-2017 08:34 AM
17,706 Views
3 Replies
2 Likes
This document descibes the basics of configuring certificates in GlobalProtect setup. Please note that there can be other ways to deploy certificates for GlobalProtect which are not covered in this document.   A. SSL/TLS service profile -  Specifies Portal/gateway server cert, every portal/gateway needs one. B. Certificate profile(if any) - Used by portal/gateway to request client/machine certificate C. Installing client/machine cert in end client   A. SSL/TLS service profile In the context of GlobalProtect, this profile is used to specify GlobalProtect portal/gateway's "server certificate" and the SSL/TLS "protocol version range". If same interface serves as both portal and gateway, you can use the same SSL/TLS profile for both portal/gateway. If portal/gateway are served through different interfaces, you can use same SSL/TLS profile as long as the certificate includes both portal/gateway IPs/FQDNs in its Subject Alternate Name(SAN), if not, create different profiles for portals and gateways as needed.   The pre-requisite to create SSL/TLS profile is to either generate/import the portal/gateway "server certificate" and its chain To import a certificate generated externally, navigate to Device>Certificate Management>Certificates and click on 'import' at the bottom. To generate a certificate on the firewall, navigate to Device>Certificate Management>Certificates and click on 'generate' at the bottom.   If the server cert is signed by a well-known third-party CA or by an internal PKI server 1. Import the Root CA (private key is optional) 2. Import intermediate CAs if any (private key is optional) 3. Import the server cert signed by the above CAs "with" private key.   IMPORTANT! If subj alt name(SAN) does not exist in this cert: This cert's common name(CN) 'must' match the portal/gateway's IP or FQDN . If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be one of the entries in that SAN list. In this case the CN can be anything, it does not matter since only SAN will be used to match IP/FQDN. Should not be of type CA. It must be of type end-entity. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. Eg. if portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and if the certificate references the fqdn 'vpn.xyz.com', then the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.   4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     -Name  - Give any name for this profile     -Certificate - Reference the server cert from step 3     -Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server   5. Reference this SSL/TLS profile in portal/gateway as needed.   If the server cert needs to be generated on the Palo Alto Networks  firewall 1. Generate a root cert with common name of any unique value. (other than IP or FQDN of portal/gateway)   (Location: Device>Certificate Management>Certificates click Generate at the bottom of the screen)   2. (optional) Generate a intermediate cert signed by above root cert. Specify its common name as any unique value. (other than IP or FQDN of portal/gateway)   3. Generate a sever cert signed by the above intermediate cert. a. This cert's common name 'must' match the portal/gateway's IP or FQDN if subj alt name(SAN) does not exist in this cert. In PAN firewalls, SAN can be created under the optional 'certificate attributes' of type 'hostname', 'IP' or 'email'. b. If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be present in that SAN list. c. Should not be a CA. d. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. For example. if the portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and the certificate references the fqdn 'vpn.xyz.com', the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.        4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     Name  - Give any name for this profile     Certificate - Reference the server cert from step 3     Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server    5. Reference this SSL/TLS profile in portal/gateway as needed.   B. Certificate Profile (Location: Device>Certificate Management>Certificate Profile) Certificate profile specifies a list of CAs and Intermediate CAs. When this certificate profile is applied to the config, the portal/gateway will send a client certificate request to the client to request for a client/machine cert signed by the CA/intermediate CA specified in the cert profile. It is recommended to place both the root and intermediate CAs in this profile, instead of just root CA.    IMPORTANT! -Client certificate refers to user cert, it can be used for 'user-logon'/'on-demand' connect methods. Used to authenticate a user. -Machine certificate refers to device cert, it can be used for 'pre-logon' connect method. This is used to authenticate a device, not a user.   1. Import the "Root CA" that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 2. Import the "intermediate CAs" if any that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 3. Go to Device > Certificate Management > Certificate Profile, click Add. 4. Give a name to the profile. 5. Add the root and intermediate CAs from Step 1 & 2.   6. Note: Username field by default is set to 'None', in a typical setup where username is pulled from LDAP/RADIUS authentication, you can leave this to none. On the other hand, if certificates are the only method of authentication, that is, if you do not have RADIUS/LDAP for portal/gateway authentication then you must change username field from none to 'Subj' or 'Subj Alt' to extract username from the client certificate common name or email/principal name. Failing to do this will result in a commit failure. 7. (optional) Check CRL or OCSP if the portal/gateway needs to verify the client/machine cert's revocation status using CRL or OCSP. Please use this with caution as it can result in clients failing to connect if used in conjunction with 'Block session if certificate status is unknown'.   8. Reference this certificate profile portal/gateway as needed.   C. Installing client/machine cert in end client   When importing a client/machine certificate, import it in PKCS format which will contain its private key.   Windows -  1. Click Start>Run, type mmc to open Microsoft certificate management console. 2. Go to File > Add/Remove Snap-in:     IMPORTANT! 3. Click Certificates>Add and select one or both of the below:   a. To add client(user) certificate, select 'My user Account'. This is used for 'user-logon' and 'on-demand' since it authenticates a user. b. To add machine(device) certificate, select 'Computer Account'. This is used for 'pre-logon' as it authenticates a machine.           4. Import client/machine certificate into mmc. a. If you are importing client certificate, import it to 'Personal' Folder under 'My user account' b. If you are importing machine certificarte, import it to 'Personal' Folder under 'Computer Account'       5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'     IMPORTANT! 6. Once imported, double click the imported client/machine certificate to make sure  a. It has private key b. Its certificate chain is full upto its root CA. If the chain is missing root CA or intermediate CA, import them to their respective folders as explained in Step 5.         7. At this point, the certificates are imported on the client, so you can close the mmc console without saving it.
View full article
dreputi ‎02-13-2017 11:46 AM
55,054 Views
8 Replies
3 Likes
Overview The Captive Portal is used to create a user-to-IP mappings on the Palo Alto Networks firewall. The portal is triggered based on the Captive Portal policies for http and/or https traffic only and is triggered only for the IP addresses without existing user-to-IP mapping. For user authentication, a local database can be used, RADIUS, Kerberos, or LDAP server. Once identified, user-based policies can be applied to the user’s traffic. While captive portal is most commonly used in a Layer 3 routed environment, this document outlines the steps to configure a V-Wire topology with Captive Portal in redirect mode authenticating to a RADIUS server.     Prerequisites As illustrated above, the network topology for this configuration requires two physical interfaces configured for the inbound and outbound V-Wire. A third physical interface should be configured with an IP and assigned to a zone outside the V-Wire. This L3 interface will be used for the Captive Portal redirect. The firewall will intercept any unknown user sessions that are using HTTP or HTTPS with an HTTP 302 redirect message. The redirection is configured to a specified host name that will be resolved to IP address assigned to L3 interface. Decryption needs to be enabled in order for the firewall to send a redirect message for https traffic. The captive portal should present a certificate and should be trusted by the end users (CA issuing the certificate should be present in Trusted Root store on the client machine). The users will not receive any certificate warning for https redirection. Also, the firewall will set a cookie in the client browser therefore the end user does not need to re-type username/password while cookie is valid (expiry timer can be set in captive portal configuration).   A DNS entry should be made for the IP address configured on the L3 interface. The DNS host name will be used as the Common Name when creating the Captive Portal authentication certificate and can be used in the configuration for the Captive Portal redirect. A RADIUS server with user accounts already defined must be running in the network and configured to operate on ports 1812 or 1645.   Information on configuring RADIUS can be found here: How to Configure Radius on Windows 2008 Server   RADIUS authentication is sent from the firewall management interface to the RADIUS server. If this RADIUS traffic passes through the firewall data ports (Data Plane), a security rule should be created (if not existing already) permitting this traffic. If there is no existing policy denying intra-zone traffic, a security policy will not be required to allow the traffic from L3 interface used by Captive Portal.   Part 1: Configure Captive Portal, Authentication, and Policies   Configure the RADIUS Server Profile Go to the "Device tab > Server Profiles > RADIUS" and create the RADIUS server profile. Fill in the profile Name, server Name, IP Address, Port (1812 or 1645) and Secret.   Configure the Authentication Profile Go to the "Device tab > Authentication Profile" and Add a new profile Fill in a Profile Name, and add the Users which should be able to authenticate against the RADIUS server in the allow list Choose Authentication RADIUS from the drop-down menu (options are None, Local DB, RADIUS, LDAP or Kerberos) Choose the server profile that was just created for the RADIUS server.   Generate a Self-Signed Certificate or Import an Existing Certificate to the Firewall Go to the "Device tab > Certificate Management > Certificates" Option 1: Generate a self-signed certificate; Use the FQDN, which will be mapped in DNS to the L3 interface hosting the captive portal, as the Common Name for the certificate; Other fields are not mandatory.           Option 2: The generated CSR (Certificate Signing Request) will be exported and signed by external authority and then imported back to the firewall (use the same Common Name as for Option 1) Option 3: Import both the certificate and the private key, which were create by the external CA.   Configure Captive Portal Go to the "Device tab > User Identification > Captive Portal Settings" Edit the Captive Portal settings Check the box to enable captive portal Select the previously created or imported Captive Portal certificate for the Server Certificate Select the previously configured Authentication Profile Enable Redirect mode For the Redirect host, type the FQDN which will be translated to interface L3 IP address; The host name must match the Common Name used on the Captive Portal certificate Idle Timer: The amount of time needed to clear captive portal session (mapping) if the authenticated user is inactive Expiration: The maximum time the captive portal session can be active for a single user; after this the mapping will be removed and the user will have to re-authenticate Session cookie timeout is the time session cookie is valid; if the user's browser presents the cookie to the captive portal they do not need to enter credentials again Roaming options allow for the same cookie to be used when the client is roaming (changing the IP address)   Note: In Transparent mode, the firewall is impersonating the destination http/https website and sending http 401 message to invoke authentication. Since the firewall does not have a certificate for the actual destination the user will always receive a certificate warning. Using the Redirect mode is generally recommended.   Configure the Interface Management Profile and Assign it to the Interface: Go to the "Network tab > Network Profiles > Interface Mgmt" Management Profile assigned to the L3 interface needs to have “Response Pages” enabled: Go to the "Network tab > Interfaces" and select the appropriate L3 interface to apply the Interface Management Profile:   Configure Captive Portal Policies: Go to the "Policies tab > Captive Portal" rule base. In this example, authenticating users is coming from the trust zone (make sure the trust zone has the User-ID checkbox enabled) and going to the untrust zone (internet). For the initial test, limit this rule to a single IP or a group of users. Users (IPs) not matching the CP policy can not trigger the CP redirection. Do not configure the redirection for https service if decryption is not enabled. The configured action is "web-form", meaning the user will be redirected to the captive portal page if there is no mapping for its IP address:   Configure and Adjust the Security Rules Based on the Particular Scenario Go to the "Policies tab > Security" rule base Make sure that captive portal traffic is allowed by security policies; we need to ensure that the users being redirected can reach the L3 interface serving the portal page; http redirection is used with port 80, while https redirection is using ports 6080/6081/6082/6083. Make certain the DNS traffic is allowed for the users (in order for redirection to work, user must first try to access external web site) Often, there is no need to create any additional security policies if the intra-zone traffic is enabled. Users from the trust zone will be able to reach the captive portal in the trust zone   Part 2: Test the Captive Portal Confirm that the captive policy rule will be triggered for a particular user using "test cp-policy-match" CLI command; also, check if there is not user-to-IP mapping for the user's IP address > test cp-policy-match source <source_ip> from trust to untrust destination <destination_ip> > show user ip-user-mapping ip <ip_address> > show user ip-user-mapping-mp ip <ip_address> When loading external http/https web sites it should be redirected to the Captive Portal page for authentication. The Captive Portal page can be customized (Device tab > Response Pages). Once the appropriate credentials are entered (checked by the RADIUS server), it will load the initially requested page. The firewall will create user-to-IP mapping (source of the mapping will be marked as CP):     > show user ip-user-mapping-mp all     IP              Vsys   From    User                             Timeout (sec)     --------------- ------ ------- -------------------------------- ----------------     172.16.21.93    vsys1  CP      paloaltonetworks\user1           895                     <<< user mapped by Captive Portal     172.16.32.1     vsys1  GP      pre-logon                        2588475     192.168.21.94   vsys1  AD      paloaltonetworks\user2           6     Total: 3 users     *: WMI probe succeeded   If the user has the mapping on the firewall, it can be cleared for testing purposes and can also clear the captive portal session for a user with the following CLI commands:     > clear user-cache ip <ip_address>     > clear user-cache-mp ip <ip_address>     > debug device-server reset captive-portal ip-address   Useful Troubleshooting Links: Troubleshooting Captive Portal Troubleshooting Captive Portal Redirect Page Issues Captive Portal Page in a Redirect Loop Captive Portal Comfort Page is Not Displayed When Visiting Encrypted Sites   owner: nmarkovic
View full article
npare ‎04-19-2016 07:31 AM
14,242 Views
1 Reply
Overview This document describes the steps to set up Radius for Captive Portal.   Steps Enable the zone for User Identification. Set up the RADIUS Server profile. Set up the Authentication Profile. The Palo Alto Networks device forwards all requests to the RADIUS server for Captive Portal. Set up the User Identification for Captive Portal. Set up the Captive Portal policy.   Note: For PAN-OS 4.1, the action will be captive-portal and not web-form.   owner: panagent
View full article
nrice ‎09-01-2015 03:57 AM
5,396 Views
0 Replies
Issue Unknown users are not redirected to the Captive Portal page when attempting to reach an HTTPS/SSL site, but are redirected when attempting an HTTP site. The Captive Portal policy has been configured properly with options to hijack 'service-http' and 'service-https', but browsing to an HTTPS site times out instead of getting redirected to the Captive Portal page. Resolution SSL Decryption/Forward-Proxy would need to be configured for the URL category in order for Captive Portal to work for HTTPS sites. For more information on how to configure SSL Decryption for the URL category, refer to the following document:  How to Implement SSL Decryption Below is a high-level overview of the Captive Portal operation for both HTTP and HTTPS: HTTP Client sends SYN, Palo Alto Networks firewall permits it Server sends SYN/ACK, firewall permits it Client sends ACK, firewall permits it Client sends HTTP GET, firewall injects a 302 redirect to Captive Portal HTTPS without decryption Client sends SYN, firewall permits it Server sends SYN/ACK, firewall permits it Client sends ACK, firewall permits it Client sends Client Hello to start HTTPS session. Firewall injects a RST because the user is unknown. This would be seen on CLI as a DISCARD session and client's browser would timeout at this point. HTTPS with decryption Same as above Same as above Same as above Client sends Client Hello to start HTTPS session The firewall responds with a Server Hello (Proxy) When the HTTPS session has been established, the firewall will see the encrypted HTTP GET message and then we can inject the appropriate 302 redirect message Inbound HTTPS Captive Portal: For inbound HTTPS sessions, the decryption would still need to be Forward-Proxy to trigger Captive Portal, not Inbound-Inspection. Inbound Inspection is a transparent decryption that the firewall does check the embedded data in an encrypted packet, to make sure the server does not surfer any vulnerabilities after the payload is delivered. The firewall should only open up the packet, scan for virus/vulnerability/spyware and forward the packet to the server untouched if there are no threats detected. In this mode, the firewall should not modify the packet in any way. In the case of the forward-proxy, however, the firewall acts as a man-in-the-middle, where it is an active participant in the SSL connection. When the user (on the internet) initiates a connection to the server (on the internal network), the firewall in forward-proxy mode, can inject the appropriate 302 Temporarily moved HTTP response to the internet-user, causing the user to be redirected to the Captive Portal interface/page. For more information about the differences between the Forward-proxy and Inbound Inspection, review the following document: Difference Between SSL Forward-Proxy and Inbound Inspection Decryption Mode See Also Troubleshooting Captive Portal Redirect Page Issues Using Captive Portal with HTTP/HTTPS Proxy owner: tasonibare
View full article
tasonibare ‎07-02-2014 12:05 PM
16,154 Views
3 Replies
Palo Alto Networks does not support Two-Factor authentication for third party VPN clients (for example, Cisco VPN client). However, it is supported for GlobalProtect clients. owner: rvanderveken
View full article
rvanderveken ‎05-22-2014 06:13 AM
7,526 Views
3 Replies
Overview The Palo Alto Networks device has a built-in device reader role that has only read rights to the firewall. The superreader role gives administrators read-only access to the current device. This document describe how to configure the superreader role for RADIUS servers running on Microsoft Windows 2008 and Cisco ACS 5.2. The principle is the same for any predefined or custom role on the Palo Alto Networks device. Roles are configured on the Palo Alto Networks device using Radius Vendor Specific Attributes (VSA). Note: The RADIUS servers need to be up and running prior to following the steps in this document. Steps Windows Server 2008 Radius On the Palo Alto Networks device, go to Device > Server Profile > RADIUS and configure the RADIUS Server Profile using the IP address, port, and the shared secret for the RADIUS server. Go to Device > Authentication Profile and create an Authentication Profile using RADIUS Server Profile. Go to Device > Setup > Authentication Settings and choose the RADIUS Authentication Profile that was created in Step 1 (shown above): On the Windows Server, add the firewall as a client. Under NPS > RADIUS Clients and Servers > RADIUS Clients, create the client profile using the IP address of the firewall and a shared secret that will be used for the firewall: On the Windows Server, configure the Palo Alto Networks RADIUS VSA settings. Under NPS > Polices > Network Policies, create a specific policy that will be used by the firewall: Add the Vendor-Specific Attributes for the Palo Alto Networks firewall. Use 25461 as a Vendor code. In Configure Attribute, configure the “superreader” value that will give only read-only access to the users that are assigned to the group of users that will have that role: The setup should look similar to the following: On the Windows Server, configure the group of domain users to which will have the read-only admin role.  Under NPS > Polices > Network Policies, select the appropriate group in the Conditions tab of the policy: Test the login with the user that is part of the group After login, the user should have the read-only access to the firewall. No changes are allowed for this user (every window should be read-only and every action should be greyed out), as shown below: The connection can be verified in the audit logs on the firewall. The role that is given to the logged in user should be "superreader" If any problems with logging are detected, search for errors in the “authd.log” on the firewall by using the following command: > tail follow yes mp-log authd.log Cisco ACS 5.2 Follow Steps 1, 2 and 3 of the Windows 2008 configuration above, using the appropriate settings for the ACS server (IP address, port and shared secret). On the ACS, under RADIUS VSA create the PaloAlto VSA using the Vendor ID: 25461. After that, select the Palo Alto VSA and create the RADIUS Dictionaries using the Attributes and the IDs. Keep in mind that all the dictionaries have been created, but only the PaloAlto-Admin-Role (with the ID=1) is used to assign the read-only value to the admin account. Under Users on the Users and Identity Stores section of the GUI, create the user that will be used to login to the firewall. Under Policy Elements, create an Authorization Profile for the “superreader” role which will use the PaloAlto-Admin-Role Dictionary. In the Authorization part, under Access Policies, create a rule that will allow the access to the firewall’s IP address using the Permit read access PA Authorization Profile that was have created before. Test the login with the user that is part of the group. After login, the user should have the read-only access to the firewall. No changes are allowed for this user. The connection can be verified in the audit logs on the firewall. If any problems with logging are detected, search for errors in the “authd.log” on the firewall using the following command: > tail follow yes mp-log authd.log See Also Radius Vendor Specific Attributes (VSA) - For configuring admin roles with RADIUS running on Win 2003 or Cisco ACS 4.0. owner: ialeksov
View full article
ialeksov ‎03-05-2014 03:03 PM
31,109 Views
0 Replies
1 Like
Details The key to getting group mappings to work for groups that have users existing in multiple domains is to make sure that the mappings are configured against the root domain, and not a child domain. The reason for this is that even if the group mapping is pointing at a Global Catalog, only the DN strings for the users in a group will be pulled down. Then, a query is executed through LDAP for the sAMAccountName that matches the DN string. This is done because the system needs the usernames in the group to match what it has in the ip-user-mapping database, which is in the form of Domain\Username. Since the DN string won't match this, the second LDAP query provides this information. If this is done with a child domain, the Global Catalog will provide all of the DN strings for users in other domains; however, the sAMAccountName will only return the users that exist in that child domain, because they only exist in that child partition. Even if the root is completely empty, it still has a full 'read-only' partition of all of the users that exist in all of the child domains. Therefore, the best way to do this is to configure a Global Catalog (3268) to the root domain controllers, while also configuring an LDAP (369) for the root domain controllers. Set the 'Server Profile' in the Group Mapping object to use the Global Catalog configured (so all of the groups in all of the domains can be seen). Then, when the sAMAccountName query gets executed, it will happen against the root domain and return all of the users in all of the domains. owner: jhillon
View full article
jhillon ‎02-14-2014 07:51 AM
9,190 Views
5 Replies
4 Likes
Issue By default, LDAP communication from a Palo Alto Networks device occurs through the Management (MGT) interface on the device. In some deployment network environments, the LDAP server may not be reachable from the MGT interface. Note: In some cases, the Palo Alto Networks device is able to pull group mappings even though LDAP authentication fails from the same LDAP server. Details LDAP authentication by default uses the Management interface for authentication and there is no service route configuration option specifically for LDAP. For group mapping information, the Palo Alto Networks device uses the User-ID Agent service route or Management interface by default. Therefore, if the User-ID Agent service route is configured, then it is possible that the group mapping information is successfully retrieved. Resolution Configure a service route for the LDAP server with the source as one of the dataplane interfaces. Navigate to Device > Setup > Services Click on Service Route Configuration Click Select (if not already selected) in the Service Route Configuration dialog Add a new service route The Destination address field should be the LDAP server IP address. The Source address field should be the IP address assigned to the Dataplane interface, which can access the LDAP server.   Note: The address convention in Destination field is host based, ie /32. Defining a subnet (for example, 192.168.1.0/24) should be avoided. Note: Make sure that "Administrator Use Only" is checked in the LDAP Server Profile for use as Authenticating Server PA for Admin Access. owner: akawimandan
View full article
Ameya-Kawimandan ‎01-17-2013 11:58 PM
6,795 Views
1 Reply
Palo Alto Networks firewalls can use the following types of authentication for OSPF: Type0 No Authentication Type1 Plain Text Authentication or Type 1, that uses simple clear-text passwords. Type2 MD5 Authentication or Type 2 that uses MD5 cryptographic passwords. Steps Configure an Authentication profile and choose Simple Password or MD5 password type. Once the profile is definedattach it to one OSPF-enabled interface and commit the changes. For troubleshooting, look at the routed.log file using the CLI command: > tail follow yes mp-log routed.log The following are sample routed.log entries: Fully Adjacent **** AUDIT      0x3e01 - 200  (0000) **** I:00000505 F:00000040 qoamddsc.c 1014 :at 19:34:49, 10 February 2013 (4379890 ms) Database exchange with an adjacent OSPF neighbor has been completed. The adjacency with this neighbor is now fully up. Neighbor router ID                192.168.13.99 Neighbor IP address                192.168.13.99 While testing changing authentication type **** AUDIT      0x3e01 - 91  (0000) **** I:00003ed1 F:00000040 qodmnmi.c 210 :at 21:43:03, 10 February 2013 (5853790 ms) An adjacency with a neighbor has gone down. Resources associated with database exchange for this neighbor will be freed. Neighbor router ID                192.168.12.99 Neighbor IP address                192.168.13.99 OSPF Neighbor No Password while PA side configured for Clear Text Password **** AUDIT      0x3e02 - 39  (0000) **** I:00002c2b F:00000010 qon2auth.c 707 :at 23:09:13, 10 February 2013 (3130980 ms) OSPF 1 Packet received with unexpected authentication type 0. Expected authentication type = 1. Packet data =   45C0004C 0A340000 01590055 C0A80D63 E0000005 0201002C C0A80C63 00000000   517E0000 00000000 00000000 FFFFFF00 000A120A 00000028 C0A80D63 00000000   FFF60003 00010004 00000001 MD5 Authentication while PA side configured for Clear Text Password **** AUDIT      0x3e02 - 39  (0000) **** I:0000330e F:00000010 qon2auth.c 707 :at 23:18:53, 10 February 2013 (3711010 ms) OSPF 1 Packet received with unexpected authentication type 2. Expected authentication type = 1. Packet data =   45C00078 0A820000 0159FFDA C0A80D63 E0000005 02010030 C0A80C63 00000000   00000002 00000010 3C7EE878 FFFFFF00 000A120A 00000028 C0A80D63 C0A80D01   C0A80C01 A22541E7 95E0BFB8 E2911562 EB920B2C 00000009 00010004 00000001   00020014 3C7EE878 011241E5 DD4B6AA7 22E64507 F51E98B5 owner: aciobanu
View full article
aciobanu ‎12-03-2012 03:48 AM
5,902 Views
2 Replies
Access domains can be defined under Device tab > Use the Access Domain page to specify domains for administrator access to the firewall. The access domain is linked to RADIUS vendor-specific attributes (VSAs) and is supported only if a RADIUS server is used for administrator authentication. When an administrator attempts to log in to the firewall, the firewall queries the RADIUS server for the administrator’s access domain. If there is an associated domain on the RADIUS server, it is returned and the administrator is restricted to the defined virtual systems inside the named access domain on the device. If RADIUS is not used, the access domain settings on this page are ignored. Name: Enter a name for the access domain (up to 31 characters). The name is case-sensitive and must be unique. Use only letters, numbers, hyphens, and underscores Vsys: Select virtual systems in the Available column and click Add to select them owner: kalavi
View full article
kalavi ‎10-04-2012 12:52 PM
2,961 Views
0 Replies
This document describes the following configurations : Authentication : RADIUS. LDAP and  LOCAL Authenticate Profile : RADIUS, LDAP and  LOCAL Authentication Sequence : RADIUS, fallback to LDAP, fallback to LOCAL Using the Authentication Sequence for Firewall Administrator and Captive Portal RADIUS Authentication Device > Server-Profile > Radius Configure the fields: Domain name: RADIUS server domain Server: Friendly Name identifying Server IP address: Address of Server Port-1812 (authentication) Local User Authentication Device > Local User Database > Users Create a local user adding a password and enabling the user. LDAP Authentication Device > Server-Profile > LDAP “Base” field represents the point in the LDAP tree where the firewall will connect to and begin the search for users and groups. “Bind DN” field contains the user name credentials that the firewall uses to access the AD/ LDAP  server to be able to pull users and groups SSL is checked by default and needs server port 636, make sure to uncheck SSL if port 389 is used Domain: Needs to be the NETBIOS domain or leave blank and the system will pull the domain info. automatically Authenticate Profile Device > Authenticate Profile Configure Authentication profile for Local, Radius and LDAP authentication by selecting Authentication and Server profiles. Authentication Sequence Device > Authenticate Sequence Snapshot depicts Radius as primary authentication, first fallback as LDAP and second fallback as Local Database. Radius > Fallback to LDAP > Fallback to Local Lockout Time : Number of minutes that a user is locked out if the number of failed attempts is reached (0-60 minutes, default 0). 0 means that the lockout is in effect until it is manually unlocked. Failed Attempts : Number of failed login attempts that are allowed before the account is locked out (1-10, default 0). 0 means that there is no limit. Authentication Sequence for Firewall Administrator Device > Administrators Create Administrator with Authentication Profile = Authentication Sequence profile. Choose Role-Dynamic-SuperUser. Authentication Sequence for Captive-Portal Authentication Device > User Identification > Captive Portal Settings Select Authentication-Sequence as a Authentication Profile. owner: akawimandan
View full article
Ameya-Kawimandan ‎07-23-2012 07:05 PM
15,434 Views
12 Replies
1 Like
Overview This document describes how to configure RADIUS authentication. Note: RADIUS authentication can be used for device administrators, remote VPN or captive portal. Steps Ensure that the RADIUS server in question has been configured with a new client (which is the management IP in use). Go to Device > Server Profiles > RADIUS and add a RADIUS server Go to Device > Authentication Profile and add a RADIUS authentication profile. Apply the RADIUS server profile created in step 1 above. owner: bnitz
View full article
npare ‎05-04-2012 11:10 AM
8,139 Views
0 Replies
Overview: The paloaltonetworks firewall and Panorama have pre-defined administrative roles that can be configured for Radius Vendor Specific Attributes (VSA).   This article explains how to configure these roles for Cisco ACS 4.0 The firewall itself has the following four pre-defined roles, all of which are case sensitive: •   superuser—Full access to the current device. •   superreader (Read Only)—Read-only access to the current device. •   deviceadmin—Full access to a selected device. No access to define new accounts or virtual systems. •   devicereader (Read Only)—Read-only access to a selected device. The Panorama roles are as follows and are also case sensitive: •   superuser—Full access to the current device. •   superreader (Read Only)—Read-only access to the current device. •   panorama-admin—Full access to a selected device, except for defining new accounts or virtual systems. Steps: To allow Cisco ACS users to use the predefined rule configure the following: From Group Setup , choose the group to configure and then Edit Settings . Click the drop down menu and choose the option RADIUS (PaloAlto) . The RADIUS (PaloAlto) Attributes should be displayed.   Check the check box for PaloAlto-Admin-Role .   Enter the appropriate name of the pre-defined admin role for the users in that group. Submit and Restart the service. Log in to the firewall.   Once authenticated to Radius verify that the superuser or pre-defined admin role applied is applied to the access. . owner:  nayubi
View full article
nrice ‎04-01-2012 03:38 PM
23,633 Views
0 Replies
Overview This article provides the steps to configure LDAP for authentication to the Web UI. Steps Create an LDAP Server Profile so the firewall can communicate and query the LDAP tree. Device tab (or Panorama tab if on Panorama) > Click LDAP under Server Profiles > Click Add. Be sure to uncheck SSL, if leaving the port as 389. If the LDAP server is configured to do LDAP over SSL, leave the box checked and change the Server port to 636. Domain – Leave the domain field blank unless the firewall is being installed in a multi-domain environment. Base – Level of the LDAP tree at which the queries will start. Any user from that point and on will be accessible by the PAN. Bind DN – This is the path to a user who has permissions to query the LDAP tree. Create an Authentication Profile using the newly created LDAP server. Device tab (or Panorama tab if on Panorama) > Click Authentication Profile > Click Add. Authentication will be LDAP, choose the server profile created in the previous step, and ensure Login Attribute is “sAMAccountName”. It’s case sensitive. In this example, the allow list enables all users. The list can be limited if desired. Create an Administrator account on the Palo Alto Networks Device. Device tab (or Panorama tab if on Panorama) > Administrators > Click Add. From the Authentication Profile drop-down, choose the LDAP Authentication Profile created in the last step. Ensure the name of the administrator matches the name of the user in the LDAP server. Commit. Log out of the current Web UI session and try the login using the administrator account created wihich is also in the LDAP tree. owner: jseals
View full article
panagent ‎03-26-2012 04:40 PM
37,865 Views
11 Replies
1 Like
Issue: LDAP authentication fails for all users indicating invalid username and password, even though all users are in the allow list. Resolution: Verify the port defined for the LDAP server and whether or not  the SSL checkbox is enabled.   In general, the SSL checkbox should only be used on Port 636.  Some servers will not accept SSL on Port 389. owner:  jwoodburn
View full article
panagent ‎03-17-2012 06:50 PM
2,902 Views
0 Replies
Details Configuring a Kerberos server allows users to authenticate natively to a domain controller. When the Kerberos settings are configured, Kerberos becomes available as an option when defining authentication profiles. Recommendations for configuring Kerberos are provided below: DNS Entries If using Active Directory, it is easiest to use the AD DNS server as the PAN firewall DNS server. DNS entries already exist on this server that are needed for Kerberos authentication. If this option is not possible, make sure the DNS server that the PAN is using has Service Location(SRV) DNS entries for _kerberos._tcp and _kerberos._udp. As an example, if there is an Active Directory server named w2k3.pantac2.org, it will also need service location (SRV) entries for _kerberos._tcp.pantac2.org and _kerberos._udp.pantac2.org. Below is an example from a linux server running the Bind9 DNS server: srvce.prot.name  ttl  class   rr  pri  weight port target      w2k3                 IN      A                    10.30.14.132 _kerberos._tcp        IN      SRV   0  100    88   w2k3 _kerberos._udp       IN      SRV   0  100    88   w2k3 NTP Server The time on both the Palo Alto Network device and the Kerberos server need to be synchronized within 5 minutes of each other. This is a security feature built into Kerberos. Both the device and the AD server should be configured to use a NTP server. Device Configuration Create the Kerberos Server profile. > Device Tab> Server Profiles > Kerberos: Enter the name of the profile. For the user account name user@pantac2.org, the Realm (up to 127 characters) is the FQDN,  “pantac2.org”. Enter the Domain for the user account (up to 63 characters).which in our example is "pantac2". For each server, click add and enter the Server name. Enter the server FQDN under Host, and enter an optional port number for communication with the server. Create an Auth Profile >Device tab > Authentication Profile > New. Select Authentication “Kerberos” and be sure to select the Kerberos server configured. An example is shown below: This Auth Profile can be used for SSL VPN, Captive Portal or Administrator logins. The above Auth profile was configured to allow all authentication requests to reach the AD server. Customizing the Auth Profile is possible by using AD groups to determine which users can send an authentication request to the AD server. owner: rnitz
View full article
nrice ‎03-07-2011 02:36 PM
13,430 Views
2 Replies
1 Like
Overview This document describes the steps to configure admin authentication with a Windows 2008 RADIUS server. The prerequisites for this configuration are: L3 connectivity from the management interface or service route of the device to the RADIUS server. A Windows 2008 server that can validate domain accounts. Steps Part 1: Configuring the Palo Alto Networks Firewall Go to Device > Server Profiles > RADIUS and define a RADIUS server Go to Device > Authentication Profile and define an Authentication Profile Go to Device > Admin Roles and define an Admin Role. In this case one for a vsys, not device wide: Go to Device > Access Domain and define an Access Domain Go to Device > Setup > Management > Authentication Settings and make sure to select the RADIUS Authentication profile created above Go to Device > Administrators and validate that the user needed to be authenticated is not pre-defined on the box. Commit the configuration Part 2: Configuring the Windows 2008 server 1. (NPS Server Role required) Click Start > Administrative Tools > Network Policy Server and open NPS settings Add the Palo Alto Networks device as a RADIUS client Open the RADIUS Clients and Servers section Select RADIUS Clients Right click and select ‘New RADIUS Client’ Note: Only add a name, IP and shared secret. Leave the Vendor name on the standard setting, “RADIUS Standard”. After adding the clients, the list should look like this: Go to Policies and select Connection Request Policies. Make sure a policy for authenticating the users through Windows is configured/checked. Validate the Overview tab and make sure the Policy is enabled: Verify the Conditions tab Check the Settings tab where it is defined how the user is authenticated. Open the “Network Policies” section. Right-click on Network Policies and add a new policy. Give the policy a name Go to the Conditions tab and select which users can be authenticated (best by group designation): Go to the Constraints tab and make sure to enable “Unencrypted authentication (PAP, SPAP)" Go to the Settings tab and configure the VSAs (Vendor Specific Attributes) to be returned to map the user to the right Admin Role and Access Domain) Select Vendor Specific under the RADIUS Attributes section Click “Add” in the pane to the right Select “Custom” from the Vendor drop down list The only option left in the Attributes list now is “Vendor-Specific” Click Add. The Attribute Information window will be shown. Click Add on the left side to bring up the Vendor-Specific Attribute Information window Define the VSAs Select “Enter Vendor Code” and enter “25461”. Make the selection “Yes. It conforms”, stipulating that the attribute conforms to the RADIUS RFC specifications for vendor specific attributes. Click “Configure Attribute…” The Admin Role is Vendor-assigned attribute number “1”. The Attribute format is “String” The Attribute value is the Admin Role name, in this example, “SE-Admin-Access”. Click OK. Click Add to configure a second attribute (if needed). Attribute number “2” is the Access Domain. The user needs to be configured in User-Group 5 Note: The group can be used in a policy by typing/adding it manually in the appropriate rule. Different access/authorization options will be available by not only using “known” users (for general access), but the RADIUS returned group for more “secured” resources/rules. The list of attributes should look like this: Click “OK” until all options are saved. Optionally, right-click on the existing policy and select a desired action. Part 3: Validate the setup On the firewall Try a wrong password to see this System Log entry on the Palo Alto Networks firewall: Monitor > Logs > System With the right password, the login succeeds and lists these log entries: Check the access rights: On the NPS side From the Event Viewer (Start > Administrative Tools > Event Viewer), look for: 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.” Select the Security log listed in the Windows Logs section Look for Task Category and the entry “Network Policy Server” See Also See the following for configuring similar setups: RADIUS VSA dictionary file for Cisco ACS - PaloAltoVSA.ini RADIUS Dictionary File owner: srommens
View full article
nrice ‎12-27-2010 11:32 AM
29,458 Views
1 Reply
2 Likes
Overview A key feature of the Palo Alto Networks firewall is mapping usernames to IP addresses. Once the Palo Alto Networks firewall knows the names associated with IP addresses, the firewall can: Log this information Control traffic based upon a particular username or group The firewall uses two methods to perform username-to-IP address mapping, transparent and interactive authentication. This document discusses configuring transparent authentication via an eDirectory server, and interactive authentication via an LDAP server. The discussion is in two parts: Transparently Obtaining User Authentication Information from eDirectory Using the LDAP server for authentication with captive portal, SSL VPN, or firewall GUI access Before starting setup, we recommend having a local LDAP browser to verify the settings for the User-ID agent and the Palo Alto Networks firewall. Examples in this document are using JXplorer, a free, cross-platform LDAP browser downloadable here: http://jxplorer.org/ . Details The Palo Alto Networks firewall uses two methods to map usernames to IP addresses: Transparent authentication: The firewall can automatically retrieve username and IP mappings from Active Directory domain controllers, using the Active Directory User-ID agent.  In this case, the user previously logged into the domain, and so is not prompted for credentials by the firewall. Interactive authentication: The firewall can prompt for username, then authenticate via RADIUS or a local user database. This would apply if fusers are: Running Mac or Linux clients (called Captive Portal). Connecting to the firewall over our SSL VPN. Trying to log into the firewall GUI as an administrator. The above methods are extended to include: Transparent authentication: The firewall can automatically retrieve username and IP mappings from Active Directory domain controllers (using the Active Directory User-ID agent) or from eDirectory servers (using the new eDirectory User-ID agent).  Note: The new User-ID agent is compatible with only eDirectory 8.8 due to the unique login information eDirectory tracks. Interactive authentication: The firewall can prompt for username, then authenticate the user via RADIUS, a local user database, or an LDAP server. Transparently Obtaining User Authentication Information from eDirectory Novell’s eDirectory is a directory service that fully supports LDAP queries. With eDirectory, when a user authenticates, the source IP address and login time are stored in the directory in the fields: networkAddress (in a proprietary binary format) and loginTime. The new User-ID agent can specifically read this information and transparently map users to their IP addresses. LDAP support in PAN-OS queries the directory, builds lists of groups for policies, and maps users to groups. Because of this, part of the process of implementing eDirectory support is configuring LDAP information on the Palo Alto Networks device. Installing and Configuring the User-ID Agent Make sure to run Novell eDirectory 8.8 or later.  The User-ID Agent uses some LDAP functions that are not available in previous versions of eDirectory. Install the new User-ID agent.  Log into the support account at: https://support.paloaltonetworks.com.  Go to Software Updates, then User Identification Agent section and look for a version that ends in “-LDAP.” Download this .msi file to the Windows server where the agent will run. Install the .msi file while logged in as an administrator. It will run as a local service under the local system account. The service name is User ID Agent, as shown here in the Services management console. After installed, launch the User-ID Agent and select Configure to display the following: Device Listening Port: Use the default. This port number is for communications between this agent and the PA firewall.  Remember this port number when configuring the Palo Alto Networks firewall. Enable the Network Address Allow/Ignore list.  Add the networks you want to monitor for User IDs.  For terminal servers or other multi-user machines, add those IP addresses to the Ignore list, as we need to use the Terminal Services Agent to track users on those systems. Configure eDirectory settings. Select the eDirectory menu item on the left to display the following: Complete the following: Click OK and expand the root objects to determine the base DN.  Also, select Table Editor view to see the actual object type. In this example, the base is o=lab. Server Enter the IP address of the eDirectory server to be monitored and click Add. To monitor multiple servers, click the Copy Setting option to configure the settings at the bottom of the screen for each server. You may need to enter information for multiple eDirectory servers. If the directory is partitioned among servers, make sure each partition has a server configured. Also, depending on how quickly information is synchronized between servers, you may want to add additional servers to ensure that user/ip mappings show up more quickly. Search Base is the base DN (or root) of the directory where the agent looks for users. In a large deployment, you can scope how much of the directory is searched by setting the search base appropriately. In eDirectory, this is typically in the form of o=. Using JXplorer, you can connect to eDirectory anonymously and specify only the IP address and the default non-SSL port, as shown below. Bind Distinguished Name and Password is the fully distinguished name (FQDN) of the user you will use to query eDirectory. This account does not need any special privileges.E nter the password for this account. You should be able to browse to this anonymously as we did to get the BaseDN. Remember that the fully distinguished name is built from using the entire hierarchy. In our example, that would be cn=Admin, o=lab. Server Domain Prefix (optional) is pre-pended to the user name and can be useful if you are using multiple authentication sources. In our example, users show up in the traffic logs as:  mynds\username. Search Interval The default of 30 seconds should be fine but this can be adjusted. After the first query to build the list of all currently logged in users, subsequent queries search only for user entries modified since the last query. No other fields need to be modified as they are set to specifically work with eDirectory.  Keep the bind port at 636, with SSL enabled, as eDirectory does not allow authenticated LDAP queries to be sent in the clear. After entering the required information, click Commit to save the changes. View the agent logs to see what is happening with the agent. Go to File > Show Logs to open a .txt file. Note: If agent logs need to be modified, use an LDAP browser to determine what to set the fields to: Scroll to the bottom of the text file to view the latest debug output from the agent. Examine the output under the header labeled "Service is being started." Shown below is an example of the log file: See the message "connect succeeds on server x.x.x.x," as highlighted above. If you do not see that message, you'll need to troubleshoot. Helpful Troubleshooting Tips Error 81 in the log, make sure that the bind port/SSL setting is configured as needed. Error 93 in the log may indicate a communication error.  You may be running the wrong version of eDirectory, or the base DN is not correct. To increase the amount of information logged, go to the File > Debug menu to set the level to be more detailed (default level is info), then restart the service (File > Restart Service). Note:   This text file is not updated dynamically, so you have to close it, then use the menu to view new information. T o verify the configuration, select the Monitor icon to view user-to-IP mappings. The number of mappings increases as the agent reads more information from the LDAP server. When you see a list of users on this screen, you've configured the agent properly. Now move on to configuring the firewall to talk to this agent. Configuring the Firewall to Talk to the User-ID Agent From the Web UI, select Device, then select User Identification from the list on the left. Under the  User Identification Agent section, click Add. Set the Agent Type as user-id-agent, name it, and fill in the IP address and port you configured the agent to listen on (default port is 5007). Enable User Identification on the appropriate zone. Choose Network, select Zones from the list on the left, then select the zone where user traffic originates. At the bottom of the screen, check Enable User Identification. Commit changes. To confirm that the firewall is communicating with the agent, run the following command: >  show user userid-agent statistics To confirm that the user database was obtained from the agent, run the following command: > show user ip-user-mapping The User-IDs display under the Monitor > Traffic log in the source-user and target-user columns. Now that the basic User-ID is working, create an LDAP Server Profile to use later for the User Identification LDAP server setup. From Device, under Server Profiles, select LDAP, then click New. Fill in the same information you used when setting up the User Agent. Make sure SSL is enabled and the port is set to 636. eDirectory does not allow passwords to be sent in the clear. Define the LDAP Server to Retrieve Group Information For the final step, define the LDAP server to retrieve the group information. Under Device, select the User Identification icon. Choose Add, give the server a name, and select the Server Profile just created. Create a group or user profile, if desired. A user profile limits the users and groups that the firewall learns about for use in the policy. For eDirectory, we do not need to complete any other fields. The firewall will be retrieving object class cn=group. Commit the changes. The group information is now being retrieved from the directory. It may take a while to populate the group and user information. To confirm that the firewall is communicating with the LDAP server, and that group information was retrieved: > show user ldap-server server EDirectory Once the group and user information is retrieved, then that information can be used in policy. To confirm, go to the Policies tab, click in the source-user column, and in the screen that appears, groups should appear. Using the LDAP Server for Authentication with Captive Portal, SSL VPN, or Firewall GUI Access For situations where we need to actually challenge users for a username and password, we can now use LDAP.  There are three basic steps involved: Add an LDAP server under Server Profiles Add an LDAP server under the User Identification section Create an Authentication profile using the defined LDAP server In the following example, we will connect to Active Directory using LDAP. Under Device, select the LDAP option under Server Profiles. Click New to add the server. As in our previous example, fill in all the necessary information. Unfortunately we cannot find the Base using the method we did for eDirectory. However if you go into Active Directory’s Users and Computers you can see the base of the directory. In the example below, the base would be dc=swartz,dc=local To find Bind DN, search for the user while still in Users and Computers, then get results from the View menu. Select Choose Columns. Add the X500 distinguished name. The results should look like: With this information, we can now finish the configuration. Note: In this example, we are setting it up without SSL encryption over port 389. The Active Directory does not require encryption and is not available by default. To enable SSL for LDAP in Active Directory, the following URL can prove helpful: http://www.linuxmail.info/enable-ldap-ssl-active-directory/. Add the LDAP server in the User Identification section. There are a few differences. For Active Directory, specify how to determine group and user objects. For Active Directory, you can set the fields as follows: sAMAccountName corresponds to a user login name in Active Directory. Notice the group filter:  description=AccessGroup. This limits the number of groups and users that the firewall learns about and are available for use in creating policies. In the following example, the description fields on the groups are set.  Shown below is a before and after look at the effect of this setting in this scenario--changes were committed before and after adding this setting. The User filter can restrict users that you will learn about. These filters control only the groups you see or users you can search for when setting an Allow List in an Authentication Profile or when setting a source user or group in policy. Note: Domain Users is a special group in Active Directory that users are tied to it as part of the user schema with the attribute primaryGoupID.  Members cannot be enumerated through an LDAP query, as the member attribute is not set for this group, so it cannot be used to learn all of the usernames. To learn more about building LDAP queries, refer to the following sites: http://www.rfc-editor.org/rfc/rfc2254.txt http://www.zytrax.com/books/ldap/apa/search.html Groups:  Name=CN, Objects:=group, Members=member Users:  Name=sAMAccountName, Objects=person The final step is to create an Authentication Profile using the LDAP server. From Device, select the Authentication Profile icon and choose New. Give the profile a name, set Authentication to LDAP, select the Server Profile created, and set the login attribute. This maps the name entered by the user to an LDAP attribute. For AD, use sAMAccountName. Edit the Allow List to specify the groups and users that can use this method of authentication.  Note: Specify each user that will be assigned administrative access: This profile is now ready for administrative access, Captive Portal, or SSL VPN access as previously set for RADIUS or a Local User Database. Shown below is a screenshot of an SSL VPN profile using LDAP: One advantage of using LDAP for authentication is that for most organizations already have a directory service that supports LDAP, so nothing needs to be installed or configured.  Since we allow the user to define how to determine both groups and users, it should work with almost any LDAP compatible directory. More Information Overview of the Lightweight Directory Access Protocol Lightweight Directory Access Protocol (LDAP) is an open standard for providing directory services through IP networks.  LDAP is based upon X.500, the OSI Directory Access Protocol, and was first described in RFC1487.  The most recent version (version 3) is described in RFC2251. There are two main components to an LDAP database that we must understand in order to use it for authentication, its structure and its contents. LDAP is a hierarchical database structure that lends itself to defining organizations and their structures. It is incredibly flexible is design, because of this each organization’s LDAP structure will differ. The contents of the directory are defined in its schema, which is highly extensible. Users can modify the database design to meet their needs. The directory schema defines the possible database objects and attributes they can possess. When viewing a directory, it is common to view it as a collection of container objects (organizations, organizational units) and leaf objects (people, computers). RFC 2377 defines the basic schema for directory-enabled applications. Following is a list of some of the ones that are important to us: rdn: Relative distinguished name is the name of an object without reference to its place within the tree. It is often based upon the object’s common name. dn: Distinguished Name is the name that defines an object by indicating its location within the directory hierarchy. It is created by concatenating the relative distinguished names of the object and each of its ancestors up to the root of the directory partition. This name is unique across the entire directory base DN: Each directory is required to provide basic directory specific information so that clients can access them. One of these attributes is the list of base distinguished names (DN) that you can access on this server. Typically the base DN will be the various domain components of the directory. cn: Common Name is typically used to reference objects, as it is an attribute that all leaf objects possess.The common name need only be unique within its own container (so it is possible to have two objects with the cn of Bob as long as they are in separate containers. This attribute can contain the users login name. oOrganization is many times the root of a directory. Below the organization will be the various organizational units, groups, and members. eDirectory uses this as the base of its structure. ou: Organizational Unit is used to help define the structure of the organization. A directory can be comprised of multiple organizational units on any level of the tree. dc: Domain Component defines the top level portions of the directory and is based upon the organization’s DNS domain name. Active Directory uses this format. member: Attribute of a group object that contains all of the members of a group. The firewall uses this attribute to determine if a user is in a static group. LDAP Browsers Softerra LDAP Administrator is an excellent LDAP tool for Windows, which can be found at: >http://www.ldapadministrator.com/>.  Note: After initial free trial, purchasing this application for further use will be required. JXplorer is a free Java based browser that works on Windows, Mac and Linux.  It can be found at: http://jxplorer.org/. LdapBrowser by IIT Engineering is another free java based browser that can be found here: http://www.brothersoft.com/ldap-browser-14779.html owner: bswartzw
View full article
nrice ‎05-07-2010 08:21 PM
29,756 Views
6 Replies
1 Like
Overview The Following queries can be used to identify the version of eDirectory you are using and whether the version supports paging, which is required for the LDAP User ID Agent. An ldap search tool is required to run the commands, which is usually included on a linux or MAC system install. To view ldap controls and eDirectory version (replace host with the eDirectory server's IP address or name): ldapsearch –h host –b “” –s base –x To view operation attributes regarding a specific user ldapsearch –h host –D binddn –w password –x “cn=admin” + Replace the following terms in the above query accordingly: "host" with the eDirectory server IP or name. "binddn" with the bind dn account (cn=admin,ou=dept1,o=company1 for example) "Password" is the bind dn password "cn=admin" is the searched user, which can be replaced with any user in the eDirectory, ie "cn=John". owner: panagent
View full article
nrice ‎04-12-2010 03:46 PM
2,809 Views
0 Replies
Ask Questions Get Answers Join the Live Community