Palo Alto Networks - Google Authenticator and OpenOTP

I have been asked about how multi-factor authentication (MFA) with with Palo Alto Networks and GlobalProtect, so I thought I would put this tutorial together. GlobalProtect leverages VPN technology to safely enable applications, users, and content for remotely connected devices. Leveraging MFA for remote access provides an added authentication mechanism so that a user not only has know their password, but also possess a one time password or token. There are multiple MFA solutions out there, but for testing purposes I thought I would show how to use Google Authenticator and OpenOTP.

Install the OTP Server:

1. Download the appropriate virtual appliance from: https://www.rcdevs.com/downloads/VMWare+Appliances/. In my case, I am going to run the VM in VMware Player, so I downloaded the OVF. The user credentials for the VM by default are as follows:
1. SSH/console: root / password
2. Web: admin / password
2. Upon boot up, enter the following information (mydomain.com should be replaced with your actual domain):
1. Enter an FQDN of “otp.mydomain.com”
2. Enter an ORG name of "mydomain.com"
3. Enter "Y"
4. Enter "Y"
5. Enter "Y"
6. Press any key to continue
7. Press any key to finish
3. Log into the server via console and use "ifconfig" to locate or set the IP address.
4. Update /opt/webadm/conf/servers.xml with the details of your AD server.
1. ldap server name="servername"
2. host="ipaddress"
5. Save and quit
6. Update /opt/webadm/conf/webadm.conf with administrator account info for your AD server (you could always create a service account in AD for this function).
1. proxy_user "cn=Administrator,cn=Users,dc=mydomain,dc=com"
2. proxy_password "mypassword"
7. Comment out the following lines and add the following below it:
1. #super_admins "cn=admin,o=root", \
2. #                       "cn=super_admins,dc=WebADM"
3. super_admins "cn=Administrator,cn=Users,dc=mydomain,dc=com
8. In the "adminroles_container" section of the file comment the lines out as follows:
1. # Find below the LDAP containers required by WebADM.
2. # Change the container's DN to fit your ldap tree base.
3. # WebADM AdminRoles container
4. # adminroles_container "dc=AdminRoles,dc=WebADM"
5. # WebADM Optionsets container
6. # optionsets_container  "dc=OptionSets,dc=WebADM"
7. # WebApp configurations container
8. # webapps_container "dc=WebApps,dc=WebADM"
9. # WebSrv configurations container
10. # websrvs_container "dc=WebSrvs,dc=WebADM"
11. # Mount points container
12. # mountpoints_container "dc=MountPoints,dc=WebADM"
13. # Domain and Trusts container
14. # domains_container "dc=Domains,dc=WebADM"
15. # Clients container
16. # clients_container "dc=Clients,dc=WebADM"
9. In the "MS AD Settings" section of the file, make the following changes:
1. # With MS Active Directory use the following settings instead of the previous ones
2. # Note: Replace dc=mydomain,dc=com with your AD domain DN
3. adminroles_container  "cn=AdminRoles,cn=WebADM,dc=mydomain,dc=com"
4. optionsets_container  "cn=OptionSets,cn=WebADM,dc=mydomain,dc=com"
5. webapps_container "cn=WebApps,cn=WebADM,dc=mydomain,dc=com"
6. websrvs_container "cn=WebSrvs,cn=WebADM,dc=mydomain,dc=com"
7. mountpoints_container "cn=Mountpoints,cn=WebADM,dc=mydomain,dc=com"
8. domains_container "cn=Domains,cn=WebADM,dc=mydomain,dc=com"
9. clients_container "cn=Clients,cn=WebADM,dc=mydomain,dc=com"
10. Update the time zone, where applicable
11. Save a quit
12. Restart the server ("reboot")
13. Login via the browser ("https://<ipaddress>")
1. User / DN: cn=Administrator,cn=Users,dc=mydomain,dc=com
2. Password: mypassword
14. Select "Setup LDAP Schema"
15. Select "Extend Schema"
16. Select "OK"
17. Scroll down and select "Create Default Containers and Objects"
18. Select "OK"
19. Logout and then login again using your AD account
1. Administrator
2. mypassword
20. Select the "Admin" tab
21. Select "Local Domains"
22. Select the CN=Default hyperlink
23. Change the object name from default to "mydomain"
24. Select "Rename"
25. Select the "Applications" tab
26. Under "Web Services -> MFA Authentication Server" select "Register"
27. Select a user account on the left-hand side
28. Select "Activate"
29. Select "Extend Object"
30. Under "Application Actions" select "MFA Authentication Server"
31. Select "Register / Unregister OTP Tokens"
32. Select "I use a QRCode-based Authenticator (Event-based)" and wait for the screen to refresh and display a QR Code.
33. Download a QR reader and Google Authenticator to your mobile device.
34. Use the QR reader to scan the QR code on the screen.
35. After the QR code has been scanned successfully, click "Register"
36. Select "OK"
37. Navigate to the "Applications" tab and select "Configure" under "Web Services -> MFA Authentication Server"
38. Scroll down and select "Apply"

Test the OTP User:

1.  Select the same user on the left-hand side that you previously assigned a token
2.  Under "Application Actions" select "MFA Authentication Server"
3.  Select "Test User Login"
4.  Enter your AD password under "LDAP Password" and select "Start"
5.  Launch Google Authenticator and refresh the token
6.  Enter the token in the "OTP Password" field
7.  Select "Continue"
8.  Click "OK" once successful
1.  If you are unsuccessful, go back and review the configuration steps above

