Okey dokey, understood, many thanks....
from my understanding the agent for AD polls the security log and watches out for domain authentication either from logon, email, shared drives etc...
the security event also contains the user ip address so this is forwarded to pa, so user has an ip mapping.
what i dont understand is how can this be done with radius to syslog. The user ip to radius will be the interface of the PA.
so the syslog will show an accepted auth but how can this assist in user ip mapping.
sorry to waffle on but this is bugging me....
So what really happens is that the Radius system is setup to forward the accounting information. Then you get to go build out a Syslog Parse Profile for actually setting up the Regex or Field Identifier info, so that the firewall actually understands where to find the username or address within the syslog.
For example on a Cisco ACS syslog message the regex would look like this:
So once it's actually properly configured the firewall is going to get the Accounting syslog messages from the Radius server, pull the Username and Address info using the Regex you fed it, and simply associate the IP and user together exactly like user-id is doing through the User-ID agent. This is simply building all of the steps manually.
Ok, got it.... nice explanation.
this now makes sense via you cisco example because of course the user already has an ip address.
could similar be performed via globalprotect radius authentication. I know this is already dealt with locally on th pa but obviously loses its mapping if traversing a second firewall.
thanks again for taking the time to explain.
The steps are going to be pretty much the same regardless of whatever guide you follow. The only thing you'll really have to customize to your enviroment is going to be the Regex used in the Syslog Parse Profile. That will vary depending on what device you are actually using.
There really isn't a true 'agentless' method to be honest. You're taking what the agent would generally do on the server and putting the load on your firewall instead.
The agentless method can be resource intensive for the servers. Smaller enviroments you'd be fine, but the more users, DCs and more firewalls you setup to actually query the servers the worse it's going to be.
With the agents these functions are detached. The firewall only need to talk to the agents, and then only the user-id agents need the server/syslog integrations built.
The nice thing that you can do if you have multiple different firewalls, or use Panorama, is that you can replicate the user-id information to other firewalls. So if you do want to go with the agentless user-id you can perform it on one firewall, and then simply share that information with all other firewalls in your enviroment. Panorama starting with 8.0 can become the User-ID identity store and replicate the user-id information to all attached firewalls.
There are a lot of different user-id integration methods out there and I don't know if I've ever seen an install that is configured exactly the same as another; simply because the enviroments themselves don't look the same. I would really recommend asking your SE for some time to actually talk through your enviroment and see what he thinks you would be best suited for.
It seems like in any of these scenarios there could be the potential for increased load somewhere and increased logging. I currently have two DC's and two PA firewalls, one in passive mode. I have no panorama server though I do have some syslog server that i am sending some not all the PA log information.
I am going to start planning for my upgrade to 8 to occur during summer break, hopefully so I can take advantage of the additional features.
Concerning my SE, they keep changing. I have been asking about some of the options but so far we haven't really discussed what would work best in my environment, the issue came up as a recommendation via a quarterly healthcheck.
My real desire was to have a method that is as simple as possible and give me only the userid information that would give me the best security tracking capability
I started off using the one within the firewall but as @BPry Stated it depends on sizing.
as our firewalls grew well into double figures along with almost as many DCs it was an obvious move and helped to streamline the process of additional firewalls.
the traffic generated between agent and DC is a constant hum but only updates and address changes are forwarded to firewall
i do like the autodiscover on the agent, works well as long as your DNS is up to scratch.
i also like the gui, you can see the log generation in real time and can search for users to check ip status.
this of course is available via PA cli but for someone like myself that can only remember such commands as .......
format c: /y............ its a no brainer.
however... we had no issues with th local agent when used.
Essentially your passing the load onto something regardless of which method you are using. Do you want the load to be on the firewall or the agent; most people would go with agent simply because it's cheaper to add resources than generating a heavy load on your Management Plane.
As @Mick_Ball pointed out the Agent scales very nicely, the agentless method doesn't really scale all that well if you were to experiance growth within your enviroment. The GUI of the agent is also nicer if you don't like working out of the CLI, since the CLI is where I spend the majority of my time I don't really see that as a big advantage.
If you are just implementing user-id now I would generally lean towards the agent. That being said, your on the range where if you don't see yourself growing in size anytime soon the agentless method should work perfectly fine for you.
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!