How do I find a user's last known IP Address if they've never posted to the site?

Howdy Christopher G. Stanton - Using the Auditing feature, you should be able to get the IP address from the record of the member when authenticating. 

Unfortunately Tom Paolucci the auditing feature does not go back far enough to February to have this information.

Beyond the live auditing records that can be searched in-site, the archives should be available to download and review.

The archives of the audit don't go back far enough.

The archive duration can be adjusted by configuring the Auditing Archive Job configuration in Administration. The default retention time is 30 days.

To get information about historical data, you will need to be able to access relevant logs. If your site is hosted by Verint, Verint also keeps web access logs which may or may not be able to be used to extract the information that you need--you could open a support request to get more information.

Ben Tiedt said:

As your site is hosted by Verint,

We're self hosted on Microsoft Azure. https://community.element14.com 

Ben Tiedt said:

The archive duration can be adjusted by configuring the Auditing Archive Job configuration in Administration.

That's good to know, though it sounds like in this instance it's closing the gate after the horse has bolted, so to speak.

Unless you're saying this will recreate audit logs from some deeper logging mechanism?

Ben Tiedt said:

Verint also keeps web access logs which may or may not be able to be used to extract the information that you need--you could open a support request to get more information.

I'm open to suggestions where we could search within any logs to surface this information for those hosted on an Azure instance.

Christopher G. Stanton said:

Unless you're saying this will recreate audit logs from some deeper logging mechanism?

There is not a hidden underlying mechanism. The audit logs, as shown, represent all of the data currently available.

Christopher G. Stanton said:

I'm open to suggestions where we could search within any logs to surface this information for those hosted on an Azure instance.

If you can identify unique user agent data or a more recent IP, you may be able to find related requests in web server logs.

For bots, access is often across multiple IPs but, the usage (URLs accessed or for spidering, the original URL) or other HTTP header data may show unique similarities that can be used to implement an appropriate block.

Ben Tiedt said:

If you can identify unique user agent data or a more recent IP, you may be able to find related requests in web server logs.

As a site administrator that's not something I have direct access to unfortunately, which's why I am looking for logging inside the site itself.

It would make more sense to me if the site kept a record of "last known login/registration IP address" against the user profile that administrators could view, and that this kept separately a record of last known impersonated user IP address too. I'm surprised this isn't the case and it's only in an audit log which expires.

Ben Tiedt said:

For bots, access is often across multiple IPs but, the usage (URLs accessed or for spidering, the original URL) or other HTTP header data may show unique similarities that can be used to implement an appropriate block.

Indeed you're not wrong with typical bot activity, though if this was a malicious individual user, which can be the case sometimes, it would only be the one.

Ben Tiedt said:

There is not a hidden underlying mechanism. The audit logs, as shown, represent all of the data currently available.

Shame they're so time limited.

As there doesn't appear to be a suitably good answer to:

Christopher G. Stanton said:

As an administrator with access to the admin' section of the site, and potentially using velocity script in a sandbox, how do I find out the user's IP address so that I can add them to the banned IP address list?

Within the required time frame I've raised this as an idea:

 Record the last known User's IP address in the user's profile for administrators and moderators  

To be clear, the default retention time is 30 days, you can adjust this higher

Patrick M. said:

To be clear, the default retention time is 30 days, you can adjust this higher

While this may be helpful, it is difficult when trying to find past data that may be beyond whatever arbitrary limit is set.

Other platforms have a place on the user's profile where the last known IP addresses are logged on the user's profile along with other personally identifiable information.

While it could be argued that an IP address is typically dynamic, in my experience as a site moderator dealing with either difficult members or bad actors, having some form of long term / last known active / last known IP address is significantly valuable when it's directly available.

It feels like a rather large hammer to say "increase the log for absolutely everything forever" when it can be stored and updated as a profile field on the user profile.

Christopher G. Stanton said:

Ben Tiedt said:

If you can identify unique user agent data or a more recent IP, you may be able to find related requests in web server logs.

As a site administrator that's not something I have direct access to unfortunately, which's why I am looking for logging inside the site itself.

It would make more sense to me if the site kept a record of "last known login/registration IP address" against the user profile that administrators could view, and that this kept separately a record of last known impersonated user IP address too. I'm surprised this isn't the case and it's only in an audit log which expires.

I agree with Christopher G. Stanton  that not having this data readily available can be problematic (and yes, I've voted on the idea linked in this thread). However, I was thinking about how this could be worked around, so I wanted to ask a general question about this for someone who's more familiar with development than myself.

It seems possible that one could use the List User Presence REST Endpoint to grab the id/username and location of a member and save that in the user's extended attributes, an external db, or somewhere else. This could also, in theory, show you either the running list of all IPs per user or just their last-known. This wouldn't help get the historical data that Christopher is looking for, but could be a viable Automation(?) that could run on User.AfterAuthenticate moving forward to prevent this situation in the future. 

Would/could this work? Any flaws in this (other than the actual development)?

Alex Nassi said:

Would/could this work? Any flaws in this (other than the actual development)?

If you're doing any kind of checks on the user for their IP address, you also need to check if that user is being impersonated because that can affect any code which is polling, retrieving or pulling their IP address. You would either want to store that separately or not at all after User.AfterAuthenticate.

Our development team is attempting to use core_v2_authentication.IsImpersonated() to check for this but have found that it returns false even if the account is being impersonated (aka it's not quite working), so it cannot be relied upon at present, it also claims you're impersonating an account even if it's your own account (this has been raised with Verint support).

Alex Nassi said:

Would/could this work? Any flaws in this (other than the actual development)?

If you're doing any kind of checks on the user for their IP address, you also need to check if that user is being impersonated because that can affect any code which is polling, retrieving or pulling their IP address. You would either want to store that separately or not at all after User.AfterAuthenticate.

Our development team is attempting to use core_v2_authentication.IsImpersonated() to check for this but have found that it returns false even if the account is being impersonated (aka it's not quite working), so it cannot be relied upon at present, it also claims you're impersonating an account even if it's your own account (this has been raised with Verint support).