Difference between revisions of "Paloalto firewall AD integration"
(Created page with "Home > Enterprise security devices or applications > Paloalto firewall > AD integration To integrate palo-alto firewall with AD use following steps: # Finding base DN of AD and also DN of authenticating service user ## Login into system connected to AD and open "Active Directory Users and Computers". ## Enable View -> "Advanced Features". Without this we cannot see LDAP attributed such as DN required for integr...") |
m |
||
Line 115: | Line 115: | ||
# Add a new gateway with desired name | # Add a new gateway with desired name | ||
# Select the public IP interface on which VPN gateway will listen | # Select the public IP interface on which VPN gateway will listen | ||
#: '''Ideally setup Global protect on loopback and forward (DNAT) public IP ports to loopback ports 443 (for VPN) / 8443 (for admin UI)'''. This plays better when we need active/active VPN from two ISPs or when we need to change VPN port from 443 to something else. | |||
# In "Authentication tab" under "Client Authentication" click "Add" | # In "Authentication tab" under "Client Authentication" click "Add" | ||
## Give any desired name for Client authentication | ## Give any desired name for Client authentication | ||
Line 138: | Line 139: | ||
#: Optionally traceroute to some Internet machine and validate that Internet traffic is going directly and not over VPN due to split tunnel configuration | #: Optionally traceroute to some Internet machine and validate that Internet traffic is going directly and not over VPN due to split tunnel configuration | ||
=Troubleshoot GP VPN issues= | |||
Ensure following while deploying VPN (Global protect) to avoid VPN issues: | |||
* If the VPN is via one ISP, then we should not have Policy based forwarding (PBF) for VPN client IP destination through another ISP. If there is PBF for another ISP, we must add negative (!) destination towards VPN client IP pool in that rule to ensure that PBF is not applied for VPN clients. | |||
* There should not be any existing DNAT on port 443 for the configured ISP public IP. Ideally as mentioned preferably use a loopback IP / interface for setting up Global Protect gateway and portal. This plays better when we need active/active VPN across multiple ISPs or if we need to change VPN port from default 443. | |||
* If there is common ISP between VPN client location and VPN server location with large subnet eg /19 then that might also cause problems in connecting to VPN. In one case we had VPN configured on a ISP (Say ISP1 for a customer). That customer also had another ISP - ISP2 with /19 subnet. Then we were trying to connect to VPN from a office with similar ISP2 connection with similar /19 subnet. Unfortunately while forward packets to VPN server were going from ISP2 at office to ISP1 at client location, since the client also had ISP2, the reply packets for us were being returned via ISP2 of customer (as we had a common /19 interface). | |||
* No VPN or Global protect license is required when users connect to PA firewall from Windows. There is no need of corresponding license to be shown under Device -> Licenses for VPN to work. | |||
[[Main_Page|Home]] > [[Enterprise security devices or applications]] > [[Paloalto firewall]] > [[Paloalto firewall AD integration|AD integration]] | [[Main_Page|Home]] > [[Enterprise security devices or applications]] > [[Paloalto firewall]] > [[Paloalto firewall AD integration|AD integration]] |
Latest revision as of 04:20, 15 October 2023
Home > Enterprise security devices or applications > Paloalto firewall > AD integration
To integrate palo-alto firewall with AD use following steps:
- Finding base DN of AD and also DN of authenticating service user
- Login into system connected to AD and open "Active Directory Users and Computers".
- Enable View -> "Advanced Features". Without this we cannot see LDAP attributed such as DN required for integration
- Other option is to use https://learn.microsoft.com/en-us/sysinternals/downloads/adexplorer to get base DN and DN for authenticating user
- Right click on the parent domain and choose "Properties"
- In "General" tab note the "Domain Name (pre-Windows 2000)". This DomainName value would be required during integration configuration in future steps. Eg Example
- Go to "Attribute Editor" tab
- Look for value against distinguishedName (DN). This is the base DN for the current AD server
- Create a normal service user whose password never expires (with strong long complex password) to integrate firewall with AD, if not created already
- Right click on the user and choose "Properties". Go to "Attribute Editor" tab and look for value of distinguishedName (DN) for the user. (This is optional. We can also just use AD username while integrating instead of specifying full DN for user).
- Configure LDAP server profile using:
- Login into Paloalto firewall
- Go to "Device" -> "Server profle" -> "LDAP"
- Add a new LDAP server with desired profile name
- In server list add the server with IP or FQDN. Port can be 389 (Default) unless LDAPS has been enabled on the AD server.
- See Setup AD to respond to LDAP queries over LDAPS protocol if you need connectivity to AD over LDAPS
- In Server Settings use:
- Type
- Active Directory
- Base DN
- As noted in previous steps. Example dc=example,dc=com for example.com AD server
- Bind DN
- Bind DN of service user as noted in previous steps. For example "CN=paloalto,CN=Users,DC=example,DC=com"
- Password
- Password of the Bind DN user.
- Click "ok" to add LDAP server profile
- Configure Group mapping for the LDAP server
- Login into Paloalto firewall
- Go to Device -> "User identification"
- Go to "Group Mapping Settings" tab
- Create a new "LDAP User mapping" with desired name
- For "Server Profile" select the LDAP server profile created in previous step
- Under "Domain setting" -> "User Domain" mention the domain name noted earlier. Eg Example
- Leave "Group Objects" Object Class to group and "User Objects" Object Class to person (Their default values).
- Ensure Enabled at bottom is selected
- Click ok.
- Commit
- After commit come again open the "Group Mapping Settings" created.
- Go to "Group Include List" tab.
- Select the AD groups that might be useful while configuring firewall policies such as "Captive Users Group", "VPN Users Group" etc. (Such groups dont exist in AD by default. We can create them as per requirement)
- Click ok
- Create Authentication Profile based on LDAP server and Group mapping
- Go to "Device" -> "Authentication Profile"
- Create a new Authentication profile with desired Name
- For the Authetication Type choose "LDAP"
- For Server Profile choose the LDAP server profile created using above steps
- Leave Login Attribute to default sAMAccountName value
- User domain should be entered. For example Example.
- We entered similar domain name while creating "Group Mapping Setting" also
- Leave Username Modifier to its default value of %USERINPUT%
- Go to "Advanced" tab
- Add all the groups who should be allowed as part of this authentication profle.
- This way we can have one authentication profile for VPN Users with "VPN Users" AD group and another authentication profile for "Captive Portal" users with "Captive Portals" AD group.
- Click ok to Add authentication profile
- (Optional) Create required local users and groups
- It is possible for firewall to get disconnected with AD due to policy or if AD is down. In such cases having at least a few local superusers is preferable for VPN / Captive portal authentication.
- Under "Device" -> "Local Users Database" -> "Users", create required users
- Under "Device" -> "Local Users Database" -> "User Groups" create a local group containing all local users
- Under "Device" - "Authentication Profiles" create a authentication profile of type "Local Database".
- For this "Local Database" authentication profile go to "Advanced" tab and select the local user group created in previous steps
- Click ok to complete creating a local authentication profile
- (Optionally) Create authentication sequence where first local authentication is tried before trying AD authentication
- Go to "Device" -> "Authentication Sequence"
- Create a new "Authentication Sequence" of desired name
- Enable "Use domain to determine authentication profile"
- Select both local authentication profile (If created) and AD authentication profile as part of this sequence.
- Wherever we configure this authentication sequence both Local and AD authentication will be attempted in specified sequence
- Click ok
Test AD integration with Admin roles
Easiest way to check whether AD authentication is working or not before configuring VPN (Global Protect) or Captive portal, is to enable AD based login into the firewall as administrator. If that works then we know AD integration is working as expected before we configure VPN or captive portal.
To add a AD user as admin (Perhaps just for testing AD integration, we can delete this entry later, if required) use:
- Login into Paloalto firewall
- Go to "Device" -> "Administrators"
- Click "Add" and type only the username without domain name in Name field
- Authentication profile can be "AD authentication profile" created above or we can also choose "Authentication Sequence" created above. But while testing we should have the specified user only in AD and not in local firewall users group to ensure that test is conducted properly. Hence use a username which is only in AD and not in local paloatlo user database.
- Administrator type will be dynamic with "Superuser" role
- Click ok
- Commit
- Open the firewall in a incognito window (or different browser) and validate whether AD login with specified user is working or not.
- (Optionally) delete the test admin user created for AD integration testing
Configure Global Protect VPN portal for client setup download
The paloalto firewall has GlobalProtect VPN portal where users can login and download the end user VPN client / agent. It also has Global Protect VPN Gateway. Once agent is configured and installed, it communicated with Global Protect Gateway during VPN connectivity. Hence both might be required.
To configure Global Protect VPN portal use:
- Login into Paloalto firewall
- Go to "Network" -> "Global Protect" -> "Portals"
- Add a new portal with desired name
- Select the public IP interface on which VPN portal will listen
- In "Authentication tab" under "Client Authentication" click "Add"
- Give any desired name for Client authentication
- Leave OS to be any
- Under authentication profile choose Authentication Sequence (Or profile) desired for VPN login authentication
- For "Allow authentication with User Credentials OR Client Certificate" value should be "Yes (User Credentials or Client Certificate Required)"
- Click ok
- In "Agent" tab, under 'Agent' click Add
- Choose required name for Agent
- Under 'Config selection criteria' tab leave OS as any
- Under Groups select "VPN users" group from AD
- Under "External Gateways" add the gateway with public IP of the ethernet interface selected while creating this portal
- Click ok to Add agent
- Click ok to create portal
- Commit and test https://<portal-ip-or-fqdn> using some other Internet connectivity (not via the firewall while connected to LAN zone) and try login with AD username and password
Configure Global Protect VPN gateway for VPN connectivity
As explained portal is only for download of agent. We need to configure Gateway for VPN to work. To configure Global protect VPN gateway use:
- Login into Paloalto firewall
- Go to "Network" -> "Global Protect" -> "Gateways"
- Add a new gateway with desired name
- Select the public IP interface on which VPN gateway will listen
- Ideally setup Global protect on loopback and forward (DNAT) public IP ports to loopback ports 443 (for VPN) / 8443 (for admin UI). This plays better when we need active/active VPN from two ISPs or when we need to change VPN port from 443 to something else.
- In "Authentication tab" under "Client Authentication" click "Add"
- Give any desired name for Client authentication
- Leave OS to be any
- Under authentication profile choose Authentication Sequence (Or profile) desired for VPN login authentication
- For "Allow authentication with User Credentials OR Client Certificate" value should be "Yes (User Credentials or Client Certificate Required)"
- Click ok
- In "Agent" tab, under "Tunnel Settings" enable tunnel mode
- Give name of a unused tunnel eg tunnel.1
- Enable IPSec
- In Agent tab under "Client Settings" click Add
- Give desired name for client settings
- Under Source user, select AD "VPN users" group
- Leave OS to be default any
- Under "IP Pools" tab, "IP Pools" setting add a IP pool not used anywhere in the organization (ideally not used anywhere in other branches also)
- Under "split tunnel" -> "Access route" ensure that "No direct access to local network" is not selected
- Add local Subnets under include
- Add 0.0.0.0/0 under Exclude
- Click ok to add "client settings"
- Click ok to create Global protect gateway configuration
- Commit and test by connecting to VPN using some other Internet connectivity (not via the firewall while connected to LAN zone) and try login with AD username and password
- Test connecting to local included subnets and see that they are accessible
- Optionally traceroute to some Internet machine and validate that Internet traffic is going directly and not over VPN due to split tunnel configuration
Troubleshoot GP VPN issues
Ensure following while deploying VPN (Global protect) to avoid VPN issues:
- If the VPN is via one ISP, then we should not have Policy based forwarding (PBF) for VPN client IP destination through another ISP. If there is PBF for another ISP, we must add negative (!) destination towards VPN client IP pool in that rule to ensure that PBF is not applied for VPN clients.
- There should not be any existing DNAT on port 443 for the configured ISP public IP. Ideally as mentioned preferably use a loopback IP / interface for setting up Global Protect gateway and portal. This plays better when we need active/active VPN across multiple ISPs or if we need to change VPN port from default 443.
- If there is common ISP between VPN client location and VPN server location with large subnet eg /19 then that might also cause problems in connecting to VPN. In one case we had VPN configured on a ISP (Say ISP1 for a customer). That customer also had another ISP - ISP2 with /19 subnet. Then we were trying to connect to VPN from a office with similar ISP2 connection with similar /19 subnet. Unfortunately while forward packets to VPN server were going from ISP2 at office to ISP1 at client location, since the client also had ISP2, the reply packets for us were being returned via ISP2 of customer (as we had a common /19 interface).
- No VPN or Global protect license is required when users connect to PA firewall from Windows. There is no need of corresponding license to be shown under Device -> Licenses for VPN to work.
Home > Enterprise security devices or applications > Paloalto firewall > AD integration