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.
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!