RDP through GP tunnel with a different user.

[Ben-Price]

Hi All,

I have a client that has recently run into an issue, after upgrading to PAN OS 10.1.2. When they connect to Global Protect with their username and then try to RDP through the GP tunnel to a server on site using a different user account that is not in the allowed GP user AD group, the GP tunnel looks to freeze (doesn't disconnect) and all users have to reconnect to GP. 

Client advised that they were able to do this prior to upgrading. The traffic log detects the different username being used through the tunnel. The client has now added the different user into the allowed GP AD group and this looks to have resolved the issue. The client can now RDP through the tunnel with this different user, when logged onto GP with their user account.

It looks like the PAN is now smart enough to detect the different user trying to connect through the tunnel, where it may not have been before. GPS log has a gap in logging for approx. 10 mins when the different user tries to login over the tunnel, so not much there to go on by the looks.

So, I am wondering if this type of thing should be possible or not? Has anyone come across this type of thing before? Why does the whole tunnel seem to go down when they login as the different user? 

Thanks.

[Ben-Price]

@BPry @reaper any ideas here?

[Ben-Price]

@nikoolayy1 Any chance you could comment on this?

[GerardGlynn]

Hi Ben, 

Facing the exact same problem with GP at a customer site. 

Did you manage to resolve the problem ?

I will try adding AD user-ID administrator to the AD Group GlobalProtect , but I think we are still facing that same problem where if I login to GP using AD user-ID "BobHope" , then RDP through the GP tunnel onto a server and login with AD user-ID "administrator" , it kills access through the tunnel 

Any help or suggestions appreciated 

thanks

ger

[OtakarKlier]

Hello,

Let me see if I understand:

User = john.doe logs in with global protect.

The PAN see's all traffic in the logs from that VPN IP address as john.doe

User tries to RDP to a server with jane.doe and the PAN now sees the traffic as jane.doe?

Regards,

[GerardGlynn]

Hi Otakar, 

Yes thanks , that's the issue

I think it's also described in this article

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CleBCAS

Trying to come up with a workaround for this scenario. Remote user is logged into GP with userid-1, then that user opens a remote desktop session to a server through the GP tunnel and they login with userid-2

This activity stops their traffic going thru GP tunnel.

I think its a security feature within the GP design  

[GerardGlynn]

Hi Otakar, 

We decided to apply the “split-tunnel” config to their Global-Protect setup , where only traffic sent to their HQ internal networks is put into the GP tunnel.

This appears to have resolved the overall issue. In that they can now be logged into GP with AD User-ID-bob , then RDP onto an internal server with AD User-ID-jane and GP continues to work

Not exactly sure why split-tunnel has resolved it, but have tested a few times and all good

Cheers

Ger

[OtakarKlier]

Hello,

I have a better understanding now. We decided to use Exchange logs for user-id mapping as this seems to prevent this from happening, since the second user is not using exchange.

Regards,

[aleksandar.astardzhiev · Accepted solution]

Hi @GerardGlynn ,

What you experiencing only make sense if you have User-ID agent deployed in your network (either via separate agent installed on server or the integrated agent in the FW itself).

If that is the case it make sense to experience exactly what is described in the link you provide.

- When user login to GP, firewall will use that information to create ip-to-user mapping (since it already have the required information: authenticated user and allocated IP address)

- When user makes RDP login attempt, this will create security log under the Domain Controller. Which will be picked up by the User-ID agent and override the existing user-to-ip mapping with the username used for the RDP connection.

Apart from @OtakarKlier suggested approach I would add another two:

- As suggested in the article you can add the username used for the RDP to ignore list on the user-id agent. This will tell the agent to ignore any logon events and not create user-to-ip mapping for that user

- What I would suggest in your case is to add the GP network to user-id agent exclude network list. This will tell the agent to ignore all events for users connecting from that network. I believe this make sense, because you already have user-ip-mapping from GP, which is far more accurate from the agent, so it doesn't make sense to receive mapping from somewhere else, for something that FW already knows.

[GerardGlynn]

Hi Astardzhiev, 

Thanks for your post which is very helpful. Of course, the split-tunnel idea did not fully resolve the issue so have abandoned that for now

I will try your suggestion with excluding the GP-remote-LAN from the user-ID detection, which seems like a good solution

[GerardGlynn]

Hi Astardzhiev, 

If you apply your workaround below, do you also have to remove source user-id matching from the security policies relating to inbound Global-Protect traffic ?

- What I would suggest in your case is to add the GP network to user-id agent exclude network list. This will tell the agent to ignore all events for users connecting from that network. I believe this make sense, because you already have user-ip-mapping from GP, which is far more accurate from the agent, so it doesn't make sense to receive mapping from somewhere else, for something that FW already knows.

Thanks

ger

[GerardGlynn]

Ignore that last message about the security policies, I had forgotten to add an "include-list" of 0.0.0.0/0 to  accompany the "exclude-list"

seems to be working now 

thanks again