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.
My thoughts was regarding an (imaginary) situation where you have (for example):
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).
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)?
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.
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.
- 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).
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.
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 Live Community as a whole!
The Live Community thanks you for your participation!