Keeping UID to IP address Associations Current - A.K.A. UID Refreshes / Timeouts / Confirmations

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

Keeping UID to IP address Associations Current - A.K.A. UID Refreshes / Timeouts / Confirmations

L1 Bithead

This is a question about how a firewall, FW, keeps IP to UID associations current/up-to-date in an environment where such associations might be changing every few seconds.

 

A FW associates a UID with an internal IP address, e.g. 10.10.10.10, which has no UID associated with it. Let's say that I logon as ipj1965 from 10.10.10.10. The first time a FW sees traffic from 10.10.10.10 it will ask itself "Do I know who's at 10.10.10.10?" If not, it will ask its associated UID servers. They do know the answer, as they're constantly interrogating the Windows AD Server Logs, and will tell the FW.

 

If my UID logs off, and nobody else is given 10.10.10.10, no problem. If I 'move' to a new IP address, e.g. 10.10.10.11, that was previously not associated with a UID, the FW will associate ipj1965 with that new IP, again, by asking its UID servers. I think that this is in addition to my prior IP, 10.10.10.10. I also assume that this prior association times out after a period set somewhere in the firewall's configuration.

 

What happens when somebody else, e.g. joeblogs, is given IP 10.10.10.10? Unless the association between 10.10.10.10 and ipj1965 has timed out, joebloggs will now be permitted through any policies in which ipj1965 is a named user. When, and how, do the FWs confirm their IP address to UID associations?

 

The UID servers will know almost immediately that the joeblogs is now associated with 10.10.10.10.  Do the UID servers send a message to the FWs telling them to drop the IP/UID association whenever they learn that a UID has logged off, or changed IP? Do the UID servers keep track of which UIDs the FWs have asked them about and inform them of any changes? If it all depends on timeouts, what happens with IPs that are only associated with a UID for a short time before quickly being associated with another UID (even though it's only a single UID at any one time)?

 

I'd also like to know where this timeout is set, if that is the way the FWs keep their IP/UID associations current.

 

Thanks for any and all help,

Ian

 

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

Good Day...

 

Let me see if I can start to clarify the logic.

 

The UserID agent on the FW or installed on a DC, looks at the last 50k log entries, looking for login/logout request messages.

This list is sent over to the FW, so now the FW has the IP and the username associated with a user.

 

If an IP does not have any User information, then it becomes simply a IP inside your network.  You decide if you trust/want unknown users/IP/rogue devices in your network.....

 

You *could* (and probably should....) do an authentication policy/captive portal, to help identify and add the user to the UserID cache of the FW.  You could put up a splash page, to ask the user to identify themselves, if NTLM (browser based authentication does not work)

 

You *could* enabled IP probing (if a windows devices), so that unknown IPs are interrogated and with the correct service account permissions (Distributed COM User) allow the FW to ask the IP about who he is.. and based on the response back, update the IP cache.

 

When, and how, do the FWs confirm their IP address to UID associations?  Customer defined... with the UserID agent.

Mine is set for 2 secs.

SteveCantwell_1-1587428681530.png

 

 

The user timeout is defined in User Identification section of the FW (under the Device tab)

SteveCantwell_0-1587428547620.png

 

Granted... I am showing on the integrated UserID agent, but the same information is on the standalong UserID agent as well.

 

 

Help the community: Like helpful comments and mark solutions

View solution in original post

1 REPLY 1

Cyber Elite
Cyber Elite

Good Day...

 

Let me see if I can start to clarify the logic.

 

The UserID agent on the FW or installed on a DC, looks at the last 50k log entries, looking for login/logout request messages.

This list is sent over to the FW, so now the FW has the IP and the username associated with a user.

 

If an IP does not have any User information, then it becomes simply a IP inside your network.  You decide if you trust/want unknown users/IP/rogue devices in your network.....

 

You *could* (and probably should....) do an authentication policy/captive portal, to help identify and add the user to the UserID cache of the FW.  You could put up a splash page, to ask the user to identify themselves, if NTLM (browser based authentication does not work)

 

You *could* enabled IP probing (if a windows devices), so that unknown IPs are interrogated and with the correct service account permissions (Distributed COM User) allow the FW to ask the IP about who he is.. and based on the response back, update the IP cache.

 

When, and how, do the FWs confirm their IP address to UID associations?  Customer defined... with the UserID agent.

Mine is set for 2 secs.

SteveCantwell_1-1587428681530.png

 

 

The user timeout is defined in User Identification section of the FW (under the Device tab)

SteveCantwell_0-1587428547620.png

 

Granted... I am showing on the integrated UserID agent, but the same information is on the standalong UserID agent as well.

 

 

Help the community: Like helpful comments and mark solutions
  • 1 accepted solution
  • 3084 Views
  • 1 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!