Let me first preface this by saying I am not our network admin, and I have no access to our Palo Alto devices, but since the teams here that are supposed to be managing them cannot be bothered to look at our issues, I wanted to see if this community might have some ideas I can take back to them.
Within our IT department, many IT staff have two user IDs, a normal one for day to day activities, email, web browsing, etc., and an administrative account for higher functions. Recently, a change was made on the Palo Altos to block web access to administrative IDs. Normally not an issue, except we are seeing our web sessions under our normal IDs suddenly switch to using our administrative IDs, and this is causing issues for many IT admins. The web browser is running on our normal machine under our normal user ID, we can validate this by going to any of our internal SharePoint sites, or to Okta, and they will show up as our normal ID, but if we try to go to something that is blocked for ADM, it thinks we are using our ADM accounts.
We have tried relaunching the web browser with run as and using our normal ID, and this does not always fix the issue. It affects all web browsers.
In my case, I can be in a web browsing session, having no issues. I then open Remote Desktop Connection to a server (no web connection that I am aware of for RDC) to perform some work, and when I return to my already opened web browser on my normal device, it now thinks I am using my administrative account and I can no longer browse the internet. I can close RDC and my web browser, and opening a fresh session is still blocked. I have to wait for the mystical time out on the Palo Alto before I can start browsing again (can be minutes, can be hours).
This is making no sense as to why or how it is happening, as as I mentioned, the team that should be looking at this has yet to do anything for the past month+ since they blocked web for our admin accounts. Has anybody seen a situation like this and have any ideas on what to look at to correct this issue?
There is a KB article which suggests this is unsupported behaviour:
When you open an RDP session, an IP to user mapping is generated for the local machine, but with the admin account you authenticated with.
Since an IP is associated with only a single user, it must remove the previous mapping.
The KB itself recommends authenticating on the RDP connection by using the same account you are logged in with locally, and then using privilege escalation to perform admin tasks.
Anyway, when this happens you can lock and unlock the machine, which will generate the correct event on the domain controller to get your 'local' mapping back.
Sadly, that work around of locking and unlocking does not always work. In fact, I have never had that work for me. Neither has logging in to another site with my normal user ID, opening the application using run as with my normal ID, really nothing that would generate any kind of log in attempt has worked except disconnecting VPN and reconnecting, but then that interrupts the work flow.
Thanks for that article though, that definitely better explains the issues we are facing for a lot of our admins. Stinks that there is no other solution and we are stuck in a less than ideal situation. Would have hoped the Palos would be a little smarter.
We use the exchange logs rather than the domain controller logs for user-id mapping. Have you asked them to switch and see if it works?
Since Outlook is always hitting exchange and authenticating each time, this keeps the mapping consistent.
I hope I understood the issue correctly.
I wonder if the Terminal services agent is used what will hapen as the web user will be mapped to an IP address but the RDP will be mapped to a port.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!