User-ID agent connects and disconnects in seconds...

[kalyanram.piratla]

Hey Guys,

Can someone please explain why the User-ID connects and disconnects immediately.  I can see this happening under the system logs thereby this does not populate the source users under the traffic and url logs.

I tried looking up the knowledge base to understand this issue but was unsuccessful.  I then even went through the whole process of configuring the User-ID agent, LDAP and User-ID on the firewall from the beginning.

The box is not in production at the moment as i was doing an Eval.  It wasn't an issue, but out of interest and to seek knowledge posted it.

Many Thanks,

Kalyan

[bnelson]

Kal,

What versions of PANOS and User-ID Agent are you running? I have seen some weird behavior with older versions of the User-ID Agent running. Could you also provide the debug log from the agent itself? This could shed some more light on the issue.

Ben

[kalyanram.piratla]

Ben,

PANOS version 4.1.6 and User-ID agent 4.1.3-2.  Unfortunately, I cannot get the debug log from the agent as the customer has uninstalled the agent.  This was happening when the box was placed in VWire mode for evaluation and unfortunately I realized it after the unit was shipped back to me..!!!

Cheers...

Kalyan

[bnelson]

It is unfortunate that we don't have access to the User-ID Agent logs, but not the end of the world. If the logs are still on the firewall, you can log into the cli and view the useridd.log for any errors that may point toward a cause of the frequent disconnects.

less mp-log useridd.log

This may provide more detail on the disconnects.

Ben

[kalyanram.piratla]

Ben,

Thanks for the info.. I will get the information and then let you know accordingly....

Cheers..

Kal

[kalyanram.piratla]

Ben,

I did look up the userid logs via the CLI, but they just seem to make no sense to me.  Used less mp-log useridd.log and less mp-log useridd.log.old and both give me the same information.  Please see below:

Please let me know if rings any bells..!!!

Kind Regards,

K

[shasnain]

what port are you using on the agent to connect to the PAN. Try using a port above 10000 and see if that makes any difference.

Thanks,

Syed Hasnain

[kalyanram.piratla]

Used 5007 and 5006.  I will not be able to test it now as it was an evaluation that I was doing for a customer.  All this was realised after the box was pulled out from virtual wire mode (end of evaluation).

So will not be able to do anything now.

[jdelio]

Here is simple question..

Where is the User-ID agent installed on?

If installed ON the Domain Controller itself.. it is not recommended.

Also, if installed ON a Windowd 2008 R2 server, that also is not supported, unless we have a 2008R2 client available.

It is recommended to install on a Windows 2003 server that can talk with the Domain controllers.

[mikand]

How come its not recommended to install it on the DC itself?

If we take larger installations there will be shitloads of networktraffic for the userid agent when its tailing the security logs of all DC servers (specially when you have more than a few DC servers in your network).

[jdelio]

It is not recommended to install the agent on the DC itself for many reasons..

1. Extra load on the server itself, keep the 3rd party apps limited on the DC itself

2. In case that DC goes down for whatever reason, you do not loose an agent.

You can have 2 or more User-ID agents that back each other up in case one dies.

Then they are responsible for communicating with the DC and the Firewall in question.

Each User-ID agent can talk with multiple DC's.. which is normally how it is all setup.

About Larger installations.. yes, you are completely correct.. there can be a lot of traffic generated..

also depends on if you are using NetBios or WMI probing..

Also in larger installations.. it is probably recommended to reduce how often/interval, the polling takes place.

To limit the traffic somewhat.

I hope this makes a little bit of sense.. and I am sorry that this was not explained to you before.

[mikand]

My thoughts was regarding an (imaginary) situation where you have (for example):

Background:

5 sites with PA-devices (lets say two failover pairs like one pair for external communication such as Internet etc and one for internal communication such as servers etc).

Which gives 20 PA-devices in total (5 * 2 * 2 = 20) - (im not sure if the passive unit will be connected to the userid server or not, anyone who knows?).

And at the same time 25 locations with two DC's at each location.

Which gives 50 DC's in total.

Along with 10.000+ users...

A simple setup (regarding userid) would then be two userid agent servers per site (for redundancy) which bring you 10 userid agent servers in total. Each PA would then have a list of 10 userid servers (or just 2 from the local site if you need to be gentle with the wan - however the amount of traffic between PA and userid server is far less than between userid server and DC)

According to a previous post its reasonable to assume that traffic load between one userid agent server and a DC would yield approx 3Mbit/s (or so) specially with many concurrent users.

Because all users can reach all sites each userid agent server must tail ALL the DC servers who exists in this network (50 of them).

