Windows Based User-ID Agent Setup

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Windows Based User-ID Agent Setup

L0 Member

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!

1 accepted solution

Accepted Solutions

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


 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

8 REPLIES 8

L7 Applicator

@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,,,

Cyber Elite
Cyber Elite

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:

  • every X minutes the probe will 'probe' all users to see if theyre still logged on. If not (or attempt is bloked, so make sure to  accommodate the client firewall) the user mapping will be removed
  • if the firewall sees an IP that has no mapping associated, it will ask the user-ID for information. if the User-ID also has no mapping, it can use the probe to try and find out which user is logged on, and use that information to create a mapping (so no AD event required)

 

 

Check out this article for more information: Getting Started: User-ID

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L0 Member

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.

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. 

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


 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

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,

  • 1 accepted solution
  • 6401 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!