- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
01-28-2018 05:45 PM
Hi Fellas!
I have integrated a Windows Based user-ID agent to our VM-300 series firewall and having some issues with some users not having ip-user mapping.
Since we are enforcing security policy by AD groups for internet access, these users that doesn't have ip-user mapping will not be able to access the internet.
Some times, I will let the user to logout and login again to their computer, then the ip-user mapping will appear in the agent.
My questions are:
> What is the frequency where firewall receive user-ip mapping from Windows based agent?
> What will happen when the user-id agent was not able to read all the monitored server security logs during the
'Server Log Monitor Frequency' (my current settings is 5sec, up from the default which is 2sec)?
> If there is an existing user-ip mapping for a specific user, then the user logged-out from their machine,
would the user-ip mapping (for this user) removed from the agent?
> If the user stayed idle/locked computer for a long time, let's say 3 hours, and then my 'user identification timeout' is set to 45mins, will the agent remove its ip-user mapping? If this is the case, then only way to get the mapping back is to have the user log back in again?
Thanks in advance!
01-30-2018 12:38 AM - edited 01-30-2018 12:38 AM
hi @OliverNario
yes, 12 hours is perfectly ok if you're in a normal office environment where people don't go about roaming (switching IP) a lot
i've added my replies in orange below so we don't lose track 🙂
> User agent monitors AD servers' security log based on the 'Security Log Monitor Frequency' yes
> User agent maps the user with IP based on the security log read, and retain its mapping based on the 'User Identification yes
Timeout'
> If for example user A logout from a machine A, user mapping will still persist on the agent yes
> If another user for example user B login to the same machine A, user A mapping will be flushed, and user B will have the
new ip-user mapping yes (this is also true for 'remote desktop' login for example, so this could be tricky)
> User agent reads the delta between its last read and latest AD read yes, with a maximum of 'last 50.000 entries' in the AD log
> User agent ONLY communicates and update firewall for delta (new/removed) user-ip mapping yes, there are no intermediate 'refresh' connections towards the firewall, only add/delete. any non-existent mappings are asked by the firewall to the agent
Currently, the frequency between reads is 5sec, and this is because we suspect that the agent can't read everything within 2secs factoring link speed and AD performance. In those 5 seconds more logs will also be written, so if there is some sort of latency in reading, increasing the timer may help if the log volume is not too much that adding more times simply adds so much logs the agent runs desperately behind on trying to catch up. If system resources are an issue, you may want to look into putting your AD on a beefier system, or setting up a replication server that simply receives sync from the primary AD and use that as your agent server, taking the load off the primary AD. In general I'd recommend having the read timer as low as possible to get the mapping as quickly as possible
The ip-user mapping has improved from 80% to maybe around 95%, however there were times that user reports internet access is blocked for a brief period of time, then when they refresh the browser, it will work as normal. This could be due to the frequency between reads, as it will take more time for the agent to update the firewall for new users. I agree
Not really sure what could be the best solution, the former or the latter. Both seems to have its trade off. beefing up the AD could help, adding a secondary with a second agent or simply as replication to have more resources and read faster could help. you could also consider setting up captive portal (in a windows environment you can even use transparent NTLM) so any stragglers authenticate on the firewall directly and get a mapping in lieu of the agent getting a mapping out and lastly, you could also leverage probing so the agent goes and asks the client who they are, if no log has been read (yet) containing a logon success.
To reduce server load you could consider tuning down on audit logging on the AD
01-29-2018 12:53 AM
@OliverNario. Hi.
I'm sure someone will post back to the answers you are asking but for me...
45 mins is not very long for timeout. I have this set to 12 hours but 4 to 8 hours seems to be preferred by most.
the agent reports on change. so.. if a user logs off and the IP is removed from the security log within AD then yes the mapping will be removed.
we have had issues wher temp loss of mapping has caused downtime for internet access but this was mainly due to bad planning and a lack of understanding around the agent.
I would assume you have more than one AD server...
for the last 4 years we have had 3 seperate agents pointing to all our AD servers with a timeout of 12 hours and have had absolutely no issues..
this does not really answer all of your questions but will help prevent any of those issues from occuring,,,
01-29-2018 01:06 AM - edited 01-29-2018 01:08 AM
Hi
What is the timeout you have set in your user-ID agent? The default is 45 minutes but you may want to increase that if there are not many 'logon success' events on the AD
> The user-ID sends mapping updates (new or removed) to the firewall immediately
> Then you will want to decrease your time between reads: the user-ID agent reads the delta between it's last read and it's latest read in the AD logs. if it needs more time to read said logs than the time to it's next event, you might get into a situation where reads are missed. Also: the longer this time between reads, the longer it takes for a new user to be learned and forwarded to the firewall, potentially blocking legitimate access (if the user logs in the exact moment a read has already started, it will take at least 5 seconds for his user-id to be picked up and mapped to the firewall, so 5 seconds a userbased security policy cannot be applied yet)
> No, logout events are not picked up as they are unreliable (users may power off without loggin out)
> yes, after 45 minutes the mapping is removed unless a new logon event is registered on the AD (activity on the firewall does not refresh this timer)
> there's many ways to refresh mappig: the User-ID agent can be set up with probing enabled (netbios or WMI), this does 2 things:
Check out this article for more information: Getting Started: User-ID
01-29-2018 02:21 PM
Hi, we've had some issues using the User-ID agent on the PAN, but I think it's due to us having multiple domains. We had the same issues you were having , where we'd get a user-IP mapping 50% of the time. We tried tuning it, but couldn't imrpove it very much. After working with our sales engineer and PAN support, it looks like Captive Portal is the way to go for 100% user-IP mapping, but that can be a little aggressive for the user community.
We're looking into the other reccomendation which was having a server in each domain with a software agent that connects to the domain controllers and then reports back to the PAN. We're told this should get us much better results, and son't require us to put an agent on an actual DC.
01-29-2018 03:45 PM
Hi reaper thanks for the response. It gave me more insight on how the sending of user mapping updates from agent > firewall
Our current user identification timeout is set to 12 hours (same as DHCP lease timeout), as I've read somewhere that this is the best practice, correct me if I'm wrong.
So now, from my understanding this is what the behavior looks like:
> User agent monitors AD servers' security log based on the 'Security Log Monitor Frequency'
> User agent maps the user with IP based on the security log read, and retain its mapping based on the 'User Identification
Timeout'
> If for example user A logout from a machine A, user mapping will still persist on the agent
> If another user for example user B login to the same machine A, user A mapping will be flushed, and user B will have the
new ip-user mapping
> User agent reads the delta between its last read and latest AD read
> User agent ONLY communicates and update firewall for delta (new/removed) user-ip mapping
Currently, the frequency between reads is 5sec, and this is because we suspect that the agent can't read everything within 2secs factoring link speed and AD performance.
The ip-user mapping has improved from 80% to maybe around 95%, however there were times that user reports internet access is blocked for a brief period of time, then when they refresh the browser, it will work as normal. This could be due to the frequency between reads, as it will take more time for the agent to update the firewall for new users.
Not really sure what could be the best solution, the former or the latter. Both seems to have its trade off.
01-30-2018 12:38 AM - edited 01-30-2018 12:38 AM
hi @OliverNario
yes, 12 hours is perfectly ok if you're in a normal office environment where people don't go about roaming (switching IP) a lot
i've added my replies in orange below so we don't lose track 🙂
> User agent monitors AD servers' security log based on the 'Security Log Monitor Frequency' yes
> User agent maps the user with IP based on the security log read, and retain its mapping based on the 'User Identification yes
Timeout'
> If for example user A logout from a machine A, user mapping will still persist on the agent yes
> If another user for example user B login to the same machine A, user A mapping will be flushed, and user B will have the
new ip-user mapping yes (this is also true for 'remote desktop' login for example, so this could be tricky)
> User agent reads the delta between its last read and latest AD read yes, with a maximum of 'last 50.000 entries' in the AD log
> User agent ONLY communicates and update firewall for delta (new/removed) user-ip mapping yes, there are no intermediate 'refresh' connections towards the firewall, only add/delete. any non-existent mappings are asked by the firewall to the agent
Currently, the frequency between reads is 5sec, and this is because we suspect that the agent can't read everything within 2secs factoring link speed and AD performance. In those 5 seconds more logs will also be written, so if there is some sort of latency in reading, increasing the timer may help if the log volume is not too much that adding more times simply adds so much logs the agent runs desperately behind on trying to catch up. If system resources are an issue, you may want to look into putting your AD on a beefier system, or setting up a replication server that simply receives sync from the primary AD and use that as your agent server, taking the load off the primary AD. In general I'd recommend having the read timer as low as possible to get the mapping as quickly as possible
The ip-user mapping has improved from 80% to maybe around 95%, however there were times that user reports internet access is blocked for a brief period of time, then when they refresh the browser, it will work as normal. This could be due to the frequency between reads, as it will take more time for the agent to update the firewall for new users. I agree
Not really sure what could be the best solution, the former or the latter. Both seems to have its trade off. beefing up the AD could help, adding a secondary with a second agent or simply as replication to have more resources and read faster could help. you could also consider setting up captive portal (in a windows environment you can even use transparent NTLM) so any stragglers authenticate on the firewall directly and get a mapping in lieu of the agent getting a mapping out and lastly, you could also leverage probing so the agent goes and asks the client who they are, if no log has been read (yet) containing a logon success.
To reduce server load you could consider tuning down on audit logging on the AD
01-30-2018 02:23 AM
I'm not sure regarding the logic of DHCP 12 hours.
i would assume that all devices obtained a new IP address every day...
would it not help if the DHCP was set to 7 days so that the device kept the same address for a longer period of time...
01-30-2018 06:56 AM
its one unit of measure 🙂
Another (which I usually recommend for a static office environment) is the length of a kerberos ticket awarded to a logged on system by the AD (10 hours default, configurable)
After the ticket expires the user will generate a new auth entry and the entry will be renewed, if they're still in the office after 10 hours
01-30-2018 07:43 AM
Hello @Mick_Ball,
DHCP clients reach back out to renew their leases at 50% of the set lease time. For many years I have taken the approach of giving the lease time long enough for me to rebuild a server. For my users its 3 days, guest networks 8 hours, servers 7 days.
Just my thoughts.
Regards,
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!