11-29-2017 03:14 AM
When enabling user-id where does it check against to get the information to identify the users? I have it turned on for serveral zones and it only seems to work on the VPN user-id's.
12-20-2017 10:43 AM
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....
12-20-2017 10:54 AM
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.
12-20-2017 11:06 AM
My SE gave me this link seems pretty good but I assume there are more ways to do it other that this
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.
12-20-2017 11:12 AM
Maybe something like this - i just found this link
12-20-2017 11:32 AM
Someone may have already said this but wouldn't you be able to send the radius accounting syslog directly to the PA and not have to relay through another device?
12-20-2017 11:34 AM
Another thing what if my AD-LDAP, Radius server for the wireless, and active directory domain controller are all the same box?
12-21-2017 07:08 AM
@BPry @Mick.Ball @reaper @OtakarKlier @kiwi
Is anyone using the agentless method? If so pros and cons.
12-21-2017 08:10 AM
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.
12-21-2017 08:25 AM
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
12-21-2017 08:28 AM
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.
12-21-2017 08:34 AM
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!