PA VPN Authentication Via Ldap

[Jafar_Hussain]

Dear Team,

I have one scenario while connecting GP with LDAP user will get the IP address then the user is trying to connect internal server the traffic will go through the cisco FTD.  the issue is that once traffic will pass Paloalto then we checked in he Cisco FTD the user and IP address we are getting only management IP address and service account of Paloalto :-

I am giving one example for better understanding:-

Example:-

- UserA, UserB and UserC is the AD users.

- Service account name is palo@servicecccount

- Management IP of the firewall - 192.168.1.10

When USer A will connect the GLobal protect it will get the 10.0.0.1 IP address.

When USer B will connect the GLobal protect it will get the 10.0.0.2 IP address.

When USer C will connect the GLobal protect it will get the 10.0.0.3 IP address.

Traffic flow:- GP USER > PA FIrewall > CISCO FTD > internal server(172.16.1.1)

Then all the users try to access 172.16.1.1 on the CISCO FTD the IP address should show 10.0.0.1 ,10.0.0.2,10.0.0.3 with the name UserA, UserB, UserC) instead od this The Paloalto forward the detail  192.168.1.10(Managment IP) with user palo@serviceaccount . for all the AD users.

******************************************************************

Scenario 1:

GP connect with local user ---> PA (IP Based) ---> Cisco (IP based) =  worked

Scenario 2:

GP connect with LDAP user ---> PA (Ldap user based) ---> Cisco (Ldap user based -As per logs, Managment IP of PA and AD service account recieve as source) = Not worked 

Is this default behaviour or do i need to take any further action to resolve this.???

[aleksandar.astardzhiev]

Hi @Jafar_Hussain ,

I would say this is expected behavior for the current setup you have. Let me try to explain why you see PAN mgmt IP and service account.

1. When user connects to GP it sends its credentials to PAN FW.

2. After that FW will search the username in the Active Directory using its service account (in order to be able to make queries). For that it will use the management IP address (by default, if you don't change it with service route)

3. In the AD security logs there will be entry that palo@serviceaccount has login from fw mgmt ip - because LDAP bind is basically a login event.

4. (I assume) Cisco FTD user identification is working similarly like PAN - it is constantly reading AD security logs for login and logout events and parse them. Extracting the information which user from which ip has login (or logout) and creating user-to-ip mapping

5. GlobalProtect IP pool allocation is completely internal (if don't use radius), for that reason only PAN FW knows which IP from the pool to which user it is allocated and because of that it can easily map the user-to-ip.

6.So as you can see it is not actually a PAN FW problem, but your design/setup has a major flaw - PAN FW and Cisco FTD are not exchanging user-to-ip mapping information. The problem is that user-to-ip mapping is created by the GlobalProtect, so it is information that PAN FW "creates internally" and other devices are not aware of this.

7. Because your users are already login to the Windows (before the GP VPN was established) not login even for those users is generated in the AD, therefor Cisco FTD (only reading AD logs) is not aware that those users are assigned with this addresses.

I believe you have few options to workaround this:

1. Configure separate GP gateway configs, based on user group and use different IP pool for each config. That way you will have static IP ranges for each user/user group. So on the Cisco FTD you can allow the traffic based on the specific ip range. It is simple solution, but it doesn't scale good if you need to have lots of groups with different access.

2. I was thinking if you somehow can use the "framed-ip-address" - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000008UkxCAE&lang=en_US%E2%80%A... But not sure how can you get this IP on Cisco FTD.

3. You can configure captive portal on Cisco FTD to request users to authenticate when trying to access the internal server. That way FTD will also be able to build user-to-ip mapping for itself. I am not very familiar with Cisco FTD, but I guess you should be able to use Kerberos SSO so the browser will try to authenticate user transparently (without asking the user to enter creds again).

4. Not sure what user identification sources Cisco FTD can consume, but you should be able to "export" user-ip-mapping from PAN FW, but using log forwarding and HTTP/syslog/SNMP profile. This probably will require a bit more digging if Cisco can read other sources and probably bit of scripting magic.

[Jafar_Hussain]

@aleksandar.astardzhiev  THank you so much for your detailed explaination.