Configure GlobalProtect to Use MFA:

*** The steps below assume that you already have a working GlobalProtect Configuration that leverages an LDAP profile for user authentication. If you are just getting started with GlobalProtect, see this post. ***

1.  In the firewall, navigate to "Device -> Server Profiles -> RADIUS" and select "Add"
1.  Name - OTP
2.  Under Server
1.  Click Add
2.  Name - OTP-Server
3.  Authentication Protocol - PAP
4.  RADIUS Server - "IP Address of your OTP server"
5.  Secret - testing123
6.  Confirm secret - testing123
7.  Port - 1812
3. Select "OK"
2. Navigate to "Device -> Authentication profile" and select "Add"
1.  Name - OTP
2.  Under the "Authentication" tab
1.  Type - RADIUS
2.  Server Profile - OTP
3.  User Domain - "mydomain"
3.  Under Advanced Tab
1.  Select "Add"
2.  Include All
3.  Select "OK"
3.  Navigate to "Network -> GlobalProtect -> Gateways" and edit your gateway
1. Make sure your OTP Authentication profile is selected and not your LDAP profile
2. Select "OK"
4.  Commit 

Test MFA from the Palo Alto Networks CLI

1.  Enter "test authentication authentication-profile OTP username <username> password" from operational mode
2. You should see the following output:
1. "Got challenge response, which is regarded as failed auth since "test auth ..." CLI command does not support it. User "<username>" is replied with msg "Enter your TOKEN password"

Test MFA from the user's smart phone with Google Authenticator

1.  Open Google Authenticator and generate a pin
2.  Open GlobalProtect, enter your username and password, and select "Connect"
3.  You will then be prompted to enter your pin and will be connected

Palo Alto Networks - NAT Issue

I ran into a NAT situation recently that I thought I would share. Here is the scenario:

Firewall Untrust IP: 1.1.1.1/24
Firewall Trust IP: 10.10.10.1/24
Web Server Public IP: 2.2.2.2/32
Web Server Private IP: 10.10.10.10/32

The web server should be publicly accessible. Here are the typical steps to make that happen:

• Create the NAT policy

• Create the security policies

• Commit the configuration

Even though the NAT and security policies are correct, you will notice that the web server is still not publicly accessible and it cannot access the Internet. You will also notice that if you look in the traffic logs it does not show any traffic. This is because the public IP assigned to the web server in not on a subnet that is assigned to an interface in the Untrust zone. In other words, the firewall doesn't know where to send traffic because the web server's public IP is not in the route table.

There are three options:

1. Create loopback interface with an IP of the web server public IP and assign it to the Untrust zone.
2. Create a sub-interface on the Untrust interface with the web server public IP and assign it to the Untrust zone.
3. Create a route using the IP of the web server public IP as the destination, with the interface assigned to the Untrust zone, and give it a next hop of none.

This forces the IP to show up in the route table and traffic will begin to route properly.

Palo Alto Networks - Ruckus User-ID Integration

Palo Alto Networks firewalls are built on three core technologies: App-ID, User-ID, and Content-ID. User-ID specifically, accomplishes two objectives:

1. The mapping of IP addresses to actual user account information. This is imperative for troubleshooting and/or analyzing logged data, as IP address assignments change over time.
2. The usage of user/group information within a security policy. This allows administrators to get very granular with how they enforce corporate security posture.

In most Palo Alto Networks firewall deployments, I see User-ID configured via an agent that ties into Active Directory. However, this is typically where the integration stops. It is imperative that as much user information as possible is ingested by the firewall so that logs and security policy remain consistent. User-ID provides other mechanisms by which we can tie into user account information (i.e. syslog, API, etc.). After all, active directory is only one of those ways. Specific to Ruckus Wireless, the integration happens via syslog. As users authenticate via 802.1X or captive portal with their credentials, this information is logged in the controller. We just need to share it with the firewall.

On the Ruckus controller(s):

1. Enable the Client Association option in the Debug Logs. This will allow ZoneDirector to log the client associations containing client login information and IP.
2. Enable syslog forwarding in ZoneDirector to the firewall's MGT IP or User-ID agent IP. 

On the Palo Alto Networks firewall:

1. Enable the MGT interface to receive syslog under Device -> Setup -> Management -> Management Interface Settings.
   
2. Navigate to Device -> User Identification -> User Mapping -> Palo Alto Networks User ID Agent Setup -> Syslog Filters -> Add.
3. Create a filter to recognize the syslog messages sent from ZoneDirector. 
1. Name: Ruckus Wireless
2. Type: Regex Identifier 
3. Event Regex: operation=(update|add){1} 
4. Username Regex: sta_name (?:=.*\\|=)([a-z]+);
5. Address Regex: sta_ip=(10\.[0-9]+\.[0-9]+\.[0-9]+); ## change this to reflect your IP range
   
4. Navigate to Device -> User Identification -> Server Monitoring -> Add
1. Name: Ruckus Wireless
2. Type: Syslog Sender
3. Network Address: (IP of ZoneDirector)
4. Filter: Ruckus Wireless
   
5. Commit