This means that each userid agent server would have a sustained rate of approx 150Mbit/s (50 * 3Mbit/s = 150), which with 10 of them means you would have a network load of 300Mbit/s per site just for the tailing (and that is if we assume in this calculation that the DC's isnt available on the PA sites otherwise there will be even more traffic).

Now...

If we instead install one userid agent server (service) on each DC and configure it so it will only tail localhost and nothing more (relation would be 1:1) then yes each PA device would need to connect to 50 userid servers (instead of "just" 10 as previously).

However the traffic between each PA and each userid server is far smaller than the "tail -f" which the userid agent must process if the DC isnt installed on the same box.

Also if one DC goes down this doesnt matter since this particular userid server will be unavailable BUT this particular userid server only monitored this particular DC (since it was the same box).

Which leaves us with the question of how demanding is it to run a userid server service?

Since the traffic never goes out on the network it should be a few percent less load on the service itself (less waiting) and since this service also only monitors localhost (and NO remote hosts, perhaps only some exchange server if needed) then the load (I imagine) shouldnt be higher than if you open up the eventviewer on the DC and stare on each row who is flowing by (which should take more resources since the eventviewer draws to the screen which the userid process doesnt really have to 😉

The above is with the assumption that the DC's doesnt replicate the security log between each other which means that each userid server must tail all your DC servers in your network otherwise you will end up with blind spots.

Or how can this otherwise be setup (setting higher timeouts isnt an option because this would mean higher probability that wrong user is logged in the PA-device)?

[ucteam]

I agree with mikand on this one.. especially in large dispersed networks.. manytimes installing on DC's is the best solution..

And if its not recommended architecture then Palo Alto should officially document that .. I'm fairly sure I remember multiple refreneces in PA documentation referring to Agents been able to be installed on DC's.

And the proposed reasoning behind not installing on DC's..

1.) "Load issues on a DC"..??  have you seen how much network resources (bandwidth) a remote Agent uses vs the CPU cycles and Memory when locally installed on a DC (ie. not having to pull all the event logs across the network). Agent cpu/memory utilisation is miniscule vs it's potential for bandwidth utilisation.

2.) "The domain controller could go down"...??  well if your thinking on a small scale and you've only got "one" DC in your network and it goes down your fairly screwed anyways.. and how does having it on another server reduce your risk? it just moves the risk/dependancy to another device.. now your dependant on 2 separate devices been up and running correctly in order for your authentication to work.

Dont get me wrong I understand security and administrator concerns around installing third party applications onto devices as sensitive and trusted as domain controllers.. you need to review your options with how to plug in the PA to your authentication service and the best option will vary between different businesses/ networks..

When dealing with small systems/networks architecture is less important.. you could do it anyway and your not likely to have issues.. however on larger scales the architecture/ implemtnation type become vastly more important.. and making the wrong descision can have unfortunate consequences.

[mikand]

1) Also to take into account (if we use my numbers as example) what you need to compare is the cpu usage of:

- Running userid locally and only tail localhost.

vs

- The DC must maintain a feed to 10 userid servers (which per DC would mean approx 30Mbit/s in this example).

2) This is already handled (in my example) because there is a 1:1 relation between each DC and the userid process which the PA connects to. If the DC goes down then the service is unavailable for this particular DC - so from the userid point of view there is no loss.

If the DC dies (and therefor the particular userid service) the dead DC wont be able to login any new users anyway.

DC2 (which runs its own userid service taling localhost) will handle new logins to the network and with the help of the userid process notify all PA boxes which user is using the particular ip who just logged in.

Regarding security concerns I assume you already runs at least a third party antivirus software on your DC's to protect them somewhat from bad stuff. Also even if you use dedicated userid servers they should be protected equal way as each DC (or even more since DC's can be readonly (well somewhat readonly at least)) because what the userid tells the PA will result in which open holes will exist in your network (for example between clientnetwork and a specific server). I mean instead of trying to hack the DC or some AD accounts you could try to hack the userid server instead to gain access (at least access so your bad packets will hit the server you are interrested in).

[kalyanram.piratla]

Hello Guys,

Thanks a ton for the information and the insight view of about DC's and User-ID agent.  I am relatively new to Networking hence any such knowledge is always a learning curve for me.

But, I am still unable to figure out the reason behind the connects and disconnects every 5 seconds.  As said earlier; it was an evaluation unit and I cannot get any logs as the box is not in-line anymore neither is the User-ID agent present on the DC.

Are there any reports on such type of a behaviour?

Mikand and UCteam - Thank you very much for the detailed explanation.  Very much appreciated.

Kind Regards,

Kalyan