RDP and the PAN-Agent

[mharding]

I'm noticing that when a user connects to a server using RDP with a different username, the PAN-Agent is reading that username and associating it the user's computer.

For instance, a programmer named 'jdoe' connects to a web server from his PC using IP address 172.16.3.3 using the username 'webadmin'. The traffic logs now read that 'webadmin' is logged on to 172.16.3.3.

Is anyone else having this problem?

[bpappas]

Pan Agent picks up logon events from the domain controller security event log. So if your Windows environment is somehow showing user "webadmin" instead of "jdoe" then you should first investigate the DC security event logs to verify that this is occurring and then investigate the root cause of that.

If this isn't the case then you have a mystery that should probably be resolved with a support case.

-Benjamin

[OCDBE]

We noticed exact the same issue some days ago.. Very annoying and i'm afraid it can this issue will not be solved quickly since the Pan-agent is reading some log types of the dc security logs , i guess.

Anyone who can confirm this ? Is PA working on this ?

[mharding]

Well, it is valid in the event log. I noticed it on my Mac using RDP also.

I thought the NetBios probes would re-query the workstation, but this is not the case.

[bpappas]

The NetBios probe should query the workstation every 20 minutes (default) and re-map the user-to-ip-mapping if warranted.

The real question here is why is your Windows environment showing a logon to your user's PC from the webadmin user?

[mharding]

Here's an example from one of our Server 2008 R2 DCs when using MS-RDP.

Log Name:      Security

Source:        Microsoft-Windows-Security-Auditing

Date:          2/1/2011 3:59:30 PM

Event ID:      4624

Task Category: Logon

Level:         Information

Keywords:      Audit Success

User:          N/AComputer:      ITDNS2.lab.org

Description:An account was successfully logged on.
Subject:     Security ID:          SYSTEM

Account Name:          ITDNS2$

Account Domain: LAB

Logon ID:          0x3e7
Logon Type:               10
New Logon:     Security ID: LAB\administrator

Account Name:          administrator

Account Domain:          LAB

Logon ID:          0x2a9158bb

Logon GUID:          {00000000-0000-0000-0000-000000000000}

Process Information:

Process ID:          0x584

Process Name:          C:\Windows\System32\winlogon.exe
Network Information:

Workstation Name:     ITDNS2

Source Network Address:     172.16.16.200

Source Port:          60635

Detailed Authentication Information:

Logon Process:          User32

Authentication Package:     Negotiate     Transited

Services:     -     Package Name (NTLM only):     -     Key Length:          0

This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.     - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.     - Transited services indicate which intermediate services have participated in this logon request.     - Package name indicates which sub-protocol was used among the NTLM protocols.     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

[reaper]

adding your RDP servers to the panagent ignore list may help eleviate this issue since it should then stop collecting logon info from your server and only check your user pc's

[mharding]

Well, it's collecting the logon information from the client side, not the server side, in AD.

I imagine that it’s coming from the way Terminal Services Client 6.0 send the credentials first before letting you log into the server. I think 5 would bring up the console, and then allow you to login.

[bhavin_bhatt]

Hi, I would like to elaborate on a similar issue that i am having.

i have 2 usernames, a local one say abc and another one with more privileges, say xyz.

i use xyz to rdp to servers etc. and am usually logged into my pc with abc. my problem is that i am using usernames in the palo alto firewall for creating policies, and both of these user-ids have specific groups that they are part of being allowed through the firewall for different reasons.

Hence adding a particular user to the ignore list on the pan-agent isnt a solution, and the fact that the palo alto firewall maps users to an ip address, and the otherway round could be a bad news for a company that my use kiosks or hotdesking ...

Please advice if there is a solution for such issues.

cheers

Bhav

[jcostello]

Clarification question:

Which system is being marked with the rdp user login? Server or workstation?

Thanks

James

[bhavin_bhatt]

Hi James,

the workstation and its ip address are being associated with the local login as well as the ad login credentials used to rdp to other servers.

This confuses the palo alto while deciding which user to associate the ip address to...the correct policy does not match for the user in question.

cheers

[mharding]

My solution was to exclude the subnet our servers were on. May not be viable for everyone.

[mrajdev]

Bhavin,

The server account which you use to login during an RDP session is it part of domain administrator account? If yes then can you please try an account which is not part of domain adminstrator and see if the PC retains it original user id and IP address.

Thanks

[bhavin_bhatt]

Hi mrajdev,

thanks for the response, i am afraid the usernames are part of the domain and unfortunately, in our environment, non-domained usernames are not permitted, is there any other solutions ?

i was thinking of ignoring the admin ad users on pan-agent and use the sys admins ip addresses in the policies, not a very smart solution, but am still in search of a better solution to this problem.

Cheers

Bhav

[bryan]

Hello Bhav,

When this issue occurs, are you logging on via RDP to a Domain Controller? If so, can you attempt to logon via RDP to another Server/Workstation (Non-DC) & confirm whether the original User-ID mappings on both machines are retained?

Thanks,

Bryan